[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf
Subject:    RE: FW: LastCall:<draft-betts-itu-oam-ach-code-point-03.txt>(Allocationofan
From:       Rui Costa <RCosta () ptinovacao ! pt>
Date:       2012-03-25 11:11:48
Message-ID: 52981DB05D3C5247A12D0AEE309F3CC202444240C386 () INOAVREX11 ! ptin ! corpPT ! com
[Download RAW message or body]

"We certainly have running code, widely deployed (although my request on the MPLS \
list as to which manufacturers' boxes were involved never did get answered:-("	 Hope \
these help:	 http://tools.ietf.org/html/draft-fang-mpls-tp-oam-considerations	
http://www.eantc.com/fileadmin/eantc/downloads/events/2007-2010/CEWC09/EANTC-CEWC2009-WhitePaper-v1_2.pdf	


Regards,	
Rui

-----Original Message-----
From: t.petch [mailto:daedulus@btconnect.com] 
Sent: sexta-feira, 23 de Março de 2012 09:58
To: Alia Atlas; Rui Costa
Cc: ietf@ietf.org
Subject: Re: FW: LastCall:<draft-betts-itu-oam-ach-code-point-03.txt>(Allocationofan \
Associated Channel Code Point for Use byITU-T Ethernetbased OAM) toInformational RFC

----- Original Message -----
From: "Alia Atlas" <akatlas@gmail.com>
To: "Rui Costa" <RCosta@ptinovacao.pt>
Cc: <ietf@ietf.org>
Sent: Thursday, March 22, 2012 10:07 PM

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.

<tp>
Alia

Were the roles reversed and the second solution be a product of the IETF that the \
IETF were trying to get more widely approved, would the IETF allocate a code point?

I think that it would.  We certainly have running code, widely deployed (although my \
request on the MPLS list as to which manufacturers' boxes were involved never did get \
answered:-(.

We have a rough consensus; not unanimity, and not enough of a consensus to satisfy \
the processes of the ITU-T but I think enough to satisfy the consensus-judgers of the \
IETF (as ever, we do not vote, a majority of e-mails for one point of view may be \
discounted, it is the quality of the views expressed that matters as much or more).

So applying the standards to which we work, I think this is another reason why we \
should approve this I-D.

Tom Petch

</tp>
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 <RCosta@ptinovacao.pt> 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: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf 
> Of Alia
Atlas
> Sent: quarta-feira, 21 de Março de 2012 15:30
> To: D'Alessandro Alessandro Gerardo
> 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
> 
> 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


[prev in list] [next in list] [prev in thread] [next in thread]