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@ietf.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@ietf.org or ietf@ietf.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