Thanks for the opportunity to comment. I think it is important to document
extensions and modifications made by other bodies to IETF protocols.
I would caution against progressing this draft until the referenced ITU material
(G.7713.3) has reached consent within the ITU since to move it forward at this
stage as an informational RFC might be misleading.
At that point, perhaps Osama could clarify in the draft, that this draft
introduces no new TLVs, messages or procedures others than those already agreed
within the ITU. That is, that this draft is truly informational. Currently the
text reads as though this draft is, itself, defining new material.
With regard to the crankback extensions described in the draft, I would question
whether the information contained in the new Crankback TLV is sufficient to
handle all scenarios and would urge the author to examine
http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-04.txt. It might
be helpful if the draft expanded the description of the contents of the ER-HOP
TLV that is included in the Crankback TLV. However, if the purpose of the draft
is simply to report on the decisions made within the ITU, and if the ITU has
determined that the extensions documented here are sufficient for their purposes
then there is no further work required.
It might be useful in the context of this draft for the author to comment on the
process which led to the definition of the extensions described, why they are
deemed sufficient, and what issues remain to be addressed. This would be
beneficial because the IETF readership has, in general, not been party to the
debate within the ITU.
It would be helpful if, for the error codes, there was some indication of the
circumstances under which the codes can be generated and the actions that should
be taken on receipt of a code. For many, the answers are intuitive (which is not
to say that they should not be described) but for others some description is
necessary.
With regard to IANA considerations...
Has the ITU already assigned TLV and error code numbers? (or in the process of
doing so for G.7713.3). If so, I suggest that this draft should indicate those
numbers. If not, are you asking IANA to allocate numbers from within the space
intended for IETF standardization in which case, how is this draft wholly
informational?
Please note that the correct expansion of GMPLS is Generalized Multi-Protocol
Label Switching, and that the correct expansion of CR-LDP is Constraint-based
Routed Label Distribution Protocol.
In section 4.3, "Crankbck" should read "Crankback"
Should the security section reference draft-ietf-mpls-generalized-cr-ldp-07.txt
rather than RFCs 3036 and 3212? After all, this is really a GMPLS not an MPLS
draft.
References should be split as informational and normative.
Should G.7713.3 be listed as a distinct reference (other than G.7713)?
Regards,
Adrian
-----Original Message-----
From: The IESG [mailto:iesg-secretary(_at_)ietf(_dot_)org]
Sent: Tuesday, December 31, 2002 12:40 PM
Subject: CORRECTION: Last Call: CR-LDP Extensions for ASON to
Informational
**PLEASE NOTE THIS IS A TWO WEEK LAST CALL.**
The IESG has received a request to consider CR-LDP Extensions for ASON
<draft-aboulmagd-ccamp-crldp-ason-ext-02.txt> as an Informational RFC.
This has been reviewed in the IETF but is not the product of an IETF
Working Group.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg(_at_)ietf(_dot_)org or ietf(_at_)ietf(_dot_)org mailing lists by 2003-1-15.
Files can be obtained via
http://www.ietf.org/internet-drafts/draft-aboulmagd-ccamp-crldp-ason-ext-02.txt