[discuss] On Addresses and Identifiers / proceeding properly

Wed Mar 5 21:14:25 UTC 2014

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.

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.

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)

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 - 

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