All,
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(_dot_)sprecher(_at_)nsn(_dot_)com>
Sent by: ietf-bounces(_at_)ietf(_dot_)org
13/03/2012 03:09 PM
To
"Andrew G. Malis" <agmalis(_at_)gmail(_dot_)com>, "ext Ross Callon"
<rcallon(_at_)juniper(_dot_)net>
cc
ietf(_at_)ietf(_dot_)org
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
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(_at_)ietf(_dot_)org
נושא: 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(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
Andrew G. Malis
Sent: Monday, March 05, 2012 6:54 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: ietf(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf