On the separation of issues, I think that's helpful. On issue 1, I think
that there is definitely precedent on use of IETF protocols by the ITU-T (I
think it was in the OAM area and SG13). SG15's use of GMPLS protocols has
to do with extensions that enable them to fit into the ASON architecture.
I would like to point out that for G.7713.1 (PNNI based ASON signalling),
the ATM Forum has been very helpful in enabling the work and liaising back
to SG15.
-----Original Message-----
From: Loa Andersson [mailto:loa(_at_)pi(_dot_)se]
Sent: Thursday, January 23, 2003 06:59
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); Betts, Malcolm
[SKY:1ID0:EXCH]; Shew, Stephen [SKY:QW33:EXCH]; 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.
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.
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