[discuss] On Addresses and Identifiers / proceeding properly

[Seth Johnson]

On Wed, Mar 5, 2014 at 4:14 PM, John Curran <jcurran at istaff.org> wrote:
> On Mar 5, 2014, at 11:52 PM, Seth Johnson <seth.p.johnson at gmail.com> wrote:
>
>> I note these points here to indicate that a proper framework for
>> addressing universal identifiers needs to see where the fundamental
>> concerns begin to arise.
>
> Agreed.  There's a taxonomy behind all of this, although it is not often
> very clear...
>
> Specification of computer Internetworking protocols include delineation
> of syntax for parameter fields.  In order to achieve interoperability,
> there must be some also be common expectations on the semantics of the
> possible  values in those fields.  When the interoperability desired
> is of global scope (i.e. the Internet) then the shared expectations of
> parameter values and meanings must also be global in scope.  These
> mappings of values and their associated meaning are maintained in a
> protocol parameter registry.


Your version of interoperability interprets protocols as analogues for
legal policy, which is an unnecessary conceit.  Interoperability is
something we already have.  It's a matter of the flexibility of the
platform, whereas one makes interoperability look like it's a matter
of common rules imposed on the platform when one treats conventions as
a analogue for policy.

This is the specific thing that policies associated with identifiers
need to be guarded against becoming.  This is why I distinguish
identifiers in the sense of designating unique endpoints, from all
sorts of other purposes to which identifiers can be applied.


> There are hundreds of IETF protocols with associated registries, although
> a common example is the TCP "port number" protocol registry, which is why
> webservers (HTTP) listen for new connections on port 80 and most email
> servers listen on port 25 (SMTP).  Not many folks get excited about these
> registries, although they are fairly important and also done by the IANA
> team in ICANN per IETF direction as published in RFCs.


All very important, all very useful, and developed in a context that
gave us the greatest communications breakthrough known to man.  Just
don't interpret them like "interoperability rules," but as consensus
systems that go together with the overall design to give everyone a
maximally flexible platform.


> There are some very special protocol parameter registries which are so
> significant that they are generally just thought of by category, i.e.
> the IP address registries and the DNS registry.  The reason these get
> so much attention is that they have "general purpose" assignments, i.e.
> registries that will be used (in one way or another) by nearly every
> entity on the Internet, and potentially with each and every party having
> its own assignment.  The IPv4, IPv6, and DNS zones are in such widespread
> use that we think of these registries as different from the other IETF
> "protocol parameter" registries, but the truth is that they are just very
> specific, albeit extremely popular, examples of IETF protocol parameter
> registries.
>
> You can actually see this explained to some extent in RFC 2860, which
> is the IETF/IAB MOU with ICANN for provision of IANA services.  It
> notes that "Two particular assigned spaces present policy issues in
> addition to the technical considerations specified by the IETF: the
> assignment of domain names, and the assignment of IP address blocks.
> These policy issues are outside the scope of this MOU."   ICANN is
> still to maintain these registries (working with various others as
> needed) and may have to follow "policy" guidance from sources other
> than the RFC series.
>
> So, we've got this arrangement -
>
> Protocol Parameters
>
> Internet-scope Protocol parameters
>    [Port Numbers]
>
> Internet-scope general-purpose protocol parameters
>    [IP addresses]
>
> Internet-scope general-purpose protocol parameters with potential
>  for human readable semantics implications
>    [DNS names]
>
> The tricky part is that the policy for administration of general-purpose
> registries is often contains various economic/social/political aspects,
> and there is even the potential for such issues to arise with operational
> aspects of the registry itself (i.e. in the performance of the technical
> or clerical DNS root zone maintenance task that Milton referred to)


Right.  Just make it about the platform's strengths; don't encourage
the idea of interoperability just being a matter of rules imposed
between networks -- which will easily undermine the general purpose
nature of the platform.


> I imagine that the IETF doesn't exactly want to get dragged into the
> various policy fun that accompanies the "general purpose" DNS and IP
> registries, but they still have an interest in making sure that their
> IP and DNS protocols are easy to adopt by the community, and that means
> that registry compliance with the technical requirements is important,
> as general purpose IETF philosophy is also an important framework that
> gets passes along to these registries...  There is an effort underway
> to actually document that framework for the IANA registries (see
> <http://datatracker.ietf.org/doc/draft-iab-iana-framework/> for the
> latest draft). I would recommend reading the entire draft, but one
> particularly relevant aspect in the present draft is the section
> on Key principles -


I think I saw these principles from you before.  They seem roughly
mostly harmless, except your notion of interoperability leads in the
wrong direction, so I have an askance gaze on them.  It isn't just
common rules across networks (especially not there); it's a basic
foundation that lets people do applications by consensus, readily and
voluntarily.  We should never offer the notion of interoperability as
a basis for rationalizing policy -- policy should defend its goals and
purposes against its impact on the platform.

I'll elaborate more on the pattern of proceeding from numeric IPs to
the name space, and going on from there while understanding and
distinguishing uses of identifiers carefully, in furtherdiscussions.
ICANN has already long been doing things that it should not have been
doing the way it has been, and I gave some explanation of that in my
message.

You seem to have good work done here; I'm just diverting a direction
within your analysis that leads in a troublesome direction.  I'm also
focused more on the shortsightedness of the conception of the nature
of governance in the international arena that many have, not to say
that includes you, but that's also a core part of my approach.

(eom)


Seth

>>> 3.  Key principles of the IANA framework
>>>
>>>  Any IANA framework should be implementable with the following key
>>>    principles in mind.
>>>
>>>    Stable and Predictable: Stable and Predictable implementation of the
>>>       Internet Registries Function is important for establishing global
>>>       trust.
>>>
>>>    Accountability and transparency: Oversight, implementation, and
>>>       policy development roles are accountable to the materially
>>>       concerned parties and the wider community.  Not all roles may be
>>>       directly accountable to the wider community, in practice the
>>>       oversight role has responsibility for stewardship of the wider
>>>       community.  By implication the oversight role must maintain the
>>>       highest possible standards of transparency and be open to input
>>>       and review.
>>>
>>>    Separation of Roles: The oversight, policy development, and
>>>       implementation roles should be separate or separable.  A clear
>>>       distinction between the roles enhances the transparency and makes
>>>       it clearer who is accountable to who.
>>>
>>>    Delegation: It should be possible to delegate any of the roles
>>>       (policy, implementation, or oversight) for registries or parts
>>>       thereof.
>
> It's worth considering that these registries are consequential to the IETF's
> protocol specifications, and hence requirements such as the above from the
> IETF (which necessary to make sure their protocols can be widely adopted)
> should not be set aside lightly.
>
> FYI,
> /John
>
> Disclaimer:  My views alone (although the acknowledgements section of the
>              referenced IANA framework ID shows lots of other folks...)
>
>
>
>
>
>