Re: FW: 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

[Alia Atlas <[e-mail]>]

Rui,

Perhaps more familiarity with the related history over the last
several years would help?  I can recommend the MPLS list archives.
Otherwise, I find this remarkably disingenuous.

This is a case of a second solution that was clearly rejected by the
MPLS working group (despite in-person histrionics causing the ADs to
have to threaten to close down the WG meeting).  Then the solution was
taken to the ITU study group - where it could also not get enough
traction for their normal process.  It is still not approved as a
recommendation.

To imply that the IETF should simply trust the allocated ACH code
point to not be abused both seems optimistic and sets a dreadful
precedent.

Making an allocation available for an approved recommendation version
is a tolerable way of reducing the deliberate use of an experimental
value.   Handing the keys over for any conceivable use, or even just
the uses in the OAM RFC that have been adequately met by IETF
WG-consensus based technology, does not seem appropriate.

Alia



On Thu, Mar 22, 2012 at 10:42 AM, Rui Costa <[e-mail]> wrote:
> I fail to understand the issue under discussion.
>
> Can't imagine IEEE denying to grant Ethertype 0x86DD. If, however, from absurd that had happened, would the world stop or would we take the same information from the IP header version field?
>
> Regards,
> Rui
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Alia Atlas
> Sent: quarta-feira, 21 de Março de 2012 15:30
> To: D'Alessandro Alessandro Gerardo
> Cc: [e-mail]
> 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
>
> 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