On 13 sep. 2013, at 21:02, Adrian Farrel <adrian(_at_)olddog(_dot_)co(_dot_)uk>
wrote:
Hey Olaf,
Thanks for stubbornly pushing on with this.
Comments (sorry I haven't read the thread to see if others have already made
these comments)…
This is to acknowledge I took the suggestions that I am not quoting.
---
Section 2
clarity of the standards document
Prefer "Standards Track document"
This is a change to the original 2026 language, but I support it it makes
really clear what we are taking about.
---
Section 2
over the last decade or more have had extensive review.
...by the IESG?
...by or on behalf of the IESG?
That is already explained in the paragraphs above. I propose to just keep the
focus on the document having had review and not make an addition to that
sentence.
On the other hand, elsewhere in the thread John Klensin made the case that we
should stress that the IESG does this quality assurance since that is different
from other SDOs, this might be a good place to add that extra emphasis.
As said, I keep the text as is for now but I will take editorial guidance if
this is a serious issue.
---
Section 2
Because of this change in review assumptions, IETF Proposed Standards
should be considered to be at least as mature as final standards from
other standards development organizations. In fact, the IETF review
is more extensive than is done in other SDOs due to the cross-area
technical review performed by the IESG.
I wonder whether you should add
...a position that is further strengthened by the implementation and running
code that is often present before publication as a Proposed Standard.
Added, but with the word "Interoperable" added. Could you review if this is
still proper English and contact me off-list if it isn't:
In fact, the
IETF review is more extensive than is done in other SDOs due to
the cross-area technical review performed by the IESG, a
position that is further strengthened by the regular precense of
interoperable implementation and running code before publication
as a Proposed Standard.
---
Section 3.1
Usually, neither implementation nor operational experience is
required for the designation of a specification as a Proposed
Standard. However, such experience is highly desirable, and will
usually represent a strong argument in favor of a Proposed Standard
designation.
You could add
... and may be tracked and reported as described in [RFC6982]
Hmmm.. I want to be careful with that reference. It is an experimental document
and increases the referential complexity for little benefit.
Until serious pushback otherwise I propose to not take over this suggestion.
---
Section 3.1
Two paragraphs seem to enjoy some duplication in their final sentences.
A Proposed Standard specification is stable, has resolved known
design choices, is well-understood, has received significant
community review, and appears to enjoy enough community interest to
be considered valuable. However, as with all technical standards,
further experience might result in a change or even retraction of the
specification in the future.
and
A Proposed Standard will have no known technical omissions with
respect to the requirements placed upon it. Proposed Standards are
of such quality that implementations can be deployed in the Internet.
However, as with all technical specifications, Proposed Standards may
be revised if problems are found or better solutions are identified,
when experiences with deploying implementations of such technologies
at scale is gathered.
Fixed by removing that final sentence at first occurrence.
I'll wait a few days to see discussion converge before posting 02 in the mean
time:
pre 02 is at:
http://www.secret-wg.org/Secret-Media/draft-kolkman-proposed-standards-clarified-pre02-2013091600.txt
with a diff at:
http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-kolkman-proposed-standards-clarified-01.txt&url2=http://www.secret-wg.org/Secret-Media/draft-kolkman-proposed-standards-clarified-pre02-2013091600.txt
Thanks,
--Olaf
signature.asc
Description: Message signed with OpenPGP using GPGMail