[CCAMP] AD review of draft-ietf-ccamp-gmpls-vcat-lcas-11.txt

[Adrian Farrel <[e-mail]>]

Hi,

Don't panic!

I have performed my AD review of your draft. The purpose of the review
is to catch any nits or issues before the document goes forward to IETF
last call and IESG review. By getting these issues out at this stage we
can hope for a higher quality review and a smoother passage through the
process.

Thank you for a detailed and well-written draft. I have no technical
issues with the content, but a number of small editorial comments and
process-related questions below need to be thought about.

All of my comments are up for discussion, and you should not feel rail-
roaded into making changes. But I do think my comments need to be 
addressed before the draft moves forward, and I would like to see your
answers to my points and/or a revised I-D.

I have moved the draft into "AD-review:Revised-ID-needed" state in the
datatracker, and I look forward to seeing the new revision which I can
put forward for IETF last call.

Thanks,
Adrian

---

The header correctly says "Updates: 4606", but the correct format of
this statement is "Updates: 4606 (if approved)"

---

Since the document was first submitted before 10 November 2008, can
the editor confirm that all authors have waived their pre-RFC5378 
rights?

---

Abstract
To be more clear about the update of 4606 and to remove the citation
from the abstract, can we...

OLD
   This document updates the procedures for supporting virtual
   concatenation in [RFC4606].
NEW
   This document updates RFC 4606 by making modifications to the
   procedures for supporting virtual concatenation.
END

---

In the Table of Contents, and in the section header...

c/Author's Addresses/Authors' Addresses/

---


Some acronyms need to be expanded on first use.

TDM
LSR
LSP
NVC

---

Section 2.2

Should you include a definition of "co-routed". This is not quite as
obvious as it might seem since the meanings could be:
- same routers in the same order (includes parallel links)
- same logical links in the same order (includes bundles)
- same data links in the same order (i.e. same physical interfaces)

A bit of this comes out through careful reading of the different
categories, so maybe it is not needed, but it might help.

---

Section 2.2

In "member sharing" are the members required to be co-routed or can
they be diversely routed? I think either. Can you add a note?

---

Section 2.3

     .  GMPLS signaling for non-LCAS-capable interfaces MUST support
        only the "fixed" scenarios of section 2.2.

This appears to say:
   MUST NOT support the "dynamic" scenarios.
If you mean that, can you reword accordingly.

On the other hand, it is also possible you mean:
   MUST support the "fixed" scenarios and MAY also support the "dynamic"
   scenarios.

---

Section 4

I agree that it is right to include this section, but I would like you
to make it clearer that 4606 is normative. How about...

OLD
   Note that this section is included for informational
   purposes only.
NEW
   Note that this section is included for informational
   purposes only and does not modify [RFC4606]. It is provided to
   show how the existing GMPLS procedures may be used. [RFC4606]
   provides the normative definition for GMPLS processing of VCGs
   composed of a single member set, and in the event of any 
   conflict between this section and that document, [RFC4606] 
   takes precedence.
END

---

Section 4.3

   Note if using LCAS, a VCG member can be temporary removed from the
   VCG due to a failure of the component signal. The LCAS data plane
   signaling will take appropriate actions to adjust the VCG as
   described in [ITU-T-G.7042].

s/temporary/temporarily/

---

Figure 1 caption

    Figure 1 Figure 1. Conceptual containment relationship between VCG,
        VCAT calls, control plane LSPs, and data plane connections.

"Figure 1" appears twice

---

Section 5.2

Given that "Number of Members" is a two octet integer, you need to 
mention the byte order on the wire.

---

Section 5.2

I'm a bit surprised that you have used a whole 8 bits for "LCAS
Required". Probably not important, but you could carve out some
spare bits for future extensions without changing the format.

---

Section 5.2

Should you also have a registry for the Elementary Signal Types listed
in this section? it seems likely that there will be future additions to
the list. You should say that unlisted values are reserved and you
should say what the allocation policy is for future values.

The same applies to "Action" since future actions might show up.

---

Section 6 might need to note error cases for unknown "LCAS Required"
setting (perhaps this can be noted as a malformed message and result in
a standard result code?) and unknown or unsupported "Action" (I suggest
that this is another instance for your list because some of the actions
might not be supported by an implementation, and new actions may be
defined.)

---

Section 7.1

I suggest you remove the suggested value (2) from the document.
Suggesting values is pretty risky for implementers and in this case
your suggested value clashes with RFC 6004.

---

Section 8

I suggest you add one additional paragraph to this section.

   See [RFC5920] for additional information on GMPLS security.

And (obviously) add an Informative Reference to 5920

---

You can probably delete the final line...

"Acknowledgment"