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

[Stephen Farrell <[e-mail]>]

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.