Subject: Re: [apps-discuss] Registration policy for the Permanent Message Header Field Names registry

From: Pete Resnick <[email-masked]>
Date: Tue, 2 Oct 2012 09:50:54 -0700

Folks, I'm having trouble discerning consensus from this conversation, 
so I want to simplify a bit. Currently, IANA is requiring Expert Review 
for *all* registrations, including things published as RFCs. That's not 
what 3864 *says* to do: It is quite clear (whatever the intent) that 
RFCs (whatever stream) don't go for Expert Review:

    The registration template is submitted for incorporation in one of
    the IANA message header field repositories by *one of the following
    methods*:

And the two methods specified are "RFC" and "Expert Review".

So, here are the choices: (And I do *not* want anybody to simply choose 
one; see below.)

a) IANA should continue requiring Expert Review for all registrations.

b) IANA should require Expert Review for registrations that don't come 
as part of an RFC.

c) IANA should require Expert Review for registrations that don't come 
as part of an IETF stream RFC.

For each of the above, I'd like to hear from folks answers of the form:

- Yeah, this is OK with me.
- No, this would be actively bad and can not be what we tell IANA is the 
current policy.

Of course, if you say "actively bad", I'd also like to hear the reason. 
Potential reasons are "that's not what 3864 says and not following the 
rules is bad" or "that will let bad things be registered" or "that will 
slow down important things from being registered in a timely fashion".

The "actively bad" answers are the ones I am most interested in.

And please keep in mind that we are telling IANA what the policy will be 
until we write a new document that is clearer about our intent. This is 
a stop-gap until then.

Thanks.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: John C Klensin <[email-masked]>
Date: Tue, 02 Oct 2012 13:28:12 -0400

--On Tuesday, October 02, 2012 09:50 -0700 Pete Resnick
<[email-masked]> wrote:

> Folks, I'm having trouble discerning consensus from this
> conversation, so I want to simplify a bit. Currently, IANA is
> requiring Expert Review for *all* registrations, including
> things published as RFCs. That's not what 3864 *says* to do:
> It is quite clear (whatever the intent) that RFCs (whatever
> stream) don't go for Expert Review:
>... 
> So, here are the choices: (And I do *not* want anybody to
> simply choose one; see below.)

See comment at end, especially since you use language like "all
registrations".

> a) IANA should continue requiring Expert Review for all

- Yeah, this is OK with me and is, I believe, the most desirable
solution, especially if the Expert is smart enough to consider
whatever level of consensus an RFC might have to as part of the
evaluation (and certainly part of a community review process and
evidence that the proposal has been reviewed).  I'd also expect
Experts to pay exceptionally timely attention to things coming
to them as RFC in last-stage consideration (again, see comment
at end).

> b) IANA should require Expert Review for registrations that
> don't come as part of an RFC.

- Actively bad unless agreements are made with other streams,
especially the Independent one, about considering the Expert
among the document reviewers.  We really need to be sure someone
with expertise in the subject matter looks at these things.
 
> c) IANA should require Expert Review for registrations that
> don't come as part of an IETF stream RFC.

-- Less bad.  As long as the IESG continues to insist on an IETF
Last Call for all IETF Stream documents (RFC 2026 does not
require it for Individual Submission Informational or
Experimental documents), it is plausible to assume that someone
will call the registration to the Expert's attention, causing
this option to be not much different in practice than (a).  On
the other hand, I don't need to tell you how variable the
quality of review and documents reaching the IESG actually is,
so there is some risk.

>...
> And please keep in mind that we are telling IANA what the
> policy will be until we write a new document that is clearer
> about our intent. This is a stop-gap until then.

Pete, most of this discussion has focused on "what 3864 says"
and on when we are going to get a 3864bis and what is in it.  I
think that is incorrect.  I think the real issue here is in RFC
5226 and its failure to either explicitly discuss the
relationship between the "Expert Review" category and requests
that satisfy one or more of the "RFC Required", "IETF Review",
"Standards Action", and "IESG Approval" ones or to spell out how
combinations can and should be specified.  For example, if
something is identified as "IESG Approval" and the document that
modifies the registry is approved on the standards track, is
IANA required to demand that the IESG pass a separate resolution
approving the change?  To me, that would be a new low in the
"process over good sense" battle, but some of the comments on
this thread would predict exactly that.

So, IMO, we need to fix 5226 sooner or later.  I'll happily
leave it up to the IESG whether that fix must also explicitly
update all relevant registration documents including 3864.

    john

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Oct 2012 13:40:34 -0400

On Tue, Oct 2, 2012 at 12:50 PM, Pete Resnick <[email-masked]>wrote:

> Folks, I'm having trouble discerning consensus from this conversation, so
> I want to simplify a bit. Currently, IANA is requiring Expert Review for
> *all* registrations, including things published as RFCs. That's not what
> 3864 *says* to do: It is quite clear (whatever the intent) that RFCs
> (whatever stream) don't go for Expert Review:
>
>
> a) IANA should continue requiring Expert Review for all registrations
>

OK with that

> b) IANA should require Expert Review for registrations that don't come as
> part of an RFC.
>

No, I think that would be bad. I see the role of expert review as being
strictly limited to avoiding unnecessary duplication and avoiding
unintentional collisions. For the expert to achieve those functions they
really need to be tracking all the documents proposing headers regardless
of source. So expert review for this case is no additional effort.

I see expert review as beneficial in this case for the same reason that we
have Gen Art review, SECDIR review etc. The fact that a proposal comes from
inside the IETF does not mean that the authors understand the HTTP issues
involved or describe them effectively. I care rather more about IETF
documents and other RFCs being reviewed than non-RFCs.

In particular I care about things like the consistency of the description
of the headers.

> c) IANA should require Expert Review for registrations that don't come as
> part of an IETF stream RFC.
>

No, for same reason as above.

> until we write a new document that is clearer about our intent. This is a
> stop-gap until then.
>
> Thanks.
>
> pr
>
> --
> Pete Resnick<http://www.qualcomm.**com/~presnick/<http://www.qualcomm.com/~presnick/>
> >
> ______________________________**_________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/apps-discuss<https://www.ietf.org/mailman/listinfo/apps-discuss>
>

-- 
Website: http://hallambaker.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Oct 2012 13:43:36 -0400

Looking at John's response it is clear he interpreted the options
differently. I was interpreting b and c as 'only require'.

---

From: t.petch <[email-masked]>
Date: Tue, 2 Oct 2012 18:53:10 +0100

---- Original Message -----
From: "Pete Resnick" <[email-masked]>
To: "Apps Discuss" <[email-masked]>
Sent: Tuesday, October 02, 2012 5:50 PM

> a) IANA should continue requiring Expert Review for all registrations.

Bad idea - puts an additional load on what may be a scarce resource.

> b) IANA should require Expert Review for registrations that don't come

Poor, second best - some tracks generate RFC with little or no review
and I am not saying that this is so trivial that that would be ok.

> as part of an IETF stream RFC.

Yes, preferred outcome; ensures adequate review in all cases.

Tom Petch

> _______________________________________________
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 03 Oct 2012 09:49:31 +0900

Pretty much exactly what John said.

Regards,   Martin.

P.S.: Just for Pete, who doesn't like simple "+1"s, I have carefully 
read the mails in this thread and have expressed the same opinion 
before. I just wanted to save some useless typing.

P.P.S.: If we end up going with a), which I hope we will, then the 
overall change from discussion is exactly nil. I'd strongly suggest that 
next time a similar question comes up, the powers that be first ask what 
the overall potential benefits and costs of opening a discussion are. As 
far as I'm aware, what's currently done has produced exactly zero 
wrong/problematic outputs, and hasn't been challenged by anybody 
affected. It may be a tiny bit more work for IANA, but they are highly 
optimized for this kind of work. On the other hand, this discussion has 
used time and space on this list which I'm sure could have been used for 
other, more productive discussions. [Sorry if this sounded like a rant, 
but I had to get that out.]

Regards,   Martin.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 2 Oct 2012 22:06:16 -0400

> I'd strongly suggest that next time a
> similar question comes up, the powers that be first ask what the overall
> potential benefits and costs of opening a discussion are. As far as I'm
> aware, what's currently done has produced exactly zero wrong/problematic
> outputs, and hasn't been challenged by anybody affected. It may be a tiny
> bit more work for IANA, but they are highly optimized for this kind of work.
> On the other hand, this discussion has used time and space on this list
> which I'm sure could have been used for other, more productive discussions.
> [Sorry if this sounded like a rant, but I had to get that out.]

No, that's a fair cop.  On the other hand, though, the IETF works on
consensus.  Pete and I certainly could have just made an executive
decision.  For me, rough consensus is better.

Barry

---

From: Ned Freed <[email-masked]>
Date: Tue, 02 Oct 2012 15:21:30 -0700 (PDT)

> So, here are the choices: (And I do *not* want anybody to simply choose

At this point I think a few words about the purpose of this registry are
in order.

Not to belabor the obvious, but different registries exist for different
reasons. A registry of standardized SMTP extensions exists in order to
provide an authoritative list of same. It's a matter of convenience, not
providing new information.

The media types registry exists for several purposes, including to establish
common naming conventions and to provide a little information about semantics
and possible security issues. But one of the things it doesn't do in general is
provide descriptions or even pointers to descriptions of the media type.

So why do we have, or even want, a header registry? Again, I'm not especially
interested in intent, but what I want to see from such a registry is rather
more than a reiteration of what the IETF has chosen to specify in an RFC.

What I would like, although I recognize that there's precious little chance of
it happening at this point, is some information about some subset - even  a
small subset - of the myriad headers that are in use out there.

As a small example among many, yesterday I received a message from the
ietf-charsets list with the following block of headers on it:

X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-Originating-IP: [131.107.147.4]
X-OrganizationHeadersPreserved: BY2PRD0310HT003.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%MROCHEK.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IT.AOYAMA.AC.JP$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IANA.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14HUBC102.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC102.redmond.corp.microsoft.com
X-OriginatorOrg: microsoft.com
X-Greylist: IP, sender and recipient auto-whitelisted,
 not delayed by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.74]);
 Mon, 01 Oct 2012 21:03:23 +0000 (UTC)

(I'll spare you the entire thing, which was over 100 lines long,) This sort of
thing is now par for the course. And while I have no doubt that a lot of this
is badly designed, ill-conceived, and even irrelevant, there are times when
knowing what it means is actually important.

To this end, added review beyond making sure what is there is coherent is
a bad idea. And with that in mind...

> a) IANA should continue requiring Expert Review for all registrations.

Actively bad. Waste of resources and too high a barrier. It doesn't help
that it isn't what the rules say.

> b) IANA should require Expert Review for registrations that don't come

OK with me. And as I said before, this needs to focus on the registration, not
what it describes. That can be total crap. In fact the ones describing complete
crap are sometimes the ones that are important, because I haven't found that
customers demanding interoperability with something find "but it's crap" to be
an acceptable excuse.

> as part of an IETF stream RFC.

Actively bad. These documents have received sufficient review by the time
they get this far, there is no need to require more.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Tue, 02 Oct 2012 22:06:27 -0700 (PDT)

> > outputs, and hasn't been challenged by anybody affected.

As always with registration processes, I'm more concerned with the outputs that
were not produced than the ones that were.

				Ned

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 03 Oct 2012 14:55:02 +0900

Hello Ned,

> were not produced than the ones that were.

Good point. Actually, with "zero wrong/problematic outputs", I intended 
to include both "false positives" and "false negatives", but that was 
probably not clear enough.

Anyway, I don't think that there is a single case that a registration 
contained in an RFC was rejected because it didn't manage to pass the 
expert review, so I think in the case of hand, this consideration is 
actually irrelevant in practice.

Regards,   Martin.

---

From: Ned Freed <[email-masked]>
Date: Tue, 02 Oct 2012 23:19:02 -0700 (PDT)

> actually irrelevant in practice.

In the case of RFCs from the IETF, probably true. It's harder to say for
indepedent stream documents and non-RFC registrations, but it's still likely to
have negligible effect, especially at this late date.

So yes, John is correct in saying that this really is little benefit
for the cost. Unless, perhaps we use it as a vehicle to examine our
overall approach to registration policies.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Wed, 03 Oct 2012 09:04:36 -0400

> they get this far, there is no need to require more.

Ned,

I'm not sure we disagree, but let me explain what I was trying
to say in case it helps.

(0) For the present/immediate situation, I believe that Graham
should send in a signoff "for the avoidance of doubt", IANA
should observe that it has _both_ an draft RFC and an Expert
signoff in hand, they should smile happily, and we should move
on.  When good sense is working, I don't think we should be
trying to invent hair-splitting rules to solve a non-problem,
especially on an urgent basis.

(1)  At the risk of drifting out of the Header Registry-specific
discussion, I think it would be wise to revise/update RFC 5226
to _require_ that any document that specifies "Expert Review"
contain a statement about what that review is supposed to cover.
Just as you suggest there are different types of registries with
different purposes, I think there are differences among reviews
for coherence, for accuracy, for conformity to a particular set
or rules or guidelines, for taste, etc.  It would probably also
be useful for a 5226bis to divide Expert Review into two
categories: "expert consultation required" and "expert approval
required", where the former would cause IANA to ask the Expert
"have you looked at this and delivered any comments" and not "is
this ok".  In the former case, the Expert Review is definitely
non-blocking even though it might result in a short delay while
the proposer decides whether or not to revise the
application/request.    I hope we can trust the IESG (reinforced
by a few appeals if needed) to both enforce such a specification
requirement and to select and retain only those experts who are
willing to toe the line.

(2) Graham has, as far as I can tell, been applying exactly the
test for coherency that we are advocating.   While we might want
to give guidance to his potential successors, we are probably in
an "if it ain't broke, don't fix it" situation right now.

(3) The reason I'm advocating having the Expert take a look at
_all_ potential new entries in this particular registry is that
Graham (or you, or me, or most or all of the participants in
this discussion) might have a better eye for what is or is not
coherent than the potential registrant of, e.g., "X-FUSSP:" or
an ISE, IAB, IRTF, or even IETF review process that is
concentrating on other things.  As long as the Expert is just an
extra set of skilled eyes looking at the registration request
and doesn't have to do much more than confirm that he or she has
looked at it, and as long as the IESG is willing to deal with
non-feasant Experts, I think such a review requirement falls
into the "harmless at worst" category.

best,
   john

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 03 Oct 2012 15:04:53 +0100

On 02/10/2012 17:50, Pete Resnick wrote:
> so I want to simplify a bit. Currently, IANA is requiring Expert 
> Review for *all* registrations, including things published as RFCs. 
> That's not what 3864 *says* to do: It is quite clear (whatever the 
> intent) that RFCs (whatever stream) don't go for Expert Review:
>
> So, here are the choices: (And I do *not* want anybody to simply 
> choose one; see below.)
>
I think doing a) is fine as a stop-gap, as the replacement RFC will be 
done very quickly, right ;-). I don't think there are that many 
registrations coming from RFCs anyway for this to make a big difference. 
And nobody seem to complain about Expert Review for these...

> as part of an IETF stream RFC.
I am actually not convinced that registrations from other streams always 
have adequate reviews of this aspect, so I think Expert review for them 
is fine. Again, there are very very very few documents from other 
streams trying to register new header fields, so I don't think this is 
likely to make a significant difference. This is my preferred option.

> - No, this would be actively bad and can not be what we tell IANA is 
> the current policy.
>
> Of course, if you say "actively bad", I'd also like to hear the 
> reason. Potential reasons are "that's not what 3864 says and not 
> following the rules is bad" or "that will let bad things be 
> registered" or "that will slow down important things from being 
> registered in a timely fashion".
>
> And please keep in mind that we are telling IANA what the policy will 
> be until we write a new document that is clearer about our intent. 
> This is a stop-gap until then.

---

From: Ned Freed <[email-masked]>
Date: Wed, 03 Oct 2012 08:01:39 -0700 (PDT)

> I'm not sure we disagree, but let me explain what I was trying

I think there's some disagreement on some specific points, but I doubt
these points are worth the time we're spending on them.

> especially on an urgent basis.

I don't think that's really necessary and probably a waste, and it isn't what
was called for, but the overarching point you made - that this just isn't that
big a deal - overrides any interest I have in arguing about it further.

> contain a statement about what that review is supposed to cover.

I have no problem with doing this, but on reflection, I doubt that
it will solve the problem.

I think this is mostly a matter of attitude, and attitudes are hard to
adjust with text in documents.

These are "our" registries, and as such we want them to be "good" registries.
And it's easy to take "good" as meaning "not full of junky crap".

But that's the problem: This is a case of a registry that *needs* to be full of
junky crap. Because there is an absolutely staggering amount of junky crap out
there. A lot of it is noise and can be ignored, but some of it isn't. And it
would sure be nice if we could capture some of that subset - even if that
exposes us to registering a bunch of useless stuff - somewhere.

And this cuts both ways: In some sense it doesn't matter what Graham or whoever
does the reviews does, because it's the perception of difficulty that
determines whether or not people bother. We saw this in the early days of media
types, where the reality was IANA would let pretty much anhything through, but
since the rules looked difficult, people didn't try (and stated publicly that
this was in fact what they were (not) doing).

And again, just as the effort to fix the media type registry in some sense came
too late, it's probably too late to really solve this problem for headers. (In
fact the lateness of the creation of the registry probably made it impossible
from the get-go.) So this is really something that we need to keep in mind for
the next time, because there's bound to be one.

> requirement and to select and retain only those experts who are

All good ideaas.

> an "if it ain't broke, don't fix it" situation right now.

See above. I don't think Graham's actions were ever part of the problem.

> into the "harmless at worst" category.

That's a valid point, although to be fair, I'd say that the FUSSP risk is
greater in the indepedent stream submission process than in the header
registry.

				Ned

---

From: John Leslie <[email-masked]>
Date: Wed, 3 Oct 2012 13:18:24 -0400

> these points are worth the time we're spending on them.

   +1

>... 
> These are "our" registries, and as such we want them to be "good"
> registries. And it's easy to take "good" as meaning "not full of
> junky crap".
> 
> But that's the problem: This is a case of a registry that *needs* to be
> full of junky crap. Because there is an absolutely staggering amount of
> junky crap out there...

   +1

   This doesn't deserve much more discussion; but I'd like to put in a
plug for either

1) somebody volunteers to write the RFC to update 3864, or

2) we encourage IANA to make sure Expert Review is no more gating than
   3864 calls for it to be.

   There is certainly no problem if IANA wants to ask the Expert to
review _anything_ proposed for any registry and pass those comments to
the RFC Editor.

   If somebody does volunteer to update 3864, I have no strong preference
which path they take.

   IMHO, the horse left the barn so long ago that it's not worth the
effort to try to fix this.

--
John Leslie <[email-masked]>

---

From: Barry Leiba <[email-masked]>
Date: Wed, 3 Oct 2012 13:38:58 -0400

Ned says...
> exposes us to registering a bunch of useless stuff - somewhere.

Indeed, and this is why I've been pushing for less-strict registration
policies in general, and even more consideration of First Come, First
Served.

There are registries -- perhaps many of the first ones created, back
when, and also a number since -- where we're handing out limited
resources.  If you want one bit out of eight or sixteen or 32 to be
assigned to you, we'd better make sure you have a good case.
Ethertypes and port numbers have that aspect, and also have
interoperability issues.

But when we're talking about long character strings that
implementations can ignore at will, there's no reason to be strict,
and, as Ned says, if we wind up with a registry full of stuff no one
cares about, at least we have a list of what's out there so people can
avoid colliding with it, and can perhaps find the documentation for
something obscure when they look for it (though for that latter,
Google may have supplanted IANA as the place to go).

Whatever we decide for this case, I encourage everyone to consider
this in the general situation: When you're writing IANA Considerations
sections, and you're creating a new registry, and the resource you're
registering has an essentially unlimited namespace, consider a
registration policy that encourages registrations above one that makes
it harder and is discouraging.

Barry

---

From: John C Klensin <[email-masked]>
Date: Wed, 03 Oct 2012 13:43:46 -0400

--On Wednesday, October 03, 2012 13:18 -0400 John Leslie
<[email-masked]> wrote:

>> I think there's some disagreement on some specific points,
>> but I doubt these points are worth the time we're spending on
>> them.
> 
>    +1

Agree to that too, but Pete felt a need to ask the question.

>> ... 
>> These are "our" registries, and as such we want them to be
>> "good" registries. And it's easy to take "good" as meaning
>> "not full of junky crap".
>> 
>> But that's the problem: This is a case of a registry that
>> *needs* to be full of junky crap. Because there is an
>> absolutely staggering amount of junky crap out there...
> 
>    +1

yep

>...
>    There is certainly no problem if IANA wants to ask the
> Expert to review _anything_ proposed for any registry and pass
> those comments to the RFC Editor.
>...

>    IMHO, the horse left the barn so long ago that it's not
> worth the effort to try to fix this.

Yes.  But part of what started this discussion (oversimplified
for brevity) is that a standards-track document that specified
some registrations went in.  During Last Call, IANA essentially
said "registry says 'Expert Review' and we haven't heard from
the expert".   That is ok; it is their job.

However, that is precisely why I recommended that Graham simply
do a pro-forma review and send IANA a note that says "yes, I've
reviewed this and it is ok".  Silly?  Yes.  Should it be
unnecessary?  IMO, also yes.  But it gets the issue completely
out of the critical path for that document and lets us have any
discussion we need to have after there is actually a draft
3864bis and/or 5226bis (and, yes, we should be discussing parts
of this in the context of  draft-leiba-cotton-iana-5226bis) in
front of us.

  john

---

From: John C Klensin <[email-masked]>
Date: Wed, 03 Oct 2012 14:00:56 -0400

--On Wednesday, October 03, 2012 13:38 -0400 Barry Leiba
<[email-masked]> wrote:

>...
> Whatever we decide for this case, I encourage everyone to
> consider this in the general situation: When you're writing
> IANA Considerations sections, and you're creating a new
> registry, and the resource you're registering has an
> essentially unlimited namespace, consider a registration
> policy that encourages registrations above one that makes it
> harder and is discouraging.

Barry,

Violent agreement.

However, I think there is a role for two things with at least
some registries, neither of which makes registration hard.

(1)  A list/ description of things that ought to
	("SHOULD" ?) be included with the registration if
	possible, making sure that is a different list from
	whatever minimal stuff we absolutely insist on.
	
(2) An Expert _Review_ process (not an Expert Approval
	one), focused more on clarity and coherency than on
	technical merit,  that gives someone with some
	perspective and experience an opportunity to read the
	proposed registration and provide comments about how it
	might be improved or clarified.

If those who request the registration ignore the list and pay no
attention to the advice, we are still better off than without
the registration.  But, for people who feel cooperative as long
as the process isn't too "hard", it will result in more coherent
and complete registrations.

But I think we need to be careful to avoid discarding the baby
with the bathwater.

   john

---

From: Pete Resnick <[email-masked]>
Date: Wed, 3 Oct 2012 10:39:53 -0700

On 10/2/12 3:21 PM, Ned Freed wrote:
> [...]

Heh. OK. That worked out well. :-/

Let me make a suggestion to see if we can at least set aside this 
deadlock for the moment:

The IESG gets a crack at all RFCs anyway: All IETF documents come 
through regular Last Call and IESG Evaluation, and IAB, IRTF, and 
Independent Submissions come through the IESG for Conflict Review. Since 
the 3864 appears to say "Either publish an RFC or get Expert Review", we 
could simply tell IANA, "If it's an RFC, you don't have to check." That 
gets IANA out of the confusion they are currently in. Then, while this 
group is figuring out what they want the actual policy to be, the Apps 
ADs will take the responsibility to either check the templates, or toss 
them over the wall to Graham to check.

Does anyone object to going forward that way?

Either way, we need the conversation about what the policy *should* be 
to complete in short order. Glad to take that discussion to another list 
if it needs to be.

pr

---

From: Ned Freed <[email-masked]>
Date: Wed, 03 Oct 2012 11:23:58 -0700 (PDT)

> Does anyone object to going forward that way?

That's more or less how I expected it to work in practice. So yes, this is 
fine with me.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Wed, 03 Oct 2012 14:32:44 -0400

--On Wednesday, October 03, 2012 10:39 -0700 Pete Resnick
<[email-masked]> wrote:

>> Actively bad. These documents have received sufficient review
>> by the time they get this far, there is no need to require
>> more.
> 

Doubly so because I believe that Ned and I are in agreement
except on details that really are not important.

> Let me make a suggestion to see if we can at least set aside
> this deadlock for the moment:
> 
> The IESG gets a crack at all RFCs anyway: All IETF documents
> come through regular Last Call and IESG Evaluation, and IAB,
> IRTF, and Independent Submissions come through the IESG for
> Conflict Review. Since the 3864 appears to say "Either publish
> an RFC or get Expert Review", we could simply tell IANA, "If
> it's an RFC, you don't have to check." That gets IANA out of
> the confusion they are currently in. Then, while this group is
> figuring out what they want the actual policy to be, the Apps
> ADs will take the responsibility to either check the
> templates, or toss them over the wall to Graham to check.

Wfm if IANA will accept it.  Consistent with the "just throw
everything to Graham and let him bless it and throw it back"
suggestion I've made a couple of times now.

    john

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 04 Oct 2012 10:59:50 +0900

> suggestion I've made a couple of times now.

We all agree that we are discussing minor details. But the above 
proposal ignores the following facts:

1) In practice, it's the same as up to now (Graham has a look
at everything)
2) IANA asked the ADs, so we should assume that it will do what the the 
ADs tell it.
3) IANA is much more efficient, and less error-prone at asking the 
reviewer than the ADs. If we can, we should have IANA do the work, not 
the ADs.

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 04 Oct 2012 13:37:33 +0900

> it harder and is discouraging.

During this discussion, and based on my experience with helping to 
register media types from the W3C, and as a reviewer for charsets, I 
want to point out some other ideas on how to hopefully improve the 
review/registration process.

Many registries have a process that can be summarized as "send it to the 
mailing list, then later send it to IANA". On paper, this two-step 
process looks like it's quite easy. But submitters easily forget the 
second step, or don't know how to judge when they can move on.

For many registries, it would be great if that could be changed to 
"submit to IANA, they'll forward to the mailing list (they have to make 
sure they keep the submitter in the loop by cc'ing, I'm not sure IANA's 
systems are currently able to handle this.).

A second point that I think is worth looking at is to give the expert 
reviewers the possibility (not duty) to fix some things by themselves. 
In many cases, it's easier to do a quick fix than to wait for the 
submitter to possibly goof up again. In these cases, insisting on the 
submitter to submit again is quite contraproductive in terms of 
registration rates. Of course, how often this gets used depends very 
much on the business of the registry and the issues at hand.

Just some ideas.

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 04 Oct 2012 13:48:08 +0900

> decision.  For me, rough consensus is better.

Of course I don't disagree with that. But just to make an example, I 
wouldn't want the ADs, or anybody else for that matter, to ask whether 
they should use a paperclip or a staple to hold together the pages of a 
draft they just printed out.

The discussion of this issue has led to quite some good general insight, 
but in terms of actual changes, the result seems to be truly 
insignificant. If it was really considered necessary to get the list 
involved, a mail of the form "We instructed IANA to continue using 
paperclips. In case you think that's thoroughly wrong and cannot wait to 
be addressed/fixed until the document is updated, please say so."

Regards,    Martin.

---

From: Graham Klyne <[email-masked]>
Date: Thu, 04 Oct 2012 12:31:12 +0100

> the expert".   That is ok; it is their job.

Oops, did I drop the ball somewhere?

I *try* to respond to or acknowledge IANA requests promptly.

If there's a weakness in the system, it's that emails sometimes get lost or 
buried in the wider deluge.  Maybe that's something to look into, but I think 
it's a minor procedural issue that can probably be dealt with between IANA or 
IESG and the reviewer.

#g

---

From: Graham Klyne <[email-masked]>
Date: Thu, 04 Oct 2012 12:22:57 +0100

I'm sorry I've been out of this discussion the past few days.  Mainly, I wanted 
to confirm that John's perspective here matches mine.

One further small point:  there have been a couple of comments about the cost of 
requiring review of header fields in standard-track RFC submissions:  in 
practice there have been very few of these, and they require very little effort 
to review.  The potential cost I perceive is introducing yet another decision 
point about whether or not a submission needs to be reviewed.

#g
--

On 03/10/2012 14:04, John C Klensin wrote:
>> by the time

---

From: John C Klensin <[email-masked]>
Date: Thu, 04 Oct 2012 08:43:30 -0400

--On Thursday, October 04, 2012 13:37 +0900 "\"Martin J.
Dürst\"" <[email-masked]> wrote:

>...
> Many registries have a process that can be summarized as "send
> it to the mailing list, then later send it to IANA". On paper,
> this two-step process looks like it's quite easy. But
> submitters easily forget the second step, or don't know how to
> judge when they can move on.
> 
> For many registries, it would be great if that could be
> changed to "submit to IANA, they'll forward to the mailing
> list (they have to make sure they keep the submitter in the
> loop by cc'ing, I'm not sure IANA's systems are currently able
> to handle this.).

I would favor this generally, partially for a reason that Martin
didn't mention: it would allow IANA to establish and maintain a
tracking regime for requests.  Such a tracking regime would act
as a safeguard against the many ways that a request can fall
through the cracks despite the best of intentions (I note
Graham's recent comment about the possibility of email just
getting lost in the general noise).  Secondarily, it might
provide a public record of pending requests which might reduce
or eliminate the need for provisional registries in some cases.

> A second point that I think is worth looking at is to give the
> expert reviewers the possibility (not duty) to fix some things
> by themselves. In many cases, it's easier to do a quick fix
> than to wait for the submitter to possibly goof up again. In
> these cases, insisting on the submitter to submit again is
> quite contraproductive in terms of registration rates. Of
> course, how often this gets used depends very much on the
> business of the registry and the issues at hand.

I'm more hesitant about this.  On the other hand, if the Expert
reviewer wants to propose some specific text or changes to the
submitter and ask if it would be ok to apply them, I can't see
any problem with that even under present procedures.

best,
  john

---

From: John C Klensin <[email-masked]>
Date: Thu, 04 Oct 2012 08:51:45 -0400

--On Thursday, October 04, 2012 10:59 +0900 "\"Martin J.
Dürst\"" <[email-masked]> wrote:

>...
> We all agree that we are discussing minor details. But the
> above proposal ignores the following facts:
> 
> 2) IANA asked the ADs, so we should assume that it will do
> what the the ADs tell it.
> 3) IANA is much more efficient, and less error-prone at asking
> the reviewer than the ADs. If we can, we should have IANA do
> the work, not the ADs.

Yes.

I've said variations on this in a few off-list notes but, IMO,
the real disconnect here was that IANA felt obligated to _ask_
the IESG rather than asking Graham, getting his signoff, and
then telling the IESG that they requested expert review for
consistency with the registry spec and that all was well.   I
don't fault IANA for this -- I think "ask the IESG during Last
Call review" is part of their rule structure as (at least
implicitly) negotiated with the IESG. 

So. as a result of everyone trying to do their jobs and follow
procedures carefully, we've had a long discussion that could
have been avoided if those procedures were a little more
friendly to good sense and creativity.  While this particular
problem is about minor details, I think procedures that
discourage application of good sense and creativity when they
would efficiently facilitate a reasonable solution are a much
bigger and more general issue.

   john

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 4 Oct 2012 09:44:45 -0400

How about a web form with fields for the data in the template that people
fill in. This could be recorded separately from the registry itself which
would contain the reviewed data or it could just be a status flag thing.

I am writing a draft for a HTTP header right now. Pretty much the only
thing I care about with respect to the name is that nobody else has
attempted to use it. We can bike shed whether it should be
content-integrity, integrity, MAC, security or whatever if the proposal
gets to WG stage. At this stage the only important thing is to avoid a
collision and provide a pointer to the best available documentation in case
people want to look it up.

Bad documentation of registrations does not worry me a tenth as much as no
registration. Bad or even missing documentation has a habit of getting
fixed if people actually use a feature. It is also a pretty effective
discouragement to implementors.

The worst outcome for me is what happened with the SRV non-registry. The
IETF did not set up a registry that made sense or registration processes
that made sense. So now other people run a whole mess of registries that
are incomplete and difficult to find. What comes top in Google serach on a
given day should not determine the authoritative SRV registry.

---

From: Pete Resnick <[email-masked]>
Date: Thu, 4 Oct 2012 12:24:27 -0700

A couple of small points:

On 10/3/12 6:59 PM, "Martin J. Dürst" wrote:

> 1) In practice, it's the same as up to now (Graham has a look at 
> everything)

That was not my expectation. For IETF standards track documents that 
have gotten appropriate review, I do not expect to be asking Graham to 
look at it. For other RFCs, we'll send them to Graham if it does not 
appear that review was done.

> 2) IANA asked the ADs, so we should assume that it will do what the 
> the ADs tell it.

Understand that the current procedure is not as you describe. When a 
draft goes to Last Call, IANA asks the IESG whether there has been 
Expert Review. We could also change that procedure and tell IANA to 
simply check with Graham each time, but my feeling was that if the Apps 
ADs have looked at the thing (we look at all drafts when they come 
through the IESG) and we believe the registration template is fine, no 
need to bother anybody else.

If there are objections to this being the practice and you instead want 
Graham to look at everything, we can tell IANA to make the process 
"Check with Graham for everything". That is not my personal preference 
(and it's not what 3864 says), but if that's the consensus, we'll talk 
to IANA to make sure that happens.

pr

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 4 Oct 2012 17:08:33 -0400

Why wouldn't the expert be interested in a standards RFC submission?

That is the sort of issue I would expect them to want to be involved in.
Those are the documents I want to see have the highest possible level of
review. I don't see how a document has been given adequate review if the
domain expert has not at least been made aware of it.

I don't see that being standards track is a guarantee of quality as many
requests for HTTP headers come from people who have no connection to HTTP.
They may not even be from the apps area at all.

Since anyone can add in any HTTP headers they like, the role of the expert
is not to grant permission but to help avoid people adding unnecessary
confusion. I really disagree with the notion that IETF should ever tell
people not to add new functionality to a protocol. Explaining that the
functionality already exists is another matter as is endorsing that
protocol as a good idea.

On Thu, Oct 4, 2012 at 3:24 PM, Pete Resnick <[email-masked]>wrote:

>> We all agree that we are discussing minor details. But the above proposal
>> ignores the following facts:
>>
> That was not my expectation. For IETF standards track documents that have
> gotten appropriate review, I do not expect to be asking Graham to look at
> it. For other RFCs, we'll send them to Graham if it does not appear that
> review was done.
>
>
>> reviewer than the ADs. If we can, we should have IANA do the work, not the
>> ADs.
>>
>
> Understand that the current procedure is not as you describe. When a draft
> goes to Last Call, IANA asks the IESG whether there has been Expert Review.
> We could also change that procedure and tell IANA to simply check with
> Graham each time, but my feeling was that if the Apps ADs have looked at
> the thing (we look at all drafts when they come through the IESG) and we
> believe the registration template is fine, no need to bother anybody else.
>
> Graham to look at everything, we can tell IANA to make the process "Check
> with Graham for everything". That is not my personal preference (and it's
> not what 3864 says), but if that's the consensus, we'll talk to IANA to
> make sure that happens.
>
>
> pr
>
> --

---

From: John C Klensin <[email-masked]>
Date: Thu, 04 Oct 2012 17:10:22 -0400

--On Thursday, October 04, 2012 12:24 -0700 Pete Resnick
<[email-masked]> wrote:

>> 3) IANA is much more efficient, and less error-prone at
>> asking the  reviewer than the ADs. If we can, we should have
>> IANA do the work, not  the ADs.
> 
> Understand that the current procedure is not as you describe.
> When a draft goes to Last Call, IANA asks the IESG whether
> there has been Expert Review. We could also change that
> procedure and tell IANA to simply check with Graham each time,
> but my feeling was that if the Apps ADs have looked at the
> thing (we look at all drafts when they come through the IESG)
> and we believe the registration template is fine, no need to
> bother anybody else.
> 
> If there are objections to this being the practice and you
> instead want Graham to look at everything, we can tell IANA to
> make the process "Check with Graham for everything". That is
> not my personal preference (and it's not what 3864 says), but
> if that's the consensus, we'll talk to IANA to make sure that
> happens.

Pete,

Focusing exclusively on this particular registry for a change...

This (the Apps-discuss list and the sources of email expertise
in the IETF more generally)is a sufficiently skilled and
nit-picky crowd that the odds are extremely low that there is
any difference between the two procedures in practice.  If a
registration request has serious competency problems and goes
into Last Call in the IETF Stream, the odds are extremely high
that someone will make loud noises, making the notion of a final
check-up review by you, Barry, or Graham large irrelevant.

I think several of us have said that in different ways; I won't
say it again.

However, if you are looking to fine-tune procedures, I think the
key question is whether there is any reasonable scenario in
which the Expert Reviewer might add value, i.e., identify a
problem that wasn't caught or identify a key question that
wasn't asked otherwise.   If the answer is "yes there are such
scenarios", then the Expert ought to be in the loop.

The scenario would go like this.  First, one has to assume that
the problem --whatever it is-- isn't noticed during IETF Last
Call.  It shouldn't happen.  If it never happened, it would make
no difference whether the ADs reviewed the registration request
or not (except as part of the normal process of ensuring that LC
comments are resolved).   But things do sometimes slip through
the LC cracks (indeed, the fact that we are having this
discussion is evidence of that).   Then it needs to be far
enough in the future that, instead of having two ADs with a few
decades of experience in email issues (ignoring your current AD
roles, Graham is not inherently more qualified to do the reviews
than you or Barry) we had two ADs who were expert in, e.g., Web
services who had little in-depth experience with email protocols
and header issues.   Would it then be desirable to be sure that
someone with the relevant expertise did a final check?  I think
so.  And the finger points to an existing appointed Expert for
obvious reasons.

But, again, I'm not going to lose any sleep over whatever choice
you make because I think the odds of its actually making a
difference are very low.

RFCs that don't go through IETF LC are a different matter and
involve somewhat higher odds of a problem slipping through if
there isn't specific Expert review.

   john

---

From: Graham Klyne <[email-masked]>
Date: Fri, 05 Oct 2012 12:35:37 +0100

> people want to look it up.

This is a big part of what "provisional" registration, for which the bar is 
quite low, was meant to achieve.  It doesn't guarantee uniqueness (permanent 
registration does that), but it does give notice to other developers that, given 
good faith and a little due diligence, should help to avoid clashes.

#g
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 5 Oct 2012 11:33:39 -0400

+1

The problem is that we seem to have a commitment issue and end up using
provisional for things that should be permanent and then start upping the
barrier to provisional registrations.

On Fri, Oct 5, 2012 at 7:35 AM, Graham Klyne <[email-masked]> wrote:

> This is a big part of what "provisional" registration, for which the bar
> is quite low, was meant to achieve.  It doesn't guarantee uniqueness
> (permanent registration does that), but it does give notice to other
> developers that, given good faith and a little due diligence, should help
> to avoid clashes.
>
> #g
> --
>

---

From: Ned Freed <[email-masked]>
Date: Fri, 05 Oct 2012 12:10:30 -0700 (PDT)

> barrier to provisional registrations.

As I noted in the discussion of provisional media type registrations, part of
the problem with the provisional header registry is calling it "provisional".
The word doesn't really match up well with the intended purpose of the
registry.

At a minimum this needs to be clarified in any future revision of the
specification.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Fri, 05 Oct 2012 15:12:17 -0700 (PDT)

> systems are currently able to handle this.).

Seems like a good idea in the abstract but the devil is going to be in the
details. In particular, I'm not sure how IANA is supposed to process or
interpret the results of the list posting or who determines when that
process is "complete".

> much on the business of the registry and the issues at hand.

One way I usually handle this is to suggest text. I often do it in the first
review, but I pretty much always do it if the second attempt still has
problems.

When it comes to really small stuff like typos, I approve the registration
subject to them being corrected. That gets me out of the loop.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Sat, 06 Oct 2012 00:32:40 -0400

--On Friday, October 05, 2012 15:12 -0700 Ned Freed
<[email-masked]> wrote:

>> Many registries have a process that can be summarized as
>> "send it to the mailing list, then later send it to IANA". On
>> paper, this two-step process looks like it's quite easy. But
>> submitters easily forget the second step, or don't know how
>> to judge when they can move on.
> 
>> loop by cc'ing, I'm not sure IANA's systems are currently
>> able to handle this.).
> 

Ned,

I think there are two cases in practice:

(1) The one where there is a Designated Expert involved, in
which case my (somewhat extended) interpretation of Martin's
suggestion is that (i) IANA gets the request and logs it, (ii)
IANA sends notes to the list and to the Expert, (iii) the Expert
decides.

(2) The one where there is no Expert and the procedure really is
as Martin described: submitter sends to list, waits some period
of time for suggestions, and then forwards to IANA for
registration.  For that case, it seems that the suggestions
leaves us exactly where we are today as far as approval is
concerned.  While the submitter sends to IANA rather than the
mailing list directly, IANA just logs and forwards to the list.
The submitter still decides when to tell IANA to register,
subject to whatever constraints about time, handling of
comments, etc., apply to that particular registry.   I assume
that case would apply only to FCFS situations; for all others, I
think we've specified some sort of review and signoff process by
other than the submitter.

    john

---

From: Ned Freed <[email-masked]>
Date: Fri, 05 Oct 2012 21:37:43 -0700 (PDT)

> IANA sends notes to the list and to the Expert, (iii) the Expert

Not hard to implement, but only applicable in limited circumstances.

> other than the submitter.

Yep, it doesn't really help, does it?

				Ned

---

From: John C Klensin <[email-masked]>
Date: Sat, 06 Oct 2012 01:23:29 -0400

--On Friday, October 05, 2012 21:37 -0700 Ned Freed
<[email-masked]> wrote:

>> IANA sends notes to the list and to the Expert, (iii) the
>> Expert decides.
> 

I think it makes it a tad easier for the submitter (assuming the
submitter is clear about what registry is involved) and provides
better tracking.  Otherwise, yes, limited circumstances and a
small gain.

>> (2) The one where there is no Expert and the procedure really
>> is as Martin described: submitter sends to list, waits some
>> period of time for suggestions, and then forwards to IANA for
>> mailing list directly, IANA just logs and forwards to the
>> list. The submitter still decides when to tell IANA to
>> register, subject to whatever constraints about time,
>> handling of comments, etc., apply to that particular
>> registry.   I assume that case would apply only to FCFS
>> situations; for all others, I think we've specified some sort
>> of review and signoff process by other than the submitter.
> 

Again, provides better tracking and might be easier for
submitters to keep track of what to do.  Not a huge change.

So I thought of this as a small incremental improvement --
mostly because of the tracking aspect-- but with some emphasis
on "small".

   john

---

From: Graham Klyne <[email-masked]>
Date: Sat, 06 Oct 2012 07:32:32 +0100

> barrier to provisional registrations.

That's not something I've noticed or been aware of, at least as far as the 
message header or URI registries are concerned.  But I cannot dispute there is a 
widespread perception of a problem here, which is just as bad.

#g
--

---

From: Barry Leiba <[email-masked]>
Date: Sat, 6 Oct 2012 09:38:08 -0400

> Not hard to implement, but only applicable in limited circumstances.

Actually, it probably would be more applicable than you think, and
perhaps more helpful than you think.  Most chairs/shepherds/authors
aren't fully aware of how the expert review process works, and think
that someone else (the IESG or IANA) will take care of the expert
review.  The shepherd writeups almost always fail to mention anything
about expert review, IANA always asks in their last-call message
("IANA Question -> has the document been reviewed by the Permanent
Message Header Field Names registry expert?", from the IANA comments
on draft-snell-http-prefer), and the shepherd/authors usually don't
respond.  It then remains for someone (usually the responsible AD or
another AD who ballots a comment or DISCUSS on it) to deal with this,
and it's quite late in the process (by now it's the last few days
before the IESG telechat where the document is meant to get final
approval, and we don't have the expert review yet).

If, in IANA's last-call review, instead of asking whether it's been
through expert review IANA just sent it to the designated expert, they
would get their answer (from the DE directly), and we would be sure to
get expert review during IETF last call.

Barry

---

From: John C Klensin <[email-masked]>
Date: Sat, 06 Oct 2012 09:57:11 -0400

--On Saturday, October 06, 2012 09:38 -0400 Barry Leiba
<[email-masked]> wrote:

>>> suggestion is that (i) IANA gets the request and logs it,
>>> (ii) IANA sends notes to the list and to the Expert, (iii)
>>> the Expert decides.
>> 
> Actually, it probably would be more applicable than you think,
> and perhaps more helpful than you think.  Most
> chairs/shepherds/authors aren't fully aware of how the expert
> review process works, and think that someone else (the IESG or
> IANA) will take care of the expert review.  The shepherd
> writeups almost always fail to mention anything about expert
> review, IANA always asks in their last-call message ("IANA
> Question -> has the document been reviewed by the Permanent
> Message Header Field Names registry expert?", from the IANA
> comments on draft-snell-http-prefer), and the shepherd/authors
> usually don't respond.  It then remains for someone (usually
> the responsible AD or another AD who ballots a comment or
> DISCUSS on it) to deal with this, and it's quite late in the
> process (by now it's the last few days before the IESG
> telechat where the document is meant to get final approval,
> and we don't have the expert review yet).
>...

Barry, I agree (and have made the same observations), but I
think part of this is a Shepherd (and instructions/advice to
Shepherds) matter.  Using your report and checklist format
(which many readers of this list won't have seen, but they can
probably get the gist), wouldn't it help if one of those
checklist questions were something like "if Expert Review is
called for, are the instructions to the Expert clear enough that
he or she would know what to do and what criteria are
appropriate to be applied, even if the Expert was not a
participant in the WG or discussion leading to the document?"
An honest "yes" answer would presumably solve much of the
problem you describe.

I still favor doing this because I think that having a single
submission path (to IANA, rather than to different mailing lists
or experts) is a good idea and that a unified tracking mechanism
is an even better one.  But, in terms of problems it would
prevent or stop, I'd much rather see it (at least long-term) as
preventing the occasional odd case from falling through the
cracks than as a patch around failures in our specifications of
review mechanisms.  I say "long-term" because if, as a
side-effect, it helps with some of those failures, that is
obviously a benefit.

    john