Subject: [Ianaplan] IANA Considerations processing

From: S Moonesamy <[email-masked]>
Date: Tue, 29 Jul 2014 07:34:38 -0700

Hello,

There seems to be some disagreement about the work performed by IANA 
in respect to the IANA Considerations in IETF RFCs.  As an example I 
mentioned IANA Considerations in a review (see thread at 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10651.html 
) and mentioned that:

    The IANA Considerations are processed by the RFC Editor and IANA,
    and they will make sure that the registry is properly populated.

The word "clerical" is defined as "concerned with or relating to work 
in an office, especially routine documentation and administrative 
tasks".  That word is sometimes used to described the processing of 
the IANA Considerations section.  The IANA reviews are similar to:

  "IESG/Authors/WG Chairs:

   IANA has reviewed draft-ietf-httpbis-p2-semantics-24.  Authors should
   review the comments and/or questions below.  Please report any inaccuracies
   and respond to any questions as soon as possible.

   IANA's reviewer has the following comments/questions:

   NOTE: several entries that are part of the fourth action
   (Content-Coding registrations) have draft-ietf-httpbis-p1-messaging
   as their reference. If we're to update those entries with an RFC number
   once draft-ietf-httpbis-p1-messaging has been assigned one, these
   entries need to be requested in the IANA Considerations section for
   draft-ietf-httpbis-p1-messaging, rather than this document. We have no
   other mechanism to ensure that reference updates aren't overlooked.

   IANA understands that, upon approval of this document, there are four
   actions which IANA must complete. The third action must be approved by
   the designated expert for Permanent Message Header Field Names.

   [other details removed]

   Note:  The actions requested in this document will not be completed until
   the document has been approved for publication as an RFC. This message is
   only to confirm what actions will be performed."

As this is an IETF mailing list there would be people who can express 
their disagreement if the above is incorrect.  The work is 
non-technical.  Some people describe it as policy work.

When I have a problem with the registration process I discuss the 
matter (informally) with the IETF Chair (see 
http://www.ietf.org/mail-archive/web/ietf/current/msg87222.html 
).  As the persons reading this mailing list are familiar with the 
IETF I don't have to get into the details of the IETF Standards Process.

Regards,
S. Moonesamy

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 29 Jul 2014 11:46:00 -0400

Hello,

I’d like to offer a refinement to your words on one point that I think is important.

On Jul 29, 2014, at 10:34 AM, S Moonesamy <[email-masked]> wrote:

> 
> There seems to be some disagreement about the work performed by IANA in respect to the IANA Considerations in IETF RFCs.  As an example I mentioned IANA Considerations in a review (see thread at http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10651.html ) and mentioned that:
> 

…..
> 
> As this is an IETF mailing list there would be people who can express their disagreement if the above is incorrect.  The work is non-technical.  Some people describe it as policy work.

I don’t disagree, but….

I wouldn’t characterize this as “non-technical,” in that the impact of the decisions made stays within some pretty strict limits on the clarity and interoperability of the protocol in question. If it goes outside of those limits, the doc goes back to the ADs/chairs/WG.

But, more importantly to why we’re here: I know people sometimes call things “policy” when they mean “requiring some insight and judgment,” but I think arguing that this is “policy” is almost meaningless. The fact that it’s not mindless and can’t be fully automated (we’ve automated the stuff that can be) doesn’t mean it’s “policy” in the way the word is usually used in discussions at layer 9+ in the protocol stack. I’d describe almost all of it as “procedure” for resolving ambiguity or misunderstanding about how IANA is to carry out the “policy” already established by the IETF’s processes (see Patrik’s remarks on “policy provider” and “policy implementer”).

> When I have a problem with the registration process I discuss the matter (informally) with the IETF Chair (see http://www.ietf.org/mail-archive/web/ietf/current/msg87222.html ).  As the persons reading this mailing list are familiar with the IETF I don't have to get into the details of the IETF Standards Process.

There’s in fact quite a lot more to the process than taking it up informally with the IETF Chair; Jari is brilliant, but not that scalable. :)  The point is that there’s plenty of *established* procedure (in fact some argue there’s too much), and policy for handling it if the procedures don’t work. 

None of this is perfect, but I think it’s important in this discussion to remember that none of it required participation from NTIA, or from ICANN outside of its IANA role as specified by the IETF, to get done. AFAICT, NTIA’s absence from the picture won’t have the slightest impact on it, whether we call it “policy” or not.

thanks,
Suzanne

---

From: S Moonesamy <[email-masked]>
Date: Tue, 29 Jul 2014 09:59:45 -0700

Hi Suzanne,
>one point that I think is important.

Ok.

>I don’t disagree, but….
>
>I wouldn’t characterize this as “non-technical,” 
>in that the impact of the decisions made stays 
>within some pretty strict limits on the clarity 
>and interoperability of the protocol in 
>question. If it goes outside of those limits, 
>the doc goes back to the ADs/chairs/WG.

I'll exclude names and numbers in my comment as 
it may be more straight-forward.

The ICANN employees who review that section in 
Internet-Drafts do not consider the clarity or 
interoperability of the protocol.  The Area Directors likely review all that.

>But, more importantly to why we’re here: I know 
>people sometimes call things “policy” when they 
>mean “requiring some insight and judgment,” but 
>I think arguing that this is “policy” is almost 
>meaningless. The fact that it’s not mindless and 
>can’t be fully automated (we’ve automated the 
>stuff that can be) doesn’t mean it’s “policy” in 
>the way the word is usually used in discussions 
>at layer 9+ in the protocol stack. I’d describe 
>almost all of it as “procedure” for resolving 
>ambiguity or misunderstanding about how IANA is 
>to carry out the “policy” already established by 
>the IETF’s processes (see Patrik’s remarks on 
>“policy provider” and “policy implementer”).

I used the word "policy" as IETF participants may 
be familiar with it and some of them usually 
switch off when they hear that word. :-)  I 
vaguely recall Patrik's remarks; I'll have to go 
back and read his message (I probably agree with what he wrote).

>There’s in fact quite a lot more to the process 
>than taking it up informally with the IETF 
>Chair; Jari is brilliant, but not that scalable. 
>:)  The point is that there’s plenty of 
>*established* procedure (in fact some argue 
>there’s too much), and policy for handling it if the procedures don’t work.

There is actually a process.  I usually prefer to 
discuss a matter informally, and publicly, 
instead of invoking process as it takes less time 
and the outcome is the same.  I agree that there 
are times when the procedures don't work.  Jari 
already commented about the escalation path on a non-IETF mailing list.

>None of this is perfect, but I think it’s 
>important in this discussion to remember that 
>none of it required participation from NTIA, or 
>from ICANN outside of its IANA role as specified 
>by the IETF, to get done. AFAICT, NTIA’s absence 
>from the picture won’t have the slightest impact 
>on it, whether we call it “policy” or not.

Yes.

If the IESG were to say no to my request I don't 
see what the NTIA could have done [1].  I don't 
think that any body in that part of the picture would be bothered to help me.

Regards,
S. Moonesamy

1.  It is not part of the escalation path.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Jul 2014 08:51:09 +1200

On 30/07/2014 02:34, S Moonesamy wrote:
...
> non-technical.  Some people describe it as policy work.

I disagree. Sometimes, IANA detects technical errors during their review
of a draft. Some of their regular work is also highly technical; even the
"clerical" part needs technical understanding. It's a bit rude to suggest
otherwise, and I would hate to have IANA stuff who were not technically
competent.

It definitely isn't policy work, as far as the IETF-IANA function goes.
That's a matter of definition. Of course, sometimes the IANA staff
*apply* policy, but that is quite different from *making* policy.

   Brian

---

From: S Moonesamy <[email-masked]>
Date: Tue, 29 Jul 2014 14:38:33 -0700

Hi Brian,
>otherwise, and I would hate to have IANA stuff who were not technically

 From a message posted to the ietf@ mailing list:

   "The IETF uses a high-tech clerical service called the IANA"

There is also a message at 
http://mm.icann.org/pipermail/ianatransition/2014/000784.html where I 
read the following words:

    "... IANA is a clerical job."

I am okay with using a different word if the word "clerical" is 
considered as a bit rude.

Yes.

Regards,
S. Moonesamy

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 29 Jul 2014 18:02:12 -0400

> considered as a bit rude.

I don't think that was Brian's point at all.  I think, rather, his
point is that some people appear to be assuming a "merely" in front of
"clerical", or assuming somehow that policy work is more important
than the implementation of that policy.  In the countries with which I
am familiar, however, the tax authorities generally have a description
for people and businesses who have not attended correctly to
book-keeping: "in trouble".  

If the registration job that IANA was doing weren't _important_, we
wouldn't ask anyone to do it at all.  Instead, it is of critical
importance, but very narrow in scope.  What I think you are hearing
when people say, "IANA is a clerical job," is an attempt to limit that
scope so as to avoid a number of the policy-making questions that
several people seem to want to import to the NTIA/IANA transition
discussion.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Jul 2014 12:05:31 +1200

> several people seem to want to import to the NTIA/IANA transition

Exactly.

   Brian

---

From: S Moonesamy <[email-masked]>
Date: Tue, 29 Jul 2014 16:04:15 -0700

Hi Andrew,
>book-keeping: "in trouble".

Thanks for explaining the above.  I saw your message to a non-IETF 
mailing list. :-)

>several people seem to want to import to the NTIA/IANA transition

I agree that if a job wasn't important we would not ask anyone to do 
it.  I would avoid the word "critical" in a description of the 
registration job.

Regards,
S. Moonesamy

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 30 Jul 2014 07:44:00 +0200

On 30 jul 2014, at 01:04, S Moonesamy <[email-masked]> wrote:

> I would avoid the word "critical" in a description of the registration job.

I disagree. I do think the words works very well together.

Many registration jobs are very critical. Not only the work done by IANA, but in fact quite a large number of registration jobs are of ultimate criticality. Everything from counting the number of humans that have entered an airplane to the job today done by software to count the number of shares (and who owns each one of them) on the stock market. Quite often when you have a registration job that is critical you have multiple methods to come to the same conclusion, and then you compare the result. If the result differs, then there is some error somewhere.

But it is still a registration job.

   Patrik

---

From: S Moonesamy <[email-masked]>
Date: Wed, 30 Jul 2014 00:34:50 -0700

Hi Patrik,
At 22:44 29-07-2014, Patrik Fältström wrote:
>Many registration jobs are very critical. Not 
>only the work done by IANA, but in fact quite a 
>large number of registration jobs are of 
>ultimate criticality. Everything from counting 
>the number of humans that have entered an 
>airplane to the job today done by software to 
>count the number of shares (and who owns each 
>one of them) on the stock market. Quite often 
>when you have a registration job that is 
>critical you have multiple methods to come to 
>the same conclusion, and then you compare the 
>result. If the result differs, then there is some error somewhere.
>

Critical is a matter of context.  It could be 
viewed in terms of persons affected or, for 
example, businesses affected by an error.  The 
Stockholmsbörsen does not affect me directly; I 
don't describe it as critical as I don't know how 
it would affect me.  I might have to look into 
whether there are ways for me to influence its 
decisions if it affects me.  As another example, 
the United States Department of Commerce stated 
the following: "Critical to the DNS is the 
continued performance of the Internet Assigned 
Numbers Authority (IANA) functions".

Critical can be complex when there are geopolitical considerations.

Regards,
S. Moonesamy