(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
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
Terry,
Or we could just maintain the status quo by all agreeing with a wink ;-) that IGs _are_ normative regardless of what Resolution 1 says.
Paul Long ipDialog, Inc.
-----Original Message----- From: Terry L Anderson [mailto:tla@lucent.com] Sent: Wednesday, October 10, 2001 10:11 AM To: Paul Long Cc: ITU-SG16@mailbag.cps.INTEL.COM Subject: Re: Implementors Guide not normative?
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.
[snip]
--
------------------------------------------------------------ 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
True! Since most of us thought it always was. But it might be better to fix our process properly.
Q.14/16 folks seem to use "Amendments". T.38 for example, has Ammendments 1,2,3 & 4 approved. These contain additional Annexes as well as modifications to T.38, often using language little different from our IG. Perhaps, our IG could be simply converted into an Amendment periodically and approved. (Actually it would need to be split into separate amendments for each recommendation). These would need to follow AAP rules for approval rather than simply being approved at a SG meeting. Amendments are supposes to be limited to no more often than every two years (like new versions), but there is an exception for minor purely editorial changes or corrections due to an "oversight", so I think we would have no restrictions on the changes we have been putting into IGs.
A.11 states that "Minor modifications may be covered by publishing amendments or corrigenda rather than reissuing the complete Recommendation."
I cannot find a defined difference between "amendments" and "corrigenda".
Paul Long wrote:
Terry,
Or we could just maintain the status quo by all agreeing with a wink ;-) that IGs _are_ normative regardless of what Resolution 1 says.
Paul Long ipDialog, Inc.
-----Original Message----- From: Terry L Anderson [mailto:tla@lucent.com] Sent: Wednesday, October 10, 2001 10:11 AM To: Paul Long Cc: ITU-SG16@mailbag.cps.INTEL.COM Subject: Re: Implementors Guide not normative?
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.
[snip]
--
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
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
Dear Paul, Terry,
Amendments are applicable only to Common Text between ISO and ITU. Regular ITU Recommendations receive Corrigenda.
Formally, IGs have a lower status than a Recommendation. However, as mentioned before in this thread, IGs have been treated by the community that uses them as having the same status, in the *practical* sense. After all, the fundamental aspect is the stability of the change, and the use of IGs has allowed the work to progress more efficiently and consistently documenting the problems, than it would had been through the formal Rec. approval cycle. Of course, this is the treatment of IGs in SG 16 and, as pointed out before, does not need to be uniform across SGs. The issue of issuing corrigenda or not, or reissuing the Rec. in a new version is a common-sense decision based on the significance and extension of the corrections/modifications. Ideally, however, between version n and version n+1 the TSB would like that a period not shorter than 2 years be elapsed. This rule would not apply to Corrigenda. Please note also that while IGs are approved at a SG meeting, Corrigenda and revisions to Recs. are generally approved through the AAP in SG 16 (the TAP is only for regulatory-type recs, which seldom occur in SG 16), i.e., Consent at a SG or WP meeting, Last Call, etc.
If H.248V1+IGs is difficult to use due to the accumulated changes, maybe it is time for V2. It is the Rapporteur's group call. In this particular case, though, where we have parallel publication with the IETF, this republication has to be very carefully coordinated, probably leading to a different RFC number on the IETF side, with a quasi-synchronization of the approval process. As a matter of fact, all the IGs should also be made available to the IETF, maybe as draft-....txt (maybe it is already done, I confess I am not following up that thread).
I hope this helps.
BR, Simão.
G'Day,
Personally as I've mentioned in previous meetings I would support the approval of v2 to bring in the changes from the IGs. I feel that a 80 page corrigenda to a 134pg H.248v1 isn't very practical. It will also help interoperability if you receive a v2 message then you know exactly to expect. At previous interops different groups have implemented different IG versions.
With regards to the 2 year guideline it would be 20 months between the decision and the consent date for the recommendation. By the time the consent period is finished and the recommendation is published it would be very close to 2 years. We have had other recommendations in SG16 which have not aligned to the 2 year guideline.
Regards, Christian
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Christian,
Since the IG is not normative on H.248v1 (or any other "v" for that matter), and v1 is not interoperable and possible not even implementable without it (correct me if I'm wrong), it seems like we have two alternatives:
1. Move forward with v2 ASAP and hope that absolutely _nobody_ deploys a v1 entity. (If it were a true v1-compliant entity, it would be broken because v1 is broken; if it were a v1+IG entity, it wouldn't be v1-compliant.) 2. Produce a v1 Corrigendum so that a v1 entity is viable.
Paul Long ipDialog, Inc.
-----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@mailbag.cps.INTEL.COM]On Behalf Of Christian Groves Sent: Wednesday, October 10, 2001 8:39 PM To: ITU-SG16@mailbag.cps.INTEL.COM Subject: Re: Implementors Guide not normative?
G'Day,
Personally as I've mentioned in previous meetings I would support the approval of v2 to bring in the changes from the IGs. I feel that a 80 page corrigenda to a 134pg H.248v1 isn't very practical. It will also help interoperability if you receive a v2 message then you know exactly to expect. At previous interops different groups have implemented different IG versions.
With regards to the 2 year guideline it would be 20 months between the decision and the consent date for the recommendation. By the time the consent period is finished and the recommendation is published it would be very close to 2 years. We have had other recommendations in SG16 which have not aligned to the 2 year guideline.
Regards, Christian
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Colleagues,
It's looking to me like the best way to capture the H.248 implementer's guide is to issue in February an H.248 V2 that is at least V1+IG. Rather than argue abstractly about what else might be in V2, I thought I'd list the post-V1 proposals that have been accepted so far:
APC-1911: Change of Capabilities indicated in H.248 ServiceChange ( ftp://standard.pictel.com/avc-site/till_0012/0008_Por/APC-1911.zip )
APC-1913: Improved Auditing in H.248 Version 2 ( ftp://standard.pictel.com/avc-site/till_0012/0008_Por/APC-1913.zip )
APC-2002: Signal on Root for H248v2 ( ftp://standard.pictel.com/avc-site/till_0012/0011_Gen/APC-2002.zip )
AVD-2068: Improved Auditing in H.248 Version 2 [amends APC-1913] ( ftp://standard.pictel.com/avc-site/0103_Lau/AVD-2068.zip )
D93: Handling of multiple pending transactions in H.248 ( ftp://standard.pictel.com/avc-site/0105_Por/TD-xxx_Transaction_Pending.zip )
D129: Extendable Context Properties for H.248 v2 ( ftp://standard.pictel.com/avc-site/0105_Por/DC-xxx_Context_Property_v2.zip )
So, that's 5 proposals (note that AVD-2068 amends, or replaces, APC-1913). Please take this information into consideration when you form an opinion about what should be in V2 and the timing of V2. AVD-2131 for the Dublin meeting ( ftp://standard.pictel.com/avc-site/0110_Dub/AVD-2131.zip ) shows V1 + IG + the accepted proposals listed above. Marcello Pantaleo (your friendly H.248 editor) is also creating a document that would show V1 + IG.
Regards, Glen
Christian Groves wrote:
G'Day,
Personally as I've mentioned in previous meetings I would support the approval of v2 to bring in the changes from the IGs. I feel that a 80 page corrigenda to a 134pg H.248v1 isn't very practical. It will also help interoperability if you receive a v2 message then you know exactly to expect. At previous interops different groups have implemented different IG versions.
With regards to the 2 year guideline it would be 20 months between the decision and the consent date for the recommendation. By the time the consent period is finished and the recommendation is published it would be very close to 2 years. We have had other recommendations in SG16 which have not aligned to the 2 year guideline.
Regards, Christian
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
G'Day Glen,
Thanks for listing the proposals I think it goes some way to clarifying what H.248v2 is. I also note that there are 3 proposals for the Dublin meeting to H.248v2 these are: AVD-2120 :Auditing Context Properties (ftp://standard.pictel.com/avc-site/0110_Dub/AVD-2120.zip) AVD-2122 :H.248v2 Profile Handling (ftp://standard.pictel.com/avc-site/0110_Dub/AVD-2122.zip) AVD-2124 :Additions to the H.248 Multiplex Descriptor (ftp://standard.pictel.com/avc-site/0110_Dub/AVD-2124.zip)
Regards, Christian
Glen Freundlich wrote:
Colleagues,
It's looking to me like the best way to capture the H.248 implementer's guide is to issue in February an H.248 V2 that is at least V1+IG. Rather than argue abstractly about what else might be in V2, I thought I'd list the post-V1 proposals that have been accepted so far:
APC-1911: Change of Capabilities indicated in H.248 ServiceChange ( ftp://standard.pictel.com/avc-site/till_0012/0008_Por/APC-1911.zip )
APC-1913: Improved Auditing in H.248 Version 2 ( ftp://standard.pictel.com/avc-site/till_0012/0008_Por/APC-1913.zip )
APC-2002: Signal on Root for H248v2 ( ftp://standard.pictel.com/avc-site/till_0012/0011_Gen/APC-2002.zip )
AVD-2068: Improved Auditing in H.248 Version 2 [amends APC-1913] ( ftp://standard.pictel.com/avc-site/0103_Lau/AVD-2068.zip )
D93: Handling of multiple pending transactions in H.248 ( ftp://standard.pictel.com/avc-site/0105_Por/TD-xxx_Transaction_Pending.zip )
D129: Extendable Context Properties for H.248 v2 ( ftp://standard.pictel.com/avc-site/0105_Por/DC-xxx_Context_Property_v2.zip )
So, that's 5 proposals (note that AVD-2068 amends, or replaces, APC-1913). Please take this information into consideration when you form an opinion about what should be in V2 and the timing of V2. AVD-2131 for the Dublin meeting ( ftp://standard.pictel.com/avc-site/0110_Dub/AVD-2131.zip ) shows V1 + IG + the accepted proposals listed above. Marcello Pantaleo (your friendly H.248 editor) is also creating a document that would show V1 + IG.
Regards, Glen
Christian Groves wrote:
G'Day,
Personally as I've mentioned in previous meetings I would support the approval of v2 to bring in the changes from the IGs. I feel that a 80 page corrigenda to a 134pg H.248v1 isn't very practical. It will also help interoperability if you receive a v2 message then you know exactly to expect. At previous interops different groups have implemented different IG versions.
With regards to the 2 year guideline it would be 20 months between the decision and the consent date for the recommendation. By the time the consent period is finished and the recommendation is published it would be very close to 2 years. We have had other recommendations in SG16 which have not aligned to the 2 year guideline.
Regards, Christian
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (5)
-
Christian Groves -
Glen Freundlich -
Paul Long -
Simao Campos-Neto -
Terry L Anderson