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

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 21 Mar 2000 08:50:12 -0500

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
>

---

From: Michael Brown <[email-masked]>
Date: Tue, 21 Mar 2000 11:10:30 -0500

I also disagree with the initially posted assessment that the protocol is
incomplete and unimplementable. I can confirm that the recent changes have
indeed resulted in only very minor changes to implementation. I don't think
there is anything else to add to Brian's description of the way forward and
completely agree with his assertion that the RFC and the erratum will indeed
provide a clear and stable basis for the protocol.

Michael Brown

---

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

G'Day all,

I agree with Brian on this. The protocol is stable.
The things that concern us currently are minor errors. If identified
these should be fixed. Other clarifications can be in an implementor's
guide or clarified in version 2 of the protocol. What is currently in
H248 is more than sufficient to implement against.

Regards, Christian

---

From: Pekka Pessi <[email-masked]>
Date: Wed, 22 Mar 2000 16:42:03 +0200

>I disagree with your assessment of the state of the protocol.

        Personally, I don't think that the protocol has really stabilized
        yet.

        Also, it is reasonable to expect that a new protocol specification
        contains a lot of minor errors, omissions, and other lossage.  These
        errors will be found when 1) someone actually implements the
        protocol and 2) someone tries to get two independent implementations
        to interwork with each other.  We have not done either. Sometimes
        the fixes can be done in a compatible way, sometimes not.

>unusual circumstances.

        Or proposals to change ABNF, or ASN.1.

>In no case, AFAIK, would any of the changes
>addition.

        Existing implementations?

>There are no plans for any major changes to syntax,

        Sorry. In ASN.1 parlance, "transport syntax" means the encoded stuff
        that goes on the wire. I meant both the ASN.1/BER and ABNF stuff.

>If it needs to be changed, we will have to have a new RFC.

        When I browse the current spec, I think it is clear that we need an
        implementors' guide.

        In order to make this project successful in longer terms, I also
        think it is essentatial to clarify the rules according which the
        protocol will be updated and errata published. In ITU-T, a
        implementors' guide will usually be decided and published
        subsequently. It usually updates the basic version, in this case,
        version 1. (I don't think it is a good practice to update protocols
        without bumping the version number, but people in ITU seem to think
        otherwise.)

        How we do this in IETF? Do we publish the implementors' guide as
        another RFC, or do we replace the existing RFC with another? When we
        publish IG?  How the work towards it is organized?

        I think that this is something that should be discussed with Tom.

        Best regards,
                                        Pekka Pessi