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

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 22 Mar 2000 10:04:30 -0500

There are several implementations underway that I know of.
There is one group planning to release a version as a
reference version.
There are quite a few people who have build, and maintained
parsers.

When we pass IESG last call, the protocol will be published as
"Proposed Standard".  That is not a final specification.  It
is intended that further testing and specifically interoperability
testing be performed.  Reports of such testing must be offered
before it can be advanced.  It is very common that a new RFC is
issued prior to advancing a "Proposed Standard".

There have been some proposals to change the ASN.1 and/or ABNF.
In most cases the changes are need to align one with the other.
In some cases the changes are proposed to clear up ambiguity between
what the text says, or intended, and what the ABNF/ASN.1 actually
did.  These changes, so far, have been very minor, and there
are only a couple of them.

I think an "Implementers Guide" is just that - information that
would help an implementer create a new implementation that will
interwork with others.  Sometimes, an example is helpful,
sometimes more text is helpful.  Reports of problem areas others
have encountered, etc.  In my way of thinking, Implementers
Guides should not change the protocol.  That takes a new RFC.

Brian

> -----Original Message-----
> From: Pekka Pessi [mailto:[email-masked]]
> Sent: Wednesday, March 22, 2000 9:42 AM
> To: Rosen, Brian
> Cc: [email-masked]
> Subject: RE: Proposal: explain MEGACO protocol RFC status explicitly
>
>
> Rosen, Brian <[email-masked]> writes:
> >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.
>
> >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.
>
>       Or proposals to change ABNF, or ASN.1.
>
> >In no case, AFAIK, would any of the changes
> >invalidate any existing implementation by more than a very minor
> >addition.
>
>       Existing implementations?
>
> >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.
>
>       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.
>
> >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.
>
>       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
>