Re: I-D Action:draft-housley-iesg-rfc3932bis-12.txt

[Alfred Hönes]

Folks,

At Tue, 24 Nov 2009 16:00:48 +0100, Julian Reschke wrote:

> To illustrate the problem: for "IETF Experimental, with Consensus
> Call", we get:
>
>"This document defines an Experimental Protocol for the Internet
> community. This document is a product of the Internet Engineering
> Task Force (IETF). It represents the consensus of the IETF
> community..."
>
> I think
>
>"This document defines an Experimental Protocol for the Internet
> community. It is a product of the Internet Engineering Task Force
> (IETF) and represents the consensus of the IETF community..."
>
>
> would read much better.
>
> Best regards, Julian


(1)
For clarity in the "Experimental" case, I'd like to add:

The sentence,
   "Discussion and suggestions for improvement are requested."
had been left over in multiple examples in Appendix A.  It had
been confirmed that it would be deleted in all instances, since
this sentence does not appear in the normative text of the memo.
But apparently, it has been left undetected in the example in A.2.


At Mon, 26 Jan 2009 10:52:20 +0100, Olaf Kolkman wrote:
> On Jan 23, 2009, at 5:13 PM, Alfred Hönes wrote:
>
> ...
>
> Again Alfred, thanks ...
>
> You identified 2 issues, that have not been brought up before. And
> although we should have passed the done-is-done point I think that
> these points are substantive enough to address, while IMHO not really
> contentious, and since I am spinning the document for all the NITS I
> plan to address them as below.
>
>>   start quote  
>>
>> However, I have one general concern, and one important suggestion:
>>
>> The boilerplate sentence
>>  "Discussion and suggestions for improvement are requested."
>> apparently now shall only be included for Experimental RFCs.
>>
>> In the past, it was generally applied, and I always understood
>> it to be at the heart of the IETF process and culture.
>> I don't recall that this topic has been discussed on the list,
>> so it's dropping might have happened inadvertantly.  Please check.
>> IMHO, Proposed Standards (for instance) would need feedback
>> perhaps even more than Experimental documents; only for RFCs
>> immediately published as Historic this clause makes less sense.
>> In the case of Independent Submissions describing 3rd-party
>> protocols, RFC publication might have been sought for just this
>> goal, to start discussion in the IETF at large.
>> According to my experience, even the IAB appreciates feedback
>> to IAB Stream RFCs after publication.   :-)
>
> This inconsistency seemed to have been introduced inadvertently.
>
> I propose to _not_ have this information in the boilerplate but
> include it explicitly in where the "Updates to this Reference"
> refers to (in section 3.4).

... and so it has been confirmed on the list subsequently,
and so happened the text changes, with the sincle exception
of the leftover sentence in Appendix A.2.

Hence, I conclude this sentence can be deleted by the RFC Editor
or in AUTH48 without violating procedural rules.


(2)
Even worse from the stylistic perspective is the "Historic" case;
for instance, assuming an IETF WG documenting an original
contribution to its work (text constructed according to Sect.3):

|  This document is not an Internet Standards Track specification; it
|  has been published for the historical record.
|
|! This document defines a Historic Document for the Internet community.
|! This document is a product of the Internet Engineering Task Force
|  (IETF).  It has been approved for publication by the Internet
|  Engineering Steering Group (IESG).  Not all documents approved by the
|  IESG are candidate for any level of Internet Standards; see Section 2
|  of RFC .


I strongly recommend to change

   "This document defines a Historic Document ..."
to
   "This document is a Historic Document ..."

and continuing with  "It is ..." in the next sentence, as proposed
by Julian for the "Experimental" case above.


(3)
IIRC, the IAB Chair once had stated on the rfc-interest list that,
in order to speed up the approval and publication of the document,
final wordsmithing shall be deferred to the RFC Editor.

Does this still hold?

If yes, please let the RFC Editor perform as usual what they are
being paid for, or adjust the language in AUTH48!

Thanks!




Note -- for the record of those who did not follow the discussion:

The much more pleasant and locical permutation of the same text
for the above case ...

|  This document is a Historic Document for the Internet community.
|  It is not an Internet Standards Track specification; it has been
|  published for the historical record.
|
|  This document is a product of the Internet Engineering Task Force
|  (IETF).  It has been approved for publication by the Internet
|  Engineering Steering Group (IESG).  Not all documents approved by the
|  IESG are candidate for any level of Internet Standards; see Section 2
|  of RFC .

... had been rejected.
There have

Re: I-D Action:draft-housley-iesg-rfc3932bis-12.txt

[Brian E Carpenter]

This version satisfies all my concerns with previous versions. Thanks!

Regards
   Brian Carpenter
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: I-D Action:draft-housley-iesg-rfc3932bis-12.txt

[Julian Reschke]

 
says:


   "Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org//rfc.html"

Can we please recommend *not* to put a file extension into the URL?

BR, Julian

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: I-D Action:draft-housley-iesg-rfc3932bis-12.txt

[Paul Hoffman]

At 6:01 AM +0100 11/18/09, Julian Reschke wrote:
>
> says:
>
>   "Information about the current status of this document, any errata,
>   and how to provide feedback on it may be obtained at
>   http://www.rfc-editor.org//rfc.html"
>
>Can we please recommend *not* to put a file extension into the URL?

+1. "http://www.rfc-editor.org//rfc" is just fine, and is 
what we agreed to before.

--Paul Hoffman, Director
--VPN Consortium
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: I-D Action:draft-housley-iesg-rfc3932bis-12.txt

[Julian Reschke]

Julian Reschke wrote:


 
says:


   "Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org//rfc.html"

Can we please recommend *not* to put a file extension into the URL?

BR, Julian
...


Hi,

in the meantime I have finished a prototype implementation of the new 
boilerplate in rfc2629.xslt (*not* xml2rfc!). The implementation is 
available from , and 
requires the use of two new extension Processing Instructions to enable 
the new boilerplate:


  
  

(where the first enables the new format, while the second provides the 
information about whether there was consensus, something the current 
xml2rfc format doesn't provide).


I haven't found any problems in addition to what was reported before, 
except for a trailing dot in one of the boilerplate statements, and 
cases of repeating sentence beginnings -- maybe all of this can be fixed 
during AUTH48 (although I'd prefer to see this in a new draft for 
community review).


For the record, here's a complete summary:

-- snip --
3.1.  The title page header

 This describes the area where the work originates.
  Historically, all RFCs were labeled Network Working Group.
  "Network Working Group" refers to the original version of today's
  IETF when people from the original set of ARPANET sites and
  whomever else was interested -- the meetings were open -- got
  together to discuss, design and document proposed protocols
  [RFC0003].  Here, we obsolete the term "Network Working Group" in
  order to indicate the originating stream.

  The  is the name of the RFC stream, as defined in
  [RFC4844] and its successors.  At the time of this publication,
  the streams, and therefore the possible entries are:

  *  Internet Engineering Task Force

  *  Internet Architecture Board

  *  Internet Research Task Force

  *  Independent

JRE: as discussed earlier: should this be "Independent Submission"
instead of "Independent"?

   [:]  Some relations between RFCs in the
  series are explicitly noted in the RFC header.  For example, a new
  RFC may update one or more earlier RFCs.  Currently two
  relationships are defined: "Updates", and "Obsoletes" [RFC2223].
  Variants like "Obsoleted by" are also used (e.g in [RFC5143]).
  Other types of relationships may be defined by the RFC Editor and
  may appear in future RFCs.

JRE: "Obsoleted By" is not a variant of "Obsoletes" or "Updates".

3.2.2.  Paragraph 2

   The second paragraph of the "Status of This Memo" will now include a
   paragraph describing the type of review and exposure the document has
   received.  This is defined on a per-stream basis, subject to general
   review and oversight by the RFC Editor and IAB.  There is a specific
   structure defined here to ensure there is clarity about review
   processes and document types.  These paragraphs will need to be
   defined and maintained as part of RFC stream definitions.  Initial
   text, for current streams, is provided below.

   The paragraph may include some text that is specific to the initial
   document category, as follows: when a document is Experimental or
   Historic the second paragraph opens with:

   Experimental:  "This document defines an Experimental Protocol for
  the Internet community."

   Historic:  "This document defines a Historic Document for the
  Internet community."

JRE: the way paragraph 2 is generated, we end up with instances where
the 1st and 2nd sentence both start with "This document". This is ugly.
Is it too late to fix this?

  In addition a sentence indicating the consensus base within the
  IRTF may be added: "This RFC represents the consensus of the
   Research Group of the Internet Research Task Force
  (IRTF)." or alternatively "This RFC represents the individual
  opinion(s) of one or more members of the  Research
  Group of the Internet Research Task Force (IRTF)".

JRE: trailing dot missing in 2nd variant.


3.2.3.  Paragraph 3

   "Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org//rfc.html"

JRE: please do not bake a file extension into the permanent URL (see also
)

-- snip --

Best regards, Julian


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: I-D Action:draft-housley-iesg-rfc3932bis-12.txt

[Julian Reschke]

Julian Reschke wrote:

...
JRE: the way paragraph 2 is generated, we end up with instances where
the 1st and 2nd sentence both start with "This document". This is ugly.
Is it too late to fix this?
...


To illustrate the problem: for "IETF Experimental, with Consensus Call", 
we get:


"This document defines an Experimental Protocol for the Internet 
community. This document is a product of the Internet Engineering Task 
Force (IETF). It represents the consensus of the IETF community..."


I think

"This document defines an Experimental Protocol for the Internet 
community. It is a product of the Internet Engineering Task Force (IETF) 
and represents the consensus of the IETF community..."


would read much better.

Best regards, Julian


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf