ietf
[Top] [All Lists]

Re: PS Characterization Clarified

2013-09-16 10:32:57


--On Monday, September 16, 2013 15:58 +0200 Olaf Kolkman
<olaf(_at_)NLnetLabs(_dot_)nl> wrote:

[Barry added explicitly to the CC as this speaks to 'his'
issue]

On 13 sep. 2013, at 20:57, John C Klensin <klensin(_at_)jck(_dot_)com>
wrote:

[… skip …]

*   Added the Further Consideration section based on
discussion on the    mailinglist.

Unfortunately, IMO, it is misleading to the extent that you
are capture existing practice rather than taking us off in new
directions.  

Yeah it is a thin line. But the language was introduced to
keep a  current practice possible (as argued by Barry I
believe).

Understood.  Barry and I are on the same page wrt not wanting to
accidentally restrict established existing practices.

You wrote:

While commonly less mature specifications will be published
as Informational or Experimental RFCs, the IETF may, in
...

I see where you are going. 

<draft Proposed rewrite>

While commonly less mature specifications will be published as
Informational or Experimental RFCs, the IETF may, in
exceptional cases, publish a specification that still contains
areas for improvement or  certain uncertainties about whether
the best engineering choices are made.  In those cases that
fact will be clearly communicated in the document prefereably
on the front page of the RFC e.g. in the introduction or a
separate statement.

</draft>

I hope that removing the example of the IESG statement makes
clear that this is normally part of the development process.

Yes.

Editorial nits:

* "While commonly less mature specifications will be
published..." has "commonly" qualifying "less mature".  It is
amusing to think about what that might mean, but it isn't what
you intended.  Try "While less mature specifications will
usually be published...".  Replace "usually" with "commonly" or
"normally" if you like, but I think "usually" is closest to what
you are getting at.

* "prefereably" -> "preferably"

Additional observations based on mostly-unrelated recent
discussions:  

If you are really trying to clean 2026 up and turn the present
document into something that can be circulated to other groups
without 2026 itself, then the "change control" requirement/
...
Along the same lines but more broadly, both the sections of
2026 you are replacing and your new text, if read in
isolation, strongly imply that these are several decisions,
including those to approve standardization, that the IESG
makes on its own judgment and discretion.  I think it is
...
More important --and related to some of my comments that you
deferred to a different discussion-- the "IESG as final
_technical_ review and interpreter of consensus" model is very
different from that in some other SDOs in which the final
approval step is strictly a procedural and/or legal review
that is a consensus review only in the sense of verifying
...
So noted. 

As actionable for this draft I take that I explicitly mention
that Section 4.1 2026 is exclusively updated.

While I understand your desire to keep this short, the pragmatic
reality is that your non-IETF audience is likely to read this
document (especially after you hand it to them) and conclude
that it is the whole story.  Since the natural question that
immediately follows "why should we accept your standards at all"
is "why can't you hand them off to, e.g., ISO, the way that many
national bodies and organizations like IEEE do with many of
their documents".  

Suggestion in the interest of brevity: in addition to mentioning
the above, mention explicitly that there are requirements in
other sections of 2026 that affect what is standardized and how. 

By the way, while I understand all of the reasons why we don't
want to actually replace 2026 (and agree with most of them),
things are getting to the point that it takes far too much
energy to actually figure out what the rules are.  Perhaps it is
time for someone to create an unofficial redlined version of
2026 that incorporates all of the changes and put it up on the
web somewhere.   I think we would want a clear introduction and
disclaimer that it might be be exactly correct and that only the
RFCs are normative, but the accumulation of changes may
otherwise be taking us too far into the obscure.  If we need a
place to put it, it might be a good appendix to the Tao.  And
constructing it might be a good job for a relative newcomer who
is trying to understand the ins and outs of our formal
procedures.

best,
   john