Subject: [Ianaplan] Comment on draft-ietf-ianaplan-icg-response-02

From: Russ Housley <[email-masked]>
Date: Mon, 3 Nov 2014 16:47:36 -0500

The document says:

> In this context, the IETF considers "overlap" to be where there is in some way shared responsibility for a single registry across multiple organizations. In this sense, there is no overlap between organizations because responsibility for each registry is carefully delineated. There are, however, points of interaction between other organizations, and a few cases where we may further define the scope of a registry for technical purposes. This is the case with both names and numbers, as described in the paragraphs below. In all cases, the IETF engages directly with the appropriate organizations to ensure that each organization’s policies are followed.

We should add a paragraph after that one that considers a future where names, numbers, and protocol parameters do not use the sam operator.  I suggest:

"At present, there is a single IANA functions operator maintaining the IANA registries for the names, numbers, and protocol parameters.  Having a single IANA functions operator aids coordination.  However, in the future, delegated registries may be maintained by the responsible organization directly or by a contracted registry maintenance vendor so long as any necessary coordination is maintained."

Russ

---

From: Geoff Huston <[email-masked]>
Date: Tue, 4 Nov 2014 16:32:53 +1100

> On 4 Nov 2014, at 8:47 am, Russ Housley <[email-masked]> wrote:
> 
> The document says:
> 

It seems like a quibble, but I thought the e164.arpa registry was operated by someone else, and the 2.0.0.2.ipv6.int was similarly delegated elsewhere. I agree with the sentiment that there is no a priori requirement for a single functions operator, but rather than an abstract notion the IAB in the past has implemented this and used others for particular function operators.

Geoff

---

From: Olaf Kolkman <[email-masked]>
Date: Tue, 4 Nov 2014 07:01:03 +0000

On Nov 4, 2014, at 06:47, Russ Housley <[email-masked]<mailto:[email-masked]>> wrote:

"At present, there is a single IANA functions operator maintaining the IANA registries for the names, numbers, and protocol parameters.”

I may be in the rough but there is this one registry (e164.arpa) that I would consider an IANA function (from the IETF perspective), still it is not in this bag of functions that is currently under US contract. Perhaps that can be recognized by

s/the IANA registries/the IANA registries under US contract/

—Olaf

— — — — — — — — — —
Olaf Kolkman
(on personal title)

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 4 Nov 2014 07:23:38 +0000

> On 4 nov 2014, at 07:01, Olaf Kolkman <[email-masked]> wrote:
> 
>> On Nov 4, 2014, at 06:47, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
>> 

As explained in for example SAC-067 and SAC-068 there are both parameters from IETF that are not managed by the IANA Function at ICANN (e.164 for example) and parameters managed by the IANA Function at ICANN while not covered by the contract.

   Patrik

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Nov 2014 08:47:16 +1300

> As explained in for example SAC-067 and SAC-068 there are both parameters from IETF that are not managed by the IANA Function at ICANN (e.164 for example) and parameters managed by the IANA Functio…

The great advantage of hierarchical namespaces is that they are
hierarchies. So if the text doesn't reflect the fact that IANA
is only *required* to be the registrar for the top level of each
hierarchy, that is a bug (but one that any computer scientist
will autocorrect, as I certainly did when reading the draft).

    Brian