Implementors Guide not normative?

[Terry L Anderson]

Recommendation A.3 is no longer in affect (status: withdrawn) but Resolution 1 of the
new Study Period WTSA-2000,
    Resolution 1 – Rules of procedure of the ITU Telecommunication Standardization
Sector (ITU-T)
has similar definitions (with a little less detail of process).

9.7 Correction of defects
When a study group identifies the need for implementors to be made aware of defects
(e.g. typographical errors, editorial errors, ambiguities, omissions or
inconsistencies and technical errors) in a Recommendation, one mechanism that may be
employed is an Implementors' Guide. This Guide is an historical document recording all
identified defects and their status of correction, from their identification to final
resolution, and would be issued in the study group's COM series of documents.
Implementors' Guides shall be approved by the study group and made available to the
public.

It is still clear that IGs simply record to correction process and are not themselves
normative corrections.

I agree with Paul that we need to issue a Corrigendum or a new version with the IG's
corrections before they become normative.  We should do this as quickly as legally
possible, which I believe is to prepare something for which "consent" can be approved
at SG16 in Feb 2002 and then approved by AAP a few weeks later.  It seems to me the
large number of changes accumulated to date suggest that a V2 would be alot easier to
use (I believe a Corrigendum would still be published as differences).  Perhaps we
should then have a strategy of issuing Corrigenda periodically for V2 rather than only
IGs.

Paul Long wrote:

> (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

--

------------------------------------------------------------
Terry L Anderson              mailto:tla at lucent.com
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tla.vcf
Type: text/x-vcard
Size: 454 bytes
Desc: Card for Terry L Anderson
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20011010/4fadfbe2/attachment-0004.vcf>