R: הנדון: 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
Dear all, Wrt draft-betts, I believe it is appropriate to allocate a code point for the referenced specification without any restriction about the possibility to evolve messages/protocols when compatibility is preserved. It is not only unnecessary but it does not help in improving the relationship between the two SDOs. Best regards, Alessandro -- Telecom Italia Alessandro Gerardo D'Alessandro Transport Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 -Messaggio originale- Da: t.petch [mailto:daedu...@btconnect.com] Inviato: mercoledì 14 marzo 2012 11:56 A: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Ross Callon Cc: ietf@ietf.org Oggetto: 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 - Original Message - From: Sprecher, Nurit (NSN - IL/Hod HaSharon) nurit.sprec...@nsn.com To: Andrew G. Malis agma...@gmail.com; ext Ross Callon rcal...@juniper.net Cc: ietf@ietf.org Sent: Tuesday, March 13, 2012 8:09 PM 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, tp Why? I can understand a new code point being required if there is a new and backwards incompatible format for the messages, but if the messages are extended in a forwards compatible manner, adding new TLV for example, or a new format of IF_ID, then why should we burn a new code point? Would you say that we should have a dozen different port numbers for HTTP to reflect its evolution over time? If not, why not? Demanding that the ITU-T come back to us for a new round of negotiation when it is technically unnecessary seems to be placing an unnecessary barrier between the two SDOs. Tom Petch 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-boun...@ietf.org [mailto:ietf-boun...@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 On Thu, Mar 1, 2012 at 7:20 AM, Sprecher, Nurit (NSN - IL/Hod HaSharon) nurit.sprec...@nsn.com wrote: Hi, I cannot support the publication of the document in its current version. I have the following concerns: .It is indicated that the channel is intended to be used to carry
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
Considering that the need for this code point is a result of the ITU not fully complying with the IETF agreement, I cannot agree that we should simply allocate a code point for whatever the ITU wants to do in the future. It seems the best of the options to allocate a code point (much better than squatting) - but tie it to a stable reference. If the ITU can't provide a stable reference, then perhaps an RFC is the best way. There are lots of folks with opinions on the best procedure, but I certainly don't support the idea of not restricting the usage to what is clearly defined. Alia On Wed, Mar 21, 2012 at 11:04 AM, D'Alessandro Alessandro Gerardo alessandro.dalessan...@telecomitalia.it wrote: Dear all, Wrt draft-betts, I believe it is appropriate to allocate a code point for the referenced specification without any restriction about the possibility to evolve messages/protocols when compatibility is preserved. It is not only unnecessary but it does not help in improving the relationship between the two SDOs. Best regards, Alessandro -- Telecom Italia Alessandro Gerardo D'Alessandro Transport Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 -Messaggio originale- Da: t.petch [mailto:daedu...@btconnect.com] Inviato: mercoledì 14 marzo 2012 11:56 A: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Ross Callon Cc: ietf@ietf.org Oggetto: 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 - Original Message - From: Sprecher, Nurit (NSN - IL/Hod HaSharon) nurit.sprec...@nsn.com To: Andrew G. Malis agma...@gmail.com; ext Ross Callon rcal...@juniper.net Cc: ietf@ietf.org Sent: Tuesday, March 13, 2012 8:09 PM 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, tp Why? I can understand a new code point being required if there is a new and backwards incompatible format for the messages, but if the messages are extended in a forwards compatible manner, adding new TLV for example, or a new format of IF_ID, then why should we burn a new code point? Would you say that we should have a dozen different port numbers for HTTP to reflect its evolution over time? If not, why not? Demanding that the ITU-T come back to us for a new round of negotiation when it is technically unnecessary seems to be placing an unnecessary barrier between the two SDOs. Tom Petch 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-boun...@ietf.org [mailto:ietf-boun...@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
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=6rid=49gid=0k1=933k2=62185tid=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.sprec...@nsn.com Sent by: ietf-boun...@ietf.org 13/03/2012 03:09 PM To Andrew G. Malis agma...@gmail.com, ext Ross Callon rcal...@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
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
Nurit, Section 2 “Scope of the Ethernet based OAM ACH Type” contains the following text: 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. The restrictions on the future use of the code point could be made more explicit by modifying the text as follows: The code point allocated by this document should only be used for Ethernet based OAM messages, defined in the ITU-T Recommendation [G.8113.1], carried in the G-ACh. The messages and procedures carried behind this code point, are restricted to only those that the address the OAM functional requirements defined in [RFC5860]. Other message types should not be carried behind this code point. I hope that this addresses your concern. Regards, Malcolm Sprecher, Nurit (NSN - IL/Hod HaSharon) nurit.sprec...@nsn.com 14/03/2012 06:43 AM To Sprecher, Nurit (NSN - IL/Hod HaSharon) nurit.sprec...@nsn.com, Andrew G. Malis agma...@gmail.com, ext Ross Callon rcal...@juniper.net, malcolm.be...@zte.com.cn cc ietf@ietf.org Subject 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 Malcolm, As mentioned before, I cannot support the publication of the current version of draft-betts...it must be revised first to address the concerns I and others raised on the list. Maybe you could clarify how the text in your draft can be improved to protect the use of the code point from future extensions beyond the purpose of the code point allocation? Best regards, Nurit -snip ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
Malcolm, As mentioned before, I cannot support the publication of the current version of draft-betts...it must be revised first to address the concerns I and others raised on the list. Maybe you could clarify how the text in your draft can be improved to protect the use of the code point from future extensions beyond the purpose of the code point allocation? Best regards, Nurit מאת: ietf-boun...@ietf.org בשם Sprecher, Nurit (NSN - IL/Hod HaSharon) נשלח: ג 13/03/2012 20:09 אל: Andrew G. Malis; ext Ross Callon עותק לידיעה: 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 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-boun...@ietf.org [mailto:ietf-boun...@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 On Thu, Mar 1, 2012 at 7:20 AM, Sprecher, Nurit (NSN - IL/Hod HaSharon) nurit.sprec...@nsn.com wrote: Hi, I cannot support the publication of the document in its current version. I have the following concerns: .It is indicated that the channel is intended to be used to carry Ethernet based OAM messages. It is not clear why there is a need for ACH. PWs can be used to transmit Ethernet OAM. If the intention is to use the channel for OAM messages for operating MPLS-TP based networks, the IETF *already* defined a solution for MPLS-TP OAM and I expect to see first a technical *justification* why a second solution is needed. In addition, I would expect to see *references to the arguments* raised in draft-sprecher-mpls-tp-oam-considerations. .It is not clear what the maturity status of G.8113.1 is. It seems that the document was not approved by SG15 and the discussion was deferred to WTSA. This indicates that there is *no consensus* for the approval of G.8113.1. A code point should not be allocated before a consensus/decision is reached in the ITU-T and before the document is mature and approved. I do not think it is appropriate to allocate a code point and try to force a resolution in the ITU-T. .I find a contradiction in the draft. In one place it is mentioned: 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. In another
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
- Original Message - From: Sprecher, Nurit (NSN - IL/Hod HaSharon) nurit.sprec...@nsn.com To: Andrew G. Malis agma...@gmail.com; ext Ross Callon rcal...@juniper.net Cc: ietf@ietf.org Sent: Tuesday, March 13, 2012 8:09 PM 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, tp Why? I can understand a new code point being required if there is a new and backwards incompatible format for the messages, but if the messages are extended in a forwards compatible manner, adding new TLV for example, or a new format of IF_ID, then why should we burn a new code point? Would you say that we should have a dozen different port numbers for HTTP to reflect its evolution over time? If not, why not? Demanding that the ITU-T come back to us for a new round of negotiation when it is technically unnecessary seems to be placing an unnecessary barrier between the two SDOs. Tom Petch 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-boun...@ietf.org [mailto:ietf-boun...@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 On Thu, Mar 1, 2012 at 7:20 AM, Sprecher, Nurit (NSN - IL/Hod HaSharon) nurit.sprec...@nsn.com wrote: Hi, I cannot support the publication of the document in its current version. I have the following concerns: .It is indicated that the channel is intended to be used to carry Ethernet based OAM messages. It is not clear why there is a need for ACH. PWs can be used to transmit Ethernet OAM. If the intention is to use the channel for OAM messages for operating MPLS-TP based networks, the IETF *already* defined a solution for MPLS-TP OAM and I expect to see first a technical *justification* why a second solution is needed. In addition, I would expect to see *references to the arguments* raised in draft-sprecher-mpls-tp-oam-considerations. .It is not clear what the maturity status of G.8113.1 is. It seems that the document was not approved by SG15 and the discussion was deferred to WTSA. This indicates that there is *no consensus* for the approval of G.8113.1. A code point should not be allocated before a consensus/decision is reached in the ITU-T and before the document is mature and approved. I do not think it is appropriate to allocate a code point and try to force a resolution in the ITU-T. .I find a contradiction in the
הנדון: 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-boun...@ietf.org [mailto:ietf-boun...@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 On Thu, Mar 1, 2012 at 7:20 AM, Sprecher, Nurit (NSN - IL/Hod HaSharon) nurit.sprec...@nsn.com wrote: Hi, I cannot support the publication of the document in its current version. I have the following concerns: .It is indicated that the channel is intended to be used to carry Ethernet based OAM messages. It is not clear why there is a need for ACH. PWs can be used to transmit Ethernet OAM. If the intention is to use the channel for OAM messages for operating MPLS-TP based networks, the IETF *already* defined a solution for MPLS-TP OAM and I expect to see first a technical *justification* why a second solution is needed. In addition, I would expect to see *references to the arguments* raised in draft-sprecher-mpls-tp-oam-considerations. .It is not clear what the maturity status of G.8113.1 is. It seems that the document was not approved by SG15 and the discussion was deferred to WTSA. This indicates that there is *no consensus* for the approval of G.8113.1. A code point should not be allocated before a consensus/decision is reached in the ITU-T and before the document is mature and approved. I do not think it is appropriate to allocate a code point and try to force a resolution in the ITU-T. .I find a contradiction in the draft. In one place it is mentioned: 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. In another place it is mentioned: all ITU-T Recommendations are subject to revision. Therefore, the code point allocated by this document may be used for future versions of [G.8113.1].. The last statement opens the door for the definition of additional messages in G.8113.1 in the following versions, for example, for APS (supporting linear or ring protection mechanisms) and by this creates two solutions for other mechanisms as well. The use of the code point can go much beyond its original purpose and it will hide other messagesa code point should not be allocated at this point at all, but specifically not for unknown usage that may be defined in future versions of G.8113.1. Best regards, Nurit -Original Message-
