Two points to consider:
1) Below it is stated:
"In the future, all codepoint allocations to the ITU-T should be tied to one specific, dated revision of their specification only. This is similar to the ITU-T's own processes, such as section 2.2.1 of Rec. A.5, which requires a version number and/or date for referenced outside documents in ITU-T recommendations."
However, this is not the complete picture of the ITU process. Section 2.2 of Recommendation A.5 defines the information that must be provided when the inclusion of a normative reference is under consideration. The Authors guide requires that the following text is inserted into the References section of all ITU-T Recommendations:
"The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below."
Thus in the ITU the latest version of a referenced document is always considered.
2) Section 2 of draft-betts “Scope of the Ethernet based OAM ACH Type” restricts the use of the code point to the OAM messages necessary to meet the functional requirements of RFC 5860:
“The code point allocated by this document is intended to be used only for Ethernet based OAM messages, defined in the ITU-T Recommendation [G.8113.1], carried in the G-ACh . These Ethernet based OAM messages and procedures, address the OAM functional requirements defined in [RFC5860]. Other message types should not be carried behind this code point.”
Further only interfaces that support G.8113.1 OAM will act on these OAM messages, any interface that does not support this G-ACh type will discard these OAM messages as defined in RFC5586.
Also as stated in the last paragraph of section 2:
“All ITU-T Recommendations are subject to revisions. Therefore, the code point allocated by this document may be used for future versions of [G.8113.1].”
The intention of this statement is to bring to the attention of the IETF the normal practice in the ITU of developing amendments to Recommendations to fully meet the functional requirements (e.g. adding pro-active loss measurement). Normally any reference to ITU-T Rec G.8113.1 will automatically be directed to the current version (including any amendments).
Russ stated in https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=62185&tid=1331648664:
“Some people are using the lack of a code point as the reason that the cannot support the ITU-T document. My approach tells the ITU-T that a code point is available to them IFF they are able to reach consensus. The removes IETF from the discussion. This creates a situation where G.8113.1 succeeded or fails based on the ITU-T members actions, with no finger pointing at the IETF. This is completely a Layer 9 consideration, and it has noting to do with the technical content of the document.”
Restricting the application of the code point to a specific version of Recommendation G.8113.1 would require the ITU to deviate from its normal process for enhancing Recommendations and would put the IETF back into the discussion for approval.
Regards,
Malcolm
| "Sprecher, Nurit (NSN
- IL/Hod HaSharon)" <nurit.sprecher@xxxxxxx>
Sent by: ietf-bounces@xxxxxxxx 13/03/2012 03:09 PM |
|
Ross,
i am afraid that you missed the point. There will not be a final version since as written in draft-betts, all ITU recommendations are subject to revisions, and the code point will also be used for future revisions of the document. New messages/protocols can be defined in future revisions of the recommendation and they will use the same code point that is allocated for the first version.
This is a real issue.
Regards,
Nurit
-----הודעה מקורית-----
מאת: ext Ross Callon
נשלח: 13/03/2012, 19:27
אל: Andrew G. Malis; Sprecher, Nurit (NSN - IL/Hod HaSharon)
עותק: ietf@xxxxxxxx
נושא: RE: Last Call:<draft-betts-itu-oam-ach-code-point-03.txt>(Allocationof an Associated Channel Code Point for Use byITU-T Ethernetbased OAM) to Informational RFC
I agree that the allocation of a code point should be to a specific version of 8113.1, and specifically should be to the final version that is approved by the ITU-T (assuming that a final version of 8113.1 will be approved by the ITU-T). This would imply that draft-betts-itu-oam-ach-code-point should contain a normative reference to the final approved version of 8113.1.
Given normal IETF processes, this implies that the final RFC resulting from draft-betts-itu-oam-ach-code-point could be published as soon as the final version of 8113.1 is approved (with the understanding that there will be a small normal delay between "approved" and "published" which gives time for coordination). Given that the final version of 8113.1 might need to reference the RFC resulting from draft-betts-itu-oam-ach-code-point, a bit of cooperation might be needed between editorial staff at the ITU and RFC editorial staff, but I don't see why this should be a problem (I am sure that they all have access to email).
Ross
-----Original Message-----
From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Andrew G. Malis
Sent: Monday, March 05, 2012 6:54 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: ietf@xxxxxxxx
Subject: Re: Last Call: <draft-betts-itu-oam-ach-code-point-03.txt>(Allocationof an Associated Channel Code Point for Use byITU-T Ethernetbased OAM) to Informational RFC
I would like to support Nurit's comments below. In particular, in the
past the ITU-T has expanded upon or changed the usage of IETF
codepoint allocations, in some cases incompatibly with its original
usage or definition. In the future, all codepoint allocations to the
ITU-T should be tied to one specific, dated revision of their
specification only. This is similar to the ITU-T's own processes, such
as section 2.2.1 of Rec. A.5, which requires a version number and/or
date for referenced outside documents in ITU-T recommendations.
Cheers,
Andy
>----------------------------Snip
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf