ietf
[Top] [All Lists]

Re: Review of: Characterization of Proposed Standards

2013-11-02 08:30:31
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