Subject: Re: [Internetgovtech] IANA blog article

From: Patrik Fältström <[email-masked]>
Date: Fri, 3 Jan 2014 21:17:25 +0100

On 3 jan 2014, at 18:36, IETF Chair <[email-masked]> wrote:

> In this article I wanted to highlight an important but often hidden part in the IETF ecosystem: Internet Assigned Numbers Authority (IANA).  What is IANA, how does it work, how is it related to the IETF, and how has it evolved over time? How will it evolve in the future, and how can you participate in the discussion?
> 
> http://www.ietf.org/blog/2014/01/iana/

Comments after first read of this very good text that is coming at the right time.

In no specific order:

1. IANA itself divide its work in three parts, and because of that I think Olaf's draft is more correct than Jari's text that I think sort of only talk about two? Maybe I misunderstand.

Anyway...

2. Regarding IANA evaluation:

> In some cases, the evaluation of requests is a
> straightforward task requiring little subjective evaluation, whereas
> in other cases evaluation is more complex and requires subject matter
> experts as defined by the relevant policy guidance.

I normally explain this a bit differently. IANA at this time evaluates a request and comes back with one of three(!) different responses:

- YES, approved

- NO, not approved

- [to IETF] Rules not clear enough

I.e. I think it should be clear that IANA is to (unless things really have changed from when I was more involved)

a. Inspect the IANA Considerations Section as part of the publication process of an RFC

b. Signal to whatever policy development process that developed the rules for a certain parameter that although IANA said "ok" (see a. above), the rules where not clear enough and should be updated

3. Policy development

I think the division of the process in various pieces in Olafs draft is good. But I think it should be even more specific on the fact that the _policy_ process that results in a request to IANA to do something might be in various places, and that is not limited to IETF and ICANN and RIRs. I do for example not know where policy process is for the timezone database, or maybe IETF is the one that have set the policy for IANA, and that is to "listen to changes decided by [some third body]"? Honestly I do not know.

ICANN have the policy development of the IDN language tables, and I think I remember W3C had one parameter, but maybe I am wrong.

Hmm...

I must re-read and see whether I really feel a clarification is needed, and if so, what it is

4. ENUM

ENUM is interesting example...because IANA is not really involved at all. Or rather, IANA manages ARPA, and is asked by IAB to delegate e164.arpa to RIPE NCC which in turn is implementing the policy decided by ITU-T policy.

5. Key principles of the IANA framework

This, section 3, is very good. Can not be emphasised enough.

6. Agreement between DoC and ICANN

People will ask what the relationship is between IETF-ICANN agreements on for example IANA performance and improvements and the USGov-ICANN agreement <http://www.ntia.doc.gov/page/iana-functions-purchase-order>. See specifically C.2.9 (including sub bullets -- not the .INT TLD...) and C.4 about measurements.

Specifically, when these documents talks about IAB oversight, what is that oversight relationship with the Contracting Officer’s Representative (COR) oversight according to the contract with US Gov?

   Patrik

---

From: SM <[email-masked]>
Date: Fri, 03 Jan 2014 12:50:23 -0800

Hi Patrik,
At 12:17 03-01-2014, Patrik Fältström wrote:
>IETF and ICANN and RIRs. I do for example not 
>know where policy process is for the timezone 
>database, or maybe IETF is the one that have set 
>the policy for IANA, and that is to "listen to 
>changes decided by [some third body]"? Honestly I do not know.

It is my understanding that neither the IETF nor 
IANA sets policy for the timezone database.  The 
maintenance of the timezone database is discussed in RFC 6557.

Regards,
-sm

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 3 Jan 2014 22:21:10 +0100

On 3 jan 2014, at 21:50, SM <[email-masked]> wrote:

>> IETF and ICANN and RIRs. I do for example not know where policy process is for the timezone database, or maybe IETF is the one that have set the policy for IANA, and that is to "listen to changes decided by [some third body]"? Honestly I do not know.
> 
> It is my understanding that neither the IETF nor IANA sets policy for the timezone database.  The maintenance of the timezone database is discussed in RFC 6557.

Ok, good. Thanks for the information.

Then instructions IANA has related to this parameter still comes from IETF. That is the important piece I think.

   Patrik

---

From: David Conrad <[email-masked]>
Date: Fri, 3 Jan 2014 18:11:19 -0800

Patrik,

> 1. IANA itself divide its work in three parts, and because of that I think Olaf's draft is more correct than Jari's text that I think sort of only talk about two? Maybe I misunderstand.

Jari does briefly mention the two other major functions (names and Internet numbers), however there is (or at least was) a bit more than just {protocol parameters,names,Internet numbers}: there's also management of .ARPA and .INT and other similar odds and ends.

> - [to IETF] Rules not clear enough

Not just to the IETF. In theory, at least, IANA staff can push back on the ASO for clarification on global address policies and on ICANN in the context of root zone management (e.g., glue policy).

However, far more common than "Rules not clear enough" would be:

- [to requester] Need more information.

> b. Signal to whatever policy development process that developed the rules for a certain parameter that although IANA said "ok" (see a. above), the rules where not clear enough and should be updated

There might be a mixing of roles here. To use Olaf's terminology/distinctions, I believe (a) is (or should be) part of the policy development role and (b) is part of the implementation role.  That is, I think IANA staff should be in the loop in policy development, reviewing the IANA consideration section during the development of the policy so they can ensure that policy can be implemented.  It may be interesting that by the terms of the current IANA functions contract between ICANN and the USG (specifically, section C.2.5), it can be argued that IANA staff are explicitly disallowed from participation in policy development -- I suspect it comes down to the interpretation of "initiate, advance, or advocate" and "respond to requests for information".

> 3. Policy development
> 
> I think the division of the process in various pieces in Olafs draft is good. But I think it should be even more specific on the fact that the _policy_ process that results in a request to IANA to do something might be in various places, and that is not limited to IETF and ICANN and RIRs.

Perhaps a more exhaustive mapping of resource to policy definition body:

protocol parameters: IETF
top-level domains: ICANN, IETF (see RFC 6761), governments (in the case of ccTLDs)
top-level Internet number blocks: IETF (see RFC 7020), the RIR policy definition bodies, legacy address holders(?)
.ARPA: IAB, IETF (sub-zones, e.g., in-addr.arpa, can involve other players, depending on the sub-zone)
.INT: ICANN(?) -- this one has always been a bit odd.

> ENUM is interesting example...because IANA is not really involved at all. Or rather, IANA manages ARPA, and is asked by IAB to delegate e164.arpa to RIPE NCC which in turn is implementing the polic…

Out of curiosity, how is the ITU-T policy enforced in the case of e164.arpa?  Is there a contract between the ITU Secretariat and RIPE-NCC?

> This, section 3, is very good. Can not be emphasised enough.

I actually think this should be expanded. Each of the terms used in that section probably need to be defined/explained.  E.g., what do "stable" and "predictable" mean in the context of an IANA framework?
 
> Specifically, when these documents talks about IAB oversight, what is that oversight relationship with the Contracting Officer’s Representative (COR) oversight according to the contract with US Gov?

"*That*, Detective, is the right question." -- Dr. Alfred Lanning (deceased), "I, Robot" (the movie)  

:)

Regards,
-drc

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 4 Jan 2014 08:44:40 +0100

> Not just to the IETF. In theory, at least, IANA staff can push back on the ASO for clarification on global address policies and on ICANN in the context of root zone management (e.g., glue policy).

Correct.

> - [to requester] Need more information.

+1

> There might be a mixing of roles here. To use Olaf's terminology/distinctions, I believe (a) is (or should be) part of the policy development role and (b) is part of the implementation role.  That is, I think IANA staff should be in the loop in policy development, reviewing the IANA consideration section during the development of the policy so they can ensure that policy can be implemented.

Specifically, *IF* IANA is part of the PDP (which I believe IANA still is for at least the IETF PDP) then that should be mentioned.

> It may be interesting that by the terms of the current IANA functions contract between ICANN and the USG (specifically, section C.2.5), it can be argued that IANA staff are explicitly disallowed from participation in policy development -- I suspect it comes down to the interpretation of "initiate, advance, or advocate" and "respond to requests for information".

Correct.

I do though think IETF have had the line drawn correctly for some time. The IANA involvement is strictly to inspect the IANA considerations section.

But your point about C.2.5 (and other) is a good one regarding staff of IANA involvement in for example IETF or other PDP that result in instructions to IANA.

> top-level domains: ICANN, IETF (see RFC 6761), governments (in the case of ccTLDs)

I am very sensitive to words like "governments"...I think we normally talk about "territory" that the ccTLD is linked to. Is a "government" the governing body over a territory, or do "government" imply a "country"?

But I agree with the category.

You also have COR approval as specified in the contact with US Government, but that can be tied under "governments" possibly?

> .ARPA: IAB, IETF (sub-zones, e.g., in-addr.arpa, can involve other players, depending on the sub-zone)

...depending on the sub-zone according to instructions from IAB...

> .INT: ICANN(?) -- this one has always been a bit odd.

Um...yes...

> Out of curiosity, how is the ITU-T policy enforced in the case of e164.arpa?  Is there a contract between the ITU Secretariat and RIPE-NCC?

It is a bit complicated...but that is how it ends up being...

- There are the basic RFCs that specify ENUM
- There are instructions from IAB to RIPE-NCC (synchronized with ITU-T)

<http://www.ripe.net/data-tools/dns/enum/iab-instructions>

- There are ITU-T resolutions
- There is an exchange of letters between ITU-T and RIPE-NCC

And probably more exchanges of documents...

I think you see this best by looking at the ITU version of the setup:

<http://www.itu.int/itudoc/itu-t/circ/01-04_1/105_ww9.doc>

But this is an example where IAB made the decision to have a different entity managing "the parameter" while "just" asking IANA to delegate the e164.arpa domain (as manager of .ARPA) to whatever RIPE-NCC requests it to be.

Detail: All of this work was done (by me and a few others) together with Houlin Zhao, which I do believe will be the new head of ITU.

> I actually think this should be expanded. Each of the terms used in that section probably need to be defined/explained.  E.g., what do "stable" and "predictable" mean in the context of an IANA fram…

Yes please. We have for example that discussion with Unicode Consortium (for correct reasons) all the time, just because we have different view of what "stable" means (when discussing versioning).

> "*That*, Detective, is the right question." -- Dr. Alfred Lanning (deceased), "I, Robot" (the movie)  

;-)

   Patrik

---

From: Jefsey <[email-masked]>
Date: Mon, 27 Jan 2014 04:41:33 +0100

I wish to raise two points of interest (IMHO) in the coming Sao Paulo 
meeting's perspective:

1. http://en.wikipedia.org/wiki/Sandra_Braman
I discover (may she is well known by most of you?) this searcher. Her 
"Internet RFCs as social policy: Network design from a regulatory 
perspective" is a few years old study but it will probably be a kind 
of topics that /1NET people will discuss. Moreover if there is not a 
layer protection by a technical governance.

2. There are convergent indications that GS1 could target its own 
tables in the IANA to support the ONS (the version 2.0.1 of the 
standard was ratified one year ago). After the Unicode convergence 
(langtags, IDNA2008) this could lead ICANN to become a Tables Keeper 
for the whole Internet. This would add to the opposition of many as 
putting more control in American hands.

I would therefore suggest that the IETF maintains its own content of 
IANA tables in a format that would help differentiating file 
hosting/copyright/control and the data/number/name/parameters 
themselves. There is the Dublin Core. Intlnet started working on the 
Versailles Core to describe languages. I would suggest that the IETF 
considers an IETF Uniform Core List and an open data delivery and 
update service for its parameters descriptions and values. So 
everyone could use the parameters directly when embeding them in 
applications, etc. Without a single point of control.

Best
jfc