ietf
[Top] [All Lists]

R: Last Call:<draft-betts-itu-oam-ach-code-point-03.txt> (Allocation of anAssociated Channel Code Point for Use by ITU-T Ethernet basedOAM) to Informational RFC

2012-03-21 09:16:54
I support the draft.
Multi-vendor interoperable implementations of the protocol the draft  is asking 
for the allocation of a code point  has been already tested and deployed and 
therefore I agree with Mr. Petch when he says  we should approve it now to 
facilitate the migration of the existing boxes to an approved solution.

Best regards,
Alessandro
------------------------------------------------------------------
Telecom Italia
Alessandro Gerardo D'Alessandro
Transport Innovation
Via Reiss Romoli, 274 - 10148 Torino
phone:  +39 011 228 5887
mobile: +39 335 766 9607
fax: +39 06 418 639 07


-----Messaggio originale-----
Da: t.petch [mailto:daedulus(_at_)btconnect(_dot_)com]
Inviato: martedì 6 marzo 2012 11:32
A: John C Klensin; stbryant(_at_)cisco(_dot_)com
Cc: ietf(_at_)ietf(_dot_)org
Oggetto: Re: Last Call:<draft-betts-itu-oam-ach-code-point-03.txt> (Allocation 
of anAssociated Channel Code Point for Use by ITU-T Ethernet basedOAM) to 
Informational RFC

I am finding myself with some unfamiliar bedfellows on this issue, but yes, it 
should be approved - see inline.

Tom Petch

----- Original Message -----
From: "John C Klensin" <john-ietf(_at_)jck(_dot_)com>
To: <stbryant(_at_)cisco(_dot_)com>
Cc: <ietf(_at_)ietf(_dot_)org>
Sent: Friday, March 02, 2012 12:04 AM
Subject: Re: Last Call:<draft-betts-itu-oam-ach-code-point-03.txt> (Allocation 
of anAssociated Channel Code Point for Use by ITU-T Ethernet basedOAM) to 
Informational RFC


 <snip>

(2) Whether it is reasonable or appropriate for the IETF to use our
responsibility for code point assignments and consequent relationship
with IANA to try to keep protocols that are not consistent with our
design judgment and aesthetics --no matter how grounded in experience
and good engineering-- off the Internet.  That is the "Internet
gatekeeper" function about which, as you know, I've expressed concern
in other contexts.  I think the answer has got to be "we can, should,
and always will exercise quality control on stable specifications and
normative references but, unless we can justify being sure of our own
infallibility, we cannot and should not try to prevent another body
from deploying a specification on the Internet by using our
control of the registration model".   Telling people why we
think their ideas are sub-optimal is fine, as is identifying any risks
we see in appropriate and visible places, but telling another group
what they can't do because the IETF doesn't like the idea isn't.

We claim ownership of the name space on behalf of all parties, all SDOs 
governments, NGOs, anyone and anything, and this gives us a special 
responsibility to exercise that wisely.  We should beware of imposing our ideas 
of correctness of any kind on another SDO - that is up to  them to decide, not 
us.

Of course, one open technical solution to a problem is best but the RFC Series 
is suitable cluttered with instances of the IETF failing to achieve that so any 
argument based on those grounds is hypocritical.

A stable, approved reference is ideal, but we have been told of the widespread 
deployment of this approach using an experimental
code point so the running code very much exists.   If that is camping
on something that it would be better if it were not, then that is something to 
fix, and something we can fix.

There is no reason not to approve the allocation of a code point and 
furthermore, I believe we should do it now, to facilitate the migration of the 
existing boxes to an approved solution.  If that leaves another SDO with an 
incompatability between what is working and what their documents say, well, the 
IETF has been there too; not a good place to be, but it is up to the SDO to 
resolve that, not the IETF.

Tom Petch

And I think that distinction is entirely consistent with Russ's
suggestion.

best,
   john




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





Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone 
indicate. La diffusione, copia o qualsiasi altra azione derivante dalla 
conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate 
ricevuto questo documento per errore siete cortesemente pregati di darne 
immediata comunicazione al mittente e di provvedere alla sua distruzione, 
Grazie.

This e-mail and any attachments is confidential and may contain privileged 
information intended for the addressee(s) only. Dissemination, copying, 
printing or use by anybody else is unauthorised. If you are not the intended 
recipient, please delete this message and any attachments and advise the sender 
by return e-mail, Thanks.


Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone 
indicate. La diffusione, copia o qualsiasi altra azione derivante dalla 
conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate 
ricevuto questo documento per errore siete cortesemente pregati di darne 
immediata comunicazione al mittente e di provvedere alla sua distruzione, 
Grazie.

This e-mail and any attachments is confidential and may contain privileged 
information intended for the addressee(s) only. Dissemination, copying, 
printing or use by anybody else is unauthorised. If you are not the intended 
recipient, please delete this message and any attachments and advise the sender 
by return e-mail, Thanks.


<Prev in Thread] Current Thread [Next in Thread>