RE: Last Call: CR-LDP Extensions for ASON to Informational

["Lin, Zhi-Wei (Zhi)" <[e-mail]>]

Hi Loa,

See comments below...I guess none of these comments are technical, but more procedural...

-----Original Message-----
From: Loa Andersson [mailto:[e-mail]]
Sent: Thursday, January 23, 2003 6:59 AM
To: Lin, Zhi-Wei (Zhi)
Cc: Wijnen, Bert (Bert); Scott Bradner (E-mail); '[e-mail]';
'[e-mail]'; '[e-mail]'; Lam, Hing-Kam (Kam); Malcolm
Betts (E-mail); Stephen Shew (E-mail); Lyndon Ong (E-mail); Alan McGuire
(E-mail); Trowbridge, Stephen J (Steve)
Subject: Re: Last Call: CR-LDP Extensions for ASON to Informational


All,

taking a step back - I think we are discussing several issues in a mix
that makes it very hard to sort this out.

1. What other organizations may do to IETF (in this context (G)MPLS)
    protocols

    This won't be sorted out in this thread - and the only opinion so far
    is that it is a bad idea to let anyone else change or extend IETF
    protocols.

<zhi>Last time I checked, the IETF didn't change the protocols, individuals did through contributions.  The extensions requested for Call/Connection control were submitted by an individual.  The fact the ITU weighed in requesting approval of the changes is a separate issue.</zhi>


    This will require at statement from involved wg chairs and ADs and an
    approval from the IESG. I will push for such a statement.

2. Have the IETF protocols been changed

    This is is a matter of how "changed" is defined. Clearly the OIF
    UNI signaling spec extends the LDP protocol, message and new TLV.
    This is referenced by a normative reference in the three drafts
    discussed here

       draft-lin-ccamp-gmpls-ason-rsvpte-04.txt
       draft-aboulmagd-ccamp-crldp-ason-ext-02.txt
       draft-bala-uni-ldp-rsvp-extensions-04.txt

    I understand that the IESG wants to treat those as a packet, and that
    the last call on the CR-LDP Extensions for ASON to Informational in
    fact is a last call on all three of them. Further this could be
    construed to be seen as an "last call" on normative references -
    after all normative references are considered to necessary for
    implementing a spec.

    Also, the ITU work extends the IETF protocols, new objects, new TLVs
    and new error codes, that is why the drafts were written - to make it
    possible for IANA to approve the needed code points.

    In our normal use of terms change includes extends, but we should
    probably make that clear.

    The consequence of approving the drafts will be that the extensions
    by OIF and ITU will be approved by the IETF. I'm not sure that this
    has been in the open.

<zhi>This has been presented at the last few IETF ccamp meetings. I don't know how else to make it more clear the intention.</zhi>


    However, not having a change process that relates to these protocols
    I'm not sure if the IESG can do anything else than approving that the
    IANA allocate the code points.

3. The quality of the drafts

    In my opinion (if I were to review them as a wg chair, but I'm not
    sure that those criteria apply to informational documents) we have a
    problem here.

    The draft-lin-ccamp-gmpls-ason-rsvpte-04.txt and the
    draft-bala-uni-ldp-rsvp-extensions-04.txt is an a shape such that I
    would (reluctantly) request publishing.

    But the draft-aboulmagd-ccamp-crldp-ason-ext-02.txt is not, there is
    a long series of points that needs to be updated. References, TLV
    description, un-expanded acronyms, etc. Would have returned this to
    the author for further work. Aside from that I have a couple of
    technical issues.

    Now, if the IESG considers them to be a package, this would effect
    all of them. I guess that it would be possible to weed the draft
    after it has been approved, but it deviates from normal practice.

My belief is that we should try to separate these issues from each
other.

/Loa



-- 
Loa Andersson

Mobile          [phone]
Email           [e-mail]