WG Chair review of draft-ietf-ccamp-gmpls-g709-06.txt

["Adrian Farrel" <adrian@olddog.co.uk>]

Herewith a bunch of nits to be fixed after last call, please.

Thanks,
Adrian

> This email begins a working group last call on draft-ietf-ccamp-gmpls-g709-06.txt
> The last call will end on Friday 26th March at 12 noon GMT.
>
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g709-06.txt


Preamble
   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].
Reference [1] is not in the citations list.

Please place the Disclaimer before the Abstract. Please change
"Disclaimer" to "Note on ITU-T Recommendation G.709"

Disclaimer text...
Replace
   In this document, the presented views on ITU-T G.709 OTN
   Recommendation (and referenced) are intentionally restricted as
   needed from the GMPLS perspective within the IETF CCAMP WG context.
With
   The views on the ITU-T G.709 OTN Recommendation presented in this
   document are intentionally restricted to the GMPLS perspective within
   the IETF CCAMP WG context.

Replace
Table of Content
with
Table of Contents

Replace
   Table of Content ................................................ 2
with
   Table of Contents ............................................... 2

Section 2
   The OCh
   overhead is transported in a non-associated manner (so also referred
   to as the non-associated overhead û naOH)
Read
   The OCh
   overhead is transported in a non-associated manner (also referred
   to as the non-associated overhead naOH)

Section 2
   Therefore, adapting GMPLS to control G.709 OTN, can be achieved by
   considering that:
Read
   Adapting GMPLS to control G.709 OTN, can be achieved by creating:

Section 2
   Moreover, since the multiplexing in the digital domain
Read
   Moreover, since multiplexing in the digital domain

Section 2
   Notice also that one directly uses the G.709 ODUk (i.e.
   Digital Path) and OCh (i.e. Optical Path) layers in order to define
   the corresponding label spaces.
Read
   Notice also that one uses the G.709 ODUk (i.e. Digital Path) and
   OCh (i.e. Optical Path) layers directly in order to define the
   corresponding label spaces.

Section 3
   In this section, both parts are extended to
   accommodate the GMPLS Signalling to the G.709 transport plane
   recommendation (see [ITUT-G709]).
Read
   In this section, both parts are extended to
   accommodate GMPLS Signalling to the G.709 transport plane
   recommendation (see [ITUT-G709]).

Section 3.1
   As mentioned here above, this document extends the LSP Encoding
Read
   As mentioned above, this document extends the LSP Encoding

Section 3.1.1
   Therefore, the current "Digital Wrapper" code-point defined in
   [RFC3471] can be replaced by two separated code-points:
Read
   Therefore, the current "Digital Wrapper" code-point defined in
   [RFC3471] can be replaced by two separate code-points:

Section 3.1.1
   In the same way, two separated code-points can replace the current
   defined "Lambda" code-point:
Read
   In the same way, two separate code-points can replace the current
   defined "Lambda" code-point:

Section 3.1.3
   Note: Value 49 and 50 includes mapping of SDH
Read
   Note: Values 49 and 50 include mapping of SDH.

3.2.1 Signal Type (ST)
Can I assume that the choice of values here is intended to match a list
of values defined somewhere else? A note to that effect would be
helpful. (If not, why do you have gaps?).

Section 3.2.3
   Note that the current usage of this field only applies for G.709
   ODUk LSP i.e. values greater than zero, are only acceptable for ODUk
Read
   Note that the current usage of this field only applies for G.709
   ODUk LSPs i.e. values greater than zero, are only acceptable for ODUk

Section 3.2.3
   Therefore, it MUST be set to zero (NVC = 0) when
   requesting a G.709 OCh LSP and should be ignored when received.
Read
   Therefore, it MUST be set to zero (NVC = 0), and should be ignored
   when received, when a G.709 OCh LSP is requested.

Section 3.2.5
   The reserved fields (8 bits in row 1 and 32 bits fields in row 3)
Read
   The reserved fields (8 bits in row 1 and 32 bits in row 3)

Section 4.1
        - t2=1 indicates a not further sub-divided ODU2 signal.
Read
        - t2=1 indicates an ODU2 signal that is not further sub-divided.

Section 4.1
        - t3=1 indicates a not further sub-divided ODU3 signal.
Read
        - t3=1 indicates an ODU3 signal that is not further sub-divided.

Section 4.2
   Note: as defined in [RFC3471], label field values only have
   significance between two neighbors, and the receiver may need (in
   some particular cases) to convert the received value into a value
   that has local significance.
I am not clear about this text. You have very precisely defined the
meaning of the label field values. If this note is true, the whole of
section 4.1 seems to be wasted.

Section 4.2
Why is this section placed between the two sections (4.1 and 4.3) that
define the label spaces?

Section 8
   Three values have to be defined by IANA for this document:
What is the third value?

Section 8 IANA considerations
It would be helpful if you requested IANA to track the codepoint spaces
that you are extending and updating. That is:
- LSP Encoding Types
- Generalized PID

Please use new IPR boilerplate.

Please make non-IETF documents (i.e. ITU-T documents informational, not
normative)

[RFC3473] is sometimes referenced as [GMPLS-SIG]

[GMPLS-ARCH] is not referenced. Please move it to Informational.

Some contributors' addresses and contact details are out of date.

13. Author's Address
should read
13. Editor's Address

Appendix 2
   - Index m: The index "m" is used to represent the bit rate or set of
   bit rates supported on the interface. This is a one or more digit
   ôkö, where each ôkö represents a particular bit rate. The valid
   values for m are (1, 2, 3, 12, 23, 123).
Gotta love those funky characters!

Please use the new copyright boilerplate

Please fill in copyright date.