From tuwpress@hotmail.com Thu Jan 1 12:54:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14866 for ; Thu, 1 Jan 2004 12:54:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ac71y-00076W-00 for ccamp-archive@ietf.org; Thu, 01 Jan 2004 12:54:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ac701-00071y-00 for ccamp-archive@ietf.org; Thu, 01 Jan 2004 12:52:48 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ac6xw-0006xk-00; Thu, 01 Jan 2004 12:50:36 -0500 Received: from [209.58.115.177] (helo=ietf.org) by mx2.foretec.com with smtp (Exim 4.24) id 1Ac6xt-0005Jh-Fb; Thu, 01 Jan 2004 12:50:34 -0500 From: "O pequeno Lucas:" To: ipcdn@ietf.org Subject: Um exemplo para o Brasil ref.: ezg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Thu, 01 Jan 2004 12:50:34 -0500

qqf Feliz Ano Novo para você e família! Atenciosamente, Ferreira Passos, Atualidade Brasileira. Lucas:EnCastellano Lucas:InEnglish ProximosEnvios:SoloEnCastellano NextMessages:OnlyInEnglish

Dez. 29, 2003: Atualidade Brasileira, Rio de Janeiro.

O pequeno Lucas: um exemplo para o Brasil

Deu seu último suspiro segurando com suas mãozinhas um Menino Jesus e uma Medalha Milagrosa, e partiu para celebrar seu primeiro Natal no Céu

Lucas da Rocha Silva nasceu em São Paulo, no bairro industrial de Itaquera, zona leste da cidade, em 28 de novembro de 1994. Foi ele crescendo normalmente, como todas as crianças de sua idade, quando, na madrugada de 1o. de novembro de 2000, próximo a completar 6 anos, acordou com fortes dores na tíbia de sua perninha esquerda. Começava a trilhar uma dolorosa e inesperada via crucis que a Providencia, em seus misteriosos desígnios, lhe tinha reservado, e que ele aceitaria de maneira exemplar, até seu falecimento em 15 de dezembro de 2003.

Um exame de raios-x indicou uma fratura no local da dor, o que levou os médicos a engessarem sua perna por um mês. Mas a dor ia aumentando. O pequeno pegava então o seu tercinho, dizendo que rezaria Ave-Marias "até a dor passar". Conseguia assim adormecer, mas, no dia seguinte, seu drama recomeçava.

Em março de 2001, uma biopsia feita no Hospital Santa Marcelina indicou um tumor na tíbia. Passou a ser atendido no Instituto de Oncologia Pediátrica, do Hospital São Paulo, onde foi submetido pouco depois a um implante de ossos, para tentar deter o avanço do tumor; mas este se expandiu para o joelho, e depois para o fêmur, obrigando a mais duas cirurgias, a última das quais, em abril de 2003, lhe amputou a perninha esquerda.

O pequeno Lucas foi aceitando todos esses sofrimentos com admirável espírito cristão, como vindos da vontade de Deus, sem jamais se deixar abater, nem reclamar pelas dores ou pelo seu infortúnio. Disto são testemunhas seu pai, Carlos Alberto Gil da Silva, 39; sua mãe, da. Maria Aparecida da Rocha Silva, 36; seu irmão Klayton, 14; seu melhor amiguinho, Luizinho; seus familiares; médicos; professores; coleguinhas; vizinhos, e todos quantos o conheceram.

Desde a primeira cirurgia, precisou acordar três vezes por semana às 5.30 hs. da manhã, para ir ao Hospital e ser examinado pela sua médica, além de submeter-se a sessões de quimioterapia, radioterapia, e outros exames. Lá, enquanto aguardava o atendimento, costumava, com sua conversa alegre e animada, e participando de jogos, estimular outras crianças com doenças similares, que compreensivelmente se encontravam abatidas e tristes. Ainda com sua perninha amputada, ele deu um jeito de continuar a jogar bola e andar de bicicleta. Às vezes, quando o atendimento atrasava e o relógio estava perto do meio-dia, procurava sua médica e lhe dizia: "Por favor, me chama logo, tia, que preciso ir à escola". Seu senso do dever fez com que, até o final, continuasse a ir à escola, onde obteve sempre notas acima de 8.

O esforço de seus médicos, e as cirurgias, não impediram que, a partir de abril de 2003, o implacável tumor se alastrasse por seu debilitado organismo, passando do fêmur aos pulmões, e daí, ao maxilar e ao pescoço; o que foi multiplicando seus sofrimentos, pois agora sentia dificuldades para falar, se alimentar e mesmo respirar.

Em setembro de 2003, enquanto Lucas aguardava para efetuar um dos intermináveis exames e tratamentos, uma alma caridosa lhe deu de presente uma Medalha de Nossa Senhora das Graças, a Medalha Milagrosa, que passou a usar continuamente, com piedade sincera, até os últimos instantes de sua breve vida terrena, que já se aproximavam. Também ganhou um livrinho com a historia de Nossa Senhora de Fátima e dos três pastorinhos videntes, e ficou assim sabendo que um deles, Jacinta, falecera sendo ainda uma criança. Todas as noites, o pequeno Lucas pedia à sua mãe para ler algumas páginas desse livrinho; depois, rezava a Oração ao Anjo da Guarda e adormecia.

Algumas semanas antes do Natal, Lucas ganhou também um pequeno Menino Jesus na manjedoura, que recebeu com devoção e alegria, dizendo serenamente a seus pais que este Natal ele o passaria no Céu junto com seu avô paterno, que falecera alguns meses antes. De fato, seu corpo já não mais agüentava a quimioterapia e a radioterapia, que foram suspensas em novembro de 2003. Então seus pais convocaram os familiares e amigos para, na igreja de Dom Bosco, perto de seu lar, anunciar-lhes que os médicos já nada mais podiam fazer: seu filho agora estava inteiramente nas mãos de Deus e de Nossa Senhora. O menino, perto do altar, ouviu tudo com o rosto sereno, ao mesmo tempo decidido e resignado, com a mesma cristã serenidade e resignação que tivera desde o começo de sua doença, sem jamais reclamar de sua situação ou de suas enormes dores.

Na noite de 13 de dezembro, Lucas teve um agravamento de seus problemas respiratórios, devendo ser levado com urgência ao Instituto de Oncologia Pediátrica. Em sua escrivaninha, ele deixava, em perfeita ordem, "santinhos" de Maria Auxiliadora, Dom Bosco, Santa Madre Paulina, Beato Frei Galvão, Sta. Rita de Cássia, São Benedito, Santo Expedito e a Novena de Nossa Senhora das Graças, sua devoção preferida.

Só levou consigo ao Hospital, como seus mais valiosos tesouros, a Medalha Milagrosa e o pequeno Menino Jesus. Em 14 de dezembro, domingo, recebeu de mãos de seu Pároco a Unção dos Enfermos. No dia seguinte, de manhã, cada vez com maiores dificuldades para respirar, entrou em agonia. Sempre lúcido, continuava segurando com suas mãozinhas a Medalha Milagrosa e o Menino Jesus. Percebendo que as forças o abandonavam, conseguiu sussurrar com dificuldade: "Mãe, me ajude a segurar o Menino Jesus..." Pouco depois, dava seu último suspiro.

O Menino Jesus, sem dúvida, retribuiu o afeto dessa alma inocente, levando-o consigo para passar o primeiro Natal no Céu.

Para Deus não existem heróis anônimos; mais ainda, Ele muitas vezes nos dá a possibilidade de conhecer essas vidas, para nossa edificação, e para nos ajudar, com seus exemplos, a enfrentar as enormes dificuldades do dia-a-dia. O pequeno Lucas foi um herói, apesar de ter só 9 anos: por sua fé, e pela inteira aceitação do misterioso e luminoso caminho da dor que a Providencia lhe preparou, trilhando os passos do Divino Mestre. O pequeno Lucas é, neste sentido, um grande exemplo para o Brasil.

Gonçalo Guimarães, autor deste artigo, é jornalista.

LINKS:

Para enviar uma mensagem aos pais e irmão do pequeno Lucas, clique em:

FamiliaDoLucas:MinhaMensagem

Para enviar ao autor do artigo sua valiosa opinião, clique aqui: ArtigoSobreLucas:MinhaOpiniao

Para receber gratuitamente, por e-mail, duas fotos de Lucas (uma com 6 anos, e outra, com 9, poucos dias antes de falecer), clique aqui:

DesejoReceberFotosDeLucas

Para ser retirado de nosso Address Book, clique em:

RetirarDoAddresBook

Nota: este artigo pode ser reproduzido parcial ou totalmente, de preferência, citando a fonte: Atualidade Brasileira.

From vslpress@bol.com.br Fri Jan 9 20:10:17 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03023 for ; Fri, 9 Jan 2004 20:10:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af7do-000276-00 for ccamp-archive@ietf.org; Fri, 09 Jan 2004 20:10:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af7cD-0001x0-00 for ccamp-archive@ietf.org; Fri, 09 Jan 2004 20:08:39 -0500 Received: from [209.58.115.177] (helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1Af7a4-0001kJ-00; Fri, 09 Jan 2004 20:06:25 -0500 From: "Temas Patrulhados" To: bofchairs@ietf.org Subject: Lindenberg e o Clero "sem-microfone" ref.: nyx User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Fri, 09 Jan 2004 20:06:25 -0500 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.4 required=5.0 tests=HTML_40_50,HTML_FONT_BIG, HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2,MAILTO_TO_REMOVE, MAILTO_TO_SPAM_ADDR,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MSGID_FROM_MTA_SHORT,REMOVE_REMOVAL_2WORD,SUBJ_HAS_SPACES autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.1 LINES_OF_YELLING_2 BODY: 2 WHOLE LINES OF YELLING DETECTED * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay

Ref.: ycc FreeAutomaticTranslator / TraductorGratuito / Retirar / SubscreverGratuitamente

Série Temas "Patrulhados" (2)

Acabemos com mais uma exclusão: o Brasil precisa ouvir a voz do Clero sem-microfone

"Por que os grupelhos contestatários, de intenso ativismo no interior da Igreja, e cuja especialidade é reivindicar todo tipo de medidas antiexclusão, não incluem na sua agenda o fim do boicote contra os sacerdotes sem-microfone?"

Adolpho Lindenberg

O destaque que, há muitos anos, a mídia vem dando aos pronunciamentos de bispos e sacerdotes (em geral ligados à CNBB), incitando as invasões de terras promovidas pelo MST, criticando indiscriminadamente a Área de Livre Comércio das Américas (ALCA), as privatizações, as multinacionais (as norte-americanas, em especial), e o plantio dos transgênicos, apresenta um inconveniente sério: tais pronunciamentos podem criar a impressão de que a maioria do Episcopado e dos setores mais responsáveis do Clero brasileiro pensa como esses prelados.

Movimentos contestatários

É contristador perceber que na vasta rede de movimentos contestatários que está sendo articulada por todo o país, a ala progressista religiosa - fruto das Comunidades de Base e da Comissão Pastoral da Terra (CPT) - se sobressai como o núcleo mais ativo e radical em suas convicções. Para esses movimentos de contestação é de fundamental importância dar a impressão de que expressam a opinião majoritária, ou pelo menos muito expressiva, do Episcopado e no Clero.

Não é verdade, necessariamente.

Uma minoria do Clero fala, a maioria está calada

A realidade profunda é bem outra. A maioria do Episcopado e do Clero, na realidade, não tem voz nem vez na grande mídia. Suas pastorais, sermões e opiniões não chegam ao grande público. Quase ninguém os conhece, só alguns paroquianos e amigos próximos, com quem compartilham confidências. Eles são os prelados e sacerdotes sem-microfone; pertencem à imensa maioria dos excluídos dos grandes meios de difusão. E muitos deles inteligentes, cultos, de expressão fácil, com reflexões que ajudariam muito à autêntica formação da opinião nacional. Até por exigência de equilíbrio na ponderação das opiniões e de equidade em relação a este setor social, eles também precisariam ser ouvidos.

Padres sem-microfone são discriminados

O grande número dos padres sem-microfone, muitas vezes, talvez na maioria esmagadora dos casos, teria reservas sérias com as invasões e depredações das propriedades agrícolas. Mas são discriminados, não são ouvidos pelo público. De nada adiantam suas advertências. Não repercutem. Estão excluídos. Para eles, não funciona a encenação publicitária aparatosa, suas opiniões são ignoradas pela grande imprensa, o que acontece por exemplo no caso de "O Grito dos Excluídos". É que, para azar deles, nem estão entre os promotores da revolução social, nem pertencem aos pequenos grupos dos privilegiados pela mídia.

Excluir a exclusão

É preciso que se inclua entre os formadores de opinião, com acesso à mídia, também os prelados e sacerdotes que hoje estão sem microfone. Por que deixá-los de fora? Por que os grupelhos contestatários, de intenso ativismo no interior da Igreja, e cuja especialidade é reivindicar todo tipo de medidas antiexclusão, não incluem na agenda já tão abrangente do "Grito dos Excluídos" também o fim do boicote contra os sacerdotes sem-microfone? Afinal de contas, não se proclamam os seus participantes em batalha contra as exclusões, pelo fim das discriminações? Ou é que umas exclusões podem existir, e são bem-vindas, e outras não? Se for assim afastam-se do que deseja o povo, pois milhões de brasileiros querem saber o que pensa o Clero sem-microfone.

Adolpho Lindenberg é autor do livro "Os católicos e a economia de mercado".

LINKS:

Lindenberg:Concordo (envie seu voto virtual, e, melhor ainda, acrescente seu comentário, caso desejar)

Lindenberg:Discordo (idem)

Lindenberg:MinhaOpinião (para enviar sua valiosa opinião, assim como sugerir a Lindenberg temas relacionados com a temática apresentada, a serem abordados em seus próximos artigos)

LINKS PARA RECEBER ARTIGOS GRATUITOS:

PaginasGratuitas (para receber gratuitamente, por e-mail, Índice e Introdução à edição brasileira do livro de Lindenberg)

GratuitamenteArtigosAnteriores / GratuitamenteProximosArtigos / GratuitamenteTodosOsArtigos

LINKS PARA ADQUIRIR O LIVRO

Lindenberg:DesejoAdquirirLivroEmPortugal (receberá por e-mail o link para adquirir o livro impresso, diretamente da Editora em Portugal; preço: E 19,45)

Lindenberg:DesejoAdquirirLivroNoBrasil (receberá por e-mail o link para adquirir o livro impresso, diretamente da Editora no Brasil, com cartão de crédito ou boleto bancário; preço: R$ 30,00 mais Correio)

LINK DE REMOÇÃO

ConstruNews:Remover

LINK PARA TOMAR CONTATO COM LINDENBERG

Lindenberg:TomarContato (também pode ligar diretamente, se desejar, ao 11- 92527873, em São Paulo)

A difusão e o conteúdo desta mensagem são de exclusiva responsabilidade da ConstruNews

 From Majordomo-Owner@psg.com Thu Jan 15 13:00:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17381 for ; Thu, 15 Jan 2004 13:00:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhBnI-0006bi-00 for ccamp-archive@ietf.org; Thu, 15 Jan 2004 13:00:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhBmN-0006aW-00 for ccamp-archive@ietf.org; Thu, 15 Jan 2004 12:59:40 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AhBlp-0006Z5-00 for ccamp-archive@ietf.org; Thu, 15 Jan 2004 12:59:05 -0500 Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AhBlo-0009MV-Qd for ccamp-archive@ietf.org; Thu, 15 Jan 2004 17:59:04 +0000 To: ccamp-archive@ietf.org From: majordomo@psg.com Subject: Majordomo results Reply-To: majordomo@psg.com Message-Id: Date: Thu, 15 Jan 2004 17:59:04 +0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=HTML_MESSAGE,LINES_OF_YELLING, LINES_OF_YELLING_2,NO_REAL_NAME autolearn=no version=2.60 -- >>>> subscribe **** subscribe: unknown list ''. >>>> **** Help for majordomo@psg.com: This help message is being sent to you from the Majordomo mailing list management system at majordomo@psg.com. This is version 1.94.5 of Majordomo. If you're familiar with mail servers, an advanced user's summary of Majordomo's commands appears at the end of this message. Majordomo is an automated system which allows users to subscribe and unsubscribe to mailing lists, and to retrieve files from list archives. You can interact with the Majordomo software by sending it commands in the body of mail messages addressed to "majordomo@psg.com". Please do not put your commands on the subject line; Majordomo does not process commands in the subject line. You may put multiple Majordomo commands in the same mail message. Put each command on a line by itself. If you use a "signature block" at the end of your mail, Majordomo may mistakenly believe each line of your message is a command; you will then receive spurious error messages. To keep this from happening, either put a line starting with a hyphen ("-") before your signature, or put a line with just the word end on it in the same place. This will stop the Majordomo software from processing your signature as bad commands. Here are some of the things you can do using Majordomo: I. FINDING OUT WHICH LISTS ARE ON THIS SYSTEM To get a list of publicly-available mailing lists on this system, put the following line in the body of your mail message to majordomo@psg.com: lists Each line will contain the name of a mailing list and a brief description of the list. To get more information about a particular list, use the "info" command, supplying the name of the list. For example, if the name of the list about which you wish information is "demo-list", you would put the line info demo-list in the body of the mail message. II. SUBSCRIBING TO A LIST Once you've determined that you wish to subscribe to one or more lists on this system, you can send commands to Majordomo to have it add you to the list, so you can begin receiving mailings. To receive list mail at the address from which you're sending your mail, simply say "subscribe" followed by the list's name: subscribe demo-list If for some reason you wish to have the mailings go to a different address (a friend's address, a specific other system on which you have an account, or an address which is more correct than the one that automatically appears in the "From:" header on the mail you send), you would add that address to the command. For instance, if you're sending a request from your work account, but wish to receive "demo-list" mail at your personal account (for which we will use "jqpublic@my-isp.com" as an example), you'd put the line subscribe demo-list jqpublic@my-isp.com in the mail message body. Based on configuration decisions made by the list owners, you may be added to the mailing list automatically. You may also receive notification that an authorization key is required for subscription. Another message will be sent to the address to be subscribed (which may or may not be the same as yours) containing the key, and directing the user to send a command found in that message back to majordomo@psg.com. (This can be a bit of extra hassle, but it helps keep you from being swamped in extra email by someone who forged requests from your address.) You may also get a message that your subscription is being forwarded to the list owner for approval; some lists have waiting lists, or policies about who may subscribe. If your request is forwarded for approval, the list owner should contact you soon after your request. Upon subscribing, you should receive an introductory message, containing list policies and features. Save this message for future reference; it will also contain exact directions for unsubscribing. If you lose the intro mail and would like another copy of the policies, send this message to majordomo@psg.com: intro demo-list (substituting, of course, the real name of your list for "demo-list"). III. UNSUBSCRIBING FROM MAILING LISTS Your original intro message contains the exact command which should be used to remove your address from the list. However, in most cases, you may simply send the command "unsubscribe" followed by the list name: unsubscribe demo-list (This command may fail if your provider has changed the way your address is shown in your mail.) To remove an address other than the one from which you're sending the request, give that address in the command: unsubscribe demo-list jqpublic@my-isp.com In either of these cases, you can tell majordomo@psg.com to remove the address in question from all lists on this server by using "*" in place of the list name: unsubscribe * unsubscribe * jqpublic@my-isp.com IV. FINDING THE LISTS TO WHICH AN ADDRESS IS SUBSCRIBED To find the lists to which your address is subscribed, send this command in the body of a mail message to majordomo@psg.com: which You can look for other addresses, or parts of an address, by specifying the text for which Majordomo should search. For instance, to find which users at my-isp.com are subscribed to which lists, you might send the command which my-isp.com Note that many list owners completely or fully disable the "which" command, considering it a privacy violation. V. FINDING OUT WHO'S SUBSCRIBED TO A LIST To get a list of the addresses on a particular list, you may use the "who" command, followed by the name of the list: who demo-list Note that many list owners allow only a list's subscribers to use the "who" command, or disable it completely, believing it to be a privacy violation. VI. RETRIEVING FILES FROM A LIST'S ARCHIVES Many list owners keep archives of files associated with a list. These may include: - back issues of the list - help files, user profiles, and other documents associated with the list - daily, monthly, or yearly archives for the list To find out if a list has any files associated with it, use the "index" command: index demo-list If you see files in which you're interested, you may retrieve them by using the "get" command and specifying the list name and archive filename. For instance, to retrieve the files called "profile.form" (presumably a form to fill out with your profile) and "demo-list.9611" (presumably the messages posted to the list in November 1996), you would put the lines get demo-list profile.form get demo-list demo-list.9611 in your mail to majordomo@psg.com. VII. GETTING MORE HELP To contact a human site manager, send mail to Majordomo-Owner@psg.com. To contact the owner of a specific list, send mail to that list's approval address, which is formed by adding "-approval" to the user-name portion of the list's address. For instance, to contact the list owner for demo-list@psg.com, you would send mail to demo-list-approval@psg.com. To get another copy of this help message, send mail to majordomo@psg.com with a line saying help in the message body. VIII. COMMAND SUMMARY FOR ADVANCED USERS In the description below items contained in []'s are optional. When providing the item, do not include the []'s around it. Items in angle brackets, such as
, are meta-symbols that should be replaced by appropriate text without the angle brackets. It understands the following commands: subscribe [
] Subscribe yourself (or
if specified) to the named . unsubscribe [
] Unsubscribe yourself (or
if specified) from the named . "unsubscribe *" will remove you (or
) from all lists. This _may not_ work if you have subscribed using multiple addresses. get Get a file related to . index Return an index of files you can "get" for . which [
] Find out which lists you (or
if specified) are on. who Find out who is on the named . info Retrieve the general introductory information for the named . intro Retrieve the introductory message sent to new users. Non-subscribers may not be able to retrieve this. lists Show the lists served by this Majordomo server. help Retrieve this message. end Stop processing commands (useful if your mailer adds a signature). Commands should be sent in the body of an email message to "majordomo@psg.com". Multiple commands can be processed provided each occurs on a separate line. Commands in the "Subject:" line are NOT processed. If you have any questions or problems, please contact "Majordomo-Owner@psg.com". From Majordomo-Owner@psg.com Thu Jan 15 17:34:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05846 for ; Thu, 15 Jan 2004 17:34:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhG4Y-0002De-00 for ccamp-archive@ietf.org; Thu, 15 Jan 2004 17:34:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhG3e-0002At-00 for ccamp-archive@ietf.org; Thu, 15 Jan 2004 17:33:46 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AhG2j-00027k-00 for ccamp-archive@ietf.org; Thu, 15 Jan 2004 17:32:49 -0500 Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AhG2j-000E2j-U0 for ccamp-archive@ietf.org; Thu, 15 Jan 2004 22:32:49 +0000 To: ccamp-archive@ietf.org From: majordomo@psg.com Subject: Confirmation for subscribe ccamp Reply-To: majordomo@psg.com Message-Id: Date: Thu, 15 Jan 2004 22:32:49 +0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 -- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "ccamp@psg.com". If you really want this action to be taken, please send the following commands (exactly as shown) back to "majordomo@psg.com": auth affd6915b56e53847f4b66dffcb19b52 subscribe ccamp ccamp-archive@ietf.org If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth affd6915b56e53847f4b66dffcb19b52 subscribe ccamp \ ccamp-archive@ietf.org If you have any questions about the policy of the list owner, please contact "ccamp-approval@psg.com". Thanks! majordomo@psg.com From Majordomo-Owner@psg.com Thu Jan 15 18:20:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05857 for ; Thu, 15 Jan 2004 17:34:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhG4Z-0002Dj-00 for ccamp-archive@ietf.org; Thu, 15 Jan 2004 17:34:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhG3e-0002B1-00 for ccamp-archive@ietf.org; Thu, 15 Jan 2004 17:33:47 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AhG2j-00027l-00 for ccamp-archive@ietf.org; Thu, 15 Jan 2004 17:32:49 -0500 Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AhG2j-000E2i-SD for ccamp-archive@ietf.org; Thu, 15 Jan 2004 22:32:49 +0000 To: ccamp-archive@ietf.org From: majordomo@psg.com Subject: Majordomo results Reply-To: majordomo@psg.com Message-Id: Date: Thu, 15 Jan 2004 22:32:49 +0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 -- >>>> subscribe ccamp **** Your request to majordomo@psg.com: **** **** subscribe ccamp ccamp-archive@ietf.org **** **** must be authenticated. To accomplish this, another request must be **** sent in with an authorization key, which has been sent to: **** ccamp-archive@ietf.org **** **** If the message is not received, there is generally a problem with **** the address. Before reporting this as a problem, please note the **** following: **** **** You only need to give an address to the subscribe command if you want **** to receive list mail at a different address from where you sent the **** command. Otherwise you can simply omit it. **** **** If you do give an address to the subscribe command, it must be a legal **** address. It should not consist solely of your name. The address must **** point to a machine that is reachable from the list server. **** **** If you have any questions about the policy of the list owner, please **** contact "ccamp-approval@psg.com". **** **** Thanks! **** **** majordomo@psg.com >>>> From Majordomo-Owner@psg.com Thu Jan 15 18:58:47 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09259 for ; Thu, 15 Jan 2004 18:58:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhHNw-00068x-00 for ccamp-archive@ietf.org; Thu, 15 Jan 2004 18:58:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhHMz-00066u-00 for ccamp-archive@ietf.org; Thu, 15 Jan 2004 18:57:50 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AhHMo-00065L-00 for ccamp-archive@ietf.org; Thu, 15 Jan 2004 18:57:39 -0500 Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AhHMo-000PHL-9J for ccamp-archive@ietf.org; Thu, 15 Jan 2004 23:57:38 +0000 To: ccamp-archive@ietf.org From: majordomo@psg.com Subject: Majordomo results Reply-To: majordomo@psg.com Message-Id: Date: Thu, 15 Jan 2004 23:57:38 +0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 -- >>>> auth affd6915b56e53847f4b66dffcb19b52 subscribe ccamp ccamp-archive@ietf.org Succeeded. >>>> From owner-ccamp@psg.com Thu Jan 15 19:45:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09254 for ; Thu, 15 Jan 2004 18:58:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhHNv-00068r-00 for ccamp-archive@ietf.org; Thu, 15 Jan 2004 18:58:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhHMz-00066m-00 for ccamp-archive@ietf.org; Thu, 15 Jan 2004 18:57:49 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AhHMo-00065K-00 for ccamp-archive@ietf.org; Thu, 15 Jan 2004 18:57:38 -0500 Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AhHMp-000PHT-61 for ccamp-archive@ietf.org; Thu, 15 Jan 2004 23:57:39 +0000 To: ccamp-archive@ietf.org From: majordomo@psg.com Subject: Welcome to ccamp Reply-To: majordomo@psg.com Message-Id: Date: Thu, 15 Jan 2004 23:57:39 +0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 -- Welcome to the ccamp mailing list! Please save this message for future reference. Thank you. If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe ccamp or from another account, besides ccamp-archive@ietf.org: unsubscribe ccamp ccamp-archive@ietf.org If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. Here's the general information for the list you've subscribed to, in case you don't already have it: NOTE WELL: All statements of a technical or standards-related nature addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants certain licenses and rights in such statements to the IETF and its participants. This includes verbal statements in meetings, as well as written and electronic communications made at any time or place, to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG or any member thereof, - the IAB or any member thereof, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - or as an Internet-Drafts submission The above excludes personal communications not intended to be shared with any IETF working group, the IESG, the IAB, or any subset thereof. From owner-ccamp@ops.ietf.org Thu Jan 15 20:55:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13162 for ; Thu, 15 Jan 2004 20:55:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhJDD-0003Tv-00 for ccamp-archive@ietf.org; Thu, 15 Jan 2004 20:55:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhJCH-0003SF-00 for ccamp-archive@ietf.org; Thu, 15 Jan 2004 20:54:54 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AhJBf-0003QX-00 for ccamp-archive@ietf.org; Thu, 15 Jan 2004 20:54:15 -0500 Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AhIp8-0008Re-J7 for ccamp-data@psg.com; Fri, 16 Jan 2004 01:30:58 +0000 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AhIow-0008Oj-J0; Fri, 16 Jan 2004 01:30:46 +0000 Date: Thu, 15 Jan 2004 17:30:01 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <153115090911.20040115173001@psg.com> To: "Thomas D. Nadeau" CC: "'Vishal Sharma'" , ietf-web@ietf.org, "'CCAMP'" , "'MPLS'" Subject: Re: Outdated WG charters?! In-Reply-To: <007601c3db7f$4d64d850$6701a8c0@amer.cisco.com> References: <007601c3db7f$4d64d850$6701a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,PLING_QUERY, RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks- There was a problem with the IETF WG database, which the secretariat should have fixed. The WG web-pages are regenerated nightly, so if everything is fixed, we should not see any problems tomorrow. -- Alex http://www.psg.com/~zinin/ Thursday, January 15, 2004, 7:50:22 AM, Thomas D. Nadeau wrote: > BTW, there are other errors I noticed with > the PWE3 and MPLS WG pages pointing at other > out-dated drafts. Looks like the web server > was restored from some (really) old backups. > --Tom >> -----Original Message----- >> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf >> Of Vishal Sharma >> Sent: Wednesday, January 14, 2004 10:54 PM >> To: ietf-web@ietf.org >> Cc: CCAMP; MPLS >> Subject: Outdated WG charters?! >> Importance: High >> >> >> Hello, >> >> It appears that the Charter updates posted by the IETF Secretariat >> at >> http://www.ietf.org/html.charters/wg-dir.html just this evening >> (at least) for CCAMP and MPLS WGs are completely outdated (over >> a year old). >> >> I believe an error was made in posting these, and it would be >> great if this could be corrected at the earliest (otherwise >> it's very difficult to access the latest WG documents). >> >> Thanks much! >> >> -Vishal >> >> PS: If I am the only one experiencing this problem, please let >> me know. I've flushed all caches and buffers, so I don't think >> the problem is at my end. >> From owner-ccamp@ops.ietf.org Fri Jan 16 07:34:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12106 for ; Fri, 16 Jan 2004 07:34:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhTBB-0007bm-00 for ccamp-archive@ietf.org; Fri, 16 Jan 2004 07:34:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhTAH-0007XX-00 for ccamp-archive@ietf.org; Fri, 16 Jan 2004 07:33:30 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AhT9r-0007Sj-00 for ccamp-archive@ietf.org; Fri, 16 Jan 2004 07:33:03 -0500 Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AhSwj-000JkK-6O for ccamp-data@psg.com; Fri, 16 Jan 2004 12:19:29 +0000 Received: from [32.97.110.130] (helo=e32.co.us.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AhSwW-000JjP-Cn for ccamp@ops.ietf.org; Fri, 16 Jan 2004 12:19:16 +0000 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0GCIQrE370926; Fri, 16 Jan 2004 07:18:26 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-192-32.mts.ibm.com [9.65.192.32]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0GCIOAa123076; Fri, 16 Jan 2004 05:18:24 -0700 Received: from cichlid.raleigh.ibm.com (narten@localhost) by cichlid.raleigh.ibm.com (8.11.6/8.9.3) with ESMTP id i0GCDi703989; Fri, 16 Jan 2004 07:13:44 -0500 Message-Id: <200401161213.i0GCDi703989@cichlid.raleigh.ibm.com> To: "Naidu, Venkata" cc: "'Dimitri.Papadimitriou@alcatel.be'" , "'Wijnen, Bert (Bert)'" , IETF CCAMP List , iana@iana.org Subject: Re: IANA assignments In-Reply-To: Message from Venkata.Naidu@Marconi.com of "Thu, 08 Jan 2004 11:00:47 EST." <39469E08BD83D411A3D900204840EC55FB716D@vie-msgusr-01.dc.fore.com> Date: Fri, 16 Jan 2004 07:13:44 -0500 From: Thomas Narten Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > All I am saying is, IANA can have a guideline for long lived > drafts, such as: > > If there is a shipped implementation with an old deprecated > value, that value MUST be reserved to prevent future misuse. > It MUST be noted in the subsequent drafts and final RFC. Well, a more proper way to express the above (process wise) would be to have an IANA considerations Section (for the name space at issue) of something like: values in the range 0-128 are assigned via Standards Action or Expert Review. The purpose of Expert Review assignments is for the assignment of code points in cases where the document is expected to become published as a standards track RFC (e.g., it is a Working Group document), but for which experimentation is desired before the RFC is published. Tune further as appropriate. Then, when a WG needs an assignment, it asks IANA to make the assignment, IANA checks with the expert, and assuming the request is proper, the assignment gets made. The point is that there are ways for the WG to retain control over assignments that IANA is managing. That is what IANA Considerations sections are for. Thomas From owner-ccamp@ops.ietf.org Fri Jan 16 07:34:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12109 for ; Fri, 16 Jan 2004 07:34:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhTBC-0007br-00 for ccamp-archive@ietf.org; Fri, 16 Jan 2004 07:34:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhTAI-0007Xg-00 for ccamp-archive@ietf.org; Fri, 16 Jan 2004 07:33:31 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AhT9s-0007Sk-00 for ccamp-archive@ietf.org; Fri, 16 Jan 2004 07:33:04 -0500 Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AhSux-000JdK-9p for ccamp-data@psg.com; Fri, 16 Jan 2004 12:17:39 +0000 Received: from [32.97.110.132] (helo=e34.co.us.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AhSuk-000Jcc-FO for ccamp@ops.ietf.org; Fri, 16 Jan 2004 12:17:26 +0000 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0GCGw6t317796; Fri, 16 Jan 2004 07:16:59 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-192-32.mts.ibm.com [9.65.192.32]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0GCGvAa141510; Fri, 16 Jan 2004 05:16:57 -0700 Received: from cichlid.raleigh.ibm.com (narten@localhost) by cichlid.raleigh.ibm.com (8.11.6/8.9.3) with ESMTP id i0GCCIf03977; Fri, 16 Jan 2004 07:12:18 -0500 Message-Id: <200401161212.i0GCCIf03977@cichlid.raleigh.ibm.com> To: "Naidu, Venkata" cc: "'Wijnen, Bert (Bert)'" , IETF CCAMP List , iana@iana.org Subject: Re: IANA assignments In-Reply-To: Message from Venkata.Naidu@Marconi.com of "Thu, 08 Jan 2004 10:27:01 EST." <39469E08BD83D411A3D900204840EC55FB716C@vie-msgusr-01.dc.fore.com> Date: Fri, 16 Jan 2004 07:12:18 -0500 From: Thomas Narten Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > Is it possible for IANA to initiate a discussion in the mailing-list > before publishing a value, at least, for long lived drafts ? Not really practical. Please see RFC 2434, where it talks about mailing lists. Bottom line: IANA doesn't have the resources or subject-matter expertise to read mailing list discussions and make sense out of the diverse opinions that tend to get expressed. But one can certainly write an IANA considerations section (again see RFC 2434) that specifies that a Designated Expert should make the evaluation, and one of the steps of that process could be to check with relevant WGs first, and so forth. WGs have a lot of flexibility in defining how they want their name spaces managed. But IANA certainly can't guess what the right thing to do is. That's why it's so important the authors/WGs pay attention to IANA considerations and specify them carefully. Thomas From owner-ccamp@ops.ietf.org Fri Jan 16 07:35:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12148 for ; Fri, 16 Jan 2004 07:35:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhTBt-0007eI-00 for ccamp-archive@ietf.org; Fri, 16 Jan 2004 07:35:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhTAx-0007Zt-00 for ccamp-archive@ietf.org; Fri, 16 Jan 2004 07:34:12 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AhTA2-0007Ul-00 for ccamp-archive@ietf.org; Fri, 16 Jan 2004 07:33:14 -0500 Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AhSx3-000Jnd-VI for ccamp-data@psg.com; Fri, 16 Jan 2004 12:19:49 +0000 Received: from [32.97.110.130] (helo=e32.co.us.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AhSwq-000Jkl-Tt for ccamp@ops.ietf.org; Fri, 16 Jan 2004 12:19:36 +0000 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0GCJUrE063288; Fri, 16 Jan 2004 07:19:30 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-192-32.mts.ibm.com [9.65.192.32]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0GCJTAa122254; Fri, 16 Jan 2004 05:19:29 -0700 Received: from cichlid.raleigh.ibm.com (narten@localhost) by cichlid.raleigh.ibm.com (8.11.6/8.9.3) with ESMTP id i0GCEol04004; Fri, 16 Jan 2004 07:14:50 -0500 Message-Id: <200401161214.i0GCEol04004@cichlid.raleigh.ibm.com> To: Kireeti Kompella cc: ccamp@ops.ietf.org, iana@iana.org Subject: Re: IANA assignments In-Reply-To: Message from kireeti@juniper.net of "Wed, 14 Jan 2004 19:13:22 PST." <20040114184237.F28722@kummer.juniper.net> Date: Fri, 16 Jan 2004 07:14:50 -0500 From: Thomas Narten Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > On that basis, I would strongly recommend IANA to assign 4 for both > the C-Types of SONET/SDH TSPEC and FLOWSPEC. Too late. IANA has already assigned 3 for that value. Given that IANA is the authority and people may have already taken IANA's published value (assuming it was the legit value to use) and added it to their documents, simply changing the assignment is no longer a simple matter anymore. It might be possible to change this assignment if people can make a clear case that: - leaving the assignment of 3 is clearly worse than changing to 4, and - changing to 4 doesn't cause hardship and confusion for those that have picked up the IANA-assigned value of 3. Thomas From owner-ccamp@ops.ietf.org Fri Jan 16 07:36:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12174 for ; Fri, 16 Jan 2004 07:36:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhTCv-0007hh-00 for ccamp-archive@ietf.org; Fri, 16 Jan 2004 07:36:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhTBx-0007et-00 for ccamp-archive@ietf.org; Fri, 16 Jan 2004 07:35:13 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AhTBS-0007cf-00 for ccamp-archive@ietf.org; Fri, 16 Jan 2004 07:34:42 -0500 Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AhT07-000KAk-Cn for ccamp-data@psg.com; Fri, 16 Jan 2004 12:22:59 +0000 Received: from [32.97.110.131] (helo=e33.co.us.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AhSzu-000K9n-Ku for ccamp@ops.ietf.org; Fri, 16 Jan 2004 12:22:46 +0000 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0GCLMJh358552; Fri, 16 Jan 2004 07:21:22 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-192-32.mts.ibm.com [9.65.192.32]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0GCLKAa138600; Fri, 16 Jan 2004 05:21:21 -0700 Received: from cichlid.raleigh.ibm.com (narten@localhost) by cichlid.raleigh.ibm.com (8.11.6/8.9.3) with ESMTP id i0GCGgc04020; Fri, 16 Jan 2004 07:16:42 -0500 Message-Id: <200401161216.i0GCGgc04020@cichlid.raleigh.ibm.com> To: Kireeti Kompella cc: "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, iana@iana.org Subject: Re: IANA assignments In-Reply-To: Message from kireeti@juniper.net of "Thu, 15 Jan 2004 00:14:14 PST." <20040114234904.A29284@kummer.juniper.net> Date: Fri, 16 Jan 2004 07:16:42 -0500 From: Thomas Narten Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > The priority here is simple: the *IETF* has asked IANA for assignment > of a code point; the most reasonable value of that code point *based > on implementations of the IETF draft/RFC* is 4. This may well be a correct statement, prior to IANA having made the assignment. Now that they have published 3 as the "correct" value, things are no longer so simple. > The OIF is *not* a standards organization; for the IETF to change > what is the right decision based on premature actions of the OIF is > a sign of weakness. In any case, 'signs of weakness' should NOT be > our guiding principle -- we should do what is right and reasonable. This is not about weakness. A fundamental property of assignments is that they are stable and do not change. Once IANA makes an assignment, it needs to have very very very good reasons for backing out and making a change. > BTW, to put this in perspective, OIF UNI1.0 uses a code point value > of 4. If the value of 3 was 'approved' by the OIF for UNI1.0r2, it > seems to me that the OIF really jumped the gun: the RFC has not been > published and discussion of code point assignments is not complete. Actually, the IANA assignment step and RFC publication are different. The IANA step occurs when IANA announces its assignment (whether via email, by posting a message, by updating their web pages, etc.). An RFC can't be published until after IANA makes any relevant assignments. So even though the RFC may not be out, the code point assignment has been completed, officially. > Perhaps the OIF can approve (as soon as we complete the discussion and > reach the right conclusion) UNI1.0r3 with the correct value. It would be extremely useful for someone to ask OIF about the feasibility of this. And to comment on what other organization may have picked up the IANA-published value at this point. > I stand by my recommendation that IANA assign a value of 4 for the > SDH/SONET C-Types for FLOWSPEC and TSPEC. I think we all agree that would have been the logical assignment. Problem is, we're past that point now and reversing an assignment is not so simple. Thomas From owner-ccamp@ops.ietf.org Fri Jan 16 10:39:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18714 for ; Fri, 16 Jan 2004 10:39:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhW4A-0003WS-00 for ccamp-archive@ietf.org; Fri, 16 Jan 2004 10:39:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhW3P-0003UM-00 for ccamp-archive@ietf.org; Fri, 16 Jan 2004 10:38:36 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AhW2k-0003RA-00 for ccamp-archive@ietf.org; Fri, 16 Jan 2004 10:37:54 -0500 Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AhVp3-000DMX-EX for ccamp-data@psg.com; Fri, 16 Jan 2004 15:23:45 +0000 Received: from [204.154.129.57] (helo=tellabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AhVoJ-000DGB-9j for ccamp@ops.ietf.org; Fri, 16 Jan 2004 15:22:59 +0000 Received: from ([172.23.207.12]) by mx4.tellabs.com with ESMTP ; Fri, 16 Jan 2004 09:07:18 -0600 (CST) Received: from tellabs.com (dhcp-172-23-111-6.hq.tellabs.com [172.23.111.6]) by mailw02.hq.tellabs.com with ESMTP (8.11.1/8.7.1) id i0GF7Jm23666; Fri, 16 Jan 2004 09:07:19 -0600 (CST) Message-ID: <4007FDB5.2020802@tellabs.com> Date: Fri, 16 Jan 2004 09:05:25 -0600 From: Ben Mack-Crane User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben.Mack-Crane@tellabs.com CC: Adrian Farrel , Andy.Malis@tellabs.com, ccamp@ops.ietf.org Subject: Re: IANA assignments References: <4006AF1C.1040304@tellabs.com> Content-Type: multipart/alternative; boundary="------------080207010105030209060601" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 --------------080207010105030209060601 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Transfer-Encoding: 7bit Adrian and all, After checking with the OIF, I understand that UNI1.0r2 has passed Straw Ballot but not Principal Ballot. The value in question could be adjusted as an editorial change before going to Principal Ballot. The OIF is meeting next week and UNI1.0r2 is likely to go to Principal Ballot soon. Regards, Ben Ben.Mack-Crane@tellabs.com wrote: > Adrian, > > Initially OIF used the value (4) in UNI1.0. I do not know how this value > was chosen, or who chose it, but this is probably how it came into > common use, since UNI > interop was done quite a while ago. > > While making minor corrections and updates to conform with IETF RFCs > (since UNI1.0 > was based on drafts) we consulted the IANA assignments and found (3), > so that value > was used as the corrected value in UNI1.0r2. > > So, OIF has followed the official IANA assignment. > > Regards, > Ben > > Adrian Farrel wrote: > >>Erm, >>Which order this happen Ben? >> >>IANA or OIF first? >> >>Thanks, >>Adrian >>----- Original Message ----- >>From: "Ben Mack-Crane" >>To: >>Cc: >>Sent: Wednesday, January 14, 2004 4:02 PM >>Subject: Re: IANA assignments >> >> >> >> >>>To add to Andy's factual response on Tellabs' implementations, >>>I would like to support Bert's messages on following the process >>>and also state that we are willing to update our implementation >>>to support the "right" codepoint. >>> >>>Other standards organizations depend on the stability of the >>>IANA process. For example, the recently approved OIF UNI1.0r2 IA >>>specifies the IANA assigned C-Type (3) for SONET/SDH TSPEC/FLOWSPEC. >>>This will be a problem if the IANA assignment is changed. >>> >>>Regards, >>>Ben Mack-Crane >>> >>>Andy.Malis@tellabs.com wrote: >>> >>> >>> >>>>Ditto for Tellabs (the same as Kireeti's answer). >>>> >>>>Andy >>>> >>>>------------ >>>> >>>>At 1/9/2004 11:48 AM -0800, Kireeti Kompella wrote: >>>> >>>> >>>> >>>>>On Fri, 9 Jan 2004, Kireeti Kompella wrote: >>>>> >>>>>For the record, here is the answer from Juniper's implementation: >>>>> >>>>> >>>>> >>>>>>a) do you use the FLOWSPEC C-Type 3 for CoS? >>>>>> >>>>>> >>>>>We parse this, but don't really use it. >>>>> >>>>> >>>>> >>>>>>b) have you implemented the SONET/SDH FLOWSPEC? If so, what value did >>>>>> you use for the C-Type? >>>>>> >>>>>> >>>>>Yes. Value 4. >>>>> >>>>> >>>>> >>>>>>c) do you use the TSPEC C-Type 3 for CoS? >>>>>> >>>>>> >>>>>We parse this, but don't really use it. >>>>> >>>>> >>>>> >>>>>>d) have you implemented the SONET/SDH TSPEC? If so, what value did >>>>>> you use for the C-Type? >>>>>> >>>>>> >>>>>Yes. Value 4. >>>>> >>>>>Kireeti. >>>>>------- >>>>> >>>>> >>>> >>>> >>>----------------------------------------- >>>============================================================ >>>The information contained in this message may be privileged >>>and confidential and protected from disclosure. If the >>>reader of this message is not the intended recipient, or an >>>employee or agent responsible for delivering this message to >>>the intended recipient, you are hereby notified that any >>>reproduction, dissemination or distribution of this >>>communication is strictly prohibited. If you have received >>>this communication in error, please notify us immediately by >>>replying to the message and deleting it from your computer. >>> >>>Thank you. >>>Tellabs >>>============================================================ >>> >>> >>> >>> >>> >>> >> >> >> > > ------------------------------------------------------------------------ > > ============================================================ > The information contained in this message may be privileged > and confidential and protected from disclosure. If the > reader of this message is not the intended recipient, or an > employee or agent responsible for delivering this message to > the intended recipient, you are hereby notified that any > reproduction, dissemination or distribution of this > communication is strictly prohibited. If you have received > this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. > > Thank you. > Tellabs > ============================================================ > ----------------------------------------- ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ --------------080207010105030209060601 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Adrian and all,

After checking with the OIF, I understand that UNI1.0r2 has passed Straw Ballot but
not Principal Ballot.  The value in question could be adjusted as an editorial change before
going to Principal Ballot.  The OIF is meeting next week and UNI1.0r2 is likely to go
to Principal Ballot soon.

Regards,
Ben

Ben.Mack-Crane@tellabs.com wrote:
Adrian,

Initially OIF used the value (4) in UNI1.0.  I do not know how this value
was chosen, or who chose it, but this is probably how it came into common use, since UNI
interop was done quite a while ago.

While making minor corrections and updates to conform with IETF RFCs (since UNI1.0
was based on drafts) we consulted the IANA assignments and found (3), so that value
was used as the corrected value in UNI1.0r2.

So, OIF has followed the official IANA assignment.

Regards,
Ben

Adrian Farrel wrote:
Erm,
Which order this happen Ben?

IANA or OIF first?

Thanks,
Adrian
----- Original Message ----- 
From: "Ben Mack-Crane" <ben.mack-crane@tellabs.com>
To: <Andy.Malis@tellabs.com>
Cc: <ccamp@ops.ietf.org>
Sent: Wednesday, January 14, 2004 4:02 PM
Subject: Re: IANA assignments


  
To add to Andy's factual response on Tellabs' implementations,
I would like to support Bert's messages on following the process
and also state that we are willing to update our implementation
to support the "right" codepoint.

Other standards organizations depend on the stability of the
IANA process.  For example, the recently approved OIF UNI1.0r2 IA
specifies the IANA assigned C-Type (3) for SONET/SDH TSPEC/FLOWSPEC.
This will be a problem if the IANA assignment is changed.

Regards,
Ben Mack-Crane

Andy.Malis@tellabs.com wrote:

    
Ditto for Tellabs (the same as Kireeti's answer).

Andy

------------

At 1/9/2004 11:48 AM -0800, Kireeti Kompella wrote:

      
On Fri, 9 Jan 2004, Kireeti Kompella wrote:

For the record, here is the answer from Juniper's implementation:

        
a) do you use the FLOWSPEC C-Type 3 for CoS?
          
We parse this, but don't really use it.

        
b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
   you use for the C-Type?
          
Yes. Value 4.

        
c) do you use the TSPEC C-Type 3 for CoS?
          
We parse this, but don't really use it.

        
d) have you implemented the SONET/SDH TSPEC?  If so, what value did
   you use for the C-Type?
          
Yes. Value 4.

Kireeti.
-------
        
      
-----------------------------------------
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the
reader of this message is not the intended recipient, or an
employee or agent responsible for delivering this message to
the intended recipient, you are hereby notified that any
reproduction, dissemination or distribution of this
communication is strictly prohibited. If you have received
this communication in error, please notify us immediately by
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================


============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the
reader of this message is not the intended recipient, or an
employee or agent responsible for delivering this message to
the intended recipient, you are hereby notified that any
reproduction, dissemination or distribution of this
communication is strictly prohibited. If you have received
this communication in error, please notify us immediately by
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

--------------080207010105030209060601-- From owner-ccamp@ops.ietf.org Fri Jan 16 13:46:22 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24533 for ; Fri, 16 Jan 2004 13:46:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhYz8-00063a-00 for ccamp-archive@ietf.org; Fri, 16 Jan 2004 13:46:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhYyA-00060u-00 for ccamp-archive@ietf.org; Fri, 16 Jan 2004 13:45:23 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AhYxH-0005yg-00 for ccamp-archive@ietf.org; Fri, 16 Jan 2004 13:44:27 -0500 Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AhYgt-0005z6-Qn for ccamp-data@psg.com; Fri, 16 Jan 2004 18:27:31 +0000 Received: from [207.17.136.150] (helo=kummer.juniper.net) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AhYgh-0005yU-Nt for ccamp@ops.ietf.org; Fri, 16 Jan 2004 18:27:19 +0000 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id i0GIREPg035867; Fri, 16 Jan 2004 10:27:14 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id i0GIRDId035864; Fri, 16 Jan 2004 10:27:13 -0800 (PST) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Fri, 16 Jan 2004 10:27:13 -0800 (PST) From: Kireeti Kompella To: Thomas Narten cc: ccamp@ops.ietf.org, iana@iana.org Subject: Re: IANA assignments In-Reply-To: <200401161214.i0GCEol04004@cichlid.raleigh.ibm.com> Message-ID: <20040116102355.F35769@kummer.juniper.net> References: <200401161214.i0GCEol04004@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, 16 Jan 2004, Thomas Narten wrote: > It might be possible to change this assignment if people can make a > clear case that: > > - leaving the assignment of 3 is clearly worse than changing to 4, This is clear: all implementations that reported (with the exception of the new revision from cisco) use the value of 4. > and > - changing to 4 doesn't cause hardship and confusion for those that > have picked up the IANA-assigned value of 3. Both cisco (George Swallow) and OIF (Ben Mack-Crane) have stated on this list that reverting to 4 is acceptable *if done quickly*. So, can we do this quickly? Kireeti. ------- From owner-ccamp@ops.ietf.org Fri Jan 16 13:47:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24568 for ; Fri, 16 Jan 2004 13:47:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhZ07-000666-00 for ccamp-archive@ietf.org; Fri, 16 Jan 2004 13:47:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhYzG-00064W-00 for ccamp-archive@ietf.org; Fri, 16 Jan 2004 13:46:30 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AhYyx-00062L-00 for ccamp-archive@ietf.org; Fri, 16 Jan 2004 13:46:11 -0500 Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AhYiQ-00069f-9l for ccamp-data@psg.com; Fri, 16 Jan 2004 18:29:06 +0000 Received: from [207.17.136.150] (helo=kummer.juniper.net) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AhYiE-000693-JZ for ccamp@ops.ietf.org; Fri, 16 Jan 2004 18:28:54 +0000 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id i0GISsPg035893; Fri, 16 Jan 2004 10:28:54 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id i0GISs2R035890; Fri, 16 Jan 2004 10:28:54 -0800 (PST) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Fri, 16 Jan 2004 10:28:53 -0800 (PST) From: Kireeti Kompella To: Ben Mack-Crane cc: ccamp@ops.ietf.org Subject: Re: IANA assignments In-Reply-To: <4007FDB5.2020802@tellabs.com> Message-ID: <20040116102731.Q35769@kummer.juniper.net> References: <4006AF1C.1040304@tellabs.com> <4007FDB5.2020802@tellabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, 16 Jan 2004, Ben Mack-Crane wrote: > Adrian and all, > > After checking with the OIF, I understand that UNI1.0r2 has passed Straw > Ballot but > not Principal Ballot. The value in question could be adjusted as an > editorial change before > going to Principal Ballot. The OIF is meeting next week and UNI1.0r2 is > likely to go > to Principal Ballot soon. Thanks for the update, Ben. We'll try to resolve this quickly. Kireeti. ------- From owner-ccamp@ops.ietf.org Fri Jan 16 17:21:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02381 for ; Fri, 16 Jan 2004 17:21:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhcL6-0000y3-00 for ccamp-archive@ietf.org; Fri, 16 Jan 2004 17:21:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhcHt-0000oJ-00 for ccamp-archive@ietf.org; Fri, 16 Jan 2004 17:17:58 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AhcEF-0000Y8-00 for ccamp-archive@ietf.org; Fri, 16 Jan 2004 17:14:11 -0500 Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Ahc3l-0007Th-Sk for ccamp-data@psg.com; Fri, 16 Jan 2004 22:03:21 +0000 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ahc3Z-0007T9-85; Fri, 16 Jan 2004 22:03:09 +0000 Date: Fri, 16 Jan 2004 14:02:47 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <183189057480.20040116140247@psg.com> To: Kireeti Kompella CC: Thomas Narten , ccamp@ops.ietf.org, iana@iana.org Subject: Re: IANA assignments In-Reply-To: <20040116102355.F35769@kummer.juniper.net> References: <200401161214.i0GCEol04004@cichlid.raleigh.ibm.com> <20040116102355.F35769@kummer.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Kireeti, >> It might be possible to change this assignment if people can make a >> clear case that: >> >> - leaving the assignment of 3 is clearly worse than changing to 4, > This is clear: all implementations that reported (with the exception > of the new revision from cisco) use the value of 4. Agreed. Taking care of this. We also need to make sure we don't have situations like this in future. The solution with Expert Review Thomas proposed seems to be reasonable. Alex >> and >> - changing to 4 doesn't cause hardship and confusion for those that >> have picked up the IANA-assigned value of 3. > Both cisco (George Swallow) and OIF (Ben Mack-Crane) have stated on > this list that reverting to 4 is acceptable *if done quickly*. So, > can we do this quickly? > Kireeti. > ------- From rmonews@mail.com Sat Jan 17 02:33:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29952 for ; Sat, 17 Jan 2004 02:32:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ahkx1-0002ox-00 for ccamp-archive@ietf.org; Sat, 17 Jan 2004 02:32:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhkwP-0002kV-00 for ccamp-archive@ietf.org; Sat, 17 Jan 2004 02:32:22 -0500 Received: from cpe-144-132-189-227.nsw.bigpond.net.au ([144.132.189.227] helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1AhkvS-0002ec-00; Sat, 17 Jan 2004 02:31:24 -0500 From: "Memorial Cubano:" To: bofchairs@ietf.org Subject: Pedem Missas e orações pelas vítimas do comunismo ref.: qtz X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Sat, 17 Jan 2004 02:31:24 -0500 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=13.9 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,HTML_40_50,HTML_FONT_BIG,HTML_MESSAGE, MAILTO_SUBJ_REMOVE,MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT, REMOVE_REMOVAL_2WORD,SUBJ_HAS_SPACES,SUBJ_ILLEGAL_CHARS autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook

Ref.: (lzc) InEnglish / InItaliano / EnCastellano

Memorial cubano: Pedido de Missas e orações pelas vítimas do comunismo

A ajuda urgente que solicitamos é de caráter estritamente espiritual, ao alcance de cada um e, sem dúvida, a mais valiosa aos olhos de Deus

Queridos irmãos luso-brasileiros,

* Precisamos de vossa valiosa ajuda para resgatar do esquecimento a mais de 10 mil cubanos que morreram vítimas do regime comunista, sobre os quais se possui informação documentada. Esta ajuda que lhes solicitamos é de caráter estritamente espiritual, inteiramente ao alcance de cada um e, sem dúvida, a mais valiosa aos olhos de Deus!

* Entre os dias 20 e 23 de fevereiro próximo, no Tamiami Park de Miami, Flórida, voluntários de diversos países organizarão o Memorial Cubano, consistente em mais de 10 mil cruzes brancas, cada uma delas tendo inscrito o nome de uma vítima do regime comunista de Cuba. Familiares desterrados que nunca puderam dar o adeus a seus seres queridos assassinados, por não ser-lhes permitido visitar suas tumbas em Cuba, poderão fazê-lo agora.

* No centro da área se localizará uma cruz de madeira gigante, também pintada de branco, denominada "Cruz da vítima desconhecida", que constituirá o reconhecimento a todos os que morreram por causa do regime comunista, porém a respeito dos quais até o momento não se possui informação suficiente.

* De que maneira vocês podem unir-se a esta cruzada de orações e a esta homenagem espiritual? Simplesmente encomendando uma Missa ou serviço religioso, organizando com sua família, comunidade ou colegas de trabalho um momento de oração conjunta, ou rezando privadamente. Solicitamos-lhes que as Missas sejam encomendadas, se for possível, para o domingo 22 de fevereiro. Assim, no mundo inteiro, nesse dia se elevarão preces a Deus pelo eterno descanso dessas almas. Poderão encomendá-las em benefício das "vítimas do genocídio cubano sob o regime comunista de Fidel Castro".

* Muitas destas vítimas foram jovens que enfrentaram o "paredón" de fuzilamento proclamando "Viva Cristo Rei!"

* Confirmem-nos o quanto antes vossa adesão, encomendando Missas, prometendo orações, etc., fazendo clic em:

ConfirmamosMissa/ServicoReligioso e/ou ConfirmamosOraçoesPreces incluindo local, data e, se o desejarem, outros detalhes.

* Irmãos ibero-americanos e homens e mulheres de boa vontade, de outras regiões do mundo, que leiam esta mensagem e a ela adiram: que a Providência os recompense com o cêntuplo já nesta terra!

Com a maior consideração e estima,

Renato Gómez - Coordenador Geral

Comitê Organizador do Memorial Cubano

Tel. (1-786) 621-7505 Miami (FL) www memorialcubano org

PS.:

Em vossas orações e preces incluam também os homens, mulheres e crianças que morreram afogados no estreito da Flórida, tentando alcançar a liberdade. Seus nomes são em sua maioria desconhecidos e fontes autorizadas estimam que o número deles seja de muitas dezenas de milhares de cubanos.

Por fim, rezem pelos presos políticos que agonizam nos cárceres, como o médico Oscar Elias Biscet, pela economista Martha Beatriz Roque e milhares de outros irmãos cubanos detidos DesejoInfoPresosPoliticos. A seis anos da viagem de S.S. João Paulo II a Cuba (21-25 de janeiro de 1998), se continua contrariando o sonho papal de que a ilha-cárcere abra-se ao mundo.

LINKS PRIORITÁRIOS:

ConfirmoMissa/ServiçoReligioso e/ou ConfirmoOraçoesPreces (incluindo nome, cidade e, se desejar, outros detalhes)

MinhaAjuda (narre de que maneira poderá ajudar-nos a difundir esta iniciativa espiritual e humanitária: reenviando esta notícia a seus amigos, levando-a a jornalistas conhecidos, colocando-a no quadro de avisos de seu local de trabalho, etc.; pode incluir também sugestões).

MinhaOpiniao

OUTROS LINKS:

DesejoRecibirLinkMemorialCubano (para receber o link do web site sobre o Memorial Cubano, com nomes de todas as vítimas)

DesejoReceberInfoPresosPoliticos

ProximosEnvios:SoloEnEspañol

NextMails:OnlyInEnglish

Remover

A difusão deste e-mail é de exclusiva responsabilidade da agência humanitária Derechos Sin Fronteras (DSF).

Tradução: Graça Salgueiro

 

 

From owner-ccamp@ops.ietf.org Mon Jan 19 10:44:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22198 for ; Mon, 19 Jan 2004 10:44:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AibZj-0004Zw-00 for ccamp-archive@ietf.org; Mon, 19 Jan 2004 10:44:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AibXu-0004Mj-00 for ccamp-archive@ietf.org; Mon, 19 Jan 2004 10:42:36 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AibV6-000440-00 for ccamp-archive@ietf.org; Mon, 19 Jan 2004 10:39:40 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aib8A-0001JH-5W for ccamp-data@psg.com; Mon, 19 Jan 2004 15:15:58 +0000 Received: from [193.205.242.5] (helo=nausicaa.coritel.it) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Aib7w-0001Ia-Iq for ccamp@ops.ietf.org; Mon, 19 Jan 2004 15:15:44 +0000 Received: from Poisson ([151.100.37.144]) by nausicaa.coritel.it (8.11.2/8.11.2) with SMTP id i0JFMiw29439; Mon, 19 Jan 2004 16:22:48 +0100 Message-ID: <00ac01c3de9f$98153980$90256497@coritel> From: "alessio d'achille" To: Cc: Subject: A new draft is available Date: Mon, 19 Jan 2004 16:18:37 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A7_01C3DEA7.E4A18080" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_00A7_01C3DEA7.E4A18080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all,=20 we have just submitted to the IETF a new draft about inter-area path = protection; in this document we addressed the problem of establishing = two disjoint LSPs between two nodes which belongs to different areas = (with the term "areas" we refer to an - OSPF area or - Autonomous System or - Optical island ) The draft is now available in the IETF draft directory and its name is : A URL for this Internet-Draft is:=20 http://www.ietf.org/internet-drafts/draft-dachille-inter-area-path-protec= tion-00.txt Best regards to all, Alessio D'Achille (one of the authors of this draft),=20 on behalf of Vishal Sharma (co-author), Fabio Ricciato (author), Marco Listanti = (Author) and Ugo Monaco (Author). P.S. We have noticed that there is an error in the authors' referencs in = the very first page in the version of the draft in the IETF draft = directory (in fact, in the very first page, "Ed." figures next to Vishal = Sharma, but he is a co-author, and "Ed." should be next to Alessio = D'Achille, Fabio Ricciato, Marco Listanti and Ugo Monaco) ------=_NextPart_000_00A7_01C3DEA7.E4A18080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
we have = just submitted to=20 the IETF a new draft about inter-area path protection; in this document = we=20 addressed the problem of establishing two disjoint LSPs between two = nodes which=20 belongs to different areas (with the term "areas" we refer to=20 an
- OSPF area = or
- = Autonomous System=20 or
- Optical=20 island      )
 
The draft is now available in the IETF = draft=20 directory and its name is :
 
<draft-dachille-inter-area-path-protection-00.txt><= /DIV>
 
A URL for this Internet-Draft is: =
 
http://www.ietf.org/internet-drafts/draft-dachille-i= nter-area-path-protection-00.txt
 
Best = regards to=20 all,
 
Alessio = D'Achille (one of=20 the authors of this draft),
on behalf of
 
Vishal Sharma (co-author), Fabio = Ricciato (author),=20 Marco Listanti (Author) and Ugo Monaco (Author).
 
 
P.S. We have noticed that there is an = error in the=20 authors' referencs in the very first page in the version of the draft in = the=20 IETF draft directory (in fact, in the very first page, "Ed." figures = next to=20 Vishal Sharma, but he is a co-author, and "Ed." should be next to = Alessio=20 D'Achille, Fabio Ricciato, Marco Listanti and Ugo Monaco)
 
 
 
=  
 
------=_NextPart_000_00A7_01C3DEA7.E4A18080-- From owner-ccamp@ops.ietf.org Mon Jan 19 13:37:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01062 for ; Mon, 19 Jan 2004 13:37:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AieGx-0002Ar-00 for ccamp-archive@ietf.org; Mon, 19 Jan 2004 13:37:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AieEK-00021Y-00 for ccamp-archive@ietf.org; Mon, 19 Jan 2004 13:34:33 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AieBg-0001sW-00 for ccamp-archive@ietf.org; Mon, 19 Jan 2004 13:31:48 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AidtP-000Ii5-ON for ccamp-data@psg.com; Mon, 19 Jan 2004 18:12:55 +0000 Received: from [66.163.169.223] (helo=smtp104.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.24; FreeBSD) id 1Aidt4-000IhE-Ld for ccamp@ops.ietf.org; Mon, 19 Jan 2004 18:12:34 +0000 Received: from unknown (HELO RAKHILAPTOP) (vsharma87@63.206.95.34 with login) by smtp104.mail.sc5.yahoo.com with SMTP; 19 Jan 2004 18:12:33 -0000 From: "Vishal Sharma" To: Cc: , "alessio d'achille" Subject: RE: Inter-region TE Date: Mon, 19 Jan 2004 10:12:31 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01C3DE74.C0106B60" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <00ac01c3de9f$98153980$90256497@coritel> Importance: Normal Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C3DE74.C0106B60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Folks, I just wanted to add that this work ties in to the recent inter-AS/inter-area TE work that has been a focus of the TE and CCAMP WGs. As Alessio mentioned, this work takes a unified view of areas and AS's, and is applicable to both inter-AS and inter-area scenarios. Therefore, we would be particularly interested in feedback from some of the principal WG members who are involved in the inter-AS/inter-area activity. Regards, -Vishal -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of alessio d'achille Sent: Monday, January 19, 2004 7:19 AM To: ccamp@ops.ietf.org Cc: te-wg@osp.ietf.org Subject: A new draft is available Hi all, we have just submitted to the IETF a new draft about inter-area path protection; in this document we addressed the problem of establishing two disjoint LSPs between two nodes which belongs to different areas (with the term "areas" we refer to an - OSPF area or - Autonomous System or - Optical island ) The draft is now available in the IETF draft directory and its name is : A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dachille-inter-area-path-protectio n-00.txt Best regards to all, Alessio D'Achille (one of the authors of this draft), on behalf of Vishal Sharma (co-author), Fabio Ricciato (author), Marco Listanti (Author) and Ugo Monaco (Author). P.S. We have noticed that there is an error in the authors' referencs in the very first page in the version of the draft in the IETF draft directory (in fact, in the very first page, "Ed." figures next to Vishal Sharma, but he is a co-author, and "Ed." should be next to Alessio D'Achille, Fabio Ricciato, Marco Listanti and Ugo Monaco) ------=_NextPart_000_0023_01C3DE74.C0106B60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Folks,
 
I just=20 wanted to add that this work ties in to the recent = inter-AS/inter-area=20 TE
work that has been a focus = of the=20 TE and CCAMP WGs.
 
As=20 Alessio mentioned, this work takes a unified view of areas and AS's,=20 and
is=20 applicable to both inter-AS and inter-area = scenarios.
 
Therefore, we would be particularly = interested in=20 feedback from some of the
principal WG members who are involved in the=20 inter-AS/inter-area activity.
 
Regards,
-Vishal
-----Original Message-----
From: = owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org]On Behalf Of alessio=20 d'achille
Sent: Monday, January 19, 2004 7:19 = AM
To:=20 ccamp@ops.ietf.org
Cc: te-wg@osp.ietf.org
Subject: = A new=20 draft is available

Hi all,
 
we have = just submitted to=20 the IETF a new draft about inter-area path protection; in this = document we=20 addressed the problem of establishing two disjoint LSPs between two = nodes=20 which belongs to different areas (with the term "areas" we refer to=20 an
- OSPF = area=20 or
- = Autonomous System=20 or
- Optical = island      )
 
The draft is now available in the = IETF draft=20 directory and its name is :
 
<draft-dachille-inter-area-path-protection-00.txt><= /DIV>
 
A URL for this Internet-Draft is: =
 
http://www.ietf.org/internet-drafts/draft-dachille-i= nter-area-path-protection-00.txt
 
Best = regards to=20 all,
 
Alessio = D'Achille (one of=20 the authors of this draft),
on behalf of
 
Vishal Sharma (co-author), Fabio = Ricciato=20 (author), Marco Listanti (Author) and Ugo Monaco = (Author).
 
 
P.S. We have noticed that there is an = error in=20 the authors' referencs in the very first page in the version of the = draft in=20 the IETF draft directory (in fact, in the very first page, "Ed." = figures next=20 to Vishal Sharma, but he is a co-author, and "Ed." should be next to = Alessio=20 D'Achille, Fabio Ricciato, Marco Listanti and Ugo Monaco)
 
 
 
=  
 
------=_NextPart_000_0023_01C3DE74.C0106B60-- From owner-ccamp@ops.ietf.org Mon Jan 19 13:50:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01743 for ; Mon, 19 Jan 2004 13:50:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AieTv-0003Gx-00 for ccamp-archive@ietf.org; Mon, 19 Jan 2004 13:50:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AieSx-000377-00 for ccamp-archive@ietf.org; Mon, 19 Jan 2004 13:49:40 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AieRz-0002ze-00 for ccamp-archive@ietf.org; Mon, 19 Jan 2004 13:48:40 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AieAB-000KAQ-60 for ccamp-data@psg.com; Mon, 19 Jan 2004 18:30:15 +0000 Received: from [66.163.169.226] (helo=smtp106.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.24; FreeBSD) id 1Aie9x-000K8k-FK for ccamp@ops.ietf.org; Mon, 19 Jan 2004 18:30:01 +0000 Received: from unknown (HELO RAKHILAPTOP) (vsharma87@67.117.149.0 with login) by smtp106.mail.sc5.yahoo.com with SMTP; 19 Jan 2004 18:30:00 -0000 From: "Vishal Sharma" To: , "TE" Cc: "alessio d'achille" Subject: Inter-region TE Date: Mon, 19 Jan 2004 10:29:58 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01C3DE77.2FD8D5C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <00ac01c3de9f$98153980$90256497@coritel> Importance: Normal Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_002C_01C3DE77.2FD8D5C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Folks, I just wanted to add that this work ties in to the recent inter-AS/inter-area TE work that has been a focus of the TE and CCAMP WGs. As Alessio mentioned, this work takes a unified view of areas and AS's, and is applicable to both inter-AS and inter-area scenarios. Therefore, we would be particularly interested in feedback from some of the principal WG members who are involved in the inter-AS/inter-area activity. Regards, -Vishal -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of alessio d'achille Sent: Monday, January 19, 2004 7:19 AM To: ccamp@ops.ietf.org Cc: te-wg@osp.ietf.org Subject: A new draft is available Hi all, we have just submitted to the IETF a new draft about inter-area path protection; in this document we addressed the problem of establishing two disjoint LSPs between two nodes which belongs to different areas (with the term "areas" we refer to an - OSPF area or - Autonomous System or - Optical island ) The draft is now available in the IETF draft directory and its name is : A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dachille-inter-area-path-protectio n-00.txt Best regards to all, Alessio D'Achille (one of the authors of this draft), on behalf of Vishal Sharma (co-author), Fabio Ricciato (author), Marco Listanti (Author) and Ugo Monaco (Author). P.S. We have noticed that there is an error in the authors' referencs in the very first page in the version of the draft in the IETF draft directory (in fact, in the very first page, "Ed." figures next to Vishal Sharma, but he is a co-author, and "Ed." should be next to Alessio D'Achille, Fabio Ricciato, Marco Listanti and Ugo Monaco) ------=_NextPart_000_002C_01C3DE77.2FD8D5C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Folks,
 
I just=20 wanted to add that this work ties in to the recent = inter-AS/inter-area=20 TE
work that has been a focus = of the=20 TE and CCAMP WGs.
 
As=20 Alessio mentioned, this work takes a unified view of areas and AS's,=20 and
is=20 applicable to both inter-AS and inter-area = scenarios.
 
Therefore, we would be particularly = interested in=20 feedback from some of the
principal WG members who are involved in the=20 inter-AS/inter-area activity.
 
Regards,
-Vishal
-----Original Message-----
From: = owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org]On Behalf Of alessio=20 d'achille
Sent: Monday, January 19, 2004 7:19 = AM
To:=20 ccamp@ops.ietf.org
Cc: te-wg@osp.ietf.org
Subject: = A new=20 draft is available

Hi all,
 
we have = just submitted to=20 the IETF a new draft about inter-area path protection; in this = document we=20 addressed the problem of establishing two disjoint LSPs between two = nodes=20 which belongs to different areas (with the term "areas" we refer to=20 an
- OSPF = area=20 or
- = Autonomous System=20 or
- Optical = island      )
 
The draft is now available in the = IETF draft=20 directory and its name is :
 
<draft-dachille-inter-area-path-protection-00.txt><= /DIV>
 
A URL for this Internet-Draft is: =
 
http://www.ietf.org/internet-drafts/draft-dachille-i= nter-area-path-protection-00.txt
 
Best = regards to=20 all,
 
Alessio = D'Achille (one of=20 the authors of this draft),
on behalf of
 
Vishal Sharma (co-author), Fabio = Ricciato=20 (author), Marco Listanti (Author) and Ugo Monaco = (Author).
 
 
P.S. We have noticed that there is an = error in=20 the authors' referencs in the very first page in the version of the = draft in=20 the IETF draft directory (in fact, in the very first page, "Ed." = figures next=20 to Vishal Sharma, but he is a co-author, and "Ed." should be next to = Alessio=20 D'Achille, Fabio Ricciato, Marco Listanti and Ugo Monaco)
 
 
 
=  
 
------=_NextPart_000_002C_01C3DE77.2FD8D5C0-- From owner-ccamp@ops.ietf.org Mon Jan 19 19:31:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19074 for ; Mon, 19 Jan 2004 19:31:48 -0500 (EST) From: owner-ccamp@ops.ietf.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aijo6-00044g-00 for ccamp-archive@ietf.org; Mon, 19 Jan 2004 19:31:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aijmd-0003lo-00 for ccamp-archive@ietf.org; Mon, 19 Jan 2004 19:30:22 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Aijhu-0003Nj-00 for ccamp-archive@ietf.org; Mon, 19 Jan 2004 19:25:26 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AijRA-0002YH-Cg for ccamp-data@psg.com; Tue, 20 Jan 2004 00:08:08 +0000 Date: Mon, 19 Jan 2004 23:37:52 +0000 To: ccamp-approval@psg.com Subject: BOUNCE ccamp@ops.ietf.org: Non-member submission from [The IESG ] Sender: owner-ccamp@ops.ietf.org Precedence: bulk Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 >From amyk@cnri.reston.va.us Mon Jan 19 23:37:40 2004 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Aiixf-000PR6-IC for ccamp@ops.ietf.org; Mon, 19 Jan 2004 23:37:39 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16365; Mon, 19 Jan 2004 18:37:35 -0500 (EST) Message-Id: <200401192337.SAA16365@ietf.org> To: IETF-Announce: ; From: The IESG cc: ccamp@ops.ietf.org Subject: Short Last Call: IANA allocations for ietf-ccamp-gmpls-sonet-sdh Date: Mon, 19 Jan 2004 18:37:35 -0500 Sender: amyk@cnri.reston.va.us X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 The IESG is considering the situation with IANA allocation of the RSVP FLOWSPEC and SENDER_TSPEC C-Types for ietf-ccamp-gmpls-sonet-sdh that has been recently approved by the IESG for publication as an RFC. While the long-term measures to prevent similar situations in future are being discussed, the issue at hand needs to be quickly resolved. The proposed solution is to change the assignment of the above C-Types from value 3 (currently assigned by IANA) to 4, and mark value 3 as "reserved". The IESG would like to solicit comments on the proposed solution from the community. More details are given below. Please send your comments by January 22nd, 2004. Description of the situation with IANA assignments for ietf-ccamp-gmpls-sonet-sdh: 1. After the approval of the document by the IESG, an IANA action has been performed for the document, in which IANA correctly picked the next available C-Type value (3) in the FLOWSPEC and SENDER_TSPEC ranges and assigned it to the document. 2. However, the CCAMP WG has been informed that value 3 is being used by implementations of an another (expired) Internet draft that also picked next available value in the same ranges. Because the draft never progressed, these values have never been formally allocated by IANA within the RSVP registry. 3. Because implementations of the expired Internet draft have been deployed, assigning value 3 to ietf-ccamp-gmpls-sonet-sdh would create interoperability problems. 4. An implementation survey performed in the CCAMP WG showed that most early implementations of ietf-ccamp-gmpls-sonet-sdh use value 4, and those few that use the IANA-assigned value 3 would be willing to change it to 4 to avoid interoperability problems. From owner-ccamp@ops.ietf.org Tue Jan 20 08:05:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27177 for ; Tue, 20 Jan 2004 08:05:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AivZE-00059Z-00 for ccamp-archive@ietf.org; Tue, 20 Jan 2004 08:05:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AivYJ-00057r-00 for ccamp-archive@ietf.org; Tue, 20 Jan 2004 08:04:19 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AivXa-000569-00 for ccamp-archive@ietf.org; Tue, 20 Jan 2004 08:03:34 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AivBa-000LFC-F2 for ccamp-data@psg.com; Tue, 20 Jan 2004 12:40:50 +0000 Received: from [193.205.242.5] (helo=nausicaa.coritel.it) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AivBL-000LD7-Ei; Tue, 20 Jan 2004 12:40:36 +0000 Received: from Poisson ([151.100.37.144]) by nausicaa.coritel.it (8.11.2/8.11.2) with SMTP id i0KClWw02030; Tue, 20 Jan 2004 13:47:45 +0100 Message-ID: <00dd01c3df53$0d3a25a0$90256497@coritel> From: "alessio d'achille" To: Cc: Subject: revised version of the draft Date: Tue, 20 Jan 2004 13:43:25 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D8_01C3DF5B.611526E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_00D8_01C3DF5B.611526E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi folks,=20 Wer have just submitted a revised version of our draft: = , since the previous = version included few errors; you will find the new version soon, and we = ask you to send your feedback to us about this new version and not about = the previous one. As Vishal said in a previous e-mail, we would be particularly interested = in feedback from some of the principal WG members who are involved in = the inter-AS/inter-area activity. Best regards,=20 Alessio D'Achille=20 on behalf of Vishal Sharma, Marco Listanti, Fabio Ricciato, and Ugo = monaco ------=_NextPart_000_00D8_01C3DF5B.611526E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi folks,
 
Wer have just submitted a revised = version of our=20 draft: <draft-dachille-inter-area-path-protection-01.txt>, since = the=20 previous version included few errors; you will find the new version = soon, and we=20 ask you to send your feedback to us about this new version and not about = the=20 previous one.
 
As Vishal said in a previous e-mail, = we would=20 be particularly interested in feedback from some of the principal=20 WG members who are involved in the inter-AS/inter-area=20 activity.
 
Best regards,
 
Alessio D'Achille
 
on behalf of Vishal Sharma, Marco = Listanti, Fabio=20 Ricciato, and Ugo monaco
------=_NextPart_000_00D8_01C3DF5B.611526E0-- From owner-ccamp@ops.ietf.org Tue Jan 20 13:23:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15154 for ; Tue, 20 Jan 2004 13:23:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj0XD-00029o-00 for ccamp-archive@ietf.org; Tue, 20 Jan 2004 13:23:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj0WK-00027f-00 for ccamp-archive@ietf.org; Tue, 20 Jan 2004 13:22:36 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Aj0W8-000252-00 for ccamp-archive@ietf.org; Tue, 20 Jan 2004 13:22:24 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aj08D-0004Sh-QC for ccamp-data@psg.com; Tue, 20 Jan 2004 17:57:41 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Aiixf-000PR6-IC for ccamp@ops.ietf.org; Mon, 19 Jan 2004 23:37:39 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16365; Mon, 19 Jan 2004 18:37:35 -0500 (EST) Message-Id: <200401192337.SAA16365@ietf.org> From: The IESG cc: ccamp@ops.ietf.org Subject: Short Last Call: IANA allocations for ietf-ccamp-gmpls-sonet-sdh Date: Mon, 19 Jan 2004 18:37:35 -0500 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 The IESG is considering the situation with IANA allocation of the RSVP FLOWSPEC and SENDER_TSPEC C-Types for ietf-ccamp-gmpls-sonet-sdh that has been recently approved by the IESG for publication as an RFC. While the long-term measures to prevent similar situations in future are being discussed, the issue at hand needs to be quickly resolved. The proposed solution is to change the assignment of the above C-Types from value 3 (currently assigned by IANA) to 4, and mark value 3 as "reserved". The IESG would like to solicit comments on the proposed solution from the community. More details are given below. Please send your comments by January 22nd, 2004. Description of the situation with IANA assignments for ietf-ccamp-gmpls-sonet-sdh: 1. After the approval of the document by the IESG, an IANA action has been performed for the document, in which IANA correctly picked the next available C-Type value (3) in the FLOWSPEC and SENDER_TSPEC ranges and assigned it to the document. 2. However, the CCAMP WG has been informed that value 3 is being used by implementations of an another (expired) Internet draft that also picked next available value in the same ranges. Because the draft never progressed, these values have never been formally allocated by IANA within the RSVP registry. 3. Because implementations of the expired Internet draft have been deployed, assigning value 3 to ietf-ccamp-gmpls-sonet-sdh would create interoperability problems. 4. An implementation survey performed in the CCAMP WG showed that most early implementations of ietf-ccamp-gmpls-sonet-sdh use value 4, and those few that use the IANA-assigned value 3 would be willing to change it to 4 to avoid interoperability problems. From owner-ccamp@ops.ietf.org Tue Jan 20 14:49:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17530 for ; Tue, 20 Jan 2004 14:49:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aj1sP-0005bM-00 for ccamp-archive@ietf.org; Tue, 20 Jan 2004 14:49:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aj1rT-0005ZM-00 for ccamp-archive@ietf.org; Tue, 20 Jan 2004 14:48:32 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Aj1qa-0005Xa-00 for ccamp-archive@ietf.org; Tue, 20 Jan 2004 14:47:36 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aj1c7-000EQg-7s for ccamp-data@psg.com; Tue, 20 Jan 2004 19:32:39 +0000 Received: from [207.17.136.150] (helo=kummer.juniper.net) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Aj1bu-000EP3-UH for ccamp@ops.ietf.org; Tue, 20 Jan 2004 19:32:26 +0000 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id i0KJWQPg054622 for ; Tue, 20 Jan 2004 11:32:26 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id i0KJWQo5054619 for ; Tue, 20 Jan 2004 11:32:26 -0800 (PST) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Tue, 20 Jan 2004 11:32:26 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: Liaison response posted Message-ID: <20040120112942.Q53956@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi, The Liaison response that the CCAMP WG sent to the ITU-T re G.7713.2 has been posted to the IETF "Liaison Statements" page at http://ietf.org/IESG/liaison.html . Kireeti. ------- From owner-ccamp@ops.ietf.org Wed Jan 21 09:10:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21504 for ; Wed, 21 Jan 2004 09:10:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjJ3T-0006ag-00 for ccamp-archive@ietf.org; Wed, 21 Jan 2004 09:10:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjJ2W-0006WR-00 for ccamp-archive@ietf.org; Wed, 21 Jan 2004 09:09:04 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AjJ1o-0006Us-00 for ccamp-archive@ietf.org; Wed, 21 Jan 2004 09:08:20 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AjIfv-000CNH-IN for ccamp-data@psg.com; Wed, 21 Jan 2004 13:45:43 +0000 Received: from [195.8.69.103] (helo=cerberus.uk.clara.net) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AjIfj-000CLP-59 for ccamp@ops.ietf.org; Wed, 21 Jan 2004 13:45:31 +0000 Received: from du-069-1014.access.clara.net ([217.158.170.251] helo=Puppy) by cerberus.uk.clara.net with smtp (Exim 4.22) id 1AjIfh-000DPX-Kq for ccamp@ops.ietf.org; Wed, 21 Jan 2004 13:45:30 +0000 Message-ID: <0c0b01c3e024$db11d7d0$715708c3@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Submission deadlines for Seoul Date: Wed, 21 Jan 2004 13:45:32 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit All, Please be aware of the following deadlines. February 9, Monday - Internet Draft Cut-off for initial document (-00) submission at 09:00 ET February 16, Monday - Pre-Registration and Pre-payment cut-off at 12:00 noon ET Also, be warned! We plan to require submission of slides in advance of the meeting so that the attendees can follow along at their own speed. There will be something like a 24 hour deadline on this so you won't have to write slides until you know you are on the agenda. Cheers, Adrian From owner-ccamp@ops.ietf.org Wed Jan 21 22:38:47 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24161 for ; Wed, 21 Jan 2004 22:38:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjVg7-0004ZU-00 for ccamp-archive@ietf.org; Wed, 21 Jan 2004 22:38:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjVfG-0004VS-00 for ccamp-archive@ietf.org; Wed, 21 Jan 2004 22:37:54 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AjVem-0004Rg-00 for ccamp-archive@ietf.org; Wed, 21 Jan 2004 22:37:24 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AjVEP-000MX3-6S for ccamp-data@psg.com; Thu, 22 Jan 2004 03:10:09 +0000 Received: from [199.249.17.14] (helo=omzesmtp04.mci.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AjVE6-000MV8-PR for ccamp@ops.ietf.org; Thu, 22 Jan 2004 03:09:50 +0000 Received: from dgismtp05.wcomnet.com ([166.38.58.88]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HRV00D5GF6T91@firewall.mci.com> for ccamp@ops.ietf.org; Thu, 22 Jan 2004 03:04:05 +0000 (GMT) Received: from dgismtp05.wcomnet.com by dgismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HRV00001F6TC8@dgismtp05.mcilink.com> for ccamp@ops.ietf.org; Thu, 22 Jan 2004 03:04:05 +0000 (GMT) Received: from ws344v1681 ([166.50.122.179]) by dgismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HRV00M2LF6SZ8@dgismtp05.mcilink.com> for ccamp@ops.ietf.org; Thu, 22 Jan 2004 03:04:05 +0000 (GMT) Date: Wed, 21 Jan 2004 22:04:03 -0500 From: Ronald Bonica Subject: GTTP Draft To: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks, I have updated the generic tunnel tracing draft. It is available at http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt. Please review and comment. Ron Abstract This document describes the Generic Tunnel Tracing Protocol (GTTP). GTTP supports enhanced route-tracing applications. Network operators use enhanced route-tracing applications to trace the path between any two points in an IP network. Enhanced route-tracing applications can trace through a network's forwarding plane, its control plane or both. Furthermore, enhanced route-tracing applications can reveal details concerning tunnels that support the traced path. Tunnel details can be revealed regardless of tunneling technology. For example, enhanced route-tracing applications can trace through an MPLS LSP as well as they can trace through an IP-in-IP tunnel. =========================================== Ronald P. Bonica Ph: 703 886 1681 vBNS Engineering page: 1 888 268 8021 Ashburn, Va. =========================================== "There is more to life than simply increasing its speed." -- Mahatma Gandhi From owner-ccamp@ops.ietf.org Thu Jan 22 07:53:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20084 for ; Thu, 22 Jan 2004 07:53:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjeLK-0001OB-00 for ccamp-archive@ietf.org; Thu, 22 Jan 2004 07:53:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjeKR-0001MF-00 for ccamp-archive@ietf.org; Thu, 22 Jan 2004 07:52:59 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AjeKA-0001Jm-00 for ccamp-archive@ietf.org; Thu, 22 Jan 2004 07:52:42 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AjdwF-0003TH-W4 for ccamp-data@psg.com; Thu, 22 Jan 2004 12:27:59 +0000 Received: from [195.8.69.53] (helo=zephir.uk.clara.net) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ajdvt-0003Pv-7b for ccamp@ops.ietf.org; Thu, 22 Jan 2004 12:27:37 +0000 Received: from du-069-0991.access.clara.net ([217.158.170.228] helo=Puppy) by zephir.uk.clara.net with smtp (Exim 4.22) id 1Ajdvr-000D4Y-AG; Thu, 22 Jan 2004 12:27:35 +0000 Message-ID: <0d3201c3e0e3$23cf6be0$715708c3@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Ronald Bonica" References: Subject: Re: GTTP Draft Date: Thu, 22 Jan 2004 12:26:17 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit All, Recall that a tunnel trace protocol is now in our charter. If the WG considers that GTTP is suitable, we should adopt it and drive it to conclusion. If the WG thinks that GTTP is not suitable (or that there is no need for a tunnel trace protocol) voices should be raised. Cheers, Adrian ----- Original Message ----- From: "Ronald Bonica" To: Sent: Thursday, January 22, 2004 3:04 AM Subject: GTTP Draft > Folks, > > I have updated the generic tunnel tracing draft. It is available at > http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt. Please > review and comment. > > Ron > > Abstract > This document describes the Generic Tunnel Tracing Protocol (GTTP). GTTP > supports enhanced route-tracing applications. Network operators use enhanced > route-tracing applications to trace the path between any two points in an IP > network. Enhanced route-tracing applications can trace through a network's > forwarding plane, its control plane or both. Furthermore, enhanced > route-tracing applications can reveal details concerning tunnels that > support the traced path. Tunnel details can be revealed regardless of > tunneling technology. For example, enhanced route-tracing applications can > trace through an MPLS LSP as well as they can trace through an IP-in-IP > tunnel. > > =========================================== > Ronald P. Bonica Ph: 703 886 1681 > vBNS Engineering page: 1 888 268 8021 > Ashburn, Va. > =========================================== > "There is more to life than simply > increasing its speed." > -- Mahatma Gandhi > > > > From owner-ccamp@ops.ietf.org Fri Jan 23 18:13:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01516 for ; Fri, 23 Jan 2004 18:13:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkAUt-0004kL-00 for ccamp-archive@ietf.org; Fri, 23 Jan 2004 18:13:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkATz-0004jC-00 for ccamp-archive@ietf.org; Fri, 23 Jan 2004 18:12:59 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AkATH-0004hu-00 for ccamp-archive@ietf.org; Fri, 23 Jan 2004 18:12:16 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkA1b-0000X1-4E for ccamp-data@psg.com; Fri, 23 Jan 2004 22:43:39 +0000 Received: from [195.8.69.53] (helo=zephir.uk.clara.net) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AkA1O-0000Uo-Kz for ccamp@ops.ietf.org; Fri, 23 Jan 2004 22:43:26 +0000 Received: from du-069-0562.access.clara.net ([217.158.156.53] helo=Puppy) by zephir.uk.clara.net with smtp (Exim 4.22) id 1AkA1N-000HxB-1T for ccamp@ops.ietf.org; Fri, 23 Jan 2004 22:43:25 +0000 Message-ID: <0f6901c3e202$5736d890$715708c3@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: I-D ACTION:draft-berger-gmpls-egress-control-01.txt Date: Fri, 23 Jan 2004 22:43:32 -0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0F66_01C3E202.54330E70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0F66_01C3E202.54330E70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit All, I didn't see notification of this to the list, but it sure is relevant. Would appreciate review input from everyone, but especially those who were not clear about how/whether GMPLS supported egress port/label control. Also, can you think about whether this draft should be run through the WG. Thanks, Adrian ----- Original Message ----- From: To: Sent: Friday, January 23, 2004 8:59 PM Subject: I-D ACTION:draft-berger-gmpls-egress-control-01.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : GMPLS Signaling Procedure For Egress Control > Author(s) : L. Berger > Filename : draft-berger-gmpls-egress-control-01.txt > Pages : 5 > Date : 2004-1-23 > > This note clarifies the procedures for the control of a label used on > an egress output/downstream interface. Such control is also know and > 'Egress Control'. Support for Egress Control is implicit in > Generalized Multi-Protocol Label Switching (GMPLS) Signaling > [RFC3471] and [RFC3473]. This note does not modify GMPLS signaling > mechanisms and procedures and should be viewed as an informative > clarification of [RFC3473]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-berger-gmpls-egress-control-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-berger-gmpls-egress-control-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > ------=_NextPart_000_0F66_01C3E202.54330E70 Content-Type: application/octet-stream; name="ATT03937.dat" Content-Disposition: attachment; filename="ATT03937.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-1-23161850.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-berger-gmpls-egress-control-01.txt ------=_NextPart_000_0F66_01C3E202.54330E70 Content-Type: text/plain; name="draft-berger-gmpls-egress-control-01.txt" Content-Disposition: attachment; filename="draft-berger-gmpls-egress-control-01.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-1-23161850.I-D@ietf.org> ------=_NextPart_000_0F66_01C3E202.54330E70-- From owner-ccamp@ops.ietf.org Sat Jan 24 10:42:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12318 for ; Sat, 24 Jan 2004 10:42:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkPvn-0003do-00 for ccamp-archive@ietf.org; Sat, 24 Jan 2004 10:42:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkPul-0003ap-00 for ccamp-archive@ietf.org; Sat, 24 Jan 2004 10:41:40 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AkPtv-0003Y3-00 for ccamp-archive@ietf.org; Sat, 24 Jan 2004 10:40:47 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkPbS-0006rs-Pu for ccamp-data@psg.com; Sat, 24 Jan 2004 15:21:42 +0000 Received: from [65.205.166.188] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AkPbF-0006rH-EA for ccamp@ops.ietf.org; Sat, 24 Jan 2004 15:21:29 +0000 Received: from lb-laptop.movaz.com (kenaz.atlanta.movaz.com [172.16.8.184]) by jera.movaz.com (Postfix) with ESMTP id 38DF619D3; Sat, 24 Jan 2004 10:21:28 -0500 (EST) Message-Id: <4.3.2.7.2.20040124101905.0279dee8@mo-ex1> X-Sender: lb@mo-ex1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 24 Jan 2004 10:21:28 -0500 To: "Adrian Farrel" From: Lou Berger Subject: Re: Fw: I-D ACTION:draft-berger-gmpls-egress-control-01.txt Cc: In-Reply-To: <0f6901c3e202$5736d890$715708c3@Puppy> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Adrian, oh well, I asked for notification to be sent to the list. I was thinking of this as an individual draft, but you are probably right that it should go through WG review as it clarifies a protocol produced by the group. Moving it forward as a BCP probably is the right call... Thanks for forwarding the announcement. Lou At 05:43 PM 1/23/2004, Adrian Farrel wrote: >All, > >I didn't see notification of this to the list, but it sure is relevant. > >Would appreciate review input from everyone, but especially those who were >not clear about >how/whether GMPLS supported egress port/label control. > >Also, can you think about whether this draft should be run through the WG. > >Thanks, >Adrian > >----- Original Message ----- >From: >To: >Sent: Friday, January 23, 2004 8:59 PM >Subject: I-D ACTION:draft-berger-gmpls-egress-control-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : GMPLS Signaling Procedure For Egress Control > > Author(s) : L. Berger > > Filename : draft-berger-gmpls-egress-control-01.txt > > Pages : 5 > > Date : 2004-1-23 > > > > This note clarifies the procedures for the control of a label used on > > an egress output/downstream interface. Such control is also know and > > 'Egress Control'. Support for Egress Control is implicit in > > Generalized Multi-Protocol Label Switching (GMPLS) Signaling > > [RFC3471] and [RFC3473]. This note does not modify GMPLS signaling > > mechanisms and procedures and should be viewed as an informative > > clarification of [RFC3473]. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt > > > > > To remove yourself from the IETF Announcement list, send a message to > > ietf-announce-request with the word unsubscribe in the body of the > message. > > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-berger-gmpls-egress-control-01.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-berger-gmpls-egress-control-01.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > From owner-ccamp@ops.ietf.org Tue Jan 27 15:45:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22816 for ; Tue, 27 Jan 2004 15:45:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ala4z-0005vw-00 for ccamp-archive@ietf.org; Tue, 27 Jan 2004 15:45:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ala41-0005t8-00 for ccamp-archive@ietf.org; Tue, 27 Jan 2004 15:44:02 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Ala3f-0005q6-00 for ccamp-archive@ietf.org; Tue, 27 Jan 2004 15:43:39 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlZbo-000FRB-55 for ccamp-data@psg.com; Tue, 27 Jan 2004 20:14:52 +0000 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlZbc-000FQ6-Ee for ccamp@ops.ietf.org; Tue, 27 Jan 2004 20:14:40 +0000 Date: Tue, 27 Jan 2004 12:13:58 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <118482351094.20040127121358@psg.com> To: ccamp@ops.ietf.org Subject: Regarding IANA allocations for ietf-ccamp-gmpls-sonet-sdh MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks- I haven't been successful in getting the secretariat to send the IESG message on the subj to the right recipients, so I am forwarding the original of the IESG statement that we agreed on Thursday last week. I believe IANA guys already made necessary corrections in the registry. On a related topic, we're working with the WG chairs on the long-term solutions to the problem. Ideas should be documented in an I-D soon. Cheers. -- Alex Zinin > From: iesg@ietf.org > To: iana@iana.org > Cc: ccamp@ops.ietf.org > Subject: IESG on IANA allocations for ietf-ccamp-gmpls-sonet-sdh > > The IESG has reviewed the situation with RSVP C-Type allocations > performed for ietf-ccamp-gmpls-sonet-sdh by IANA (see [1] for more > information). The IESG recommends that IANA allocates C-Type value 4 > in the FLOWSPEC and SENDER_TSPEC ranges for this document, and marks > value 3 in these ranges as "deprecated". > > Note well: this does not set a precedent for IESG support of changing > IANA allocations based on implementation circumstances. > > The IESG also requests that CCAMP WG takes on the effort of reviewing > the situation and takes measures to prevent similar problems from > happening in the future. > > [1] IESG, "Short Last Call: IANA allocations for > ietf-ccamp-gmpls-sonet-sdh", 19 Jan 2004, e-mail message, > http://www1.ietf.org/mail-archive/ietf-announce/Current/msg28014.html From owner-ccamp@ops.ietf.org Tue Jan 27 16:14:55 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24648 for ; Tue, 27 Jan 2004 16:14:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlaXw-0000y0-00 for ccamp-archive@ietf.org; Tue, 27 Jan 2004 16:14:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlaX1-0000vn-00 for ccamp-archive@ietf.org; Tue, 27 Jan 2004 16:14:00 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AlaWi-0000tK-00 for ccamp-archive@ietf.org; Tue, 27 Jan 2004 16:13:40 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ala1j-000IKQ-Bi for ccamp-data@psg.com; Tue, 27 Jan 2004 20:41:39 +0000 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ala1X-000IIb-3A; Tue, 27 Jan 2004 20:41:27 +0000 Date: Tue, 27 Jan 2004 12:40:39 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <194483952647.20040127124039@psg.com> To: Ben Mack-Crane CC: ccamp@ops.ietf.org Subject: Re: Regarding IANA allocations for ietf-ccamp-gmpls-sonet-sdh In-Reply-To: <4016CB76.8020103@tellabs.com> References: <118482351094.20040127121358@psg.com> <4016CB76.8020103@tellabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Ben, [cc'ing the ccamp list] Yup. I checked the TSPEC right after I hit the send button. I'm following up with IANA already. -- Alex Tuesday, January 27, 2004, 12:35:03 PM, Ben Mack-Crane wrote: > Alex, > I just checked the IANA website and found the following: > 9 FLOWSPEC [RFC2205] > Class Types or C-Types: > 1 Reserved [RFC2205] > 2 Int-serv Flowspec [RFC2210] > 3 Deprecated [IESG] > 4 SONET/SDH FLOWSPEC [RFC-ietf-ccamp-gmpls-sonet-sdh-08.txt] > ... > 12 SENDER_TSPEC [RFC2205] > Class Types or C-Types: > 2 Int-serv [RFC2210] > 3 SONET/SDH SENDER_TSPEC [RFC-ietf-ccamp-gmpls-sonet-sdh-08.txt] > It looks like the FLOWSPEC is changed but the TSPEC is not. So there > may be a bit of fixing yet to do. > Regards, > Ben > Alex Zinin wrote: >>Folks- >> >> I haven't been successful in getting the secretariat to send the IESG >> message on the subj to the right recipients, so I am forwarding the >> original of the IESG statement that we agreed on Thursday last week. >> I believe IANA guys already made necessary corrections in the >> registry. >> >> On a related topic, we're working with the WG chairs on the long-term >> solutions to the problem. Ideas should be documented in an I-D soon. >> >> Cheers. From owner-ccamp@ops.ietf.org Tue Jan 27 18:37:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00157 for ; Tue, 27 Jan 2004 18:37:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlclX-0002LW-00 for ccamp-archive@ietf.org; Tue, 27 Jan 2004 18:37:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alckc-0002IO-00 for ccamp-archive@ietf.org; Tue, 27 Jan 2004 18:36:11 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AlckH-0002Eq-00 for ccamp-archive@ietf.org; Tue, 27 Jan 2004 18:35:49 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlcPG-0006wj-3b for ccamp-data@psg.com; Tue, 27 Jan 2004 23:14:06 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlcP3-0006vp-Q7 for ccamp@ops.ietf.org; Tue, 27 Jan 2004 23:13:53 +0000 Received: from localhost by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29392; Tue, 27 Jan 2004 18:13:49 -0500 (EST) Date: Tue, 27 Jan 2004 18:13:48 -0500 (EST) From: IESG Secretary X-X-Sender: amyk@ietf.org To: iana@iana.org cc: ccamp@ops.ietf.org, , Subject: IESG on IANA allocations for ietf-ccamp-gmpls-sonet-sdh Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 The IESG has reviewed the situation with RSVP C-Type allocations performed for ietf-ccamp-gmpls-sonet-sdh by IANA (see [1] for more information). The IESG recommends that IANA allocates C-Type value 4 in the FLOWSPEC and SENDER_TSPEC ranges for this document, and marks value 3 in these ranges as "deprecated". Note well: this does not set a precedent for IESG support of changing IANA allocations based on implementation circumstances. The IESG also requests that CCAMP WG takes on the effort of reviewing the situation and takes measures to prevent similar problems from happening in the future. [1] IESG, "Short Last Call: IANA allocations for ietf-ccamp-gmpls-sonet-sdh", 19 Jan 2004, e-mail message, http://www1.ietf.org/mail-archive/ietf-announce/Current/msg28014.html From owner-ccamp@ops.ietf.org Wed Jan 28 11:35:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08641 for ; Wed, 28 Jan 2004 11:35:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlsfI-0001oc-00 for ccamp-archive@ietf.org; Wed, 28 Jan 2004 11:35:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alsdq-0001Uj-00 for ccamp-archive@ietf.org; Wed, 28 Jan 2004 11:34:14 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AlscT-0001E2-00 for ccamp-archive@ietf.org; Wed, 28 Jan 2004 11:32:50 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlsCk-000NWF-2d for ccamp-data@psg.com; Wed, 28 Jan 2004 16:06:14 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlsCW-000NRx-8f for ccamp@ops.ietf.org; Wed, 28 Jan 2004 16:06:00 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06204; Wed, 28 Jan 2004 11:05:56 -0500 (EST) Message-Id: <200401281605.LAA06204@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt Date: Wed, 28 Jan 2004 11:05:56 -0500 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS (GMPLS) RSVP-TE Signalling in support of Automatically Switched Optical Network (ASON) Author(s) : J. Drake Filename : draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt Pages : 41 Date : 2004-1-27 This document specifies how Generalized MPLS (GMPLS) RSVP-TE signaling may be used and extended to satisfy the requirements of the Automatically Switched Optical Network (ASON) architecture specified by the ITU-T. The requirements are in a companion document 'Requirements for Generalized MPLS (GMPLS) Usage and Extensions for Automatically Switched Optical Network (ASON).' In particular, this document details the mechanisms for setting up Soft Permanent Connections (SPC), the necessary extensions in delivering full and logical call/connection separation support, the extended restart capabilities during control plane failures, extended label usage and crankback signalling capability. The mechanisms proposed in the present document are applicable to any environment (including multi-area) and for any type of interface: packet, layer-2, time-division multiplexed, lambda or fiber switching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-28112555.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-28112555.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Wed Jan 28 11:40:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09569 for ; Wed, 28 Jan 2004 11:40:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlskG-0002lG-00 for ccamp-archive@ietf.org; Wed, 28 Jan 2004 11:40:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlsjC-0002Y3-00 for ccamp-archive@ietf.org; Wed, 28 Jan 2004 11:39:47 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AlsiH-0002Mr-00 for ccamp-archive@ietf.org; Wed, 28 Jan 2004 11:38:49 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlsCw-000NY1-46 for ccamp-data@psg.com; Wed, 28 Jan 2004 16:06:26 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlsCb-000NVZ-KW for ccamp@ops.ietf.org; Wed, 28 Jan 2004 16:06:05 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06221; Wed, 28 Jan 2004 11:06:02 -0500 (EST) Message-Id: <200401281606.LAA06221@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-terminology-03.txt Date: Wed, 28 Jan 2004 11:06:01 -0500 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Recovery (Protection and Restoration) Terminology for GMPLS Author(s) : E. Mannie, D. Papadimitriou Filename : draft-ietf-ccamp-gmpls-recovery-terminology-03.txt Pages : 20 Date : 2004-1-27 This document defines a common terminology for Generalized Multi- Protocol Label Switching (GMPLS) based recovery mechanisms (i.e. protection and restoration) that are under consideration by the CCAMP Working Group. The proposed terminology is intended to be independent of the underlying transport technologies covered by GMPLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-recovery-terminology-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-28112604.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-terminology-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-28112604.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Wed Jan 28 19:30:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09125 for ; Wed, 28 Jan 2004 19:30:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Am054-0001j1-00 for ccamp-archive@ietf.org; Wed, 28 Jan 2004 19:30:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Am047-0001dj-00 for ccamp-archive@ietf.org; Wed, 28 Jan 2004 19:29:51 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Am039-0001YN-00 for ccamp-archive@ietf.org; Wed, 28 Jan 2004 19:28:51 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Alzhp-000BGz-RD for ccamp-data@psg.com; Thu, 29 Jan 2004 00:06:49 +0000 Received: from [195.8.69.103] (helo=cerberus.uk.clara.net) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Alzhd-000BFY-0T for ccamp@ops.ietf.org; Thu, 29 Jan 2004 00:06:37 +0000 Received: from du-069-0024.access.clara.net ([217.158.132.24] helo=Puppy) by cerberus.uk.clara.net with smtp (Exim 4.22) id 1Alzhb-000D1P-ED for ccamp@ops.ietf.org; Thu, 29 Jan 2004 00:06:35 +0000 Message-ID: <017a01c3e5fb$c2d18990$b8849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Requests for agenda slots Date: Thu, 29 Jan 2004 00:03:41 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit OK folks, Time to start requesting agenda slots. Please mail to me and Kireeti. Make the Subject line start with AGENDA: Please state the name and version number of the draft. Please suggest how long you need to describe progress and plans, and hear questions. Recall - you are not presenting your drafts! Authors of new drafts would be well advised to ensure that their draft clearly falls within the charter. The best way to do this is to write a summary section that highlights the line items in the charter that your draft addresses.. Have a look at draft-ietf-ccamp-crankback-00.txt if you need a model. Authors/editors of working group drafts can expect to be prodded by me for contributions. Thanks, Adrian From owner-ccamp@ops.ietf.org Thu Jan 29 11:34:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00197 for ; Thu, 29 Jan 2004 11:34:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmF7d-0005fm-00 for ccamp-archive@ietf.org; Thu, 29 Jan 2004 11:34:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmF6i-0005Z6-00 for ccamp-archive@ietf.org; Thu, 29 Jan 2004 11:33:32 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AmF68-0005Sx-00 for ccamp-archive@ietf.org; Thu, 29 Jan 2004 11:32:56 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AmEfv-0002Sn-Dd for ccamp-data@psg.com; Thu, 29 Jan 2004 16:05:51 +0000 Received: from [202.54.117.12] (helo=HQ-SMTP.vsnl.co.in) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AmEfh-0002Rl-0f for ccamp@ops.ietf.org; Thu, 29 Jan 2004 16:05:37 +0000 Received: from mail pickup service by HQ-SMTP.vsnl.co.in with Microsoft SMTPSVC; Thu, 29 Jan 2004 21:41:58 +0530 Received: from mail pickup service by HQ-SMTP.vsnl.co.in with Microsoft SMTPSVC; Thu, 29 Jan 2004 20:19:32 +0530 Received: from asgard.ietf.org ([132.151.6.40]) by HQ-SMTP.vsnl.co.in with Microsoft SMTPSVC(5.0.2195.6713); Wed, 28 Jan 2004 22:17:51 +0530 Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AlsFs-00070P-DW for ietf-announce-list@asgard.ietf.org; Wed, 28 Jan 2004 11:09:28 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AlsCc-0006pn-Fp for all-ietf@asgard.ietf.org; Wed, 28 Jan 2004 11:06:06 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06221; Wed, 28 Jan 2004 11:06:02 -0500 (EST) Message-Id: <200401281606.LAA06221@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-terminology-03.txt Date: Wed, 28 Jan 2004 11:06:01 -0500 X-OriginalArrivalTime: 28 Jan 2004 16:47:53.0328 (UTC) FILETIME=[7902CF00:01C3E5BE] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Recovery (Protection and Restoration) Terminology for GMPLS Author(s) : E. Mannie, D. Papadimitriou Filename : draft-ietf-ccamp-gmpls-recovery-terminology-03.txt Pages : 20 Date : 2004-1-27 This document defines a common terminology for Generalized Multi- Protocol Label Switching (GMPLS) based recovery mechanisms (i.e. protection and restoration) that are under consideration by the CCAMP Working Group. The proposed terminology is intended to be independent of the underlying transport technologies covered by GMPLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-recovery-terminology-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-28112604.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-terminology-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-28112604.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Thu Jan 29 14:16:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09648 for ; Thu, 29 Jan 2004 14:16:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmHeW-0003A5-00 for ccamp-archive@ietf.org; Thu, 29 Jan 2004 14:16:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmHdV-00034h-00 for ccamp-archive@ietf.org; Thu, 29 Jan 2004 14:15:34 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AmHd4-0002zC-00 for ccamp-archive@ietf.org; Thu, 29 Jan 2004 14:15:06 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AmHIF-0002ll-LH for ccamp-data@psg.com; Thu, 29 Jan 2004 18:53:35 +0000 Received: from [202.54.117.12] (helo=HQ-SMTP.vsnl.co.in) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AmHHj-0002hp-Et for ccamp@ops.ietf.org; Thu, 29 Jan 2004 18:53:03 +0000 Received: from mail pickup service by HQ-SMTP.vsnl.co.in with Microsoft SMTPSVC; Fri, 30 Jan 2004 00:29:25 +0530 Received: from asgard.ietf.org ([132.151.6.40]) by HQ-SMTP.vsnl.co.in with Microsoft SMTPSVC(5.0.2195.6713); Wed, 28 Jan 2004 22:19:43 +0530 Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AlsFs-00070I-91 for ietf-announce-list@asgard.ietf.org; Wed, 28 Jan 2004 11:09:28 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AlsCX-0006pU-Bi for all-ietf@asgard.ietf.org; Wed, 28 Jan 2004 11:06:01 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06204; Wed, 28 Jan 2004 11:05:56 -0500 (EST) Message-Id: <200401281605.LAA06204@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt Date: Wed, 28 Jan 2004 11:05:56 -0500 X-OriginalArrivalTime: 28 Jan 2004 16:49:45.0546 (UTC) FILETIME=[BBE5EAA0:01C3E5BE] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS (GMPLS) RSVP-TE Signalling in support of Automatically Switched Optical Network (ASON) Author(s) : J. Drake Filename : draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt Pages : 41 Date : 2004-1-27 This document specifies how Generalized MPLS (GMPLS) RSVP-TE signaling may be used and extended to satisfy the requirements of the Automatically Switched Optical Network (ASON) architecture specified by the ITU-T. The requirements are in a companion document 'Requirements for Generalized MPLS (GMPLS) Usage and Extensions for Automatically Switched Optical Network (ASON).' In particular, this document details the mechanisms for setting up Soft Permanent Connections (SPC), the necessary extensions in delivering full and logical call/connection separation support, the extended restart capabilities during control plane failures, extended label usage and crankback signalling capability. The mechanisms proposed in the present document are applicable to any environment (including multi-area) and for any type of interface: packet, layer-2, time-division multiplexed, lambda or fiber switching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-28112555.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-28112555.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Fri Jan 30 10:35:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22271 for ; Fri, 30 Jan 2004 10:35:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amafu-0003ce-00 for ccamp-archive@ietf.org; Fri, 30 Jan 2004 10:35:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amaf7-0003W3-00 for ccamp-archive@ietf.org; Fri, 30 Jan 2004 10:34:30 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Amaeg-0003OO-00 for ccamp-archive@ietf.org; Fri, 30 Jan 2004 10:34:03 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ama9g-000DSp-2c for ccamp-data@psg.com; Fri, 30 Jan 2004 15:02:00 +0000 Received: from [65.205.166.188] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ama9G-000DIu-Up for ccamp@ops.ietf.org; Fri, 30 Jan 2004 15:01:35 +0000 Received: from lb-laptop.movaz.com (kenaz.atlanta.movaz.com [172.16.8.184]) by jera.movaz.com (Postfix) with ESMTP id 8611F13B41; Fri, 30 Jan 2004 10:01:33 -0500 (EST) Message-Id: <4.3.2.7.2.20040130092632.03e9af00@mo-ex1> X-Sender: lb@mo-ex1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 30 Jan 2004 10:01:14 -0500 To: "Tom Petch" , "Randy Presuhn" From: Lou Berger Subject: disman MIB Followup on gmpls-alarm-spec- Cc: "Wijnen, Bert (Bert)" , In-Reply-To: <002801c3aeb2$64db2100$0301a8c0@tom3> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Tom, (Randy) Thank you for providing this input. What we're looking for is a reference that provides enumerated values for alarms. The ITU specs that we found all provide text strings, which is what we're trying to avoid. It seems that the disman MIB provides exactly what we're looking for. Please let us know if our intended use of the values defined in the MIB makes sense from your (disman WG's) perspective, or if you recommend an alternate approach. Thank you, Lou PS The text in the new rev (submitted today) of the draft reads: [from: http://labn.net/docs/draft-berger-ccamp-gmpls-alarm-spec-01.txt] 3.1.3. Error Codes and Values The Error Codes and Values used in ALARM_SPEC objects are the same as those used in ERROR_SPEC objects. New Error Code values for use with both ERROR_SPEC and ALARM_SPEC objects may be assigned to support alarm types defined by other standards. In this document we define one new Error Code. The Error Code uses the value TBA (by IANA) and is referred to as "Alarms". The values used in the Error Values field are the same as the values used for IANAItuProbableCause in the Alarm MIB [ALARM-MIB]. The error values field is carried in an object with the format: [from: rfc3473] 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num (6) | C-Type (3) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Error Node Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Error Code | Error Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ At 10:20 AM 11/19/2003, Tom Petch wrote: >FYI > > >As a member of the disman WG, I have followed the development of the alarm >mib, >currently draft-ietf-disman-alarm-mib-15.txt, over some years and this has >included formal liaison with SG4 and some contact with SG15 over such >issues as >who owns the code points and who can define them. SG4 have expressed >satisfaction with the way in which the liaison with disman WG has worked >(as on >the IETF web site). > >But > >1) not knowing the working procedures of the ITU, I don't know if the >agreement >with disman extends to other IETF WG - the wording suggests not to me. > >2) the alarm mib is currently under debate between authors and WG chair with a >list of some 80 issues being resolved; the most difficult to resolve >appear IMO >to be the ones relating to the existence of the ITU alarm table as an >augmentation of the basic disman alarm table (and perhaps IMHO the lack of >suitable features in SMIv2). The alarm mib is complex, not one I would expect >people to be able to dip into and readily extract a part thereof. > >3) I have lost track of the start of this thread and just what it was that >this, >ccamp, WG >wanted to include in what (and my Acrobat viewer renders the text of the >bullet >points in AlarmSpec as black blobs of varying size:-(! But whatever it is, I >suggest you contact the >disman chair, randy presuhn, to clarify the niceties of any interaction >with the >output of disman, whatever form that finally takes. It may be that M.3100 >related material should be in a common MIB module and not included in the >alarm >mib because of issues of future updates and cross references from multiple >WGs.. > >I think this is known as cross-functional review:-) > >Tom Petch > > >-----Original Message----- >From: Wijnen, Bert (Bert) >To: Brungard, Deborah A, ALABS ; Wijnen, Bert (Bert) >; Adrian Farrel ; Lou Berger > >Cc: ccamp@ops.ietf.org >Date: 18 November 2003 23:10 >Subject: RE: Taking to the list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > > >the disman mib has enumerations I believe! > > > >Thanks, > >Bert > > > >> -----Original Message----- > >> From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] > >> Sent: dinsdag 18 november 2003 23:06 > >> To: Wijnen, Bert (Bert); Adrian Farrel; Lou Berger > >> Cc: ccamp@ops.ietf.org > >> Subject: RE: Taking to the > >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > >> > >> > >> Thanks Bert. > >> > >> M.3100 provides the generic information model, X.733 and > >> X.736 define OSI generics pointing to X.721, and X.721 > >> provides abstract syntax. We were looking for an enumeration > >> to use vs. needing to support abstract syntax strings in > >> signaling. Any suggestions are welcome. > >> Deborah > >> > >> -----Original Message----- > >> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > >> Sent: Tuesday, November 11, 2003 11:46 AM > >> To: Adrian Farrel; Lou Berger > >> Cc: ccamp@ops.ietf.org > >> Subject: RE: Taking to the > >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > >> > >> > >> Things to potentially look at: > >> > >> draft-ietf-disman-alarm-mib-15.txt > >> > >> [M.3100] ITU Recommendation M.3100, "Generic Network Information > >> Model", 1995 > >> > >> [X.733] ITU Recommendation X.733, "Information Technology - Open > >> Systems Interconnection - System Management: Alarm > >> Reporting Function", 1992 > >> > >> [X.736] ITU Recommendation X.736, "Information Technology - Open > >> Systems Interconnection - System Management: Security > >> Alarm Reporting Function", 1992 > >> > >> Thanks, > >> Bert > >> > >> > -----Original Message----- > >> > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > >> > Sent: dinsdag 11 november 2003 17:28 > >> > To: Lou Berger > >> > Cc: ccamp@ops.ietf.org > >> > Subject: Re: Taking to the > >> > list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > >> > > >> > > >> > Lou, > >> > > >> > I believe the alarm reference was M.3100. > >> > > >> > Can someone confirm? > >> > > >> > Adrian > >> > > >> > > >> > > In the morning's meeting the AD's asked to bring the > >> proposed Alarm > >> > > communication extension to "the list". For today's > >> > presentation see: > >> > > http://www.labn.net/docs/AlarmSpec00.pdf > >> > > > >> > > I believe the issues to be discussed are: > >> > > 1) Is there general interest in this work? > >> > > 2) Should the usage of new TLVs in Error_Spec be permitted? > >> > > (We think there's some value, particularly with string > >> > > and timestamp) > >> > > 3) Are there good references for alarm code points? > >> > > > >> > > Thank, > >> > > Lou (and co-authors) > >> > > >> > > >> > > From owner-ccamp@ops.ietf.org Fri Jan 30 19:41:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03193 for ; Fri, 30 Jan 2004 19:41:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmjCf-0003kt-00 for ccamp-archive@ietf.org; Fri, 30 Jan 2004 19:41:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmjBo-0003bp-00 for ccamp-archive@ietf.org; Fri, 30 Jan 2004 19:40:49 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AmjAx-0003T1-00 for ccamp-archive@ietf.org; Fri, 30 Jan 2004 19:39:55 -0500 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Amik0-000HxY-TW for ccamp-data@psg.com; Sat, 31 Jan 2004 00:12:04 +0000 Received: from [192.11.223.163] (helo=auemail2.firewall.lucent.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Amijh-000Hvx-5p for ccamp@ops.ietf.org; Sat, 31 Jan 2004 00:11:45 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i0V0BfJ13421 for ; Fri, 30 Jan 2004 18:11:41 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sat, 31 Jan 2004 01:11:40 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC4A2@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Lou Berger'" , Tom Petch , Randy Presuhn Cc: "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org Subject: RE: disman MIB Followup on gmpls-alarm-spec- Date: Sat, 31 Jan 2004 01:11:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 TO me this looks fine Thanks, Bert > -----Original Message----- > From: Lou Berger [mailto:lberger@movaz.com] > Sent: vrijdag 30 januari 2004 16:01 > To: Tom Petch; Randy Presuhn > Cc: Wijnen, Bert (Bert); ccamp@ops.ietf.org > Subject: disman MIB Followup on gmpls-alarm-spec- > > > Tom, (Randy) > > Thank you for providing this input. What we're > looking for is a > reference that provides enumerated values for alarms. The > ITU specs that > we found all provide text strings, which is what we're trying > to avoid. It > seems that the disman MIB provides exactly what we're looking for. > > Please let us know if our intended use of the values defined > in the MIB > makes sense from your (disman WG's) perspective, or if you > recommend an > alternate approach. > > Thank you, > Lou > > PS The text in the new rev (submitted today) of the draft reads: > [from: > http://labn.net/docs/draft-berger-ccamp-gmpls-alarm-spec-01.txt] > 3.1.3. Error Codes and Values > > The Error Codes and Values used in ALARM_SPEC objects are > the same as > those used in ERROR_SPEC objects. New Error Code values > for use with > both ERROR_SPEC and ALARM_SPEC objects may be assigned to support > alarm types defined by other standards. > > In this document we define one new Error Code. The Error > Code uses > the value TBA (by IANA) and is referred to as "Alarms". > The values > used in the Error Values field are the same as the values used for > IANAItuProbableCause in the Alarm MIB [ALARM-MIB]. > > The error values field is carried in an object with the format: > [from: rfc3473] > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length | Class-Num (6) | C-Type (3) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv4 Error Node Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Flags | Error Code | Error Value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ TLVs ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > At 10:20 AM 11/19/2003, Tom Petch wrote: > >FYI > > > > > >As a member of the disman WG, I have followed the > development of the alarm > >mib, > >currently draft-ietf-disman-alarm-mib-15.txt, over some > years and this has > >included formal liaison with SG4 and some contact with SG15 > over such > >issues as > >who owns the code points and who can define them. SG4 have expressed > >satisfaction with the way in which the liaison with disman > WG has worked > >(as on > >the IETF web site). > > > >But > > > >1) not knowing the working procedures of the ITU, I don't > know if the > >agreement > >with disman extends to other IETF WG - the wording suggests > not to me. > > > >2) the alarm mib is currently under debate between authors > and WG chair with a > >list of some 80 issues being resolved; the most difficult to resolve > >appear IMO > >to be the ones relating to the existence of the ITU alarm table as an > >augmentation of the basic disman alarm table (and perhaps > IMHO the lack of > >suitable features in SMIv2). The alarm mib is complex, not > one I would expect > >people to be able to dip into and readily extract a part thereof. > > > >3) I have lost track of the start of this thread and just > what it was that > >this, > >ccamp, WG > >wanted to include in what (and my Acrobat viewer renders the > text of the > >bullet > >points in AlarmSpec as black blobs of varying size:-(! But > whatever it is, I > >suggest you contact the > >disman chair, randy presuhn, to clarify the niceties of any > interaction > >with the > >output of disman, whatever form that finally takes. It may > be that M.3100 > >related material should be in a common MIB module and not > included in the > >alarm > >mib because of issues of future updates and cross references > from multiple > >WGs.. > > > >I think this is known as cross-functional review:-) > > > >Tom Petch > > > > > >-----Original Message----- > >From: Wijnen, Bert (Bert) > >To: Brungard, Deborah A, ALABS ; Wijnen, > Bert (Bert) > >; Adrian Farrel ; Lou Berger > > > >Cc: ccamp@ops.ietf.org > >Date: 18 November 2003 23:10 > >Subject: RE: Taking to the > list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > > > > > >the disman mib has enumerations I believe! > > > > > >Thanks, > > >Bert > > > > > >> -----Original Message----- > > >> From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] > > >> Sent: dinsdag 18 november 2003 23:06 > > >> To: Wijnen, Bert (Bert); Adrian Farrel; Lou Berger > > >> Cc: ccamp@ops.ietf.org > > >> Subject: RE: Taking to the > > >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > >> > > >> > > >> Thanks Bert. > > >> > > >> M.3100 provides the generic information model, X.733 and > > >> X.736 define OSI generics pointing to X.721, and X.721 > > >> provides abstract syntax. We were looking for an enumeration > > >> to use vs. needing to support abstract syntax strings in > > >> signaling. Any suggestions are welcome. > > >> Deborah > > >> > > >> -----Original Message----- > > >> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > >> Sent: Tuesday, November 11, 2003 11:46 AM > > >> To: Adrian Farrel; Lou Berger > > >> Cc: ccamp@ops.ietf.org > > >> Subject: RE: Taking to the > > >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > >> > > >> > > >> Things to potentially look at: > > >> > > >> draft-ietf-disman-alarm-mib-15.txt > > >> > > >> [M.3100] ITU Recommendation M.3100, "Generic > Network Information > > >> Model", 1995 > > >> > > >> [X.733] ITU Recommendation X.733, "Information > Technology - Open > > >> Systems Interconnection - System Management: Alarm > > >> Reporting Function", 1992 > > >> > > >> [X.736] ITU Recommendation X.736, "Information > Technology - Open > > >> Systems Interconnection - System > Management: Security > > >> Alarm Reporting Function", 1992 > > >> > > >> Thanks, > > >> Bert > > >> > > >> > -----Original Message----- > > >> > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > >> > Sent: dinsdag 11 november 2003 17:28 > > >> > To: Lou Berger > > >> > Cc: ccamp@ops.ietf.org > > >> > Subject: Re: Taking to the > > >> > list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > >> > > > >> > > > >> > Lou, > > >> > > > >> > I believe the alarm reference was M.3100. > > >> > > > >> > Can someone confirm? > > >> > > > >> > Adrian > > >> > > > >> > > > >> > > In the morning's meeting the AD's asked to bring the > > >> proposed Alarm > > >> > > communication extension to "the list". For today's > > >> > presentation see: > > >> > > http://www.labn.net/docs/AlarmSpec00.pdf > > >> > > > > >> > > I believe the issues to be discussed are: > > >> > > 1) Is there general interest in this work? > > >> > > 2) Should the usage of new TLVs in Error_Spec be permitted? > > >> > > (We think there's some value, particularly > with string > > >> > > and timestamp) > > >> > > 3) Are there good references for alarm code points? > > >> > > > > >> > > Thank, > > >> > > Lou (and co-authors) > > >> > > > >> > > > >> > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 31 Jan 2004 00:13:57 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC4A2@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Lou Berger'" , Tom Petch , Randy Presuhn Cc: "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org Subject: RE: disman MIB Followup on gmpls-alarm-spec- Date: Sat, 31 Jan 2004 01:11:38 +0100 MIME-Version: 1.0 Content-Type: text/plain TO me this looks fine Thanks, Bert > -----Original Message----- > From: Lou Berger [mailto:lberger@movaz.com] > Sent: vrijdag 30 januari 2004 16:01 > To: Tom Petch; Randy Presuhn > Cc: Wijnen, Bert (Bert); ccamp@ops.ietf.org > Subject: disman MIB Followup on gmpls-alarm-spec- > > > Tom, (Randy) > > Thank you for providing this input. What we're > looking for is a > reference that provides enumerated values for alarms. The > ITU specs that > we found all provide text strings, which is what we're trying > to avoid. It > seems that the disman MIB provides exactly what we're looking for. > > Please let us know if our intended use of the values defined > in the MIB > makes sense from your (disman WG's) perspective, or if you > recommend an > alternate approach. > > Thank you, > Lou > > PS The text in the new rev (submitted today) of the draft reads: > [from: > http://labn.net/docs/draft-berger-ccamp-gmpls-alarm-spec-01.txt] > 3.1.3. Error Codes and Values > > The Error Codes and Values used in ALARM_SPEC objects are > the same as > those used in ERROR_SPEC objects. New Error Code values > for use with > both ERROR_SPEC and ALARM_SPEC objects may be assigned to support > alarm types defined by other standards. > > In this document we define one new Error Code. The Error > Code uses > the value TBA (by IANA) and is referred to as "Alarms". > The values > used in the Error Values field are the same as the values used for > IANAItuProbableCause in the Alarm MIB [ALARM-MIB]. > > The error values field is carried in an object with the format: > [from: rfc3473] > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length | Class-Num (6) | C-Type (3) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv4 Error Node Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Flags | Error Code | Error Value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ TLVs ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > At 10:20 AM 11/19/2003, Tom Petch wrote: > >FYI > > > > > >As a member of the disman WG, I have followed the > development of the alarm > >mib, > >currently draft-ietf-disman-alarm-mib-15.txt, over some > years and this has > >included formal liaison with SG4 and some contact with SG15 > over such > >issues as > >who owns the code points and who can define them. SG4 have expressed > >satisfaction with the way in which the liaison with disman > WG has worked > >(as on > >the IETF web site). > > > >But > > > >1) not knowing the working procedures of the ITU, I don't > know if the > >agreement > >with disman extends to other IETF WG - the wording suggests > not to me. > > > >2) the alarm mib is currently under debate between authors > and WG chair with a > >list of some 80 issues being resolved; the most difficult to resolve > >appear IMO > >to be the ones relating to the existence of the ITU alarm table as an > >augmentation of the basic disman alarm table (and perhaps > IMHO the lack of > >suitable features in SMIv2). The alarm mib is complex, not > one I would expect > >people to be able to dip into and readily extract a part thereof. > > > >3) I have lost track of the start of this thread and just > what it was that > >this, > >ccamp, WG > >wanted to include in what (and my Acrobat viewer renders the > text of the > >bullet > >points in AlarmSpec as black blobs of varying size:-(! But > whatever it is, I > >suggest you contact the > >disman chair, randy presuhn, to clarify the niceties of any > interaction > >with the > >output of disman, whatever form that finally takes. It may > be that M.3100 > >related material should be in a common MIB module and not > included in the > >alarm > >mib because of issues of future updates and cross references > from multiple > >WGs.. > > > >I think this is known as cross-functional review:-) > > > >Tom Petch > > > > > >-----Original Message----- > >From: Wijnen, Bert (Bert) > >To: Brungard, Deborah A, ALABS ; Wijnen, > Bert (Bert) > >; Adrian Farrel ; Lou Berger > > > >Cc: ccamp@ops.ietf.org > >Date: 18 November 2003 23:10 > >Subject: RE: Taking to the > list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > > > > > >the disman mib has enumerations I believe! > > > > > >Thanks, > > >Bert > > > > > >> -----Original Message----- > > >> From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] > > >> Sent: dinsdag 18 november 2003 23:06 > > >> To: Wijnen, Bert (Bert); Adrian Farrel; Lou Berger > > >> Cc: ccamp@ops.ietf.org > > >> Subject: RE: Taking to the > > >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > >> > > >> > > >> Thanks Bert. > > >> > > >> M.3100 provides the generic information model, X.733 and > > >> X.736 define OSI generics pointing to X.721, and X.721 > > >> provides abstract syntax. We were looking for an enumeration > > >> to use vs. needing to support abstract syntax strings in > > >> signaling. Any suggestions are welcome. > > >> Deborah > > >> > > >> -----Original Message----- > > >> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > >> Sent: Tuesday, November 11, 2003 11:46 AM > > >> To: Adrian Farrel; Lou Berger > > >> Cc: ccamp@ops.ietf.org > > >> Subject: RE: Taking to the > > >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > >> > > >> > > >> Things to potentially look at: > > >> > > >> draft-ietf-disman-alarm-mib-15.txt > > >> > > >> [M.3100] ITU Recommendation M.3100, "Generic > Network Information > > >> Model", 1995 > > >> > > >> [X.733] ITU Recommendation X.733, "Information > Technology - Open > > >> Systems Interconnection - System Management: Alarm > > >> Reporting Function", 1992 > > >> > > >> [X.736] ITU Recommendation X.736, "Information > Technology - Open > > >> Systems Interconnection - System > Management: Security > > >> Alarm Reporting Function", 1992 > > >> > > >> Thanks, > > >> Bert > > >> > > >> > -----Original Message----- > > >> > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > >> > Sent: dinsdag 11 november 2003 17:28 > > >> > To: Lou Berger > > >> > Cc: ccamp@ops.ietf.org > > >> > Subject: Re: Taking to the > > >> > list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > >> > > > >> > > > >> > Lou, > > >> > > > >> > I believe the alarm reference was M.3100. > > >> > > > >> > Can someone confirm? > > >> > > > >> > Adrian > > >> > > > >> > > > >> > > In the morning's meeting the AD's asked to bring the > > >> proposed Alarm > > >> > > communication extension to "the list". For today's > > >> > presentation see: > > >> > > http://www.labn.net/docs/AlarmSpec00.pdf > > >> > > > > >> > > I believe the issues to be discussed are: > > >> > > 1) Is there general interest in this work? > > >> > > 2) Should the usage of new TLVs in Error_Spec be permitted? > > >> > > (We think there's some value, particularly > with string > > >> > > and timestamp) > > >> > > 3) Are there good references for alarm code points? > > >> > > > > >> > > Thank, > > >> > > Lou (and co-authors) > > >> > > > >> > > > >> > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 Jan 2004 15:04:20 +0000 Message-Id: <4.3.2.7.2.20040130092632.03e9af00@mo-ex1> Date: Fri, 30 Jan 2004 10:01:14 -0500 To: "Tom Petch" , "Randy Presuhn" From: Lou Berger Subject: disman MIB Followup on gmpls-alarm-spec- Cc: "Wijnen, Bert (Bert)" , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Tom, (Randy) Thank you for providing this input. What we're looking for is a reference that provides enumerated values for alarms. The ITU specs that we found all provide text strings, which is what we're trying to avoid. It seems that the disman MIB provides exactly what we're looking for. Please let us know if our intended use of the values defined in the MIB makes sense from your (disman WG's) perspective, or if you recommend an alternate approach. Thank you, Lou PS The text in the new rev (submitted today) of the draft reads: [from: http://labn.net/docs/draft-berger-ccamp-gmpls-alarm-spec-01.txt] 3.1.3. Error Codes and Values The Error Codes and Values used in ALARM_SPEC objects are the same as those used in ERROR_SPEC objects. New Error Code values for use with both ERROR_SPEC and ALARM_SPEC objects may be assigned to support alarm types defined by other standards. In this document we define one new Error Code. The Error Code uses the value TBA (by IANA) and is referred to as "Alarms". The values used in the Error Values field are the same as the values used for IANAItuProbableCause in the Alarm MIB [ALARM-MIB]. The error values field is carried in an object with the format: [from: rfc3473] 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num (6) | C-Type (3) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Error Node Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Error Code | Error Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ At 10:20 AM 11/19/2003, Tom Petch wrote: >FYI > > >As a member of the disman WG, I have followed the development of the alarm >mib, >currently draft-ietf-disman-alarm-mib-15.txt, over some years and this has >included formal liaison with SG4 and some contact with SG15 over such >issues as >who owns the code points and who can define them. SG4 have expressed >satisfaction with the way in which the liaison with disman WG has worked >(as on >the IETF web site). > >But > >1) not knowing the working procedures of the ITU, I don't know if the >agreement >with disman extends to other IETF WG - the wording suggests not to me. > >2) the alarm mib is currently under debate between authors and WG chair with a >list of some 80 issues being resolved; the most difficult to resolve >appear IMO >to be the ones relating to the existence of the ITU alarm table as an >augmentation of the basic disman alarm table (and perhaps IMHO the lack of >suitable features in SMIv2). The alarm mib is complex, not one I would expect >people to be able to dip into and readily extract a part thereof. > >3) I have lost track of the start of this thread and just what it was that >this, >ccamp, WG >wanted to include in what (and my Acrobat viewer renders the text of the >bullet >points in AlarmSpec as black blobs of varying size:-(! But whatever it is, I >suggest you contact the >disman chair, randy presuhn, to clarify the niceties of any interaction >with the >output of disman, whatever form that finally takes. It may be that M.3100 >related material should be in a common MIB module and not included in the >alarm >mib because of issues of future updates and cross references from multiple >WGs.. > >I think this is known as cross-functional review:-) > >Tom Petch > > >-----Original Message----- >From: Wijnen, Bert (Bert) >To: Brungard, Deborah A, ALABS ; Wijnen, Bert (Bert) >; Adrian Farrel ; Lou Berger > >Cc: ccamp@ops.ietf.org >Date: 18 November 2003 23:10 >Subject: RE: Taking to the list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > > > >the disman mib has enumerations I believe! > > > >Thanks, > >Bert > > > >> -----Original Message----- > >> From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] > >> Sent: dinsdag 18 november 2003 23:06 > >> To: Wijnen, Bert (Bert); Adrian Farrel; Lou Berger > >> Cc: ccamp@ops.ietf.org > >> Subject: RE: Taking to the > >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > >> > >> > >> Thanks Bert. > >> > >> M.3100 provides the generic information model, X.733 and > >> X.736 define OSI generics pointing to X.721, and X.721 > >> provides abstract syntax. We were looking for an enumeration > >> to use vs. needing to support abstract syntax strings in > >> signaling. Any suggestions are welcome. > >> Deborah > >> > >> -----Original Message----- > >> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > >> Sent: Tuesday, November 11, 2003 11:46 AM > >> To: Adrian Farrel; Lou Berger > >> Cc: ccamp@ops.ietf.org > >> Subject: RE: Taking to the > >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > >> > >> > >> Things to potentially look at: > >> > >> draft-ietf-disman-alarm-mib-15.txt > >> > >> [M.3100] ITU Recommendation M.3100, "Generic Network Information > >> Model", 1995 > >> > >> [X.733] ITU Recommendation X.733, "Information Technology - Open > >> Systems Interconnection - System Management: Alarm > >> Reporting Function", 1992 > >> > >> [X.736] ITU Recommendation X.736, "Information Technology - Open > >> Systems Interconnection - System Management: Security > >> Alarm Reporting Function", 1992 > >> > >> Thanks, > >> Bert > >> > >> > -----Original Message----- > >> > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > >> > Sent: dinsdag 11 november 2003 17:28 > >> > To: Lou Berger > >> > Cc: ccamp@ops.ietf.org > >> > Subject: Re: Taking to the > >> > list:draft-berger-ccamp-gmpls-alarm-spec-00.txt > >> > > >> > > >> > Lou, > >> > > >> > I believe the alarm reference was M.3100. > >> > > >> > Can someone confirm? > >> > > >> > Adrian > >> > > >> > > >> > > In the morning's meeting the AD's asked to bring the > >> proposed Alarm > >> > > communication extension to "the list". For today's > >> > presentation see: > >> > > http://www.labn.net/docs/AlarmSpec00.pdf > >> > > > >> > > I believe the issues to be discussed are: > >> > > 1) Is there general interest in this work? > >> > > 2) Should the usage of new TLVs in Error_Spec be permitted? > >> > > (We think there's some value, particularly with string > >> > > and timestamp) > >> > > 3) Are there good references for alarm code points? > >> > > > >> > > Thank, > >> > > Lou (and co-authors) > >> > > >> > > >> > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Jan 2004 18:54:51 +0000 Message-Id: <200401281605.LAA06204@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt Date: Wed, 28 Jan 2004 11:05:56 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS (GMPLS) RSVP-TE Signalling in support of Automatically Switched Optical Network (ASON) Author(s) : J. Drake Filename : draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt Pages : 41 Date : 2004-1-27 This document specifies how Generalized MPLS (GMPLS) RSVP-TE signaling may be used and extended to satisfy the requirements of the Automatically Switched Optical Network (ASON) architecture specified by the ITU-T. The requirements are in a companion document 'Requirements for Generalized MPLS (GMPLS) Usage and Extensions for Automatically Switched Optical Network (ASON).' In particular, this document details the mechanisms for setting up Soft Permanent Connections (SPC), the necessary extensions in delivering full and logical call/connection separation support, the extended restart capabilities during control plane failures, extended label usage and crankback signalling capability. The mechanisms proposed in the present document are applicable to any environment (including multi-area) and for any type of interface: packet, layer-2, time-division multiplexed, lambda or fiber switching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-28112555.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-28112555.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Jan 2004 16:07:52 +0000 Message-Id: <200401281606.LAA06221@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-terminology-03.txt Date: Wed, 28 Jan 2004 11:06:01 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Recovery (Protection and Restoration) Terminology for GMPLS Author(s) : E. Mannie, D. Papadimitriou Filename : draft-ietf-ccamp-gmpls-recovery-terminology-03.txt Pages : 20 Date : 2004-1-27 This document defines a common terminology for Generalized Multi- Protocol Label Switching (GMPLS) based recovery mechanisms (i.e. protection and restoration) that are under consideration by the CCAMP Working Group. The proposed terminology is intended to be independent of the underlying transport technologies covered by GMPLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-recovery-terminology-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-28112604.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-terminology-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-28112604.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Jan 2004 00:09:07 +0000 Message-ID: <017a01c3e5fb$c2d18990$b8849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Requests for agenda slots Date: Thu, 29 Jan 2004 00:03:41 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit OK folks, Time to start requesting agenda slots. Please mail to me and Kireeti. Make the Subject line start with AGENDA: Please state the name and version number of the draft. Please suggest how long you need to describe progress and plans, and hear questions. Recall - you are not presenting your drafts! Authors of new drafts would be well advised to ensure that their draft clearly falls within the charter. The best way to do this is to write a summary section that highlights the line items in the charter that your draft addresses.. Have a look at draft-ietf-ccamp-crankback-00.txt if you need a model. Authors/editors of working group drafts can expect to be prodded by me for contributions. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 Jan 2004 16:09:19 +0000 Message-Id: <200401281606.LAA06221@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-terminology-03.txt Date: Wed, 28 Jan 2004 11:06:01 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Recovery (Protection and Restoration) Terminology for GMPLS Author(s) : E. Mannie, D. Papadimitriou Filename : draft-ietf-ccamp-gmpls-recovery-terminology-03.txt Pages : 20 Date : 2004-1-27 This document defines a common terminology for Generalized Multi- Protocol Label Switching (GMPLS) based recovery mechanisms (i.e. protection and restoration) that are under consideration by the CCAMP Working Group. The proposed terminology is intended to be independent of the underlying transport technologies covered by GMPLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-recovery-terminology-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-28112604.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-terminology-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-28112604.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 Jan 2004 16:09:03 +0000 Message-Id: <200401281605.LAA06204@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt Date: Wed, 28 Jan 2004 11:05:56 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS (GMPLS) RSVP-TE Signalling in support of Automatically Switched Optical Network (ASON) Author(s) : J. Drake Filename : draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt Pages : 41 Date : 2004-1-27 This document specifies how Generalized MPLS (GMPLS) RSVP-TE signaling may be used and extended to satisfy the requirements of the Automatically Switched Optical Network (ASON) architecture specified by the ITU-T. The requirements are in a companion document 'Requirements for Generalized MPLS (GMPLS) Usage and Extensions for Automatically Switched Optical Network (ASON).' In particular, this document details the mechanisms for setting up Soft Permanent Connections (SPC), the necessary extensions in delivering full and logical call/connection separation support, the extended restart capabilities during control plane failures, extended label usage and crankback signalling capability. The mechanisms proposed in the present document are applicable to any environment (including multi-area) and for any type of interface: packet, layer-2, time-division multiplexed, lambda or fiber switching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-28112555.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-28112555.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 27 Jan 2004 23:15:08 +0000 Date: Tue, 27 Jan 2004 18:13:48 -0500 (EST) From: IESG Secretary To: iana@iana.org cc: ccamp@ops.ietf.org, , Subject: IESG on IANA allocations for ietf-ccamp-gmpls-sonet-sdh Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The IESG has reviewed the situation with RSVP C-Type allocations performed for ietf-ccamp-gmpls-sonet-sdh by IANA (see [1] for more information). The IESG recommends that IANA allocates C-Type value 4 in the FLOWSPEC and SENDER_TSPEC ranges for this document, and marks value 3 in these ranges as "deprecated". Note well: this does not set a precedent for IESG support of changing IANA allocations based on implementation circumstances. The IESG also requests that CCAMP WG takes on the effort of reviewing the situation and takes measures to prevent similar problems from happening in the future. [1] IESG, "Short Last Call: IANA allocations for ietf-ccamp-gmpls-sonet-sdh", 19 Jan 2004, e-mail message, http://www1.ietf.org/mail-archive/ietf-announce/Current/msg28014.html Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 27 Jan 2004 20:42:23 +0000 Date: Tue, 27 Jan 2004 12:40:39 -0800 From: Alex Zinin Reply-To: Alex Zinin Message-ID: <194483952647.20040127124039@psg.com> To: Ben Mack-Crane CC: ccamp@ops.ietf.org Subject: Re: Regarding IANA allocations for ietf-ccamp-gmpls-sonet-sdh MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ben, [cc'ing the ccamp list] Yup. I checked the TSPEC right after I hit the send button. I'm following up with IANA already. -- Alex Tuesday, January 27, 2004, 12:35:03 PM, Ben Mack-Crane wrote: > Alex, > I just checked the IANA website and found the following: > 9 FLOWSPEC [RFC2205] > Class Types or C-Types: > 1 Reserved [RFC2205] > 2 Int-serv Flowspec [RFC2210] > 3 Deprecated [IESG] > 4 SONET/SDH FLOWSPEC [RFC-ietf-ccamp-gmpls-sonet-sdh-08.txt] > ... > 12 SENDER_TSPEC [RFC2205] > Class Types or C-Types: > 2 Int-serv [RFC2210] > 3 SONET/SDH SENDER_TSPEC [RFC-ietf-ccamp-gmpls-sonet-sdh-08.txt] > It looks like the FLOWSPEC is changed but the TSPEC is not. So there > may be a bit of fixing yet to do. > Regards, > Ben > Alex Zinin wrote: >>Folks- >> >> I haven't been successful in getting the secretariat to send the IESG >> message on the subj to the right recipients, so I am forwarding the >> original of the IESG statement that we agreed on Thursday last week. >> I believe IANA guys already made necessary corrections in the >> registry. >> >> On a related topic, we're working with the WG chairs on the long-term >> solutions to the problem. Ideas should be documented in an I-D soon. >> >> Cheers. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 27 Jan 2004 20:17:15 +0000 Date: Tue, 27 Jan 2004 12:13:58 -0800 From: Alex Zinin Reply-To: Alex Zinin Message-ID: <118482351094.20040127121358@psg.com> To: ccamp@ops.ietf.org Subject: Regarding IANA allocations for ietf-ccamp-gmpls-sonet-sdh MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks- I haven't been successful in getting the secretariat to send the IESG message on the subj to the right recipients, so I am forwarding the original of the IESG statement that we agreed on Thursday last week. I believe IANA guys already made necessary corrections in the registry. On a related topic, we're working with the WG chairs on the long-term solutions to the problem. Ideas should be documented in an I-D soon. Cheers. -- Alex Zinin > From: iesg@ietf.org > To: iana@iana.org > Cc: ccamp@ops.ietf.org > Subject: IESG on IANA allocations for ietf-ccamp-gmpls-sonet-sdh > > The IESG has reviewed the situation with RSVP C-Type allocations > performed for ietf-ccamp-gmpls-sonet-sdh by IANA (see [1] for more > information). The IESG recommends that IANA allocates C-Type value 4 > in the FLOWSPEC and SENDER_TSPEC ranges for this document, and marks > value 3 in these ranges as "deprecated". > > Note well: this does not set a precedent for IESG support of changing > IANA allocations based on implementation circumstances. > > The IESG also requests that CCAMP WG takes on the effort of reviewing > the situation and takes measures to prevent similar problems from > happening in the future. > > [1] IESG, "Short Last Call: IANA allocations for > ietf-ccamp-gmpls-sonet-sdh", 19 Jan 2004, e-mail message, > http://www1.ietf.org/mail-archive/ietf-announce/Current/msg28014.html Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 24 Jan 2004 15:23:56 +0000 Message-Id: <4.3.2.7.2.20040124101905.0279dee8@mo-ex1> Date: Sat, 24 Jan 2004 10:21:28 -0500 To: "Adrian Farrel" From: Lou Berger Subject: Re: Fw: I-D ACTION:draft-berger-gmpls-egress-control-01.txt Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Adrian, oh well, I asked for notification to be sent to the list. I was thinking of this as an individual draft, but you are probably right that it should go through WG review as it clarifies a protocol produced by the group. Moving it forward as a BCP probably is the right call... Thanks for forwarding the announcement. Lou At 05:43 PM 1/23/2004, Adrian Farrel wrote: >All, > >I didn't see notification of this to the list, but it sure is relevant. > >Would appreciate review input from everyone, but especially those who were >not clear about >how/whether GMPLS supported egress port/label control. > >Also, can you think about whether this draft should be run through the WG. > >Thanks, >Adrian > >----- Original Message ----- >From: >To: >Sent: Friday, January 23, 2004 8:59 PM >Subject: I-D ACTION:draft-berger-gmpls-egress-control-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : GMPLS Signaling Procedure For Egress Control > > Author(s) : L. Berger > > Filename : draft-berger-gmpls-egress-control-01.txt > > Pages : 5 > > Date : 2004-1-23 > > > > This note clarifies the procedures for the control of a label used on > > an egress output/downstream interface. Such control is also know and > > 'Egress Control'. Support for Egress Control is implicit in > > Generalized Multi-Protocol Label Switching (GMPLS) Signaling > > [RFC3471] and [RFC3473]. This note does not modify GMPLS signaling > > mechanisms and procedures and should be viewed as an informative > > clarification of [RFC3473]. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt > > > > > To remove yourself from the IETF Announcement list, send a message to > > ietf-announce-request with the word unsubscribe in the body of the > message. > > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-berger-gmpls-egress-control-01.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-berger-gmpls-egress-control-01.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Jan 2004 22:47:17 +0000 Message-ID: <0f6901c3e202$5736d890$715708c3@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: I-D ACTION:draft-berger-gmpls-egress-control-01.txt Date: Fri, 23 Jan 2004 22:43:32 -0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0F66_01C3E202.54330E70" This is a multi-part message in MIME format. ------=_NextPart_000_0F66_01C3E202.54330E70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit All, I didn't see notification of this to the list, but it sure is relevant. Would appreciate review input from everyone, but especially those who were not clear about how/whether GMPLS supported egress port/label control. Also, can you think about whether this draft should be run through the WG. Thanks, Adrian ----- Original Message ----- From: To: Sent: Friday, January 23, 2004 8:59 PM Subject: I-D ACTION:draft-berger-gmpls-egress-control-01.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : GMPLS Signaling Procedure For Egress Control > Author(s) : L. Berger > Filename : draft-berger-gmpls-egress-control-01.txt > Pages : 5 > Date : 2004-1-23 > > This note clarifies the procedures for the control of a label used on > an egress output/downstream interface. Such control is also know and > 'Egress Control'. Support for Egress Control is implicit in > Generalized Multi-Protocol Label Switching (GMPLS) Signaling > [RFC3471] and [RFC3473]. This note does not modify GMPLS signaling > mechanisms and procedures and should be viewed as an informative > clarification of [RFC3473]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-berger-gmpls-egress-control-01.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-berger-gmpls-egress-control-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-berger-gmpls-egress-control-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > ------=_NextPart_000_0F66_01C3E202.54330E70 Content-Type: application/octet-stream; name="ATT03937.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT03937.dat" Content-Type: text/plain Content-ID: <2004-1-23161850.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-berger-gmpls-egress-control-01.txt ------=_NextPart_000_0F66_01C3E202.54330E70 Content-Type: text/plain; name="draft-berger-gmpls-egress-control-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-berger-gmpls-egress-control-01.txt" Content-Type: text/plain Content-ID: <2004-1-23161850.I-D@ietf.org> ------=_NextPart_000_0F66_01C3E202.54330E70-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Jan 2004 12:30:10 +0000 Message-ID: <0d3201c3e0e3$23cf6be0$715708c3@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Ronald Bonica" Subject: Re: GTTP Draft Date: Thu, 22 Jan 2004 12:26:17 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit All, Recall that a tunnel trace protocol is now in our charter. If the WG considers that GTTP is suitable, we should adopt it and drive it to conclusion. If the WG thinks that GTTP is not suitable (or that there is no need for a tunnel trace protocol) voices should be raised. Cheers, Adrian ----- Original Message ----- From: "Ronald Bonica" To: Sent: Thursday, January 22, 2004 3:04 AM Subject: GTTP Draft > Folks, > > I have updated the generic tunnel tracing draft. It is available at > http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt. Please > review and comment. > > Ron > > Abstract > This document describes the Generic Tunnel Tracing Protocol (GTTP). GTTP > supports enhanced route-tracing applications. Network operators use enhanced > route-tracing applications to trace the path between any two points in an IP > network. Enhanced route-tracing applications can trace through a network's > forwarding plane, its control plane or both. Furthermore, enhanced > route-tracing applications can reveal details concerning tunnels that > support the traced path. Tunnel details can be revealed regardless of > tunneling technology. For example, enhanced route-tracing applications can > trace through an MPLS LSP as well as they can trace through an IP-in-IP > tunnel. > > =========================================== > Ronald P. Bonica Ph: 703 886 1681 > vBNS Engineering page: 1 888 268 8021 > Ashburn, Va. > =========================================== > "There is more to life than simply > increasing its speed." > -- Mahatma Gandhi > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Jan 2004 03:12:56 +0000 Date: Wed, 21 Jan 2004 22:04:03 -0500 From: Ronald Bonica Subject: GTTP Draft To: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Folks, I have updated the generic tunnel tracing draft. It is available at http://www.ietf.org/internet-drafts/draft-bonica-tunproto-05.txt. Please review and comment. Ron Abstract This document describes the Generic Tunnel Tracing Protocol (GTTP). GTTP supports enhanced route-tracing applications. Network operators use enhanced route-tracing applications to trace the path between any two points in an IP network. Enhanced route-tracing applications can trace through a network's forwarding plane, its control plane or both. Furthermore, enhanced route-tracing applications can reveal details concerning tunnels that support the traced path. Tunnel details can be revealed regardless of tunneling technology. For example, enhanced route-tracing applications can trace through an MPLS LSP as well as they can trace through an IP-in-IP tunnel. =========================================== Ronald P. Bonica Ph: 703 886 1681 vBNS Engineering page: 1 888 268 8021 Ashburn, Va. =========================================== "There is more to life than simply increasing its speed." -- Mahatma Gandhi Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Jan 2004 13:47:25 +0000 Message-ID: <0c0b01c3e024$db11d7d0$715708c3@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Submission deadlines for Seoul Date: Wed, 21 Jan 2004 13:45:32 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit All, Please be aware of the following deadlines. February 9, Monday - Internet Draft Cut-off for initial document (-00) submission at 09:00 ET February 16, Monday - Pre-Registration and Pre-payment cut-off at 12:00 noon ET Also, be warned! We plan to require submission of slides in advance of the meeting so that the attendees can follow along at their own speed. There will be something like a 24 hour deadline on this so you won't have to write slides until you know you are on the agenda. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Jan 2004 19:35:16 +0000 Date: Tue, 20 Jan 2004 11:32:26 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: Liaison response posted Message-ID: <20040120112942.Q53956@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, The Liaison response that the CCAMP WG sent to the ITU-T re G.7713.2 has been posted to the IETF "Liaison Statements" page at http://ietf.org/IESG/liaison.html . Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Jan 2004 18:01:46 +0000 Message-Id: <200401192337.SAA16365@ietf.org> From: The IESG cc: ccamp@ops.ietf.org Subject: Short Last Call: IANA allocations for ietf-ccamp-gmpls-sonet-sdh Date: Mon, 19 Jan 2004 18:37:35 -0500 The IESG is considering the situation with IANA allocation of the RSVP FLOWSPEC and SENDER_TSPEC C-Types for ietf-ccamp-gmpls-sonet-sdh that has been recently approved by the IESG for publication as an RFC. While the long-term measures to prevent similar situations in future are being discussed, the issue at hand needs to be quickly resolved. The proposed solution is to change the assignment of the above C-Types from value 3 (currently assigned by IANA) to 4, and mark value 3 as "reserved". The IESG would like to solicit comments on the proposed solution from the community. More details are given below. Please send your comments by January 22nd, 2004. Description of the situation with IANA assignments for ietf-ccamp-gmpls-sonet-sdh: 1. After the approval of the document by the IESG, an IANA action has been performed for the document, in which IANA correctly picked the next available C-Type value (3) in the FLOWSPEC and SENDER_TSPEC ranges and assigned it to the document. 2. However, the CCAMP WG has been informed that value 3 is being used by implementations of an another (expired) Internet draft that also picked next available value in the same ranges. Because the draft never progressed, these values have never been formally allocated by IANA within the RSVP registry. 3. Because implementations of the expired Internet draft have been deployed, assigning value 3 to ietf-ccamp-gmpls-sonet-sdh would create interoperability problems. 4. An implementation survey performed in the CCAMP WG showed that most early implementations of ietf-ccamp-gmpls-sonet-sdh use value 4, and those few that use the IANA-assigned value 3 would be willing to change it to 4 to avoid interoperability problems. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Jan 2004 12:43:46 +0000 Message-ID: <00dd01c3df53$0d3a25a0$90256497@coritel> From: "alessio d'achille" To: Cc: Subject: revised version of the draft Date: Tue, 20 Jan 2004 13:43:25 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D8_01C3DF5B.611526E0" This is a multi-part message in MIME format. ------=_NextPart_000_00D8_01C3DF5B.611526E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi folks,=20 Wer have just submitted a revised version of our draft: = , since the previous = version included few errors; you will find the new version soon, and we = ask you to send your feedback to us about this new version and not about = the previous one. As Vishal said in a previous e-mail, we would be particularly interested = in feedback from some of the principal WG members who are involved in = the inter-AS/inter-area activity. Best regards,=20 Alessio D'Achille=20 on behalf of Vishal Sharma, Marco Listanti, Fabio Ricciato, and Ugo = monaco ------=_NextPart_000_00D8_01C3DF5B.611526E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi folks,
 
Wer have just submitted a revised = version of our=20 draft: <draft-dachille-inter-area-path-protection-01.txt>, since = the=20 previous version included few errors; you will find the new version = soon, and we=20 ask you to send your feedback to us about this new version and not about = the=20 previous one.
 
As Vishal said in a previous e-mail, = we would=20 be particularly interested in feedback from some of the principal=20 WG members who are involved in the inter-AS/inter-area=20 activity.
 
Best regards,
 
Alessio D'Achille
 
on behalf of Vishal Sharma, Marco = Listanti, Fabio=20 Ricciato, and Ugo monaco
------=_NextPart_000_00D8_01C3DF5B.611526E0-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Jan 2004 00:11:09 +0000 Date: Mon, 19 Jan 2004 23:37:52 +0000 From: owner-ccamp@ops.ietf.org To: ccamp-approval@psg.com Subject: BOUNCE ccamp@ops.ietf.org: Non-member submission from [The IESG ] Message-Id: >From amyk@cnri.reston.va.us Mon Jan 19 23:37:40 2004 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Aiixf-000PR6-IC for ccamp@ops.ietf.org; Mon, 19 Jan 2004 23:37:39 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16365; Mon, 19 Jan 2004 18:37:35 -0500 (EST) Message-Id: <200401192337.SAA16365@ietf.org> To: IETF-Announce: ; From: The IESG cc: ccamp@ops.ietf.org Subject: Short Last Call: IANA allocations for ietf-ccamp-gmpls-sonet-sdh Date: Mon, 19 Jan 2004 18:37:35 -0500 Sender: amyk@cnri.reston.va.us X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 The IESG is considering the situation with IANA allocation of the RSVP FLOWSPEC and SENDER_TSPEC C-Types for ietf-ccamp-gmpls-sonet-sdh that has been recently approved by the IESG for publication as an RFC. While the long-term measures to prevent similar situations in future are being discussed, the issue at hand needs to be quickly resolved. The proposed solution is to change the assignment of the above C-Types from value 3 (currently assigned by IANA) to 4, and mark value 3 as "reserved". The IESG would like to solicit comments on the proposed solution from the community. More details are given below. Please send your comments by January 22nd, 2004. Description of the situation with IANA assignments for ietf-ccamp-gmpls-sonet-sdh: 1. After the approval of the document by the IESG, an IANA action has been performed for the document, in which IANA correctly picked the next available C-Type value (3) in the FLOWSPEC and SENDER_TSPEC ranges and assigned it to the document. 2. However, the CCAMP WG has been informed that value 3 is being used by implementations of an another (expired) Internet draft that also picked next available value in the same ranges. Because the draft never progressed, these values have never been formally allocated by IANA within the RSVP registry. 3. Because implementations of the expired Internet draft have been deployed, assigning value 3 to ietf-ccamp-gmpls-sonet-sdh would create interoperability problems. 4. An implementation survey performed in the CCAMP WG showed that most early implementations of ietf-ccamp-gmpls-sonet-sdh use value 4, and those few that use the IANA-assigned value 3 would be willing to change it to 4 to avoid interoperability problems. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Jan 2004 18:32:29 +0000 From: "Vishal Sharma" To: , "TE" Cc: "alessio d'achille" Subject: Inter-region TE Date: Mon, 19 Jan 2004 10:29:58 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01C3DE77.2FD8D5C0" This is a multi-part message in MIME format. ------=_NextPart_000_002C_01C3DE77.2FD8D5C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Folks, I just wanted to add that this work ties in to the recent inter-AS/inter-area TE work that has been a focus of the TE and CCAMP WGs. As Alessio mentioned, this work takes a unified view of areas and AS's, and is applicable to both inter-AS and inter-area scenarios. Therefore, we would be particularly interested in feedback from some of the principal WG members who are involved in the inter-AS/inter-area activity. Regards, -Vishal -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of alessio d'achille Sent: Monday, January 19, 2004 7:19 AM To: ccamp@ops.ietf.org Cc: te-wg@osp.ietf.org Subject: A new draft is available Hi all, we have just submitted to the IETF a new draft about inter-area path protection; in this document we addressed the problem of establishing two disjoint LSPs between two nodes which belongs to different areas (with the term "areas" we refer to an - OSPF area or - Autonomous System or - Optical island ) The draft is now available in the IETF draft directory and its name is : A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dachille-inter-area-path-protectio n-00.txt Best regards to all, Alessio D'Achille (one of the authors of this draft), on behalf of Vishal Sharma (co-author), Fabio Ricciato (author), Marco Listanti (Author) and Ugo Monaco (Author). P.S. We have noticed that there is an error in the authors' referencs in the very first page in the version of the draft in the IETF draft directory (in fact, in the very first page, "Ed." figures next to Vishal Sharma, but he is a co-author, and "Ed." should be next to Alessio D'Achille, Fabio Ricciato, Marco Listanti and Ugo Monaco) ------=_NextPart_000_002C_01C3DE77.2FD8D5C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Folks,
 
I just=20 wanted to add that this work ties in to the recent = inter-AS/inter-area=20 TE
work that has been a focus = of the=20 TE and CCAMP WGs.
 
As=20 Alessio mentioned, this work takes a unified view of areas and AS's,=20 and
is=20 applicable to both inter-AS and inter-area = scenarios.
 
Therefore, we would be particularly = interested in=20 feedback from some of the
principal WG members who are involved in the=20 inter-AS/inter-area activity.
 
Regards,
-Vishal
-----Original Message-----
From: = owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org]On Behalf Of alessio=20 d'achille
Sent: Monday, January 19, 2004 7:19 = AM
To:=20 ccamp@ops.ietf.org
Cc: te-wg@osp.ietf.org
Subject: = A new=20 draft is available

Hi all,
 
we have = just submitted to=20 the IETF a new draft about inter-area path protection; in this = document we=20 addressed the problem of establishing two disjoint LSPs between two = nodes=20 which belongs to different areas (with the term "areas" we refer to=20 an
- OSPF = area=20 or
- = Autonomous System=20 or
- Optical = island      )
 
The draft is now available in the = IETF draft=20 directory and its name is :
 
<draft-dachille-inter-area-path-protection-00.txt><= /DIV>
 
A URL for this Internet-Draft is: =
 
http://www.ietf.org/internet-drafts/draft-dachille-i= nter-area-path-protection-00.txt
 
Best = regards to=20 all,
 
Alessio = D'Achille (one of=20 the authors of this draft),
on behalf of
 
Vishal Sharma (co-author), Fabio = Ricciato=20 (author), Marco Listanti (Author) and Ugo Monaco = (Author).
 
 
P.S. We have noticed that there is an = error in=20 the authors' referencs in the very first page in the version of the = draft in=20 the IETF draft directory (in fact, in the very first page, "Ed." = figures next=20 to Vishal Sharma, but he is a co-author, and "Ed." should be next to = Alessio=20 D'Achille, Fabio Ricciato, Marco Listanti and Ugo Monaco)
 
 
 
=  
 
------=_NextPart_000_002C_01C3DE77.2FD8D5C0-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Jan 2004 18:15:44 +0000 From: "Vishal Sharma" To: Cc: , "alessio d'achille" Subject: RE: Inter-region TE Date: Mon, 19 Jan 2004 10:12:31 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01C3DE74.C0106B60" This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C3DE74.C0106B60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Folks, I just wanted to add that this work ties in to the recent inter-AS/inter-area TE work that has been a focus of the TE and CCAMP WGs. As Alessio mentioned, this work takes a unified view of areas and AS's, and is applicable to both inter-AS and inter-area scenarios. Therefore, we would be particularly interested in feedback from some of the principal WG members who are involved in the inter-AS/inter-area activity. Regards, -Vishal -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of alessio d'achille Sent: Monday, January 19, 2004 7:19 AM To: ccamp@ops.ietf.org Cc: te-wg@osp.ietf.org Subject: A new draft is available Hi all, we have just submitted to the IETF a new draft about inter-area path protection; in this document we addressed the problem of establishing two disjoint LSPs between two nodes which belongs to different areas (with the term "areas" we refer to an - OSPF area or - Autonomous System or - Optical island ) The draft is now available in the IETF draft directory and its name is : A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dachille-inter-area-path-protectio n-00.txt Best regards to all, Alessio D'Achille (one of the authors of this draft), on behalf of Vishal Sharma (co-author), Fabio Ricciato (author), Marco Listanti (Author) and Ugo Monaco (Author). P.S. We have noticed that there is an error in the authors' referencs in the very first page in the version of the draft in the IETF draft directory (in fact, in the very first page, "Ed." figures next to Vishal Sharma, but he is a co-author, and "Ed." should be next to Alessio D'Achille, Fabio Ricciato, Marco Listanti and Ugo Monaco) ------=_NextPart_000_0023_01C3DE74.C0106B60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Folks,
 
I just=20 wanted to add that this work ties in to the recent = inter-AS/inter-area=20 TE
work that has been a focus = of the=20 TE and CCAMP WGs.
 
As=20 Alessio mentioned, this work takes a unified view of areas and AS's,=20 and
is=20 applicable to both inter-AS and inter-area = scenarios.
 
Therefore, we would be particularly = interested in=20 feedback from some of the
principal WG members who are involved in the=20 inter-AS/inter-area activity.
 
Regards,
-Vishal
-----Original Message-----
From: = owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org]On Behalf Of alessio=20 d'achille
Sent: Monday, January 19, 2004 7:19 = AM
To:=20 ccamp@ops.ietf.org
Cc: te-wg@osp.ietf.org
Subject: = A new=20 draft is available

Hi all,
 
we have = just submitted to=20 the IETF a new draft about inter-area path protection; in this = document we=20 addressed the problem of establishing two disjoint LSPs between two = nodes=20 which belongs to different areas (with the term "areas" we refer to=20 an
- OSPF = area=20 or
- = Autonomous System=20 or
- Optical = island      )
 
The draft is now available in the = IETF draft=20 directory and its name is :
 
<draft-dachille-inter-area-path-protection-00.txt><= /DIV>
 
A URL for this Internet-Draft is: =
 
http://www.ietf.org/internet-drafts/draft-dachille-i= nter-area-path-protection-00.txt
 
Best = regards to=20 all,
 
Alessio = D'Achille (one of=20 the authors of this draft),
on behalf of
 
Vishal Sharma (co-author), Fabio = Ricciato=20 (author), Marco Listanti (Author) and Ugo Monaco = (Author).
 
 
P.S. We have noticed that there is an = error in=20 the authors' referencs in the very first page in the version of the = draft in=20 the IETF draft directory (in fact, in the very first page, "Ed." = figures next=20 to Vishal Sharma, but he is a co-author, and "Ed." should be next to = Alessio=20 D'Achille, Fabio Ricciato, Marco Listanti and Ugo Monaco)
 
 
 
=  
 
------=_NextPart_000_0023_01C3DE74.C0106B60-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Jan 2004 15:20:09 +0000 Message-ID: <00ac01c3de9f$98153980$90256497@coritel> From: "alessio d'achille" To: Cc: Subject: A new draft is available Date: Mon, 19 Jan 2004 16:18:37 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A7_01C3DEA7.E4A18080" This is a multi-part message in MIME format. ------=_NextPart_000_00A7_01C3DEA7.E4A18080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all,=20 we have just submitted to the IETF a new draft about inter-area path = protection; in this document we addressed the problem of establishing = two disjoint LSPs between two nodes which belongs to different areas = (with the term "areas" we refer to an - OSPF area or - Autonomous System or - Optical island ) The draft is now available in the IETF draft directory and its name is : A URL for this Internet-Draft is:=20 http://www.ietf.org/internet-drafts/draft-dachille-inter-area-path-protec= tion-00.txt Best regards to all, Alessio D'Achille (one of the authors of this draft),=20 on behalf of Vishal Sharma (co-author), Fabio Ricciato (author), Marco Listanti = (Author) and Ugo Monaco (Author). P.S. We have noticed that there is an error in the authors' referencs in = the very first page in the version of the draft in the IETF draft = directory (in fact, in the very first page, "Ed." figures next to Vishal = Sharma, but he is a co-author, and "Ed." should be next to Alessio = D'Achille, Fabio Ricciato, Marco Listanti and Ugo Monaco) ------=_NextPart_000_00A7_01C3DEA7.E4A18080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
we have = just submitted to=20 the IETF a new draft about inter-area path protection; in this document = we=20 addressed the problem of establishing two disjoint LSPs between two = nodes which=20 belongs to different areas (with the term "areas" we refer to=20 an
- OSPF area = or
- = Autonomous System=20 or
- Optical=20 island      )
 
The draft is now available in the IETF = draft=20 directory and its name is :
 
<draft-dachille-inter-area-path-protection-00.txt><= /DIV>
 
A URL for this Internet-Draft is: =
 
http://www.ietf.org/internet-drafts/draft-dachille-i= nter-area-path-protection-00.txt
 
Best = regards to=20 all,
 
Alessio = D'Achille (one of=20 the authors of this draft),
on behalf of
 
Vishal Sharma (co-author), Fabio = Ricciato (author),=20 Marco Listanti (Author) and Ugo Monaco (Author).
 
 
P.S. We have noticed that there is an = error in the=20 authors' referencs in the very first page in the version of the draft in = the=20 IETF draft directory (in fact, in the very first page, "Ed." figures = next to=20 Vishal Sharma, but he is a co-author, and "Ed." should be next to = Alessio=20 D'Achille, Fabio Ricciato, Marco Listanti and Ugo Monaco)
 
 
 
=  
 
------=_NextPart_000_00A7_01C3DEA7.E4A18080-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Jan 2004 22:04:41 +0000 Date: Fri, 16 Jan 2004 14:02:47 -0800 From: Alex Zinin Reply-To: Alex Zinin Message-ID: <183189057480.20040116140247@psg.com> To: Kireeti Kompella CC: Thomas Narten , ccamp@ops.ietf.org, iana@iana.org Subject: Re: IANA assignments MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kireeti, >> It might be possible to change this assignment if people can make a >> clear case that: >> >> - leaving the assignment of 3 is clearly worse than changing to 4, > This is clear: all implementations that reported (with the exception > of the new revision from cisco) use the value of 4. Agreed. Taking care of this. We also need to make sure we don't have situations like this in future. The solution with Expert Review Thomas proposed seems to be reasonable. Alex >> and >> - changing to 4 doesn't cause hardship and confusion for those that >> have picked up the IANA-assigned value of 3. > Both cisco (George Swallow) and OIF (Ben Mack-Crane) have stated on > this list that reverting to 4 is acceptable *if done quickly*. So, > can we do this quickly? > Kireeti. > ------- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Jan 2004 18:30:12 +0000 Date: Fri, 16 Jan 2004 10:28:53 -0800 (PST) From: Kireeti Kompella To: Ben Mack-Crane cc: ccamp@ops.ietf.org Subject: Re: IANA assignments Message-ID: <20040116102731.Q35769@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 16 Jan 2004, Ben Mack-Crane wrote: > Adrian and all, > > After checking with the OIF, I understand that UNI1.0r2 has passed Straw > Ballot but > not Principal Ballot. The value in question could be adjusted as an > editorial change before > going to Principal Ballot. The OIF is meeting next week and UNI1.0r2 is > likely to go > to Principal Ballot soon. Thanks for the update, Ben. We'll try to resolve this quickly. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Jan 2004 18:29:57 +0000 Date: Fri, 16 Jan 2004 10:27:13 -0800 (PST) From: Kireeti Kompella To: Thomas Narten cc: ccamp@ops.ietf.org, iana@iana.org Subject: Re: IANA assignments Message-ID: <20040116102355.F35769@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 16 Jan 2004, Thomas Narten wrote: > It might be possible to change this assignment if people can make a > clear case that: > > - leaving the assignment of 3 is clearly worse than changing to 4, This is clear: all implementations that reported (with the exception of the new revision from cisco) use the value of 4. > and > - changing to 4 doesn't cause hardship and confusion for those that > have picked up the IANA-assigned value of 3. Both cisco (George Swallow) and OIF (Ben Mack-Crane) have stated on this list that reverting to 4 is acceptable *if done quickly*. So, can we do this quickly? Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Jan 2004 15:25:26 +0000 Message-ID: <4007FDB5.2020802@tellabs.com> Date: Fri, 16 Jan 2004 09:05:25 -0600 From: Ben Mack-Crane User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: Ben.Mack-Crane@tellabs.com CC: Adrian Farrel , Andy.Malis@tellabs.com, ccamp@ops.ietf.org Subject: Re: IANA assignments Content-Type: multipart/alternative; boundary="------------080207010105030209060601" --------------080207010105030209060601 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Transfer-Encoding: 7bit Adrian and all, After checking with the OIF, I understand that UNI1.0r2 has passed Straw Ballot but not Principal Ballot. The value in question could be adjusted as an editorial change before going to Principal Ballot. The OIF is meeting next week and UNI1.0r2 is likely to go to Principal Ballot soon. Regards, Ben Ben.Mack-Crane@tellabs.com wrote: > Adrian, > > Initially OIF used the value (4) in UNI1.0. I do not know how this value > was chosen, or who chose it, but this is probably how it came into > common use, since UNI > interop was done quite a while ago. > > While making minor corrections and updates to conform with IETF RFCs > (since UNI1.0 > was based on drafts) we consulted the IANA assignments and found (3), > so that value > was used as the corrected value in UNI1.0r2. > > So, OIF has followed the official IANA assignment. > > Regards, > Ben > > Adrian Farrel wrote: > >>Erm, >>Which order this happen Ben? >> >>IANA or OIF first? >> >>Thanks, >>Adrian >>----- Original Message ----- >>From: "Ben Mack-Crane" >>To: >>Cc: >>Sent: Wednesday, January 14, 2004 4:02 PM >>Subject: Re: IANA assignments >> >> >> >> >>>To add to Andy's factual response on Tellabs' implementations, >>>I would like to support Bert's messages on following the process >>>and also state that we are willing to update our implementation >>>to support the "right" codepoint. >>> >>>Other standards organizations depend on the stability of the >>>IANA process. For example, the recently approved OIF UNI1.0r2 IA >>>specifies the IANA assigned C-Type (3) for SONET/SDH TSPEC/FLOWSPEC. >>>This will be a problem if the IANA assignment is changed. >>> >>>Regards, >>>Ben Mack-Crane >>> >>>Andy.Malis@tellabs.com wrote: >>> >>> >>> >>>>Ditto for Tellabs (the same as Kireeti's answer). >>>> >>>>Andy >>>> >>>>------------ >>>> >>>>At 1/9/2004 11:48 AM -0800, Kireeti Kompella wrote: >>>> >>>> >>>> >>>>>On Fri, 9 Jan 2004, Kireeti Kompella wrote: >>>>> >>>>>For the record, here is the answer from Juniper's implementation: >>>>> >>>>> >>>>> >>>>>>a) do you use the FLOWSPEC C-Type 3 for CoS? >>>>>> >>>>>> >>>>>We parse this, but don't really use it. >>>>> >>>>> >>>>> >>>>>>b) have you implemented the SONET/SDH FLOWSPEC? If so, what value did >>>>>> you use for the C-Type? >>>>>> >>>>>> >>>>>Yes. Value 4. >>>>> >>>>> >>>>> >>>>>>c) do you use the TSPEC C-Type 3 for CoS? >>>>>> >>>>>> >>>>>We parse this, but don't really use it. >>>>> >>>>> >>>>> >>>>>>d) have you implemented the SONET/SDH TSPEC? If so, what value did >>>>>> you use for the C-Type? >>>>>> >>>>>> >>>>>Yes. Value 4. >>>>> >>>>>Kireeti. >>>>>------- >>>>> >>>>> >>>> >>>> >>>----------------------------------------- >>>============================================================ >>>The information contained in this message may be privileged >>>and confidential and protected from disclosure. If the >>>reader of this message is not the intended recipient, or an >>>employee or agent responsible for delivering this message to >>>the intended recipient, you are hereby notified that any >>>reproduction, dissemination or distribution of this >>>communication is strictly prohibited. If you have received >>>this communication in error, please notify us immediately by >>>replying to the message and deleting it from your computer. >>> >>>Thank you. >>>Tellabs >>>============================================================ >>> >>> >>> >>> >>> >>> >> >> >> > > ------------------------------------------------------------------------ > > ============================================================ > The information contained in this message may be privileged > and confidential and protected from disclosure. If the > reader of this message is not the intended recipient, or an > employee or agent responsible for delivering this message to > the intended recipient, you are hereby notified that any > reproduction, dissemination or distribution of this > communication is strictly prohibited. If you have received > this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. > > Thank you. > Tellabs > ============================================================ > ----------------------------------------- ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ --------------080207010105030209060601 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Adrian and all,

After checking with the OIF, I understand that UNI1.0r2 has passed Straw Ballot but
not Principal Ballot.  The value in question could be adjusted as an editorial change before
going to Principal Ballot.  The OIF is meeting next week and UNI1.0r2 is likely to go
to Principal Ballot soon.

Regards,
Ben

Ben.Mack-Crane@tellabs.com wrote:
Adrian,

Initially OIF used the value (4) in UNI1.0.  I do not know how this value
was chosen, or who chose it, but this is probably how it came into common use, since UNI
interop was done quite a while ago.

While making minor corrections and updates to conform with IETF RFCs (since UNI1.0
was based on drafts) we consulted the IANA assignments and found (3), so that value
was used as the corrected value in UNI1.0r2.

So, OIF has followed the official IANA assignment.

Regards,
Ben

Adrian Farrel wrote:
Erm,
Which order this happen Ben?

IANA or OIF first?

Thanks,
Adrian
----- Original Message ----- 
From: "Ben Mack-Crane" <ben.mack-crane@tellabs.com>
To: <Andy.Malis@tellabs.com>
Cc: <ccamp@ops.ietf.org>
Sent: Wednesday, January 14, 2004 4:02 PM
Subject: Re: IANA assignments


  
To add to Andy's factual response on Tellabs' implementations,
I would like to support Bert's messages on following the process
and also state that we are willing to update our implementation
to support the "right" codepoint.

Other standards organizations depend on the stability of the
IANA process.  For example, the recently approved OIF UNI1.0r2 IA
specifies the IANA assigned C-Type (3) for SONET/SDH TSPEC/FLOWSPEC.
This will be a problem if the IANA assignment is changed.

Regards,
Ben Mack-Crane

Andy.Malis@tellabs.com wrote:

    
Ditto for Tellabs (the same as Kireeti's answer).

Andy

------------

At 1/9/2004 11:48 AM -0800, Kireeti Kompella wrote:

      
On Fri, 9 Jan 2004, Kireeti Kompella wrote:

For the record, here is the answer from Juniper's implementation:

        
a) do you use the FLOWSPEC C-Type 3 for CoS?
          
We parse this, but don't really use it.

        
b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
   you use for the C-Type?
          
Yes. Value 4.

        
c) do you use the TSPEC C-Type 3 for CoS?
          
We parse this, but don't really use it.

        
d) have you implemented the SONET/SDH TSPEC?  If so, what value did
   you use for the C-Type?
          
Yes. Value 4.

Kireeti.
-------
        
      
-----------------------------------------
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the
reader of this message is not the intended recipient, or an
employee or agent responsible for delivering this message to
the intended recipient, you are hereby notified that any
reproduction, dissemination or distribution of this
communication is strictly prohibited. If you have received
this communication in error, please notify us immediately by
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================


============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the
reader of this message is not the intended recipient, or an
employee or agent responsible for delivering this message to
the intended recipient, you are hereby notified that any
reproduction, dissemination or distribution of this
communication is strictly prohibited. If you have received
this communication in error, please notify us immediately by
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

--------------080207010105030209060601-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Jan 2004 12:23:27 +0000 Message-Id: <200401161216.i0GCGgc04020@cichlid.raleigh.ibm.com> To: Kireeti Kompella cc: "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, iana@iana.org Subject: Re: IANA assignments Date: Fri, 16 Jan 2004 07:16:42 -0500 From: Thomas Narten > The priority here is simple: the *IETF* has asked IANA for assignment > of a code point; the most reasonable value of that code point *based > on implementations of the IETF draft/RFC* is 4. This may well be a correct statement, prior to IANA having made the assignment. Now that they have published 3 as the "correct" value, things are no longer so simple. > The OIF is *not* a standards organization; for the IETF to change > what is the right decision based on premature actions of the OIF is > a sign of weakness. In any case, 'signs of weakness' should NOT be > our guiding principle -- we should do what is right and reasonable. This is not about weakness. A fundamental property of assignments is that they are stable and do not change. Once IANA makes an assignment, it needs to have very very very good reasons for backing out and making a change. > BTW, to put this in perspective, OIF UNI1.0 uses a code point value > of 4. If the value of 3 was 'approved' by the OIF for UNI1.0r2, it > seems to me that the OIF really jumped the gun: the RFC has not been > published and discussion of code point assignments is not complete. Actually, the IANA assignment step and RFC publication are different. The IANA step occurs when IANA announces its assignment (whether via email, by posting a message, by updating their web pages, etc.). An RFC can't be published until after IANA makes any relevant assignments. So even though the RFC may not be out, the code point assignment has been completed, officially. > Perhaps the OIF can approve (as soon as we complete the discussion and > reach the right conclusion) UNI1.0r3 with the correct value. It would be extremely useful for someone to ask OIF about the feasibility of this. And to comment on what other organization may have picked up the IANA-published value at this point. > I stand by my recommendation that IANA assign a value of 4 for the > SDH/SONET C-Types for FLOWSPEC and TSPEC. I think we all agree that would have been the logical assignment. Problem is, we're past that point now and reversing an assignment is not so simple. Thomas Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Jan 2004 12:20:12 +0000 Message-Id: <200401161214.i0GCEol04004@cichlid.raleigh.ibm.com> To: Kireeti Kompella cc: ccamp@ops.ietf.org, iana@iana.org Subject: Re: IANA assignments Date: Fri, 16 Jan 2004 07:14:50 -0500 From: Thomas Narten > On that basis, I would strongly recommend IANA to assign 4 for both > the C-Types of SONET/SDH TSPEC and FLOWSPEC. Too late. IANA has already assigned 3 for that value. Given that IANA is the authority and people may have already taken IANA's published value (assuming it was the legit value to use) and added it to their documents, simply changing the assignment is no longer a simple matter anymore. It might be possible to change this assignment if people can make a clear case that: - leaving the assignment of 3 is clearly worse than changing to 4, and - changing to 4 doesn't cause hardship and confusion for those that have picked up the IANA-assigned value of 3. Thomas Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Jan 2004 12:19:55 +0000 Message-Id: <200401161213.i0GCDi703989@cichlid.raleigh.ibm.com> To: "Naidu, Venkata" cc: "'Dimitri.Papadimitriou@alcatel.be'" , "'Wijnen, Bert (Bert)'" , IETF CCAMP List , iana@iana.org Subject: Re: IANA assignments Date: Fri, 16 Jan 2004 07:13:44 -0500 From: Thomas Narten > All I am saying is, IANA can have a guideline for long lived > drafts, such as: > > If there is a shipped implementation with an old deprecated > value, that value MUST be reserved to prevent future misuse. > It MUST be noted in the subsequent drafts and final RFC. Well, a more proper way to express the above (process wise) would be to have an IANA considerations Section (for the name space at issue) of something like: values in the range 0-128 are assigned via Standards Action or Expert Review. The purpose of Expert Review assignments is for the assignment of code points in cases where the document is expected to become published as a standards track RFC (e.g., it is a Working Group document), but for which experimentation is desired before the RFC is published. Tune further as appropriate. Then, when a WG needs an assignment, it asks IANA to make the assignment, IANA checks with the expert, and assuming the request is proper, the assignment gets made. The point is that there are ways for the WG to retain control over assignments that IANA is managing. That is what IANA Considerations sections are for. Thomas Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Jan 2004 12:19:43 +0000 Message-Id: <200401161212.i0GCCIf03977@cichlid.raleigh.ibm.com> To: "Naidu, Venkata" cc: "'Wijnen, Bert (Bert)'" , IETF CCAMP List , iana@iana.org Subject: Re: IANA assignments Date: Fri, 16 Jan 2004 07:12:18 -0500 From: Thomas Narten > Is it possible for IANA to initiate a discussion in the mailing-list > before publishing a value, at least, for long lived drafts ? Not really practical. Please see RFC 2434, where it talks about mailing lists. Bottom line: IANA doesn't have the resources or subject-matter expertise to read mailing list discussions and make sense out of the diverse opinions that tend to get expressed. But one can certainly write an IANA considerations section (again see RFC 2434) that specifies that a Designated Expert should make the evaluation, and one of the steps of that process could be to check with relevant WGs first, and so forth. WGs have a lot of flexibility in defining how they want their name spaces managed. But IANA certainly can't guess what the right thing to do is. That's why it's so important the authors/WGs pay attention to IANA considerations and specify them carefully. Thomas Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 16 Jan 2004 01:33:05 +0000 Date: Thu, 15 Jan 2004 17:30:01 -0800 From: Alex Zinin Reply-To: Alex Zinin Message-ID: <153115090911.20040115173001@psg.com> To: "Thomas D. Nadeau" CC: "'Vishal Sharma'" , ietf-web@ietf.org, "'CCAMP'" , "'MPLS'" Subject: Re: Outdated WG charters?! MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks- There was a problem with the IETF WG database, which the secretariat should have fixed. The WG web-pages are regenerated nightly, so if everything is fixed, we should not see any problems tomorrow. -- Alex http://www.psg.com/~zinin/ Thursday, January 15, 2004, 7:50:22 AM, Thomas D. Nadeau wrote: > BTW, there are other errors I noticed with > the PWE3 and MPLS WG pages pointing at other > out-dated drafts. Looks like the web server > was restored from some (really) old backups. > --Tom >> -----Original Message----- >> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf >> Of Vishal Sharma >> Sent: Wednesday, January 14, 2004 10:54 PM >> To: ietf-web@ietf.org >> Cc: CCAMP; MPLS >> Subject: Outdated WG charters?! >> Importance: High >> >> >> Hello, >> >> It appears that the Charter updates posted by the IETF Secretariat >> at >> http://www.ietf.org/html.charters/wg-dir.html just this evening >> (at least) for CCAMP and MPLS WGs are completely outdated (over >> a year old). >> >> I believe an error was made in posting these, and it would be >> great if this could be corrected at the earliest (otherwise >> it's very difficult to access the latest WG documents). >> >> Thanks much! >> >> -Vishal >> >> PS: If I am the only one experiencing this problem, please let >> me know. I've flushed all caches and buffers, so I don't think >> the problem is at my end. >> Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 Jan 2004 16:25:55 +0000 Message-Id: <200401151623.i0FGNIK6025745@rtp-core-2.cisco.com> To: Kireeti Kompella cc: ccamp@ops.ietf.org, iana@iana.org cc: swallow@cisco.com Subject: Re: IANA assignments Date: Thu, 15 Jan 2004 11:23:17 -0500 From: George Swallow > Let me start with the second issue, as it is more relevant to CCAMP. > The responses I got unanimously state that the codepoint value used > for SONET/SDH TSPEC and FLOWSPEC is 4. There is a minor wrinkle here > that in Cisco's implementation, the initial version used 4 and a later > revision uses 3. Apart from that, all responses (from about 10 > independent implementations, if memory serves) indicated that they use > the value 4. Cisco doesn't care which value is used. We DO want the issue resolved SOON. > On that basis, I would strongly recommend IANA to assign 4 for both > the C-Types of SONET/SDH TSPEC and FLOWSPEC. > > The other issue, what to do with the value of 3, is less clear. Most > responses indicated that they either parsed and ignored or simply > ignored this value. As CCAMP WG chair, I don't have a stand on > whether this value should be set aside as reserved, or left as a hole > in the address space, to be assigned to the next request for a code > point for a TSPEC/FLOWSPEC C-Type. I say leave it as a hole but have a note that says it won't get assigned until at least 2005. (To give folks time to field versions that don't parse this.) ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 Jan 2004 15:53:49 +0000 Message-ID: <4006B6D8.3030701@tellabs.com> Date: Thu, 15 Jan 2004 09:50:48 -0600 From: Ben Mack-Crane User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: Kireeti Kompella CC: "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, iana@iana.org Subject: Re: IANA assignments Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; format="flowed" Kireeti, I don't understand how OIF "jumped the gun" by using a value from the IANA website, which I understand is the authoritative source for number assignments. Regards, Ben Kireeti Kompella wrote: >If the value of 3 was 'approved' by the OIF for UNI1.0r2, it >seems to me that the OIF really jumped the gun: the RFC has not been >published and discussion of code point assignments is not complete. > > >Kireeti. >------- > > > ----------------------------------------- ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 Jan 2004 15:51:38 +0000 Reply-To: From: "Thomas D. Nadeau" To: "'Vishal Sharma'" , Cc: "'CCAMP'" , "'MPLS'" Subject: RE: Outdated WG charters?! Date: Thu, 15 Jan 2004 10:50:22 -0500 Organization: Cisco Systems, inc. Message-ID: <007601c3db7f$4d64d850$6701a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit BTW, there are other errors I noticed with the PWE3 and MPLS WG pages pointing at other out-dated drafts. Looks like the web server was restored from some (really) old backups. --Tom > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf > Of Vishal Sharma > Sent: Wednesday, January 14, 2004 10:54 PM > To: ietf-web@ietf.org > Cc: CCAMP; MPLS > Subject: Outdated WG charters?! > Importance: High > > > Hello, > > It appears that the Charter updates posted by the IETF Secretariat > at > http://www.ietf.org/html.charters/wg-dir.html just this evening > (at least) for CCAMP and MPLS WGs are completely outdated (over > a year old). > > I believe an error was made in posting these, and it would be > great if this could be corrected at the earliest (otherwise > it's very difficult to access the latest WG documents). > > Thanks much! > > -Vishal > > PS: If I am the only one experiencing this problem, please let > me know. I've flushed all caches and buffers, so I don't think > the problem is at my end. > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 Jan 2004 15:22:39 +0000 Message-ID: <4006AF1C.1040304@tellabs.com> Date: Thu, 15 Jan 2004 09:17:48 -0600 From: Ben Mack-Crane User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: Adrian Farrel CC: Andy.Malis@tellabs.com, ccamp@ops.ietf.org Subject: Re: IANA assignments Content-Type: multipart/alternative; boundary="------------010705070204010203070609" --------------010705070204010203070609 Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Transfer-Encoding: 7bit Adrian, Initially OIF used the value (4) in UNI1.0. I do not know how this value was chosen, or who chose it, but this is probably how it came into common use, since UNI interop was done quite a while ago. While making minor corrections and updates to conform with IETF RFCs (since UNI1.0 was based on drafts) we consulted the IANA assignments and found (3), so that value was used as the corrected value in UNI1.0r2. So, OIF has followed the official IANA assignment. Regards, Ben Adrian Farrel wrote: >Erm, >Which order this happen Ben? > >IANA or OIF first? > >Thanks, >Adrian >----- Original Message ----- >From: "Ben Mack-Crane" >To: >Cc: >Sent: Wednesday, January 14, 2004 4:02 PM >Subject: Re: IANA assignments > > > > >>To add to Andy's factual response on Tellabs' implementations, >>I would like to support Bert's messages on following the process >>and also state that we are willing to update our implementation >>to support the "right" codepoint. >> >>Other standards organizations depend on the stability of the >>IANA process. For example, the recently approved OIF UNI1.0r2 IA >>specifies the IANA assigned C-Type (3) for SONET/SDH TSPEC/FLOWSPEC. >>This will be a problem if the IANA assignment is changed. >> >>Regards, >>Ben Mack-Crane >> >>Andy.Malis@tellabs.com wrote: >> >> >> >>>Ditto for Tellabs (the same as Kireeti's answer). >>> >>>Andy >>> >>>------------ >>> >>>At 1/9/2004 11:48 AM -0800, Kireeti Kompella wrote: >>> >>> >>> >>>>On Fri, 9 Jan 2004, Kireeti Kompella wrote: >>>> >>>>For the record, here is the answer from Juniper's implementation: >>>> >>>> >>>> >>>>>a) do you use the FLOWSPEC C-Type 3 for CoS? >>>>> >>>>> >>>>We parse this, but don't really use it. >>>> >>>> >>>> >>>>>b) have you implemented the SONET/SDH FLOWSPEC? If so, what value did >>>>> you use for the C-Type? >>>>> >>>>> >>>>Yes. Value 4. >>>> >>>> >>>> >>>>>c) do you use the TSPEC C-Type 3 for CoS? >>>>> >>>>> >>>>We parse this, but don't really use it. >>>> >>>> >>>> >>>>>d) have you implemented the SONET/SDH TSPEC? If so, what value did >>>>> you use for the C-Type? >>>>> >>>>> >>>>Yes. Value 4. >>>> >>>>Kireeti. >>>>------- >>>> >>>> >>> >>> >> >>----------------------------------------- >>============================================================ >>The information contained in this message may be privileged >>and confidential and protected from disclosure. If the >>reader of this message is not the intended recipient, or an >>employee or agent responsible for delivering this message to >>the intended recipient, you are hereby notified that any >>reproduction, dissemination or distribution of this >>communication is strictly prohibited. If you have received >>this communication in error, please notify us immediately by >>replying to the message and deleting it from your computer. >> >>Thank you. >>Tellabs >>============================================================ >> >> >> >> >> >> > > > ----------------------------------------- ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ --------------010705070204010203070609 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Adrian,

Initially OIF used the value (4) in UNI1.0.  I do not know how this value
was chosen, or who chose it, but this is probably how it came into common use, since UNI
interop was done quite a while ago.

While making minor corrections and updates to conform with IETF RFCs (since UNI1.0
was based on drafts) we consulted the IANA assignments and found (3), so that value
was used as the corrected value in UNI1.0r2.

So, OIF has followed the official IANA assignment.

Regards,
Ben

Adrian Farrel wrote:
Erm,
Which order this happen Ben?

IANA or OIF first?

Thanks,
Adrian
----- Original Message ----- 
From: "Ben Mack-Crane" <ben.mack-crane@tellabs.com>
To: <Andy.Malis@tellabs.com>
Cc: <ccamp@ops.ietf.org>
Sent: Wednesday, January 14, 2004 4:02 PM
Subject: Re: IANA assignments


  
To add to Andy's factual response on Tellabs' implementations,
I would like to support Bert's messages on following the process
and also state that we are willing to update our implementation
to support the "right" codepoint.

Other standards organizations depend on the stability of the
IANA process.  For example, the recently approved OIF UNI1.0r2 IA
specifies the IANA assigned C-Type (3) for SONET/SDH TSPEC/FLOWSPEC.
This will be a problem if the IANA assignment is changed.

Regards,
Ben Mack-Crane

Andy.Malis@tellabs.com wrote:

    
Ditto for Tellabs (the same as Kireeti's answer).

Andy

------------

At 1/9/2004 11:48 AM -0800, Kireeti Kompella wrote:

      
On Fri, 9 Jan 2004, Kireeti Kompella wrote:

For the record, here is the answer from Juniper's implementation:

        
a) do you use the FLOWSPEC C-Type 3 for CoS?
          
We parse this, but don't really use it.

        
b) have you implemented the SONET/SDH FLOWSPEC?  If so, what value did
   you use for the C-Type?
          
Yes. Value 4.

        
c) do you use the TSPEC C-Type 3 for CoS?
          
We parse this, but don't really use it.

        
d) have you implemented the SONET/SDH TSPEC?  If so, what value did
   you use for the C-Type?
          
Yes. Value 4.

Kireeti.
-------
        
      

-----------------------------------------
============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the
reader of this message is not the intended recipient, or an
employee or agent responsible for delivering this message to
the intended recipient, you are hereby notified that any
reproduction, dissemination or distribution of this
communication is strictly prohibited. If you have received
this communication in error, please notify us immediately by
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

--------------010705070204010203070609-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 Jan 2004 08:15:51 +0000 Date: Thu, 15 Jan 2004 00:14:14 -0800 (PST) From: Kireeti Kompella To: "Wijnen, Bert (Bert)" cc: ccamp@ops.ietf.org, iana@iana.org Subject: RE: IANA assignments Message-ID: <20040114234904.A29284@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 15 Jan 2004, Wijnen, Bert (Bert) wrote: > I hope you also realize that it was pointed out that OIF has assumed > the assigned value of 3 (probably because IANA had assigned it and > published it on the iana web pages... Adrian has asked the question > if it is indeed so or not). So if IANA changes it, it may be perceived > by outside world as a weakness. Not sure it is.. but we should check > (or so I think... IANA pls let us know what you think about this). I do realize that. The priority here is simple: the *IETF* has asked IANA for assignment of a code point; the most reasonable value of that code point *based on implementations of the IETF draft/RFC* is 4. The OIF is *not* a standards organization; for the IETF to change what is the right decision based on premature actions of the OIF is a sign of weakness. In any case, 'signs of weakness' should NOT be our guiding principle -- we should do what is right and reasonable. BTW, to put this in perspective, OIF UNI1.0 uses a code point value of 4. If the value of 3 was 'approved' by the OIF for UNI1.0r2, it seems to me that the OIF really jumped the gun: the RFC has not been published and discussion of code point assignments is not complete. Perhaps the OIF can approve (as soon as we complete the discussion and reach the right conclusion) UNI1.0r3 with the correct value. Note that many participants in the CCAMP mailing list have implemented OIF UNI1.0, and I have not heard that we should change the value to 3; in fact, Tellabs' own implementation uses 4 today. I stand by my recommendation that IANA assign a value of 4 for the SDH/SONET C-Types for FLOWSPEC and TSPEC. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 Jan 2004 06:20:35 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503509E52@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Kireeti Kompella , ccamp@ops.ietf.org Cc: iana@iana.org Subject: RE: IANA assignments Date: Thu, 15 Jan 2004 07:18:23 +0100 MIME-Version: 1.0 Content-Type: text/plain > On Fri, 9 Jan 2004, Kireeti Kompella wrote: > > > a) do you use the FLOWSPEC C-Type 3 for CoS? > > b) have you implemented the SONET/SDH FLOWSPEC? If so, > what value did > > you use for the C-Type? > > c) do you use the TSPEC C-Type 3 for CoS? > > d) have you implemented the SONET/SDH TSPEC? If so, what value did > > you use for the C-Type? > > There are two issues at hand: > i) what should be done about the codepoint value of 3? and > ii) what value should be assigned for the SONET/SDH TSPEC and > FLOWSPEC? > > Let me start with the second issue, as it is more relevant to CCAMP. > The responses I got unanimously state that the codepoint value used > for SONET/SDH TSPEC and FLOWSPEC is 4. There is a minor wrinkle here > that in Cisco's implementation, the initial version used 4 and a later > revision uses 3. Apart from that, all responses (from about 10 > independent implementations, if memory serves) indicated that they use > the value 4. > > On that basis, I would strongly recommend IANA to assign 4 for both > the C-Types of SONET/SDH TSPEC and FLOWSPEC. > I hope you also realize that it was pointed out that OIF has assumed the assigned value of 3 (probably because IANA had assigned it and published it on the iana web pages... Adrian has asked the question if it is indeed so or not). So if IANA changes it, it may be perceived by outside world as a weakness. Not sure it is.. but we should check (or so I think... IANA pls let us know what you think about this). Bert Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 Jan 2004 03:55:06 +0000 From: "Vishal Sharma" To: Cc: "CCAMP" , "MPLS" Subject: Outdated WG charters?! Date: Wed, 14 Jan 2004 19:53:47 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, It appears that the Charter updates posted by the IETF Secretariat at http://www.ietf.org/html.charters/wg-dir.html just this evening (at least) for CCAMP and MPLS WGs are completely outdated (over a year old). I believe an error was made in posting these, and it would be great if this could be corrected at the earliest (otherwise it's very difficult to access the latest WG documents). Thanks much! -Vishal PS: If I am the only one experiencing this problem, please let me know. I've flushed all caches and buffers, so I don't think the problem is at my end. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 Jan 2004 03:15:20 +0000 Date: Wed, 14 Jan 2004 19:13:22 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org cc: iana@iana.org Subject: RE: IANA assignments Message-ID: <20040114184237.F28722@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi All, On Fri, 9 Jan 2004, Kireeti Kompella wrote: > a) do you use the FLOWSPEC C-Type 3 for CoS? > b) have you implemented the SONET/SDH FLOWSPEC? If so, what value did > you use for the C-Type? > c) do you use the TSPEC C-Type 3 for CoS? > d) have you implemented the SONET/SDH TSPEC? If so, what value did > you use for the C-Type? There are two issues at hand: i) what should be done about the codepoint value of 3? and ii) what value should be assigned for the SONET/SDH TSPEC and FLOWSPEC? Let me start with the second issue, as it is more relevant to CCAMP. The responses I got unanimously state that the codepoint value used for SONET/SDH TSPEC and FLOWSPEC is 4. There is a minor wrinkle here that in Cisco's implementation, the initial version used 4 and a later revision uses 3. Apart from that, all responses (from about 10 independent implementations, if memory serves) indicated that they use the value 4. On that basis, I would strongly recommend IANA to assign 4 for both the C-Types of SONET/SDH TSPEC and FLOWSPEC. The other issue, what to do with the value of 3, is less clear. Most responses indicated that they either parsed and ignored or simply ignored this value. As CCAMP WG chair, I don't have a stand on whether this value should be set aside as reserved, or left as a hole in the address space, to be assigned to the next request for a code point for a TSPEC/FLOWSPEC C-Type. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 Jan 2004 22:28:38 +0000 Message-ID: <033b01c3daed$aa9ee430$715708c3@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Ben Mack-Crane" , Cc: Subject: Re: IANA assignments Date: Wed, 14 Jan 2004 22:27:53 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Erm, Which order this happen Ben? IANA or OIF first? Thanks, Adrian ----- Original Message ----- From: "Ben Mack-Crane" To: Cc: Sent: Wednesday, January 14, 2004 4:02 PM Subject: Re: IANA assignments > To add to Andy's factual response on Tellabs' implementations, > I would like to support Bert's messages on following the process > and also state that we are willing to update our implementation > to support the "right" codepoint. > > Other standards organizations depend on the stability of the > IANA process. For example, the recently approved OIF UNI1.0r2 IA > specifies the IANA assigned C-Type (3) for SONET/SDH TSPEC/FLOWSPEC. > This will be a problem if the IANA assignment is changed. > > Regards, > Ben Mack-Crane > > Andy.Malis@tellabs.com wrote: > > > Ditto for Tellabs (the same as Kireeti's answer). > > > > Andy > > > > ------------ > > > > At 1/9/2004 11:48 AM -0800, Kireeti Kompella wrote: > > > >> On Fri, 9 Jan 2004, Kireeti Kompella wrote: > >> > >> For the record, here is the answer from Juniper's implementation: > >> > >> > a) do you use the FLOWSPEC C-Type 3 for CoS? > >> > >> We parse this, but don't really use it. > >> > >> > b) have you implemented the SONET/SDH FLOWSPEC? If so, what value did > >> > you use for the C-Type? > >> > >> Yes. Value 4. > >> > >> > c) do you use the TSPEC C-Type 3 for CoS? > >> > >> We parse this, but don't really use it. > >> > >> > d) have you implemented the SONET/SDH TSPEC? If so, what value did > >> > you use for the C-Type? > >> > >> Yes. Value 4. > >> > >> Kireeti. > >> ------- > > > > > > > > ----------------------------------------- > ============================================================ > The information contained in this message may be privileged > and confidential and protected from disclosure. If the > reader of this message is not the intended recipient, or an > employee or agent responsible for delivering this message to > the intended recipient, you are hereby notified that any > reproduction, dissemination or distribution of this > communication is strictly prohibited. If you have received > this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. > > Thank you. > Tellabs > ============================================================ > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 Jan 2004 22:27:21 +0000 Message-ID: <033801c3daed$7c458120$715708c3@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Re: RFC3473 Date: Wed, 14 Jan 2004 22:26:31 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi M, I see the following in RFC3473... 2.3. Generalized Label Object The format of a Generalized Label object is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num (16)| C-Type (2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See [RFC3471] for a description of parameters and encoding of labels. Looks like a C-Num and a C-Type from where I'm standing. Cheers, Adrian ----- Original Message ----- From: To: Sent: Wednesday, January 14, 2004 4:35 PM Subject: RFC3473 > Hi, I was reading the RFC 3473 and observed that Class-Num and C-Type in label were not specified and it gives only reference to the RFC 3471 but there are no definition of Class-Num or C-Type defined in RFC 3471. > > So what is Class-Num and C-Type? > > M > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 Jan 2004 22:24:07 +0000 Message-ID: <032c01c3daec$eec4d580$715708c3@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "'mpls@uu.net'" , Subject: Temporary Registy for LSP-ATTRIBUTE flags Date: Wed, 14 Jan 2004 13:20:29 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit All, I have created a temporary registry for flags in the new LSP Attribute Flags TLV and RRO Attribute Flags RRO subobject as defined in draft-ietf-mpls-rsvpte-attributes. Please note that this is a temporary and provisional registry. It does not replace the IANA registration of these flags. Implementers are advised that an entry in this temporary registry does not guarantee the use of a particular bit in the final RFC. This registry does provide a place to register provisional bit assignments so that experimental implementations may hope to interwork and so that new Internet Drafts may suggest bit numbers that do not conflict. You can reach the registry at http://www.olddog.co.uk/lsp-attrib.txt If it would help you to have your bit-usage registered, please send me your registration requests. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 Jan 2004 16:36:24 +0000 From: Reply-To: m.kim2@chello.nl To: Subject: RFC3473 Date: Wed, 14 Jan 2004 17:35:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20040114163506.XUDS10991.amsfep18-int.chello.nl@localhost> Hi, I was reading the RFC 3473 and observed that Class-Num and C-Type in label were not specified and it gives only reference to the RFC 3471 but there are no definition of Class-Num or C-Type defined in RFC 3471. So what is Class-Num and C-Type? M Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 14 Jan 2004 16:09:46 +0000 Message-ID: <40056806.4030600@tellabs.com> Date: Wed, 14 Jan 2004 10:02:14 -0600 From: Ben Mack-Crane User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: Andy.Malis@tellabs.com CC: ccamp@ops.ietf.org Subject: Re: IANA assignments Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; format="flowed" To add to Andy's factual response on Tellabs' implementations, I would like to support Bert's messages on following the process and also state that we are willing to update our implementation to support the "right" codepoint. Other standards organizations depend on the stability of the IANA process. For example, the recently approved OIF UNI1.0r2 IA specifies the IANA assigned C-Type (3) for SONET/SDH TSPEC/FLOWSPEC. This will be a problem if the IANA assignment is changed. Regards, Ben Mack-Crane Andy.Malis@tellabs.com wrote: > Ditto for Tellabs (the same as Kireeti's answer). > > Andy > > ------------ > > At 1/9/2004 11:48 AM -0800, Kireeti Kompella wrote: > >> On Fri, 9 Jan 2004, Kireeti Kompella wrote: >> >> For the record, here is the answer from Juniper's implementation: >> >> > a) do you use the FLOWSPEC C-Type 3 for CoS? >> >> We parse this, but don't really use it. >> >> > b) have you implemented the SONET/SDH FLOWSPEC? If so, what value did >> > you use for the C-Type? >> >> Yes. Value 4. >> >> > c) do you use the TSPEC C-Type 3 for CoS? >> >> We parse this, but don't really use it. >> >> > d) have you implemented the SONET/SDH TSPEC? If so, what value did >> > you use for the C-Type? >> >> Yes. Value 4. >> >> Kireeti. >> ------- > > ----------------------------------------- ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 Jan 2004 19:40:14 +0000 Message-Id: <6.0.1.1.2.20040113140126.03356ec0@po1.vivacenetworks.com> Date: Tue, 13 Jan 2004 14:04:00 -0500 To: ccamp@ops.ietf.org From: "Andrew G. Malis" Subject: RE: IANA assignments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Ditto for Tellabs (the same as Kireeti's answer). Andy ------------ At 1/9/2004 11:48 AM -0800, Kireeti Kompella wrote: >On Fri, 9 Jan 2004, Kireeti Kompella wrote: > >For the record, here is the answer from Juniper's implementation: > > > a) do you use the FLOWSPEC C-Type 3 for CoS? > >We parse this, but don't really use it. > > > b) have you implemented the SONET/SDH FLOWSPEC? If so, what value did > > you use for the C-Type? > >Yes. Value 4. > > > c) do you use the TSPEC C-Type 3 for CoS? > >We parse this, but don't really use it. > > > d) have you implemented the SONET/SDH TSPEC? If so, what value did > > you use for the C-Type? > >Yes. Value 4. > >Kireeti. >------- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 Jan 2004 18:38:42 +0000 Message-Id: <200401131836.i0DIaPK6029538@rtp-core-2.cisco.com> To: Kireeti Kompella cc: ccamp@ops.ietf.org, iana@iana.org cc: swallow@cisco.com Subject: Re: IANA assignments Date: Tue, 13 Jan 2004 13:36:25 -0500 From: George Swallow > Okay, in order to come to some conclusion here, those of you who have > implemented RSVP-TE and/or GMPLS RSVP-TE please answer the following: > > a) do you use the FLOWSPEC C-Type 3 for CoS? No. > b) have you implemented the SONET/SDH FLOWSPEC? If so, what value did > you use for the C-Type? Yes, The initial release used 4. We have an updated release that uses 3. > c) do you use the TSPEC C-Type 3 for CoS? No, > d) have you implemented the SONET/SDH TSPEC? If so, what value did > you use for the C-Type? Yes, The initial release used 4. We have an updated release that uses 3. > Please send your answers to the mailing list or to the chairs AND ADs > at the latest by Wed Jan 14, 2004, 5pm PST. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 Jan 2004 15:25:35 +0000 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt Date: Tue, 13 Jan 2004 07:22:58 -0800 Message-ID: <23F5FB9E8B1C734F9633D9E1D336E88524D472@sb-exchange1.rinconnetworks.com> Thread-Topic: draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt thread-index: AcPWCY/ydztsK/XzQI+bP4OvcrnVogD3aLxQ From: "Jonathan Lang" To: Cc: All, The following typo has been pointed out in draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt and will be fixed during AUTH48. "0x0080 J2-trace: J2 Section Trace Correlation Capable of transmitting SONET/SDH VT SPE/LOVC Path trace over J2 Path overhead byte as defined in [T1.105] and [G.707]." should read "0x0080 J2-trace: J2 Path Trace Correlation Capable of transmitting SONET/SDH VT SPE/LOVC Path trace over J2 Path overhead byte as defined in [T1.105] and [G.707]." Thanks, Jonathan Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 Jan 2004 03:14:23 +0000 Message-ID: <1037EB10994D094790FC003F87DCC0BC024D3865@pine> From: "Pandian, Vijay" To: "'ccamp@ops.ietf.org'" Subject: draft-ietf-ccamp-ospf-gmpls-extensions-12.txt Date: Mon, 12 Jan 2004 22:10:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi, In section 1.4, the Switching Capability-specific information is described for all types of switching capabilities except for FSC. I assume there is no Switching Capability specific information present for FSC. Please clarify. Regards, Vijay Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 Jan 2004 03:11:04 +0000 Message-ID: <1037EB10994D094790FC003F87DCC0BC024D3864@pine> From: "Pandian, Vijay" To: "'ccamp@ops.ietf.org'" Subject: draft-ietf-ccamp-ospf-gmpls-extensions-12.txt Date: Mon, 12 Jan 2004 22:05:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi, In section 1.4, the Switching Capability-specific information is not described for all types of switching capabilities except for FSC. I assume there is no Switching Capability specific information present for FSC. Please clarify. Regards, Vijay Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 Jan 2004 10:39:30 +0000 Message-ID: <40027961.6070203@alcatel.be> Date: Mon, 12 Jan 2004 11:39:29 +0100 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: Diego Caviglia Cc: kireeti@juniper.net, ccamp@ops.ietf.org Subject: Re: draft-ietf-mpls-lsp-hierarchy-08 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed diego, the document is in the RFC Editor queue (per i-d status tracker) since nov'02 - thanks, d. Diego Caviglia wrote: > Hi all, > the ID in the subject expired in March 2002 is there any > intention to go on with work on FA? > > IMHO that was a good and very usefull work. > > Regards. > > Diego > > > > ------------------------------------------ > Diego Caviglia > Marconi - Optical Networks > ASTN/GMPLS - System Design Manager > Via A. Negrone 1/A > 16153 Genoa - Italy > Phone: +390106003736 > > "Timeo Danae et Dona Ferentes" > > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 Jan 2004 09:27:35 +0000 Sensitivity: Subject: draft-ietf-mpls-lsp-hierarchy-08 To: kireeti@juniper.net Cc: ccamp@ops.ietf.org From: "Diego Caviglia" Date: Mon, 12 Jan 2004 10:25:10 +0100 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset="us-ascii" Hi all, the ID in the subject expired in March 2002 is there any intention to go on with work on FA? IMHO that was a good and very usefull work. Regards. Diego ------------------------------------------ Diego Caviglia Marconi - Optical Networks ASTN/GMPLS - System Design Manager Via A. Negrone 1/A 16153 Genoa - Italy Phone: +390106003736 "Timeo Danae et Dona Ferentes" Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 11 Jan 2004 20:44:55 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155033D3C63@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: David Charlap , IETF CCAMP List Subject: RE: IANA assignments Date: Sun, 11 Jan 2004 21:39:18 +0100 MIME-Version: 1.0 Content-Type: text/plain Maybe... it might be good if people who have used un-reserved values for implementing ID-level specifications take a look at draft-narten-iana-experimental-allocations-05.txt and specifically section 1.1. It is only a page long that section. It explains why doing such things might be bad. Thanks, Bert Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 09 Jan 2004 22:08:36 +0000 Message-ID: <3FFF2648.6030205@alcatel.be> Date: Fri, 09 Jan 2004 23:08:08 +0100 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: IANA assignments Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed kireeti, historically value 4 has been considered for the TSPEC/FLOWSPEC, so this value has been used for our main implementation (started before the official IANA value assignment) note: it would be of interest to reach rapidly agreement on this since from my side any development initiated/ started after this consider the use the value assigned by IANA thanks, - dimitri. Kireeti Kompella wrote: > On Fri, 9 Jan 2004, Kireeti Kompella wrote: > > >>Okay, in order to come to some conclusion here, those of you who have >>implemented RSVP-TE and/or GMPLS RSVP-TE please answer the following: > > > > > For the record, here is the answer from Juniper's implementation: > > >>a) do you use the FLOWSPEC C-Type 3 for CoS? > > > We parse this, but don't really use it. > > >>b) have you implemented the SONET/SDH FLOWSPEC? If so, what value did >> you use for the C-Type? > > > Yes. Value 4. > > >>c) do you use the TSPEC C-Type 3 for CoS? > > > We parse this, but don't really use it. > > >>d) have you implemented the SONET/SDH TSPEC? If so, what value did >> you use for the C-Type? > > > Yes. Value 4. > > Kireeti. > ------- > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 09 Jan 2004 20:33:11 +0000 Message-ID: <3FFF103B.2090106@marconi.com> Date: Fri, 09 Jan 2004 15:34:03 -0500 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: IETF CCAMP List Subject: RE: IANA assignments Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kireeti Kompella wrote: > Okay, in order to come to some conclusion here, those of you who have > implemented RSVP-TE and/or GMPLS RSVP-TE please answer the following: This is for Marconi's RSVP-TE implementation. > a) do you use the FLOWSPEC C-Type 3 for CoS? Yes - for interoperability with other vendors that required it in the recent past and might still require it. > b) have you implemented the SONET/SDH FLOWSPEC? If so, what value did > you use for the C-Type? Not at this time. > c) do you use the TSPEC C-Type 3 for CoS? Yes - for interoperability. > d) have you implemented the SONET/SDH TSPEC? If so, what value did > you use for the C-Type? Not at this time. > Please send your answers to the mailing list or to the chairs AND ADs > at the latest by Wed Jan 14, 2004, 5pm PST. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 09 Jan 2004 20:26:20 +0000 Message-Id: <200401092025.i09KPDue032037@mailhost.avici.com> To: ccamp@ops.ietf.org Subject: Re: IANA assignments Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 09 Jan 2004 15:25:12 -0500 From: Markus Jork > Okay, in order to come to some conclusion here, those of you who have > implemented RSVP-TE and/or GMPLS RSVP-TE please answer the following: > > a) do you use the FLOWSPEC C-Type 3 for CoS? Yes. It's implemented but not being used. We already thought about taking the code out in future releases. > b) have you implemented the SONET/SDH FLOWSPEC? If so, what value did > you use for the C-Type? yes, 4 > c) do you use the TSPEC C-Type 3 for CoS? yes (plus same comment as in a) > d) have you implemented the SONET/SDH TSPEC? If so, what value did > you use for the C-Type? yes, 4 Markus Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 09 Jan 2004 20:00:25 +0000 Message-ID: <829F074A10F98943A218DC363D09C92A01476840@w2ksjexg06.oni.com> From: "Ong, Lyndon" To: 'Kireeti Kompella' , ccamp@ops.ietf.org Subject: RE: IANA assignments Date: Fri, 9 Jan 2004 11:59:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Kireeti, We assume 3 for CoS (but have not used it so far) and 4 for SONET/SDH FLOWSPEC/TSPEC. Cheers, Lyndon (Ciena) -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Friday, January 09, 2004 10:34 AM To: ccamp@ops.ietf.org Cc: iana@iana.org Subject: RE: IANA assignments Okay, in order to come to some conclusion here, those of you who have implemented RSVP-TE and/or GMPLS RSVP-TE please answer the following: a) do you use the FLOWSPEC C-Type 3 for CoS? b) have you implemented the SONET/SDH FLOWSPEC? If so, what value did you use for the C-Type? c) do you use the TSPEC C-Type 3 for CoS? d) have you implemented the SONET/SDH TSPEC? If so, what value did you use for the C-Type? Please send your answers to the mailing list or to the chairs AND ADs at the latest by Wed Jan 14, 2004, 5pm PST. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 09 Jan 2004 19:50:26 +0000 Date: Fri, 9 Jan 2004 11:49:53 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: RE: IANA assignments Message-ID: <20040109114901.U3667@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 9 Jan 2004, Kireeti Kompella wrote: > Okay, in order to come to some conclusion here, those of you who have > implemented RSVP-TE and/or GMPLS RSVP-TE please answer the following: ... > Please send your answers to the mailing list or to the chairs AND ADs > at the latest by Wed Jan 14, 2004, 5pm PST. Please don't copy IANA on the replies -- the chairs will summarize the results and conclusions to IANA. Thanks, Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 09 Jan 2004 19:49:37 +0000 Date: Fri, 9 Jan 2004 11:48:49 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: RE: IANA assignments Message-ID: <20040109114332.N3667@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 9 Jan 2004, Kireeti Kompella wrote: > Okay, in order to come to some conclusion here, those of you who have > implemented RSVP-TE and/or GMPLS RSVP-TE please answer the following: For the record, here is the answer from Juniper's implementation: > a) do you use the FLOWSPEC C-Type 3 for CoS? We parse this, but don't really use it. > b) have you implemented the SONET/SDH FLOWSPEC? If so, what value did > you use for the C-Type? Yes. Value 4. > c) do you use the TSPEC C-Type 3 for CoS? We parse this, but don't really use it. > d) have you implemented the SONET/SDH TSPEC? If so, what value did > you use for the C-Type? Yes. Value 4. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 09 Jan 2004 19:37:34 +0000 Message-ID: <3FFF02EE.8070002@alcatel.be> Date: Fri, 09 Jan 2004 20:37:18 +0100 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: rick king CC: ccamp@ops.ietf.org Subject: Re: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed thanks, i encourage the ccamp community to share any feedback they think relevant to make progress with this wg i-d and reach consensus toward a second rev. of this document (that i hope will be ready for last call, as expected) thanks, - dimitri. rick king wrote: > I think it's better now. Thank you for your kindly clarifying. > > Rick > > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Friday, January 09, 2004 7:34 AM > To: rick king > Cc: ccamp@ops.ietf.org > Subject: Re: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt > > > the RA represents a partition of the data plane and is used as the > representation of the data plane within the control plane, in the > next revision will include a statement on this since this may be > where the mis-understanding comes from, wrt to relationship with > the RC, the text will be clarified from: > > " - A RA MAY support different routing protocols. There SHOULD NOT be > any dependencies on the different routing protocols used. > - For a RA, the cluster of RCs is referred to as a routing domain. > The routing information exchanged between routing domains (i.e. > inter-domain) is independent of both the intra-domain routing > protocol and the intra-domain control distribution choice(s), e.g. > centralized, fully distributed." > > to: > > "- For a RA, the cluster of RCs is referred to as a routing (control) > domain. The RC MAY support more than one routing protocol. There > SHOULD NOT be any dependencies on the different routing protocols > used. > - The routing information exchanged between routing domains (i.e. > inter-domain) is independent of both the intra-domain routing > protocol and the intra-domain control distribution choice(s), e.g. > centralized, fully distributed." > > well hope this clarifies, > - dimitri. > > rick king wrote: > > >>Then what's relationship between a RA and a routing control domain? >> >>thanks >> >>Rick >> >>-----Original Message----- >>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Dimitri.Papadimitriou@alcatel.be >>Sent: Wednesday, January 07, 2004 6:57 AM >>To: rick king >>Cc: ccamp@ops.ietf.org >>Subject: Re: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt >> >> >>hi, thanks for commenting, see in-line: >> >>rick king wrote: >> >> >> >>>Some comments. Section 3. ......The ASON model allows for the protocols >>>used within different control domains to be different; and for the protocol >>>used between control domains to be different than the protocols used within >>>control domains. ...... >>> >>>The routing requirements contained in this draft apply to protocols used >>>between control domains(E-NNI routing) or protocols used within control >>>domains(I-NNI routing) or both? >> >> >>-> both >> >> >> >>>...... - For a RA, the cluster of RCs is referred to as a routing >>>domain...... >>> >>>Does this means that RA=routing domain? Maybe routing control domain is more >>>align with G.7715. >> >> >>-> yes, it is "routing (control) domain", we will clarify in the >> next version >> >> >> >>>Section 4.2.1 ...... - The second approach places the Level N routing >>>function on a separate system from the Level N+1 routing function. In this >>>case, a communication interface must be used between the systems containing >>>the routing functions for different levels. This communication interface and >>>mechanisms are outside the scope of this document. ....... >>> >>>Is it possible that the Level N routing function and the Level N+1 routing >>>function are from different vendors? If the answer is yes, then I think the >>>communication interface and mechanisms should be defined. Otherwise how can >>>you achieve inter-operate? >> >> >>-> it is expected to cover multi-vendor case (note that the other >> alternative is single vendor only) so that this "communication >> interface" is expected to be defined but it is not within the >> scope of this document, what's within the scope is the routing >> information exchanged (ie ways to achieve the communication >> interface between these systems is not) >> >>thanks, >>- dimitri. >> >> >> >>>Thank you. >>> >>>rick >>> >>>-----Original Message----- From: owner-ccamp@ops.ietf.org >>>[mailto:owner-ccamp@ops.ietf.org]On Behalf Of >>>Dimitri.Papadimitriou@alcatel.be Sent: Tuesday, December 30, 2003 5:19 AM To: >>>ccamp@ops.ietf.org Subject: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt >>> >>> >>>all, >>> >>>the following version of the "ASON routing requirements" document completes >>>the template proposed in the v00.txt: >>> >>> >>> >>> >>>please provide any comment you think relevant in order to progress this wg >>>i-d >>> >>>thanks, - dimitri. >>> >> >> > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 09 Jan 2004 18:35:56 +0000 Date: Fri, 9 Jan 2004 10:34:16 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org cc: iana@iana.org Subject: RE: IANA assignments Message-ID: <20040109102052.Q3667@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Okay, in order to come to some conclusion here, those of you who have implemented RSVP-TE and/or GMPLS RSVP-TE please answer the following: a) do you use the FLOWSPEC C-Type 3 for CoS? b) have you implemented the SONET/SDH FLOWSPEC? If so, what value did you use for the C-Type? c) do you use the TSPEC C-Type 3 for CoS? d) have you implemented the SONET/SDH TSPEC? If so, what value did you use for the C-Type? Please send your answers to the mailing list or to the chairs AND ADs at the latest by Wed Jan 14, 2004, 5pm PST. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 09 Jan 2004 04:56:37 +0000 From: "rick king" To: Cc: Subject: RE: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt Date: Fri, 9 Jan 2004 12:53:23 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SSB0aGluayBpdCdzIGJldHRlciBub3cuIFRoYW5rIHlvdSBmb3IgeW91ciBraW5kbHkgY2xhcmlm eWluZy4NCg0KUmljaw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGltaXRy aS5QYXBhZGltaXRyaW91QGFsY2F0ZWwuYmUgW21haWx0bzpEaW1pdHJpLlBhcGFkaW1pdHJpb3VA YWxjYXRlbC5iZV0NClNlbnQ6IEZyaWRheSwgSmFudWFyeSAwOSwgMjAwNCA3OjM0IEFNDQpUbzog cmljayBraW5nDQpDYzogY2NhbXBAb3BzLmlldGYub3JnDQpTdWJqZWN0OiBSZTogZHJhZnQtaWV0 Zi1jY2FtcC1nbXBscy1hc29uLXJvdXRpbmctcmVxdHMtMDEudHh0DQoNCg0KdGhlIFJBIHJlcHJl c2VudHMgYSBwYXJ0aXRpb24gb2YgdGhlIGRhdGEgcGxhbmUgYW5kIGlzIHVzZWQgYXMgdGhlIA0K cmVwcmVzZW50YXRpb24gb2YgdGhlIGRhdGEgcGxhbmUgd2l0aGluIHRoZSBjb250cm9sIHBsYW5l LCBpbiB0aGUNCm5leHQgcmV2aXNpb24gd2lsbCBpbmNsdWRlIGEgc3RhdGVtZW50IG9uIHRoaXMg c2luY2UgdGhpcyBtYXkgYmUNCndoZXJlIHRoZSBtaXMtdW5kZXJzdGFuZGluZyBjb21lcyBmcm9t LCB3cnQgdG8gcmVsYXRpb25zaGlwIHdpdGgNCnRoZSBSQywgdGhlIHRleHQgd2lsbCBiZSBjbGFy aWZpZWQgZnJvbToNCg0KICAgIiAtIEEgUkEgTUFZIHN1cHBvcnQgZGlmZmVyZW50IHJvdXRpbmcg cHJvdG9jb2xzLiBUaGVyZSBTSE9VTEQgTk9UIGJlDQogICAgICAgYW55IGRlcGVuZGVuY2llcyBv biB0aGUgZGlmZmVyZW50IHJvdXRpbmcgcHJvdG9jb2xzIHVzZWQuDQogICAgIC0gRm9yIGEgUkEs IHRoZSBjbHVzdGVyIG9mIFJDcyBpcyByZWZlcnJlZCB0byBhcyBhIHJvdXRpbmcgZG9tYWluLg0K ICAgICAgIFRoZSByb3V0aW5nIGluZm9ybWF0aW9uIGV4Y2hhbmdlZCBiZXR3ZWVuIHJvdXRpbmcg ZG9tYWlucyAoaS5lLg0KICAgICAgIGludGVyLWRvbWFpbikgaXMgaW5kZXBlbmRlbnQgb2YgYm90 aCB0aGUgaW50cmEtZG9tYWluIHJvdXRpbmcNCiAgICAgICBwcm90b2NvbCBhbmQgdGhlIGludHJh LWRvbWFpbiBjb250cm9sIGRpc3RyaWJ1dGlvbiBjaG9pY2UocyksIGUuZy4NCiAgICAgICBjZW50 cmFsaXplZCwgZnVsbHkgZGlzdHJpYnV0ZWQuIg0KDQp0bzoNCg0KICAgICItIEZvciBhIFJBLCB0 aGUgY2x1c3RlciBvZiBSQ3MgaXMgcmVmZXJyZWQgdG8gYXMgYSByb3V0aW5nIChjb250cm9sKQ0K ICAgICAgIGRvbWFpbi4gVGhlIFJDIE1BWSBzdXBwb3J0IG1vcmUgdGhhbiBvbmUgcm91dGluZyBw cm90b2NvbC4gVGhlcmUNCiAgICAgICBTSE9VTEQgTk9UIGJlIGFueSBkZXBlbmRlbmNpZXMgb24g dGhlIGRpZmZlcmVudCByb3V0aW5nIHByb3RvY29scw0KICAgICAgIHVzZWQuDQogICAgIC0gVGhl IHJvdXRpbmcgaW5mb3JtYXRpb24gZXhjaGFuZ2VkIGJldHdlZW4gcm91dGluZyBkb21haW5zIChp LmUuDQogICAgICAgaW50ZXItZG9tYWluKSBpcyBpbmRlcGVuZGVudCBvZiBib3RoIHRoZSBpbnRy YS1kb21haW4gcm91dGluZw0KICAgICAgIHByb3RvY29sIGFuZCB0aGUgaW50cmEtZG9tYWluIGNv bnRyb2wgZGlzdHJpYnV0aW9uIGNob2ljZShzKSwgZS5nLg0KICAgICAgIGNlbnRyYWxpemVkLCBm dWxseSBkaXN0cmlidXRlZC4iDQoNCndlbGwgaG9wZSB0aGlzIGNsYXJpZmllcywNCi0gZGltaXRy aS4NCg0KcmljayBraW5nIHdyb3RlOg0KDQo+IFRoZW4gd2hhdCdzIHJlbGF0aW9uc2hpcCBiZXR3 ZWVuIGEgUkEgYW5kIGEgcm91dGluZyBjb250cm9sIGRvbWFpbj8NCj4gDQo+IHRoYW5rcw0KPiAN Cj4gUmljaw0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogb3duZXIt Y2NhbXBAb3BzLmlldGYub3JnIFttYWlsdG86b3duZXItY2NhbXBAb3BzLmlldGYub3JnXU9uIEJl aGFsZiBPZiBEaW1pdHJpLlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZQ0KPiBTZW50OiBXZWRuZXNk YXksIEphbnVhcnkgMDcsIDIwMDQgNjo1NyBBTQ0KPiBUbzogcmljayBraW5nDQo+IENjOiBjY2Ft cEBvcHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtYXNv bi1yb3V0aW5nLXJlcXRzLTAxLnR4dA0KPiANCj4gDQo+IGhpLCB0aGFua3MgZm9yIGNvbW1lbnRp bmcsIHNlZSBpbi1saW5lOg0KPiANCj4gcmljayBraW5nIHdyb3RlOg0KPiANCj4gDQo+PlNvbWUg Y29tbWVudHMuIFNlY3Rpb24gMy4gICAuLi4uLi5UaGUgIEFTT04gbW9kZWwgYWxsb3dzIGZvciB0 aGUgcHJvdG9jb2xzDQo+PnVzZWQgd2l0aGluIGRpZmZlcmVudCBjb250cm9sIGRvbWFpbnMgdG8g YmUgZGlmZmVyZW50OyBhbmQgZm9yIHRoZSBwcm90b2NvbA0KPj51c2VkIGJldHdlZW4gY29udHJv bCBkb21haW5zIHRvIGJlIGRpZmZlcmVudCB0aGFuIHRoZSBwcm90b2NvbHMgdXNlZCB3aXRoaW4N Cj4+Y29udHJvbCBkb21haW5zLiAuLi4uLi4NCj4+DQo+PlRoZSByb3V0aW5nIHJlcXVpcmVtZW50 cyBjb250YWluZWQgaW4gdGhpcyBkcmFmdCBhcHBseSB0byBwcm90b2NvbHMgdXNlZA0KPj5iZXR3 ZWVuIGNvbnRyb2wgZG9tYWlucyhFLU5OSSByb3V0aW5nKSBvciBwcm90b2NvbHMgdXNlZCB3aXRo aW4gY29udHJvbA0KPj5kb21haW5zKEktTk5JIHJvdXRpbmcpIG9yIGJvdGg/DQo+IA0KPiANCj4g LT4gYm90aA0KPiANCj4gDQo+Pi4uLi4uLiAtIEZvciBhIFJBLCB0aGUgY2x1c3RlciBvZiBSQ3Mg aXMgcmVmZXJyZWQgdG8gYXMgYSByb3V0aW5nDQo+PmRvbWFpbi4uLi4uLg0KPj4NCj4+RG9lcyB0 aGlzIG1lYW5zIHRoYXQgUkE9cm91dGluZyBkb21haW4/IE1heWJlIHJvdXRpbmcgY29udHJvbCBk b21haW4gaXMgbW9yZQ0KPj5hbGlnbiB3aXRoIEcuNzcxNS4NCj4gDQo+IA0KPiAtPiB5ZXMsIGl0 IGlzICJyb3V0aW5nIChjb250cm9sKSBkb21haW4iLCB3ZSB3aWxsIGNsYXJpZnkgaW4gdGhlDQo+ ICAgICBuZXh0IHZlcnNpb24NCj4gDQo+IA0KPj5TZWN0aW9uIDQuMi4xICAgIC4uLi4uLiAgIC0g VGhlIHNlY29uZCBhcHByb2FjaCBwbGFjZXMgdGhlIExldmVsIE4gcm91dGluZw0KPj5mdW5jdGlv biBvbiBhIHNlcGFyYXRlIHN5c3RlbSBmcm9tIHRoZSBMZXZlbCBOKzEgcm91dGluZyBmdW5jdGlv bi4gSW4gdGhpcyANCj4+Y2FzZSwgYSBjb21tdW5pY2F0aW9uIGludGVyZmFjZSBtdXN0IGJlIHVz ZWQgYmV0d2VlbiB0aGUgc3lzdGVtcyBjb250YWluaW5nDQo+PnRoZSByb3V0aW5nIGZ1bmN0aW9u cyBmb3IgZGlmZmVyZW50IGxldmVscy4gVGhpcyBjb21tdW5pY2F0aW9uIGludGVyZmFjZSBhbmQN Cj4+bWVjaGFuaXNtcyBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gLi4u Li4uLg0KPj4NCj4+SXMgaXQgcG9zc2libGUgdGhhdCB0aGUgTGV2ZWwgTiByb3V0aW5nIGZ1bmN0 aW9uIGFuZCAgdGhlIExldmVsIE4rMSByb3V0aW5nDQo+PmZ1bmN0aW9uIGFyZSBmcm9tIGRpZmZl cmVudCB2ZW5kb3JzPyBJZiB0aGUgYW5zd2VyIGlzIHllcywgdGhlbiBJIHRoaW5rIHRoZQ0KPj5j b21tdW5pY2F0aW9uIGludGVyZmFjZSBhbmQgbWVjaGFuaXNtcyBzaG91bGQgYmUgZGVmaW5lZC4g T3RoZXJ3aXNlIGhvdyBjYW4NCj4+eW91IGFjaGlldmUgaW50ZXItb3BlcmF0ZT8NCj4gDQo+IA0K PiAtPiBpdCBpcyBleHBlY3RlZCB0byBjb3ZlciBtdWx0aS12ZW5kb3IgY2FzZSAobm90ZSB0aGF0 IHRoZSBvdGhlcg0KPiAgICAgYWx0ZXJuYXRpdmUgaXMgc2luZ2xlIHZlbmRvciBvbmx5KSBzbyB0 aGF0IHRoaXMgImNvbW11bmljYXRpb24NCj4gICAgIGludGVyZmFjZSIgaXMgZXhwZWN0ZWQgdG8g YmUgZGVmaW5lZCBidXQgaXQgaXMgbm90IHdpdGhpbiB0aGUNCj4gICAgIHNjb3BlIG9mIHRoaXMg ZG9jdW1lbnQsIHdoYXQncyB3aXRoaW4gdGhlIHNjb3BlIGlzIHRoZSByb3V0aW5nDQo+ICAgICBp bmZvcm1hdGlvbiBleGNoYW5nZWQgKGllIHdheXMgdG8gYWNoaWV2ZSB0aGUgY29tbXVuaWNhdGlv bg0KPiAgICAgaW50ZXJmYWNlIGJldHdlZW4gdGhlc2Ugc3lzdGVtcyBpcyBub3QpDQo+IA0KPiB0 aGFua3MsDQo+IC0gZGltaXRyaS4NCj4gDQo+IA0KPj5UaGFuayB5b3UuDQo+Pg0KPj5yaWNrDQo+ Pg0KPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBvd25lci1jY2FtcEBvcHMuaWV0 Zi5vcmcNCj4+W21haWx0bzpvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmddT24gQmVoYWxmIE9mDQo+ PkRpbWl0cmkuUGFwYWRpbWl0cmlvdUBhbGNhdGVsLmJlIFNlbnQ6IFR1ZXNkYXksIERlY2VtYmVy IDMwLCAyMDAzIDU6MTkgQU0gVG86DQo+PmNjYW1wQG9wcy5pZXRmLm9yZyBTdWJqZWN0OiBkcmFm dC1pZXRmLWNjYW1wLWdtcGxzLWFzb24tcm91dGluZy1yZXF0cy0wMS50eHQNCj4+DQo+Pg0KPj5h bGwsDQo+Pg0KPj50aGUgZm9sbG93aW5nIHZlcnNpb24gb2YgdGhlICJBU09OIHJvdXRpbmcgcmVx dWlyZW1lbnRzIiBkb2N1bWVudCBjb21wbGV0ZXMNCj4+dGhlIHRlbXBsYXRlIHByb3Bvc2VkIGlu IHRoZSB2MDAudHh0Og0KPj4NCj4+PGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWlldGYtY2NhbXAtZ21wbHMtYXNvbi1yb3V0aW5nLXJlcXRzLTAxLnR4dD4NCj4+DQo+ Pg0KPj5wbGVhc2UgcHJvdmlkZSBhbnkgY29tbWVudCB5b3UgdGhpbmsgcmVsZXZhbnQgaW4gb3Jk ZXIgdG8gcHJvZ3Jlc3MgdGhpcyB3Zw0KPj5pLWQNCj4+DQo+PnRoYW5rcywgLSBkaW1pdHJpLg0K Pj4NCj4gDQo+IA0KDQotLSANClBhcGFkaW1pdHJpb3UgRGltaXRyaQ0KRS1tYWlsIDogZGltaXRy aS5wYXBhZGltaXRyaW91QGFsY2F0ZWwuYmUNCkUtbWFpbCA6IGRwYXBhZGltaXRyaW91QHBzZy5j b20NCldlYnBhZ2U6IGh0dHA6Ly9wc2cuY29tL35kcGFwYWRpbWl0cmlvdS8NCkFkZHJlc3M6IEZy LiBXZWxsZXNwbGVpbiAxLCBCLTIwMTggQW50d2VycGVuLCBCZWxnaXVtDQpQaG9uZSAgOiArMzIg MyAyNDAtODQ5MQ0K Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 08 Jan 2004 23:33:53 +0000 Message-ID: <3FFDE8CA.4030300@alcatel.be> Date: Fri, 09 Jan 2004 00:33:30 +0100 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: rick king CC: ccamp@ops.ietf.org Subject: Re: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed the RA represents a partition of the data plane and is used as the representation of the data plane within the control plane, in the next revision will include a statement on this since this may be where the mis-understanding comes from, wrt to relationship with the RC, the text will be clarified from: " - A RA MAY support different routing protocols. There SHOULD NOT be any dependencies on the different routing protocols used. - For a RA, the cluster of RCs is referred to as a routing domain. The routing information exchanged between routing domains (i.e. inter-domain) is independent of both the intra-domain routing protocol and the intra-domain control distribution choice(s), e.g. centralized, fully distributed." to: "- For a RA, the cluster of RCs is referred to as a routing (control) domain. The RC MAY support more than one routing protocol. There SHOULD NOT be any dependencies on the different routing protocols used. - The routing information exchanged between routing domains (i.e. inter-domain) is independent of both the intra-domain routing protocol and the intra-domain control distribution choice(s), e.g. centralized, fully distributed." well hope this clarifies, - dimitri. rick king wrote: > Then what's relationship between a RA and a routing control domain? > > thanks > > Rick > > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Dimitri.Papadimitriou@alcatel.be > Sent: Wednesday, January 07, 2004 6:57 AM > To: rick king > Cc: ccamp@ops.ietf.org > Subject: Re: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt > > > hi, thanks for commenting, see in-line: > > rick king wrote: > > >>Some comments. Section 3. ......The ASON model allows for the protocols >>used within different control domains to be different; and for the protocol >>used between control domains to be different than the protocols used within >>control domains. ...... >> >>The routing requirements contained in this draft apply to protocols used >>between control domains(E-NNI routing) or protocols used within control >>domains(I-NNI routing) or both? > > > -> both > > >>...... - For a RA, the cluster of RCs is referred to as a routing >>domain...... >> >>Does this means that RA=routing domain? Maybe routing control domain is more >>align with G.7715. > > > -> yes, it is "routing (control) domain", we will clarify in the > next version > > >>Section 4.2.1 ...... - The second approach places the Level N routing >>function on a separate system from the Level N+1 routing function. In this >>case, a communication interface must be used between the systems containing >>the routing functions for different levels. This communication interface and >>mechanisms are outside the scope of this document. ....... >> >>Is it possible that the Level N routing function and the Level N+1 routing >>function are from different vendors? If the answer is yes, then I think the >>communication interface and mechanisms should be defined. Otherwise how can >>you achieve inter-operate? > > > -> it is expected to cover multi-vendor case (note that the other > alternative is single vendor only) so that this "communication > interface" is expected to be defined but it is not within the > scope of this document, what's within the scope is the routing > information exchanged (ie ways to achieve the communication > interface between these systems is not) > > thanks, > - dimitri. > > >>Thank you. >> >>rick >> >>-----Original Message----- From: owner-ccamp@ops.ietf.org >>[mailto:owner-ccamp@ops.ietf.org]On Behalf Of >>Dimitri.Papadimitriou@alcatel.be Sent: Tuesday, December 30, 2003 5:19 AM To: >>ccamp@ops.ietf.org Subject: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt >> >> >>all, >> >>the following version of the "ASON routing requirements" document completes >>the template proposed in the v00.txt: >> >> >> >> >>please provide any comment you think relevant in order to progress this wg >>i-d >> >>thanks, - dimitri. >> > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 08 Jan 2004 16:30:13 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155033D389A@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: David Charlap , IETF CCAMP List , iana@iana.org Subject: RE: IANA assignments Date: Thu, 8 Jan 2004 17:13:03 +0100 MIME-Version: 1.0 Content-Type: text/plain > Dimitri.Papadimitriou@alcatel.be wrote: > > to what *change* do you refer here, when you say > > > > " If not, at least, isn't it a good idea to let the WG know > > the rational reason behind changing the proposed value in the > > draft ?" > > > > The SENDER_TSPEC/FLOWSPEC values were always mentioned as TBA > > and value 3 has never been reserved - > > The value 3 was specified for the old RSVP-TE draft. > > Yes, there was no value specified in the GMPLS-SONET/SDH draft. > > So how did IANA assign a value? And why did they choose to assign a > value to this draft, when they aren't assigning values to other > important drafts (like DiffServ-TE)? > They do NOT assign a value to just a DRAFT They assign a value to a DRAFT AFTER it has been approved by IESG and put into RFC-Editor and IANA queues for final processing. That NEVER happend to the old RSVP draft, and so that old draft NEVER HAD a VALID assignment. Bert > -- David > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 08 Jan 2004 16:21:24 +0000 Message-ID: <3FFD83A2.2030404@alcatel.be> Date: Thu, 08 Jan 2004 17:21:54 +0100 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: David Charlap Cc: IETF CCAMP List , iana@iana.org Subject: Re: IANA assignments Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed the "draft" is in the RFC Editor queue and blocked due to a reference to [GMPLS-ARCH] otherwise it should have been out now with an RFC number. David Charlap wrote: > Dimitri.Papadimitriou@alcatel.be wrote: > >> to what *change* do you refer here, when you say >> >> " If not, at least, isn't it a good idea to let the WG know >> the rational reason behind changing the proposed value in the >> draft ?" >> >> The SENDER_TSPEC/FLOWSPEC values were always mentioned as TBA >> and value 3 has never been reserved - > > > The value 3 was specified for the old RSVP-TE draft. > > Yes, there was no value specified in the GMPLS-SONET/SDH draft. > > So how did IANA assign a value? And why did they choose to assign a > value to this draft, when they aren't assigning values to other > important drafts (like DiffServ-TE)? > > -- David > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 08 Jan 2004 16:02:36 +0000 Message-ID: <3FFD7F60.8050605@marconi.com> Date: Thu, 08 Jan 2004 11:03:44 -0500 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: IETF CCAMP List , iana@iana.org Subject: Re: IANA assignments Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dimitri.Papadimitriou@alcatel.be wrote: > to what *change* do you refer here, when you say > > " If not, at least, isn't it a good idea to let the WG know > the rational reason behind changing the proposed value in the > draft ?" > > The SENDER_TSPEC/FLOWSPEC values were always mentioned as TBA > and value 3 has never been reserved - The value 3 was specified for the old RSVP-TE draft. Yes, there was no value specified in the GMPLS-SONET/SDH draft. So how did IANA assign a value? And why did they choose to assign a value to this draft, when they aren't assigning values to other important drafts (like DiffServ-TE)? -- David Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 08 Jan 2004 16:02:20 +0000 Message-ID: <39469E08BD83D411A3D900204840EC55FB716D@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Dimitri.Papadimitriou@alcatel.be'" Cc: "'Wijnen, Bert (Bert)'" , IETF CCAMP List , iana@iana.org Subject: RE: IANA assignments Date: Thu, 8 Jan 2004 11:00:47 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Dimitri, -> to what *change* do you refer here, when you say -> -> " If not, at least, isn't it a good idea to let the WG know -> the rational reason behind changing the proposed value in the -> draft ?" -> -> The SENDER_TSPEC/FLOWSPEC values were always mentioned as TBA -> and value 3 has never been reserved - I am referring to old expired long lived RSVP-TE drafts which used C-Type 3 and we all implemented and shipped with 3. When we decide to remove C-Type, isn't it good to reserve at the change/deprecating time ? (draft-ietf-mpls-rsvp-lsp-tunnel-07.txt was published in Aug 2000 and draft-ietf-mpls-rsvp-lsp-tunnel-08.txt was published in Feb 2001) All I am saying is, IANA can have a guideline for long lived drafts, such as: If there is a shipped implementation with an old deprecated value, that value MUST be reserved to prevent future misuse. It MUST be noted in the subsequent drafts and final RFC. Venkata. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 08 Jan 2004 15:35:41 +0000 Message-ID: <3FFD78E0.8090104@alcatel.be> Date: Thu, 08 Jan 2004 16:36:00 +0100 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: "Naidu, Venkata" Cc: "'Wijnen, Bert (Bert)'" , IETF CCAMP List , iana@iana.org Subject: Re: IANA assignments Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed to what *change* do you refer here, when you say " If not, at least, isn't it a good idea to let the WG know the rational reason behind changing the proposed value in the draft ?" The SENDER_TSPEC/FLOWSPEC values were always mentioned as TBA and value 3 has never been reserved - Naidu, Venkata wrote: > Bert, > > -> NOPE, cause it would not have been assigned based on the fact that > -> it is in some ID. > -> > -> > IMO this is an IANA process issue, but we've been here before > -> > (at least some of us), and never really resolved anything. > -> > (A simple solution would be to reserve values for long lived drafts > -> > and formally assign on RFC publication or return the values if/when > -> > the draft dies.) > -> > > -> NOPE. The simple solution is that you request a value in > -> experimental > -> space while the ID is progressing and being discussed. Only at final > -> ID approval and RFC-publication will a value in the STDS track space > -> be assigned. > > Is it possible for IANA to initiate a discussion in the mailing-list > before publishing a value, at least, for long lived drafts ? So that > we come to a consensus before assigning a value. If not, at least, > isn't it a good idea to let the WG know the rational reason behind > changing the proposed value in the draft ? > > Venkata. > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 08 Jan 2004 15:28:11 +0000 Message-ID: <39469E08BD83D411A3D900204840EC55FB716C@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Wijnen, Bert (Bert)'" , IETF CCAMP List Cc: iana@iana.org Subject: RE: IANA assignments Date: Thu, 8 Jan 2004 10:27:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Bert, -> NOPE, cause it would not have been assigned based on the fact that -> it is in some ID. -> -> > IMO this is an IANA process issue, but we've been here before -> > (at least some of us), and never really resolved anything. -> > (A simple solution would be to reserve values for long lived drafts -> > and formally assign on RFC publication or return the values if/when -> > the draft dies.) -> > -> NOPE. The simple solution is that you request a value in -> experimental -> space while the ID is progressing and being discussed. Only at final -> ID approval and RFC-publication will a value in the STDS track space -> be assigned. Is it possible for IANA to initiate a discussion in the mailing-list before publishing a value, at least, for long lived drafts ? So that we come to a consensus before assigning a value. If not, at least, isn't it a good idea to let the WG know the rational reason behind changing the proposed value in the draft ? Venkata. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 08 Jan 2004 15:17:04 +0000 Message-Id: <200401081515.i08FFQLE002409@rtp-core-1.cisco.com> To: "Wijnen, Bert (Bert)" cc: Lou Berger , David Charlap , IETF CCAMP List , iana@iana.org Subject: Re: IANA assignments Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 08 Jan 2004 10:15:26 -0500 From: Eric Rosen Bert> The simple solution is that you request a value in experimental space Bert> while the ID is progressing and being discussed. Only at final ID Bert> approval and RFC-publication will a value in the STDS track space be Bert> assigned. This will result in a situation where the value from the experimental space becomes the de facto standard. That seems a bit silly. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 08 Jan 2004 13:44:33 +0000 Message-Id: <4.3.2.7.2.20040108081533.02859140@mo-ex1> Date: Thu, 08 Jan 2004 08:42:49 -0500 To: "Wijnen, Bert (Bert)" From: Lou Berger Subject: RE: IANA assignments Cc: "David Charlap" , "IETF CCAMP List" , , lberger@movaz.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed humm, I think we're debating two points. One we agree on the other I'm not sure about. Point 1: (re)assignment of values removed from or used in dead drafts. I'm all for this and agree that these values should be reused. Point 2: temporary assignment of *real* values for long lived drafts. I think we disagree here, but am not sure. There needs to be a way to tentatively assign values to ensure interoperable implementations of drafts. Sure when the draft doesn't make it to RFC, point 1 applies and the values are free for reuse. As there is no IANA process that supports this, the implementation community resorts to agreeing on values. Changing these values at RFC publication time serves no purpose other than disrupting the vendor and service provider communities. In this case, the draft has been stable for 2+ years. There have been *many* implementations, many interop tests, and even deployments. There are also derivative works (OIF and ITU). All use the same value here. It serves no one in the community to change the value at this time. All it does is destabilize an otherwise stable technology. In short, IANA should formally assign the values that have been used for the past few years. I would love for IANA/IESG to come up with a formal procedure to deal with this real interoperability issue. Lou At 06:43 AM 1/8/2004, Wijnen, Bert (Bert) wrote: > > Bert, > > Got to say I agree with David on this. There is a > > long standing issue with IANA assignments for long lived drafts. > > We hit this with MPLS, GMPLS and now this document. > > > > The way this was resolved in the past was to make a formal request to IANA > > that included specific values and then for implementations to use these > > values until the formal assignment was made. > >NOPE,. NOPE and NOPE. I (and IANA, and our IANA rules/guidelines) are >OK with a WG asking for a specific value (in a ID), but that does NOT >mean that early implementors can or should use that value. >Because it CAN and WILL be taken away for otehr assignments when the >ID does not make it to RFC. > > > I think that the request for assignment of a specific value (3) got > > dropped in this case. > > If that had been made, all would be good. > > >NOPE, cause it would not have been assigned based on the fact that >it is in some ID. > > > IMO this is an IANA process issue, but we've been here before > > (at least some of us), and never really resolved anything. > > (A simple solution would be to reserve values for long lived drafts > > and formally assign on RFC publication or return the values if/when > > the draft dies.) > > >NOPE. The simple solution is that you request a value in experimental >space while the ID is progressing and being discussed. Only at final >ID approval and RFC-publication will a value in the STDS track space >be assigned. > >Bert > > Lou > > > > > -----Original Message----- > > > > From: David Charlap > > > > [<mailto:David.Charlap@marconi.com>mailto:David.Charlap@marconi.com] > > > > > Sent: dinsdag 6 januari 2004 18:34 > > > > To: IETF CCAMP List > > > > Subject: IANA assignments > > > > > > > > > > > > Today, I was going through the IANA assignements for RSVP > > > > > > > > > > (<http://www.iana.org/assignments/rsvp-parameters>http://www.i > >ana.org/assignments/rsvp-parameters) > > and noticed > > > what may be a problem. > > > > > > The SONET/SDH FLOWSPEC C-Type > > > (draft-ietf-ccamp-gmpls-sonet-sdh-08.txt) > > > is assigned the value 3. > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 08 Jan 2004 11:45:28 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155033D3792@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Lou Berger , "Wijnen, Bert (Bert)" Cc: David Charlap , IETF CCAMP List , iana@iana.org Subject: RE: IANA assignments Date: Thu, 8 Jan 2004 12:43:26 +0100 MIME-Version: 1.0 Content-Type: text/plain > Bert, > Got to say I agree with David on this. There is a > long standing issue with IANA assignments for long lived drafts. > We hit this with MPLS, GMPLS and now this document. > > The way this was resolved in the past was to make a formal request to IANA > that included specific values and then for implementations to use these > values until the formal assignment was made. NOPE,. NOPE and NOPE. I (and IANA, and our IANA rules/guidelines) are OK with a WG asking for a specific value (in a ID), but that does NOT mean that early implementors can or should use that value. Because it CAN and WILL be taken away for otehr assignments when the ID does not make it to RFC. > I think that the request for assignment of a specific value (3) got > dropped in this case. > If that had been made, all would be good. > NOPE, cause it would not have been assigned based on the fact that it is in some ID. > IMO this is an IANA process issue, but we've been here before > (at least some of us), and never really resolved anything. > (A simple solution would be to reserve values for long lived drafts > and formally assign on RFC publication or return the values if/when > the draft dies.) > NOPE. The simple solution is that you request a value in experimental space while the ID is progressing and being discussed. Only at final ID approval and RFC-publication will a value in the STDS track space be assigned. Bert > Lou > > > -----Original Message----- > > > From: David Charlap > > [mailto:David.Charlap@marconi.com] > > > Sent: dinsdag 6 januari 2004 18:34 > > > To: IETF CCAMP List > > > Subject: IANA assignments > > > > > > > > > Today, I was going through the IANA assignements for RSVP > > > > > > (http://www.i ana.org/assignments/rsvp-parameters) > and noticed > > what may be a problem. > > > > The SONET/SDH FLOWSPEC C-Type > > (draft-ietf-ccamp-gmpls-sonet-sdh-08.txt) > > is assigned the value 3. > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 08 Jan 2004 00:37:53 +0000 Message-Id: <4.3.2.7.2.20040107192604.00b231a0@mo-ex1> Date: Wed, 07 Jan 2004 19:35:02 -0500 To: "Wijnen, Bert (Bert)" From: Lou Berger Subject: RE: IANA assignments Cc: "David Charlap" , "IETF CCAMP List" , iana@iana.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Bert, Got to say I agree with David on this. There is a long standing issue with IANA assignments for long lived drafts. We hit this with MPLS, GMPLS and now this document. The way this was resolved in the past was to make a formal request to IANA that included specific values and then for implementations to use these values until the formal assignment was made. I think that the request for assignment of a specific value (3) got dropped in this case. If that had been made, all would be good. IMO this is an IANA process issue, but we've been here before (at least some of us), and never really resolved anything. (A simple solution would be to reserve values for long lived drafts and formally assign on RFC publication or return the values if/when the draft dies.) Lou > -----Original Message----- > > From: David Charlap > [mailto:David.Charlap@marconi.com] > > Sent: dinsdag 6 januari 2004 18:34 > > To: IETF CCAMP List > > Subject: IANA assignments > > > > > > Today, I was going through the IANA assignements for RSVP > > > (http://www.iana.org/assignments/rsvp-parameters) > and noticed > > what may be a problem. > > > > The SONET/SDH FLOWSPEC C-Type > > (draft-ietf-ccamp-gmpls-sonet-sdh-08.txt) > > is assigned the value 3. > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 07 Jan 2004 17:29:15 +0000 Message-ID: From: "Lam, Hing-Kam (Kam)" To: ccamp@ops.ietf.org Subject: FW: ITU-T Q14/15, and Joint Q14/15, Q12/4, Q14/4 Rapporteur Grp. Mtgs., 16-20 Feb. 2004, Chicago, USA Date: Wed, 7 Jan 2004 12:25:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" This is a re-send. It bounced on the ccamp list. > -----Original Message----- > From: Lam, Hing-Kam (Kam) > Sent: Wednesday, January 07, 2004 9:53 AM > To: 'tsg15q14@itu.int'; 'tsg4wp3q12@itu.int'; 'tsg4wp3q14@itu.int' > Cc: 'knut-hakon.johannessen@telenor.com'; 'Lakshmi.Raman@Radisys.com'; 'Kireeti Kompella'; 'adrian@olddog.co.uk'; 'Alex Zinin'; 'Bill Fenner'; 'ccamp@ops.ietf.org'; 'teller.enteract@rcn.com' > Subject: ITU-T Q14/15, and Joint Q14/15, Q12/4, Q14/4 Rapporteur Grp. Mtgs., 16-20 Feb. 2004, Chicago, USA > > Dear all, > > Based on the information available at this time, i.e. number of expected participants (>20), the topics for discussion, and number of expected contributions (>15), the SG15 management team has authorized Q14/15 to hold the Q14/15, and the Joint Q14/15, Q12/4, Q14/4 Rapporteur Group meetings as planned (16-20 February 2004, Chicago, Ill., USA). > Note that the Joint Q14/15, Q12/4, Q14/4 Rapporteur Grp. Meeting will occur on the second part of the week from Wednesday to Friday (i.e., 18-20 Feb. 2004). > > I have created a directory in the ITU-T informal FTP site for contributons and logistic information > http://ties.itu.int/u/tsg15/sg15/wp3/q14/0402/ > > Deadline for contribution submission is noon (U.S. EST) 9th February 2004. > > If you plan to provide contributions, please send me the title as soon as possible so that I can assign Working Document (WD) numbers. Please upload your contributions BY Noon (U.S. EST) Monday 9th February 2004 to the above TIES ftp directory with the file name wdxx_company-name_short-title.doc, where xx is the WD number. Please include the leading 0 in the WD number and use all lower case and _ for spaces. After uploading, please send me a note so that I can update the document list. If you want me to upload the contributions for you, email me the file. > > As the IETF experts have been invited to attend this interim meeting, > I have also created a directory in the ITU-T public site at > ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/wp3/q14/0402 for them to access the contributions and logistic information without the need of an ITU-T TIES account. I will try to synchronize the information in this public directory with the TIES directory as often as possible. > > Regards, > Kam Lam > ITU-T Q14/15 Rapporteur > 1-732-949-8338 > hklam@lucent.com > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 07 Jan 2004 06:41:46 +0000 From: "rick king" To: Cc: Subject: RE: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt Date: Wed, 7 Jan 2004 14:39:33 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 VGhlbiB3aGF0J3MgcmVsYXRpb25zaGlwIGJldHdlZW4gYSBSQSBhbmQgYSByb3V0aW5nIGNvbnRy b2wgZG9tYWluPw0KDQp0aGFua3MNCg0KUmljaw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogb3duZXItY2NhbXBAb3BzLmlldGYub3JnIFttYWlsdG86b3duZXItY2NhbXBAb3Bz LmlldGYub3JnXU9uIEJlaGFsZiBPZiBEaW1pdHJpLlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZQ0K U2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDA3LCAyMDA0IDY6NTcgQU0NClRvOiByaWNrIGtpbmcN CkNjOiBjY2FtcEBvcHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBkcmFmdC1pZXRmLWNjYW1wLWdt cGxzLWFzb24tcm91dGluZy1yZXF0cy0wMS50eHQNCg0KDQpoaSwgdGhhbmtzIGZvciBjb21tZW50 aW5nLCBzZWUgaW4tbGluZToNCg0KcmljayBraW5nIHdyb3RlOg0KDQo+IFNvbWUgY29tbWVudHMu IFNlY3Rpb24gMy4gICAuLi4uLi5UaGUgIEFTT04gbW9kZWwgYWxsb3dzIGZvciB0aGUgcHJvdG9j b2xzDQo+IHVzZWQgd2l0aGluIGRpZmZlcmVudCBjb250cm9sIGRvbWFpbnMgdG8gYmUgZGlmZmVy ZW50OyBhbmQgZm9yIHRoZSBwcm90b2NvbA0KPiB1c2VkIGJldHdlZW4gY29udHJvbCBkb21haW5z IHRvIGJlIGRpZmZlcmVudCB0aGFuIHRoZSBwcm90b2NvbHMgdXNlZCB3aXRoaW4NCj4gY29udHJv bCBkb21haW5zLiAuLi4uLi4NCj4gDQo+IFRoZSByb3V0aW5nIHJlcXVpcmVtZW50cyBjb250YWlu ZWQgaW4gdGhpcyBkcmFmdCBhcHBseSB0byBwcm90b2NvbHMgdXNlZA0KPiBiZXR3ZWVuIGNvbnRy b2wgZG9tYWlucyhFLU5OSSByb3V0aW5nKSBvciBwcm90b2NvbHMgdXNlZCB3aXRoaW4gY29udHJv bA0KPiBkb21haW5zKEktTk5JIHJvdXRpbmcpIG9yIGJvdGg/DQoNCi0+IGJvdGgNCg0KPiAuLi4u Li4gLSBGb3IgYSBSQSwgdGhlIGNsdXN0ZXIgb2YgUkNzIGlzIHJlZmVycmVkIHRvIGFzIGEgcm91 dGluZw0KPiBkb21haW4uLi4uLi4NCj4gDQo+IERvZXMgdGhpcyBtZWFucyB0aGF0IFJBPXJvdXRp bmcgZG9tYWluPyBNYXliZSByb3V0aW5nIGNvbnRyb2wgZG9tYWluIGlzIG1vcmUNCj4gYWxpZ24g d2l0aCBHLjc3MTUuDQoNCi0+IHllcywgaXQgaXMgInJvdXRpbmcgKGNvbnRyb2wpIGRvbWFpbiIs IHdlIHdpbGwgY2xhcmlmeSBpbiB0aGUNCiAgICBuZXh0IHZlcnNpb24NCg0KPiBTZWN0aW9uIDQu Mi4xICAgIC4uLi4uLiAgIC0gVGhlIHNlY29uZCBhcHByb2FjaCBwbGFjZXMgdGhlIExldmVsIE4g cm91dGluZw0KPiBmdW5jdGlvbiBvbiBhIHNlcGFyYXRlIHN5c3RlbSBmcm9tIHRoZSBMZXZlbCBO KzEgcm91dGluZyBmdW5jdGlvbi4gSW4gdGhpcyANCj4gY2FzZSwgYSBjb21tdW5pY2F0aW9uIGlu dGVyZmFjZSBtdXN0IGJlIHVzZWQgYmV0d2VlbiB0aGUgc3lzdGVtcyBjb250YWluaW5nDQo+IHRo ZSByb3V0aW5nIGZ1bmN0aW9ucyBmb3IgZGlmZmVyZW50IGxldmVscy4gVGhpcyBjb21tdW5pY2F0 aW9uIGludGVyZmFjZSBhbmQNCj4gbWVjaGFuaXNtcyBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2Yg dGhpcyBkb2N1bWVudC4gLi4uLi4uLg0KPiANCj4gSXMgaXQgcG9zc2libGUgdGhhdCB0aGUgTGV2 ZWwgTiByb3V0aW5nIGZ1bmN0aW9uIGFuZCAgdGhlIExldmVsIE4rMSByb3V0aW5nDQo+IGZ1bmN0 aW9uIGFyZSBmcm9tIGRpZmZlcmVudCB2ZW5kb3JzPyBJZiB0aGUgYW5zd2VyIGlzIHllcywgdGhl biBJIHRoaW5rIHRoZQ0KPiBjb21tdW5pY2F0aW9uIGludGVyZmFjZSBhbmQgbWVjaGFuaXNtcyBz aG91bGQgYmUgZGVmaW5lZC4gT3RoZXJ3aXNlIGhvdyBjYW4NCj4geW91IGFjaGlldmUgaW50ZXIt b3BlcmF0ZT8NCg0KLT4gaXQgaXMgZXhwZWN0ZWQgdG8gY292ZXIgbXVsdGktdmVuZG9yIGNhc2Ug KG5vdGUgdGhhdCB0aGUgb3RoZXINCiAgICBhbHRlcm5hdGl2ZSBpcyBzaW5nbGUgdmVuZG9yIG9u bHkpIHNvIHRoYXQgdGhpcyAiY29tbXVuaWNhdGlvbg0KICAgIGludGVyZmFjZSIgaXMgZXhwZWN0 ZWQgdG8gYmUgZGVmaW5lZCBidXQgaXQgaXMgbm90IHdpdGhpbiB0aGUNCiAgICBzY29wZSBvZiB0 aGlzIGRvY3VtZW50LCB3aGF0J3Mgd2l0aGluIHRoZSBzY29wZSBpcyB0aGUgcm91dGluZw0KICAg IGluZm9ybWF0aW9uIGV4Y2hhbmdlZCAoaWUgd2F5cyB0byBhY2hpZXZlIHRoZSBjb21tdW5pY2F0 aW9uDQogICAgaW50ZXJmYWNlIGJldHdlZW4gdGhlc2Ugc3lzdGVtcyBpcyBub3QpDQoNCnRoYW5r cywNCi0gZGltaXRyaS4NCg0KPiBUaGFuayB5b3UuDQo+IA0KPiByaWNrDQo+IA0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmcNCj4gW21h aWx0bzpvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmddT24gQmVoYWxmIE9mDQo+IERpbWl0cmkuUGFw YWRpbWl0cmlvdUBhbGNhdGVsLmJlIFNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDMwLCAyMDAzIDU6 MTkgQU0gVG86DQo+IGNjYW1wQG9wcy5pZXRmLm9yZyBTdWJqZWN0OiBkcmFmdC1pZXRmLWNjYW1w LWdtcGxzLWFzb24tcm91dGluZy1yZXF0cy0wMS50eHQNCj4gDQo+IA0KPiBhbGwsDQo+IA0KPiB0 aGUgZm9sbG93aW5nIHZlcnNpb24gb2YgdGhlICJBU09OIHJvdXRpbmcgcmVxdWlyZW1lbnRzIiBk b2N1bWVudCBjb21wbGV0ZXMNCj4gdGhlIHRlbXBsYXRlIHByb3Bvc2VkIGluIHRoZSB2MDAudHh0 Og0KPiANCj4gPGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYt Y2NhbXAtZ21wbHMtYXNvbi1yb3V0aW5nLXJlcXRzLTAxLnR4dD4NCj4gDQo+IA0KPiBwbGVhc2Ug cHJvdmlkZSBhbnkgY29tbWVudCB5b3UgdGhpbmsgcmVsZXZhbnQgaW4gb3JkZXIgdG8gcHJvZ3Jl c3MgdGhpcyB3Zw0KPiBpLWQNCj4gDQo+IHRoYW5rcywgLSBkaW1pdHJpLg0KPiANCg0KLS0gDQpQ YXBhZGltaXRyaW91IERpbWl0cmkNCkUtbWFpbCA6IGRpbWl0cmkucGFwYWRpbWl0cmlvdUBhbGNh dGVsLmJlDQpFLW1haWwgOiBkcGFwYWRpbWl0cmlvdUBwc2cuY29tDQpXZWJwYWdlOiBodHRwOi8v cHNnLmNvbS9+ZHBhcGFkaW1pdHJpb3UvDQpBZGRyZXNzOiBGci4gV2VsbGVzcGxlaW4gMSwgQi0y MDE4IEFudHdlcnBlbiwgQmVsZ2l1bQ0KUGhvbmUgIDogKzMyIDMgMjQwLTg0OTENCg0K Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 06 Jan 2004 22:56:06 +0000 Message-ID: <3FFB3D31.6030703@alcatel.be> Date: Tue, 06 Jan 2004 23:56:49 +0100 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 MIME-Version: 1.0 To: rick king CC: ccamp@ops.ietf.org Subject: Re: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed hi, thanks for commenting, see in-line: rick king wrote: > Some comments. Section 3. ......The ASON model allows for the protocols > used within different control domains to be different; and for the protocol > used between control domains to be different than the protocols used within > control domains. ...... > > The routing requirements contained in this draft apply to protocols used > between control domains(E-NNI routing) or protocols used within control > domains(I-NNI routing) or both? -> both > ...... - For a RA, the cluster of RCs is referred to as a routing > domain...... > > Does this means that RA=routing domain? Maybe routing control domain is more > align with G.7715. -> yes, it is "routing (control) domain", we will clarify in the next version > Section 4.2.1 ...... - The second approach places the Level N routing > function on a separate system from the Level N+1 routing function. In this > case, a communication interface must be used between the systems containing > the routing functions for different levels. This communication interface and > mechanisms are outside the scope of this document. ....... > > Is it possible that the Level N routing function and the Level N+1 routing > function are from different vendors? If the answer is yes, then I think the > communication interface and mechanisms should be defined. Otherwise how can > you achieve inter-operate? -> it is expected to cover multi-vendor case (note that the other alternative is single vendor only) so that this "communication interface" is expected to be defined but it is not within the scope of this document, what's within the scope is the routing information exchanged (ie ways to achieve the communication interface between these systems is not) thanks, - dimitri. > Thank you. > > rick > > -----Original Message----- From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org]On Behalf Of > Dimitri.Papadimitriou@alcatel.be Sent: Tuesday, December 30, 2003 5:19 AM To: > ccamp@ops.ietf.org Subject: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt > > > all, > > the following version of the "ASON routing requirements" document completes > the template proposed in the v00.txt: > > > > > please provide any comment you think relevant in order to progress this wg > i-d > > thanks, - dimitri. > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 06 Jan 2004 22:49:22 +0000 Date: Tue, 30 Dec 2003 18:57:31 -0800 (PST) From: Jim Boyle To: Jean Philippe Vasseur cc: ccamp@ops.ietf.org Subject: Re: Fwd: MPLS Inter-area TE requirement draft Message-ID: <20031230185418.B55637@maroon.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I also encourage the members of CCAMP to review my original draft, at http://www.ietf.org/internet-drafts/draft-boyle-tewg-interarea-reqts-01.txt I solicit comments on these 2 inter-area drafts, as well as the TEWG doc on inter-as requirements be directed to te-wg@ops.ietf.org thanks! Jim On Tue, 30 Dec 2003, Jean Philippe Vasseur wrote: > copying CCAMP for comments. > > Thanks. > > JP. > > >Date: Tue, 30 Dec 2003 15:25:20 -0500 > >To: te-wg@ops.ietf.org > >From: Jean Philippe Vasseur > >Subject: MPLS Inter-area TE requirement draft > >Cc: ejk@tech.org, Jim Boyle , bwijnen@lucent.com, > >jeanlouis.leroux@francetelecom.com, Raymond_Zhang@infonet.com, Kenji > >Kumaki , Yuichi Ikejiri , Parantap > >Lahiri , ting_wo.chung@bell.ca > > > >Hi, > > > >Please find attached a new MPLS Inter-area TE requirement draft, which is > >truly the collective effort of the SPs on this draft along with comments > >we received form others. I took the liberty to send the draft to the list > >since it is still not on the IETF site and Bert mentioned that quick > >progress should be made on this item. > > > >Jim, as already mentioned on the list, we would be happy to work with you > >on this draft in order to quickly come up with a single draft if you will. > > > >Thanks in advance for your comment. > > > >JP. > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 06 Jan 2004 22:49:11 +0000 Message-ID: <20031230084456.73090.qmail@web21505.mail.yahoo.com> Date: Tue, 30 Dec 2003 00:44:56 -0800 (PST) From: rick king Subject: RE: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt To: ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-333418823-1072773896=:70951" --0-333418823-1072773896=:70951 Content-Type: text/plain; charset=us-ascii Some comments. Section 3. ......The ASON model allows for the protocols used within different control domains to be different; and for the protocol used between control domains to be different than the protocols used within control domains. ...... The routing requirements contained in this draft apply to protocols used between control domains(E-NNI routing) or protocols used within control domains(I-NNI routing) or both? ...... - For a RA, the cluster of RCs is referred to as a routing domain...... Does this means that RA=routing domain? Maybe routing control domain is more align with G.7715. Section 4.2.1 ...... - The second approach places the Level N routing function on a separate system from the Level N+1 routing function. In this case, a communication interface must be used between the systems containing the routing functions for different levels. This communication interface and mechanisms are outside the scope of this document. ....... Is it possible that the Level N routing function and the Level N+1 routing function are from different vendors? If the answer is yes, then I think the communication interface and mechanisms should be defined. Otherwise how can you achieve inter-operate? Thank you. -rick -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Dimitri.Papadimitriou@alcatel.be Sent: Tuesday, December 30, 2003 5:19 AM To: ccamp@ops.ietf.org Subject: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt all, the following version of the "ASON routing requirements" document completes the template proposed in the v00.txt: please provide any comment you think relevant in order to progress this wg i-d thanks, - dimitri. --------------------------------- Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 --0-333418823-1072773896=:70951 Content-Type: text/html; charset=us-ascii
Some comments.
Section 3.   ......The  ASON model allows for the protocols used within different control
   domains to be different; and for the protocol used between control
   domains to be different than the protocols used within control
   domains. ......
    The routing requirements contained in this draft apply to protocols used between control
   domains(E-NNI routing) or protocols used within control  domains(I-NNI routing) or both?
  ...... - For a RA, the cluster of RCs is referred to as a routing domain......
  
   Does this means that RA=routing domain? Maybe routing control domain is
   more align with G.7715.
Section 4.2.1    ......   - The second approach places the Level N routing function on a
        separate system from the Level N+1 routing function. In this
        case, a communication interface must be used between the
        systems containing the routing functions for different levels.
        This communication interface and mechanisms are outside the
        scope of this document. .......
  Is it possible that the Level N routing function and  the Level N+1 routing function are
from different vendors? If the answer is yes, then I think the  communication interface and mechanisms should be defined. Otherwise how can you achieve inter-operate?
 
Thank you.
 
-rick
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Dimitri.Papadimitriou@alcatel.be
Sent: Tuesday, December 30, 2003 5:19 AM
To: ccamp@ops.ietf.org
Subject: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt

all,
the following version of the "ASON routing requirements" document
completes the template proposed in the v00.txt:
please provide any comment you think relevant in order to progress
this wg i-d
thanks,
- dimitri.
 

Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003 --0-333418823-1072773896=:70951-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 06 Jan 2004 22:23:40 +0000 Message-ID: <3FFB3559.7030908@marconi.com> Date: Tue, 06 Jan 2004 17:23:21 -0500 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: IETF CCAMP List Subject: Re: IANA assignments Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Wijnen, Bert (Bert) wrote: > The BAD thing is that someone else (some vendor) has used a value > from some other draft document... and THAT WAS and IS BAD. > If you want to use a value, you better MAKE SURE it is a value that > has been assigned and registered by IANA, that is if it is in IANA > maintained namespace. The use of 3 for the CoS object was defined in many revisions of RSVP-TE. Nearly every vendor shipped an implementation at the time. Even though there are other proper methods for signaling best-effort today (the Null-Service IntServ class), I doubt anybody will want to remove their old pre-standard code, because they won't want to break backward-compatibility with their older system software revisions. This sort of thing has happened in the past, and IANA usually responded by marking the pre-standard value as "Reserved". For example, RSVP message type 14 was the pre-standard value used for Hello messages, and is now marked Reserved. >> I realize that expired drafts aren't supposed to have an impact on these >> kinds of decisions, but there are shipping products currently on the >> market that still use this C-Type. > > It migth be good to point out which products did this BAD move. > And which document did they find them in? Considering that the GMPLS-SONET/SDH draft version 0 was written years after RSVP-TE draft 01, where the CoS C-Type was originally defined, and after several vendors had already shipped product with it, I think the decision should be obvious. draft-ietf-mpls-rsvp-lsp-tunnel-**.txt is not some fly-by-night proposal. And the C-Type in question (including its value) was in the draft for seven revisions (that's 3.5 years). This isn't something you casually ignore. >> The person responsible for this draft should make sure to choose a >> different value before the draft becomes an RFC. > > I am not so sure I agree. > We should try to not make things break in the market. > But at the other hand, if we give into this kind of thing, it seems > we might also do away with IANA... and that seems not right to me. Who is "we"? You sound as if there's a war on or something. Last I heard, we (meaning all of us) were interested in making our routers work. And you can't do that if someone defines a new standard that contradicts current (and popular) implementations. -- David Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 06 Jan 2004 21:47:04 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155033D348B@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: David Charlap , IETF CCAMP List Subject: RE: IANA assignments Date: Tue, 6 Jan 2004 22:44:52 +0100 MIME-Version: 1.0 Content-Type: text/plain Inline: > -----Original Message----- > From: David Charlap [mailto:David.Charlap@marconi.com] > Sent: dinsdag 6 januari 2004 18:34 > To: IETF CCAMP List > Subject: IANA assignments > > > Today, I was going through the IANA assignements for RSVP > (http://www.iana.org/assignments/rsvp-parameters) and noticed > what may be a problem. > > The SONET/SDH FLOWSPEC C-Type > (draft-ietf-ccamp-gmpls-sonet-sdh-08.txt) > is assigned the value 3. > Actually, if it is on that IANA web page, as it indeed is, then that means that IANA has already assigned it. The internet draft in fact has: TBA (means To Be Assigned). > This is bad. The value 3 was already used in some (now > expired) RSVP-TE drafts to represent the class-of-service C-Type. > The BAD thing is that someone else (some vendor) has used a value from some other draft document... and THAT WAS and IS BAD. If you want to use a value, you better MAKE SURE it is a value that has been assigned and registered by IANA, that is if it is in IANA maintained namespace. > The same problem exists for the SONET/SDH TSPEC. > SAME answer! > I realize that expired drafts aren't supposed to have an impact on these > kinds of decisions, but there are shipping products currently on the > market that still use this C-Type. > It migth be good to point out which products did this BAD move. And which document did they find them in? > The person responsible for this draft should make sure to choose a > different value before the draft becomes an RFC. > I am not so sure I agree. We should try to not make things break in the market. But at the other hand, if we give into this kind of thing, it seems we might also do away with IANA... and that seems not right to me. Bert > -- David > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 06 Jan 2004 21:11:07 +0000 Message-ID: <3FFAF189.8050306@marconi.com> Date: Tue, 06 Jan 2004 12:34:01 -0500 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: IETF CCAMP List Subject: IANA assignments Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Today, I was going through the IANA assignements for RSVP (http://www.iana.org/assignments/rsvp-parameters) and noticed what may be a problem. The SONET/SDH FLOWSPEC C-Type (draft-ietf-ccamp-gmpls-sonet-sdh-08.txt) is assigned the value 3. This is bad. The value 3 was already used in some (now expired) RSVP-TE drafts to represent the class-of-service C-Type. The same problem exists for the SONET/SDH TSPEC. I realize that expired drafts aren't supposed to have an impact on these kinds of decisions, but there are shipping products currently on the market that still use this C-Type. The person responsible for this draft should make sure to choose a different value before the draft becomes an RFC. -- David Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 02 Jan 2004 21:23:51 +0000 Message-ID: From: "Lam, Hing-Kam (Kam)" To: "'Kireeti Kompella'" , "'adrian@olddog.co.uk'" Cc: "'ccamp@ops.ietf.org'" , "'Alex Zinin'" , "'Bill Fenner'" Subject: Location Change: ITU-T Q14/15 Interim meeting Date: Fri, 2 Jan 2004 16:21:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Dear Mr. Kompella and Mr. Farrel, I was informed by Mr. McDonough of Cisco that the Cisco facility will be closed on February 16. Since we need a full week to get the work done, we have decided to change the location of the meeting to Chicago, USA hosted by Tellabs. The meeting date remain unchange, i.e., February 16 - 20, 2004. For those ccamp WG experts interested in attending the interim meeting, please let me know by 13 January 2004 and also indicate how many contributions (if any) you plan to submit. The cut-off date for submitting contributions to the meeting is 9 February 2004. Regards, Kam Lam ITU-T Q14/15 Rapporteur 1-732-949-8338 > -----Original Message----- > From: Lam, Hing-Kam (Kam) > Sent: Monday, December 08, 2003 3:08 PM > To: 'Kireeti Kompella'; 'adrian@olddog.co.uk' > Cc: ccamp@ops.ietf.org; 'Alex Zinin'; 'Bill Fenner'; 'Scott > Bradner'; Wijnen, Bert (Bert) > Subject: ITU-T Q14/15 Interim meeting > > Dear Mr. Kompella and Mr. Farrel, > > In the ITU-T Q14/15 to CCAMP WG liaison (7th November 2003) > and in the 58th IETF meeting, > we invited the participation of the CCAMP WG experts to the > upcoming Q14/15 Interim meeting, > in the week of 16 February 2004 in North Carolina (or San Jose). > > Now I have received confirmation from the host that the location > will be at the Cisco campus in Research Triangle Park > in Raleigh, North Carolina, USA. > > For those ccamp WG experts interested in attending the > interim meeting, please reply by 13 January 2004 and > also indicate how many contributions (if any) you plan to submit. > The cut-off date for submitting contributions to the meeting > is 9 February 2004. > > The terms of Reference of the Q14/15 Rapporteur meeting are: > - Continue development of G.fame (Framework for > ASON Management) > - Revision to G.7710, G.784, and G.874 > - Revision to G.7713 and G.7713.x > - Revision to G.7714 and G.7714.1 > - Continue the specification of G.7716 > - Consideration of protocol-specific link-state > routing protocols > > Further information about the meeting, including logistic and > travel information, will > be available later on. > > Regards, > Kam Lam (Q14/15 Rapporteur) > +1 732 949 8338 >