RE: [PWE3] FW: LastCall: <draft-betts-itu-oam-ach-code-point-03.txt>(Allocationof an Associated Channel Code Point for Use byITU-T Ethernet basedOAM) to Informational RFC

[Ross Callon <[e-mail]>]

A current AD might take precedence over a past one, but back when I was on the IESG we twice had discussions of the use of RFC2119 keywords in informational track documents. Both times we fortunately came to the same conclusion - that it is fine to use RFC2119 keywords in informational (or experimental) RFCs.

Ross

From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Friday, March 23, 2012 11:39 AM
To: t.petch
Cc: [e-mail]
Subject: Re: [PWE3] FW: LastCall: <draft-betts-itu-oam-ach-code-point-03.txt>(Allocationof an Associated Channel Code Point for Use byITU-T Ethernet basedOAM) to Informational RFC

Tom,

I have no objections to using the RFC 2119 key words, I am not sure if that is appropriate in an informational track document, I expect that our AD will provide some guidance.

Regards,

Malcolm


"t.petch" <[e-mail]>

23/03/2012 05:50 AM

To

"Loa Andersson" <[e-mail]>, <[e-mail]>

cc

<[e-mail]>

Subject

Re: [PWE3] FW: LastCall:        <draft-betts-itu-oam-ach-code-point-03.txt>(Allocationof        an Associated Channel Code Point for Use byITU-T Ethernet        basedOAM)        to Informational RFC







Loa

The one point that jumps out at me is the proposed text
"Other message types should not be carried behind this code point."
or should that be
"Other message types SHOULD NOT be carried behind this code point."
which, in IETF-Land, is a bit different.

I prefer the latter.

Tom Petch


----- Original Message -----
From: "Loa Andersson" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Friday, March 23, 2012 10:44 AM
Subject: Re: [PWE3] FW: LastCall:
<draft-betts-itu-oam-ach-code-point-03.txt>(Allocationof an Associated Channel
Code Point for Use byITU-T Ethernet basedOAM) to Informational RFC


> Malcolm,
>
> good that we are making some progress!
>
> On the experimental code point
> ------------------------------
>
> I doesn't seem appropriate to call out the fact that some commercial
> products has been using an experimental code point in production
> setting!
>
> On the remain (key) disagreements
> ---------------------------------
>
> I will let other people comment for now.
>
>
> /Loa
>
> On 2012-03-21 21:33, [e-mail] wrote:
> > Loa,
> >
> > Thank you for your comments and suggestions, please see in line below.
> >
> > Regards,
> >
> > Malcolm
> >
> >
> > [e-mail] wrote on 12/03/2012 04:31:43 AM:
> >
> >  > Loa Andersson <[e-mail]>
> >  > Sent by: [e-mail]
> >  >
> >  > 12/03/2012 04:31 AM
> >  >
> >  > To
> >  >
> >  > [e-mail]
> >  >
> >  > cc
> >  >
> >  > Subject
> >  >
> >  > Re: [PWE3] FW: Last Call: <draft-betts-itu-oam-ach-code-
> >  > point-03.txt>(Allocation of 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.
> >  >
> >
> > MB: No objection to this change
> >
> >  >
> >  > 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]."
> >
> > MB: No objection to this change
> >
> >  >
> >  > 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."
> >
> > MB: Since the draft will not be published as an RFC until after G.8113.1
> > is approved we can directly reference the approved Recommendation and I
> > suggest that we modify paragraph to:
> >
> >
> > ITU-T Recommendation [G.8113.1] documents MPLS OAM. 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).
> >
> > MB: Thank you, I will fix this.
> >
> >  >
> >  > 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
> >  > -
> >
> > MB: I do not agree with the deletion of this text, these existing
> > deployments, and the desire to migrate to an allocated code point, are
> > part of the rational for requesting the code point.
> >
> >  >
> >  >
> >  > 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.
> >
> >
> > MB: I do not agree with this proposed change. Other comments request
> > that the restriction on the applicability of the code point is
> > strengthened so I propose the following:
> >
> > The code point allocated by this document should only be used for 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.
> >
> >
> >  >
> >  > 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.
> >
> > MB: No objection to this change.
> >
> >  >
> >  >
> >  > 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:
> >  > -
> >  >
> >  >
> >
> > MB: I do not agree with the removal of this text:
> >
> > 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).
> >
> > Only those 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.
> >
> > 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.
> >
> >
> >
> >  >---------------snip
> >
> >
> >  >
> >  > Loa Andersson email: [e-mail]
> >  > Sr Strategy and Standards Manager [e-mail]
> >  > Ericsson Inc phone: [phone]
> >  > [phone]
> >  > _______________________________________________
> >  > Ietf mailing list
> >  > [e-mail]
> >  > https://www.ietf.org/mailman/listinfo/ietf
> >  >
>
> --
>
>
> Loa Andersson                         email: [e-mail]
> Sr Strategy and Standards Manager            [e-mail]
> Ericsson Inc                          phone: [phone]
>                                               [phone]
>
>