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.