From isis-wg-bounces@ietf.org Thu Sep 01 01:51:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAhzQ-0005RG-HK; Thu, 01 Sep 2005 01:51:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAhzM-0005R8-Ni for isis-wg@megatron.ietf.org; Thu, 01 Sep 2005 01:51:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12465 for ; Thu, 1 Sep 2005 01:51:51 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAi1F-0000Kp-Db for isis-wg@ietf.org; Thu, 01 Sep 2005 01:53:50 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j815pVBT016332; Wed, 31 Aug 2005 22:51:31 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j815pPuf030393; Wed, 31 Aug 2005 22:51:25 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j815pPiH030386; Wed, 31 Aug 2005 22:51:25 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Wed, 31 Aug 2005 22:51:24 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: "Parker, Jeff" , ISIS WG Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: "Wijnen, Bert \(Bert\)" Subject: [Isis-wg] FWD: TC name issues in draft-ietf-isis-wg-mib-22.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Jeff and ISIS WG, Bert Wijnen (the OPS AD for Network Management) had some questions about the naming of three of the TEXTUAL-CONVENTION definitions in draft-ietf-isis-wg-mib-22.txt, and he asked if I had discussed that with you. Since I have not, I am forwarding the following comments for your consideration. Thanks, Mike Heard ---------- Forwarded message ---------- Date: Wed, 31 Aug 2005 18:33:56 +0200 From: "Wijnen, Bert (Bert)" To: C. M. Heard , "Wijnen, Bert (Bert)" Subject: RE: I-D ACTION:draft-ietf-isis-wg-mib-22.txt I agree with what you are answering, so feel free to ocpy the WG list. I want to do a more extensive check though. Now w.r.t. the TC names - AdminState, can in my view best be named IsisAdminState But I am not sure about the other 2. renaming them to be Isis-prefixed would be OK. They are somewhat generic though, and we have allowed such generic names in some other MIB modules. But this is a real strange MIB module to have such generic TCs. If they do name them IsisXxxx, then of course if we ever do such TCs in a more generic place, then they can easily replace theirs in a later revision and import from our generic MIB module. Again it seems time that we start a IANA Maintained GENERIC-TC-MIB module or some such, which extends RFC2579. Maybe we should just do a document that picks up RFC2579 MIB and then add a set of TCs we allready agree on, and then at the same time hand it over to IABA for further maintenenace.? Bert > -----Original Message----- > From: C. M. Heard [mailto:heard@pobox.com] > Sent: Tuesday, August 30, 2005 22:57 > To: Wijnen, Bert (Bert) > Subject: RE: I-D ACTION:draft-ietf-isis-wg-mib-22.txt > > > Bert, > > I did indeed send e-mail to the author and WG stating > that I think the ISIS-MIB is ready for the next step > in the process. However, it is always good to get an > independent set of eyes -- I did not discuss any of > the issues noted below with the author. As it happens > I just overlooked the problems with the TC names > Unsigned8TC, Unsigned16TC, and AdminState, and that > was a mistake on my part. Since RFC 2578 specifically > bans name collisions in "standard" MIB modules, and > names cannot be changed after publication, I think > that these names should be fixed. The rest of the > stuff I would be inclined to leave, since it can be > fixed in a subsequent revision of the MIB module if > implementation experience indicates that it is necessary. > > I haven't cc:'d the author and WG, but I'll do so if you > agree with my assessment (or you can convey your comments > directly). > > Thanks, > > Mike > > On Wed, 31 Aug 2005, Wijnen, Bert (Bert) wrote: > > Mike, I am getting asked if this MIB is now ready for > > IESG review (I guess that also means IETF Last Call). > > > > >From the below email from you, I am pretty confident it is > > in good shape. > > A quick check of ev 22 document though makes me wonder: > > > > - Is it wise to define Unsigned8TC and Unsigned16TC > > with those generic names) in this MIB module? > > I know there is already an Unsigned16TC in an IPSP PIB. > > > > - Is it wise to have a AdminState TC with that genetic > > name in this MIB module? Specifically since it says > > it is for "enabling or disabling a row" > > > > - I see quite some text in comments in the MIB modules and > > wonder if it would not be better to advise them to move > > it into DESCRIPTION clauses as appropriate? > > > > - various DESCRIPTION clauses are pretty terse. > > > > I do not think any of the above is a showstopper, > > I just wonder if you had discussed that with the author(s) > > and/or WG at all. And I wonder what your opinion is on > > these sort of things. > > > > > > > > > -----Original Message----- > > > From: C. M. Heard [mailto:heard@pobox.com] > > > Sent: Tuesday, July 12, 2005 04:19 > > > To: ISIS WG > > > Cc: Wijnen, Bert (Bert) > > > Subject: Re: I-D ACTION:draft-ietf-isis-wg-mib-22.txt > > > > > > > > > On Mon, 11 Jul 2005 Internet-Drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line > > > > Internet-Drafts directories. This draft is a work item of the > > > > IS-IS for IP Internets Working Group of the IETF. > > > > > > > > Title : Management Information Base for IS-IS > > > > Author(s) : J. Parker > > > > Filename : draft-ietf-isis-wg-mib-22.txt > > > > Pages : 101 > > > > Date : 2005-7-11 > > > ... > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-22.txt > > > > All of the outstanding MIB Doctor issues have been addressed. As > > far as I am concerned it's ready to be forwarded to the IESG. > > > > Mike Heard > > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Sep 01 11:25:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAqwM-00089A-2W; Thu, 01 Sep 2005 11:25:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAqwK-000892-8Q for isis-wg@megatron.ietf.org; Thu, 01 Sep 2005 11:25:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10401 for ; Thu, 1 Sep 2005 11:25:18 -0400 (EDT) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAqyG-0001x7-GF for isis-wg@ietf.org; Thu, 01 Sep 2005 11:27:23 -0400 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.35 ; Thu, 1 Sep 2005 11:25:04 -0400 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Thu, 1 Sep 2005 11:25:04 -0400 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.182 140.233.20.182 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 01 Sep 2005 11:25:03 -0400 From: "Parker, Jeff" To: "C. M. Heard" , ISIS WG , Christian Hopps Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Sep 2005 15:25:04.0460 (UTC) FILETIME=[53C038C0:01C5AF09] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Content-Transfer-Encoding: 7bit Cc: "Wijnen, Bert \(Bert\)" Subject: [Isis-wg] Re: TC name issues in draft-ietf-isis-wg-mib-22.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org I agree with the suggestion about AdminState. Will change If I can pick up the TCs for Uint8 and Uint16, I would be happy to do so. Since this is in last call, I don't see how I could replace names chosen now in a later version. I will Look for the IPSP PIB. Pointers welcome Rename the Uint8 TC as IsisXxxx I can look at the descriptions and move text around. This is a larger change, and I'd like to consult with Chris before starting down this road. If there are particularly opaque objects, I'd be happy to make a small set of changes. Classes start in two weeks, so I will try to wrap up a new version before that. - jeff On 9/1/05 1:51 AM, "C. M. Heard" wrote: > Jeff and ISIS WG, > > Bert Wijnen (the OPS AD for Network Management) had some questions > about the naming of three of the TEXTUAL-CONVENTION definitions in > draft-ietf-isis-wg-mib-22.txt, and he asked if I had discussed that > with you. Since I have not, I am forwarding the following comments > for your consideration. > > Thanks, > > Mike Heard > > ---------- Forwarded message ---------- > Date: Wed, 31 Aug 2005 18:33:56 +0200 > From: "Wijnen, Bert (Bert)" > To: C. M. Heard , "Wijnen, Bert (Bert)" > Subject: RE: I-D ACTION:draft-ietf-isis-wg-mib-22.txt > > I agree with what you are answering, so feel free to ocpy > the WG list. I want to do a more extensive check though. > > Now w.r.t. the TC names > - AdminState, can in my view best be named IsisAdminState > > But I am not sure about the other 2. renaming them to be > Isis-prefixed would be OK. They are somewhat generic though, > and we have allowed such generic names in some other MIB modules. > But this is a real strange MIB module to have such generic TCs. > If they do name them IsisXxxx, then of course if we ever do > such TCs in a more generic place, then they can easily replace theirs > in a later revision and import from our generic MIB module. > > Again it seems time that we start a IANA Maintained GENERIC-TC-MIB > module or some such, which extends RFC2579. Maybe we should just > do a document that picks up RFC2579 MIB and then add a set of TCs > we allready agree on, and then at the same time hand it over to > IABA for further maintenenace.? > > Bert > > >> -----Original Message----- >> From: C. M. Heard [mailto:heard@pobox.com] >> Sent: Tuesday, August 30, 2005 22:57 >> To: Wijnen, Bert (Bert) >> Subject: RE: I-D ACTION:draft-ietf-isis-wg-mib-22.txt >> >> >> Bert, >> >> I did indeed send e-mail to the author and WG stating >> that I think the ISIS-MIB is ready for the next step >> in the process. However, it is always good to get an >> independent set of eyes -- I did not discuss any of >> the issues noted below with the author. As it happens >> I just overlooked the problems with the TC names >> Unsigned8TC, Unsigned16TC, and AdminState, and that >> was a mistake on my part. Since RFC 2578 specifically >> bans name collisions in "standard" MIB modules, and >> names cannot be changed after publication, I think >> that these names should be fixed. The rest of the >> stuff I would be inclined to leave, since it can be >> fixed in a subsequent revision of the MIB module if >> implementation experience indicates that it is necessary. >> >> I haven't cc:'d the author and WG, but I'll do so if you >> agree with my assessment (or you can convey your comments >> directly). >> >> Thanks, >> >> Mike >> >> On Wed, 31 Aug 2005, Wijnen, Bert (Bert) wrote: >>> Mike, I am getting asked if this MIB is now ready for >>> IESG review (I guess that also means IETF Last Call). >>> >>>> From the below email from you, I am pretty confident it is >>> in good shape. >>> A quick check of ev 22 document though makes me wonder: >>> >>> - Is it wise to define Unsigned8TC and Unsigned16TC >>> with those generic names) in this MIB module? >>> I know there is already an Unsigned16TC in an IPSP PIB. >>> >>> - Is it wise to have a AdminState TC with that genetic >>> name in this MIB module? Specifically since it says >>> it is for "enabling or disabling a row" >>> >>> - I see quite some text in comments in the MIB modules and >>> wonder if it would not be better to advise them to move >>> it into DESCRIPTION clauses as appropriate? >>> >>> - various DESCRIPTION clauses are pretty terse. >>> >>> I do not think any of the above is a showstopper, >>> I just wonder if you had discussed that with the author(s) >>> and/or WG at all. And I wonder what your opinion is on >>> these sort of things. >>> >>> >>> >>>> -----Original Message----- >>>> From: C. M. Heard [mailto:heard@pobox.com] >>>> Sent: Tuesday, July 12, 2005 04:19 >>>> To: ISIS WG >>>> Cc: Wijnen, Bert (Bert) >>>> Subject: Re: I-D ACTION:draft-ietf-isis-wg-mib-22.txt >>>> >>>> >>>> On Mon, 11 Jul 2005 Internet-Drafts@ietf.org wrote: >>>>> A New Internet-Draft is available from the on-line >>>>> Internet-Drafts directories. This draft is a work item of the >>>>> IS-IS for IP Internets Working Group of the IETF. >>>>> >>>>> Title : Management Information Base for IS-IS >>>>> Author(s) : J. Parker >>>>> Filename : draft-ietf-isis-wg-mib-22.txt >>>>> Pages : 101 >>>>> Date : 2005-7-11 >>>> ... >>>>> A URL for this Internet-Draft is: >>>>> > http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-22.txt >>> >>> All of the outstanding MIB Doctor issues have been addressed. As >>> far as I am concerned it's ready to be forwarded to the IESG. >>> >>> Mike Heard >>> >> > > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Sep 01 14:08:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAtUD-0002jg-GZ; Thu, 01 Sep 2005 14:08:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAtUC-0002i4-1h for isis-wg@megatron.ietf.org; Thu, 01 Sep 2005 14:08:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17910 for ; Thu, 1 Sep 2005 14:08:24 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAtW9-0006xp-O3 for isis-wg@ietf.org; Thu, 01 Sep 2005 14:10:32 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j81I8HBT018299; Thu, 1 Sep 2005 11:08:17 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j81I844S014299; Thu, 1 Sep 2005 11:08:04 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j81I82IH014287; Thu, 1 Sep 2005 11:08:03 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Thu, 1 Sep 2005 11:08:02 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: "Parker, Jeff" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: "Wijnen, Bert \(Bert\)" , Christian Hopps , ISIS WG Subject: [Isis-wg] Re: TC name issues in draft-ietf-isis-wg-mib-22.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Jeff, A MIB module can't IMPORT from a PIB module, so I suggest renaming Unsigned16TC to IsisUnsigned16TC and Unsigned8TC to IsisUnsigned8TC. Mike On Thu, 1 Sep 2005, Parker, Jeff wrote: > I agree with the suggestion about AdminState. Will change > > If I can pick up the TCs for Uint8 and Uint16, I would be happy to do so. > Since this is in last call, I don't see how I could replace names chosen now > in a later version. I will > Look for the IPSP PIB. Pointers welcome > Rename the Uint8 TC as IsisXxxx > > I can look at the descriptions and move text around. This is a larger > change, and I'd like to consult with Chris before starting down this road. > If there are particularly opaque objects, I'd be happy to make a small set > of changes. > > Classes start in two weeks, so I will try to wrap up a new version before > that. > > - jeff > > > On 9/1/05 1:51 AM, "C. M. Heard" wrote: > > > Jeff and ISIS WG, > > > > Bert Wijnen (the OPS AD for Network Management) had some questions > > about the naming of three of the TEXTUAL-CONVENTION definitions in > > draft-ietf-isis-wg-mib-22.txt, and he asked if I had discussed that > > with you. Since I have not, I am forwarding the following comments > > for your consideration. > > > > Thanks, > > > > Mike Heard > > > > ---------- Forwarded message ---------- > > Date: Wed, 31 Aug 2005 18:33:56 +0200 > > From: "Wijnen, Bert (Bert)" > > To: C. M. Heard , "Wijnen, Bert (Bert)" > > Subject: RE: I-D ACTION:draft-ietf-isis-wg-mib-22.txt > > > > I agree with what you are answering, so feel free to ocpy > > the WG list. I want to do a more extensive check though. > > > > Now w.r.t. the TC names > > - AdminState, can in my view best be named IsisAdminState > > > > But I am not sure about the other 2. renaming them to be > > Isis-prefixed would be OK. They are somewhat generic though, > > and we have allowed such generic names in some other MIB modules. > > But this is a real strange MIB module to have such generic TCs. > > If they do name them IsisXxxx, then of course if we ever do > > such TCs in a more generic place, then they can easily replace theirs > > in a later revision and import from our generic MIB module. > > > > Again it seems time that we start a IANA Maintained GENERIC-TC-MIB > > module or some such, which extends RFC2579. Maybe we should just > > do a document that picks up RFC2579 MIB and then add a set of TCs > > we allready agree on, and then at the same time hand it over to > > IABA for further maintenenace.? > > > > Bert > > > > > >> -----Original Message----- > >> From: C. M. Heard [mailto:heard@pobox.com] > >> Sent: Tuesday, August 30, 2005 22:57 > >> To: Wijnen, Bert (Bert) > >> Subject: RE: I-D ACTION:draft-ietf-isis-wg-mib-22.txt > >> > >> > >> Bert, > >> > >> I did indeed send e-mail to the author and WG stating > >> that I think the ISIS-MIB is ready for the next step > >> in the process. However, it is always good to get an > >> independent set of eyes -- I did not discuss any of > >> the issues noted below with the author. As it happens > >> I just overlooked the problems with the TC names > >> Unsigned8TC, Unsigned16TC, and AdminState, and that > >> was a mistake on my part. Since RFC 2578 specifically > >> bans name collisions in "standard" MIB modules, and > >> names cannot be changed after publication, I think > >> that these names should be fixed. The rest of the > >> stuff I would be inclined to leave, since it can be > >> fixed in a subsequent revision of the MIB module if > >> implementation experience indicates that it is necessary. > >> > >> I haven't cc:'d the author and WG, but I'll do so if you > >> agree with my assessment (or you can convey your comments > >> directly). > >> > >> Thanks, > >> > >> Mike > >> > >> On Wed, 31 Aug 2005, Wijnen, Bert (Bert) wrote: > >>> Mike, I am getting asked if this MIB is now ready for > >>> IESG review (I guess that also means IETF Last Call). > >>> > >>>> From the below email from you, I am pretty confident it is > >>> in good shape. > >>> A quick check of ev 22 document though makes me wonder: > >>> > >>> - Is it wise to define Unsigned8TC and Unsigned16TC > >>> with those generic names) in this MIB module? > >>> I know there is already an Unsigned16TC in an IPSP PIB. > >>> > >>> - Is it wise to have a AdminState TC with that genetic > >>> name in this MIB module? Specifically since it says > >>> it is for "enabling or disabling a row" > >>> > >>> - I see quite some text in comments in the MIB modules and > >>> wonder if it would not be better to advise them to move > >>> it into DESCRIPTION clauses as appropriate? > >>> > >>> - various DESCRIPTION clauses are pretty terse. > >>> > >>> I do not think any of the above is a showstopper, > >>> I just wonder if you had discussed that with the author(s) > >>> and/or WG at all. And I wonder what your opinion is on > >>> these sort of things. > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: C. M. Heard [mailto:heard@pobox.com] > >>>> Sent: Tuesday, July 12, 2005 04:19 > >>>> To: ISIS WG > >>>> Cc: Wijnen, Bert (Bert) > >>>> Subject: Re: I-D ACTION:draft-ietf-isis-wg-mib-22.txt > >>>> > >>>> > >>>> On Mon, 11 Jul 2005 Internet-Drafts@ietf.org wrote: > >>>>> A New Internet-Draft is available from the on-line > >>>>> Internet-Drafts directories. This draft is a work item of the > >>>>> IS-IS for IP Internets Working Group of the IETF. > >>>>> > >>>>> Title : Management Information Base for IS-IS > >>>>> Author(s) : J. Parker > >>>>> Filename : draft-ietf-isis-wg-mib-22.txt > >>>>> Pages : 101 > >>>>> Date : 2005-7-11 > >>>> ... > >>>>> A URL for this Internet-Draft is: > >>>>> > > http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-22.txt > >>> > >>> All of the outstanding MIB Doctor issues have been addressed. As > >>> far as I am concerned it's ready to be forwarded to the IESG. > >>> > >>> Mike Heard > >>> > >> > > > > > > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Sep 01 20:37:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAzYn-00046h-IM; Thu, 01 Sep 2005 20:37:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAzYk-00046W-VN for isis-wg@megatron.ietf.org; Thu, 01 Sep 2005 20:37:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09104 for ; Thu, 1 Sep 2005 20:37:31 -0400 (EDT) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAzao-0002Vw-0F for isis-wg@ietf.org; Thu, 01 Sep 2005 20:39:42 -0400 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.35 ; Thu, 1 Sep 2005 20:36:28 -0400 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Thu, 1 Sep 2005 20:37:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Isis-wg] Re: TC name issues in draft-ietf-isis-wg-mib-22.txt Date: Thu, 1 Sep 2005 20:37:21 -0400 Message-ID: <664FBBD972927F499753DB2E44E2430C02BE27BF@grasshopper.middlebury.edu> Thread-Topic: [Isis-wg] Re: TC name issues in draft-ietf-isis-wg-mib-22.txt Thread-Index: AcWvSHYyZSNMvMtRTdWwPrs7UsW5UgADda+m From: "Parker, Jeff" To: "Wijnen, Bert \(Bert\)" , "Jeff Parker" , "C. M. Heard" X-OriginalArrivalTime: 02 Sep 2005 00:37:22.0148 (UTC) FILETIME=[7B5A2240:01C5AF56] X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: Christian Hopps , ISIS WG X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1839067940==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org --===============1839067940== content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 QmVydCAtDQogICAgVGhvc2UgbG9vayBsaWtlIHZhbGlkIHBvaW50cy4gIEkgd2lsbCBkbyBzb21l IHdvcmRzbWl0aGluZyBhbmQgcmVwb3J0IGJhY2suDQogICAgSSBjb3VsZCBhZGRyZXNzIHNvbWUg b2YgdGhlIHBvaW50cyBub3csIGJ1dCBwZXJoYXBzIGl0IHdvdWxkIGJlIGJldHRlciB0byBzYXZl IG15IHRob3VnaHRzIGZvciBhbiBlZGl0aW5nIHNlc3Npb24sIGFuZCBzZWUgaWYgSSBjYW4gbWFr ZSB0aGUgdGV4dCBzcGVhayBmb3IgaXRzZWxmDQogDQotIGplZmYNCg0KCS0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tIA0KCUZyb206IFdpam5lbiwgQmVydCAoQmVydCkgW21haWx0bzpid2lqbmVu QGx1Y2VudC5jb21dIA0KCVNlbnQ6IFRodSA5LzEvMjAwNSA2OjU2IFBNIA0KCVRvOiBKZWZmIFBh cmtlcjsgQy4gTS4gSGVhcmQ7IFBhcmtlciwgSmVmZiANCglDYzogQ2hyaXN0aWFuIEhvcHBzOyBJ U0lTIFdHIA0KCVN1YmplY3Q6IFJFOiBbSXNpcy13Z10gUmU6IFRDIG5hbWUgaXNzdWVzIGluIGRy YWZ0LWlldGYtaXNpcy13Zy1taWItMjIudHh0DQoJDQoJDQoNCglJbmxpbmUNCgkNCgk+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJPiBGcm9tOiBKZWZmIFBhcmtlciBbbWFpbHRvOmpwYXJr ZXJAd29ybGQuc3RkLmNvbV0NCgk+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMDEsIDIwMDUg MTk6MTINCgk+IFRvOiBDLiBNLiBIZWFyZDsgSmVmZiBQYXJrZXINCgk+IENjOiBXaWpuZW4sIEJl cnQgKEJlcnQpOyBDaHJpc3RpYW4gSG9wcHM7IElTSVMgV0cNCgk+IFN1YmplY3Q6IFJlOiBbSXNp cy13Z10gUmU6IFRDIG5hbWUgaXNzdWVzIGluDQoJPiBkcmFmdC1pZXRmLWlzaXMtd2ctbWliLTIy LnR4dA0KCT4NCgk+DQoJPiBUaGFua3MgZm9yIHRoZSBjb21tZW50cy4NCgk+DQoJPiA+Pj4+PiAt IElzIGl0IHdpc2UgdG8gZGVmaW5lIFVuc2lnbmVkOFRDIGFuZCBVbnNpZ25lZDE2VEMNCgk+ID4+ Pj4+ICAgd2l0aCB0aG9zZSBnZW5lcmljIG5hbWVzKSBpbiB0aGlzIE1JQiBtb2R1bGU/DQoJPiA+ Pj4+PiAgIEkga25vdyB0aGVyZSBpcyBhbHJlYWR5IGFuIFVuc2lnbmVkMTZUQyBpbiBhbiBJUFNQ IFBJQi4NCgk+DQoJPiBNYWRlIHRoZXNlIElzaXNYeHgNCgk+DQoJVGhhbmtzDQoJDQoJPiA+Pj4+ PiAtIElzIGl0IHdpc2UgdG8gaGF2ZSBhIEFkbWluU3RhdGUgVEMgd2l0aCB0aGF0IGdlbmV0aWMN Cgk+ID4+Pj4+ICAgbmFtZSBpbiB0aGlzIE1JQiBtb2R1bGU/IFNwZWNpZmljYWxseSBzaW5jZSBp dCBzYXlzDQoJPiA+Pj4+PiAgIGl0IGlzIGZvciAiZW5hYmxpbmcgb3IgZGlzYWJsaW5nIGEgcm93 Ig0KCT4gDQoJPiBNYWRlIHRoaXMgSXNpc0FkbWluU3RhdGUNCgk+IA0KCVRoYW5rcw0KCQ0KCT4g Pj4+Pj4gLSBJIHNlZSBxdWl0ZSBzb21lIHRleHQgaW4gY29tbWVudHMgaW4gdGhlIE1JQiBtb2R1 bGVzIGFuZA0KCT4gPj4+Pj4gICB3b25kZXIgaWYgaXQgd291bGQgbm90IGJlIGJldHRlciB0byBh ZHZpc2UgdGhlbSB0byBtb3ZlDQoJPiA+Pj4+PiAgIGl0IGludG8gREVTQ1JJUFRJT04gY2xhdXNl cyBhcyBhcHByb3ByaWF0ZT8NCgk+ID4+Pj4+IA0KCT4gPj4+Pj4gLSAgdmFyaW91cyBERVNDUklQ VElPTiBjbGF1c2VzIGFyZSBwcmV0dHkgdGVyc2UuDQoJPiA+Pj4+Pg0KCT4gPj4+Pj4gSSBkbyBu b3QgdGhpbmsgYW55IG9mIHRoZSBhYm92ZSBpcyBhIHNob3dzdG9wcGVyLA0KCT4gPj4+Pj4gSSBq dXN0IHdvbmRlciBpZiB5b3UgaGFkIGRpc2N1c3NlZCB0aGF0IHdpdGggdGhlIGF1dGhvcihzKQ0K CT4gPj4+Pj4gYW5kL29yIFdHIGF0IGFsbC4gQW5kIEkgd29uZGVyIHdoYXQgeW91ciBvcGluaW9u IGlzIG9uDQoJPiA+Pj4+PiB0aGVzZSBzb3J0IG9mIHRoaW5ncy4NCgk+DQoJPiBJIHVuZGVyc3Rh bmQgdGhhdCBvbmUgbWFuJ3MgdGVyc2UgaXMgYW5vdGhlciBtYW4ncyBwcm9saXgsDQoJPiBidXQg SSdtIG5vdCBzdXJlDQoJPiB3aGljaCBtb2R1bGVzIGFyZSBiZWluZyBkaXNjdXNzZWQuICBJIHNr aW1tZWQgdGhyb3VnaCB0aGUNCgk+IHdob2xlIE1JQiBhbmQNCgk+IGRpZG4ndCBmaW5kIHRoYXQg bXVjaCByZWxldmFudCBpbiBjb21tZW50cyBvdXRzaWRlIHRoZQ0KCT4gREVTQ1JJUFRJT04gY2xh dXNlcy4NCgk+DQoJPiBJIHdpbGwgYmUgaGFwcHkgdG8gbW92ZSB0ZXh0IGFyb3VuZCBvciB3b3Jk c21pdGggaWYgdGhlcmUgaXMNCgk+IGFuIG9ic2N1cmUNCgk+IGNsYXVzZSwgYnV0IEkgdGhpbmsg dGhlIGxpc3QgYWxyZWFkeSBoYXMgYmVlbiBwcmV0dHkgZnJhbmsNCgk+IGFib3V0IG9iamVjdHMN Cgk+IHRoZXkgZm91bmQgb2JzY3VyZS4gIEkgZG9uJ3Qgc2VlIGEgc3lzdGVtaWMgcHJvYmxlbSBh bmQgSQ0KCT4gZGlkbid0IHNwb3QgYW55DQoJPiBwcm9ibGVtYXRpYyBvYmplY3QuDQoJPg0KCT4g Qm90dG9tIGxpbmU6IGdpdmUgbWUgYSByZWZlcmVuY2UgYW5kIEkgd2lsbCBmaXggaXQuDQoJPg0K CQ0KCU9LLCBhcyBJIHNhaWQgaW4gYSBwcmV2aW91cyBlbWFpbCwgdGhlIGxhc3QgdGhpbmcgaXMg bm90IGFueXRoaW5nDQoJdG8gaG9sZCB0aGUgZG9jIGhvc3RhZ2Ugb3Zlci4gQnV0IGlmIHlvdSB3 YW50IGV4YW1wbGVzLCBoZXJlIGFyZSBhIGZldzoNCgkNCgkgICAgSXNpc1N5c3RlbUlEIDo6PSBU RVhUVUFMLUNPTlZFTlRJT04NCgkgICAgICAgIFNUQVRVUyBjdXJyZW50DQoJICAgICAgICBERVND UklQVElPTg0KCSAgICAgICAgICAgICJBIHN5c3RlbSBJRC4iDQoJICAgICAgICBTWU5UQVggT0NU RVQgU1RSSU5HIChTSVpFKDYpKQ0KCQ0KCUkgYW0gc3VyZSB0aGF0IElTLUlTIHBlb3BsZSBrbm93 IHdoYXQgIkEgc3lzdGVtIElEIiBpcy4NCglCdXQgYWxsIEkgY2FuIHRlbGwgaXMgdGhhdCBpdCBp cyA2IG9jdGV0cy4gSSBoYXZlIG5vIGlkZWENCglob3cgaXQgaXMgY3JlYXRlZC9jb25maWd1cmVk LCB3aGF0IHRoZSBmb3JtYXQgaXMuLi4gZXRjLg0KCUkgc2VlIG5vIFJFRkVSRU5DRSBjbGF1c2Ug ZWl0aGVyLCB3aGljaCBtaWdodCBwb2ludCBtZSB0bw0KCXRoZSBwcm9wZXIgSVMtSVMgZG9jdW1l bnQgdGhhdCBkZXNjcmliZXMgdGhlIGZvcm1hdCBhbmQNCglzZW1hbnRpY3Mgb2YgIkEgc3lzdGVt IElEIi4NCgkNCglOb3cgSSBzZWUgdGhhdCB3aGVuIHlvdSB1c2UgdGhlIFRDIGluIGlzaXNTeXNJ RCB0aGF0IHlvdQ0KCWFkZCBhIGxvdCBvZiB0ZXh0IHRoZXJlLiBBbmQgdGhhdCBpcyBzdHJhbmdl LiBUaGUgaWRlYSBvZiBhDQoJVEMgaXMgdGhhdCB0aGUgc2VtYW50aWNzIGFyZSBkZXNjcmliZWQg aW4gdGhlIFRDIHNvIHRoYXQgeW91DQoJZG8gbm90IGhhdmUgdG8gcmVwZWF0IGl0IHVtdHkgdGlt ZXMgZXZlcnkgdGltZSB5b3UgdXNlDQoJdGhlIHNhbWUgVEMuIE9oIHdlbGwuDQoJDQoJU2FtZSBz dG9yeSBmb3I6DQoJDQoJDQoJICAgIElzaXNMaW5rU3RhdGVQRFVJRCA6Oj0gVEVYVFVBTC1DT05W RU5USU9ODQoJICAgICAgICBTVEFUVVMgY3VycmVudA0KCSAgICAgICAgREVTQ1JJUFRJT04NCgkg ICAgICAgICAgICAiQSBMaW5rIFN0YXRlIFBEVSBJZGVudGlmaWVyLiINCgkgICAgICAgIFNZTlRB WCBPQ1RFVCBTVFJJTkcgKFNJWkUoOCkpDQoJDQoJSW4gZmFjdCBJIHRoaW5rIG1hbnkgb2YgeW91 ciBUQ3MgY291bGQgdXNlIGEgUkVGRVJFTkNFIGNsYXVzZS4NCgkNCglGdXJ0aGVyLCBPbiBwYWdl IDEyIEkgc2VlOg0KCSAgLS0gQmVoYXZpb3IgRGVmaW5pdGlvbnMNCgkNCgkgIC0tIFJlc2V0dGlu Z1RpbWVyIGJlaGF2aW9yIGRlZmluaXRpb24NCgkgIC0tICJUaGlzIG9iamVjdCBzcGVjaWZpZXMg dGhlIGludGVydmFsIGJldHdlZW4gY2VydGFpbiBldmVudHMgaW4NCgkNCglTbyB3aGF0IGlzICJU aGlzIG9iamVjdCIgPz8NCglJIHNlZSBubyBvdGhlciBvY2N1cmVuY2Ugb2YgUmVzZXR0aW5nVGlt ZXINCglTbyB3aGVyZSBkb2VzIHRoaXMgYmVsb25nPw0KCQ0KCSAgLS0gdGhlIG9wZXJhdGlvbiBv ZiB0aGUgcHJvdG9jb2wgc3RhdGUgbWFjaGluZS4gSWYgdGhlIHZhbHVlIG9mDQoJICAtLSB0aGlz IG9iamVjdCBpcyBzZXQgdG8gYSBuZXcgdmFsdWUgd2hpbGUgdGhlIHByb3RvY29sIHN0YXRlDQoJ ICAtLSBtYWNoaW5lIGlzIGluIG9wZXJhdGlvbiwgdGhlIGltcGxlbWVudGF0aW9uIHNoYWxsIHRh a2UgdGhlDQoJICAtLSBuZWNlc3Nhcnkgc3RlcHMgdG8gZW5zdXJlIHRoYXQgZm9yIGFueSB0aW1l IGludGVydmFsIHdoaWNoDQoJICAtLSB3YXMgaW4gcHJvZ3Jlc3Mgd2hlbiB0aGUgdmFsdWUgb2Yg dGhlIGNvcnJlc3BvbmRpbmcgb2JqZWN0DQoJICAtLSB3YXMgY2hhbmdlZCwgdGhlIG5leHQgZXhw aXJhdGlvbiBvZiB0aGF0IGludGVydmFsIHRha2VzIHBsYWNlDQoJICAtLSB0aGUgc3BlY2lmaWVk IHRpbWUgYWZ0ZXIgdGhlIG9yaWdpbmFsIHN0YXJ0IG9mIHRoYXQgaW50ZXJ2YWwsDQoJICAtLSBv ciBpbW1lZGlhdGVseSwgd2hpY2hldmVyIGlzIGxhdGVyLiBUaGUgcHJlY2lzaW9uIHdpdGggd2hp Y2gNCgkgIC0tIHRoaXMgdGltZSBzaGFsbCBiZSBpbXBsZW1lbnRlZCBzaGFsbCBiZSB0aGUgc2Ft ZSBhcyB0aGF0DQoJICAtLSBhc3NvY2lhdGVkIHdpdGggdGhlIGJhc2ljIG9wZXJhdGlvbiBvZiB0 aGUgdGltZXIgb2JqZWN0LiINCgkNCgkgIC0tIFJlcGxhY2VPbmx5V2hpbGVEaXNhYmxlZCBiZWhh dmlvciBkZWZpbml0aW9uDQoJICAtLSAiVGhpcyBvYmplY3QgbWF5IG5vdCBiZSBtb2RpZmllZCB3 aGlsZSB0aGUgY29ycmVzcG9uZGluZw0KCSAgLS0gdGFibGUgcm93J3MgdmFyaWFibGUgb2YgdHlw ZSBBZG1pblN0YXRlIGlzIGluIHN0YXRlIG9uLiINCgkNCglTYW1lIHF1ZXN0aW9ucw0KCSAgLS0g TWFudWFsT3JBdXRvbWF0aWMgYmVoYXZpb3IgZGVmaW5pdGlvbg0KCSAgLS0gIlRoZSBhY2Nlc3Mg b2YgdGhpcyBvYmplY3QgaXMgcmVhZC13cml0ZSBpZiB0aGUgcm93IHRvIHdoaWNoDQoJICAtLSBp dCBiZWxvbmdzIGlzIG1hbnVhbCAoaS5lLiBpcyBiZWluZyBvciB3YXMgY3JlYXRlZCBtYW51YWxs eSkNCgkgIC0tIG90aGVyd2lzZSAoaS5lLiB3YXMgY3JlYXRlZCBhdXRvbWF0aWNhbGx5KSBpdCBp cyByZWFkLW9ubHkuIg0KCQ0KCVNhbWUgcXVlc3Rpb25zDQoJDQoJRnVydGhlciBJIFNlZSB0aGF0 IGZvciBzZXZlcmFsIG9mIHlvdXIgcmVhZC13cml0ZSBvYmplY3RzLA0KCXlvdSBkbyBub3QgZGVm aW5lIHdoYXQgdGhlIHBlcnNpc3RlbmN5IGJlaGF2aW91ciBpcyBvciBzaG91bGQNCgliZS4gU28g d2hhdCBjYW4gYSBtYW5hZ2VtZW50IGFwcGxpY2F0aW9uIGV4cGVjdCBhZnRlciBhDQoJcmVzdGFy dCBvZiB0aGUgYWdlbnQ/IFNvbWUgb2YgdGhlIG9iamVjdHMgSSBmb3VuZCB0aGlzIGZvcjoNCgkN CgkgIGlzaXNTeXNMZXZlbFR5cGUNCgkgIGlzaXNTeXNJRA0KCSAgaXNpc1N5c01heFBhdGhTcGxp dHMNCgkgIGlzaXNTeXNNYXhMU1BHZW5JbnQNCgkNCglhbmQgcHJvYmFibHkgbW9yZSBvYmplY3Rz Lg0KCVRoYXQgaXMgYnkgdGhlIHdheSBhIHR5cGUgb2YgImJsb2NraW5nIiBpc3N1ZS4NCgkNCgkN CglPbiBQYWdlIDE2IEkgc2VlOg0KCQ0KCS0tIFRoZSBMZXZlbCAxIE1hbnVhbCBBcmVhIEFkZHJl c3MgVGFibGUNCgktLSBjb250YWlucyB0aGUgc2V0IG9mIGFyZWEgYWRkcmVzc2VzIG1hbnVhbGx5 IGNvbmZpZ3VyZWQNCgktLSBmb3IgdGhpcyBJbnRlcm1lZGlhdGUgU3lzdGVtLg0KCS0tIEF0IGxl YXN0IG9uZSByb3cgaW4gd2hpY2ggdGhlIHZhbHVlIG9mIGlzaXNNYW5BcmVhQWRkckV4aXN0U3Rh dGUNCgktLSBpcyBhY3RpdmUgbXVzdCBiZSBwcmVzZW50LiBUaGUgbWF4aW11bSBudW1iZXIgb2Yg cm93cw0KCS0tIGluIHRoaXMgdGFibGUgZm9yIGZvciB3aGljaCB0aGUgb2JqZWN0DQoJLS0gaXNp c01hbkFyZWFBZGRyRXhpc3RTdGF0ZSBoYXMgdGhlIHZhbHVlIGFjdGl2ZSBpcyAzLg0KCS0tICAg ICBBbiBhdHRlbXB0IHRvIGNyZWF0ZSBtb3JlIDMgcm93cyBvZiBpc2lzTWFuQXJlYUFkZHJFbnRy eQ0KCS0tIHdpdGggc3RhdGUgJ2FjdGl2ZScgaW4gb25lIGluc3RhbmNlIG9mIHRoZSBJUy1JUyBw cm90b2NvbA0KCS0tIHNob3VsZCByZXR1cm4gaW5jb25zaXN0ZW50VmFsdWUuDQoJDQoJICAgIGlz aXNNYW5BcmVhQWRkclRhYmxlIE9CSkVDVC1UWVBFDQoJICAgICAgICBTWU5UQVggU0VRVUVOQ0Ug T0YgSXNpc01hbkFyZWFBZGRyRW50cnkNCgkgICAgICAgIE1BWC1BQ0NFU1Mgbm90LWFjY2Vzc2li bGUNCgkgICAgICAgIFNUQVRVUyBjdXJyZW50DQoJICAgICAgICBERVNDUklQVElPTg0KCSAgICAg ICAgICAgICJUaGUgc2V0IG9mIG1hbnVhbCBhcmVhIGFkZHJlc3NlcyBjb25maWd1cmVkIG9uIHRo aXMNCgkgICAgICAgICAgICAgSW50ZXJtZWRpYXRlIFN5c3RlbS4iDQoJICAgICAgICBSRUZFUkVO Q0UgIntJU0lTLmFvaSBtYW51YWxBcmVhQWRkcmVzc2VzICgxMCl9Ig0KCSAgICA6Oj0geyBpc2lz U3lzdGVtIDIgfQ0KCQ0KCVNvIEkgd29uZGVyIHdoeSB0aGUgY29tbWVudGVkIHRleHQgKGFsbCBs aW5lcyBzdGFydGluZyB3aXRoIC0tKQ0KCWFyZSBub3QganVzdCBwdXQgaW50byB0aGUgREVTQ0lQ VElPTiBjbGF1c2UuDQoJDQoJVGhhdCBpcyB0aGUgc29ydCBvZiB0aGluZ3MgdGhhdCBJIHdvbmRl ciBhYm91dC4NCgkNCglCZXJ0DQoJDQoNCg== --===============1839067940== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============1839067940==-- From isis-wg-bounces@ietf.org Fri Sep 02 10:23:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBCRj-0001aH-8I; Fri, 02 Sep 2005 10:23:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAtOE-0003Xz-EL for isis-wg@megatron.ietf.org; Thu, 01 Sep 2005 14:02:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17499 for ; Thu, 1 Sep 2005 14:02:15 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAtQE-0006ic-2u for isis-wg@ietf.org; Thu, 01 Sep 2005 14:04:22 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j81I21I5020387; Thu, 1 Sep 2005 13:02:02 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 1 Sep 2005 20:02:01 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507EE0C16@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Parker, Jeff" , "C. M. Heard" , ISIS WG , Christian Hopps Date: Thu, 1 Sep 2005 20:02:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 X-Mailman-Approved-At: Fri, 02 Sep 2005 10:23:08 -0400 Cc: Subject: [Isis-wg] RE: TC name issues in draft-ietf-isis-wg-mib-22.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Inline > -----Original Message----- > From: Parker, Jeff [mailto:jeffp@middlebury.edu] > Sent: Thursday, September 01, 2005 12:25 > To: C. M. Heard; ISIS WG; Christian Hopps > Cc: Wijnen, Bert (Bert) > Subject: Re: TC name issues in draft-ietf-isis-wg-mib-22.txt > > > I agree with the suggestion about AdminState. Will change > Good > If I can pick up the TCs for Uint8 and Uint16, I would be > happy to do so. There currently are none that are in an RFC (I believe) > Since this is in last call, I don't see how I could replace > names chosen now in a later version. I will > Look for the IPSP PIB. Pointers welcome > Rename the Uint8 TC as IsisXxxx > Don't pick up the one from the IPSP PIB. It is unclear if/when that document will move to RFC-Editor, so you do not want to become dependent on it. I just used that one as an example where we can run into a conflict in the future. If we (MIB doctors and the rest of the IETF) could decide soon (but I am not sure we can), then you could import from there. But I would not recommend to do so either. So for now... what I suggested is: - maybe best you name them IsisUnsigned16TC and IsisUnsigned8TC - that way you prevent name clashes - that way hopefully people will not so easily import them from this doc (cause they would have a totally illogical dependency on an isis document) - if we ever get to do generic Unsigned16TC and Unsigned8TC, then whenever you do a new rev of your doc, you can obsolete your TCs and replace the SYNTAX of IsisUnsigned16TC to Unsigned16TC because sematically and on the wire they are the same (or so I assume, but we can never be sure till we see both TCs of course). > I can look at the descriptions and move text around. This is a larger > change, and I'd like to consult with Chris before starting > down this road. If there are particularly opaque objects, > I'd be happy to make a small set of changes. > Don't go out of your way to do so. In general, I like to see explanantions/semantics described in the proper DESCRIPTION clauses as opposed to in comments outside the DESCRIPTION clauses. But it is not a show stopper. > Classes start in two weeks, so I will try to wrap up a new > version before that. > Bert > - jeff > > > On 9/1/05 1:51 AM, "C. M. Heard" wrote: > > > Jeff and ISIS WG, > > > > Bert Wijnen (the OPS AD for Network Management) had some questions > > about the naming of three of the TEXTUAL-CONVENTION definitions in > > draft-ietf-isis-wg-mib-22.txt, and he asked if I had discussed that > > with you. Since I have not, I am forwarding the following comments > > for your consideration. > > > > Thanks, > > > > Mike Heard > > > > ---------- Forwarded message ---------- > > Date: Wed, 31 Aug 2005 18:33:56 +0200 > > From: "Wijnen, Bert (Bert)" > > To: C. M. Heard , "Wijnen, Bert (Bert)" > > > Subject: RE: I-D ACTION:draft-ietf-isis-wg-mib-22.txt > > > > I agree with what you are answering, so feel free to ocpy > > the WG list. I want to do a more extensive check though. > > > > Now w.r.t. the TC names > > - AdminState, can in my view best be named IsisAdminState > > > > But I am not sure about the other 2. renaming them to be > > Isis-prefixed would be OK. They are somewhat generic though, > > and we have allowed such generic names in some other MIB modules. > > But this is a real strange MIB module to have such generic TCs. > > If they do name them IsisXxxx, then of course if we ever do > > such TCs in a more generic place, then they can easily > replace theirs > > in a later revision and import from our generic MIB module. > > > > Again it seems time that we start a IANA Maintained GENERIC-TC-MIB > > module or some such, which extends RFC2579. Maybe we should just > > do a document that picks up RFC2579 MIB and then add a set of TCs > > we allready agree on, and then at the same time hand it over to > > IABA for further maintenenace.? > > > > Bert > > > > > >> -----Original Message----- > >> From: C. M. Heard [mailto:heard@pobox.com] > >> Sent: Tuesday, August 30, 2005 22:57 > >> To: Wijnen, Bert (Bert) > >> Subject: RE: I-D ACTION:draft-ietf-isis-wg-mib-22.txt > >> > >> > >> Bert, > >> > >> I did indeed send e-mail to the author and WG stating > >> that I think the ISIS-MIB is ready for the next step > >> in the process. However, it is always good to get an > >> independent set of eyes -- I did not discuss any of > >> the issues noted below with the author. As it happens > >> I just overlooked the problems with the TC names > >> Unsigned8TC, Unsigned16TC, and AdminState, and that > >> was a mistake on my part. Since RFC 2578 specifically > >> bans name collisions in "standard" MIB modules, and > >> names cannot be changed after publication, I think > >> that these names should be fixed. The rest of the > >> stuff I would be inclined to leave, since it can be > >> fixed in a subsequent revision of the MIB module if > >> implementation experience indicates that it is necessary. > >> > >> I haven't cc:'d the author and WG, but I'll do so if you > >> agree with my assessment (or you can convey your comments > >> directly). > >> > >> Thanks, > >> > >> Mike > >> > >> On Wed, 31 Aug 2005, Wijnen, Bert (Bert) wrote: > >>> Mike, I am getting asked if this MIB is now ready for > >>> IESG review (I guess that also means IETF Last Call). > >>> > >>>> From the below email from you, I am pretty confident it is > >>> in good shape. > >>> A quick check of ev 22 document though makes me wonder: > >>> > >>> - Is it wise to define Unsigned8TC and Unsigned16TC > >>> with those generic names) in this MIB module? > >>> I know there is already an Unsigned16TC in an IPSP PIB. > >>> > >>> - Is it wise to have a AdminState TC with that genetic > >>> name in this MIB module? Specifically since it says > >>> it is for "enabling or disabling a row" > >>> > >>> - I see quite some text in comments in the MIB modules and > >>> wonder if it would not be better to advise them to move > >>> it into DESCRIPTION clauses as appropriate? > >>> > >>> - various DESCRIPTION clauses are pretty terse. > >>> > >>> I do not think any of the above is a showstopper, > >>> I just wonder if you had discussed that with the author(s) > >>> and/or WG at all. And I wonder what your opinion is on > >>> these sort of things. > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: C. M. Heard [mailto:heard@pobox.com] > >>>> Sent: Tuesday, July 12, 2005 04:19 > >>>> To: ISIS WG > >>>> Cc: Wijnen, Bert (Bert) > >>>> Subject: Re: I-D ACTION:draft-ietf-isis-wg-mib-22.txt > >>>> > >>>> > >>>> On Mon, 11 Jul 2005 Internet-Drafts@ietf.org wrote: > >>>>> A New Internet-Draft is available from the on-line > >>>>> Internet-Drafts directories. This draft is a work item of the > >>>>> IS-IS for IP Internets Working Group of the IETF. > >>>>> > >>>>> Title : Management Information Base for IS-IS > >>>>> Author(s) : J. Parker > >>>>> Filename : draft-ietf-isis-wg-mib-22.txt > >>>>> Pages : 101 > >>>>> Date : 2005-7-11 > >>>> ... > >>>>> A URL for this Internet-Draft is: > >>>>> > > http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-22.txt > >>> > >>> All of the outstanding MIB Doctor issues have been addressed. As > >>> far as I am concerned it's ready to be forwarded to the IESG. > >>> > >>> Mike Heard > >>> > >> > > > > > > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Sep 02 10:23:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBCRj-0001aq-Rk; Fri, 02 Sep 2005 10:23:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAxHt-0007mY-Tz for isis-wg@megatron.ietf.org; Thu, 01 Sep 2005 18:12:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02426 for ; Thu, 1 Sep 2005 18:11:59 -0400 (EDT) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAxJv-0006i0-NP for isis-wg@ietf.org; Thu, 01 Sep 2005 18:14:08 -0400 Received: from 140.233.20.182 [140.233.20.182] by anthrax.middlebury.edu with XWall v3.35 ; Thu, 1 Sep 2005 18:11:11 -0400 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 01 Sep 2005 18:11:31 -0400 Subject: Re: [Isis-wg] Re: TC name issues in draft-ietf-isis-wg-mib-22.txt From: Jeff Parker To: "C. M. Heard" , Jeff Parker Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 02 Sep 2005 10:23:08 -0400 Cc: "Wijnen, Bert \(Bert\)" , Christian Hopps , ISIS WG X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Thanks for the comments. >>>>> - Is it wise to define Unsigned8TC and Unsigned16TC >>>>> with those generic names) in this MIB module? >>>>> I know there is already an Unsigned16TC in an IPSP PIB. Made these IsisXxx >>>>> - Is it wise to have a AdminState TC with that genetic >>>>> name in this MIB module? Specifically since it says >>>>> it is for "enabling or disabling a row" Made this IsisAdminState >>>>> - I see quite some text in comments in the MIB modules and >>>>> wonder if it would not be better to advise them to move >>>>> it into DESCRIPTION clauses as appropriate? >>>>> >>>>> - various DESCRIPTION clauses are pretty terse. >>>>> >>>>> I do not think any of the above is a showstopper, >>>>> I just wonder if you had discussed that with the author(s) >>>>> and/or WG at all. And I wonder what your opinion is on >>>>> these sort of things. I understand that one man's terse is another man's prolix, but I'm not sure which modules are being discussed. I skimmed through the whole MIB and didn't find that much relevant in comments outside the DESCRIPTION clauses. I will be happy to move text around or wordsmith if there is an obscure clause, but I think the list already has been pretty frank about objects they found obscure. I don't see a systemic problem and I didn't spot any problematic object. Bottom line: give me a reference and I will fix it. I have respun. Will be happy to resubmit or send out for review. I will wait until early next week, and upload to IETF again. - jeff parker myrmidon:~/MIB jeff$ diff mib.22 mib 118c118 < AdminState ::= TEXTUAL-CONVENTION --- > IsisAdminState ::= TEXTUAL-CONVENTION 247c247 < Unsigned16TC ::= TEXTUAL-CONVENTION --- > IsisUnsigned16TC ::= TEXTUAL-CONVENTION 256c256 < Unsigned8TC ::= TEXTUAL-CONVENTION --- > IsisUnsigned8TC ::= TEXTUAL-CONVENTION 282c282 < -- table row's variable of type AdminState is in state on." --- > -- table row's variable of type IsisAdminState is in state on." 365c365 < SYNTAX Unsigned16TC (1..65535) --- > SYNTAX IsisUnsigned16TC (1..65535) 378c378 < SYNTAX Unsigned16TC (1..65535) --- > SYNTAX IsisUnsigned16TC (1..65535) 391c391 < SYNTAX AdminState --- > SYNTAX IsisAdminState 412c412 < SYNTAX Unsigned16TC (350..65535) --- > SYNTAX IsisUnsigned16TC (350..65535) 425c425 < SYNTAX Unsigned16TC (1492..16000) --- > SYNTAX IsisUnsigned16TC (1492..16000) 920c920 < Unsigned16TC, --- > IsisUnsigned16TC, 957c957 < SYNTAX Unsigned16TC (1..65535) --- > SYNTAX IsisUnsigned16TC (1..65535) 1111c1111 < AdminState, --- > IsisAdminState, 1161c1161 < SYNTAX AdminState --- > SYNTAX IsisAdminState 1366c1366 < Unsigned16TC, --- > IsisUnsigned16TC, 1510c1510 < SYNTAX Unsigned16TC (1..65535) --- > SYNTAX IsisUnsigned16TC (1..65535) 2104c2104 < Unsigned16TC, --- > IsisUnsigned16TC, 2211c2211 < SYNTAX Unsigned16TC (1..65535) --- > SYNTAX IsisUnsigned16TC (1..65535) 2453c2453 < AdminState, --- > IsisAdminState, 2496c2496 < SYNTAX AdminState --- > SYNTAX IsisAdminState 2719c2719 < AdminState, --- > IsisAdminState, 2831c2831 < SYNTAX AdminState --- > SYNTAX IsisAdminState 2836c2836 < object follows the AdminState and ManualOrAutomatic --- > object follows the IsisAdminState and ManualOrAutomatic 2944c2944 < Unsigned16TC, --- > IsisUnsigned16TC, 2946c2946 < Unsigned16TC, --- > IsisUnsigned16TC, 2948c2948 < Unsigned16TC, --- > IsisUnsigned16TC, 2950c2950 < Unsigned8TC --- > IsisUnsigned8TC 2987c2987 < SYNTAX Unsigned16TC --- > SYNTAX IsisUnsigned16TC 2995c2995 < SYNTAX Unsigned16TC --- > SYNTAX IsisUnsigned16TC 3004c3004 < SYNTAX Unsigned16TC --- > SYNTAX IsisUnsigned16TC 3012c3012 < SYNTAX Unsigned8TC --- > SYNTAX IsisUnsigned8TC 3057c3057 < Unsigned16TC, --- > IsisUnsigned16TC, 3059c3059 < Unsigned8TC, --- > IsisUnsigned8TC, 3061c3061 < Unsigned8TC, --- > IsisUnsigned8TC, 3084c3084 < SYNTAX Unsigned16TC --- > SYNTAX IsisUnsigned16TC 3092c3092 < SYNTAX Unsigned8TC --- > SYNTAX IsisUnsigned8TC 3100c3100 < SYNTAX Unsigned8TC --- > SYNTAX IsisUnsigned8TC 3160c3160 < SYNTAX Unsigned8TC --- > SYNTAX IsisUnsigned8TC 3168c3168 < SYNTAX Unsigned8TC --- > SYNTAX IsisUnsigned8TC 3177c3177 < SYNTAX Unsigned8TC --- > SYNTAX IsisUnsigned8TC 3195c3195 < SYNTAX Unsigned16TC (0..16000) --- > SYNTAX IsisUnsigned16TC (0..16000) 3206c3206 < SYNTAX Unsigned16TC (0..16000) --- > SYNTAX IsisUnsigned16TC (0..16000) _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Sep 02 10:23:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBCRk-0001bP-ID; Fri, 02 Sep 2005 10:23:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAxzK-000338-Ml for isis-wg@megatron.ietf.org; Thu, 01 Sep 2005 18:56:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04740 for ; Thu, 1 Sep 2005 18:56:52 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAy1K-00080P-VD for isis-wg@ietf.org; Thu, 01 Sep 2005 18:59:01 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j81MuUA6022167; Thu, 1 Sep 2005 17:56:30 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 2 Sep 2005 00:56:29 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507EE0C4B@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Jeff Parker , "C. M. Heard" , Jeff Parker Subject: RE: [Isis-wg] Re: TC name issues in draft-ietf-isis-wg-mib-22.txt Date: Fri, 2 Sep 2005 00:56:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 X-Mailman-Approved-At: Fri, 02 Sep 2005 10:23:08 -0400 Cc: Christian Hopps , ISIS WG X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Inline > -----Original Message----- > From: Jeff Parker [mailto:jparker@world.std.com] > Sent: Thursday, September 01, 2005 19:12 > To: C. M. Heard; Jeff Parker > Cc: Wijnen, Bert (Bert); Christian Hopps; ISIS WG > Subject: Re: [Isis-wg] Re: TC name issues in > draft-ietf-isis-wg-mib-22.txt > > > Thanks for the comments. > > >>>>> - Is it wise to define Unsigned8TC and Unsigned16TC > >>>>> with those generic names) in this MIB module? > >>>>> I know there is already an Unsigned16TC in an IPSP PIB. > > Made these IsisXxx > Thanks > >>>>> - Is it wise to have a AdminState TC with that genetic > >>>>> name in this MIB module? Specifically since it says > >>>>> it is for "enabling or disabling a row" > > Made this IsisAdminState > Thanks > >>>>> - I see quite some text in comments in the MIB modules and > >>>>> wonder if it would not be better to advise them to move > >>>>> it into DESCRIPTION clauses as appropriate? > >>>>> > >>>>> - various DESCRIPTION clauses are pretty terse. > >>>>> > >>>>> I do not think any of the above is a showstopper, > >>>>> I just wonder if you had discussed that with the author(s) > >>>>> and/or WG at all. And I wonder what your opinion is on > >>>>> these sort of things. > > I understand that one man's terse is another man's prolix, > but I'm not sure > which modules are being discussed. I skimmed through the > whole MIB and > didn't find that much relevant in comments outside the > DESCRIPTION clauses. > > I will be happy to move text around or wordsmith if there is > an obscure > clause, but I think the list already has been pretty frank > about objects > they found obscure. I don't see a systemic problem and I > didn't spot any > problematic object. > > Bottom line: give me a reference and I will fix it. > OK, as I said in a previous email, the last thing is not anything to hold the doc hostage over. But if you want examples, here are a few: IsisSystemID ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A system ID." SYNTAX OCTET STRING (SIZE(6)) I am sure that IS-IS people know what "A system ID" is. But all I can tell is that it is 6 octets. I have no idea how it is created/configured, what the format is... etc. I see no REFERENCE clause either, which might point me to the proper IS-IS document that describes the format and semantics of "A system ID". Now I see that when you use the TC in isisSysID that you add a lot of text there. And that is strange. The idea of a TC is that the semantics are described in the TC so that you do not have to repeat it umty times every time you use the same TC. Oh well. Same story for: IsisLinkStatePDUID ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A Link State PDU Identifier." SYNTAX OCTET STRING (SIZE(8)) In fact I think many of your TCs could use a REFERENCE clause. Further, On page 12 I see: -- Behavior Definitions -- ResettingTimer behavior definition -- "This object specifies the interval between certain events in So what is "This object" ?? I see no other occurence of ResettingTimer So where does this belong? -- the operation of the protocol state machine. If the value of -- this object is set to a new value while the protocol state -- machine is in operation, the implementation shall take the -- necessary steps to ensure that for any time interval which -- was in progress when the value of the corresponding object -- was changed, the next expiration of that interval takes place -- the specified time after the original start of that interval, -- or immediately, whichever is later. The precision with which -- this time shall be implemented shall be the same as that -- associated with the basic operation of the timer object." -- ReplaceOnlyWhileDisabled behavior definition -- "This object may not be modified while the corresponding -- table row's variable of type AdminState is in state on." Same questions -- ManualOrAutomatic behavior definition -- "The access of this object is read-write if the row to which -- it belongs is manual (i.e. is being or was created manually) -- otherwise (i.e. was created automatically) it is read-only." Same questions Further I See that for several of your read-write objects, you do not define what the persistency behaviour is or should be. So what can a management application expect after a restart of the agent? Some of the objects I found this for: isisSysLevelType isisSysID isisSysMaxPathSplits isisSysMaxLSPGenInt and probably more objects. That is by the way a type of "blocking" issue. On Page 16 I see: -- The Level 1 Manual Area Address Table -- contains the set of area addresses manually configured -- for this Intermediate System. -- At least one row in which the value of isisManAreaAddrExistState -- is active must be present. The maximum number of rows -- in this table for for which the object -- isisManAreaAddrExistState has the value active is 3. -- An attempt to create more 3 rows of isisManAreaAddrEntry -- with state 'active' in one instance of the IS-IS protocol -- should return inconsistentValue. isisManAreaAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisManAreaAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The set of manual area addresses configured on this Intermediate System." REFERENCE "{ISIS.aoi manualAreaAddresses (10)}" ::= { isisSystem 2 } So I wonder why the commented text (all lines starting with --) are not just put into the DESCIPTION clause. That is the sort of things that I wonder about. Bert _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Sep 05 09:24:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECGxH-0004xL-LU; Mon, 05 Sep 2005 09:24:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECGxG-0004xG-8D for isis-wg@megatron.ietf.org; Mon, 05 Sep 2005 09:24:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16101 for ; Mon, 5 Sep 2005 09:24:08 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECH00-0006iN-Bm for ISIS-wg@ietf.org; Mon, 05 Sep 2005 09:27:02 -0400 Received: by wproxy.gmail.com with SMTP id 68so714872wri for ; Mon, 05 Sep 2005 06:23:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=cLs3a3lxGtrrguxxDWeJGWM7wgEKgrOZmMqcWUs+M1mehM7/8Qq8Aep9YaUoNl0TVZPjnQBl9J4GJ0dyIWJICmKI11q45cEEZ3OHlgOBtNcklpjFgZKoq5fosFIQo982fgZvBRzC0eYNRn5Ve/jDzkMA6fw7sPLad4RJEsTiwpE= Received: by 10.54.23.40 with SMTP id 40mr3698265wrw; Mon, 05 Sep 2005 06:23:58 -0700 (PDT) Received: by 10.54.101.6 with HTTP; Mon, 5 Sep 2005 06:23:58 -0700 (PDT) Message-ID: Date: Mon, 5 Sep 2005 18:53:58 +0530 From: Abhishek Verma To: ISIS-wg@ietf.org Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Subject: [Isis-wg] Authentication X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: abhishekv.verma@gmail.com List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0749005436==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org --===============0749005436== Content-Type: multipart/alternative; boundary="----=_Part_8535_22527257.1125926638887" ------=_Part_8535_22527257.1125926638887 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Please let me know if my understanding of how LSPs are authenticated in=20 ISIS is correct. The purpose of authentication in ISIS is not confidentiality, but to verif= y=20 the originator. This means that the LSP (or any other ISIS packet) is not= =20 encrypted, but a TLV is added at the end of the LSP which carries the=20 digest. The reciever, computes the digest on its own, compares it with what= =20 it recieved, and if both match then it accepts the LSP. The idea is that if= =20 somebody mangled the packet in between, then the digest will not match and= =20 the reciever will ignore this LSP. This way we can be sure that the LSP that we receive was indeed sent by th= e=20 correct router, unless ofcourse, the eavesdropper is aware of the secret ke= y=20 being shared between the two routers. Is this correct? Thanks, Abhishek -- Institute of Technology, BHU Varanasi - India ------=_Part_8535_22527257.1125926638887 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
Hi,
 
Please let me know if my understanding of how LSPs are authenticated i= n ISIS is correct.
 
The purpose of authentication in ISIS is not confidentiality, but to v= erify the originator. This means that the LSP (or any other ISIS packet) is= not encrypted, but a TLV is added at the end of the LSP which carries the = digest. The reciever, computes the digest on its own, compares it with what= it recieved, and if both match then it accepts the LSP. The idea is that i= f somebody mangled the packet in between, then the digest will not match an= d the reciever will ignore this LSP.
 
This way we can be sure that the LSP that we receive was indeed sent b= y the correct router, unless ofcourse, the eavesdropper is aware of the sec= ret key being shared between the two routers.
 
Is this correct?
 
Thanks,
Abhishek
 
--
Institute of Technology, BHU
Varanasi - India
 
------=_Part_8535_22527257.1125926638887-- --===============0749005436== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============0749005436==-- From isis-wg-bounces@ietf.org Mon Sep 05 09:59:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECHV4-00018a-Oa; Mon, 05 Sep 2005 09:59:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECHV2-00018V-PB for isis-wg@megatron.ietf.org; Mon, 05 Sep 2005 09:59:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17146 for ; Mon, 5 Sep 2005 09:59:00 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECHXg-0007QN-O7 for ISIS-wg@ietf.org; Mon, 05 Sep 2005 10:01:54 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IMC00688KFVKA@szxga01-in.huawei.com> for ISIS-wg@ietf.org; Mon, 05 Sep 2005 22:04:44 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IMC00HYMKFVTR@szxga01-in.huawei.com> for ISIS-wg@ietf.org; Mon, 05 Sep 2005 22:04:43 +0800 (CST) Received: from [10.18.4.187] by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IMC00B3UKI96Z@szxml02-in.huawei.com>; Mon, 05 Sep 2005 22:06:09 +0800 (CST) Date: Mon, 05 Sep 2005 19:29:28 +0530 From: Saravana Kumar Subject: Re: [Isis-wg] Authentication In-reply-to: To: abhishekv.verma@gmail.com Message-id: <431C4F40.3040805@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7BIT Cc: ISIS-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Hi Abhishek, Yes, your understanding is correct. The purpose of authentication in ISIS is to ensure that only the PDUs sent by authorized sources are accepted & processed. However this scheme is not fool proof in the sense that it doesnt hold up well against replay attacks. Any malicious router can store the PDUs that it has received over the network and send them at a later point of time to fool the receiving routers to think that the PDU was received from a trusted source and cause some disturbance to the network. E.g. Re-sending LSP purges or hello PDUs which were capturned when the adjacency state was in INIT. Having said that, i should add that the LSPs in ISIS are by default resilient against replay attacks through the use of sequence numbers, i.e any replayed LSP is likely to contain a sequence number which is less or same as that of the LSP stored in the receivers LSDB and normal protocol flow will ensure that the replayed LSPs are not processed. However the hello PDUs in ISIS are vulnerable to the replay attacks where any third party can capture the hellos sent at the beginning of a session establishment and send them later to bring down the adjacency. You can check out the draft http://www.ietf.org/internet-drafts/draft-manral-rp-existingcrypto-00.txt for more details. Regards, Saravana Abhishek Verma wrote: > Hi, > > Please let me know if my understanding of how LSPs are authenticated > in ISIS is correct. > > The purpose of authentication in ISIS is not confidentiality, but to > verify the originator. This means that the LSP (or any other ISIS > packet) is not encrypted, but a TLV is added at the end of the LSP > which carries the digest. The reciever, computes the digest on its > own, compares it with what it recieved, and if both match then it > accepts the LSP. The idea is that if somebody mangled the packet in > between, then the digest will not match and the reciever will ignore > this LSP. > > This way we can be sure that the LSP that we receive was indeed sent > by the correct router, unless ofcourse, the eavesdropper is aware of > the secret key being shared between the two routers. > > Is this correct? > > Thanks, > Abhishek > > -- > Institute of Technology, BHU > Varanasi - India > > >------------------------------------------------------------------------ > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Sep 06 18:50:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECmGj-00021E-1i; Tue, 06 Sep 2005 18:50:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECmGR-0001wp-Gz; Tue, 06 Sep 2005 18:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06751; Tue, 6 Sep 2005 18:50:00 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECmJU-00068H-In; Tue, 06 Sep 2005 18:53:13 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ECmGQ-0001DF-7g; Tue, 06 Sep 2005 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 06 Sep 2005 18:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-te-bis-00.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS extensions for Traffic Engineering Author(s) : T. Li, H. Smit Filename : draft-ietf-isis-te-bis-00.txt Pages : 21 Date : 2005-9-6 This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol (LSP) Data Units. This information describes additional details regarding the state of the network that are useful for traffic engineering computations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-te-bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-isis-te-bis-00.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-isis-te-bis-00.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: <2005-9-6162154.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-te-bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-te-bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-6162154.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --NextPart-- From isis-wg-bounces@ietf.org Wed Sep 07 10:48:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED1E3-00014U-Ke; Wed, 07 Sep 2005 10:48:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED1E2-00014M-Ez for isis-wg@megatron.ietf.org; Wed, 07 Sep 2005 10:48:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24124 for ; Wed, 7 Sep 2005 10:48:32 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED1H9-0007hp-Gl for isis-wg@ietf.org; Wed, 07 Sep 2005 10:51:49 -0400 Received: from du-069-0021.access.clara.net ([217.158.132.21] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1ED1DS-000KiI-82 for isis-wg@ietf.org; Wed, 07 Sep 2005 15:48:23 +0100 Message-ID: <03bd01c5b3bb$88466c20$93849ed9@Puppy> From: "Adrian Farrel" To: References: Subject: Re: [Isis-wg] I-D ACTION:draft-ietf-isis-te-bis-00.txt Date: Wed, 7 Sep 2005 15:50:43 +0100 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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Hi, To save the cycles on my CPU from the onerous responsibility of running diff, can you confirm that the only change so far is the intention to make this standards track? (Incidentally, the heading of the I-D does not have a "Proposed Status" line to make this point.) Could someone also summarize whether any planned changes are known at the moment or whether we are just hoping for a quickish review based on existing implementations. Cheers, Adrian ----- Original Message ----- From: To: Cc: Sent: Tuesday, September 06, 2005 11:50 PM Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-te-bis-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. > > Title : IS-IS extensions for Traffic Engineering > Author(s) : T. Li, H. Smit > Filename : draft-ietf-isis-te-bis-00.txt > Pages : 21 > Date : 2005-9-6 > > This document describes extensions to the Intermediate System to > Intermediate System (IS-IS) protocol to support Traffic Engineering > (TE). This document extends the IS-IS protocol by specifying new > information that an Intermediate System (router) can place in Link > State Protocol (LSP) Data Units. This information describes > additional details regarding the state of the network that are useful > for traffic engineering computations. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-isis-te-bis-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-isis-te-bis-00.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-isis-te-bis-00.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. > -------------------------------------------------------------------------- ------ > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Sep 07 11:26:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED1oL-0000I2-S3; Wed, 07 Sep 2005 11:26:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED1oH-0000Gx-31; Wed, 07 Sep 2005 11:26:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25783; Wed, 7 Sep 2005 11:25:59 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED1rT-0000Fx-Ji; Wed, 07 Sep 2005 11:29:19 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1ED1oG-0005ck-G9; Wed, 07 Sep 2005 11:26:00 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 07 Sep 2005 11:26:00 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: isis-wg@ietf.org Subject: [Isis-wg] Last Call: 'M-ISIS: Multi Topology (MT) Routing in IS-IS' to Proposed Standard X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org The IESG has received a request from the IS-IS for IP Internets WG to consider the following document: - 'M-ISIS: Multi Topology (MT) Routing in IS-IS ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-09-21. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-multi-topology-10.txt _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sun Sep 11 12:32:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEUkP-0002e6-MD; Sun, 11 Sep 2005 12:32:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EE34K-0006Oo-OZ for isis-wg@megatron.ietf.org; Sat, 10 Sep 2005 06:58:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27490 for ; Sat, 10 Sep 2005 06:58:34 -0400 (EDT) Received: from rwcrmhc13.comcast.net ([204.127.198.39] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EE37v-00043l-GF for isis-wg@ietf.org; Sat, 10 Sep 2005 07:02:31 -0400 Received: from comcast.net (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111](misconfigured sender)) by comcast.net (rwcrmhc13) with SMTP id <2005091010582701500iuh31e>; Sat, 10 Sep 2005 10:58:27 +0000 Date: Sat, 10 Sep 2005 03:59:16 -0700 Subject: Re: [Isis-wg] I-D ACTION:draft-ietf-isis-te-bis-00.txt Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) To: Adrian Farrel From: Tony Li In-Reply-To: <03bd01c5b3bb$88466c20$93849ed9@Puppy> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) X-Spam-Score: 0.1 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 11 Sep 2005 12:32:03 -0400 Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Yes, that is the intent of this draft. Please note that the source of the draft has been manually converted to XML, so the results of 'diff' may well be copious. Obviously numerous non-technical changes were required. I'm unaware of any 'accepted' way of adding this intention to the draft boilerplate, but would be happy to do so if educated. You'll find that at the bottom of section 1, there is a new explicit paragraph that references the prior Informational draft and mentions that this version is on the standards track. Tony On Wednesday, September 7, 2005, at 07:50 AM, Adrian Farrel wrote: > Hi, > > To save the cycles on my CPU from the onerous responsibility of running > diff, can you confirm that the only change so far is the intention to > make > this standards track? (Incidentally, the heading of the I-D does not > have > a "Proposed Status" line to make this point.) > > Could someone also summarize whether any planned changes are known at > the > moment or whether we are just hoping for a quickish review based on > existing implementations. > > Cheers, > Adrian > > ----- Original Message ----- > From: > To: > Cc: > Sent: Tuesday, September 06, 2005 11:50 PM > Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-te-bis-00.txt > > >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. >> This draft is a work item of the IS-IS for IP Internets Working Group >> of > the IETF. >> >> Title : IS-IS extensions for Traffic Engineering >> Author(s) : T. Li, H. Smit >> Filename : draft-ietf-isis-te-bis-00.txt >> Pages : 21 >> Date : 2005-9-6 >> >> This document describes extensions to the Intermediate System to >> Intermediate System (IS-IS) protocol to support Traffic Engineering >> (TE). This document extends the IS-IS protocol by specifying new >> information that an Intermediate System (router) can place in Link >> State Protocol (LSP) Data Units. This information describes >> additional details regarding the state of the network that are >> useful >> for traffic engineering computations. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-isis-te-bis-00.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> >> 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-isis-te-bis-00.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-isis-te-bis-00.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. >> > > > ----------------------------------------------------------------------- > --- > ------ > > >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg@ietf.org >> https://www1.ietf.org/mailman/listinfo/isis-wg >> > > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Sep 12 10:37:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEpR7-0002Dw-Oq; Mon, 12 Sep 2005 10:37:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEl2K-0006t7-DQ; Mon, 12 Sep 2005 05:55:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07879; Mon, 12 Sep 2005 05:55:30 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEl6L-0006Xf-Nr; Mon, 12 Sep 2005 05:59:51 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j8C9t8o02192; Mon, 12 Sep 2005 12:55:08 +0300 Date: Mon, 12 Sep 2005 12:55:08 +0300 (EEST) From: Pekka Savola To: iesg@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-Mailman-Approved-At: Mon, 12 Sep 2005 10:37:32 -0400 Cc: isis-wg@ietf.org Subject: [Isis-wg] Re: Last Call: 'M-ISIS: Multi Topology (MT) Routing in IS-IS' to Proposed Standard X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org On Wed, 7 Sep 2005, The IESG wrote: > The IESG has received a request from the IS-IS for IP Internets WG to consider > the following document: > > - 'M-ISIS: Multi Topology (MT) Routing in IS-IS ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2005-09-21. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-multi-topology-10.txt The spec is needed, but needs polishing. There are numerous ID-nits (don't number status of the memo, abstract sections; too long lines; etc.) -- see below *). Section 11.4 states: No attempt is made in this draft to let the M-ISIS IPv6 topology to understand the "normal" IPv6 prefix with TLV type 236. A network SHOULD only run IS-IS either with IPv6 using type 236 or with M-ISIS IPv6 using type 237. ==> I'd like to see why this approach was adopted. How does an operator transition from "regular" IS-IS to multi-topology IS-IS? Is this approach reasonable (enough)? Isn't the same issue also present for v4 MT-ISIS TLVs? *) nits at: http://tools.ietf.org/wg/isis/draft-ietf-isis-wg-multi-topology/draft-ietf-isis-wg-multi-topology-10.nits.txt The most significant one, which may require WG discussion is the lack of IANA considerations section. Specifically, the assignment policies for MT ID values described in section 11.5 require to be spelled out especially for the upper-most block of numbers. You will also need to give pointer to IANA to update the references to this draft for the TLVs that this draft has taken in http://www.iana.org/assignments/isis-tlv-codepoints when this gets published as an RFC. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Sep 14 17:13:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFeZT-0003sK-GA; Wed, 14 Sep 2005 17:13:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFeZO-0003ry-Sh; Wed, 14 Sep 2005 17:13:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12141; Wed, 14 Sep 2005 17:13:28 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFee3-00009g-N4; Wed, 14 Sep 2005 17:18:21 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 14 Sep 2005 14:13:20 -0700 Received: from [128.107.134.5] (naiming-linux.cisco.com [128.107.134.5]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j8ELDJuk028413; Wed, 14 Sep 2005 14:13:20 -0700 (PDT) Message-ID: <4328926D.1040104@cisco.com> Date: Wed, 14 Sep 2005 14:13:17 -0700 From: Naiming Shen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Subject: Re: [Isis-wg] Re: Last Call: 'M-ISIS: Multi Topology (MT) Routing in IS-IS' to Proposed Standard References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Hi Pekka, thanks for the review, and see comments inline. Pekka Savola said the following on 09/12/2005 02:55 AM: > On Wed, 7 Sep 2005, The IESG wrote: > >> The IESG has received a request from the IS-IS for IP Internets WG to >> consider >> the following document: >> >> - 'M-ISIS: Multi Topology (MT) Routing in IS-IS ' >> as a Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send any comments to the >> iesg@ietf.org or ietf@ietf.org mailing lists by 2005-09-21. >> >> The file can be obtained via >> http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-multi-topology-10.txt >> > > > The spec is needed, but needs polishing. There are numerous ID-nits > (don't number status of the memo, abstract sections; too long lines; > etc.) -- see below *). > > Section 11.4 states: > > No attempt is made in this draft to let the M-ISIS IPv6 topology to > understand the "normal" IPv6 prefix with TLV type 236. A network > SHOULD only run IS-IS either with IPv6 using type 236 or with M-ISIS > IPv6 using type 237. > > ==> I'd like to see why this approach was adopted. How does an operator > transition from "regular" IS-IS to multi-topology IS-IS? Is this > approach reasonable (enough)? Isn't the same issue also present for v4 > MT-ISIS TLVs? It's the same issue. The IPv6 prefix with TLV type 236 is part of the 'standard' topology, just like the IPv4 prefix TLV. We don't try to "merge" the IS-IS routing among different topologies. For transition into MT ISIS, there are probably many ways to do it depend on the network requirement. Usually MT is to add some new service on top of the existing infrastructure. E.g. you want to add a QoS topology using some high bandwidth links, when the topology is ready, switch over VoIP traffic onto it gradually from the edge boxes. If one wants to replace the existing "normal" TLVs with the MT TLVs completely without a flag day, then probably taking the approach similar to IS-IS TE metric transition, announce both of them first in both topologies, then switch traffic onto the new topology one by one, then stop announcing in the old topology. I think one router vendor already has such an implementation for exactly this regarding IPv6 topology transition. > > *) nits at: > http://tools.ietf.org/wg/isis/draft-ietf-isis-wg-multi-topology/draft-ietf-isis-wg-multi-topology-10.nits.txt > > > The most significant one, which may require WG discussion is the lack of > IANA considerations section. Specifically, the assignment policies for > MT ID values described in section 11.5 require to be spelled out > especially for the upper-most block of numbers. You will also need to > give pointer to IANA to update the references to this draft for the TLVs > that this draft has taken in > http://www.iana.org/assignments/isis-tlv-codepoints when this gets > published as an RFC. > I'll take care of the nits above. for the IANA, we received this message: IESG: The IANA has reviewed the following Internet-Draft which is in Last Call: draft-ietf-isis-wg-multi-topology-10.txt, and has the following with regards to the publication of this document: NO IANA Considerations section We understand this document to have NO IANA Actions. Thank you. Michelle Cotton (on behalf of IANA) and yes, good point, we'll need to give them the pointers for updating the content of http://www.iana.org/assignments/isis-tlv-codepoints as you described. thanks. - Naiming > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Sep 16 02:37:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG9r2-0004vY-RB; Fri, 16 Sep 2005 02:37:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG9r0-0004vN-Md; Fri, 16 Sep 2005 02:37:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27425; Fri, 16 Sep 2005 02:37:44 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EG9vw-0003Ln-W3; Fri, 16 Sep 2005 02:42:54 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j8G6bN510000; Fri, 16 Sep 2005 09:37:23 +0300 Date: Fri, 16 Sep 2005 09:37:23 +0300 (EEST) From: Pekka Savola To: Naiming Shen Subject: Re: [Isis-wg] Re: Last Call: 'M-ISIS: Multi Topology (MT) Routing in IS-IS' to Proposed Standard In-Reply-To: <4328926D.1040104@cisco.com> Message-ID: References: <4328926D.1040104@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: iesg@ietf.org, isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org On Wed, 14 Sep 2005, Naiming Shen wrote: >> ==> I'd like to see why this approach was adopted. How does an operator >> transition from "regular" IS-IS to multi-topology IS-IS? Is this approach >> reasonable (enough)? Isn't the same issue also present for v4 MT-ISIS >> TLVs? > > It's the same issue. The IPv6 prefix with TLV type 236 is part of the > 'standard' topology, just like the IPv4 prefix TLV. We don't try to > "merge" the IS-IS routing among different topologies. How come the issue is only mentioned under IPv6 and not consistently with both or in a more generic place, like in introduction (smells like an applicability statement which should be clearly stated up front). >> *) nits at: >> http://tools.ietf.org/wg/isis/draft-ietf-isis-wg-multi-topology/draft-ietf-isis-wg-multi-topology-10.nits.txt >> >> The most significant one, which may require WG discussion is the lack of >> IANA considerations section. Specifically, the assignment policies for MT >> ID values described in section 11.5 require to be spelled out especially >> for the upper-most block of numbers. You will also need to give pointer to >> IANA to update the references to this draft for the TLVs that this draft >> has taken in http://www.iana.org/assignments/isis-tlv-codepoints when this >> gets published as an RFC. >> > > I'll take care of the nits above. for the IANA, we received this message: > > IESG: > > The IANA has reviewed the following Internet-Draft which is in Last > Call: draft-ietf-isis-wg-multi-topology-10.txt, and has the following > with regards to the publication of this document: > > NO IANA Considerations section > We understand this document to have NO IANA Actions. > > Thank you. > > Michelle Cotton > (on behalf of IANA) > > and yes, good point, we'll need to give them the pointers for updating > the content of http://www.iana.org/assignments/isis-tlv-codepoints > as you described. Note that IANA *thinks* there is nothing to do (because the doc had no IANA considerations section), but they are wrong and you should give them a heads-up. You probably need to create an IANA registry for the ID values and specify the assignment policy, as well as do minor updates on the existing registries. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Sep 19 15:00:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHQsM-0001ze-Vx; Mon, 19 Sep 2005 15:00:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHQsM-0001zW-Au; Mon, 19 Sep 2005 15:00:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14472; Mon, 19 Sep 2005 15:00:24 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHQy1-0000zJ-57; Mon, 19 Sep 2005 15:06:18 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 19 Sep 2005 12:00:15 -0700 X-IronPort-AV: i="3.97,123,1125903600"; d="scan'208"; a="343130181:sNHT31001204" Received: from [128.107.134.5] (naiming-linux.cisco.com [128.107.134.5]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8JJ0D4V000967; Mon, 19 Sep 2005 12:00:13 -0700 (PDT) Message-ID: <432F0ABC.6010207@cisco.com> Date: Mon, 19 Sep 2005 12:00:12 -0700 From: Naiming Shen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Subject: Re: [Isis-wg] Re: Last Call: 'M-ISIS: Multi Topology (MT) Routing in IS-IS' to Proposed Standard References: <4328926D.1040104@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Pekka, Pekka Savola said the following on 09/15/2005 11:37 PM: > On Wed, 14 Sep 2005, Naiming Shen wrote: > >>> ==> I'd like to see why this approach was adopted. How does an >>> operator transition from "regular" IS-IS to multi-topology IS-IS? Is >>> this approach reasonable (enough)? Isn't the same issue also >>> present for v4 MT-ISIS TLVs? >> >> >> It's the same issue. The IPv6 prefix with TLV type 236 is part of the >> 'standard' topology, just like the IPv4 prefix TLV. We don't try to >> "merge" the IS-IS routing among different topologies. > > > How come the issue is only mentioned under IPv6 and not consistently with > both or in a more generic place, like in introduction (smells like an > applicability statement which should be clearly stated up front). > This draft has been dragged so long, from I recall, in the earlier versions, when this IPv6 MT TLV was introduced, there were sentenses mentioning to let the new topology to understand the "normal" topology IPv6 TLVs, it had some one directional "merging" of routing intention at the time. That was a mistake on author's side and was scrached in ver04 of the draft. The above paragraph was added later due to someone want us to explicitly mention that there was no relation between the two IPv6 topologies. I think we should remove this paragraph now if there is no objection from the working group. >>> *) nits at: >>> http://tools.ietf.org/wg/isis/draft-ietf-isis-wg-multi-topology/draft-ietf-isis-wg-multi-topology-10.nits.txt >>> >>> >>> The most significant one, which may require WG discussion is the lack >>> of IANA considerations section. Specifically, the assignment >>> policies for MT ID values described in section 11.5 require to be >>> spelled out especially for the upper-most block of numbers. You will >>> also need to give pointer to IANA to update the references to this >>> draft for the TLVs that this draft has taken in >>> http://www.iana.org/assignments/isis-tlv-codepoints when this gets >>> published as an RFC. >>> >> >> I'll take care of the nits above. for the IANA, we received this >> message: >> >> IESG: >> >> The IANA has reviewed the following Internet-Draft which is in Last >> Call: draft-ietf-isis-wg-multi-topology-10.txt, and has the following >> with regards to the publication of this document: >> >> NO IANA Considerations section We understand this document to have NO >> IANA Actions. >> >> Thank you. >> >> Michelle Cotton (on behalf of IANA) >> >> and yes, good point, we'll need to give them the pointers for updating >> the content of http://www.iana.org/assignments/isis-tlv-codepoints as >> you described. > > > Note that IANA *thinks* there is nothing to do (because the doc had no > IANA considerations section), but they are wrong and you should give them > a heads-up. You probably need to create an IANA registry for the ID > values and specify the assignment policy, as well as do minor updates on > the existing registries. > Ok, will do that. You may need to educate me on how to create an IANA registry for this. thanks. - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Sep 20 02:31:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHbfK-0002pi-Ap; Tue, 20 Sep 2005 02:31:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHbfJ-0002pZ-Ed; Tue, 20 Sep 2005 02:31:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10224; Tue, 20 Sep 2005 02:31:39 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHbl5-0002RO-8Z; Tue, 20 Sep 2005 02:37:39 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j8K6VTb22002; Tue, 20 Sep 2005 09:31:29 +0300 Date: Tue, 20 Sep 2005 09:31:29 +0300 (EEST) From: Pekka Savola To: Naiming Shen Subject: Re: [Isis-wg] Re: Last Call: 'M-ISIS: Multi Topology (MT) Routing in IS-IS' to Proposed Standard In-Reply-To: <432F0ABC.6010207@cisco.com> Message-ID: References: <4328926D.1040104@cisco.com> <432F0ABC.6010207@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: iesg@ietf.org, isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org On Mon, 19 Sep 2005, Naiming Shen wrote: >> How come the issue is only mentioned under IPv6 and not consistently with >> both or in a more generic place, like in introduction (smells like an >> applicability statement which should be clearly stated up front). > > This draft has been dragged so long, from I recall, in the earlier versions, > when this IPv6 MT TLV was introduced, there were sentenses mentioning > to let the new topology to understand the "normal" topology IPv6 TLVs, > it had some one directional "merging" of routing intention at the time. > That was a mistake on author's side and was scrached in ver04 of the draft. > The above paragraph was added later due to someone want us to explicitly > mention that there was no relation between the two IPv6 topologies. > I think we should remove this paragraph now if there is no objection > from the working group. In principle, I think a generalized rewording of the applicability statement (for both v4 and v6) would be useful and should be included but it should be placed in the Introduction or some other relevant part of the spec so it's more prominent. >> Note that IANA *thinks* there is nothing to do (because the doc had no IANA >> considerations section), but they are wrong and you should give them >> a heads-up. You probably need to create an IANA registry for the ID >> values and specify the assignment policy, as well as do minor updates on >> the existing registries. > > Ok, will do that. You may need to educate me on how to create an IANA > registry for this. Ok, maybe the example IANA considerations section below gives an idea how to instruct IANA to create a new registry. Note: the text may need some tweaking, and there are issues which need to be ironed out, for example, - the assignment policies may need discussion in the WG -- i.e., is "IETF Consensus" (basically requires an IETF-published RFC and a bit more) appropriate for new assignments? - Should there be a FCFS or expert review mechanism to reserve a part of the experimental ID space so that the folks using those spaces could request them from IANA (instead of just grabbing a number at random)? - should the number 2^12-1 be reserved for special purposes if it'd ever be needed? =========== IANA Considerations IANA is requested to create a new registry, "IS-IS multi-topology ID values" with the following assignments made in this document and registration policies for future assignments: - MT ID #0: Equivalent to the ``standard'' topology. - MT ID #1: Reserved for IPv4 in-band management purposes. - MT ID #2: Reserved for IPv6 routing topology. - MT ID #3: Reserved for IPv4 multicast routing topology. - MT ID #4: Reserved for IPv6 multicast routing topology. - MT ID #5-#3995: Assigned by IETF Consensus [RFC2434]. - MT ID #3996-#4095: Reserved for development, experimental and proprietary features [RFC3692]. IANA is also requested to update the IS-IS codepoint registry (http://www.iana.org/assignments/isis-tlv-codepoints) so that codes 222, 229, 235 and 237 refer to this document's RFC number. [[ note to the RFC-editor: the above paragraph may be removed or reworded prior to RFC publication ]] -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Sep 20 17:05:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHpIm-0006Iu-0r; Tue, 20 Sep 2005 17:05:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHpIg-0006Hi-Fl; Tue, 20 Sep 2005 17:05:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05696; Tue, 20 Sep 2005 17:05:11 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHpOZ-0003N1-1Y; Tue, 20 Sep 2005 17:11:20 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 20 Sep 2005 14:05:03 -0700 X-IronPort-AV: i="3.97,127,1125903600"; d="scan'208"; a="343659741:sNHT32450692" Received: from [128.107.134.5] (naiming-linux.cisco.com [128.107.134.5]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8KL514V024642; Tue, 20 Sep 2005 14:05:01 -0700 (PDT) Message-ID: <4330797C.80501@cisco.com> Date: Tue, 20 Sep 2005 14:05:00 -0700 From: Naiming Shen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Subject: Re: [Isis-wg] Re: Last Call: 'M-ISIS: Multi Topology (MT) Routing in IS-IS' to Proposed Standard References: <4328926D.1040104@cisco.com> <432F0ABC.6010207@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Pekka Savola said the following on 09/19/2005 11:31 PM: > On Mon, 19 Sep 2005, Naiming Shen wrote: > >>> How come the issue is only mentioned under IPv6 and not consistently >>> with >>> both or in a more generic place, like in introduction (smells like an >>> applicability statement which should be clearly stated up front). >> >> >> This draft has been dragged so long, from I recall, in the earlier >> versions, >> when this IPv6 MT TLV was introduced, there were sentenses mentioning >> to let the new topology to understand the "normal" topology IPv6 TLVs, >> it had some one directional "merging" of routing intention at the time. >> That was a mistake on author's side and was scrached in ver04 of the >> draft. >> The above paragraph was added later due to someone want us to explicitly >> mention that there was no relation between the two IPv6 topologies. >> I think we should remove this paragraph now if there is no objection >> from the working group. > > > In principle, I think a generalized rewording of the applicability > statement (for both v4 and v6) would be useful and should be included > but it should be placed in the Introduction or some other relevant part > of the spec so it's more prominent. > Sure, I'll update it somewhere in Introduction area. >>> Note that IANA *thinks* there is nothing to do (because the doc had >>> no IANA considerations section), but they are wrong and you should >>> give them >>> a heads-up. You probably need to create an IANA registry for the ID >>> values and specify the assignment policy, as well as do minor updates on >>> the existing registries. >> >> >> Ok, will do that. You may need to educate me on how to create an IANA >> registry for this. > > > Ok, maybe the example IANA considerations section below gives an idea > how to instruct IANA to create a new registry. Note: the text may need > some tweaking, and there are issues which need to be ironed out, for > example, > - the assignment policies may need discussion in the WG -- i.e., is > "IETF Consensus" (basically requires an IETF-published RFC and a bit > more) appropriate for new assignments? > - Should there be a FCFS or expert review mechanism to reserve a part > of the experimental ID space so that the folks using those spaces could > request them from IANA (instead of just grabbing a number at random)? > - should the number 2^12-1 be reserved for special purposes if it'd > ever be needed? > > > =========== > IANA Considerations > > IANA is requested to create a new registry, "IS-IS multi-topology ID > values" with the following assignments made in this document and > registration policies for future assignments: > > - MT ID #0: Equivalent to the ``standard'' topology. > - MT ID #1: Reserved for IPv4 in-band management purposes. > - MT ID #2: Reserved for IPv6 routing topology. > - MT ID #3: Reserved for IPv4 multicast routing topology. > - MT ID #4: Reserved for IPv6 multicast routing topology. > - MT ID #5-#3995: Assigned by IETF Consensus [RFC2434]. > - MT ID #3996-#4095: Reserved for development, experimental and > proprietary features [RFC3692]. > > IANA is also requested to update the IS-IS codepoint registry > (http://www.iana.org/assignments/isis-tlv-codepoints) so that codes > 222, 229, 235 and 237 refer to this document's RFC number. > > [[ note to the RFC-editor: the above paragraph may be removed or > reworded prior to RFC publication ]] > Cool. thanks for the suggested text. will update the draft. thanks. - Naiming > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Sep 20 18:44:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHqqY-0001Sb-IB; Tue, 20 Sep 2005 18:44:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHqqX-0001SW-Qf for isis-wg@megatron.ietf.org; Tue, 20 Sep 2005 18:44:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12091 for ; Tue, 20 Sep 2005 18:44:14 -0400 (EDT) Received: from adsl-66-120-207-101.dsl.sntc01.pacbell.net ([66.120.207.101] helo=coffee.rawdofmt.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHqwP-0005pH-9i for isis-wg@ietf.org; Tue, 20 Sep 2005 18:50:24 -0400 Received: from [?0?IPv6:::1] (localhost [127.0.0.1]) by coffee.rawdofmt.org (Postfix) with ESMTP id 590353DCC8B; Tue, 20 Sep 2005 15:43:56 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Christian Hopps Date: Tue, 20 Sep 2005 15:43:58 -0700 To: ISIS WG X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Cc: Tony Li Subject: [Isis-wg] WG Last Call for draft-ietf-isis-te-bis-00.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Given draft-ietf-isis-te-bis-00.txt is just a reissue for standards track, and has been reviewed, implemented and deployed, we are placing the new draft in WG Last Call. If you have any comments please submit them in the next 2 weeks. Chris & Dave. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Sep 27 08:06:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKEEH-00064S-L0; Tue, 27 Sep 2005 08:06:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKEEF-00064K-SD for isis-wg@megatron.ietf.org; Tue, 27 Sep 2005 08:06:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03032 for ; Tue, 27 Sep 2005 08:06:35 -0400 (EDT) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKELS-00038G-Cn for isis-wg@ietf.org; Tue, 27 Sep 2005 08:14:05 -0400 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j8RC6TxV020861 for ; Tue, 27 Sep 2005 07:06:30 -0500 (CDT) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 27 Sep 2005 17:36:27 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D21AEC7A3E@ii0015exch002u.iprc.lucent.com> From: "Ramalingam, Swaminathan (Swaminathan)" To: isis-wg@ietf.org Date: Tue, 27 Sep 2005 17:35:49 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Isis-wg] areaTransmitPassword/domainTransmitPassword X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Hi- If a system is configured with no password, and L1/L2 LSP/CSNPs are received with some passwords, what should be the behaviour of processing those LSPs/CSNPs. I believe it should be dropped as the system is configured with no password and receiving LSPs/CSNPs with passwords. Please comment on this. But in the ISO 10589 & RFC 1195, there is no explicit mentioning of this. It might mislead some implementators to accept L1/L2 LSP/CSNPs in this case. Thanks, Swami _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Sep 27 08:59:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKF3a-0001lg-4F; Tue, 27 Sep 2005 08:59:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKF3X-0001kk-Le for isis-wg@megatron.ietf.org; Tue, 27 Sep 2005 08:59:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05567 for ; Tue, 27 Sep 2005 08:59:34 -0400 (EDT) Received: from usaga01-in.huawei.com ([12.129.211.51] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKFAl-0004MI-Kn for isis-wg@ietf.org; Tue, 27 Sep 2005 09:07:05 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0INH003DT7XIR4@usaga01-in.huawei.com> for isis-wg@ietf.org; Tue, 27 Sep 2005 05:56:07 -0700 (PDT) Received: from huawei.com ([172.17.1.218]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0INH00GK87XHQC@usaga01-in.huawei.com> for isis-wg@ietf.org; Tue, 27 Sep 2005 05:56:06 -0700 (PDT) Received: from [172.24.1.3] (Forwarded-For: [172.24.2.12]) by szxmc02-in.huawei.com (mshttpd); Tue, 27 Sep 2005 20:59:40 +0800 Date: Tue, 27 Sep 2005 20:59:40 +0800 From: saravanak 70193 Subject: Re: [Isis-wg] areaTransmitPassword/domainTransmitPassword To: swamir@lucent.com Message-id: <27113c272aef.272aef27113c@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: multipart/mixed; boundary="Boundary_(ID_T1SnOJ0A1P6/iG2xeeRYOg)" Content-language: en X-Accept-Language: en Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_T1SnOJ0A1P6/iG2xeeRYOg) Content-type: text/plain; charset=us-ascii Content-disposition: inline Content-Transfer-Encoding: 7BIT The simple answer to your question is that the system should accept and process the LSPs/CSNPs with passwords. The security mechanism in ISIS (if used) ensures that only the information from trusted sources are processed. An administrator setting up a network will configure all the ISIS systems with the same authentication information, so that they can accept and process only the LSPs from the routers within the trusted group. A malicious system may try to inject some wrong information into the network (flapping links for e.g) but it wont be processed as it doesnt pass the authentication checks. If a system is not configured with any password then it means that its administrator is not concerned about the sources from which the routing information is received (perhaps his part of the network is in secure premisis, so he doesnt need to use area authentication and can opt for domain authentication in the backbone) and it is free to process all the received LSPs. Hope this explained your question, if you have any further concerns about the behaviour plz let me know. - Saravana ----- Original Message ----- From: isis-wg-bounces@ietf.org Date: Tuesday, September 27, 2005 8:16 pm > Hi- > > If a system is configured with no password, and L1/L2 LSP/CSNPs are > receivedwith some passwords, what should be the behaviour of > processing those > LSPs/CSNPs. > > I believe it should be dropped as the system is configured with no > passwordand receiving LSPs/CSNPs with passwords. Please comment on > this. > But in the ISO 10589 & RFC 1195, there is no explicit mentioning of > this. It > might mislead some implementators to accept L1/L2 LSP/CSNPs in this > case. > > > Thanks, > Swami > --Boundary_(ID_T1SnOJ0A1P6/iG2xeeRYOg) Content-type: text/x-vcard; name=s70193.vcf; charset=windows-1252 Content-disposition: attachment; filename=s70193.vcf Content-description: Card for saravanak 70193 Content-Transfer-Encoding: 7BIT begin:vcard n:Kumar;Saravana fn:Saravana Kumar version:2.1 email;internet:saravanak@huawei.com end:vcard --Boundary_(ID_T1SnOJ0A1P6/iG2xeeRYOg) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --Boundary_(ID_T1SnOJ0A1P6/iG2xeeRYOg)-- From isis-wg-bounces@ietf.org Tue Sep 27 09:29:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKFWY-00089o-Iu; Tue, 27 Sep 2005 09:29:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKFWX-00086s-5O for isis-wg@megatron.ietf.org; Tue, 27 Sep 2005 09:29:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07218 for ; Tue, 27 Sep 2005 09:29:31 -0400 (EDT) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKFdl-0005CU-DX for isis-wg@ietf.org; Tue, 27 Sep 2005 09:37:03 -0400 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j8RDTLKg000940; Tue, 27 Sep 2005 08:29:22 -0500 (CDT) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 27 Sep 2005 18:59:19 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D21AEC7AFE@ii0015exch002u.iprc.lucent.com> From: "Ramalingam, Swaminathan (Swaminathan)" To: saravanak 70193 , "Ramalingam, Swaminathan (Swaminathan)" Subject: RE: [Isis-wg] areaTransmitPassword/domainTransmitPassword Date: Tue, 27 Sep 2005 18:59:11 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Saravanak, I guess, no administrator will configure password on just one peer. It doesn't serve any purpose. Assuming on error scenario like this (misconfiguration), for a source and destination, route will be available on one path and the reverse path, there will not be path available. Though the routing protocol adjacencies' are perfect on all links including misconfigured link, few routes are still unreachable. This sounds little weird to me. Any thoughts? Thanks, Swami > -----Original Message----- > From: saravanak 70193 [mailto:saravanak@huawei.com] > Sent: Tuesday, September 27, 2005 6:30 PM > To: swamir@lucent.com > Cc: isis-wg@ietf.org > Subject: Re: [Isis-wg] areaTransmitPassword/domainTransmitPassword > > > > The simple answer to your question is that the system should > accept and process the LSPs/CSNPs with passwords. > > The security mechanism in ISIS (if used) ensures that only > the information from trusted sources are processed. An > administrator setting up a network will configure all the > ISIS systems with the same authentication information, so > that they can accept and process only the LSPs from the > routers within the trusted group. A malicious system may try > to inject some wrong information into the network (flapping > links for e.g) but it wont be processed as it doesnt pass the > authentication checks. > > If a system is not configured with any password then it means > that its administrator is not concerned about the sources > from which the routing information is received (perhaps his > part of the network is in secure premisis, so he doesnt need > to use area authentication and can opt for domain > authentication in the backbone) and it is free to process all > the received LSPs. > > Hope this explained your question, if you have any further > concerns about the behaviour plz let me know. > > - Saravana > > ----- Original Message ----- > From: isis-wg-bounces@ietf.org > Date: Tuesday, September 27, 2005 8:16 pm > > > Hi- > > > > If a system is configured with no password, and L1/L2 LSP/CSNPs are > > receivedwith some passwords, what should be the behaviour of > > processing those > > LSPs/CSNPs. > > > > I believe it should be dropped as the system is configured with no > > passwordand receiving LSPs/CSNPs with passwords. Please comment on > > this. > > But in the ISO 10589 & RFC 1195, there is no explicit mentioning of > > this. It > > might mislead some implementators to accept L1/L2 LSP/CSNPs in this > > case. > > > > > > Thanks, > > Swami > > > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Sep 27 20:24:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKPk3-0006cT-QT; Tue, 27 Sep 2005 20:24:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKPk2-0006c2-M7 for isis-wg@megatron.ietf.org; Tue, 27 Sep 2005 20:24:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00467 for ; Tue, 27 Sep 2005 20:24:09 -0400 (EDT) Received: from rwcrmhc11.comcast.net ([216.148.227.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKPrN-0001XD-Kj for isis-wg@ietf.org; Tue, 27 Sep 2005 20:31:46 -0400 Received: from [192.168.0.100] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (rwcrmhc11) with SMTP id <20050928002351013003v2j6e>; Wed, 28 Sep 2005 00:23:51 +0000 In-Reply-To: <6733C768256DEC42A72BAFEFA9CF06D21AEC7A3E@ii0015exch002u.iprc.lucent.com> References: <6733C768256DEC42A72BAFEFA9CF06D21AEC7A3E@ii0015exch002u.iprc.lucent.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8F218CCA-F1C2-4684-B472-6F24525071F7@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Isis-wg] areaTransmitPassword/domainTransmitPassword Date: Tue, 27 Sep 2005 17:23:49 -0700 To: "Ramalingam, Swaminathan (Swaminathan)" X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org I'll also point out that accepting the PDUs allows you to transition to a fully authenticated network in a smooth fashion. Tony On Sep 27, 2005, at 5:05 AM, Ramalingam, Swaminathan (Swaminathan) wrote: > Hi- > > If a system is configured with no password, and L1/L2 LSP/CSNPs are > received > with some passwords, what should be the behaviour of processing those > LSPs/CSNPs. > > I believe it should be dropped as the system is configured with no > password > and receiving LSPs/CSNPs with passwords. Please comment on this. > > But in the ISO 10589 & RFC 1195, there is no explicit mentioning of > this. It > might mislead some implementators to accept L1/L2 LSP/CSNPs in this > case. > > > > Thanks, > Swami > > > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Sep 30 11:43:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELN2q-0008Ms-VX; Fri, 30 Sep 2005 11:43:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKrVV-0003Rv-4J for isis-wg@megatron.ietf.org; Thu, 29 Sep 2005 02:03:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08622 for ; Thu, 29 Sep 2005 02:02:59 -0400 (EDT) From: fab12@freesurf.fr Received: from fidel.freesurf.fr ([212.43.206.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKrcx-0007YT-6E for isis-wg@ietf.org; Thu, 29 Sep 2005 02:10:52 -0400 Received: from freesurf.fr (arlette.freesurf.fr [212.43.206.12]) by fidel.freesurf.fr (Postfix) with SMTP id 013EF2A747A for ; Thu, 29 Sep 2005 08:02:24 +0200 (CEST) Received: from 195.68.44.146 (SquirrelMail authenticated user fab12) by arlette.freesurf.fr with HTTP; Thu, 29 Sep 2005 08:02:23 +0200 (CEST) Message-ID: <55795.195.68.44.146.1127973743.squirrel@arlette.freesurf.fr> Date: Thu, 29 Sep 2005 08:02:23 +0200 (CEST) Subject: Re: [Isis-wg] areaTransmitPassword/domainTransmitPassword To: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.5) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.2 (+) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 30 Sep 2005 11:43:30 -0400 X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Except that ISs supporting authentication will refuse the PDU with no password, won't they? >I'll also point out that accepting the PDUs allows you to transition >to a fully authenticated network in a smooth fashion. > >Tony On Sep 27, 2005, at 5:05 AM, Ramalingam, Swaminathan (Swaminathan) wrote: > Hi- > > If a system is configured with no password, and L1/L2 LSP/CSNPs are > received > with some passwords, what should be the behaviour of processing those > LSPs/CSNPs. > > I believe it should be dropped as the system is configured with no > password > and receiving LSPs/CSNPs with passwords. Please comment on this. > > But in the ISO 10589 & RFC 1195, there is no explicit mentioning of > this. It > might mislead some implementators to accept L1/L2 LSP/CSNPs in this > case. > > > > Thanks, > Swami > > > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Sep 30 12:46:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELO1S-0001Pu-4V; Fri, 30 Sep 2005 12:46:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELO1O-0001Po-0g for isis-wg@megatron.ietf.org; Fri, 30 Sep 2005 12:46:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20386 for ; Fri, 30 Sep 2005 12:46:03 -0400 (EDT) Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELO9G-0001oD-TZ for isis-wg@ietf.org; Fri, 30 Sep 2005 12:54:16 -0400 Received: from unknown (HELO beta.jnpr.net) (172.24.18.109) by kremlin.juniper.net with ESMTP; 30 Sep 2005 09:45:56 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,147,1125903600"; d="scan'208"; a="484538945:sNHT494063952" Received: from [172.26.200.5] ([172.26.200.5]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 30 Sep 2005 09:45:54 -0700 Message-ID: <433D6BC1.2080703@juniper.net> Date: Fri, 30 Sep 2005 18:45:53 +0200 From: Hannes Gredler User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: fab12@freesurf.fr Subject: Re: [Isis-wg] areaTransmitPassword/domainTransmitPassword References: <55795.195.68.44.146.1127973743.squirrel@arlette.freesurf.fr> In-Reply-To: <55795.195.68.44.146.1127973743.squirrel@arlette.freesurf.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Sep 2005 16:45:55.0081 (UTC) FILETIME=[6CECFF90:01C5C5DE] X-Spam-Score: 1.1 (+) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org as tony has pointed out that is again a matter how friendly the implementation is to migration scenarios . for example in a migration scenario (non-auth -> auth) you might not flag-day migrate all routers in a single maintenance window .. therefore it might make sense to run a full authentication check on the PDU if TLV #10 is present and do kinda "loose" authentication check if TLV #10 is not present; at the end of the migration period the router is configured to "raise the shields" and both check "the TLV #10 present" and "the TLV #10 not-present" case; /hannes fab12@freesurf.fr wrote: > Except that ISs supporting authentication will refuse the PDU with no > password, won't they? > > >>I'll also point out that accepting the PDUs allows you to transition >>to a fully authenticated network in a smooth fashion. >> >>Tony > > > > > On Sep 27, 2005, at 5:05 AM, Ramalingam, Swaminathan (Swaminathan) > wrote: > > >>Hi- >> >>If a system is configured with no password, and L1/L2 LSP/CSNPs are >>received >>with some passwords, what should be the behaviour of processing those >>LSPs/CSNPs. >> >>I believe it should be dropped as the system is configured with no >>password >>and receiving LSPs/CSNPs with passwords. Please comment on this. >> >>But in the ISO 10589 & RFC 1195, there is no explicit mentioning of >>this. It >>might mislead some implementators to accept L1/L2 LSP/CSNPs in this >>case. >> >> >> >>Thanks, >>Swami >> >> >> >>_______________________________________________ >>Isis-wg mailing list >>Isis-wg@ietf.org >>https://www1.ietf.org/mailman/listinfo/isis-wg >> > > > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > > > > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Sep 30 12:47:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELO3A-0001br-JA; Fri, 30 Sep 2005 12:47:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELO33-0001bY-Sx for isis-wg@megatron.ietf.org; Fri, 30 Sep 2005 12:47:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20454 for ; Fri, 30 Sep 2005 12:47:47 -0400 (EDT) Received: from web31809.mail.mud.yahoo.com ([68.142.207.72]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ELOAw-0001qH-Kv for isis-wg@ietf.org; Fri, 30 Sep 2005 12:56:00 -0400 Received: (qmail 90846 invoked by uid 60001); 30 Sep 2005 16:47:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=v5BJH9qWFIouk9q0RfThT+i+4wyWDPXV/O598SpBwwkbo8jFZ/iacfQb+X7heRVBD7zpyUg7vmOwNTIo+VzCKzxh/gRFBuzqKZeOOjzvRm9m9BVd6K2d0HKD/NjgSwQrn1LhokSK+Vo3BJWlppSKEyLlhDuReqVqAmnxWzKeJ7I= ; Message-ID: <20050930164739.90844.qmail@web31809.mail.mud.yahoo.com> Received: from [67.170.225.38] by web31809.mail.mud.yahoo.com via HTTP; Fri, 30 Sep 2005 09:47:39 PDT Date: Fri, 30 Sep 2005 09:47:39 -0700 (PDT) From: Satish Dattatri Subject: Re: [Isis-wg] areaTransmitPassword/domainTransmitPassword To: fab12@freesurf.fr, isis-wg@ietf.org In-Reply-To: <55795.195.68.44.146.1127973743.squirrel@arlette.freesurf.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 8bit Cc: X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Please refer to D.2 of RFC1195 to see how seamless transition could be done with Receive and Transmitt password(s). That mechanism is not specific to simple passwords. Satish --- fab12@freesurf.fr wrote: > Except that ISs supporting authentication will refuse the PDU with no > password, won't they? > > >I'll also point out that accepting the PDUs allows you to transition > >to a fully authenticated network in a smooth fashion. > > > >Tony > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg