Re: [CCAMP] 2nd WG Last Call comments on ospf-g709v3 (editorial only)
Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Tue, 25 June 2013 09:59 UTC
Return-Path: <daniele.ceccarelli@ericsson.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72FF21E808D for <ccamp@ietfa.amsl.com>; Tue, 25 Jun 2013 02:59:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.051
X-Spam-Level:
X-Spam-Status: No, score=-3.051 tagged_above=-999 required=5 tests=[AWL=-0.452, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-SalLGXf0gi for <ccamp@ietfa.amsl.com>; Tue, 25 Jun 2013 02:59:34 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id E22AB21E804B for <ccamp@ietf.org>; Tue, 25 Jun 2013 02:59:27 -0700 (PDT)
X-AuditID: c1b4fb38-b7f476d0000049c9-60-51c969fedf58
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 6A.39.18889.EF969C15; Tue, 25 Jun 2013 11:59:26 +0200 (CEST)
Received: from ESESSMB301.ericsson.se ([169.254.1.30]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0328.009; Tue, 25 Jun 2013 11:59:25 +0200
From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
To: Lou Berger <lberger@labn.net>, CCAMP <ccamp@ietf.org>, "draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org" <draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org>
Thread-Topic: 2nd WG Last Call comments on ospf-g709v3 (editorial only)
Thread-Index: AQHOaT5Cf8xlCy0KhEe413e0mrGZ+Zk5kc0QgAADdACAAAOEYA==
Date: Tue, 25 Jun 2013 09:59:25 +0000
Message-ID: <4A1562797D64E44993C5CBF38CF1BE480EEBF7@ESESSMB301.ericsson.se>
Accept-Language: it-IT, en-US
Content-Language: it-IT
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.16]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM+Jvre6/zJOBBn8vq1g8mXODxeJvw2sW i47mtywOzB5Llvxk8viwqZnN48vlz2wBzFFcNimpOZllqUX6dglcGXsWfmYs6Paq+L5AuoHx tWUXIyeHhICJxPnO5SwQtpjEhXvr2boYuTiEBI4ySizYtx/KWcwocWDBH/YuRg4ONgEriSeH fEDiIgLLGCUebpjIDtItLOAmsbL1AjOILSLgLvFv020o20liz8VnYDaLgKrEjzftYDavgLfE 75OXWEFsRgFZiQm7FzGC2MwC4hIvpp9gh7hIQGLJnvPMELaoxMvH/1ghbEWJnWch5jAL6Enc mDqFDcLWlli28DXUfEGJkzOfsExgFJ6FZOwsJC2zkLTMQtKygJFlFSNHcWpxUm66kcEmRmDA H9zy22IH4+W/NocYpTlYlMR5P53aFSgkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBkSVYcbvz D++dZt4bP0e3pYbfbnRR6pY3XGayMUVPY92+jddevCoo2dVUxbd2y/E1ry8+ZlDud+8u7/XM /VI8u8f/rusPm2+uB0NPn9x4MO+E4dEa4dl/j74+9TZuwdKpy+QyTu3LezHTWjf7yqXZD7mv X/m290PKvKATif23q4X75BZ9235+5golluKMREMt5qLiRADEBuxwRgIAAA==
Subject: Re: [CCAMP] 2nd WG Last Call comments on ospf-g709v3 (editorial only)
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jun 2013 09:59:40 -0000
Hi Lou, All comments addressed. Some comments in line below. BR Daniele >-----Original Message----- >From: Lou Berger [mailto:lberger@labn.net] >Sent: venerdì 14 giugno 2013 22.32 >To: CCAMP; draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org >Subject: 2nd WG Last Call comments on ospf-g709v3 (editorial only) > >Hi, > The following are comments as part of my LC review of >draft-ietf-ccamp-gmpls-ospf-g709v3-06. Note that I'm the document >shepherd, see RFC 4858 for more information. > >Please see >http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft -ietf-ccamp-gmpls-ospf-g709v3-06.txt >for line numbers used in this message. > >The draft needs to be nit free before being passed to the IESG. The >following nits show in the above URL: > Miscellaneous warnings: > >--------------------------------------------------------------- >------------- > > == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', >'SHOULD', > or 'RECOMMENDED' is not an accepted usage according to RFC 2119. >Please > use uppercase 'NOT' together with RFC 2119 keywords (if that is >what you > mean). > > Found 'MUST not' in this paragraph: > > - Unreserved Bandwidth (32 bits): This field indicates the > Unreserved Bandwidth at a particular priority level. >This field MUST be > set to the bandwidth, in bits/s in IEEE floating point format, >available > at the indicated Signal Type for a particular priority level. One >field > MUST be present for each bit set in the Priority field, and is >ordered to > match the Priority field. Fields MUST not be present for priority >levels > that are not indicated in the Priority field.This field is >REQUIRED for > Type 2 (variable container) TLVs, and MUST NOT be used for Type 1 >TLVs. > > -- The document date (April 4, 2013) is 71 days in the past. Is this > intentional? > > > Checking references for intended status: Proposed Standard > >--------------------------------------------------------------- >------------- > > (See RFCs 3967 and 4897 for information about using normative >references > to lower-maturity documents in RFCs) > > == Outdated reference: A later version (-12) exists of > draft-ietf-ccamp-gmpls-g709-framework-11 > > == Outdated reference: A later version (-08) exists of > draft-ietf-ccamp-otn-g709-info-model-05 > > == Outdated reference: A later version (-09) exists of > draft-ietf-ccamp-gmpls-signaling-g709v3-05 > >I also have the following editorial comments: > >As with other documents: >- This and the other g709v3 documents should be consistent in usage of >"TS granularity" versus "TSG". Sometimes one is used rather than the >other, sometimes both are used in the same document (as is the case in >this document). Please pick either one and update the four documents >to be consistent. TS granularity use. TSG used only in figures because of room. > >- Another and related comment is please define and use a consistent >plural form of "TS". You initially define "TSs" to expand to "Time >Slots", but then use "TS" as the plural form in many (but not all >cases). I personally think "TSs" in all plural cases makes the most >sense. OK > >- Also same comment for TSGs. > >- Please be consistent in usage of "Gbps". Some inconsistent examples: > "1.25/2.5", "1.25Gps", "1.25 GBps" and "1.25 Gbps". (I personally >prefer the final form, but any common form is fine.) 1.25Gbps and 2.5Gbps > >- RFC 4203 uses the field name "Switching Capability-specific > information" while the document uses "Switch Capability Specific > Information", so throughout the document please > s/Switch Capability/Switching Capability > >- per RFC4203, fix capitalization when referring to the filed name: > s/MAX LSP bandwidth/MAX LSP Bandwidth > >lines 2-5: > Shouldn't this document be identified as an update to 4203? > YES >Lines 24-32: > The Abstract is really in need of a make over. How about something > like the following: > > This document describes Open Shortest Path First - Traffic > Engineering (OSPF-TE) routing protocol extensions to support > Generalized MPLS (GMPLS) control of Optical Transport Networks > (OTN) specified in ITU-T Recommendation G.709 as published in 2012. > It extends mechanisms defined in RFC4203. > >Line 102: > Expand ODU > >Lines 105/6: > Drop "which is being standardized in ITU-T" > >Line 107: > s/the routing process/routing > >Lines 108: > You should mentioned the base OSPF TE document here. How about: > s/OSPF-TE/use in GMPLS OSPF-TE as defined in [RFC4203]. > >Line 115: > s/The routing/Routing > >Line 143-145: > I think this text reads a bit backwards, it is the need for the ISCD > that drives the new type/swcap, not the other way around I also > suggest adding informative reference to > draft-ietf-ccamp-swcaps-update, perhaps something like: > > OLD > This > leads to the need to define a new Switching Capability value and > associated new Switching Capability for the Interface Switching > Capability Descriptor (ISCD). > NEW > These capabilities are carried in the Interface Switching > Capability Descriptor (ISCD) Switching Capability-specific > information field using formats defined in this document. > As discussed in [swcaps-update], the use of a technology specific > Switching Capability-specific information field necessitates > the definition of a new Switching Capability value and > associated new Switching Capability. > OK >Line 178: > Drop "on this traffic card" > >Lines 192/3: > "The TE-Link is referred to as OTUk-TE-Link." > This term is used just once in the document. Suggest dropping it. > OK >Lines 193/4: > Doesn't the TE link for an OTUk physical Link always provide ODUk > capacity? Either way this text needs to be fixed/clarified. What about dropping all of this text: The TE-Link is 193 referred to as OTUk-TE-Link. The OTUk-TE-Link advertises ODUj 194 switching capacity. The advertised capacity could include ODUk 195 switching capacity. > >Lines 196, 206: > Is this an OTUk or ODUk TE link? You first says the former then the > latter. I suspect you mean former, i.e., s/ODUk/OTUk > OK >Line 209/10: > "Such TE-Links are also termed ODUk-TE-Links." > This term is used just once in the document. Suggest dropping it. OK > >Lines 210-212,221: > ODUj vs ODUk. Isn't it the case that a multi hop TE link could > represent either ODUj or ODUk resources? This isn't clear from the > current text/usage of ODUj/k. > New text: It is possible to create TE-Links that span more than one hop by creating FA between non-adjacent nodes. As in the one hop case, these types of ODUk-TE-Links also advertise ODU switching capacity. >Line 229: > s/[RFC4202]/and is defined in [RFC4203] > >Lines 249-257: > The document already says 4203 MUST be followed, so no need to >provide > normative language for 4203-defined behavior. Specifically: > s/field MUST be used/field is used > s/MUST be in/is in > >Lines 286/7: > Isn't this sentence redundant with the prior sentence? Suggest > dropping. > OK >Line 291: > s/OTN ISCD/OTN-TDM ISCD > >Line 293/4: > Types are defined in this document. > Suggest adding: > Note that type values are defined in this document and not >[RFC3630]. > >Line 301: > SCSI acronym not defined. > >Line 301,302: > s/any/each > >Line 302: > To clarify and to add a transition to the next paragraph, I suggest > adding something along the lines of: > Each container type is identified by a Signal Type. Signal Type > values are defined in [OTN-SIG]. OK > >Line 469/470: > The sentence starting "This field is ..." isn't used consistently > (i.e., not present for Unreserved ODUj, Unreserved Padding, and > Maximum LSP Bandwidth). It should be dropped, or parallel > statements should be added for the other cases. > dropped >Line 1112: > I think the first sentence is a bit hard to follow. How about: > OLD > This document, as [RFC4203], specifies > NEW > This document extends [RFC4203]. As with[RFC4203], it specifies ok > >Line 1133: > s/Type/Name > >Line 1145: > How about the following as the registry name: > "Types for sub-TLVs of OTN-TDM SCSI (Switch Capability Specific >Information)" > >Lines 1153-1159 > To be aligned with what you want to see with the registry, and fix >type 2 description: > > Value Sub-TLV Reference > 0 Reserved [This.I-D] > 1 Unreserved Bandwidth [This.I-D] > for fixed containers > 2 Unreserved/Max Bandwidth [This.I-D] > for flexible containers > ok >Lines 1161/2 > You some parts of the IANA "formula", how about: > OLD > New TLV type values may be allocated only by an IETF Consensus > action. The request Registration Procedures are Standards Action. > New > Types are to be assigned via Standards Action as defined in > [RFC5226]. > >Lines 1247-1249: > Shouldn't [G.709-2012] be normative? yes > >That's it, >Lou > >
- Re: [CCAMP] 2nd WG Last Call comments on ospf-g70… Daniele Ceccarelli
- Re: [CCAMP] 2nd WG Last Call comments on ospf-g70… Lou Berger
- Re: [CCAMP] 2nd WG Last Call comments on ospf-g70… Daniele Ceccarelli
- Re: [CCAMP] 2nd WG Last Call comments on ospf-g70… Lou Berger