Loa hi, I think your proposal is productive and provides a good basis to progress. Please see some comments inline (<Nurit>...\<Nurit>). Best regards, Nurit -----Original Message----- From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of ext Loa Andersson Sent: Monday, March 12, 2012 10:32 AM To: ietf@xxxxxxxx Subject: Re: [PWE3] FW: Last Call:<draft-betts-itu-oam-ach-code-point-03.txt>(Allocationof an Associated Channel Code Point for Use byITU-T Ethernet based OAM)to Informational RFC All, I've been asked to clarify thee comments in this mail, I done so by proposing new text to draft-betts-. I hope this helps. Title ===== Comment: We want to assign a Associated Channel Type. The registry that it will be assigned from is "Pseudowire Associated Channel Types"; however RFC 5586, makes the Channel Types generic and I think the title should be changed as follows: OLD: Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM NEW: Allocation of an Generic Associated Channel Type for ITU-T MPLS-TP OAM Note: Neither MPLS-TP or OAM are in the RFC Editors list of wellknown acronyms, therfore the title probably should be: NEW: Allocation of an Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance and Administration. Introduction - first paragraph ============================== In the first paragraph of the introduction, there seems to be an oddity in the description of the role of the ietf-tp-oam-analysis document. Instead of: OLD "tools defined by the IETF [I-D.ietf-mpls-tp-oam-analysis], that are intended to meet the OAM functional requirements defined in [RFC5860]." NEW: "tools described by the IETF [I-D.ietf-mpls-tp-oam-analysis], which are used to meet the OAM functional requirements defined in [RFC5860]." <Nurit> should we say "described and referred by..."? \<Nurit> <Nurit> should we say "...that satisfies the OAM functional requirements defined in [RFC586]"? Intrduction - second paragraph ============================== The next paragraph in describing G.8113.1, stumbles over the current vs anticipated future state of G.8113.1 and its relationship to its antecedents. I'm a bit un-certain about the correct terminology, but I think the following change would improve the document. OLD: The ITU-T has documented, in draft new Recommendation [G.8113.1], the use of Ethernet based OAM mechanisms, originally defined in [Y.1731], carried in the MPLS Generic Associated Channel (G-ACh). This approach requires the allocation of an ACH Type from the registry of ACH types maintained by IANA in order that the messages that will be described in [G.8113.1] can be identified by an implementation. NEW: "The ITU-T has Draft Recommendation [G.8113.1] documented MPLS OAM which as of this writing is undergoing the ITU-T Traditional Approval Process (TAP). This Recommendation builds upon Ethernet OAM as documented in [Y.1731]. The messages in [G.8113.1] are defined to be carried in a new Associated Channel Type in the MPLS Generaic Associated Channel (G-Ach). In order to carry these messages in an interoperable fashion, an Associated Channel Type from the IANA maintained registry "Pseudowire Associated Channel Types is to be used." Note there are confusion around some of the Associated Channel acronyms that are refledted in this document. ACh is Associated Channel ACH is Associated Chamnnel Header G-ACh is Generic Associated Channel "ACH Type" is not used anywhere in IETF documents; we talk about Associated Channel Type or Generic Associated Channel Type (G-ACh Type). Introduction - third paragraph ============================== In the third paragraph, there seems to be an unnecessary reference to experimental types. When asking for a code point for a standard, it is not helped to bring up experimental code space. Can we remove the text reading: OLD: "without continuing to resorting to the use of an experimental ACH Type," NEW - Section 2 - first paragraph =========================== In section 2, the first sentence refers to Ethernet based OAM messages. As far as I know, the messages in G.8113.1 are either MPLS-TP OAM messages, or they are simply the OAM messages defined in G.8113.1. The simplest path to clarity would seem to be to replace "Ethernet based OAM messages" in that sentence with "messages". The second sentence of that paragraph does not seem to say anything we need to say. Can we remove it? OLD: 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. NEW: The code point allocated by this document is intended to be used only for OAM messages, defined in the ITU-T Recommendation [G.8113.1], carried in the G-ACh . Other message types should not be carried behind this Associated Channel Type. <Nurit> here we should be clearer about which OAM messages we refer to. It should be clear that these are the only ones that satisfy the requirements of RFC 5860. I want to make sure that messages of protection mechanisms are not included and are not hidden by the allocated codepoint. \<Nurit> Section 2 - second paragraph ============================ A matter of some clarity, can we change this paragrap like this: OLD: This code point may be used on any transport construct that uses the G-ACh, e.g., MPLS-TP Sections, MPLS-TP LSPs or PWs. NEW: The Generic Associated Channel Type assigned by this document may be used on any transport construct that uses the G-ACh, e.g., MPLS-TP Sections, MPLS-TP LSPs or PWs as specified by G.8113.1. Section 2 - third paragraph =========================== With regard to revisions, which is what I think the third paragraph is about, I am not clear what you are trying to say. A code point allocation must point to a stable referent. If the desired referent changes, then process needs to be followed to make sure that the IANA is updated in accordance with IETF procedures. Hence, I am left to the conclusion that the third paragraph is actually asking for something we can not do. Can we remove that? OLD: 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]. NEW: - On 2012-02-27 14:51, Loa Andersson wrote: > All, > > I agree with Stewart, while shortage of code points might be a reason > to think twice before allocating one, "abundance" in itself is never > a reason to allocate code points. > > I'm way less inclined to approve of this draft in the condition it > is now. Actually I believe that we should think very careful before > approving it at all. > > /Loa > > On 2012-02-27 14:01, Stewart Bryant wrote: >> >> Daniel >> >> Shortage of ACh types was never an issue. >> >> The issue issue is the concerns articulated in >> draft-sprecher-mpls-tp-oam-considerations >> >> Stewart >> >> >> On 23/02/2012 10:35, Daniel Cohn wrote: >>> Support - as there is no foreseen shortage in ACH types, I don't see a >>> reason why this code point should not be allocated to an ITU developed >>> protocol that is already deployed in the field. >>> >>> DC >>> >>>> -----Original Message----- >>>> From: ietf-announce-bounces@xxxxxxxx [mailto:ietf-announce- >>>> bounces@xxxxxxxx] On Behalf Of The IESG >>>> Sent: 22 February 2012 15:13 >>>> To: IETF-Announce >>>> Subject: Last Call:<draft-betts-itu-oam-ach-code-point-03.txt> >>> (Allocation of >>> an >>>> Associated Channel Code Point for Use by ITU-T Ethernet based OAM) to >>>> Informational RFC >>>> >>>> >>>> The IESG has received a request from an individual submitter to >>> consider >>>> the following document: >>>> - 'Allocation of an Associated Channel Code Point for Use by ITU-T >>>> Ethernet based OAM' >>>> <draft-betts-itu-oam-ach-code-point-03.txt> as an Informational RFC >>>> >>>> The IESG plans to make a decision in the next few weeks, and solicits >>>> final comments on this action. Please send substantive comments to the >>>> ietf@xxxxxxxx mailing lists by 2012-03-21. Exceptionally, comments may >>> be >>>> sent to iesg@xxxxxxxx instead. In either case, please retain the >>>> beginning of the Subject line to allow automated sorting. >>>> >>>> Abstract >>>> >>>> This document assigns an Associated Channel Type code point for >>>> carrying Ethernet based Operations, Administration, and Management >>>> messages in the MPLS Generic Associated Channel (G-ACh). >>>> >>>> The file can be obtained via >>>> http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/ >>>> >>>> IESG discussion can be tracked via >>>> http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/ >>>> >>>> >>>> No IPR declarations have been submitted directly on this I-D. >>>> _______________________________________________ >>>> IETF-Announce mailing list >>>> IETF-Announce@xxxxxxxx >>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@xxxxxxxx >>> https://www.ietf.org/mailman/listinfo/pwe3 >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@xxxxxxxx >>> https://www.ietf.org/mailman/listinfo/ietf >>> >> >> > -- Loa Andersson email: loa.andersson@xxxxxxxxxxxx Sr Strategy and Standards Manager loa@xxxxx Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf