Re: Review of: Characterization of Proposed Standards

[Barry Leiba <[e-mail]>]

So far, I've just held the DISCUSS ballot that's been the formal
process to keep this discussion open.  It's time to start paddling the
oar that I've stuck in.

It seems that there are still three points that Dave has:

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 have a couple of notes in response.  I agree that this
is a formal process change -- some say it's not, but is only
documenting what we already do, and I think that's ignoring the fact
that, notwithstanding that, this document *does* change the formal
definition of what Proposed Standard means.  It doesn't matter that
it's "merely reflecting reality"; it's still a formal change.  That
said, 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 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.

So, while I understand Dave's concern, I don't share it.  But Dave goes on:

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

On point 2, Olaf says this:
>>  There was a suggestion to remove the characterization of Internet
>> Standard (for completeness) I think that is a matter of taste and not
>> of content.

I think that's not really addressing the core of Dave's concern, which
isn't that the repetition is unnecessary (which would be a matter of
taste), but that it's actually harmful, in that future changes could
leave us with two divergent definitions of "Internet Standard".

On this, I'll note that we're already somewhat along that path, as
6410 quoted text from 2026 in its definition of "Internet Standard".
And I'll also note to things along that line:

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

b. 6410 had the opportunity to do the same thing, copying the
definition of Proposed Standard (which it did not change) from 2026,
and it didn't do it.  Instead, it said this:

   The stated requirements for Proposed Standard are not changed; they
   remain exactly as specified in RFC 2026 [1].  No new requirements are
   introduced; no existing published requirements are relaxed.

I suggest that that's a better approach, and would suggest that
Section 3.2 would be better done this way:

   The stated requirements for Internet Standard are not changed; they
   remain exactly as specified in Section 2.2 of [RFC6410], as it updates
   Section 4.1.3 of [RFC2026].

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.  This is from Section 4.1.1 of RFC 2026:

   A Proposed Standard should have no known technical omissions with
   respect to the requirements placed upon it.  However, the IESG may
   waive this requirement in order to allow a specification to advance
   to the Proposed Standard state when it is considered to be useful and
   necessary (and timely) even with known technical omissions.

Without Section 4, I believe we are removing the option that the
second sentence gives the IESG, and I want to be absolutely sure we
want to do that, before we do.  It's my opinion that we don't want to
remove it, and that's the purpose of Section 4.

> My concern about section 4 is that it only serves to invite criticism of
> IETF documents.  The statements in Section 4 really apply to all technical
> specifications and all organizations that publish them.  We never achieve
> perfection and we always reserve the right to produce a better version.

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?

Barry