WG last call comments on draft-ietf-ccamp-mpls-graceful-shutdown

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

Hi,

I've received the following comments from, amongst others, Dimitri 
Papadimitriou.

===
The first section of the draft after the table of contents should be the 
Introduction. Terminology must come later.
===
The doc is applicable to both MPLS-TE and GMPLS, but the introduction does 
not make this sufficiently clear.
===
Section 4.1.1 needs to be sure to cover MPLS-TE and GMPLS. In particular, it 
needs to be clear about the relative applicabilities of RFC3630 and RFC4203.
===
Would be good to refine the description of the use of Notify message in 
Section 4.2.1. Normally Notify is used in addition to an Error message 
(PathErr/ResvErr), not in place of an Error message. This may be the 
intention of the text, but the use of "or" in two places leads to confusion. 
If the authors intend to exclusively use a Notify message, they should look 
at defining an ADMIN_STATUS bit.
===
Sections 4.2.2 and 4.2.3 should be aligned with the decision on 4.2.1
===
It would be helpful to have only one instance of section 4.2.2
===
The document does not state how LSP Path/Resv state that was established 
based on "old" OSPF/ISIS information is treated. All that we have is 
"rejection", but what does that actually mean in terms of error codes and 
precise processing?
===
Section 5 states that there are no new security considerations. It is true 
that there are no new protocol elements needing protection, but there is a 
change in the risk analysis. But this document introduces ways to make 
resources unavailable for the control plane. The section should highlight 
the consequences of such operations being attacked, and point out how such 
attacks might be detected and whether the operations place additional 
requirements for the use of which (existing) security techniques.

Thanks,
Adrian