ietf
[Top] [All Lists]

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

2012-03-14 06:57:26
----- Original Message -----
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" 
<nurit(_dot_)sprecher(_at_)nsn(_dot_)com>
To: "Andrew G. Malis" <agmalis(_at_)gmail(_dot_)com>; "ext Ross Callon"
<rcallon(_at_)juniper(_dot_)net>
Cc: <ietf(_at_)ietf(_dot_)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(_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,

<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-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

On Thu, Mar 1, 2012 at 7:20 AM, Sprecher, Nurit (NSN - IL/Hod
HaSharon) <nurit(_dot_)sprecher(_at_)nsn(_dot_)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 messages....a 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-----

From: ietf-announce-bounces(_at_)ietf(_dot_)org [mailto:ietf-announce-

bounces(_at_)ietf(_dot_)org] 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(_at_)ietf(_dot_)org mailing lists by 2012-03-21. Exceptionally, 
comments may

be

sent to iesg(_at_)ietf(_dot_)org 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(_at_)ietf(_dot_)org

https://www.ietf.org/mailman/listinfo/ietf-announce



_______________________________________________

mpls mailing list

mpls(_at_)ietf(_dot_)org

https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________

Ietf mailing list

Ietf(_at_)ietf(_dot_)org

https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________

Ietf mailing list

Ietf(_at_)ietf(_dot_)org

https://www.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf



--------------------------------------------------------------------------------


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf