All,
Zhi-Wei is right this is procedural and intentionally so.
I do not criticize "ITU" or people that are active in the ITU for not
following the IETF procedures, especially since there is a big hole in
the procedural framework here.
The only one to blame for the lack in procedure are ourselves :(, but we
can't cry over spilled milk, but need to do something about it.
What I'm saying is that what happened here very acutely demonstrates
this need to document such a procedure.
/Loa
Lin, Zhi-Wei (Zhi) wrote:
Hi Loa,
See comments below...I guess none of these comments are technical, but more
procedural...
-----Original Message-----
From: Loa Andersson [mailto:loa(_at_)pi(_dot_)se]
Sent: Thursday, January 23, 2003 6:59 AM
To: Lin, Zhi-Wei (Zhi)
Cc: Wijnen, Bert (Bert); Scott Bradner (E-mail); 'iesg(_at_)ietf(_dot_)org';
'ietf(_at_)ietf(_dot_)org'; 'kireeti(_at_)juniper(_dot_)net'; 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 +46 739 81 21 64
Email loa(_at_)pi(_dot_)se