Subject: [yam] draft template for YAM early IESG review

From: Chris Newman <[email-masked]>
Date: Wed, 29 Jul 2009 14:49:08 +0200

The YAM WG has this text in the charter:

===
On a case by case basis, substantive changes may be considered, if they
will modify text to match existing conforming implementations -- that
is, implementations that are already deployed with significant use.
Specifically, such changes will be permitted to relax requirements or
to fix BNF bugs where the intent is and has been clear. The WG will
consult with the IESG about proposed changes before it starts working
on them. Once the document is done by the WG, approval proceeds
using the normal IETF approval process. The two step approach is proposed
in order to save both IESG and WG time and to avoid late surprises
when a document is considered done by the WG.
===

Which we need to implement.  I've been asked to create a template for 
sending documents to the IESG for early review.  Here's a first draft:

--------
The YAM WG has evaluated the following document for advancement from draft 
to full standard:
  http://tools.ietf.org/html/rfc<number>

Date published:

Link to draft standard interop report:
  ...

Proposed Changes (the WG proposes making the following changes in a 
revision):
  ...

Non-Changes (the WG discussed and chose not to make the following changes):
  ...

Downrefs (At full standard, the following references would be downrefs):
  ...

The YAM WG requests feedback from the IESG on this decision.  In particular:
1. Does the IESG believe the proposed changes are suitable during a move 
from draft to
   full standard?
2. Does the IESG believe any other proposed changes are necessary to 
satisfy IESG
   requirements to advance to full standard?
3. Does the IESG consider the downrefs acceptable for a full standard?
--------

		- Chris

---

From: Chris Newman <[email-masked]>
Date: Wed, 29 Jul 2009 16:11:40 +0200

> sending documents to the IESG for early review.  Here's a first draft:

On the running code principle, I decided to apply the template to one of 
the documents on our work list to see how the implementation goes.  Tony 
had asked me how the template would work if the working group wanted to 
advance an RFC on the standards track with no changes, so this is what it 
would look like if the WG made that decision with RFC 3282 (Content 
Language Headers):

=======
The YAM WG has evaluated the following document for advancement from draft 
to full standard:
  Content Language Headers
  http://tools.ietf.org/html/rfc3282

Date published: May 2002

Link to draft standard interop report:
  not archived, Patrik Faltstrom was responsible AD.

Proposed Changes (the WG proposes making the following changes in a 
revision):
  None.  The WG would like to save the cost of RFC revision and 
republication
  as no technical changes are needed.

Non-Changes (the WG discussed and chose not to make the following changes):
  Split references into normative and informative sections
  Add IANA Considerations section
     If new RFC were published, then IANA would need to update Message 
Header
     Registry.  If current RFC is kept, no IANA action is required.
  Update references which have been superceded
  Update BCP 47 reference from RFC 3066 to RFC 4646 & 4647
  Apply new legal boilerplate

Downrefs (At full standard, the following references would be downrefs):
  RFC 2822 Message Format (reference to CFWS, won't change in revisions)
  RFC 2616 HTTP (reference to meaning of q value for Accept-Language)
  RFC 2234 ABNF (no change in relevant parts of full standard revision)

The YAM WG requests feedback from the IESG on this decision.  In particular:
1. Does the IESG believe the proposed changes are suitable during a move 
from
   draft to full standard?
2. Does the IESG believe any other proposed changes are necessary to satisfy
   IESG requirements to advance to full standard?
3. Does the IESG consider the downrefs acceptable for a full standard?
========

Incidentally, if the WG did have rough consensus on the above write-up, I 
would be very interested in the IESG's response.  If I were on the IESG 
trying to respond to this, this is the sort of response I'd consider:

1. IESG likes the idea to save the cost of RFC publication, go ahead as 
proposed.
2. IESG believes the improvement if the WG applied the non-changes listed 
above would be worth the extra cost and strongly prefers the WG make those 
changes.
3. The downref to HTTP is problematic as the meaning and use of q value may 
change in a revision.  This effort should seek feedback from the HTTP 
community on that topic or wait for HTTP to advance on the standards track.

Comments?

		- Chris