Subject: [apps-discuss] RFC 3864 message header registration and independent stream RFC publication

From: Graham Klyne <[email-masked]>
Date: Tue, 08 Apr 2014 10:45:43 +0100

All,

TL;DR:  should a permanent message header field registration be allowed through 
an ISE RFC publication, which does not require IETF review?

...

An issue has come up concerning permanent registration of a message header field 
through an RFC independent stream editor (ISE) submission 
(https://tools.ietf.org/html/rfc6548).

RFC 3864 says:
[[
A Permanent Message Header Field Registry, intended for headers
defined in IETF standards-track documents, those that have
achieved a comparable level of community review, or are generally
recognized to be in widespread use.
]]
-- http://tools.ietf.org/html/rfc3864#section-2.1

But also:
[[
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],
]]
-- http://tools.ietf.org/html/rfc3864#section-4.2.1

The latter quote appears to allow permanent registration following *any* RFC 
publication.  Specifically, it appears to allow permanent registration following 
RFC publication through the RFC ISE stream, which does not require review within 
the IETF.  As one of the original drafters of the registration specification, I 
claim this was not intended.  At the time, (I think) I believed that independent 
submission RFCs were still subject to IETF,. or at least IESG, review.  (I'm not 
sure if this is also true of my co-editors, so I'm speaking for myself here.)

My expectation was that a permanent header field registration could be achieved 
through an IETF-reviewed informational RFC, as well as a standards-track RFC. 
This flexibility was used, for example, to grandfather entries into the 
permanent registry in http://tools.ietf.org/html/rfc4229.

(In my role as reviewer for IANA) I have received a request to accept a 
permanent registration from an ISE RFC submission that has not been reviewed in 
the IETF, and have pushed back.  But the requester makes the reasonable point 
that the section 4.2.1 text noted above provides no explicit grounds for refusal 
of such a permanent registration.

In the current case, I would like to see the registration request submitted for 
review on the designated mailing list ([email-masked]) (per 
http://tools.ietf.org/html/rfc3864#section-4.3) and see what feedback it garners.

Under the circumstances, I think I should ask you, the IETF community, whether 
it is reasonable to push back in circumstances which have come about due to what 
is effectively a drafting error.  And, more generally, does this community feel 
that it should be allowable to create permanent header field registry entries 
without undergoing IETF review?

RFC3864 also says:
[[
The IESG is the final arbiter of any objection.
]]
-- http://tools.ietf.org/html/rfc3864#section-4.4

So there is process scope to refuse a permanent registration, even if other 
conditions are met, if the IESG opines it should not be made.

(For the avoidance of doubt, I accept ISE submissions are perfectly suitable 
mechanism for creating provisional registrations, it's just permanent 
registration I'm questioning here.)

I welcome any thoughts and feedback.

#g
--

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 8 Apr 2014 05:41:42 -0700

On Apr 8, 2014, at 2:45 AM, Graham Klyne <[email-masked]> wrote:

> All,
> 
> TL;DR:  should a permanent message header field registration be allowed through an ISE RFC publication, which does not require IETF review?
> 
> ...
> 
> An issue has come up concerning permanent registration of a message header field through an RFC independent stream editor (ISE) submission (https://tools.ietf.org/html/rfc6548).
> 
> RFC 3864 says:
> [[

I note as well that BCP 90 says:
   Publication in an RFC or other form of Open Standard document (per
   RFC 2026 [1], section 7) is sufficient grounds for publication in the
   permanent registry.

This text was changed by the IESG when it approved BCP 90.  Namely the IESG changed "IESG-approved RFC" to "RFC".   See  <https://datatracker.ietf.org/doc/rfc3864/writeup/>.

> 
> The latter quote appears to allow permanent registration following *any* RFC publication.  Specifically, it appears to allow permanent registration following RFC publication through the RFC ISE stream, which does not require review within the IETF.  As one of the original drafters of the registration specification, I claim this was not intended.  At the time, (I think) I believed that independent submission RFCs were still subject to IETF,. or at least IESG, review.  (I'm not sure if this is also true of my co-editors, so I'm speaking for myself here.)

Yes, what did the IETF or the IESG believe at the time the draft was considered?   One has to assume IETF participants and IESG members reviewed the text as draft  And I argue that it must be assumed that specific changes they request the RFC Editor to make are made based upon their consideration and deliberate action which, I think, effectively moots drafting errors in the text submitted to them.

> My expectation was that a permanent header field registration could be achieved through an IETF-reviewed informational RFC, as well as a standards-track RFC.

> This flexibility was used, for example, to grandfather entries into the permanent registry in http://tools.ietf.org/html/rfc4229.

RFC 4229 being an independent submission is not an IETF-reviewed RFC [BCP 26]:

      IETF Review - (Formerly called "IETF Consensus" in
            [IANA-CONSIDERATIONS]) New values are assigned only through
            RFCs that have been shepherded through the IESG as AD-
            Sponsored or IETF WG Documents [RFC3932] [RFC3978].  The
            intention is that the document and proposed assignment will
            be reviewed by the IESG and appropriate IETF WGs (or
            experts, if suitable working groups no longer exist) to
            ensure that the proposed assignment will not negatively
            impact interoperability or otherwise extend IETF protocols
            in an inappropriate or damaging manner.

            To ensure adequate community review, such documents are
            shepherded through the IESG as AD-sponsored (or WG)
            documents with an IETF Last Call.

            Examples: IPSECKEY Algorithm Types [RFC4025],
            Accounting-Auth-Method AVP values in DIAMETER [RFC4005], TLS
            Handshake Hello Extensions [RFC4366].

If it is your intent to allow registrations specified in some independent submissions but not others, some clear and concise acceptance/non-acceptance criteria should be published in an update to BCP 90.

Can you propose clear and concise changes to BCP 90 which reflect what you think the criteria should be?  Please use BCP 26 terminology to the extent possible.

> Under the circumstances, I think I should ask you, the IETF community, whether it is reasonable to push back in circumstances which have come about due to what is effectively a drafting error.

I note above, I think the so-called drafting error is moot.

>  And, more generally, does this community feel that it should be allowable to create permanent header field registry entries without undergoing IETF review?

What about "open standards"?   They aren't subject to IETF review either.

I think the criteria for acceptance/non-acceptance into any registry should be made a clear as possible.  While I think the term "IETF review" (as defined by BCP 26) is reasonably clear, this is not what BCP 90 says, nor would use of the term be consistent with what you seem to want.

I note also that IETF Review also allows IETF reviewed experimental RFC.

I see the main problem here is that BCP 90 creates an "IETF endorsed" vs "non-IETF endorsed" issue through this 4.2.2 text:
  Registration as a Provisional Message Header Field does not imply any
   kind of endorsement by the IETF, IANA or any other body.

The problem is that same should, if open standards and ISEs are to be allowed, ought to said for Permanent Registry as well.  Consider RFC 4229's registration.  Given that RFC 4229 is an ISE, no IETF endorsement is implied by the publication of the RFC.  But BCP 90 text (in the provisional registry) implies that it is endorsed by the IETF, and that's simply not the case.

If the indent of the registration split is "Endorsed" vs. "Non-Endorsed", then the registries should be renamed, registration policy should be IETF Review for "endorsed", and items not having IETF Review (including non-IETF standards and ISEs) should be moved out of the "endorsed" registry.

But I argue that such a split serves little purpose and even couter-productive.   Those who care about the status of a spec should not be looking at an IANA registry to tell them the status.  I argue that if any change to BCP 90 is to be made, we should do away with the registry split.

> So there is process scope to refuse a permanent registration, even if other conditions are met, if the IESG opines it should not be made.

This text doesn't say anything about conditions for rejections. This text simply means that the requestor has the right to appeal any registration action to the IESG.

Regards, Kurt

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 08 Apr 2014 14:50:58 +0200

>sure if this is also true of my co-editors, so I'm speaking for myself here.)

I noticed this at the time and think it's quite plausible to require an
RFC but not require IETF consensus, considering how low the bar is for
"Open Standards" more generally. If there are problems with individual
registrations I would expect the Designated Expert to push back on an
individual basis; for instance, if someone tried to register all single
letter HTTP header names, I would expect insistence on review by the
HTTPBis Working Group and denial of the registration request if they're
unhappy with the proposal, even if the registration procedures do not
address such a case in detail; there is a reason a human is in charge.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 11 Apr 2014 18:59:13 +0900

Hello Graham,

It is my understanding that RFCs in the independent stream go through an 
IETF conflict review. I think that would be one way to deal with 
registration proposals that would be considered harmful.

Regards,   Martin.

On 2014/04/08 18:45, Graham Klyne wrote:
> All,
>
> TL;DR:  should a permanent message header field registration be allowed
> through an ISE RFC publication, which does not require IETF review?
>
> ...
>
> An issue has come up concerning permanent registration of a message
> header field through an RFC independent stream editor (ISE) submission
> The latter quote appears to allow permanent registration following *any*
> RFC publication.  Specifically, it appears to allow permanent
> registration following RFC publication through the RFC ISE stream, which
> does not require review within the IETF.  As one of the original
> drafters of the registration specification, I claim this was not
> intended.  At the time, (I think) I believed that independent submission
> RFCs were still subject to IETF,. or at least IESG, review.  (I'm not
> My expectation was that a permanent header field registration could be
> achieved through an IETF-reviewed informational RFC, as well as a
> standards-track RFC. This flexibility was used, for example, to
> grandfather entries into the permanent registry in
> http://tools.ietf.org/html/rfc4229.
>
> permanent registration from an ISE RFC submission that has not been
> reviewed in the IETF, and have pushed back.  But the requester makes the
> reasonable point that the section 4.2.1 text noted above provides no
> explicit grounds for refusal of such a permanent registration.
>
> In the current case, I would like to see the registration request
> submitted for review on the designated mailing list
> ([email-masked]) (per
> Under the circumstances, I think I should ask you, the IETF community,
> whether it is reasonable to push back in circumstances which have come
> about due to what is effectively a drafting error.  And, more generally,
> does this community feel that it should be allowable to create permanent
> header field registry entries without undergoing IETF review?
>
> RFC3864 also says:
> [[
> So there is process scope to refuse a permanent registration, even if
> other conditions are met, if the IESG opines it should not be made.
>
> (For the avoidance of doubt, I accept ISE submissions are perfectly
> suitable mechanism for creating provisional registrations, it's just
> permanent registration I'm questioning here.)
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Graham Klyne <[email-masked]>
Date: Fri, 11 Apr 2014 14:03:44 +0100

On 11/04/2014 10:59, "Martin J. Dürst" wrote:
> Hello Graham,
>
> It is my understanding that RFCs in the independent stream go through an IETF
> conflict review. I think that would be one way to deal with registration
> proposals that would be considered harmful.

Hi Martin,

Thanks for the comment.  I agree that the conflict review may be a way to deal 
with this.  But I might also suggest that it lacks clarity for both submitter 
and reviewers.  It's not clear to me if an IESG conflict review would regard an 
unreviewed permanent header registration as a conflict.

 From from the submitter's viewpoint, it would be better if the registration 
document itself were clearer on this point (which it currently is not).

I'm currently asking myself if the current confusion can be clarified through a 
document erratum (I see this as a problem of drafting), but a change here might 
be seen as substantive and requiring new review.

But before attacking any of that I'm hoping to get a sense of what a consensus 
about permanent registration requirements might look like.  (My own inclination 
would be to clarify the RFC requirement to be an "IETF stream RFC" per 
http://tools.ietf.org/html/rfc4844#section-5.1.1)

#g
--

---

From: Barry Leiba <[email-masked]>
Date: Mon, 14 Apr 2014 17:09:32 -0400

Catching up...

>> IETF conflict review. I think that would be one way to deal with registration
> Thanks for the comment.  I agree that the conflict review may be a way to
> deal with this.  But I might also suggest that it lacks clarity for both
> submitter and reviewers.  It's not clear to me if an IESG conflict review
> would regard an unreviewed permanent header registration as a conflict.

Right.  5742 limits what we can do in conflict reviews, and pushing
back on a problematic registration would be limited, I think, to a #5
response, which is rather nuclear:

   5. The IESG has concluded that this document extends an IETF protocol
      in a way that requires IETF review and should therefore not be
      published without IETF review and IESG approval.

> I'm currently asking myself if the current confusion can be clarified
> through a document erratum (I see this as a problem of drafting), but a
> change here might be seen as substantive and requiring new review.

Hm.

Hm.

I'm still thinking.

On the one hand, as you point out in your first note, from your PoV
this is an erratum: if you had been aware of the confusion at
publication time, you'd have considered it an error and would have
clarified it.

But on the other hand, the community (and the IESG) might well have
taken it at its word and expect to have IETF review.

The backstop, though, is that it all goes through the designated
expert, who is a delegate of the IESG.  I see that as the real
solution here.  The way *I* interpret the text is that the
registration policy is "Specification Required", and it's up to the
judgment of the expert whether the specification is adequate and the
request is reasonable and properly done.

I think we can live with that until someone wants to update 3864.

Barry, Applications AD

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 15 Apr 2014 10:30:20 +0100

Hi Graham,

> On 11 Apr 2014, at 14:03, Graham Klyne <[email-masked]> wrote:
> 
> Thanks for the comment.  I agree that the conflict review may be a way to deal with this.  But I might also suggest that it lacks clarity for both submitter and reviewers.  It's not clear to me if an IESG conflict review would regard an unreviewed permanent header registration as a conflict.
> 
> From from the submitter's viewpoint, it would be better if the registration document itself were clearer on this point (which it currently is not).
> 
> I'm currently asking myself if the current confusion can be clarified through a document erratum (I see this as a problem of drafting), but a change here might be seen as substantive and requiring new review.
> 
> But before attacking any of that I'm hoping to get a sense of what a consensus about permanent registration requirements might look like.  (My own inclination would be to clarify the RFC requirement to be an "IETF stream RFC" per http://tools.ietf.org/html/rfc4844#section-5.1.1)

What about header field registrations from other SDOs (e.g. W3C)?

---

From: Graham Klyne <[email-masked]>
Date: Tue, 15 Apr 2014 11:02:04 +0100

Hi Barry,

TL;DR: I'm looking to see some level of community review for permanent 
registrations.  I don't think "specification required" implies that.  In the 
near term, are you OK for me to apply what I claim was the *intent* rather than 
the letter of what is stated in RFC 3864 (e.g. ask for IETF review before 
agreeing to permanent registration)?  For the longer term, revising 
BCP90/RFC3854 would seem to be the right thing to do.

...

The original *intent* of the RFC3864 text was to be stronger than just 
"specification required" for permanent header field registration.  For RFC-based 
publications, it was more like "IETF Review" to use a term from 
http://tools.ietf.org/html/rfc5226.

I think that intent is stated at http://tools.ietf.org/html/rfc3864#section-2.1, 
but the registration requirements that follow, in that section and at 
http://tools.ietf.org/html/rfc3864#section-4.2, didn't allow for the RFC ISE stream.

(Separately: allowing non-IETF standards seemed and seems to me to be a 
reasonable thing to allow, and by my understanding would allow new permanent 
header fields to be registered though, e.g., W3C recommendation-track 
publication, etc.  I don't think that's a lowering of the bar.)

So the drafting of the publication requirements is at odds with the stated 
intent.  Which I think raises two questions:

1. Can this be treated as a drafting error and fixed accordingly?

2. My sense at the time of drafting RFC3864 was that the community felt that 
permanent header fields should undergo a level of review consistent with a 
standards action.  Is this still the community view, or is there consensus to 
relax the requirements?

My feeling is that relying on the designated expert to make technical judgement 
about specifications can be problematic.  By their nature, header fields deal 
with a very broad range of technical issues, and it is difficult for a single 
reviewer to be conversant with the entire range of concerns involved, and hence 
to make judgement about whether the specifications are sufficient to enable 
interoperable implementation.  As a reviewer, my approach has been to look for 
evidence of suitable review by a qualified community.  Where I have technical 
concerns of my own, I separate them from my response as designated reviewer 
(unless there is a clear violation of a technical requirement).

Thus, I think that your interpretation is slightly at odds with mine, because I 
was expecting to see some review beyond simply making a judgement about whether 
the specification is "properly done".  For example, I would like to be able to 
ask for unreviewed proposals to be announced on the header fields review mailing 
list, with notifications to appropriate technical groups, so that they can be 
subjected to review (as described for non-RFC specifications per 
http://tools.ietf.org/html/rfc3864#section-4.3).  I am not seeing this as an 
option under the "specification required" criteria, but maybe you see it 
differently?

#g
--

---

From: Graham Klyne <[email-masked]>
Date: Tue, 15 Apr 2014 12:03:48 +0100

Hi Alexey,

> What about header field registrations from other SDOs (e.g. W3C)?

I tend to regard a W3C recommendation track publication, or similar, as 
incorporating a good level of review.  However, I would also interpret 
http://tools.ietf.org/html/rfc3864#section-4.3 as indicating that non-RFC 
publications should be submitted to [email-masked] for review.

I think that submission to [email-masked] would be good 
practice for any registration.

#g
--

---

From: Barry Leiba <[email-masked]>
Date: Tue, 15 Apr 2014 13:00:33 -0400

> registrations.

Ack.  And what I was trying to say in the on-list message is that at
the first level, we're ok now: the DE can make a judgment about
whether there's been enough review, and can ask for more.  Nevil is
always eager to get the right review for documents, and will work with
you on it.

IOW, I think the existing registration process can work fine for us
for now, until we update it.

We do still have to decide whether it's really necessary for header
fields to have such thorough review -- I'm not convinced.  But in the
meantime, the DE's judgment can drive whatever review we want for now.

b

>  I don't think "specification required" implies that.  In the
> near term, are you OK for me to apply what I claim was the *intent* rather
> than the letter of what is stated in RFC 3864 (e.g. ask for IETF review
> before agreeing to permanent registration)?  For the longer term, revising
> "specification required" for permanent header field registration.  For
> RFC-based publications, it was more like "IETF Review" to use a term from
> I think that intent is stated at
> http://tools.ietf.org/html/rfc3864#section-2.1, but the registration
> requirements that follow, in that section and at
> standards action.  Is this still the community view, or is there consensus
> to relax the requirements?
>
> My feeling is that relying on the designated expert to make technical
> judgement about specifications can be problematic.  By their nature, header
> fields deal with a very broad range of technical issues, and it is difficult
> for a single reviewer to be conversant with the entire range of concerns
> involved, and hence to make judgement about whether the specifications are
> sufficient to enable interoperable implementation.  As a reviewer, my
> approach has been to look for evidence of suitable review by a qualified
> community.  Where I have technical concerns of my own, I separate them from
> my response as designated reviewer (unless there is a clear violation of a
> technical requirement).
>
> Thus, I think that your interpretation is slightly at odds with mine,
> because I was expecting to see some review beyond simply making a judgement
> about whether the specification is "properly done".  For example, I would
> like to be able to ask for unreviewed proposals to be announced on the
> header fields review mailing list, with notifications to appropriate
> technical groups, so that they can be subjected to review (as described for
> non-RFC specifications per http://tools.ietf.org/html/rfc3864#section-4.3).
> I am not seeing this as an option under the "specification required"
> criteria, but maybe you see it differently?
>
> #g
> --
>
>
>>>> registration

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 16 Apr 2014 14:20:53 +0100

On Apr 15, 2014, at 11:02 AM, Graham Klyne <[email-masked]> wrote:

> TL;DR: I'm looking to see some level of community review for permanent registrations.

Which community do you mean here?  The Internet community?  The IETF community? some other?

All I-D are available for community review and those submitted to the ISE for independent review have significant review as part of that process.  Of course, this is not the same as IETF Review (or IETF Consensus).

— Kurt