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@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of Christian Groves Sent: Tuesday, October 09, 2001 10:40 PM To: Paul Long Cc: megaco@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@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of Christian Groves Sent: Tuesday, October 09, 2001 8:03 PM To: 'megaco@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@mailbag.intel.com
--
------------------------------------------------------------ Terry L Anderson mailto:tla@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