Implementors Guide not normative?

Paul Long plong at IPDIALOG.COM
Wed Oct 10 00:07:06 EDT 2001


(This is the continuation of a thread from the IETF reflector for RFC 3015,
a.k.a. Megaco, since it really just relates to SG16. Note also that this
thread also applies to H.323, et al.!)

Christian,

After further consultation and research, it appears that you are
correct--the ITU-T IG is _not_ normative and never has been:

ITU-T Recommendation A.3, Amendment 1 states: "2.10.10 implementors' guide:
An implementors' guide is a document which records all identified defects
(e.g. typographical errors, editorial errors, ambiguities, omissions or
inconsistencies, and technical errors) associated with a Recommendation or a
set of Recommendations and their status of correction, from their
identification to final resolution. An implementors' guide is issued by the
ITU-T following agreement by a Study Group. Typically, defect corrections
are first collected in an implementors' guide and, at a time deemed
appropriate by the Study Group, they are used to produce a corrigendum or
are included as revisions to a Recommendation."

So the IG is just a central place to temporarily record for public review
things that
        1. can be published in a corrigendum like the X.691 Corrigenda 1, 2, and 3
or
        2. need to be fixed in the next revision, e.g., H.248v2.

Until the contents of the H.248 IG is rolled into one or the other of these
two ITU-T publications, it has no normative force. The immediate impact is
that H.248v1 is defined solely by the Recommendation, warts and all. Until
and unless an H.248 Corrigendum 1 is Decided, H.248v1 (06/00) is apparently
not implementable. :-) We can work on a Corrigendum for v1 if we want an
implementable v1 or just abandon v1 altogether and choose the second path by
rolling the IG into H.248v2 as soon as possible.

Another possibility for future revisions to H.248 is to add an explicit
"forward reference" to the IG in the Recommendation so that the
Recommendation itself makes the IG normative. Don't know if this'll fly with
the ITU-T, though.

NOTE: It doesn't really matter what "normative" means because that's not at
issue. Use whatever word(s) you want, but the point is that the IG does not
contain requirements, is not a standard, does not actually modify a
Recommendation, and is therefore merely a peripheral, historical artifact of
the standards-making ITU-T process.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: megaco-admin at ietf.org [mailto:megaco-admin at ietf.org]On Behalf Of
Christian Groves
Sent: Tuesday, October 09, 2001 10:40 PM
To: Paul Long
Cc: megaco at ietf.org
Subject: Re: [Megaco] What exactly constitutes Version 1 ?


Paul,

>From my understanding (A series of recommendations) an IG is an
historical document detailing the defect and the steps leading to its
correction. An amendment/corrigenda to a recommendation performs the
actual normative correction. Whilst I think IG is a practical way of
detailing all the changes and has been the accepted method in sg16, the
question is how do non-SG16 groups normatively refer to the IG? Another
issue is that an IG is not translated for non-english speakers. They
need to be able to do the updates too. The status of the IG is probably
best discussed on the SG16 mailing list.

However, if we issue a H248v2 then we don't have the above problems.

Regards, Christian

Paul Long wrote:
>
> Christian,
>
> The IG not normative? Back when H.324 was developed, its IG was definitely
> not normative because it was truly an _implementer's guide_, like the name
> indicates, and not a corregendum, like they are now. It was my
understanding
> that as of H.323, which would now include H.248, "IGs" became normative.
> However, the only thing I can find that says that they are anything close
to
> normative is the statement in the IGs that, "[This document] must be read
in
> conjunction with the Recommendation to serve as an additional authorative
> source of information for implementors."
>
> I've always been told that IGs are normative, that version X of a
> Recommendation is defined by the Recommendation _and_ its corresponding
IG,
> so I suppose it comes down to how you interpret this statement.
> Unfortunately, the Recommendations themselves do not make any reference to
> their corresponding IG.
>
> Finally, I believe that it is the concensus that the IG is normative,
based
> on the statement I cited, above.
>
> Paul Long
> ipDialog, Inc.
>
> -----Original Message-----
> From: megaco-admin at ietf.org [mailto:megaco-admin at ietf.org]On Behalf Of
> Christian Groves
> Sent: Tuesday, October 09, 2001 8:03 PM
> To: 'megaco at ietf.org'
> Subject: Re: [Megaco] What exactly constitutes Version 1 ?
>
> What is the problem to limit features? The whole idea of the list and
> contributions to SG16 is that proposals are presented, discussed and
> accepted or not. It is this step that weeds out the harmful ideas. So I
> don't buy that emotional argument.
>
> I don't agree that the implementors' guide just fixed a few bugs. Look
> at the size of it now and it doesn't fix all problems ie. exceeding
> message sizes. It has become unwieldly to use the original spec. We need
> something that other standards bodies can reference. An implementors'
> guide isn't normative.
>
> As for the new features they are fixing things that are needed in real
> systems and its because of experience that they've been added. ie.
> Individual auditing so that you don't blow out the message size on the
> reply, procedures to handle the case where a reply message will exceed
> message size, having all descriptors being extended by packages so you
> can introduce new features without protocol updates.
>
> I don't think that because of the state (or lack of it) of individual
> companies implementations that this should prevent the standard from
> moving forward.
>
> Cheers, Christian

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com



More information about the sg16-avd mailing list