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

[Lou Berger <[e-mail]>]

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.

- 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.

- 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.)

- 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?

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.

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.

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.

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

Line 209/10:
  "Such TE-Links are also termed ODUk-TE-Links."
  This term is used just once in the document.  Suggest dropping it.

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.

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.

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].

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.

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

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
	
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?

That's it,
Lou