ietf
[Top] [All Lists]

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

2009-11-30 11:29:00
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 XXXX.


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 XXXX.

... had been rejected.
There have been strong voices from the IESG insisting on that it is
more important to state what a document is *not* than to state what
it *is* -- unless it it Std Track or BCP.


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah(_at_)TR-Sys(_dot_)de                    
 |
+------------------------+--------------------------------------------+

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf