Subject: Re: DRAFT Revision to the WG Document Writeup (about IPR)

From: Russ Housley <[email-masked]>
Date: Thu, 9 Feb 2012 21:01:08 -0500

It has taken me a very long time to incorporate all of the comments into a revised draft of the WG Document Writeup.  Here is the revision.  Please review and comment.

Russ

= = = = = = = = = 

Document Writeup

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This DRAFT version is dated
9 February 2012.

  (1) Briefly describe the review of this document that was
      performed by the Document Shepherd.  If this version of the
      document is not ready for publication, please explain why the
      document is being forwarded to the IESG.

  (2) Has the document had adequate review both from WG participants? 
      Does the Document Shepherd have any concerns about the depth or
      breadth of the reviews that have been performed?  

  (3) Do portions of the document need review from a particular or
      from broader perspective, e.g., security, operational complexity,
      AAA, DNS, DHCP, XML, or internationalization? If so, describe the
      review that took place.

  (4) Describe any specific concerns or issues that the Document
      Shepherd has with this document that the Responsible Area
      Director and/or the IESG should be aware of? For example,
      perhaps he or she is uncomfortable with certain parts of the
      document, or has concerns whether there really is a need for it.
      In any event, if the WG has discussed those issues and has
      indicated that it still wishes to advance the document, detail
      those concerns here.

  (5) Has an IPR disclosure been filed that references this document?
      If so, summarize any WG discussion and conclusion regarding the
      IPR disclosures.

  (6) How solid is the WG consensus behind this document? Does it 
      represent the strong concurrence of a few individuals, with 
      others being silent, or does the WG as a whole understand and 
      agree with it?   

  (7) Has anyone threatened an appeal or otherwise indicated extreme 
      discontent? If so, please summarise the areas of conflict in 
      separate email messages to the Responsible Area Director. (It 
      should be in a separate email because this questionnaire is 
      publicly available.) 

  (8) Identify any ID nits the Document Shepherd has found in this
      document. (See the Internet-Drafts Checklist and
      http://www.ietf.org/tools/idnits/). Boilerplate checks are not
      enough; this check needs to be thorough.

  (9) Describe how the document meets any required formal review
      criteria, such as the MIB Doctor, media type, and URI type
      reviews.

 (10) Have all references within this been document been identified
      as either normative and informative? Are there normative
      references to documents that are not ready for advancement or
      are otherwise in an unclear state? If such normative references
      exist, what is the plan for their completion? Are there normative
      references that are downward references (see [RFC3967])? If so,
      list these downward references to support the Area Director in
      the Last Call procedure. 

 (11) List other RFCs that this document obsoletes, and indicate whether 
      the to-be-obsolete RFCs are listed in both the title page header
      as well as in the Abstract and Introduction. Which if these RFCs,
      if any, are to be moved to Historic? Is this change of status
      explicitly stated in the document Introduction.

 (12) List other RFCs that this document updates, and indicate whether
      they appear in both the title page header as well as in the
      Abstract and Introduction.

 (13) Describe the Document Shepherd's review of the IANA considerations
      section, especially with regard to its consistency with the body
      of the document. Confirm that all protocol extensions that the
      document makes are associated with the appropriate reservations
      in IANA registries. Confirm that any referenced IANA registries
      have been clearly identified. Confirm that newly created IANA
      registries include a detailed specification of the initial
      contents for the registry, that allocations procedures for
      future registrations are defined, and a reasonable name for the
      new registry has been suggested (see [RFC5226]). List any IANA 
      Experts that the IESG will need to appoint during IESG Evaluation
      for any new registries that require Expert Review for future
      allocations.

 (14) Describe reviews and automated checks performed by the Document
      Shepherd to validate sections of the document written in a formal
      language, such as XML code, BNF rules, MIB definitions, etc.

 (14) The IESG approval announcement includes a Document Announcement
      Write-Up. Please provide such a Document Announcement Write-Up.
      Recent examples can be found in the "Action" announcements for
      approved documents. The approval announcement contains the
      following sections:

      Technical Summary

        Relevant content can frequently be found in the abstract 
        and/or introduction of the document. If not, this may be 
        an indication that there are deficiencies in the abstract 
        or introduction.

      Working Group Summary

        Was there anything in WG process that is worth noting? For 
        example, was there controversy about particular points or 
        were there decisions where the consensus was particularly 
        rough?

      Document Quality

        Are there existing implementations of the protocol? Have a 
        significant number of vendors indicated their plan to 
        implement the specification? Are there any reviewers that 
        merit special mention as having done a thorough review, 
        e.g., one that resulted in important changes or a 
        conclusion that the document had no substantive issues? If 
        there was a MIB Doctor, Media Type or other expert review, 
        what was its course (briefly)? In the case of a Media Type 
        review, on what date was the request posted?

      Personnel

        Who is the Document Shepherd? Who is the Responsible Area
        Director.

---

From: Tina TSOU <[email-masked]>
Date: Fri, 10 Feb 2012 02:03:42 +0000

Tina

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Russ Housley
> Sent: Thursday, February 09, 2012 6:01 PM
> To: IETF WG Chairs
> Subject: Re: DRAFT Revision to the WG Document Writeup (about IPR)
> 
> It has taken me a very long time to incorporate all of the comments into a
> revised draft of the WG Document Writeup.  Here is the revision.  Please
> review and comment.
> 
> Russ
> 
> = = = = = = = = =
> 
> Document Writeup
> 
Both from WG participants and what?

---

From: Russ Housley <[email-masked]>
Date: Thu, 9 Feb 2012 21:07:12 -0500

> Both from WG participants and what?

Editing remnant.  Please ignore "both"

Russ

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 9 Feb 2012 21:02:12 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ Housley

Another editing remnant:

>  (10) Have all references within this been document been identified [...]

s/this been/this/

>       explicitly stated in the document Introduction.

s/./?/

>       Abstract and Introduction.

There was some recent chatter about whether or not it's appropriate to list these things in both places as well as the title page header.  Was there consensus?  If so, should these two be updated?

-MSK

---

From: Russ Housley <[email-masked]>
Date: Fri, 10 Feb 2012 01:04:07 -0500

Murray:

Thanks for the editorial changes.

> There was some recent chatter about whether or not it's appropriate to list these things in both places as well as the title page header.  Was there consensus?  If so, should these two be updated?

This remains consistent with the outcome I believe.  It is certainly consistent with IDnits.

Russ

---

From: <[email-masked]>
Date: Fri, 10 Feb 2012 10:01:13 -0500

Russ,

>       Abstract and Introduction.

For both of these items, is the "and" in "Abstract and Introduction" intended
to be AND, OR, or XOR ?

I had a recent encounter w/idnits where it recommended that this info be
in the Abstract, but the authors chose the Introduction.

In (13), this sentence could be misread as requiring the writeup to nominate
the IANA Experts:

>       List any IANA

Assuming that this was not intended, here's an attempt at a rewrite:

        List any new registries that require Expert Review for future
        allocations.  Is there any guidance that the IESG would find useful
        in appointing the IANA Experts for these new registries?  If so,
        provide it here, keeping in mind that this questionnaire is publicly
        available.
	
The "keeping in mind" is intended to provide a hint along the lines of "if
you nominate IANA Experts here, make sure you've asked them first" ;-).

Thanks,
--David

> Sent: Thursday, February 09, 2012 9:01 PM
> To: IETF WG Chairs
> It has taken me a very long time to incorporate all of the comments into a revised draft of the WG
> Document Writeup.  Here is the revision.  Please review and comment.
> 
> Russ
> 
> = = = = = = = = =
> 
> Document Writeup
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 10 Feb 2012 10:21:14 -0500

John:

How about:

 (12) List other RFCs that this document updates, and indicate whether
      they appear in both the title page header as well as in the
      Abstract and Introduction. If the updated RFCs are not listed
      in the Abstract and Introduction, explain why, and point to part
      of the document that describes the nature of the updates. If this
      information is not in the document, explain why  the WG considers
      it unnecessary.

I will put the discussion of "IESG Considerations" into the I-D on the agenda of a future meeting.

WG chair are the people that are most impacted by an update to this writeup template, so this seems like the best place to start the review process.  RFC 4858 does not expect a heavy-weight process to make changes to this template, so I had not thought much about further review.

Russ

On Feb 10, 2012, at 9:09 AM, John C Klensin wrote:

> 
> 
> --On Friday, February 10, 2012 01:04 -0500 Russ Housley
> <[email-masked]> wrote:
> 
>>>> (12) List other RFCs that this document updates, and
>>>> indicate whether they appear in both the title page header
>>>>     as well as in the Abstract and Introduction.
>>> 
>>> There was some recent chatter about whether or not it's
>>> appropriate to list these things in both places as well as
>>> the title page header.  Was there consensus?  If so, should
>>> these two be updated?
>> 
> Russ, I think it is consistent with the outcome in the sense
> that it says "and indicate" rather than some variation on "make
> sure it is there".  But I think the the fuzziness might, itself,
> be confusing.  I also think that the other side of the
> discussion was actually to get some useful information in there.
> Usually "this updates RFC NNNN" is not really useful
> information, at least in the same sense that "this updates RFC
> NNNN, changing A, B, and C because..." might be.  Although
> others might disagree, I don't think one wants to go into detail
> here.  But would some phrasing like the following better address
> the issue (and what the IESG is trying to find out):
> 
> 	If this document updates other RFCs, are they listed in
> 	the title page header and, if not, why not?  What other
> 	provisions have been made to identify the relationship
> 	(e.g., listing in the Abstract and/or Introduction)?
> 	Are the nature of the changes identified and explained
> 	and, if not, why does the WG consider that unnecesary?
> 
> I think that can be tuned, but I think it would be useful to
> both get a little more information and to at least slightly
> reduce the guessing game around "if I 'indicate' that the
> information isn't in both the Abstract and Introduction, what
> happens then".   My understanding was that the IESG was inclined
> to move toward a "do it or explain why not (or at least that you
> thought about it and decided not to, rather that forgetting).
> If that is the case, then the text in the draft doesn't reflect
> it very well.
> 
> Three additional thoughts:
> 
> (1) I remain troubled by statements about consistency with
> IDnits.  IDNit is not a consensus document or algorithm.   If a
> statement or requirement is to be justified on the basis of
> consistency with something else, can we please confine the
> targets to things that have achieved community consensus.
> 
> (2) The other idea that came up in that set of conversations was
> the possibility of allowing (or encouraging or requiring) more
> material with the same treatment as the IANA Considerations
> section, i.e., required in the I-D and for LC and other reviews,
> but with instructions to the RFC Editor to remove them before
> publication.  At least some of the people who are most strongly
> opposed to simple "This updates RFC xxxx" statements in
> abstracts would have no problem with a second paragraph of the
> abstract, or a special status paragraph, containing whatever
> information of that sort which the IESG thinks would be helpful
> if it were removed from there on publication.   Has the IESG
> discussed that option?
> 
> (3) May I presume that a version of this draft will be exposed
> on the IETF list for comment before being made "official"?  It
> seems to me that there are a lot of people with experience as
> ADs, WG Chairs, and/or document shepherds, as well as people who
> might take on some of those roles soon, who don't happen to be
> on the WG Chairs list today.
> 
> best,
>   john
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 10 Feb 2012 10:28:46 -0500

> For both of these items, is the "and" in "Abstract and Introduction" intended

AND

> in the Abstract, but the authors chose the Introduction.

Summaries are made of the RFC repository that include the Abstract.  So, we are looking for "this document updated RFC XXXX" in the Abstract, and a description of the nature of the update in the Introduction.

How about:

 (13) Describe the Document Shepherd's review of the IANA considerations
      section, especially with regard to its consistency with the body
      of the document. Confirm that all protocol extensions that the
      document makes are associated with the appropriate reservations
      in IANA registries. Confirm that any referenced IANA registries
      have been clearly identified. Confirm that newly created IANA
      registries include a detailed specification of the initial
      contents for the registry, that allocations procedures for
      future registrations are defined, and a reasonable name for the
      new registry has been suggested (see [RFC5226]). List any new
      registries that require Expert Review for future allocations.
      Provide any public guidance that the IESG would find useful in
      selecting the IANA Experts for these new registries.

Russ

---

From: <[email-masked]>
Date: Fri, 10 Feb 2012 10:51:08 -0500

Russ,

> > For both of these items, is the "and" in "Abstract and Introduction"
> > intended to be AND, OR, or XOR ?
> 
> AND

Suggested edit for clarity in items 11 and 12:

OLD
	both the title page header as well as in the Abstract
	and Introduction
NEW
	all three of a) the title page header, b) the Abstract
	and c) the Introduction.
END

Your revised text for (13) looks fine to me.

Thanks,
--David

> From: Russ Housley [mailto:[email-masked]]
> Sent: Friday, February 10, 2012 10:29 AM
> To: Black, David
> Cc: [email-masked]
> Summaries are made of the RFC repository that include the Abstract.  So, we are looking for "this
> document updated RFC XXXX" in the Abstract, and a description of the nature of the update in the
> Introduction.
>

---

From: John C Klensin <[email-masked]>
Date: Fri, 10 Feb 2012 09:09:22 -0500

best,
   john

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 10 Feb 2012 08:51:36 -0800

Formatting nit, but one that bites me every time: the indenting makes copy-and-paste followed by adding answers hard.

Proposed change:

Current:

Proposed:

This is particularly important for section 14 (well, the second 14: you have two :-) )

--Paul Hoffman

---

From: John C Klensin <[email-masked]>
Date: Fri, 10 Feb 2012 12:14:33 -0500

--On Friday, February 10, 2012 10:21 -0500 Russ Housley
<[email-masked]> wrote:

> John:
> 
> How about:
> 
>  (12) List other RFCs that this document updates, and indicate
> whether they appear in both the title page header as
> well as in the Abstract and Introduction. If the updated
> RFCs are not listed in the Abstract and Introduction,
> explain why, and point to part of the document that
> describes the nature of the updates. If this information
> is not in the document, explain why  the WG considers it
> unnecessary.

You should consider whether you want to ask for a pointer to the
explanation of the changes or an indication or why it is
unnecessary in all cases -- the above asks for that only if
there is no listing in the Abstract and Introduction.   But the
above is more than close enough to solve the problem I was
concerned about.  Thanks.

> I-D on the agenda of a future meeting.

Thanks.  Wfm.  Just didn't want that possibility to get lost.

> WG chair are the people that are most impacted by an update to
> this writeup template, so this seems like the best place to
> start the review process.  RFC 4858 does not expect a
> heavy-weight process to make changes to this template, so I
> had not thought much about further review.

I think that sorting this out on the WG Chair list is absolutely
a reasonable thing to do.  Certainly, of all the lists we have,
it has the highest density of people who are likely to be
concerned enough about document submission issues to review a
draft carefully.  But there are folks in the community would
might be able to make useful contributions to this if they knew
about it; giving them that opportunity seems like a good idea.
Equally important, I think we have all noticed that things that
are designed as guidance (including IDnits, RFC 4859, etc.)
sometimes gradually slide into being normative requirements as,
e.g., ADs with insufficient organizational memory hold documents
up on review because those documents do not "conform" to that
guidance.

Because nasty surprises that show up after a WG thinks it is
finished are, at best, not helpful, I think the more that can be
done to expose the contents of (the nearly-finished form of) a
document like this to the community and get community sign-off,
the better off we all are.

YMMD.

     john

---

From: John C Klensin <[email-masked]>
Date: Fri, 10 Feb 2012 12:41:42 -0500

--On Friday, February 10, 2012 10:28 -0500 Russ Housley
<[email-masked]> wrote:

>...
>> I had a recent encounter w/idnits where it recommended that
>> this info be in the Abstract, but the authors chose the
>> Introduction.
> 
> Summaries are made of the RFC repository that include the
> Abstract.  So, we are looking for "this document updated RFC
> XXXX" in the Abstract, and a description of the nature of the
> update in the Introduction.

Hmm.  I didn't understand until now that those summaries of
published RFCs were part of the motivation for wanting that
sentence in the Abstract.    Given the number of RFCs that have
been published before this suggestion was made that don't
include an "updates" sentence in the Abstract, wouldn't it be a
lot more effective to recommend that those compiling such
summaries use the 
"updates" header or, even better, the RFC Index to capture that
information.

Since it hasn't been said on  this list, I'm strongly in favor
of putting "updates" information in the abstract if it is
critical to the reason the document was written.  But then, I'd
expect to see "This updates RFC NNNN by changing ... to ... and
...", which really might be useful abstract material.

For the more common case, someone who is looking for a RFC or
trying to understand what is covers is a lot more interested in
current specifications and that information rather than the
back-thread.    As others have pointed out, a forward thread is
actually a lot more important, but that information cannot be
obtained from abstracts (or any other part of a published
document).

best,
    john

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Feb 2012 08:19:00 +1300

> 	all three of a) the title page header, b) the Abstract

Stated like that, of course, it looks like a purely bureaucratic
and rather pointless requirement. Rather along the lines that John
suggested, the guideline (not rule) should probably be that
the Abstract indicates the scope of the update in very general
terms, and the Introduction describes it more specifically
(e.g. mentions which part of the protocol is modified).

    Brian

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 11 Feb 2012 02:44:03 +0100

One thing I have noted recently is a number of documents that have got beyond publication request (indeed even to IESG ballot) and have then changed status (e.g. informational to proposed standard).

I certainly change the style of my review for an informational document and a proposed standard document, and therefore a change at this late stage could mean the document has not had the best targeted review.

Could I suggest adding something at the publication request stage that tries to identify if it has been verified that the document is submitted as the correct type of document.

Regards

Keith

> Sent: 10 February 2012 02:01
> To: IETF WG Chairs

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 10 Feb 2012 18:06:14 -0800

> Could I suggest adding something at the publication request stage that tries to identify if it has been verified that the document is submitted as the correct type of document.

As someone who is "guilty as charged", I give a +1 to this.

--Paul Hoffman

---

From: Fred Baker <[email-masked]>
Date: Sun, 12 Feb 2012 22:44:05 -0500

On Feb 10, 2012, at 2:19 PM, Brian E Carpenter wrote:

> Stated like that, of course, it looks like a purely bureaucratic and rather pointless requirement. 

to be honest, a lot of this looks bureaucratic to me. If the draft states (as it has the option to via xm2rfc and in any event in the first page header) that it updates an RFC, it seems that information could be derived from the document without ALSO being included in the abstract. The document shepherd's review is available online; why does it ALSO need to be described (first question)? Specifically what description is called for in addition to what is online?

To my small and inefficient mind, the questions in this document should address the questions the IESG asks itself, the shepherd, and the authors. Ideally, having answered them, any further questions the IESG has should be specific to the document, not general. And they should need to be answered once, in one place.

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Mon, 13 Feb 2012 11:13:21 +0100

+1.

G/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Fred Baker (fred)
Sent: maandag 13 februari 2012 4:44
To: Russ Housley
Cc: Working Group Chairs; Brian E Carpenter
Subject: Re: [BOFCHAIRS] DRAFT Revision to the WG Document Writeup
(about IPR)

> Stated like that, of course, it looks like a purely bureaucratic and
rather pointless requirement. 

to be honest, a lot of this looks bureaucratic to me. If the draft
states (as it has the option to via xm2rfc and in any event in the first
page header) that it updates an RFC, it seems that information could be
derived from the document without ALSO being included in the abstract.
The document shepherd's review is available online; why does it ALSO
need to be described (first question)? Specifically what description is
called for in addition to what is online?

To my small and inefficient mind, the questions in this document should
address the questions the IESG asks itself, the shepherd, and the
authors. Ideally, having answered them, any further questions the IESG
has should be specific to the document, not general. And they should
need to be answered once, in one place.

---

From: Acee Lindem <[email-masked]>
Date: Mon, 13 Feb 2012 06:08:14 -0500

+1 - I'm perfectly happy with the current document shepherd template. 
Acee

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 13 Feb 2012 10:19:45 -0500

Russ,

Personally I would like (14) Writeups first and then the other sections 
as background.

	Olafur

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 13 Feb 2012 11:45:57 -0500

On Sun, 2012-02-12 at 22:44 -0500, Fred Baker wrote:
>  states (as it has the option to via xm2rfc and in any event in the
>  first page header) that it updates an RFC, it seems that information
>  could be derived from the document without ALSO being included in the
>  abstract.

Except that the entire _point_ of the abstract is that people can read
it to get an idea of what the document is about when they don't _have_
the document.  An abstract needs to stand _completely_ on its own; the
person reading it doesn't have metadata from XML or our tracker or the
first-page header.

To a lesser extent, this applies to the introduction, too -- the person
reading the introduction to a published RFC (or even an I-D) isn't
reading the XML or the tracker; they're reading the text.  I'd certainly
agree that there's no specific need to duplicate this information in
both the introduction _and_ the header.  However, as long as the
canonical version of our documents is the plain text and not XML, it
needs to be in some standard, machine-readable place so that tools can
find it.  Whether it _also_ needs to be mentioned in the introduction is
IMHO a matter of style and should mostly be left up to the
author/editor, though personally I'll generally encourage doing so.

>  The document shepherd's review is available online; why does
>  it ALSO need to be described (first question)? Specifically what
>  description is called for in addition to what is online?

Hm?  The writeup that is the answer to these questions is available
online.  But the shepherd is also expected to read and review the
document, and there's no standard place to find the results of that,
unless you count reading the mailing list and looking for it, which
won't always be successful, because there is no requirement that the
shepherd post any comments (I usually find something to comment on, but
not always).

In any case, the point of the question is not to obtain information, but
to cause the shepherd to do a review _before_ submitting the writeup, so
he can answer "yes".  The same goes for most of these questions -- in
most cases, there is a common, trivial answer and a less common answer
that requires explanation; the point is to get the shepherd to check on
these things and point out anything unusual.  

-- Jeff

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Feb 2012 09:27:46 +1300

> person reading it doesn't have metadata from XML or our tracker or the

Allow me to invent an example of what I think would be reasonable:

Updates: 791

Abstract

This document updates the IPv4 specification (RFC 791) by abolishing fragmentation.

Introduction

Since [RFC791] introduced the notion of dynamic fragmentation and reassembly
of Internet Protocol packets, it has proved to be operationally complex
and error-prone (for example, see [RFC1435], [RFC2923], [RFC4459]). It also
creates security risks [RFC1858], [RFC3128]. This document therefore
removes the notion of fragmentation from IP version 4 and redefines the
associated header fields as reserved for future use.

   Brian

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 13 Feb 2012 17:24:43 -0500

> Allow me to invent an example of what I think would be reasonable:

OK, so we are in agreement.

Though it seems like assembling those references is an awful lot of
effort to go to in order to demonstrate that. :-)

---

From: Russ Housley <[email-masked]>
Date: Wed, 15 Feb 2012 13:25:47 -0500

The numbers have changed to address another comment.  I hope this wording captures your concern. 

(12) List other RFCs that this document obsoletes, and indicate whether 
      the to-be-obsolete RFCs are listed in the title page header, in
      the Abstract, and in the Introduction. Which of these RFCs, if
      any, are to be moved to Historic? Is this change of status
      explicitly stated in the document Introduction?

 (13) List other RFCs that this document updates, and indicate whether
      they appear in the title page header, in the Abstract, and in the
      Introduction. If the updated RFCs are not listed in the Abstract
      and Introduction, explain why, and point to part of the document
      that describes the nature of the updates. If this information is
      not in the document, explain why the WG considers it unnecessary.

Russ

---

From: <[email-masked]>
Date: Wed, 15 Feb 2012 13:41:21 -0500

Looks good, Thanks, --David

> Sent: Wednesday, February 15, 2012 1:26 PM
> To: Black, David
> Cc: [email-masked]

---

From: Russ Housley <[email-masked]>
Date: Wed, 15 Feb 2012 15:54:28 -0500

I believe that I have addresses all comments, including the requests for a different style and ordering.

Russ

= = = = = = = = =

Document Writeup

15 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

Working Group Summary

Document Quality

 Personnel

   Director?

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

(4) Has the document had adequate review from WG participants? Does the
document Shepherd have any concerns about the depth or breadth of the
reviews that have been performed?  

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

(9) How solid is the WG consensus behind this document? Does it 
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?   

(10) Has anyone threatened an appeal or otherwise indicated extreme 
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.) 

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

(13) Have all references within this document been identified as
either normative and informative? Are there normative references to
documents that are not ready for advancement or are otherwise in an
unclear state? If such normative references exist, what is the plan for
their completion? Are there normative references that are downward
references (see RFC 3967)? If so, list these downward references to
support the Area Director in the Last Call procedure. 

(14) List other RFCs that this document obsoletes, and indicate whether
the to-be-obsolete RFCs are listed in the title page header, in the
Abstract, and in the Introduction. Which of these RFCs, if any, are to
be moved to Historic? Is this change of status explicitly stated in the
Introduction?

(15) List other RFCs that this document updates, and indicate whether
they appear in the title page header, in the Abstract, and in the
Introduction. If the updated RFCs are not listed in the Abstract and
Introduction, explain why, and point to part of the document that
describes the nature of the updates. If this information is not in
the document, explain why the WG considers it unnecessary.

(16) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
List any new registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

(17) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

---

From: <[email-masked]>
Date: Wed, 15 Feb 2012 21:30:52 +0000

Item 3 of the writeup says: "If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG."

Is it really possible that a WG chair would be forwarding a document when
he/she is aware that it is not ready?

-Basavaraj

---

From: Fred Baker <[email-masked]>
Date: Wed, 15 Feb 2012 15:51:49 -0700

> he/she is aware that it is not ready?

I think the objective is to (a) make the IESG and community review easier and (b) give the WG Chair an objective measure of readiness.

---

From: Joe Touch <[email-masked]>
Date: Wed, 15 Feb 2012 14:54:51 -0800

FWIW, there are cases where the WG chair doesn't think a doc is ready 
but the authors insist otherwise; that's still a legitimate case where 
the WG chair's perspective can be given and the IESG involved to resolve 
the issue.

Joe

On 2/15/2012 2:51 PM, Fred Baker wrote:
>
> On Feb 15, 2012, at 2:30 PM,<[email-masked]>  <[email-masked]>  wrote:
>
>>
>> On 2/15/12 2:54 PM, "ext Russ Housley"<[email-masked]>  wrote:
>>

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 16 Feb 2012 10:05:14 -0500

> I believe that I have addresses all comments, including the requests for a different style and ordering.

Thanks Russ,
this looks good (much better than current template).
I really like item (1) to be there not having the intended status in the 
writeup lead to errors and problems:

Do you want to tell the DS to check the document header is in compliance 
with the request?
Current:
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?

Proposal:
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?
Does the header in the draft state this ?

	Olafur

---

From: Brian Haberman <[email-masked]>
Date: Thu, 16 Feb 2012 11:46:02 -0500

Olafur,
      This is a good point for me to inject a comment...

> Does the header in the draft state this ?

These types of checks can be automated and would be easy to accomplish 
if the DS writeup was an on-line form that the chair must fill out when 
requesting advancement.  Conceptually, the form would look much like the 
draft submission form in use today.

Can we get such a functionality added as a To Do?

Regards,
Brian

---

From: "Scott O. Bradner" <[email-masked]>
Date: Wed, 15 Feb 2012 18:27:52 -0500

> It has taken me a very long time to incorporate all of the comments into a revised draft of the WG Document Writeup.  Here is the revision.  Please review and comment.
…

to me, the goal should be having this as a web page to be filled in - that puts constraints on how many questions
you can ask at once 

>      breadth of the reviews that have been performed?  

the two sentences above seem redundant

>      list these downward references to support the Area Director in

multiple questions in a question - maybe ask if the references are properly segmented 
and explain any possibly blocking or downward  references - (a series of questions within a single 
one is a pain if each has to be answered - that is one of the big pains of the current version and
stands in the way of making this a web page to be filled in

>      Abstract and Introduction.

for 11 & 13 why not  just ask if any changes to the status of existing RFCs (e.g. obsoleting, moving to historic, etc.) are
listsed on the title page header, abstract & introduction?

>      for any new registries that require Expert Review for future

see above - lots of questions in a pile

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 17 Feb 2012 00:19:02 +0100

Assuming question 1 is the response to my comment, I did expect something a bit more penetrating to ensure the right decision had been made. Perhaps...

> Internet Standard, Informational, Experimental, or Historic)? Please identify why you consider this is the correct type of RFC.

Where the answer is not "This is the type of RFC identified when the milestone was set".

Typical answers might be:

Proposed standard: It defines a protocol where meeting the normative requirements defines conformance to the protocol.

Informational: It defines new values for the protocol where IANA registration requires only a informational RFC.

Regards

Keith

> Sent: 15 February 2012 20:54
> To: IETF WG Chairs
> Subject: Re: DRAFT Revision to the WG Document Writeup
>

---

From: Russ Housley <[email-masked]>
Date: Tue, 21 Feb 2012 12:59:18 -0500

I have incorporated the last round of comments.  I think we are probably ready to start using this and get some experience with it.

Russ

= = = = = = = = =

Document Writeup

21 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is the proper type of RFC?  Is this type of RFC indicated in the title
page header?

Technical Summary

Working Group Summary

Document Quality

 Personnel

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?  

(13) Have all references within this document been identified as
either normative and informative?

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure. 

(16) Will publication of this document change to the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

(17) Describe the Document Shepherd's review of the IANA considerations

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

---

From: Ross Callon <[email-masked]>
Date: Tue, 21 Feb 2012 15:38:15 -0500

Minor nit: 

The "and" above should be "or".

Ross

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Tuesday, February 21, 2012 12:59 PM
To: IETF WG Chairs
Subject: Re: DRAFT Revision to the WG Document Writeup

Russ

= = = = = = = = =

Document Writeup

Technical Summary

Working Group Summary

Document Quality

 Personnel

---

From: Russ Housley <[email-masked]>
Date: Tue, 21 Feb 2012 15:43:01 -0500

Thanks.  I'll fix it.

Russ

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 22 Feb 2012 04:34:34 +0100

Seem to be missing the word "this".

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?  Why is this the proper type of RFC?  Is this type of RFC indicated in the title page header?

Regards

Keith

> Sent: 21 February 2012 17:59
> To: IETF WG Chairs
> I have incorporated the last round of comments.  I think we are probably
> ready to start using this and get some experience with it.
> 
> Russ
> 
> = = = = = = = = =
> 
> Document Writeup
>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 23 Feb 2012 08:30:07 -0800

I know you want to close out this version, but another idea just occurred to me that would be valuable for the checklist:

If this is a "bis" document, was there any errata filed on the base RFC? If so, have all of them been included in this new document?

--Paul Hoffman