Re: [Ianaplan] control and negotiation (was Re: draft-ietf-ianaplan-icg-response-02 working group last call)

["Peterson, Jon" <[e-mail]>]

And well, we know there are certain protocol parameter registrations that
don't come form our I-Ds and RFCs. If it were the case that literally all
of IANA's protocol parameter registry entries originated in IETF
specifications, a new set of potential remedies would become available to
us. Alas, no.

But I do think Stephen is right that the community that interacts with
IANA is a small and technically sophisticated one, and that this means
that we don't have to worry too much about holding their hands in the
event of a transition. The situation of the root zone, say, is very
different. The potential for damaging "breakage" in the protocol parameter
registry is quite small.

Jon Peterson
Neustar, Inc.

On 11/10/14, 11:26 AM, "Eliot Lear" <[e-mail]> wrote:

>While I agree that only a subset of developers ever go to IANA, they are
>roughly the same set of developers who use RFCs.  We would not be having
>this discussion if we wanted to protect against misrepresentation of the
>RFC series.  As someone who is a designated expert for port numbers, I
>will also say that we don't want to make it any more difficult than it
>already is for people to make applications for our protocol parameters,
>nor do we want to break any processes (automated or human) that retrieve
>the protocol parameters so that they are included in the right places in
>various distributions.
>
>Eliot
>
>On 11/9/14, 3:50 PM, Stephen Farrell wrote:
>> I have to say this thread seems fairly ridiculous to me. There's
>> maybe some remote possibility of potential issues for someone
>> with IANA as a trademark, but as stated by others, that's just
>> not interesting for the protocol parameters - in the face of any
>> such thorny legal issue, we'd just move to some other nomenclature
>> (e.g. the BLAHBLAH considerations section, or whatever) and we
>> would have no problems at all doing so.
>>
>> However, I do think Andrew earlier made a good point that those
>> most exercised by this possibility are perhaps (or perhaps vastly)
>> overestimating its probability due to a disconnect between their
>> experience and the reality of IETF protocol parameters, so in the
>> spirit of trying to help close that gap, here's another bit of
>> information about how things work hat I don't recall having been
>> posted here (apologies if it has) ...
>>
>> On 09/11/14 13:19, Miles Fidelman wrote:
>>> The primary reason for addressing the issue is to avoid or reduce the
>>> potential for costly trademark litigation down the road.  If all
>>>remains
>>> cooperative, as may predict, then there's no issue at all. On the other
>>> hand, if an edge case arises - an attempt to change IANA contractors
>>> under less-than-cooperative situations - there is the potential for
>>> nasty litigation, as well as technical game playing.
>> I don't see much game playing here of interest. The fact is that
>> implementers do not start by reading the IANA registries. We had
>> a long discussion on that between the IESG and some authors of a
>> Diameter RFC a few years ago where the author concerned (Glen Zorn)
>> convinced me at least that updating RFC text is basically far more
>> of interest than updating IANA registries.
>>
>> Many people write code that uses libraries and don't even see RFCs.
>> Fewer by far have to start from an RFC to write their code. The
>> number of people who actually consult the IANA protocol parameter
>> registries is a yet again much smaller set. (Given that the protocol
>> parameter registry entries alone are not sufficient to implement in
>> almost all cases and that RFCs that specify protocols almost always
>> contain enough that one doesn't have to go looking at an IANA
>> registry to implement.)
>>
>> The set of people who start anything from consulting an IANA registry
>> is probably almost infinitesimally small, and I would say is
>> basically IESG members, designated experts and IANA staffers, none
>> of whom are going to be in the least confused by any trademark
>> crapology.
>>
>> So a lot of the concern expressed about potential downsides here is
>> just misplaced as the real source of protocol parameters used by
>> developers is the RFC series and not IANA anything.
>>
>> S.
>>
>> _______________________________________________
>> Ianaplan mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ianaplan
>>
>>
>
>