Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON)
draft-ietf-ccamp-gmpls-ason-reqts-07

[Ballot comment]
Reviewed by Lucy Lynch, Gen-ART

Her review:

This draft is basically ready for publication, but has nits that should
be fixed before publication."

Needs an IANA section -

idnits 1.46 (25 Oct 2004)

draft-ietf-ccamp-gmpls-ason-reqts-07.txt:

  The document seems to lack an IANA Considerations section
  Checking conformance with RFC 3667/3668 boilerplate...

  Warnings:
    There are 11 instances of lines with hyphenated line breaks in the
document.

NOTES:

Incorporates  ITU-T SG15, Q.14/15 comments as noted here:

https://www.ietf.org/IESG/LIAISON/itut-sg15-ls-re-draft-ietf-ccamp-gmpls-ason-reqts.html
https://www.ietf.org/IESG/LIAISON/ietf-ccamp-lr-itut-sg15-ason.html

as well as changes proposed by Jonathan Sadler in San Diego, see the
ccamp thread on ASON Opacity:
http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00929.html

Question:
Is there a formal process for incorporating feedback from the ITU?

AD-review comments

draft-ietf-ccamp-gmpls-ason-reqts:
---------------------------------

Section 2: conventions.

Since 2119 talks about protocol specifications and implementations, a note
along the following lines would be helpful:

  "While [2119] describes interpretations of these key words in terms of
  protocol specifications and implementations, they are used in this document
  to describe design requirements for protocol extensions."

Regarding MAY/SHOULD/MUST themselves. The way these key words are used in
the document is not consistent. One would assume that they would be used
to specify what features or functionality would need to be supported.
However, in certain places, the way they are used is questionable.
For example:

> 3. Introduction
...
>    This document concentrates on requirements related to the signaling
>    aspects of the GMPLS suite of protocols. It discusses functional
>    requirements required to support Automatically Switched Optical
>    Networks that MAY lead to additional extensions to GMPLS signaling
                  ^^^
>    (see [RFC 3471] and [RFC 3473]) to support these capabilities.

or:

>                                          It MUST NOT be assumed that
                                              ^^^^^^^^
>    there is a one-to-one relationship of control plane interfaces and
>    transport plane (physical) links, or that there is a one-to-one
>    relationship of control plane entities and transport plane entities,
>    or that there is a one-to-one relationship of control plane
>    identifiers for transport plane resources.

  On the other hand, for instance, section 4 does not have these words
  capitalized:

> 4.2 Support for Call and Connection Separation
...
>    To support the introduction of the call concept, GMPLS signaling
>    should include a call identification mechanism and allow for end-to-
    ^^^^^^
>    end call capability exchange.
 

  Please go through the document and make sure cases like these are corrected.

  Some notes on the contents of the document:
 
>  Section 4.4:
...
>    - Any control plane failure must not result in releasing established
>      calls and connections (including the corresponding transport plane
>      connections).

  Does "any control plane failure" include fatal and unrecoverable ones?
  Does it only include single failure, or double/multiple failures also?
  These are important questions to answer, especially in comparison with
  the assumptions behind IETF graceful restart work.

> 4.6 Support for Crankback
...
>    - Rerouting attempts limitation: to prevent an endless repetition of
>      connection setup attempts (using crankback information), the
>      number of retries should be strictly limited. The maximum number
>      of crankback rerouting attempts allowed can be limited per
>      connection, per node, per area or even per administrative domain.

It is not clear what is meant here for the per-area/domain case.

Is it the sum of rerouting attempts that all nodes in an area can make (which
would require some sort of distributed coordination mechanism) or the number of
attempts that the connection initiator can make through a specific area?

Section 9: references.

Is it possible to easily access the ITU-T documents referenced?
Can URLs be included?