Re: הנדון: 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

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.sprecher@nsn.com> 
Sent by: ietf-bounces@ietf.org
13/03/2012 03:09 PM

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