From rcallon@juniper.net Sun Jan 2 16:57:21 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95BB63A6936 for ; Sun, 2 Jan 2011 16:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.593 X-Spam-Level: X-Spam-Status: No, score=-106.593 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNXBetP+aeTP for ; Sun, 2 Jan 2011 16:57:16 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 4C5673A6933 for ; Sun, 2 Jan 2011 16:57:07 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTSEfYjgBQbuxFwgpXBV3titx7rbTD4jS@postini.com; Sun, 02 Jan 2011 16:59:22 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 2 Jan 2011 16:53:45 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Sun, 2 Jan 2011 19:53:45 -0500 From: Ross Callon To: "rtg-ads@tools.ietf.org" Date: Sun, 2 Jan 2011 19:53:43 -0500 Thread-Topic: Review of draft-ietf-isis-layer2-09 Thread-Index: AcuqGEmc33rSojB0SmODdRqwfGAMNwAx5NEQ Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB177049AC8B6E657EMBX01WFjnprn_" MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "draft-ietf-isis-layer2.all@tools.ietf.org" Subject: [RTG-DIR] Review of draft-ietf-isis-layer2-09 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 00:57:21 -0000 --_000_DF7F294AF4153D498141CBEFADB177049AC8B6E657EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have been asked to provide an additional Routing Directorate review for t= his draft. The Routing Directorate seeks to review all routing or routing-r= elated drafts as they pass through IETF last call and IESG review. The purp= ose of the review is to provide assistance to the Routing ADs. For more inf= ormation about the Routing Directorate, please see http://www.ietf.org/iesg= /directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-isis-layer2-09.txt Reviewer: Ross Callon Review Date: 2011-01-02 IETF LC End Date: 2010-12-14 Intended Status: proposed standard Summary: I have only very minor concerns about this document. While these are of a n= ature that the RFC editor staff might be expected to identify and fix, you = may nonetheless want to resolve these before publication. Comments: The document is well written and structured, and generally conforms to the = conventional definition of IS-IS TLVs. Major Issues: No major issues found. Minor Issues: Section 2.2, The bullet item "Type: TLV Type, set to MT-PORT-CAP TLV 143 [T= BD]." My understanding is that the value 143 was incorrectly picked (and overlaps= with a different meaning of the same value). My understanding is also that= the "TBD" means that this was tentative. This will need to be corrected pr= ior to publication, and you might want to add an RFC editor's note to this = effect (or at least make sure that you check this during auth-48). Section 6.2, informative references. The third reference. I believe that th= is is to "draft-ietf-trill-rbridge-protocol-16.txt", which is in the RFC ed= itor's queue waiting on a normative reference to this document. It would be= less confusing to include the draft name. My understanding is that the RFC= editor will then replace this with the RFC when both are published togethe= r. --_000_DF7F294AF4153D498141CBEFADB177049AC8B6E657EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello,
I have been asked to p= rovide an additional Routing Directorate review for this draft. The Routing= Directorate seeks to review all routing or routing-related drafts as they = pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing A= Ds. For more information about the Routing Directorate, please see http://www.ietf.o= rg/iesg/directorate/routing.html
Although these comment= s are primarily for the use of the Routing ADs, it would be helpful if you = could consider them along with any other IETF Last Call comments that you r= eceive, and strive to resolve them through discussion or by updating the draft.
Document: draft-ietf-i= sis-layer2-09.txt
Reviewer: Ross Callon
Review Date: 2011-01-02
IETF LC End Date: 2010-12-14
Intended Status: proposed standard
Summary:
I have only very minor= concerns about this document. While these are of a nature that the RFC edi= tor staff might be expected to identify and fix, you may nonetheless want t= o resolve these before publication.
Comments:
The document is well w= ritten and structured, and generally conforms to the conventional definitio= n of IS-IS TLVs.
Major Issues:
No major issues found.=
Minor Issues:
 
Section 2.2, The bullet item “Type: TLV Type, set to MT-PORT-CAP= TLV 143 [TBD].”
 
My understanding is that the value 143 was incorrectly picked (and ove= rlaps with a different meaning of the same value). My understanding is also= that the “TBD” means that this was tentative. This will need t= o be corrected prior to publication, and you might want to add an RFC editor’s note to this effect (or at least ma= ke sure that you check this during auth-48).
 
 
Section 6.2, informative references. The third reference. I believe th= at this is to “draft-ietf-trill-rbridge-protocol-16.txt”, which= is in the RFC editor’s queue waiting on a normative reference to thi= s document. It would be less confusing to include the draft name. My understanding is that the RFC editor will then replace t= his with the RFC when both are published together.
 
 --_000_DF7F294AF4153D498141CBEFADB177049AC8B6E657EMBX01WFjnprn_-- From ayabaner@cisco.com Mon Jan 3 11:09:25 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 758EB3A6AE4 for ; Mon, 3 Jan 2011 11:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.135 X-Spam-Level: X-Spam-Status: No, score=-7.135 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfSodES77+gp for ; Mon, 3 Jan 2011 11:09:19 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 4A5693A6AE2 for ; Mon, 3 Jan 2011 11:09:19 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0HABauIU2rR7H+/2dsb2JhbACCKaEuXAJzowKZB4JyglgEhGWGH4MjhHQ X-IronPort-AV: E=Sophos;i="4.60,268,1291593600"; d="scan'208,217";a="309698283" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 03 Jan 2011 19:11:26 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p03JBQOv015114; Mon, 3 Jan 2011 19:11:26 GMT Received: from xmb-sjc-22b.amer.cisco.com ([128.107.191.112]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Jan 2011 11:11:26 -0800 Received: from 171.71.55.146 ([171.71.55.146]) by xmb-sjc-22b.amer.cisco.com ([128.107.191.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 3 Jan 2011 19:11:25 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Mon, 03 Jan 2011 11:11:25 -0800 From: Ayan Banerjee To: Ross Callon , "rtg-ads@tools.ietf.org" Message-ID: Thread-Topic: Review of draft-ietf-isis-layer2-09 Thread-Index: AcuqGEmc33rSojB0SmODdRqwfGAMNwAx5NEQACaJwQg= In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3376897885_288200" X-OriginalArrivalTime: 03 Jan 2011 19:11:26.0470 (UTC) FILETIME=[04C6FA60:01CBAB7A] X-Mailman-Approved-At: Mon, 03 Jan 2011 11:48:57 -0800 Cc: "rtg-dir@ietf.org" , "draft-ietf-isis-layer2.all@tools.ietf.org" Subject: Re: [RTG-DIR] Review of draft-ietf-isis-layer2-09 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 19:09:25 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3376897885_288200 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Ross, Thanks much for the comments. Regarding the minor issues: The MT-PORT-CAP-TLV with the suggested value is fine. The MAC-reachability TLV was in conflict and version =AD09 of this draft moved it to a non-conflicting value. Yes, this is accurate, the suggested reference is to =B3draft-ietf-trill-rbridge-protocol-16.txt=B2. I am hoping that we can fix thi= s up in the RFC editor queue. Thanks, Ayan On 1/2/11 4:53 PM, "Ross Callon" wrote: > Hello, > I have been asked to provide an additional Routing Directorate review for= this > draft. The Routing Directorate seeks to review all routing or routing-rel= ated > drafts as they pass through IETF last call and IESG review. The purpose o= f the > review is to provide assistance to the Routing ADs. For more information = about > the Routing Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, it = would > be helpful if you could consider them along with any other IETF Last Call > comments that you receive, and strive to resolve them through discussion = or by > updating the draft. > Document: draft-ietf-isis-layer2-09.txt > Reviewer: Ross Callon > Review Date: 2011-01-02 > IETF LC End Date: 2010-12-14 > Intended Status: proposed standard > Summary: > I have only very minor concerns about this document. While these are of a > nature that the RFC editor staff might be expected to identify and fix, y= ou > may nonetheless want to resolve these before publication. > Comments:=20 > The document is well written and structured, and generally conforms to th= e > conventional definition of IS-IS TLVs. > Major Issues: > No major issues found. > Minor Issues: > =20 > Section 2.2, The bullet item =B3Type: TLV Type, set to MT-PORT-CAP TLV 143 > [TBD].=B2 > =20 > My understanding is that the value 143 was incorrectly picked (and overla= ps > with a different meaning of the same value). My understanding is also tha= t the > =B3TBD=B2 means that this was tentative. This will need to be corrected prior= to > publication, and you might want to add an RFC editor=B9s note to this effec= t (or > at least make sure that you check this during auth-48). > =20 > =20 > Section 6.2, informative references. The third reference. I believe that = this > is to =B3draft-ietf-trill-rbridge-protocol-16.txt=B2, which is in the RFC edi= tor=B9s > queue waiting on a normative reference to this document. It would be less > confusing to include the draft name. My understanding is that the RFC edi= tor > will then replace this with the RFC when both are published together. > =20 >=20 --B_3376897885_288200 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: Review of draft-ietf-isis-layer2-09 Ross,

Thanks much for the comments. Regarding the minor issues:

The MT-PORT-CAP-TLV with the suggested value is fine. The MAC-reachability = TLV was in conflict and version –09 of this draft moved it to a non-co= nflicting value.

Yes, this is accurate, the suggested reference is to “draft-ietf-trill-rb= ridge-protocol-16.txt”. I am hoping that we can fix this up in the RFC= editor queue.

Thanks,
Ayan




On 1/2/11 4:53 PM, "Ross Callon" <rcallon@juniper.net> wrote:

Hello,
I have been asked to provide an additional Routing Directorate review fo= r this draft. The Routing Directorate seeks to review all routing or routing= -related drafts as they pass through IETF last call and IESG review. The pur= pose of the review is to provide assistance to the Routing ADs. For more inf= ormation about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/r= outing.html <http://www.ietf.org/iesg/directorate/routing.html>
Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Cal= l comments that you receive, and strive to resolve them through discussion o= r by updating the draft.
Document: draft-ietf-isis-layer2-09.txt
Reviewer: Ross Callon
Review Date: 2011-01-02
IETF LC End Date: 2010-12-14
Intended Status: proposed standard
Summary:
I have only very minor concerns about this document. While these are of= a nature that the RFC editor staff might be expected to identify and fix, y= ou may nonetheless want to resolve these before publication.
Comments:
The document is well written and structured, and generally conforms to = the conventional definition of IS-IS TLVs.
Major Issues:
No major issues found.
Minor Issues:
Section 2.2, The bullet item “Type: TLV Type, set to MT-PORT-CAP TLV = 143 [TBD].”
 
My understanding is that the value 143 was incorrectly picked (and overlaps= with a different meaning of the same value). My understanding is also that = the “TBD” means that this was tentative. This will need to be co= rrected prior to publication, and you might want to add an RFC editor’= s note to this effect (or at least make sure that you check this during auth= -48).
 
 
Section 6.2, informative references. The third reference. I believe that th= is is to “draft-ietf-trill-rbridge-protocol-16.txt”, which is in= the RFC editor’s queue waiting on a normative reference to this docum= ent. It would be less confusing to include the draft name. My understanding = is that the RFC editor will then replace this with the RFC when both are pub= lished together.
 

--B_3376897885_288200-- From matthew.bocci@alcatel-lucent.com Tue Jan 4 06:39:43 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80DEB3A6B67 for ; Tue, 4 Jan 2011 06:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.847 X-Spam-Level: X-Spam-Status: No, score=-105.847 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMVyEKATiCzh for ; Tue, 4 Jan 2011 06:39:42 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 211053A69ED for ; Tue, 4 Jan 2011 06:39:41 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p04EfRkM004441 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Jan 2011 15:41:46 +0100 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.38]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 4 Jan 2011 15:41:44 +0100 From: "Bocci, Matthew (Matthew)" To: Julien Meuric , "rtg-ads@tools.ietf.org" Date: Tue, 4 Jan 2011 15:41:41 +0100 Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-uni-nni-02 Thread-Index: AcusHYGXdIG/pYVaSCWPBGKr7vRGaQ== Message-ID: In-Reply-To: <4D12214F.5080302@orange-ftgroup.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-tp-uni-nni.all@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-uni-nni-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 14:39:43 -0000 Julien, Thank you very much for your review. Please see below for some responses. Best regards, Matthew On 22/12/2010 16:03, "Julien Meuric" wrote: >Hello, > >I have been selected as the Routing Directorate reviewer for this draft. >The Routing Directorate seeks to review all routing or routing-related >drafts as they pass through IETF last call and IESG review. The purpose >of the review is to provide assistance to the Routing ADs. For more >information about the Routing Directorate, please see >http://www.ietf.org/iesg/directorate/routing.html > >Although these comments are primarily for the use of the Routing ADs, it >would be helpful if you could consider them along with any other IETF >Last Call comments that you receive, and strive to resolve them through >discussion or by updating the draft. > >Document: draft-ietf-mpls-tp-uni-nni-02.txt >Reviewer: Julien Meuric >Review Date: 2010-12-22 >IETF LC End Date: 2010-12-23 >Intended Status: Informational > >*Summary:* >I have some minor concerns about this document that I think should be >resolved before publication. > >*Comments:* >This document focuses on a specific topic within a limited scope. >Nevertheless, it is a patch to RFC 5921 and thus requires reading some >parts of the latter (sections 3.4.2 and 3.4.3 mainly), which is >detrimental to its readability if considered alone. > >*Major Issues:* >No major issues found. > >*Minor Issues:* >- It is not obvious why P nodes are not mentioned when tackling the NNI. >It requires to look for an answer in RFC 5921, which lies in the last >paragraph of section 3.4.2. It may be worth considering introducing that >paragraph in this document (in section 1 for instance). I propose adding the following text (mostly copied from RFC5921) as a final paragraph in Section 1.1: "Awareness of the Transport Service layer need exist only at PE nodes, and so only these nodes are illustrate in the figures. MPLS-TP Provider (P) nodes need have no awareness of this layer. Both PE and P nodes participate in the Transport Path layer. A PE terminates (i.e., is an LER with respect to) the transport paths it supports, and is responsible for multiplexing and demultiplexing of Transport Service Instance traffic over such transport paths." >- Linked to the above, the exact scope of the document is defined a bit >late: the fact that UNI and NNI are "Transport Service Interfaces" is >not stated before section 1.1, while one would expect to be aware of >this information from the abstract and introduction. I propose to modify the first sentence of the abstract and Section 1 as follows: "The framework for MPLS in transport networks (RFC 5921) provides reference models for an MPLS Transport Profile (MPLS-TP) transport service interfaces, which are a User-to-Network Interface (UNI), and an MPLS-TP Network-to-Network Interface (NNI)." >- The phrase "Transport Service Instance" is only mentioned in section >3: defining it in section 1.2 may improve the readability; "TSI" is only >used in drawings: is it necessary to use the acronym, especially in this >context where the phrase "Transport Service Interface" is also used? TSI is expanded in the terminology section (1.2). It is not expanded in the figures because of the constraints of ASCII art. >- The term "attachment circuit" is mentioned in section 2, but it does >not appear on figures, nor is defined in the I-D. Definition and/or >illustration would be welcome. This text was added as a result of a last call comment and is copied from RFC5921. The term is a well known term that is used in RFC5921, as well as being extensively used in PWE3 and L2VPN, so I a not sure it needs to be defined again here. >- The acronyms UNI-C and UNI-N are used for the first time in section >1.1, without expansion/definition and before the terminology section. >They should either be removed from there, or be expanded/defined at >first use. I will add an expansion on first use, which I believe should actually be 'User-to-Network Interface, Client side' and 'User-to-Network Interface, Network side'. >- The acronym UNI-N is defined in section 1.2 but not actually expanded, >thus leading to wonder why "-N". I agree that "PE side" is more >meaningful than "network", but adding expansion while keeping definition >may be considered. I will add the expansion in the terminology and correct the expansion for UNI-C. >- Figure 1: it looks like "Native service control" is defined as native >service control and/or GMPLS, where I understand that GMPLS can be an >option even if not native. Would not it be clearer to write "Service >control" and keep current definition (native and/or GMPLS)? I think we have to be careful not to confuse the control plane of the client service for establishing and maintaining client connections across the UNI with the control plane of the transport service, which is why we use the term Native Service Control. So this may be either a control plane belonging to the client service, or it may be GMPLS since this can be used as an alternative in some instances. The term Native Service is in common usage as per RFC3985, but I appreciate that the usage here is a little unclear. How about: "Native service control =3D Control plane defined as belonging to the native service, and/or GMPLS" ? > >*Nits:* >Abstract >s/subjet/subject/ OK >----- >Section 1.2 >s/PE Side/PE side/ OK >----- >Section 2 & 3 >- either: > s/User-Network/User-to-Network/ in section 2 > + s/NNI is illustrated/Network-to-Network Interface (NNI) is >illustrated/ in section 3 >- or: s/User-Network Interface (UNI)/UNI/ in section 2 >----- > > >Regards and merry Christmas, > >Julien > From julien.meuric@orange-ftgroup.com Fri Jan 7 01:36:54 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 438D73A67F9 for ; Fri, 7 Jan 2011 01:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWDzcUzZj-ul for ; Fri, 7 Jan 2011 01:36:52 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 314473A67F6 for ; Fri, 7 Jan 2011 01:36:52 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8525FFC4010; Fri, 7 Jan 2011 10:39:01 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 77D0AFC4001; Fri, 7 Jan 2011 10:39:01 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Jan 2011 10:38:58 +0100 Received: from [87.127.0.0] ([10.42.12.26]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Jan 2011 10:38:57 +0100 Message-ID: <4D26DF31.6060708@orange-ftgroup.com> Date: Fri, 07 Jan 2011 10:38:57 +0100 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Bocci, Matthew (Matthew)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 07 Jan 2011 09:38:57.0700 (UTC) FILETIME=[B4F79E40:01CBAE4E] Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-tp-uni-nni.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-uni-nni-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 09:36:54 -0000 Hi Matthew (and happy new year everyone). See my answers in line. Cheers, Julien Le 04/01/2011 15:41, Bocci, Matthew (Matthew) a écrit : > Julien, > > Thank you very much for your review. > > Please see below for some responses. > > Best regards, > > Matthew > > > On 22/12/2010 16:03, "Julien Meuric" > wrote: > >> Hello, >> >> I have been selected as the Routing Directorate reviewer for this draft. >> The Routing Directorate seeks to review all routing or routing-related >> drafts as they pass through IETF last call and IESG review. The purpose >> of the review is to provide assistance to the Routing ADs. For more >> information about the Routing Directorate, please see >> http://www.ietf.org/iesg/directorate/routing.html >> >> Although these comments are primarily for the use of the Routing ADs, it >> would be helpful if you could consider them along with any other IETF >> Last Call comments that you receive, and strive to resolve them through >> discussion or by updating the draft. >> >> Document: draft-ietf-mpls-tp-uni-nni-02.txt >> Reviewer: Julien Meuric >> Review Date: 2010-12-22 >> IETF LC End Date: 2010-12-23 >> Intended Status: Informational >> >> *Summary:* >> I have some minor concerns about this document that I think should be >> resolved before publication. >> >> *Comments:* >> This document focuses on a specific topic within a limited scope. >> Nevertheless, it is a patch to RFC 5921 and thus requires reading some >> parts of the latter (sections 3.4.2 and 3.4.3 mainly), which is >> detrimental to its readability if considered alone. >> >> *Major Issues:* >> No major issues found. >> >> *Minor Issues:* >> - It is not obvious why P nodes are not mentioned when tackling the NNI. >> It requires to look for an answer in RFC 5921, which lies in the last >> paragraph of section 3.4.2. It may be worth considering introducing that >> paragraph in this document (in section 1 for instance). > I propose adding the following text (mostly copied from RFC5921) as a > final paragraph in Section 1.1: > > "Awareness of the Transport Service layer need exist only at PE nodes, and > so only these nodes are illustrate in the figures. > MPLS-TP Provider (P) nodes need have no awareness of this layer. > Both PE and P nodes participate in the Transport Path layer. A PE > terminates (i.e., is an LER with respect to) the transport paths it > supports, and is responsible for multiplexing and demultiplexing of > Transport Service Instance traffic over such transport paths." > [JM] OK >> - Linked to the above, the exact scope of the document is defined a bit >> late: the fact that UNI and NNI are "Transport Service Interfaces" is >> not stated before section 1.1, while one would expect to be aware of >> this information from the abstract and introduction. > I propose to modify the first sentence of the abstract and Section 1 as > follows: > "The framework for MPLS in transport networks (RFC 5921) provides > reference models for an MPLS Transport Profile (MPLS-TP) transport service > interfaces, which are a User-to-Network Interface (UNI), and an MPLS-TP > Network-to-Network Interface (NNI)." > [JM] OK >> - The phrase "Transport Service Instance" is only mentioned in section >> 3: defining it in section 1.2 may improve the readability; "TSI" is only >> used in drawings: is it necessary to use the acronym, especially in this >> context where the phrase "Transport Service Interface" is also used? > TSI is expanded in the terminology section (1.2). It is not expanded in > the figures because of the constraints of ASCII art. > [JM] It is expanded but not actually defined/explained; adding a sentence in the terminology section would be helpful. >> - The term "attachment circuit" is mentioned in section 2, but it does >> not appear on figures, nor is defined in the I-D. Definition and/or >> illustration would be welcome. > This text was added as a result of a last call comment and is copied from > RFC5921. The term is a well known term that is used in RFC5921, as well as > being extensively used in PWE3 and L2VPN, so I a not sure it needs to be > defined again here. > [JM] That is a typical example of the main shortcoming of this document. Anyway, it is up to you. >> - The acronyms UNI-C and UNI-N are used for the first time in section >> 1.1, without expansion/definition and before the terminology section. >> They should either be removed from there, or be expanded/defined at >> first use. > I will add an expansion on first use, which I believe should actually be > 'User-to-Network Interface, Client side' and 'User-to-Network Interface, > Network side'. > [JM] OK >> - The acronym UNI-N is defined in section 1.2 but not actually expanded, >> thus leading to wonder why "-N". I agree that "PE side" is more >> meaningful than "network", but adding expansion while keeping definition >> may be considered. > I will add the expansion in the terminology and correct the expansion for > UNI-C. > [JM] OK >> - Figure 1: it looks like "Native service control" is defined as native >> service control and/or GMPLS, where I understand that GMPLS can be an >> option even if not native. Would not it be clearer to write "Service >> control" and keep current definition (native and/or GMPLS)? > I think we have to be careful not to confuse the control plane of the > client service for establishing and maintaining client connections across > the UNI with the control plane of the transport service, which is why we > use the term Native Service Control. So this may be either a control plane > belonging to the client service, or it may be GMPLS since this can be used > as an alternative in some instances. The term Native Service is in common > usage as per RFC3985, but I appreciate that the usage here is a little > unclear. How about: "Native service control = Control plane defined as > belonging to the native service, and/or GMPLS" ? > [JM] Not sure about that one. I completely agree with the intent, my concern is about the "patch-like" wording because it feels like writing "x = x + y" [while y (GMPLS) is not zero]... "x + y" should remain, but I would feel more comfortable with a more generic phrase [than RFC 3985] for the "left x": if "service control" is excluded, how about something like "service layer control"? >> *Nits:* >> Abstract >> s/subjet/subject/ > OK > >> ----- >> Section 1.2 >> s/PE Side/PE side/ > OK > >> ----- >> Section 2& 3 >> - either: >> s/User-Network/User-to-Network/ in section 2 >> + s/NNI is illustrated/Network-to-Network Interface (NNI) is >> illustrated/ in section 3 >> - or: s/User-Network Interface (UNI)/UNI/ in section 2 >> ----- >> >> >> Regards and merry Christmas, >> >> Julien >> From matthew.bocci@alcatel-lucent.com Fri Jan 7 04:31:49 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F5753A683E for ; Fri, 7 Jan 2011 04:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.871 X-Spam-Level: X-Spam-Status: No, score=-105.871 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKv16llcMmaR for ; Fri, 7 Jan 2011 04:31:47 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 87B053A683A for ; Fri, 7 Jan 2011 04:31:47 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p07CXajV003058 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 7 Jan 2011 13:33:52 +0100 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.38]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 7 Jan 2011 13:33:52 +0100 From: "Bocci, Matthew (Matthew)" To: Julien Meuric Date: Fri, 7 Jan 2011 13:33:47 +0100 Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-uni-nni-02 Thread-Index: AcuuZyMAAmcHaC0iQ+qalWMpsSByHQ== Message-ID: In-Reply-To: <4D26DF31.6060708@orange-ftgroup.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-tp-uni-nni.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-uni-nni-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 12:31:49 -0000 Hi Julien, Happy New Year. Please see below. Thanks. Matthew On 07/01/2011 09:38, "Julien Meuric" wrote: >Hi Matthew (and happy new year everyone). > >See my answers in line. > >Cheers, > >Julien > > >Le 04/01/2011 15:41, Bocci, Matthew (Matthew) a =E9crit : >> Julien, >> >> Thank you very much for your review. >> >> Please see below for some responses. >> >> Best regards, >> >> Matthew >> >> >> On 22/12/2010 16:03, "Julien Meuric" >> wrote: >> >>> Hello, >>> >>> I have been selected as the Routing Directorate reviewer for this >>>draft. >>> The Routing Directorate seeks to review all routing or routing-related >>> drafts as they pass through IETF last call and IESG review. The purpose >>> of the review is to provide assistance to the Routing ADs. For more >>> information about the Routing Directorate, please see >>> http://www.ietf.org/iesg/directorate/routing.html >>> >>> Although these comments are primarily for the use of the Routing ADs, >>>it >>> would be helpful if you could consider them along with any other IETF >>> Last Call comments that you receive, and strive to resolve them through >>> discussion or by updating the draft. >>> >>> Document: draft-ietf-mpls-tp-uni-nni-02.txt >>> Reviewer: Julien Meuric >>> Review Date: 2010-12-22 >>> IETF LC End Date: 2010-12-23 >>> Intended Status: Informational >>> >>> *Summary:* >>> I have some minor concerns about this document that I think should be >>> resolved before publication. >>> >>> *Comments:* >>> This document focuses on a specific topic within a limited scope. >>> Nevertheless, it is a patch to RFC 5921 and thus requires reading some >>> parts of the latter (sections 3.4.2 and 3.4.3 mainly), which is >>> detrimental to its readability if considered alone. >>> >>> *Major Issues:* >>> No major issues found. >>> >>> *Minor Issues:* >>> - It is not obvious why P nodes are not mentioned when tackling the >>>NNI. >>> It requires to look for an answer in RFC 5921, which lies in the last >>> paragraph of section 3.4.2. It may be worth considering introducing >>>that >>> paragraph in this document (in section 1 for instance). >> I propose adding the following text (mostly copied from RFC5921) as a >> final paragraph in Section 1.1: >> >> "Awareness of the Transport Service layer need exist only at PE nodes, >>and >> so only these nodes are illustrate in the figures. >> MPLS-TP Provider (P) nodes need have no awareness of this layer. >> Both PE and P nodes participate in the Transport Path layer. A PE >> terminates (i.e., is an LER with respect to) the transport paths it >> supports, and is responsible for multiplexing and demultiplexing of >> Transport Service Instance traffic over such transport paths." >> >[JM] OK > >>> - Linked to the above, the exact scope of the document is defined a bit >>> late: the fact that UNI and NNI are "Transport Service Interfaces" is >>> not stated before section 1.1, while one would expect to be aware of >>> this information from the abstract and introduction. >> I propose to modify the first sentence of the abstract and Section 1 as >> follows: >> "The framework for MPLS in transport networks (RFC 5921) provides >> reference models for an MPLS Transport Profile (MPLS-TP) transport >>service >> interfaces, which are a User-to-Network Interface (UNI), and an MPLS-TP >> Network-to-Network Interface (NNI)." >> >[JM] OK > >>> - The phrase "Transport Service Instance" is only mentioned in section >>> 3: defining it in section 1.2 may improve the readability; "TSI" is >>>only >>> used in drawings: is it necessary to use the acronym, especially in >>>this >>> context where the phrase "Transport Service Interface" is also used? >> TSI is expanded in the terminology section (1.2). It is not expanded in >> the figures because of the constraints of ASCII art. >> >[JM] It is expanded but not actually defined/explained; adding a sentence >in the terminology section would be helpful. MB> It is defined in RFC5921, section 3.4.2. I propose to add the following modified snippet from that paragraph to the terminology section: "a single logical point-to-point connection at the Transport Service layer between the ingress PE providing a packet transport service to a CE, and the corresponding egress PE to which the peer CE is attached." =20 > >>> - The term "attachment circuit" is mentioned in section 2, but it does >>> not appear on figures, nor is defined in the I-D. Definition and/or >>> illustration would be welcome. >> This text was added as a result of a last call comment and is copied >>from >> RFC5921. The term is a well known term that is used in RFC5921, as well >>as >> being extensively used in PWE3 and L2VPN, so I a not sure it needs to be >> defined again here. >> >[JM] That is a typical example of the main shortcoming of this document. >Anyway, it is up to you. > >>> - The acronyms UNI-C and UNI-N are used for the first time in section >>> 1.1, without expansion/definition and before the terminology section. >>> They should either be removed from there, or be expanded/defined at >>> first use. >> I will add an expansion on first use, which I believe should actually be >> 'User-to-Network Interface, Client side' and 'User-to-Network Interface, >> Network side'. >> >[JM] OK > >>> - The acronym UNI-N is defined in section 1.2 but not actually >>>expanded, >>> thus leading to wonder why "-N". I agree that "PE side" is more >>> meaningful than "network", but adding expansion while keeping >>>definition >>> may be considered. >> I will add the expansion in the terminology and correct the expansion >>for >> UNI-C. >> >[JM] OK > >>> - Figure 1: it looks like "Native service control" is defined as native >>> service control and/or GMPLS, where I understand that GMPLS can be an >>> option even if not native. Would not it be clearer to write "Service >>> control" and keep current definition (native and/or GMPLS)? >> I think we have to be careful not to confuse the control plane of the >> client service for establishing and maintaining client connections >>across >> the UNI with the control plane of the transport service, which is why we >> use the term Native Service Control. So this may be either a control >>plane >> belonging to the client service, or it may be GMPLS since this can be >>used >> as an alternative in some instances. The term Native Service is in >>common >> usage as per RFC3985, but I appreciate that the usage here is a little >> unclear. How about: "Native service control =3D Control plane defined as >> belonging to the native service, and/or GMPLS" ? >> >[JM] Not sure about that one. I completely agree with the intent, my >concern is about the "patch-like" wording because it feels like writing >"x =3D x + y" [while y (GMPLS) is not zero]... "x + y" should remain, but = I >would feel more comfortable with a more generic phrase [than RFC 3985] >for the "left x": if "service control" is excluded, how about something >like "service layer control"? MB> Service Layer Control could be confused with transport Service layer control. Also, mentioning GMPLS was a specific request from the ITU-T here and they have already reviewed the document as a part of the joint MPLS-TP process, and this somewhat constrains us to only making changes that are really necessary. So, how about we delete the note from the figure, change the name in the figure to Client Service Control, and then add the following sentence to the text below the figure: "Note that the client service control plane may be a control protocol belonging to the native service, or GMPLS." > >>> *Nits:* >>> Abstract >>> s/subjet/subject/ >> OK >> >>> ----- >>> Section 1.2 >>> s/PE Side/PE side/ >> OK >> >>> ----- >>> Section 2& 3 >>> - either: >>> s/User-Network/User-to-Network/ in section 2 >>> + s/NNI is illustrated/Network-to-Network Interface (NNI) is >>> illustrated/ in section 3 >>> - or: s/User-Network Interface (UNI)/UNI/ in section 2 >>> ----- >>> >>> >>> Regards and merry Christmas, >>> >>> Julien >>> From julien.meuric@orange-ftgroup.com Fri Jan 7 06:04:28 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF6633A68C6 for ; Fri, 7 Jan 2011 06:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.189 X-Spam-Level: X-Spam-Status: No, score=-103.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpvh236VUDEZ for ; Fri, 7 Jan 2011 06:04:27 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 94EE93A68C2 for ; Fri, 7 Jan 2011 06:04:27 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 42FA08B801A; Fri, 7 Jan 2011 15:07:33 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 39BEA8B8019; Fri, 7 Jan 2011 15:07:33 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Jan 2011 15:06:33 +0100 Received: from [87.127.0.0] ([10.42.12.26]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Jan 2011 15:06:33 +0100 Message-ID: <4D271DE8.8090501@orange-ftgroup.com> Date: Fri, 07 Jan 2011 15:06:32 +0100 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Bocci, Matthew (Matthew)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 07 Jan 2011 14:06:33.0267 (UTC) FILETIME=[16D4B830:01CBAE74] Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-tp-uni-nni.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-uni-nni-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 14:04:28 -0000 Hi again Matthew. The definition you propose for TSI is fine with me. The phrase "Client service control" addresses my comment. I do not care if you use a note with "=" or a full sentence, but the one you suggest for the latter reads clear (to me at least). Enjoy the week-end, Julien Le 07/01/2011 13:33, Bocci, Matthew (Matthew) a écrit : > Hi Julien, > > Happy New Year. Please see below. > > Thanks. > Matthew > > > On 22/12/2010 16:03, "Julien Meuric" > wrote: >>>> - The phrase "Transport Service Instance" is only mentioned in section >>>> 3: defining it in section 1.2 may improve the readability; "TSI" is >>>> only >>>> used in drawings: is it necessary to use the acronym, especially in >>>> this >>>> context where the phrase "Transport Service Interface" is also used? >>> TSI is expanded in the terminology section (1.2). It is not expanded in >>> the figures because of the constraints of ASCII art. >>> >> [JM] It is expanded but not actually defined/explained; adding a sentence >> in the terminology section would be helpful. > MB> It is defined in RFC5921, section 3.4.2. I propose to add the > following modified snippet from that paragraph to the terminology section: > "a single logical point-to-point connection at the Transport Service layer > between the ingress PE providing a packet transport service to a CE, and > the corresponding egress PE to which the peer CE is attached." >>>> - Figure 1: it looks like "Native service control" is defined as native >>>> service control and/or GMPLS, where I understand that GMPLS can be an >>>> option even if not native. Would not it be clearer to write "Service >>>> control" and keep current definition (native and/or GMPLS)? >>> I think we have to be careful not to confuse the control plane of the >>> client service for establishing and maintaining client connections >>> across >>> the UNI with the control plane of the transport service, which is why we >>> use the term Native Service Control. So this may be either a control >>> plane >>> belonging to the client service, or it may be GMPLS since this can be >>> used >>> as an alternative in some instances. The term Native Service is in >>> common >>> usage as per RFC3985, but I appreciate that the usage here is a little >>> unclear. How about: "Native service control = Control plane defined as >>> belonging to the native service, and/or GMPLS" ? >>> >> [JM] Not sure about that one. I completely agree with the intent, my >> concern is about the "patch-like" wording because it feels like writing >> "x = x + y" [while y (GMPLS) is not zero]... "x + y" should remain, but I >> would feel more comfortable with a more generic phrase [than RFC 3985] >> for the "left x": if "service control" is excluded, how about something >> like "service layer control"? > MB> Service Layer Control could be confused with transport Service layer > control. Also, mentioning GMPLS was a specific request from the ITU-T here > and they have already reviewed the document as a part of the joint MPLS-TP > process, and this somewhat constrains us to only making changes that are > really necessary. So, how about we delete the note from the figure, change > the name in the figure to Client Service Control, and then add the > following sentence to the text below the figure: > "Note that the client service control plane may be a control protocol > belonging to the native service, or GMPLS." > > From russ@cisco.com Mon Jan 10 07:55:17 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E50E93A67ED for ; Mon, 10 Jan 2011 07:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.486 X-Spam-Level: X-Spam-Status: No, score=-10.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIEKbmEAuB9v for ; Mon, 10 Jan 2011 07:55:15 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B5E403A6973 for ; Mon, 10 Jan 2011 07:55:15 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQGAFe7Kk1AZnwN/2dsb2JhbACWMo4Pc6Mtl2aFTASEZ4YjgyA Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 10 Jan 2011 15:57:29 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0AFvT8G020316; Mon, 10 Jan 2011 15:57:29 GMT Message-ID: <4D2B2C74.2050504@cisco.com> Date: Mon, 10 Jan 2011 10:57:40 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: rtg-ads@tools.ietf.org X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC53E66628394F736AF52316F" Cc: rtg-dir@ietf.org, draft-ietf-roll-security-framework-03.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-roll-security-framework-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 15:55:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC53E66628394F736AF52316F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-roll-security-framework-03 Reviewer: Russ White Review Date: 10 Jan 2011 Intended Status: Informational Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: This draft is well written and very readable; I didn't find any spelling or editorial nits. Thanks for the hard work! There are some places I have questions, though I consider all of them minor, and therefore not blocks to the publication of an informational draft. =3D=3D 5.1.3 "The only means of fully countering a traffic analysis attack is through the use of tunneling (encapsulation) where encryption is applied across the entirety of the original packet source/destination addresses." Wouldn't injecting false information into the stream also counter this sort of attack? IE, the point here is to use traffic patterns to discover information by inference, or rather use metadata to infer data. Injecting information ignored by the system itself into the data stream is one traditional means used to obfuscate the metadata. OTOH, I don't know if this sort of defense is really acceptable in a low power/lossy network of the type described here. =3D=3D 4.1.1 & 4.1.2 It might be useful to explain what sort of damage could be done through routing exchange and routing information exposures... Is there a particular reason the topology is to be considered "secret?" IE, what's the security risk to someone knowing what the logical topology looks like= ? =3D=3D 5.2.2 The counter to overclaiming and misclaiming may employ: comparison with historical routing/topology data; designs which restrict realizable network topologies." I'm not certain how these two countermeasures would work within a dynamic routing environment. How can a new link (not historically available) coming up be differentiated from an overclaim? If you restrict the possible set of topologies to a subset of what is physically or logically possible, aren't you limiting the uses of the network over the long term? Won't an attacker know to stay within these bounds when forming the attack? =3D=3D Russ --------------enigC53E66628394F736AF52316F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0rLHcACgkQER27sUhU9OQIXwCdF+TpJhKYCIakWdrIHOS12kGU qqMAoMrwhHiwdF9tLT59x2AxwA1RDqov =ejOu -----END PGP SIGNATURE----- --------------enigC53E66628394F736AF52316F-- From danli@huawei.com Tue Jan 11 00:51:08 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACF503A6A1A for ; Tue, 11 Jan 2011 00:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.89 X-Spam-Level: X-Spam-Status: No, score=-3.89 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxwKqmyx6Ifj for ; Tue, 11 Jan 2011 00:51:06 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 653473A63EB for ; Tue, 11 Jan 2011 00:51:06 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEU00LISOOK5P@szxga03-in.huawei.com> for rtg-dir@ietf.org; Tue, 11 Jan 2011 16:53:08 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEU008I9OOKI1@szxga03-in.huawei.com> for rtg-dir@ietf.org; Tue, 11 Jan 2011 16:53:08 +0800 (CST) Received: from l00037133 ([10.70.77.125]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEU0081IOOK2Q@szxml04-in.huawei.com> for rtg-dir@ietf.org; Tue, 11 Jan 2011 16:53:08 +0800 (CST) Date: Tue, 11 Jan 2011 16:53:08 +0800 From: Dan Li To: Tomonori TAKEDA Message-id: <022d01cbb16c$f7d86750$7d4d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <201012311503.oBVF3oAA008419@imail2.m.ecl.ntt.co.jp> Cc: rtg-dir@ietf.org, draft-ietf-ccamp-gmpls-g-694-lambda-labels.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-ccamp-gmpls-g-694-lambda-labels-10.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 08:51:08 -0000 Hi all, We have updated this draft according to the comments received during the RtgDir review process. The major change is the description of Identifier in section 3.2 and 3.3. Others are minor editorial changes. The latest version (11) of this draft: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-lambda-labels-11.txt Thanks, Dan ----- Original Message ----- From: "Tomonori TAKEDA" To: Cc: ; ; Sent: Friday, December 31, 2010 11:03 PM Subject: Re: RtgDir review: draft-ietf-ccamp-gmpls-g-694-lambda-labels-10.txt > Hi Dan, > > Thanks for your reply. > > The proposed text is good for me. > > Tomonori > >> Hi Tomonori, >> >> Thanks for your comments! I would like to update the description of Identifier in section 3.2 and 3.3. >> >> OLD >> (3) Identifier: 9 bits >> >> The identifier field is a per-node assigned and scoped value. This >> field MAY change on a per-hop basis. In all cases but one, a node MAY >> select any value, including zero (0), for this field. Once selected, >> the value MUST NOT change until the LSP is torn down and the value >> MUST be used in all LSP related messages, e.g., in Resv messages and >> label RRO subobjects. The sole special case occurs when this label >> format is used in a label ERO subobject. In this case, the special >> value of zero (0) means that the referenced node MAY assign any >> Identifier field value, including zero (0), when establishing the >> corresponding LSP. >> NEW >> (3) Identifier: 9 bits >> >> The identifier field in lambda label format is used to distinguish different >> lasers (in one node) when they can transmit the same frequency lambda. >> The identifier field is a per-node assigned and scoped value. This >> field MAY change on a per-hop basis. In all cases but one, a node MAY >> select any value, including zero (0), for this field. Once selected, >> the value MUST NOT change until the LSP is torn down and the value >> MUST be used in all LSP related messages, e.g., in Resv messages and >> label RRO subobjects. The sole special case occurs when this label >> format is used in a label ERO subobject. In this case, the special >> value of zero (0) means that the referenced node MAY assign any >> Identifier field value, including zero (0), when establishing the >> corresponding LSP. When non-zero value is assigned to the identifier >> field in a label ERO subobject, the referenced node MUST use the >> assigned value for the identifier field in the corresponding LSP related >> messages. >> >> Is this ok? >> >> Thanks, >> >> Dan >> > From jmh@joelhalpern.com Thu Jan 13 15:43:25 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA5553A6C25 for ; Thu, 13 Jan 2011 15:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.609 X-Spam-Level: X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLdxB18eR9V4 for ; Thu, 13 Jan 2011 15:43:24 -0800 (PST) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id C67653A6C24 for ; Thu, 13 Jan 2011 15:43:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id D48D43245D5A; Thu, 13 Jan 2011 15:45:48 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-169.clppva.btas.verizon.net [71.161.51.169]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 15400322C23B; Thu, 13 Jan 2011 15:45:47 -0800 (PST) Message-ID: <4D2F8EAA.7060908@joelhalpern.com> Date: Thu, 13 Jan 2011 18:45:46 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: rtg-ads@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org, "rtg-dir@ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 23:43:25 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-mif-dhcpv6-route-option-00.txt Reviewer: Joel M. Halpern Review Date: 13-Jan-2011 IETF LC End Date: N/A Intended Status: Standards Track Summary: I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors. Comments: Major Issues: Given the existence of RFC 3442, I will not investigate the question of whether this is a sensible strategy for directing hosts. I do understand that there are good reasons for wanting to do this. However, it seems to me that there needs to be a discussion of how this will be made consistent with routing. A configured preference of this sort could easily cause a host to send messages into a long-lived temporary black hole, even when there is another path. Is there an expectation that this will somehow be synchronized with teh routing system? If so, how? If not, what are the consequences if things get de-synchronized. Minor Issues: I presume that the reason there is no discussion of size issues, as there is in RFC 3442, is due to some difference in DHCPv6 vs DHCPv4? It would seem that even if this is a non-issue, this document should say why it is a non-issue. (It seems likely that excessive use of this option by an administrator could cause difficulties.) Nits: The introduction begins with the phrasing "The Neighbor Discovery (ICMPv6) protocol". While ND rides on top of ICMPv6, it is not the same as ICMPv6. The parenthetical is misleading rather than helpful. Please remove it. In contrast, it would be helpful if the beginning of the next sentence, "Extensions to the protocol defined in [RFC4191]" actually included the words "Router Advertisement" in the text, since that is what protocol is referred to without being named. It would seem a good idea to include a reference to the current specification of DHCPv6 the first time it is mentioned. It would be clearer (not technically different, but clearer) if the first and second sentence in section 4 each indicated what message (presumably request and response respectively) is being used to carry this information. Even if obvious, it would also be good if the second sentence referred to whatever option holder the response message uses, in parallel with the construction of the first sentence. The text in section 4.1 as written makes it appear that routes are sent individually, rather than the description of the first part of section 4 or the actual description of the format of the OPTION_NEXT_HOP. (As written in 4.1, one is led to expect pairs of next-hops and routes, which is clearly not what you actually intend.) Yours, Joel M. Halpern From Adrian.Farrel@huawei.com Thu Jan 13 15:52:00 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A897D3A6C21 for ; Thu, 13 Jan 2011 15:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.546 X-Spam-Level: X-Spam-Status: No, score=-103.546 tagged_above=-999 required=5 tests=[AWL=-0.947, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57B+GDzfWv0U for ; Thu, 13 Jan 2011 15:51:59 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 9DCE63A6BC7 for ; Thu, 13 Jan 2011 15:51:59 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEZ00KTYJQN1B@usaga01-in.huawei.com> for rtg-dir@ietf.org; Thu, 13 Jan 2011 15:54:23 -0800 (PST) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEZ00MF1JQL25@usaga01-in.huawei.com> for rtg-dir@ietf.org; Thu, 13 Jan 2011 15:54:23 -0800 (PST) Date: Thu, 13 Jan 2011 23:54:20 +0000 From: Adrian Farrel In-reply-to: <4D2F8EAA.7060908@joelhalpern.com> To: rtg-ads@tools.ietf.org Message-id: <059a01cbb37d$33bbf130$9b33d390$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: AQKzeNGgyTvUlNrC6NMrNhCvH+xYUpIAB/Qw References: <4D2F8EAA.7060908@joelhalpern.com> Cc: draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org, rtg-dir@ietf.org, "'Joel M. Halpern'" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 23:52:00 -0000 Hi, Of course, the I-D is not in WG last call and has, in fact, only just been adopted by the WG, but I asked for an early Routing Directorate review because the Abstract of the I-D worried me. Can we (authors, WG chairs, ADs, and Routing Directorate) have a discussion about the question Joel asks, and see whether this idea constitutes "dynamic configuration of static routes on a host" or something more scary? Many thanks, Adrian > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: 13 January 2011 23:46 > To: rtg-ads@tools.ietf.org > Cc: rtg-dir@ietf.org; draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org > Subject: RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review. The purpose > of the review is to provide assistance to the Routing ADs. For more > information about the Routing Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-mif-dhcpv6-route-option-00.txt > Reviewer: Joel M. Halpern > Review Date: 13-Jan-2011 > IETF LC End Date: N/A > Intended Status: Standards Track > > Summary: I have significant concerns about this document and recommend > that the Routing ADs discuss these issues further with the authors. > > Comments: > > Major Issues: > Given the existence of RFC 3442, I will not investigate the > question of whether this is a sensible strategy for directing hosts. I > do understand that there are good reasons for wanting to do this. > However, it seems to me that there needs to be a discussion of how this > will be made consistent with routing. A configured preference of this > sort could easily cause a host to send messages into a long-lived > temporary black hole, even when there is another path. Is there an > expectation that this will somehow be synchronized with teh routing > system? If so, how? If not, what are the consequences if things get > de-synchronized. > > Minor Issues: > I presume that the reason there is no discussion of size issues, as > there is in RFC 3442, is due to some difference in DHCPv6 vs DHCPv4? It > would seem that even if this is a non-issue, this document should say > why it is a non-issue. (It seems likely that excessive use of this > option by an administrator could cause difficulties.) > > Nits: > The introduction begins with the phrasing "The Neighbor Discovery > (ICMPv6) protocol". While ND rides on top of ICMPv6, it is not the same > as ICMPv6. The parenthetical is misleading rather than helpful. Please > remove it. > In contrast, it would be helpful if the beginning of the next > sentence, "Extensions to the protocol defined in [RFC4191]" actually > included the words "Router Advertisement" in the text, since that is > what protocol is referred to without being named. > > It would seem a good idea to include a reference to the current > specification of DHCPv6 the first time it is mentioned. > > It would be clearer (not technically different, but clearer) if the > first and second sentence in section 4 each indicated what message > (presumably request and response respectively) is being used to carry > this information. Even if obvious, it would also be good if the second > sentence referred to whatever option holder the response message uses, > in parallel with the construction of the first sentence. > > The text in section 4.1 as written makes it appear that routes are > sent individually, rather than the description of the first part of > section 4 or the actual description of the format of the > OPTION_NEXT_HOP. (As written in 4.1, one is led to expect pairs of > next-hops and routes, which is clearly not what you actually intend.) > > Yours, > Joel M. Halpern From leeyoung@huawei.com Fri Jan 14 13:29:20 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E3DB3A6C8D for ; Fri, 14 Jan 2011 13:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhijDlmUDwtU for ; Fri, 14 Jan 2011 13:29:15 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id D7CB83A6BD0 for ; Fri, 14 Jan 2011 13:29:14 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LF1003IU7SR4K@usaga04-in.huawei.com> for rtg-dir@ietf.org; Fri, 14 Jan 2011 15:31:40 -0600 (CST) Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LF100GBI7SRSC@usaga04-in.huawei.com> for rtg-dir@ietf.org; Fri, 14 Jan 2011 15:31:39 -0600 (CST) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.218.12; Fri, 14 Jan 2011 13:31:38 -0800 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0218.012; Fri, 14 Jan 2011 13:31:38 -0800 Date: Fri, 14 Jan 2011 21:31:37 +0000 From: Leeyoung X-Originating-IP: [10.124.12.79] To: "rtg-ads@tools.ietf.org" Message-id: <7AEB3D6833318045B4AE71C2C87E8E1736AC87@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Wv7Tul16/FAsdrgNPI7Yzg)" Content-language: en-US Accept-Language: en-US Thread-topic: RtgDir review: draft-ietf-pmol-metrics-framework-07.txt Thread-index: Acu0Mm5r6oWnvy6UTgyPWVxevjywtg== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Mailman-Approved-At: Fri, 14 Jan 2011 14:06:36 -0800 Cc: "rtg-dir@ietf.org" , "draft-ietf-pmol-metrics-framework.all@tools.ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-pmol-metrics-framework-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 21:29:20 -0000 --Boundary_(ID_Wv7Tul16/FAsdrgNPI7Yzg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-pmol-metrics-framework-07.txt Reviewer: Young Lee Review Date: 14 January 2011 Intended Status: BCP Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: Overall, this document is clearly written and easy to understand. Major Issues: No major issues found. Minor Issues: Section 1.1 It would be helpful for readers if you include some references for the statement: "The IETF is also actively involved....." Section 1.1 It is not clear what "refers to" means in the paragraph that begins with "This document refers to a ....." Isn't Performance Metrics Entity what this document tries to implement? Section 6.6 The statement "the Performance Metrics Entity be implemented" could be more specific. It will be good to summarize the scope of implementation. It was clear to me which parts to be implemented as part of Performance Metrics Entity from the document. Nits: Section 1 s/comparison/comparison. Section 1 s/restricted/limited ("limited" may be a better choice of word than "restricted") Globally Either capitalize "performance metric" or use lower-case consistently throughout the document Globally Be consistent with the usage of double quotes around the title of RFC's your are referencing to. In some places, you used double quotes (E.g., "Guideline for ..." RFC 5706) and in other places you did not use double quotes (E.g., RFC 4710, 3611). --Boundary_(ID_Wv7Tul16/FAsdrgNPI7Yzg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hello,

I have been selected as the Routing Directorate reviewer for this draft.= The Routing Directorate seeks to review all routing or routing-related dra= fts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the= Routing ADs. For more information about the Routing Directorate, please se= e http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it= would be helpful if you could consider them along with any other IETF Last= Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-pmol-metrics-framework-07.txt
Reviewer: Young Lee
Review Date: 14 January 2011
Intended Status: BCP

Summary:
I have some minor concerns about this document that I think should be resol= ved before publication.

Comments:
Overall, this document is clearly written and easy to understand.

Major Issues:
No major issues found.

Minor Issues:
Section 1.1

It would be helpful for reade= rs if you include some references for the statement: “The IETF is als= o actively involved…..”

 

Section 1.1=

It is not clear what “r= efers to” means in the paragraph that begins with “This documen= t refers to a …..” Isn’t Performance Metrics Entity what = this document tries to implement?  

 

Section 6.6=

The statement “the Perf= ormance Metrics Entity be implemented” could be more specific. It wil= l be good to summarize the scope of implementation. It was clear to me which parts to be implemented as part of Performance Me= trics Entity from the document.  

Nits:
Section 1
s/comparison/comparison.

Section 1

s/restricted/limited (“= limited” may be a better choice of word than “restricted”= )

 

Globally

Either capitalize “performance metric” or use lower-case consistently throughout the document =

 

Globally

Be consistent with the usage = of double quotes around the title of RFC’s your are referencing to. I= n some places, you used double quotes (E.g., “Guideline for …” RFC 5706)  and in other places you did not use dou= ble quotes (E.g., RFC 4710, 3611).

 

 

--Boundary_(ID_Wv7Tul16/FAsdrgNPI7Yzg)-- From hadi@mojatatu.com Mon Jan 17 05:55:29 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C26C28C0D7 for ; Mon, 17 Jan 2011 05:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.989 X-Spam-Level: X-Spam-Status: No, score=-101.989 tagged_above=-999 required=5 tests=[AWL=0.988, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdQpbsUkSjEO for ; Mon, 17 Jan 2011 05:55:26 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 0030428C10A for ; Mon, 17 Jan 2011 05:55:24 -0800 (PST) Received: by qwi2 with SMTP id 2so5004366qwi.31 for ; Mon, 17 Jan 2011 05:57:58 -0800 (PST) Received: by 10.224.54.134 with SMTP id q6mr3861201qag.278.1295272678526; Mon, 17 Jan 2011 05:57:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.179.202 with HTTP; Mon, 17 Jan 2011 05:57:37 -0800 (PST) From: Jamal Hadi Salim Date: Mon, 17 Jan 2011 08:57:37 -0500 Message-ID: To: stig@cisco.com, rtg-ads@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: rtg-dir@ietf.org, draft-ietf-pim-registry.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-pim-registry-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 13:55:29 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-pim-registry-03 Reviewer: Jamal Hadi Salim Review Date: 2011-01-17 IETF LC End Date: 2011-01-20 Intended Status: proposed standard Summary: I have some very minor concerns about this document that may need to be cleared before publication. Comments: The document is well written and structured to request IANA for the creation of a registry for PIM message types. The initial content specified on this document is based on existing RFCs. The document goes on to specify how new PIM message types should be allocated. Major Issues: No major issues found. Minor Issues: Although section 3.2 describes how the new types should be allocated, given that this document is the first time all allocated PIM message types are aggregated, it would be useful to also list the unassigned message types and summarize what 3.2 says. i.e. Type Name Reference ---- ---------------------------------------- --------------------- 0 Hello [RFC3973] [RFC4601] 1 Register [RFC4601] 2 Register Stop [RFC4601] 3 Join/Prune [RFC3973] [RFC4601] 4 Bootstrap [RFC4601] 5 Assert [RFC3973] [RFC4601] 6 Graft [RFC3973] 7 Graft-Ack [RFC3973] 8 Candidate RP Advertisement [RFC4601] 9 State Refresh [RFC3973] 10 DF Election [RFC5015] 11-14 Unassigned at the moment Future IETF Review 15 Reserved (for extension of type space) [this document] Nits: There is an interesting nit in that you have RFC 3973 as a normative reference (which sounds deserving in the context of this document) but that RFC is an experimental RFC. cheers, jamal From bclaise@cisco.com Mon Jan 17 14:54:25 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 217F33A6F74 for ; Mon, 17 Jan 2011 14:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41Fm7s9fo3es for ; Mon, 17 Jan 2011 14:54:19 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id A42423A6D87 for ; Mon, 17 Jan 2011 14:54:18 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0HMumZI022383; Mon, 17 Jan 2011 23:56:48 +0100 (CET) Received: from [10.55.86.153] (dhcp-10-55-86-153.cisco.com [10.55.86.153]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p0HMudk2007531; Mon, 17 Jan 2011 23:56:41 +0100 (CET) Message-ID: <4D34C927.8050406@cisco.com> Date: Mon, 17 Jan 2011 23:56:39 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Leeyoung References: <7AEB3D6833318045B4AE71C2C87E8E1736AC87@DFWEML501-MBX.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1736AC87@DFWEML501-MBX.china.huawei.com> Content-Type: multipart/alternative; boundary="------------030308040203030500000507" X-Mailman-Approved-At: Mon, 17 Jan 2011 15:11:01 -0800 Cc: me , "rtg-dir@ietf.org" , "draft-ietf-pmol-metrics-framework.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pmol-metrics-framework-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 22:54:25 -0000 This is a multi-part message in MIME format. --------------030308040203030500000507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Lee, Thanks for your review. > > Hello, > > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG > review. The purpose of the review is to provide assistance to the > Routing ADs. For more information about the Routing Directorate, > please see http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, > it would be helpful if you could consider them along with any other > IETF Last Call comments that you receive, and strive to resolve them > through discussion or by updating the draft. > > Document: draft-ietf-pmol-metrics-framework-07.txt > Reviewer: Young Lee > Review Date: 14 January 2011 > Intended Status: BCP > > **Summary:** > I have some minor concerns about this document that I think should be > resolved before publication. > > **Comments:** > Overall, this document is clearly written and easy to understand. > > **Major Issues:** > No major issues found. > > **Minor Issues:** > Section 1.1 > > It would be helpful for readers if you include some references for the > statement: "The IETF is also actively involved....." > Added the reference to TCP [RFC793] and SCTP [RFC4960] > > Section 1.1 > > It is not clear what "refers to" means in the paragraph that begins > with "This document refers to a ....." Isn't Performance Metrics > Entity what this document tries to implement? > Yes. Would the following solve your issue? OLD: This document refers to a Performance Metrics Entity, whose goal is to advice and support the Performance Metric development at the IETF. A recommendation about the Performance Metrics Entity is made in Section 6.6. NEW: This document refers to the implementation of a Performance Metrics Entity, whose goal is to advice and support the Performance Metric development at the IETF. A recommendation about the Performance Metrics Entity is made in Section 6.6. > Section 6.6 > > The statement "the Performance Metrics Entity be implemented" could be > more specific. It will be good to summarize the scope of > implementation. It was clear to me which parts to be implemented as > part of Performance Metrics Entity from the document. > What about "the Performance Metrics Entity be implemented (_according to this memo)"?_ > > **Nits:** > Section 1 > s/comparison/comparison. > Done. > > Section 1 > > s/restricted/limited ("limited" may be a better choice of word than > "restricted") > Done. > > Globally > > Either capitalize "performance metric" or use lower-case consistently > throughout the document > Capitalized, as this is specified in the terminology. Good catch. > > Globally > > Be consistent with the usage of double quotes around the title of > RFC's your are referencing to. In some places, you used double quotes > (E.g., "Guideline for ..." RFC 5706) and in other places you did not > use double quotes (E.g., RFC 4710, 3611). > Done. I keep a temp version with all the changes. --------------030308040203030500000507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Lee,

Thanks for your review.

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-pmol-metrics-framework-07.txt
Reviewer: Young Lee
Review Date: 14 January 2011
Intended Status: BCP

Summary:
I have some minor concerns about this document that I think should be resolved before publication.

Comments:
Overall, this document is clearly written and easy to understand.

Major Issues:
No major issues found.

Minor Issues:
Section 1.1

It would be helpful for readers if you include some references for the statement: “The IETF is also actively involved…..”

Added the reference to TCP [RFC793] and SCTP [RFC4960]

 

Section 1.1

It is not clear what “refers to” means in the paragraph that begins with “This document refers to a …..” Isn’t Performance Metrics Entity what this document tries to implement? 

Yes.
Would the following solve your issue?
OLD:
                         This document refers to a Performance Metrics Entity, whose goal is
                         to advice and support the Performance Metric development at the IETF.
                         A recommendation about the Performance Metrics Entity is made
                         in Section 6.6.

NEW:
                        This document refers to the implementation of a Performance Metrics Entity, whose goal is
                         to advice and support the Performance Metric development at the IETF.
                         A recommendation about the Performance Metrics Entity is made
                         in Section 6.6.


 

Section 6.6

The statement “the Performance Metrics Entity be implemented” could be more specific. It will be good to summarize the scope of implementation. It was clear to me which parts to be implemented as part of Performance Metrics Entity from the document. 

What about "the Performance Metrics Entity be implemented (according to this memo)"?

Nits:
Section 1
s/comparison/comparison.

Done.

Section 1

s/restricted/limited (“limited” may be a better choice of word than “restricted”)

Done.

 

Globally

Either capitalize “performance metric” or use lower-case consistently throughout the document

Capitalized, as this is specified in the terminology. Good catch.

 

Globally

Be consistent with the usage of double quotes around the title of RFC’s your are referencing to. In some places, you used double quotes (E.g., “Guideline for …” RFC 5706)  and in other places you did not use double quotes (E.g., RFC 4710, 3611).

 

 

Done.

I keep a temp version with all the changes.

--------------030308040203030500000507-- From Adrian.Farrel@huawei.com Tue Jan 18 10:07:48 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C91203A7055 for ; Tue, 18 Jan 2011 10:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.57 X-Spam-Level: X-Spam-Status: No, score=-105.57 tagged_above=-999 required=5 tests=[AWL=1.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tdSj6j-9eZL for ; Tue, 18 Jan 2011 10:07:42 -0800 (PST) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 4EF183A6F0B for ; Tue, 18 Jan 2011 10:07:42 -0800 (PST) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LF8004DID57T6@usaga03-in.huawei.com> for rtg-dir@ietf.org; Tue, 18 Jan 2011 12:10:19 -0600 (CST) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LF800FPRD55WE@usaga03-in.huawei.com> for rtg-dir@ietf.org; Tue, 18 Jan 2011 12:10:19 -0600 (CST) Date: Tue, 18 Jan 2011 18:10:17 +0000 From: Adrian Farrel In-reply-to: <4D35D59A.9090306@cisco.com> To: 'Stig Venaas' , 'Jamal Hadi Salim' Message-id: <04eb01cbb73a$f7476ab0$e5d64010$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: AQIr3P34bejrPkJc0V3vVUaSb3pQWgHlSRxXkweQruA= References: <4D35D59A.9090306@cisco.com> Cc: rtg-dir@ietf.org, draft-ietf-pim-registry.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pim-registry-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 18:07:48 -0000 Hi, A Normative reference is one that must be read to understand the document in hand. A reference used to say "this code point was created in the referenced document" does not require the referenced document to be read. That would make it Informational. A > -----Original Message----- > From: Stig Venaas [mailto:svenaas@cisco.com] > Sent: 18 January 2011 18:02 > To: Jamal Hadi Salim > Cc: rtg-ads@tools.ietf.org; rtg-dir@ietf.org; draft-ietf-pim- > registry.all@tools.ietf.org > Subject: Re: RtgDir review: draft-ietf-pim-registry-03 > > On 1/17/2011 5:57 AM, Jamal Hadi Salim wrote: > > Hello, > > > > I have been selected as the Routing Directorate reviewer for this draft. > > The Routing Directorate seeks to review all routing or routing-related > > drafts as they pass through IETF last call and IESG review. The purpose > > of the review is to provide assistance to the Routing ADs. For more > > information about the Routing Directorate, please see > > http://www.ietf.org/iesg/directorate/routing.html > > Thanks, I agree with your comments. Just one question. > > [...] > > Nits: > > > > There is an interesting nit in that you have RFC 3973 as a normative > > reference (which sounds deserving in the context of this document) > > but that RFC is an experimental RFC. > > I'm not sure whether it is important, but I am wondering what is the > right solution here. Is it OK to have a normative reference, or should > it be an informative reference? > > I'm sure it must be common that registries are created and need to > reference e.g. experimental RFCs. In some cases the registry reference > is not even an RFC. Perhaps it then makes more sense to list them as > informative references? > > Stig > > > > > cheers, > > jamal From svenaas@cisco.com Tue Jan 18 09:59:26 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5DDF3A6FE2 for ; Tue, 18 Jan 2011 09:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id demkkV-PkoPc for ; Tue, 18 Jan 2011 09:59:25 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id E62F03A6F6C for ; Tue, 18 Jan 2011 09:59:25 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACpkNU2rR7Ht/2dsb2JhbACkVHOoOpoFhVAEhG+GL4Mk Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 18 Jan 2011 18:02:03 +0000 Received: from [10.33.12.88] ([10.33.12.88]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0II23tc000163; Tue, 18 Jan 2011 18:02:03 GMT Message-ID: <4D35D59A.9090306@cisco.com> Date: Tue, 18 Jan 2011 10:02:02 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jamal Hadi Salim References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 18 Jan 2011 10:09:21 -0800 Cc: rtg-dir@ietf.org, draft-ietf-pim-registry.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pim-registry-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 18:02:17 -0000 On 1/17/2011 5:57 AM, Jamal Hadi Salim wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review. The purpose > of the review is to provide assistance to the Routing ADs. For more > information about the Routing Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html Thanks, I agree with your comments. Just one question. [...] > Nits: > > There is an interesting nit in that you have RFC 3973 as a normative > reference (which sounds deserving in the context of this document) > but that RFC is an experimental RFC. I'm not sure whether it is important, but I am wondering what is the right solution here. Is it OK to have a normative reference, or should it be an informative reference? I'm sure it must be common that registries are created and need to reference e.g. experimental RFCs. In some cases the registry reference is not even an RFC. Perhaps it then makes more sense to list them as informative references? Stig > > cheers, > jamal From leeyoung@huawei.com Tue Jan 18 12:03:03 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19E013A7014 for ; Tue, 18 Jan 2011 12:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.094 X-Spam-Level: X-Spam-Status: No, score=-6.094 tagged_above=-999 required=5 tests=[AWL=-0.380, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWsl7ynoFTij for ; Tue, 18 Jan 2011 12:02:56 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 734E43A6E5D for ; Tue, 18 Jan 2011 12:02:56 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LF800B7AIH9X3@usaga02-in.huawei.com> for rtg-dir@ietf.org; Tue, 18 Jan 2011 12:05:34 -0800 (PST) Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LF800C2MIH821@usaga02-in.huawei.com> for rtg-dir@ietf.org; Tue, 18 Jan 2011 12:05:33 -0800 (PST) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 18 Jan 2011 12:05:28 -0800 Received: from DFWEML502-MBX.china.huawei.com ([fe80::1086:4a1f:19fa:9025]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Tue, 18 Jan 2011 12:05:32 -0800 Date: Tue, 18 Jan 2011 20:05:31 +0000 From: Leeyoung In-reply-to: <4D34C927.8050406@cisco.com> X-Originating-IP: [10.124.12.79] To: Benoit Claise Message-id: <7AEB3D6833318045B4AE71C2C87E8E1736DF2B@dfweml502-mbx.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_m+l2Zaq7zFH9YwsQKsMeIg)" Content-language: en-US Accept-Language: en-US Thread-topic: RtgDir review: draft-ietf-pmol-metrics-framework-07.txt Thread-index: Acu0Mm5r6oWnvy6UTgyPWVxevjywtgCqmxiAABt1lCA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <7AEB3D6833318045B4AE71C2C87E8E1736AC87@DFWEML501-MBX.china.huawei.com> <4D34C927.8050406@cisco.com> Cc: "rtg-dir@ietf.org" , "draft-ietf-pmol-metrics-framework.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pmol-metrics-framework-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 20:03:03 -0000 --Boundary_(ID_m+l2Zaq7zFH9YwsQKsMeIg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Benoit, Thanks. I am fine with your suggested changes. No more issues are pending. Regards, Young ________________________________ From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Monday, January 17, 2011 4:57 PM To: Leeyoung Cc: rtg-ads@tools.ietf.org; rtg-dir@ietf.org; draft-ietf-pmol-metrics-framework.all@tools.ietf.org; me Subject: Re: RtgDir review: draft-ietf-pmol-metrics-framework-07.txt Hi Lee, Thanks for your review. Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-pmol-metrics-framework-07.txt Reviewer: Young Lee Review Date: 14 January 2011 Intended Status: BCP Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: Overall, this document is clearly written and easy to understand. Major Issues: No major issues found. Minor Issues: Section 1.1 It would be helpful for readers if you include some references for the statement: "The IETF is also actively involved....." Added the reference to TCP [RFC793] and SCTP [RFC4960] Section 1.1 It is not clear what "refers to" means in the paragraph that begins with "This document refers to a ....." Isn't Performance Metrics Entity what this document tries to implement? Yes. Would the following solve your issue? OLD: This document refers to a Performance Metrics Entity, whose goal is to advice and support the Performance Metric development at the IETF. A recommendation about the Performance Metrics Entity is made in Section 6.6. NEW: This document refers to the implementation of a Performance Metrics Entity, whose goal is to advice and support the Performance Metric development at the IETF. A recommendation about the Performance Metrics Entity is made in Section 6.6. Section 6.6 The statement "the Performance Metrics Entity be implemented" could be more specific. It will be good to summarize the scope of implementation. It was clear to me which parts to be implemented as part of Performance Metrics Entity from the document. What about "the Performance Metrics Entity be implemented (according to this memo)"? Nits: Section 1 s/comparison/comparison. Done. Section 1 s/restricted/limited ("limited" may be a better choice of word than "restricted") Done. Globally Either capitalize "performance metric" or use lower-case consistently throughout the document Capitalized, as this is specified in the terminology. Good catch. Globally Be consistent with the usage of double quotes around the title of RFC's your are referencing to. In some places, you used double quotes (E.g., "Guideline for ..." RFC 5706) and in other places you did not use double quotes (E.g., RFC 4710, 3611). Done. I keep a temp version with all the changes. --Boundary_(ID_m+l2Zaq7zFH9YwsQKsMeIg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi Benoit,

 

Thanks. I am fine with your suggested = changes. No more issues are pending.

 

Regards,

Young

 

= From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Monday, January 17, 20= 11 4:57 PM
To: Leeyoung
Cc: rtg-ads@tools.ietf.org; rtg-dir@ietf.org; draft-ietf-pmol-metrics-framework.all@tools.ietf.org; me Subject: Re: RtgDir review: = draft-ietf-pmol-metrics-framework-07.txt

 

Hi Lee,

Thanks for your review.

Hello,

I have been selected as the Routing Directorate reviewer= for this draft. The Routing Directorate seeks to review all routing or rou= ting-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide as= sistance to the Routing ADs. For more information about the Routing Directo= rate, please see http://www.ie= tf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the= Routing ADs, it would be helpful if you could consider them along with any= other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the = draft.

Document: draft-ietf-pmol-metrics-framework-07.txt
Reviewer: Young Lee
Review Date: 14 January 2011
Intended Status: BCP

Summary:
I have some minor concerns about this document that I think should be resol= ved before publication.

Comments:
Overall, this document is clearly written and easy to understand.

Major Issues:
No major issues found.

Mi= nor Issues:
Section 1.1

It would be h= elpful for readers if you include some references for the statement: “The IETF is also actively involved…..” <= /span>

Added the reference to TCP [RFC793] = and SCTP [RFC4960]

=  

Section 1.1

It is not cle= ar what “refers to” means in the paragraph that begins with “This document refers to a …..” Isn’t Perform= ance Metrics Entity what this document tries to implement? 

Yes.
Would the following solve your issue?
OLD:
            &nb= sp;            This = document refers to a Performance Metrics Entity, whose goal is
            &nb= sp;            to ad= vice and support the Performance Metric development at the IETF.
            &nb= sp;            A rec= ommendation about the Performance Metrics Entity is made
            &nb= sp;            in Se= ction 6.6.

NEW:
                    =    This document refers to the implementation of a Performance M= etrics Entity, whose goal is
            &nb= sp;            to ad= vice and support the Performance Metric development at the IETF.
            &nb= sp;            A rec= ommendation about the Performance Metrics Entity is made
            &nb= sp;            in Se= ction 6.6.



=  

Section 6.6

The statement= “the Performance Metrics Entity be implemented” could be more specific. It will be good to summarize the scope of implementation= . It was clear to me which parts to be implemented as part of Performance M= etrics Entity from the document. 

What about "the Performance Met= rics Entity be implemented (according to this memo)"?

Nits:<= /b>
Section 1
s/comparison/comparison.

Done.

= Section 1

s/restricted/= limited (“limited” may be a better choice of word than “restricted”)

Done.

=  

Globally

Either capita= lize “pe= rformance metric” or use lower-case consistently throughout the document =

Capitalized, as this is specified in= the terminology. Good catch.

=  

Globally

Be consistent= with the usage of double quotes around the title of RFC’s your are referencing to. In some places, you used double quote= s (E.g., “Guideline for …” RFC 5706)  and in other p= laces you did not use double quotes (E.g., RFC 4710, 3611).

 <= /u5:p>

 <= /u5:p>

Done.=

I keep a temp version with all the changes.

--Boundary_(ID_m+l2Zaq7zFH9YwsQKsMeIg)-- From hadi@mojatatu.com Wed Jan 19 07:59:44 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 401D73A701A for ; Wed, 19 Jan 2011 07:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.038 X-Spam-Level: X-Spam-Status: No, score=-102.038 tagged_above=-999 required=5 tests=[AWL=0.938, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAmqnsNx4h8n for ; Wed, 19 Jan 2011 07:59:43 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 53A4B3A7015 for ; Wed, 19 Jan 2011 07:59:43 -0800 (PST) Received: by qyk34 with SMTP id 34so763474qyk.10 for ; Wed, 19 Jan 2011 08:02:23 -0800 (PST) Received: by 10.224.215.135 with SMTP id he7mr771597qab.378.1295452943335; Wed, 19 Jan 2011 08:02:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.179.202 with HTTP; Wed, 19 Jan 2011 08:02:03 -0800 (PST) In-Reply-To: <04eb01cbb73a$f7476ab0$e5d64010$@huawei.com> References: <4D35D59A.9090306@cisco.com> <04eb01cbb73a$f7476ab0$e5d64010$@huawei.com> From: Jamal Hadi Salim Date: Wed, 19 Jan 2011 11:02:03 -0500 Message-ID: To: Adrian.Farrel@huawei.com Content-Type: text/plain; charset=ISO-8859-1 Cc: rtg-dir@ietf.org, Stig Venaas , draft-ietf-pim-registry.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pim-registry-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 15:59:44 -0000 For completion sake: i am assuming the logical conclusion here is for Stig to move those refs to informative, correct? cheers, jamal On Tue, Jan 18, 2011 at 1:10 PM, Adrian Farrel wrote: > Hi, > > A Normative reference is one that must be read to understand the document in > hand. > > A reference used to say "this code point was created in the referenced document" > does not require the referenced document to be read. That would make it > Informational. > > A > >> -----Original Message----- >> From: Stig Venaas [mailto:svenaas@cisco.com] >> Sent: 18 January 2011 18:02 >> To: Jamal Hadi Salim >> Cc: rtg-ads@tools.ietf.org; rtg-dir@ietf.org; draft-ietf-pim- >> registry.all@tools.ietf.org >> Subject: Re: RtgDir review: draft-ietf-pim-registry-03 >> >> On 1/17/2011 5:57 AM, Jamal Hadi Salim wrote: >> > Hello, >> > >> > I have been selected as the Routing Directorate reviewer for this draft. >> > The Routing Directorate seeks to review all routing or routing-related >> > drafts as they pass through IETF last call and IESG review. The purpose >> > of the review is to provide assistance to the Routing ADs. For more >> > information about the Routing Directorate, please see >> > http://www.ietf.org/iesg/directorate/routing.html >> >> Thanks, I agree with your comments. Just one question. >> >> [...] >> > Nits: >> > >> > There is an interesting nit in that you have RFC 3973 as a normative >> > reference (which sounds deserving in the context of this document) >> > but that RFC is an experimental RFC. >> >> I'm not sure whether it is important, but I am wondering what is the >> right solution here. Is it OK to have a normative reference, or should >> it be an informative reference? >> >> I'm sure it must be common that registries are created and need to >> reference e.g. experimental RFCs. In some cases the registry reference >> is not even an RFC. Perhaps it then makes more sense to list them as >> informative references? >> >> Stig >> >> > >> > cheers, >> > jamal > > From stig@venaas.com Wed Jan 19 09:44:00 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DAD628C10D for ; Wed, 19 Jan 2011 09:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqOgRT2qLUEa for ; Wed, 19 Jan 2011 09:43:59 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 2364E28C0EA for ; Wed, 19 Jan 2011 09:43:59 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:983b:1c82:efb4:44ad] (unknown [IPv6:2001:420:4:ea0c:983b:1c82:efb4:44ad]) by ufisa.uninett.no (Postfix) with ESMTPSA id E59697FDA; Wed, 19 Jan 2011 18:46:36 +0100 (CET) Message-ID: <4D37237A.3070703@venaas.com> Date: Wed, 19 Jan 2011 09:46:34 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jamal Hadi Salim References: <4D35D59A.9090306@cisco.com> <04eb01cbb73a$f7476ab0$e5d64010$@huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, draft-ietf-pim-registry.all@tools.ietf.org, Adrian.Farrel@huawei.com, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pim-registry-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 17:44:00 -0000 On 1/19/2011 8:02 AM, Jamal Hadi Salim wrote: > For completion sake: i am assuming the logical conclusion here is for > Stig to move > those refs to informative, correct? I will. Based on the below, I should make all references informational, even if the document using the code point is standards track. That makes sense to me :) Stig > > cheers, > jamal > > On Tue, Jan 18, 2011 at 1:10 PM, Adrian Farrel wrote: >> Hi, >> >> A Normative reference is one that must be read to understand the document in >> hand. >> >> A reference used to say "this code point was created in the referenced document" >> does not require the referenced document to be read. That would make it >> Informational. >> >> A >> >>> -----Original Message----- >>> From: Stig Venaas [mailto:svenaas@cisco.com] >>> Sent: 18 January 2011 18:02 >>> To: Jamal Hadi Salim >>> Cc: rtg-ads@tools.ietf.org; rtg-dir@ietf.org; draft-ietf-pim- >>> registry.all@tools.ietf.org >>> Subject: Re: RtgDir review: draft-ietf-pim-registry-03 >>> >>> On 1/17/2011 5:57 AM, Jamal Hadi Salim wrote: >>>> Hello, >>>> >>>> I have been selected as the Routing Directorate reviewer for this draft. >>>> The Routing Directorate seeks to review all routing or routing-related >>>> drafts as they pass through IETF last call and IESG review. The purpose >>>> of the review is to provide assistance to the Routing ADs. For more >>>> information about the Routing Directorate, please see >>>> http://www.ietf.org/iesg/directorate/routing.html >>> >>> Thanks, I agree with your comments. Just one question. >>> >>> [...] >>>> Nits: >>>> >>>> There is an interesting nit in that you have RFC 3973 as a normative >>>> reference (which sounds deserving in the context of this document) >>>> but that RFC is an experimental RFC. >>> >>> I'm not sure whether it is important, but I am wondering what is the >>> right solution here. Is it OK to have a normative reference, or should >>> it be an informative reference? >>> >>> I'm sure it must be common that registries are created and need to >>> reference e.g. experimental RFCs. In some cases the registry reference >>> is not even an RFC. Perhaps it then makes more sense to list them as >>> informative references? >>> >>> Stig >>> >>>> >>>> cheers, >>>> jamal >> >> From enkechen@cisco.com Fri Jan 21 16:42:24 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 141F63A6868 for ; Fri, 21 Jan 2011 16:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnJ-2ixqCsho for ; Fri, 21 Jan 2011 16:42:23 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 43FEE3A685D for ; Fri, 21 Jan 2011 16:42:23 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 22 Jan 2011 00:45:10 +0000 Received: from dhcp-171-71-139-100.cisco.com (dhcp-171-71-139-100.cisco.com [171.71.139.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0M0jAi4007608; Sat, 22 Jan 2011 00:45:10 GMT Message-ID: <4D3A28D1.6000907@cisco.com> Date: Fri, 21 Jan 2011 16:46:09 -0800 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Lightning/1.0b1 Thunderbird/3.0.11 MIME-Version: 1.0 To: rtg-ads@tools.ietf.org Content-Type: multipart/alternative; boundary="------------010003090403070600010804" Cc: rtg-dir@ietf.org, Enke Chen , draft-ietf-isis-purge-tlv.all@tools.ietf.org Subject: [RTG-DIR] Review of draft-ietf-isis-purge-tlv-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 00:42:24 -0000 This is a multi-part message in MIME format. --------------010003090403070600010804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-isis-purge-tlv-05.txt Reviewer: Enke Chen Review Date: January 20, 2011 Intended Status: Standards Track ** Summary: **** The proposed extension makes sense. The new TLV is useful in debugging and operation. There is no performance impact as it is limited to purges.** ** **Comments: Overall this document is clearly written and easy to understand.**** Major Issues: None. Minor Issues: None. --------------010003090403070600010804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-isis-purge-tlv-05.txt
Reviewer: Enke Chen
Review Date: January 20, 2011
Intended Status: Standards Track

Summary:

The proposed extension makes sense.  The new TLV is useful in debugging and operation. There is no performance impact as it is limited to purges.

Comments:

Overall this document is clearly written and easy to understand.

Major Issues:

None.

Minor Issues:

None.

--------------010003090403070600010804-- From matthew.bocci@alcatel-lucent.com Tue Jan 25 07:39:05 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BD6B3A67F3 for ; Tue, 25 Jan 2011 07:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.655 X-Spam-Level: X-Spam-Status: No, score=-105.655 tagged_above=-999 required=5 tests=[AWL=0.594, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtzPSzJ5sQiG for ; Tue, 25 Jan 2011 07:39:04 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id DEB213A67EA for ; Tue, 25 Jan 2011 07:39:03 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p0PFe7sv001261 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Jan 2011 16:41:58 +0100 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.38]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 25 Jan 2011 16:41:53 +0100 From: "Bocci, Matthew (Matthew)" To: "rtg-ads@tools.ietf.org" Date: Tue, 25 Jan 2011 16:41:50 +0100 Thread-Topic: RtgDir review: draft-ietf-isis-ieee-aq-03.txt Thread-Index: Acu8pmNJeKztidBxRxWE5eBZQQEXlw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "rtg-dir@ietf.org" , "draft-ietf-isis-ieee-aq@tools.ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-isis-ieee-aq-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 15:39:05 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-isis-ieee-aq-03.txt Reviewer: Matthew Bocci Review Date: 24-01-11 IETF LC End Date: 18-01-11 Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: Major Issues: None Minor Issues: Abstract: 802.1aq Shortest Path Bridging (SPB) is being standardized by the IEEE as the next step in the evolution of the various spanning tree and registration protocols. 802.1aq allows for true shortest path forwarding in a mesh network context utilizing multiple equal cost paths. This permits it to support much larger layer 2 topologies, with faster convergence, and vastly improved use of the mesh topology. Combined with this is single point provisioning for logical connectivity membership (E-LINE/E-LAN/E-TREE etc). MB> I would suggest stating up-front that this is applicable to Ethernet e.g. "802.1aq allows for true shortest path forwarding in an Ethernet mesh network context utilizing multiple equal cost paths." Also, please expand all acronyms on first use. Note that 802.1aq requires no state machine or other substantive changes to [IS-IS]. It is our intention that 802.1aq be simply a new ^^^^^^^^^ MB> Is this an intention or fact? I think this could be rephrased as e.g. "802.1aq simply requires a new NLPID and set of TLVs." NLPID and set of TLVs. In the event of any confusion the reader should take [IS-IS] as authoritative. MB> Please can you clarify the above sentence. Do you mean "In the event of inconsistency between this document and [IS-IS], [IS-IS] should be taken as authoritative."? =20 Section 1: Introduction: This section is empty. I suggest that some text should be proposed to fill this section. Section 4:=20 This draft specifies a number of extensions, in particular a set of new TLVs, to allow IS-IS to support Shortest Path Bridging (SPB). Those sections of the draft are clearly normative. It also includes a lengthy overview (Section 4) of SPB which I do not think is intended to be normative (the draft explains that the IEEE is responsible for the overall standardisation of SPB). However, that section contains some text using normative language, e.g: MUST NOT in Section 4.3. I believe this language should be removed and the status of section 4 clarified. You could include a statement similar to the statement about IS-IS that you used in the abstract, but referencing [802.1aq], as the first paragraph of section 4. Sections 13 - 16 These sections define the new TLVs. In general, the figures do not indicate the byte ordering/alignment and do not share a common style. For example, in section 14.1: +-+-+-+-+-+-+-+-+ |Type =3D SPB-Inst| =3D 1 +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CIST Root Identifier (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CIST Root Identifier (cont) (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CIST External ROOT Path Cost (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bridge Priority | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R R R R R R R R R R R|V| SPSourceID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num of Trees | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLAN-ID (1) Tuples (8 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLAN-ID (N) Tuples (8 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where VLAN-ID tuples have the format as: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ |U|M|A| Res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ECT - Algorithm (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Base VID (12 bits) | SPVID (12 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ It would help readability if you structured the figures throughout showing the ordering/alignment by adding a couple of lines to the top of each one showing the bit/byte alignment, as in the VLAN-ID tuple example above. Nits: - There are numerous instances where acronyms are not expanded on first use. Please expand all unfamiliar (i.e. not very common in the routing area) acronyms. - Section 4, 2nd para, last line: please provide references for 802.1ag and Y.1731.=20 From stig@venaas.com Mon Jan 31 12:45:31 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55C803A6C8E for ; Mon, 31 Jan 2011 12:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.395 X-Spam-Level: X-Spam-Status: No, score=-102.395 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHROFWKBWUT1 for ; Mon, 31 Jan 2011 12:45:30 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 934663A6C71 for ; Mon, 31 Jan 2011 12:45:29 -0800 (PST) Received: from [IPv6:2001:420:4:ea0c:954b:5606:be1f:6b0c] (unknown [IPv6:2001:420:4:ea0c:954b:5606:be1f:6b0c]) by ufisa.uninett.no (Postfix) with ESMTPSA id 193737FE6; Mon, 31 Jan 2011 21:48:42 +0100 (CET) Message-ID: <4D47202C.5060005@venaas.com> Date: Mon, 31 Jan 2011 12:48:44 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jamal Hadi Salim References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, draft-ietf-pim-registry.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pim-registry-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 20:45:31 -0000 Hi Thanks for the review. I have now submitted revision 04 that I believe takes care of your issues. See below. On 1/17/2011 5:57 AM, Jamal Hadi Salim wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review. The purpose > of the review is to provide assistance to the Routing ADs. For more > information about the Routing Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-pim-registry-03 > Reviewer: Jamal Hadi Salim > Review Date: 2011-01-17 > IETF LC End Date: 2011-01-20 > Intended Status: proposed standard > > Summary: > > I have some very minor concerns about this document that may need > to be cleared before publication. > > Comments: > > The document is well written and structured to request IANA for > the creation of a registry for PIM message types. The initial > content specified on this document is based on existing RFCs. > The document goes on to specify how new PIM message types should > be allocated. > > Major Issues: > > No major issues found. > > Minor Issues: > Although section 3.2 describes how the new types should be allocated, > given that this document is the first time all allocated PIM message > types are aggregated, it would be useful to also list the unassigned > message types and summarize what 3.2 says. i.e. > > Type Name Reference > ---- ---------------------------------------- --------------------- > 0 Hello [RFC3973] [RFC4601] > 1 Register [RFC4601] > 2 Register Stop [RFC4601] > 3 Join/Prune [RFC3973] [RFC4601] > 4 Bootstrap [RFC4601] > 5 Assert [RFC3973] [RFC4601] > 6 Graft [RFC3973] > 7 Graft-Ack [RFC3973] > 8 Candidate RP Advertisement [RFC4601] > 9 State Refresh [RFC3973] > 10 DF Election [RFC5015] > 11-14 Unassigned at the moment Future IETF Review I added 11-14 Unassigned this document > 15 Reserved (for extension of type space) [this document] > > Nits: > > There is an interesting nit in that you have RFC 3973 as a normative > reference (which sounds deserving in the context of this document) > but that RFC is an experimental RFC. I have now made them informative. I believe that is appropriate. In addition I added the sentence: The message type is a 4-bit integer with possible values from 0 to 15. Stig > > cheers, > jamal From hadi@mojatatu.com Mon Jan 31 15:02:44 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7C1A3A6B42 for ; Mon, 31 Jan 2011 15:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.069 X-Spam-Level: X-Spam-Status: No, score=-102.069 tagged_above=-999 required=5 tests=[AWL=0.908, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cu2Xq2jzXrtH for ; Mon, 31 Jan 2011 15:02:44 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id EE9B93A6B26 for ; Mon, 31 Jan 2011 15:02:43 -0800 (PST) Received: by qwi2 with SMTP id 2so6390514qwi.31 for ; Mon, 31 Jan 2011 15:05:58 -0800 (PST) Received: by 10.224.20.9 with SMTP id d9mr6770807qab.228.1296515144546; Mon, 31 Jan 2011 15:05:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.179.202 with HTTP; Mon, 31 Jan 2011 15:05:24 -0800 (PST) In-Reply-To: <4D47202C.5060005@venaas.com> References: <4D47202C.5060005@venaas.com> From: Jamal Hadi Salim Date: Mon, 31 Jan 2011 18:05:24 -0500 Message-ID: To: Stig Venaas Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtg-dir@ietf.org, draft-ietf-pim-registry.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pim-registry-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 23:02:45 -0000 Hi Stig, Sounds good to me. I will take your word for it and assume that i dont need to validate the document for those changes ;-> cheers, jamal On Mon, Jan 31, 2011 at 3:48 PM, Stig Venaas wrote: > Hi > > Thanks for the review. I have now submitted revision 04 that I believe > takes care of your issues. See below. > > On 1/17/2011 5:57 AM, Jamal Hadi Salim wrote: >> >> Hello, >> >> I have been selected as the Routing Directorate reviewer for this draft. >> The Routing Directorate seeks to review all routing or routing-related >> drafts as they pass through IETF last call and IESG review. The purpose >> of the review is to provide assistance to the Routing ADs. For more >> information about the Routing Directorate, please see >> http://www.ietf.org/iesg/directorate/routing.html >> >> Although these comments are primarily for the use of the Routing ADs, it >> would be helpful if you could consider them along with any other IETF >> Last Call comments that you receive, and strive to resolve them through >> discussion or by updating the draft. >> >> Document: draft-ietf-pim-registry-03 >> Reviewer: Jamal Hadi Salim >> Review Date: 2011-01-17 >> IETF LC End Date: 2011-01-20 >> Intended Status: proposed standard >> >> Summary: >> >> I have some very minor concerns about this document that may need >> to be cleared before publication. >> >> Comments: >> >> The document is well written and structured to request IANA for >> the creation of a registry for PIM message types. The initial >> content specified on this document is based on existing RFCs. >> The document goes on to specify how new PIM message types should >> be allocated. >> >> Major Issues: >> >> No major issues found. >> >> Minor Issues: >> Although section 3.2 describes how the new types should be allocated, >> given that this document is the first time all allocated PIM message >> types are aggregated, it would be useful to also list the unassigned >> message types and summarize what 3.2 says. i.e. >> >> =A0 =A0Type =A0 Name =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0Reference >> =A0 =A0---- =A0---------------------------------------- =A0-------------= -------- >> =A0 =A0 =A00 =A0 =A0Hello =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [RFC3973] [RFC4601] >> =A0 =A0 =A01 =A0 =A0Register =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0[RFC4601] >> =A0 =A0 =A02 =A0 =A0Register Stop =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 [RFC4601] >> =A0 =A0 =A03 =A0 =A0Join/Prune =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0[RFC3973] [RFC4601] >> =A0 =A0 =A04 =A0 =A0Bootstrap =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 [RFC4601] >> =A0 =A0 =A05 =A0 =A0Assert =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[RFC3973] [RFC4601] >> =A0 =A0 =A06 =A0 =A0Graft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [RFC3973] >> =A0 =A0 =A07 =A0 =A0Graft-Ack =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 [RFC3973] >> =A0 =A0 =A08 =A0 =A0Candidate RP Advertisement =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0[RFC4601] >> =A0 =A0 =A09 =A0 =A0State Refresh =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 [RFC3973] >> =A0 =A0 10 =A0 =A0DF Election =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 [RFC5015] >> =A0 =A0 11-14 Unassigned at the moment =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0Future IETF Review > > I added > > 11-14 Unassigned =A0 =A0 =A0this document > >> =A0 =A0 15 =A0 =A0Reserved (for extension of type space) =A0 =A0[this do= cument] >> >> Nits: >> >> There is an interesting nit in that you have RFC 3973 as a normative >> reference (which sounds deserving in the context of this document) >> but that RFC is an experimental RFC. > > I have now made them informative. I believe that is appropriate. > > In addition I added the sentence: > > The message type is a 4-bit integer with possible values from 0 to 15. > > Stig > >> >> cheers, >> jamal > > From julien.meuric@orange-ftgroup.com Mon Jan 31 15:51:01 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 839E03A6C64 for ; Mon, 31 Jan 2011 15:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agFNXpktfrvK for ; Mon, 31 Jan 2011 15:51:00 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 34B493A68B1 for ; Mon, 31 Jan 2011 15:51:00 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3A9ED6C0002; Tue, 1 Feb 2011 00:54:44 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 2C3206C0001; Tue, 1 Feb 2011 00:54:44 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Feb 2011 00:54:14 +0100 Received: from [10.193.116.25] ([10.193.116.25]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Feb 2011 00:54:13 +0100 Message-ID: <4D474BA3.7020803@orange-ftgroup.com> Date: Tue, 01 Feb 2011 00:54:11 +0100 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "rtg-ads@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jan 2011 23:54:14.0037 (UTC) FILETIME=[29CD3C50:01CBC1A2] Cc: "rtg-dir@ietf.org" , draft-ietf-ccamp-mpls-tp-cp-framework.all@tools.ietf.org Subject: [RTG-DIR] RtgDir Review: draft-ietf-ccamp-mpls-tp-cp-framework X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 23:51:01 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-ccamp-mpls-tp-cp-framework-05 Reviewer: Julien Meuric Review Date: 31 January 2011 IETF LC End Date: 31 January 2011 Intended Status: Informational *Summary:* I have some minor concerns about this document that I think should be resolved before publication. *Comments:* This document is clearly written and easy to understand, even if the reader does not go over the numerous references. *Major Issues:* No major issues found. *Minor Issues:* (leaving out acronym expansion or references to add already highlighted by the AD) ---------- Section 1.3 Quoting Adrian (by the way: congratulations!): "A reference to draft-ietf-mpls-tp-uni-nni might be appropriate to aid the discussion of UNIs and NNIs." Indeed, but it requires more than a reference: since the aforementioned I-D only defines "service interfaces", a little elaboration on the use of "NNI" in draft-ietf-ccamp-mpls-tp-cp-framework is needed. ---------- Section 2.1 Requirement 17 looks like a tautology. Requirement 19 in RFC 5654 clarifies the intend, but I am not sure it is needed here more than "A control plane must not be required to support coffee making". Requirements 21 and 22 refers to "homogeneous" and "non homogeneous" domains, but I do not think it is defined. Would my domain with all my 640 Mb/s switching capacity nodes be homogeneous? I believe requirement 24 also covers 27.C from RFC 5654. Requirement 39 mentions ASON: I thought the scope of ASON was circuit-switched technologies, has it been extended for packet-switched? Requirement 62 states "this should be the default": I guess "this" refers to bidirectional, but I believe the wording should be improved. Requirement 65 says "the control plane may support extra-traffic": not sure what is means (extra traffic over the control network?). ---------- Section 4.2.1 It is consistent to section 2 of RFC 5951: an explicit reference could be added, especially when considering the title of that RFC... ---------- Section 4.3 and 5.2 Not sure about the dashes following the numbers: should not they be in the right column instead of the left one? It is a bit surprising to see explicitly "proper vendor implementation" while it is should be implicit for any standard specification... ---------- Section 5.3.2: "If the control plane is physically separated... information". I do not believe this paragraph is needed here: no other section mentions that sub-case (which might be in the scope of the ForCES WG). ---------- Section 4.2.1 focuses on "Management Plane Support" within the "4. TE LSPs" section. The same kind of paragraph is expected in the "5. Pseudowires" section but is currently missing. ---------- *Nits:* ---------- Section 1.2 s/over LSP based/over LSP-based/ ---------- Section 2.3 s/customer/client/ ---------- Section 4.1.1 s/control (and management) planes/control (and management) plane(s)/ ---------- Section 4.1.2 s/and consequently, MPLS-TP uses/and consequently MPLS-TP, uses/ s/control (and management) planes/control (and management) plane(s)/ ---------- Section 4.1.4.1 (interesting concepts) s/(PCE) Based approaches/(PCE)-based approaches/ s/PCE requests and responses/requests to and responses from PCE/ ---------- Section 4.1.9 s/LSPs as discussed in [TP-SURVIVE], is/LSPs, as discussed in [TP-SURVIVE], is/ ---------- Section 4.2.1.2 s/the life, (traffic hit/the life (traffic hit/ ---------- Section 4.4.4 s/but nonetheless, must/but nonetheless must/ ---------- Section 4.4.5 s/OAM related/OAM-related/ (twice) ---------- Section 4.4.6 s/Diffserv enable/Diffserv-enabled/transport s/Diffserv related/Diffserv-related/ ---------- Section 4.4.8 s/entity related/entity-related/ ---------- Section 5.3.1 s/to be, theoretically, a straightforward exercise/to be a straightforward exercise/ (unless there is a strong reason to keep it theoretical) ---------- Section 5.3.5 s/transport service require OAM/transport service requires OAM/ s/performance related monitor/performance-related monitor/ ---------- Section 6 s/MPLS and GMPLS related/MPLS- and GMPLS-related/ ---------- Regards, Julien