Opened 9 years ago

Last modified 9 years ago

#352 new defect

Comments

Reported by: rcallon@… Owned by: draft-iab-iana-framework@…
Priority: major Milestone: milestone1
Component: draft-iab-iana-framework Version: 1.0
Severity: Active WG Document Keywords:
Cc:

Description

First of all a meta-issue: This document of course does not touch on the “800-pound bear in the living room” issue of who the IANA functions should report to / be contracted by. I think that this is appropriate. It would be premature to think about this issue and we need to nail down what the functions need to be without fighting this particular 800 pound bear (which the very serious politicians will be wrestling over).

Second paragraph on page 5 (second to last paragraph in section 1.3): This is one very long and awkward sentence. I think that is should be split into two sentences. For example:

This document may be read independent of [RFC6220] and
[RFC7020] -- which document the requirements specific to a subset of
all current IANA function Internet registries, namely the IETF
protocol parameter registries and the Internet Numbers Registry
System respectively. However these RFCs provide context and examples
of the subject matter of this document.


I wonder whether the last paragraph of section 1.3 should be its own section (1.4), since it is still part of the introduction (section 1) but somewhat different from the rest of what is in section 1.3.

I think that the first paragraph of section 2 should really be two paragraphs, with a paragraph break after the first sentence.

The first paragraph of section 2.1 (The policy development role) has an unmatched quotation mark (“) and a missing period (.).

First sentence of section 3. Does this talk about “Any IANA framework…” or “The IANA framework…”?

First paragraph of section 4.1. This currently reads:

For many registries there is a de-facto separation of the Policy
Development and the Evaluation coordination that takes place at
implementation. While this has never been an explicit requirement,
it seems that splitting those roles can surface a lack of clarity in
the policies. In addition, having the policy setting, oversight and
evaluation roles separated prevents the evaluation role from being
burdened with perceptions of favoritism and unfairness.


The second sentence is IMHO nearly incomprehensible. Also, can’t evaluation still be burdened with perceptions of favoritism even if it is separated from the other roles, and the separation is really useful to provide clear focus on this role without confusing it with the other roles? Finally, the first sentence talks about separating two roles, where the third sentence talks about three roles (adding oversight as a third role).

I think that this paragraph needs some work.

Section 4.5: Using slightly different terminology than RFC 6220 seems unfortunate, and may make this all look at bit flakey (which is a perception that we don’t want given the current climate). If this is necessary, I wonder whether RFC 6220 needs to be redone to make its terminology consistent with this document.

The title of section 8 has a minor typo.

Thanks, Ross

Change History (1)

comment:1 Changed 9 years ago by bernard_aboba@…

[John Klensin]

I have a few comments on draft-iab-iana-framework-01:

First of all a meta-issue: This document of course does not
touch on the "800-pound bear in the living room" issue of who
the IANA functions should report to / be contracted by. I
think that this is appropriate. It would be premature to think
about this issue and we need to nail down what the functions
need to be without fighting this particular 800 pound bear
(which the very serious politicians will be wrestling over).

While I believe that issue should be kept separate, along with
the closely-related issue of who has the right to authorize new
registries, "premature" may be going too far. The reality is
that we are stirring those coals as do a number of I* actions
including the Montevideo declaration, the Brazil meeting
announcement/ plans, and so on. Olaf, with my help, has been
trying very carefully to walk around such topics as the
convenient fictions that underlie the US Govt's claims to the
authority to create ICANN and give it that contract (as distinct
from the US Govt's claim to "own" the pre-1998 registries, which
are much stronger). As I just told another interested parties,
it is probably too late for the details of that history to have
any effect on what is going on now... unless it were someone's
purpose to further challenge the legitimacy of the US Govt's
behavior, to [further] undermine ICANN's credibility, or to
mount an attack on Hillary Clinton.

Second paragraph on page 5 (second to last paragraph in
section 1.3): This is one very long and awkward sentence. I
think that is should be split into two sentences. For example:

This document may be read independent of [RFC6220] and
[RFC7020] -- which document the requirements specific to a

subset of all current IANA function Internet registries,
namely the IETF protocol parameter registries and the
Internet Numbers Registry System respectively. However
these RFCs provide context and examples of the subject
matter of this document.

If one wants to fine-tune that sort of language (I've done a
bit, but not a comprehensive editing job), one might further
improve the above by making even more sentences and fewer
complex subordinate clauses, e.g.,

This document may be read independently of [RFC6220] and
[RFC7020]. Those documents identify the specific
requirements for the IETF Protocol Parameter registries
and the Internet Numbers Registry System. As such, they
provide context and examples for some of the subject
matter of this document. Those requirements apply only to
those subsets of the current collection of IANA function
Internet registries.

or something more like that. However, while I've made other
suggestions earlier, I suggest that the IAB has a team of highly
skilled professional editors available to it, and that it would
probably be more efficient to turn the draft over to the RFC
Editor staff at some stage, let them have a go at it, and have
us fine-tune or re-tune whatever they produce.

...

The second sentence is IMHO nearly incomprehensible. Also,
can't evaluation still be burdened with perceptions of
favoritism even if it is separated from the other roles, and
the separation is really useful to provide clear focus on this
role without confusing it with the other roles?

That issue is one of the key reasons --other than pure
record-keeping-- why the IANA function was made largely
independent of the IAB from more or less the beginning. We
discarded the advantages of that arrangement in favor of more
control when the IESG started setting itself, and the IETF
community, as the arbiters of what values actually got
registered, the appointer and overseer of Experts, and so on.

...

Several of your editorial observations overlap with things I
already pointed out to Olaf, but you caught some additional
things. More eyes definitely help although I wonder whether we
are at the point where asking the RFC Editor to make a pass
might be efficient.

best,

john

Note: See TracTickets for help on using tickets.