Subject: Re: RFC 3015 & Draft Megaco Agenda

From: "Taylor, Tom-PT [NORSE:B901:EXCH]" <[email-masked]>
Date: Tue, 5 Dec 2000 17:29:00 -0500

Hi.

> -----Original Message-----
> From: Troy Cauble [mailto:[email-masked]]
> Sent: Tuesday, December 05, 2000 11:24 AM
...
>
> Please excuse me for not keeping up, but I have several questions
> on the state of H.248/Megaco in the two standards bodies.
>
> I understand that RFC 3015 obsoletes 2885 and 2886.  Does it have
> ONLY the information in those documents or does it contain some
> of the issues resolved in this list?  (Like those in the ITU-T
> Implementor's Guide.)

[PTT] RFC 3015 contains ONLY the information in 2885 and 2886.

>
> Is the Implementor's Guide considered "done", or is it still a
> living document?

It is a living document.

>
> I've primarily been working from the ITU-T documents, mainly
> because the IG was a living document and RFC 2886 was written
> in August.  Are the two protocols still in synch?
> Does the 6/00 ITU-T doc plus the IG cover everything in
> RFCs 2885 and 2886?  Everything in 3015?

[PTT]
The IG is additional to the RFC.  BTW, August is the publication date of
2886, but it was actually written last spring.  Here is the key equation:
 2885 + 2886 = 3015 = H.248 (June 2000)
The Implementor's Guide captures corrections and clarifications made since
last June's Decision.  It is accepted by both the ITU-T and the IETF, even
though the IETF doesn't usually have Implementor's Guides as such.

>
>
> Also, some of the comments in the "Draft Megaco Agenda" thread
> make me think you're close to shutting down the working group.
> IMO there are still some significant under specified portions
> of the protocol, particularly in the ASN.1 encoding.  Does the
> Megaco working group think the protocol is "done"?

[PTT]
IETF Working Groups are established with charters.  Except for the MIB, we
have fulfilled ours.  The IESG has to decide whether we should be
rechartered to continue the work, or whether we should continue informally
on the list with SG 16 the only formal mechanism for update.  You should be
aware that RFCs don't have to originate from Working Groups, so we can
continue to ask the IESG to approve Megaco-related RFCs and back up our
requests with the statement that there is consensus on the Megaco discussion
list (still 1100-plus people!) when that statement applies.

BTW, in response to Brian's earlier note, Scott says it is OK to have a
rechartering discussion but there are no guarantees the IESG will act on it.
One reason why they might not is because our heavily-loaded ADs need to turn
their attention elsewhere and figure that Megaco is working without their
formal support.

> -troy

---

From: Tom Taylor <[email-masked]>
Date: Wed, 6 Dec 2000 10:15:39 -0500

The basic equation is
RFC 2885 + RFC 2886 = H.248 (June 2000) = RFC 3015.

There seems to be some back and forth in our views of how the Implementor's Guide should be published.  I'm willing to create
either a brief I-D which just has a pointer to the IG on the ITU site, or else a full-fledged I-D reproducing the entire content.  There
is also the issue of officially approved vs. interim content; they should be documented separately so people know they are taking a
slight risk by acting on the interim material.  The obvious answer is to take the officially approved versions forward to RFC status.

Note that the ITU does not charge for Implementor's Guides.

As for H.248v2, it seems reasonable that people should want to discuss the possibilities on the list, and I can take responsibility for
feeding the material forward to SG 16.  Procedurally it would go in as an ISOC contribution if Scott agrees, or else as a Nortel
contribution.  I should remind people that ITU-T practice is to develop protocols incrementally.  That is, H.248v2 would not
normally deprecate any of the content of H.248v1, and H.248v1 and H.248v2 implementations should be able to interoperate.
Corrections documented in the Implementor's Guide would be assimilated into H.248v2.  One final point: absent pressing need,
ITU-T rules call for at least a two year gap between versions.  SG 16 hasn't let this rule get in the way of further development in
the past.

Tom Taylor