Re: WG document status

[Kireeti Kompella <kireeti@juniper.net>]

Hi Steve,

On Mon, 25 Feb 2002, Stephen Trowbridge wrote:

> Regarding the WG last call on the documents:
>         draft-ietf-mpls-generalized-cr-ldp-05.txt
>         draft-ietf-mpls-generalized-rsvp-te-06.txt
> Please note that there is a communication statement from ITU-T Q.14/15
> which can be found at: http://www.ietf.org/IESG/LIAISON/ITU-OIF.html
> which is relevant to these drafts. In particular, this statement gives
> four examples of requirements from ITU-T Recommendations G.807/Y.1302,
> G.8080/Y.1304 and G.7713/Y.1704 which are not met by the current versions
> of the drafts.

I had read the statement, but haven't had time to read G.7713.{1,2,3}.
In particular, I haven't read G.7713 (protocol neutral specification),
or the requirements document (or is that just G.7713?)  Is there a
complete list of the requirements that are not met by GMPLS?

> I am aware that it may not be the goal of everyone that these drafts
> meet all of these requirements in the first version. But I think it is
> our long term goal that these protocols and the ITU-T requirements
> converge to the same solution.

Agreed.  Can we meet you halfway? :-)  For example, can we comment
on some of the requirements?  Or are they sacrosanct?

> In light of the communication statement, can we have some discussion
> about the way forward toward this goal? Some possible approaches are:
> - It seems for the moment, WG last call has not completed on another
>   of 4 drafts that are proposed to advance as a set. While we are
>   working to resolve the issues with: draft-ietf-ccamp-gmpls-sonet-sdh-02.txt,
>   is it possible to also address the requirements gaps in these other
>   two drafts?

I'm hoping that the issues with the sonet-sdh draft will be resolved
over the next two-three weeks.  At that point, the set will be ready
for IETF Last Call.

> - If these two drafts are advanced as is to a proposed standard RFC, can
>   the requirement gaps be addressed with one or more new documents which
>   provide only additions, without obsoleting the original RFC?

As far as the given examples go, additions seem sufficient to satisfy
the requirements.  If it turns out that some aspects need to be
reworked, this won't be the first time that RFCs have been superseded
by newer versions.

Kireeti.