I can reaffirm Zhi's comment that call and connection separation
goes back to G.8080, an already approved ITU specification of
the G.ASON architecture.
I'm a bit puzzled by the argument that no one but IETF should be
allowed to extend an IETF protocol - I would think that extensions
are generally allowed if they don't cause a limitation on
the available codepoints and are documented to allow people
to use them. Aren't some codepoint
partitions designed for people to do this, without having to
force all extension work through a WG?
Also, I would think that approving the drafts is just that,
approving the drafts and their contents as Informational
documents, it is not being asked that these become IETF Standards.
From: Loa Andersson [mailto:loa(_at_)pi(_dot_)se]
Sent: Thursday, January 23, 2003 3: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
Betts (E-mail); Stephen Shew (E-mail); Ong, Lyndon; Alan McGuire
(E-mail); Trowbridge, Stephen J (Steve)
Subject: Re: Last Call: CR-LDP Extensions for ASON to Informational
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)
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
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
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
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
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
Mobile +46 739 81 21 64