Re: [CCAMP] 2nd WG Last Call comments on ospf-g709v3 (editorial only)

[Daniele Ceccarelli <[e-mail]>]

Hi Lou,

All comments addressed. Some comments in line below.

BR
Daniele 

>-----Original Message-----
>From: Lou Berger [mailto:[e-mail]]
>Sent: venerdì 14 giugno 2013 22.32
>To: CCAMP; [e-mail]
>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
>
>