Re: Review of: Characterization of Proposed Standards

[Dave Crocker <[e-mail]>]

On 10/31/2013 1:53 PM, Barry Leiba wrote:
> 1. A general point: the document doesn't seem to have had the review
> and scrutiny that one would expect for a significant process change.
>
> 2. Simple duplication of text from 2026 (in Section 3.2) is not a
> good idea, as it invites future divergence.
>
> 3. Section 4 should be removed, as it weakens the statements made
> elsewhere in the document and invites criticism, and is in effect
> self evident anyway.
>
> To point 1... I believe that the light volume of comments is because (1) it
> *is* reflecting reality, and that's mostly not controversial and (2)
> a lot of this was discussed when RFC 6410 was being developed, and

That's a perfectly reasonable theory.  It might even correct.

But it's merely a guess and there are other possibilities, some of which 
could be problematic.

We should not have to guess.

Again, we are changing possibly THE core document for the IETF and we 
should not be making guesses about either what the IETF thinks of it nor 
what the community causing the change thinks about it.

We need to obtain explicit comment and establish an concrete record.


> these changes are really artifacts of that discussion (which did not
> lack in participation).  Further, the document has been out here for
> discussion; the opportunity has been here, and IETF folks aren't
> normally shy if they have things to say.

Actually, shy isn't the problem.  Complacent and inattentive is the 
problem.  We do that really well, also.

Again, this document is too important for the community to treat 
casually by staying silent about a change to core normative text.



>> 2.  I also wonder whether we shouldn't circulate the draft more
>> broadly, outside of the IETF, to request the comments.  Will it
accomplish
>> what we want it to accomplish?
>
> We could post it to the new-work mailing list, or explicitly send it
> out through our liaisons.  It's likely, I think, that it would get
> little attention that way, though we won't know unless we do it.  On
> the other hand, we don't normally send our process documents out
> that way -- we didn't do that with the draft that became 6410, for
> example. I have no objection to soliciting external reviews and
> comments, but I'm doubtful that it'll be useful.

Using existing means of public circulation is fine, but it's rather 
passive.  Here, too, my point is that we need to press for explicit 
feedback.

Again:  This round of modification is triggered by reports from Olaf of 
folk who are discounting the Proposed Standard label.  It makes little 
sense to change a foundational document for these folk without getting 
them to review it and agree that it assuages their concerns.

If the text does not satisfy these folk, are then going to modify the 
document again, and again do it by guessing what will work for them?



> a. 6410 tweaked the definition of Internet Standard, in order to
> merge in aspects of Draft Standard.  That this document quotes 2026
> without also bringing in the changes from 6410 somewhat misstates
> things (in a small way, but nonetheless...).
...
> I suggest that that's a better approach, and would suggest that
> Section 3.2 would be better done this way:

Well, re-using text from another update of RFC 2026 is appealing.  On 
reflection, I think we got this issue wrong for RFC 6410, for the reason 
I've stated about the current work.  That said, the cloning approach you 
are suggesting makes sense.


> On point 3, I'll note that Section 4 is in this document exactly in
> response to my comments.  I was concerned that as this document
> tightens the formal criteria for PS, it's likely to cause even more
> strictness in IESG approval.  We've always had the option (and have
> not infrequently exercised it) to approve a document at PS that
> *does* have known limitations.
...
> I believe that Section 4 is saying more than the things that apply
> to all technical specifications: it's not just saying that they're
> not perfect and that we might find problems later.  It's meant to say
> that we might, sometimes, approve specifications at Proposed Standard
> that we *know* to have imperfections and limitations, and we're
> approving them anyway.  And what it's adding to what 2026 says about
> that is that when we do that, we'll explicitly say so in the
> document.
>
> Perhaps you have a suggestion for different wording, Dave, that will
> address your concern while still addressing mine?

Interesting.  I didn't read the text and get the meaning Barry is 
offering.  Barry's interpretation highlights an issue that makes sense 
to me and his language about the issue is simple and direct.  That makes 
it harder for the reader (including me) to miss the point.

So first let's drop discussion about what we do /not/ publish as 
Proposed.  It's distracting.

Second, let's have affirmative language about special cases that we /do/ 
publish as Proposed.  Again, Barry's language looks pretty reasonable 
for this, I think.

Perhaps:

    4.  Further Considerations

    Occasionally the IETF may choose to publish as Proposed Standard a
    document that contains areas of known limitations or challenges.  In
    such cases any known issues with the document will be clearly and
    prominently communicated in the document, for example in the
    abstract, the introduction, or a separate section or statement.





On 11/1/2013 1:33 AM, Olaf Kolkman wrote:
> This IMHO is an argument to consolidate. If I don’t get it right
> (with some high layer IETF experience) then how would an external
> consumer. Let’s put a consolidated  2026/6410 IETF Standards
> characterization in this document and create clarity.
>
> (I would be helped with being pointed out those small things)
>
> I want one document to point at when people ask me ‘what is the
> difference between proposed and Internet standards’.


I'm not sure what 'consolidated' means, but it sounds as if Olaf has
just argued for issuing an updated RFC 2026, folding in the previous and 
current changes.

That's probably the cleanest solution, of course.  The obvious downside 
is the risk of reviews that call for other changes in the document.  But 
given the low level of community interest in this foundational document, 
that's probably not a major risk...

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net