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

From: Applications Area Directors <[email-masked]>
Date: Tue, 25 Sep 2012 19:13:52 -0400

App Area denizens:

Pete and I have been having a debate, in response to a request for
clarification from IANA, on the proper registration policy for the
Permanent Message Header Field Names registry:
   http://www.iana.org/assignments/message-headers/perm-headers.html

The registry was defined in RFC 3864 (along with the Provisional
Message Header Field Names registry), and we weren't as rigorous then
as we are now about specifying registration policies.  The relevant
text from 3864 is in two places:

Section 4.2.1:
   A header registered in the Permanent Message Header Field Registry
   MUST be published as an RFC or as an "Open Standard" in the sense
   described by RFC 2026, section 7 [1], and MUST have a name which is
   unique among all the registered permanent field names that may be
   used with the same application protocol.

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

   o  An IANA considerations section in a defining RFC, calling for
      registration of the message header and referencing information as
      required by the registration template within the same document.
      Registration of the header is then processed as part of the RFC
      publication process.

   o  Send a copy of the template to the designated email discussion
      list [33] [34].  Allow a reasonable period - at least 2 weeks -
      for discussion and comments, then send the template to IANA at the
      designated email address [35].  IANA will publish the template
      information if the requested name and the specification document
      meet the criteria noted in Section 4.1 and Section 4.2.2, unless
      the IESG or their designated expert have requested that it not be
      published (see Section 4.4).  IESG's designated expert should
      confirm to IANA that the registration criteria have been
      satisfied.

This collectively clearly says that there are two processes: one for
registrations documented in an RFC, and one for others, which involves
expert review.  IANA currently has the policy listed as "Expert
Review", and, therefore, question whether registration requests in
RFCs have been through expert review.  Our answer, on reading RFC
3864, is "No, and it's not necessary."  So they want to correct their
registration policy.

The trouble is that Pete reads RFC 3864 and says that the words
clearly say that all that's required is an RFC, so the correct policy
should be "RFC Required or Expert Review"... while I read RFC 3864 and
say that the intent was to have a reasonable level of review for the
registrations, that the intended level of review will only happen with
IETF Stream RFCs, and so the correct policy should be "IETF Review or
Expert Review".

We're looking for discussion, and other opinions.

The difference between our opinions involves RFCs done in non-IETF
streams: currently those in the IAB, IRTF, and Independent Streams.
Let's focus on the Independent Stream for the moment, because that's
the one with the greatest potential for problems.

The IESG gets a very light level of review for Independent Stream
documents, just to determine whether the publication request is in
conflict with work being done in the IETF -- a check for "end runs",
as we call it.  We can object to the publication of a document that is
in conflict with current IETF work.  But we can't object on the
grounds that an IANA registration request has not had sufficient
review.

On the other hand, we can *recommend* to the ISE that the IANA
registration go through expert review.  The ISE is not obliged to take
that recommendation, but he's very likely to.  Pete thinks that this
provides sufficient opportunity for the IESG to say that the
registration needs to be checked.  I think that was never the intent
of RFC 3864, and that it should only be IETF Stream RFCs that can
bypass Expert Review.

OK, there are the arguments so far.  Opinions, please (and I'd
especially like to hear from Graham (the designated expert for the
registry) and Ned (the designated expert for Media Types, which has a
similar process)).

Barry (for Barry and Pete)

---

From: John Leslie <[email-masked]>
Date: Tue, 25 Sep 2012 19:38:14 -0400

> IETF Stream RFCs, and so the correct policy should be "IETF Review or

   Sorry, Barry, I'm with Pete here.

   It might indeed be better if it had been written your way; but RFCs
are "forever", and trying to fix by "interpreting" is a bad choice.

> grounds that an IANA registration request has not had sufficient

   True, but anybody (even IESG members) can write a note suggesting
changes to the RFC Editor.

   IMHO, if the authors are so recalcitrant as to resist suggestions
from the RFC Editor, we should find another windmill to tilt at.
The overall intent is to have a simple path to expanding header fields.
Nobody has to use them. We want the process simple enough that new
fields are documented, not drawn out so much that they appear without
documentation.

> of RFC 3864, and that it should only be IETF Stream RFCs that can

   Again, I agree with Pete.

--
John Leslie <[email-masked]>

---

From: Ned Freed <[email-masked]>
Date: Tue, 25 Sep 2012 20:01:04 -0700 (PDT)

>    Sorry, Barry, I'm with Pete here.

And so am I. The mistake we make with depressing regularity is making
our registration processes too onerous, with the inevitable result that
people just do things without bothering to register.

We really, really, really need to get it through our heads that we are not the
protocol police and that documentation of something does not imply endorsement.
A documented bad idea can be seen for what it is, whereas an undocumented one
can be very difficult to grapple with.

> are "forever", and trying to fix by "interpreting" is a bad choice.

Agreed as well.

> changes to the RFC Editor.

Indeed.

> fields are documented, not drawn out so much that they appear without

Exactly.

>    Again, I agree with Pete.

As do I. I have a number of issues with the way RFC 3864 was done, but this is
not one of them.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Sep 2012 08:56:30 -0700

> can be very difficult to grapple with.

+10

Registration is an administrative step to ensure awareness and 
uniqueness; it's not for quality control (absent an extremely compelling 
case being made for 'dangerous' registrations.)

d/

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: Barry Leiba <[email-masked]>
Date: Wed, 26 Sep 2012 12:04:26 -0400

> Sorry, Barry, I'm with Pete here.

Well, John, there's no need for the "sorry"; this is all exactly the
feedback we're looking for.

> We really, really, really need to get it through our heads that we are not
> the protocol police and that documentation of something does not imply
> endorsement.

Yes, and I think everyone here knows that I've been pushing hard in
general for more lenient registration policies, not tighter ones.  I
absolutely agree with what Ned says above.

Pete and I are trying to get at what was intended in RFC 3864, not
trying to apply our opinions of what it *should* have done.

So far, we have three responses that want the slightly more relaxed
"RFC Required or Expert Review" policy.  Honestly, it's what I want as
well.  If we think that's what was intended in RFC 3864, I'm happy,
and we can give an answer to IANA.

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 26 Sep 2012 17:35:53 +0100

> IETF Stream RFCs, and so the correct policy should be "IETF Review or
Yeah, I got confused by that in the past as well.

According to Graham (who is the Expert Reviewer and can correct me if I 
misrepresent him), Expert Review is required in all cases, but for IETF 
Stream RFCs Graham trusts that there was sufficient review and basically 
applies lightweight approval.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 26 Sep 2012 12:43:53 -0400

Alexey says...
> applies lightweight approval.

Now, this is how IANA has been handling this until now (because they
have consider the policy to be simply "Expert Review"), but it's the
one option that's clearly NOT supported by RFC 3864 Section 4.3 --
which very clearly bypasses expert review for requests that are in
RFCs.

Are you saying that you read 3864 differently?

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 26 Sep 2012 18:24:13 +0100

> Are you saying that you read 3864 differently?
Quoting the RFC again:

Section 4.2.1:

  Section 4.3:

The two sections can be interpreted as complementary (i.e. both apply). And the last sentence can be interpreted as "Expert Review would magically happen during RFC publication". Granted, this might be a very liberal interpretation of the above.

But anyway, ask Graham, as he actually co-edited the RFC.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 26 Sep 2012 18:25:06 +0100

> absolutely agree with what Ned says above.
Agreed.

But I think the question you've asked was not "what do you think the 
policy should be", but "what do you think the document currently requires".

---

From: Ned Freed <[email-masked]>
Date: Wed, 26 Sep 2012 13:18:27 -0700 (PDT)

> policy should be", but "what do you think the document currently requires".

I believe I stated that I think Pete's reading is correct. IMO Barry's is a
stretch.

And while it's entirely appropriate to ask "what does the RFC say", once this
reaches the point of trying to divine intent, in cases like this that's going
too far. The RFC says what it says. What the authors intended to say might be
relevant during a revision process, or perhaps in deciding how to handle a
technical case that wasn't anticipated, but it's not really appropriate when
the apparent goal is to implement administrative policy.

				Ned

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 26 Sep 2012 16:36:57 -0400

> As do I. I have a number of issues with the way RFC 3864 was done, but this is

… and FWIW I've been talking to Graham about revising it. In our copious spare time, of course.

Cheers,

--
Mark Nottingham
http://www.mnot.net/

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 27 Sep 2012 15:28:48 +0900

First, I have copied Graham explicitly. I think he's on this list, but 
may not have realized that we might appreciate his input.

More below.

> applies lightweight approval.

Graham said this for URI/IRI scheme registrations, in the context of the 
ni:/nih: discussion. He may have said the same for message header field 
names, or he may not have said so. In the later case, he may still 
actually do so also for message header field names.

Regarding the point that Barry explicitly asked for, my reading (not 
interpretation or intent) of the text is that "one of the following 
methods:" clearly means that it's okay to have an RFC but no Expert 
Review (it doesn't exclude doing both, but it does not require having 
both at the same time). Anything else would be a serious interpretative 
stretch to the plain English text.

While writing this mail (and ducking to not being hit by Barry's rant), 
I'd like to add that I agree with John that in general, it's a good idea 
to pass RFC-based registrations past the Expert Reviewers, because of 
exactly the reasons John has given. I also agree with the general 
sentiment that it's better to encourage registrations even for stuff 
that's not necessary technically sound, for the reasons given by several 
people in the thread.

Last but not least, I have to say that I don't care too much which way 
this turns out, because I don't think it will make too much of a 
difference in practice.

Regards,   Martin.

---

From: Ned Freed <[email-masked]>
Date: Fri, 28 Sep 2012 00:46:09 -0700 (PDT)

> … and FWIW I've been talking to Graham about revising it. In our copious

I'm always willing to take some of that copius free time off your hands ;-)

More seriously, while such a revision would be nice, I don't think any of this
or previous comments pushes it anywhere close to urgent.

				Ned

---

From: Graham Klyne <[email-masked]>
Date: Fri, 28 Sep 2012 09:22:58 +0100

Hi,

 From memory, and reading the quoted text from section 4..1 of RFC3864, the 
*intent* of the permanent header field registration was that permanent header 
fields should have been reviewed through an open standards process by the IETF 
or similar body - i.e. that permanently registered header fields would be 
treated as being approved standards.

The expert review process was intended to allow some judgement to be applied 
regarding whether the criteria had been met, particularly in cases where the 
definition had not gone through the IETF standards process leading to 
standards-track RFC publication.  For example, I would regard a new HTTP header 
published in a W3C REC track specification to meet the criteria.

Thus, section 4.2.1 states the requirements, and section 4.3 describes the 
process for checking that the requirements are satisfied.  Note that the role of 
expert reviewer here is not primarily to make a technical judgement, but to 
check for evidence of due process.  (In the case of publication in an RFC 
standards-track document, due process would be self-evident.)

...

It is possible that there are instances of approved permanent headers that have 
been published in informational RFCs that have been through an IETF last-call. 
This would, strictly speaking, be a violation of the letter of RFC3864 
requirements.  I believe the URI scheme registries were loosely modeled on the 
message header field registries, but IIRC adopted a lower bar of "IETF 
Consensus" for permanent registration.  In practice, I think there are 
relatively few cases where this has or would have made a material difference.

...

Since then, there has been a general and gradual move away from the notion of 
strict standards-process compliance for registered protocol parameters of this 
kind.  There's a tension here between flexibility to introduce new features into 
existing IETF protocols, and avoiding a Tower of Babel profusion of options with 
attendant developer confusion and possibly harmful consequences in deployment.

Given that there is no enforcement of what header fields can actually be 
transmitted, and more recent experience that suggests lighter-touch mechanisms 
can be quite effective for distilling community consensus, there is a reasonable 
debate to be had about whether the originally proposed requirements and 
mechanism are appropriate today.  Some discussion of this has taken place on the 
HAPPIANA list, but that is currently stalled.

...

To respond to your specific questions, I would judge that an independent stream 
RFC did not meet the criteria (unless it contained reference to definitions in 
some other open standards body specification - in which that would be the 
primary reference).  IAB and IRTF stream publications are less clear cut. 
Strictly, they don't meet the requirements, but to enforce that absolutely 
would, IMO, to make the process master rather than servant of "doing the right 
thing".  As reviewer, my response would be to seek IESG guidance in such corner 
cases.  (I think there's an "escape clause" in RFC3864 that gives the IESG final 
say in any case.)

At the end of the day, I understand the "IETF way" aims to apply good judgement 
in these cases ("do the right thing"), and the process is intended to help us 
achieve that outcome.  I see the role of expert reviewer in the process is, in 
part, to allow for corner cases to be handled responsively.

...

I hope this helps.

#g
--

On 26/09/2012 00:13, Applications Area Directors wrote:
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Graham Klyne <[email-masked]>
Date: Fri, 28 Sep 2012 09:39:52 +0100

Martin,

On 27/09/2012 07:28, "Martin J. Dürst" wrote:
> First, I have copied Graham explicitly. I think he's on this list, but may not
> have realized that we might appreciate his input.

I'm here, but not always attentive or instantly responsive :)   I have responded 
to Barry's message.

Brief comments below...

>> applies lightweight approval.

Yes, I think expert review is always required.  In the case of standards yrack 
publicaton, it's generally trivial (though I do try to make sure the template 
and definition are actually present and not obviously bogus or inadequate, but 
any technical comments are clearly separated from my expert reviewer response).

> ni:/nih: discussion. He may have said the same for message header field names,
> or he may not have said so. In the later case, he may still actually do so also
> for message header field names.

The URI scheme requirements are different from the message header requirements. 
  They came later, and were (I believe) designed to be less strict (maybe 
setting a direction for future progress...)

#g
--

> interpretation or intent) of the text is that "one of the following methods:"
> clearly means that it's okay to have an RFC but no Expert Review (it doesn't
> exclude doing both, but it does not require having both at the same time).
> Anything else would be a serious interpretative stretch to the plain English text.
>
>
> While writing this mail (and ducking to not being hit by Barry's rant), I'd like
> to add that I agree with John that in general, it's a good idea to pass
> RFC-based registrations past the Expert Reviewers, because of exactly the
> reasons John has given. I also agree with the general sentiment that it's better
> to encourage registrations even for stuff that's not necessary technically
> sound, for the reasons given by several people in the thread.
>
> Last but not least, I have to say that I don't care too much which way this
> turns out, because I don't think it will make too much of a difference in practice.
>
>
> Regards, Martin.

---

From: Graham Klyne <[email-masked]>
Date: Fri, 28 Sep 2012 09:28:36 +0100

On 26/09/2012 16:56, Dave Crocker wrote:
> Registration is an administrative step to ensure awareness and uniqueness; it's
> not for quality control (absent an extremely compelling case being made for
> 'dangerous' registrations.)

I mostly agree with this, but it was not the prevailing mood at the time header 
registration proposal was written.  The introduction of the "provisional" 
registry to provide an alternative to standards-track process was, at the time, 
not without controversy.  The result inevitably contained compromises, and maybe 
not the best ones.

But the world has moved on, and maybe it's time to loosen the apron strings some 
more.

#g

---

From: Barry Leiba <[email-masked]>
Date: Fri, 28 Sep 2012 06:30:23 -0400

Hi, Graham.

So you are actually saying that we should leave it alone, and require
registrations in RFCs to go through Expert Review, as they have been,
and you (and, one presumes, your successor, eventually) will do the
right thing.  You're saying that the first bullet in Section 4.3 does
*not* say that RFCs do not have to go through Expert Review?

Barry

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 28 Sep 2012 08:43:46 -0400

That is how I think it should work.

For the DNS registration I needed for CAA, I first asked for a registration
through the DNS header registration process, then had the draft referred
back to DNS land as part of the last call process.

I don't see anything wrong with that process. In fact I think that the
expert review is actually more important in standards track applications
than otherwise since the point of standards track is that there has been
review.

For other applications I think people need to take note of the fact that
people can and do create new headers without any IANA registration
whatsoever. The advantage of registration is that it helps avoid accidental
collisions - provided there is a sufficient description to understand what
is registered.

The real reason that we are having a big confusion in diplomatic circles
concerning IETF standards making is that they are unable to understand any
system that does not have a top-down flow of authority.

Expert review needs to be really minimal or we will end up in the situation
where we have a large number of headers that are de-facto standards because
they are in use that are not recorded anywhere. We will end up with the
mess we have got into with SRV prefixes where other groups have taken over
the task of registration.

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

---

From: Graham Klyne <[email-masked]>
Date: Fri, 28 Sep 2012 13:46:52 +0100

> *not* say that RFCs do not have to go through Expert Review?

Short answer: yes, I think so.

... but re-reading the actual text at 
http://tools.ietf.org/html/rfc3864#section-3 it's not so obvious.

What seems to happen in practice is that IANA run header field registration 
templates in RFCs submitted for publication by me for approval.  For 
standards-track RFCs, that's pretty much a formality, for others, I will dig a 
little further to evaluate the source of the definition.

Thus, my response to your question.

By way of explanation, section 4.3 is intended to tell submitters what they have 
to do.  I think the unstated assumption here is that the expert review is part 
of the "RFC publication process" - that could be clearer.

Do IANA get to review registrations before final approval for standards-track 
RFC publication (as they do, e.g., for independent stream submissions)?  If so, 
then I think it makes sense to simply pass all submissions by the designated 
reviewer, as an extra pair of eyeballs, however cursory, rarely does harm.

#g

---

From: John C Klensin <[email-masked]>
Date: Sat, 29 Sep 2012 10:12:46 -0400

--On Friday, September 28, 2012 13:46 +0100 Graham Klyne
<[email-masked]> wrote:

> By way of explanation, section 4.3 is intended to tell
> submitters what they have to do.  I think the unstated
> assumption here is that the expert review is part of the "RFC
> publication process" - that could be clearer.

> Do IANA get to review registrations before final approval for
> standards-track RFC publication (as they do, e.g., for
> independent stream submissions)?  If so, then I think it makes
> sense to simply pass all submissions by the designated

It is actually the opposite.  Under current procedures IANA gets
to (and is required to) review anything that goes out for IETF
Last Call as part of/ during the Last Call process.  AFIK, there
is no such requirement for the Independent Stream.  But I think
the solution to this problem (if there is a problem) is to work
with IANA and the other streams to be sure that review happens
in all cases where it is appropriate.  In practice, little or
nothing is required for an RFC because the RFC Editor has their
own procedures for noticing IANA Consideratons sections and
registrations and clearing them with IANA.   I don't think that
requires changes to 3864, nor that such changes would help since
this is really a procedural/ coordination issue and there is no
real evidence that anything is broken.  I agree that, if 3864
were opened for other reasons, a little clarification might be
in order.

But it seems to me that you are doing the right thing, IANA is
doing the right thing, the RFC Editor is doing the right thing,
and, if anything actually needs to be done, it is simply to
remind the other streams and the RFC Editor that publication of
relevant RFCs before IANA signs off is an invitation to
confusion.  I personally don't think they even need reminding.

best,
   john