Subject: Re: Proposal: explain MEGACO protocol RFC status explicitly

From: Chip Sharp <[email-masked]>
Date: Tue, 21 Mar 2000 12:02:51 -0800

As a further clarification, independent of any judgement on megaco/H.248 in
particular, publication of any RFC as Proposed Standard is really a
snapshot of the development of the protocol.  At the point of publication
of the RFC as Proposed Standard, the protocol is considered stable enough
to begin implementation, perform interoperability tests and perhaps get
some deployment experience (not necessarily in production networks).

If during this process, problems are found in the protocol and corrections
are needed, a new RFC can be published with the corrections while still
remaining in Proposed Standard state.

There is no requirement to implement an I-D before it moves to Proposed
Standard.  Sometimes this is done and it definitely helps to get this
experience to learn the ins and outs as the protocol is developed, but it
is not required.

As far as megaco/H.248 is concerned, I do believe something like
implementer's agreements (or profiles) will have to be worked out for
interoperability reasons for specific applications since there are so many
options and different ways of doing the same thing.   Although there are
details we all don't agree on, the IP Phone profile is one attempt at doing
this for an IP Phone application.

One thing to keep in mind is that before megaco can move to Draft Standard
in IETF, all options that don't have multiple interoperable implementations
have to be removed.

Chip

At 08:50 AM 3/21/00 -0500, Rosen, Brian wrote:
>I disagree with your assessment of the state of the protocol.
>
>While there have been a series of text change proposals made
>in the last few weeks, all of them have either been requests
>to clear up language, or proposals to fix some minor errors for
>unusual circumstances.  In no case, AFAIK, would any of the changes
>invalidate any existing implementation by more than a very minor
>addition.  There are no plans for any major changes to syntax,
>and no changes at all to semantics, unless you consider clarification
>of intent to be a semantic change.  I don't understand the "transport
>syntax" part at all, unless you are thinking about the ITU work
>on ATM transport and SCTP annexes, which will not carry through to the
>IETF version on present plans.
>
>There will be an erratum published with the RFC.  Together, they
>should provide a stable basis for the protocol.  The document is large.
>In any such document, there are things that could use more explanation.
>While an implementor's guide has been discussed, it has not yet
>been decided if we will need one.  I suspect we will.  The guide will
>not, if I have anything to do with it, change the protocol at all.
>If it needs to be changed, we will have to have a new RFC.
>
>Brian
>
> > -----Original Message-----
> > From: Pekka Pessi [mailto:[email-masked]]
> > Sent: Tuesday, March 21, 2000 8:35 AM
> > To: [email-masked]
> > Subject: Proposal: explain MEGACO protocol RFC status explicitly
> >
> >
> >         Hello all,
> >
> >         The current MEGACO/H.248 draft,
> > draft-ietf-megaco-protocol-07.txt,
> >         is still ongoing work. AFAIK the protocol is still
> > incomplete and
> >         largely unimplementable. A reference implementation
> > has just been
> >         started.  The working group is planning to change the protocol
> >         semantics and transport syntax. There would be no point in
> >         publishing the document as an RFC, if this were an
> > IETF-only project
> >
> >         As I have understood, publishing incomplete recommendations is
> >         business as usual in ITU-T due to practical reasons. The ITU-T
> >         recommendations must be approved using time-consuming formal
> >         process, including a ballot. So, the finalized ITU-T
> > specification
> >         actually consists of a recommendation document
> > together with an
> >         Implementor's Guide correcting the errors and omissions in the
> >         recommendation document. IG may contain major changes that are
> >         incompatible with the published recommendation
> > document.  Also, when
> >         referring to a ITU-T specification, like H.323v2, people are
> >         actually referring to the recommendation together with the
> >         respective implementor's guide.
> >
> >         The ITU-T process is (or at least should be) familiar to the
> >         developers using ITU-T recommendations. However, in Internet
> >         community people are expecting that the RFC is not
> > just a snapshot
> >         of an on-going work. They don't anticipate that there
> > is a companion
> >         document possibly changing the base protocol in every turn.
> >
> > Proposal
> >
> >         I propose that the MEGACO RFC should contain a
> > paragraph explaining
> >         the status of the text, ie. that the protocol will be
> > changed by an
> >         Implementors' Guide published soon. The MEGACO RFC should also
> >         recommend that any reference to it must also be
> > accompanied with a
> >         note explaining the status of the RFC, and a reference to the
> >         Implementors' Guide.
> >
> >         Best regards,
> >                                         Pekka Pesi
> >

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------

---

From: Christian Groves <[email-masked]>
Date: Wed, 22 Mar 2000 14:26:56 +1100

G'Day all,

Chip raises an interesting issue of interoperability tests. The current
plans for such testing seems to me to be ambiguous at best.

Due to the generic nature of Megaco it seems to me to be quite difficult
to test. From what I have seen (please correct me if this isn't the
case) is that Megaco/H248 is planned to be tested as part of a larger
application test. ie. trunking gateway, IP phone etc. This to me seems a
lot of overhead just to test the megaco protocol. It also seems to put
certain players of the interop test. ie. if I make SIP GW which have
h248 but the interop test covers IP phones how do I get my Megaco stack
tested???

Are there any initiatives where something similar to the following
approach is taken? Do people see merit in this?
o The test is a test of the protocol mechanisms.
o Test between 2 boxes (PCs, workstations etc) that implement H248 with
the necessary SW to drive the test. These boxes would be application
agnostic.
o A test package could be developed with "dummy" properties, events,
signals etc.
o A test case document which lists test cases for a good coverage test
of Megaco. These test cases could describe what should occur at dummy
event detection.

The aim of the approach is an interop where people who intend to
implement Megaco but not in one of the proposed applications can test
there stacks without having to implement an entire application.

If anyone has any information of the current status of Megaco interops
can they please share it on the list.

Cheers, Christian