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

[Eliot Lear <[e-mail]>]

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