At 03:19 09-10-2009, Stephen Kent wrote:
>As ads for financial products remind us "Past performance is not a
>guarantee of future performance." Since we have been making changes
>in IETF functions over time, including the RFC Editor function, I
>don't think it is unreasonable to formalize this aspect of the
>relationship between the IESG and the RFC Editor, before a problem arises.
By over-formalizing the procedures, the IETF will end up with a rigid process.
Or else it will end up with a bunch of rules that in practice nobody follows,
which is a recipe for a different sort of trouble.
But regardless of outcome, I agree with the sentiment that over-formalization
is bad.
>I believe that most folks recognize that the public, in general,
>does not distinguish between RFCs that are the product of IETF WGs,
>individual submissions, independent submissions, etc. I think the
>IESG has a legitimate role in ensuring that RFCs that are not the
>product of WGs are appropriate labelled, and inclusion of an IESG
>note is a reasonable way to do that.
As yes, the old "people can't read" argument. The problem I have with this
argument is people who can't manage to comprehend the line at the top of a
specification that says "this does not specify a standard of any kind" are
highly unlikely to be able to assess the technical content of the document with
any degree of accuracy either.
And I somehow don't think anyone would be particularly pleased by dumbing our
specifications down to the first grade level, assuming that's even possible.
And while anecdotes are not data, I have to say I haven't seen any recent cases
of RFPs or whatnot referring to independent submissions. (Experimental
specifications, yes, but in these cases it was pretty clear the authors were
well aware of the status of the document and simply didn't care.) So perhaps
this problem isn't as severe as is sometimes claimed.
Section 1.1 of the draft mentions that:
"The IESG may provide an IESG note to an Independent Submission or
IRTF Stream document to explain the specific relationship, if any, to
IETF work."
That's a "may". From what you said, I deduce that you would prefer
that line to say:
The IESG will provide an IESG note to an Independent Submission ...
The reasons for the IESG Note are mentioned in Section 3. None of
them are about a label saying that the RFC is not a product of a WG.
Perhaps because such labels are already included, and when someone isn't
reading what the document says it really doesn't matter how many times you
repeat something.
>When the RFC series was first established, the need for archival,
>searchable, open publication of Internet-related documents was a
>good argument for the autonomy of the RFC Editor function. Moreover,
>the RFC Editor function pre-dates the existence of the IETF and the
>IESG, by many years. But, times change. The availability of search
>engines like Google make it possible for essentially anyone to
>publish material that is widely accessible, relatively easy to find,
>and more or less archival. Also, the vast majority of the RFCs
>published for many years are documents approved by the IESG. Thus it
>seems reasonable to revisit the degree of autonomy the RFC Editor
>enjoys relative to the IESG. The current proposal does not change
>the relationship very much in practice, but I understand that it is
>an important issue in principle, and the IETF membership has debated
>it in this context, extensively.
An open source advocate once suggested to me that I could use
Geocities to publish material. That site is closing this
month. There are differences between publishing something on your
web site and publishing a RFC. The latter does not require search
engine optimization for wide dissemination. A RFC has intrinsic
qualities because of the way it is produced. There are some RFCs
with IESG notes, such as RFC 4144, which I read as good advice.
RFC 4144 is an example of something which IMO doesn't happen often enough these
days - documents that comment on other specifications or processes, possibly
from points of view that do not reflect the consensus of the IETF but
nevertheless are worth preserving. It is important that it be clear these are
not consensus documents, but that'ss not the same as saying they should not be
part of the RFC series.
The current proposal undermines the independence of the RFC Editor
(ISE in practice). It changes the relationship from one where the
various parties should work together and come to an agreement to a
tussle between the RFC Editor and the IESG. I don't think that an
appeal is a good idea. I didn't object to it as the IESG folks may
feel better if they had that mechanism. However, I do object to
making the outcome mandatory.
I have to agree.
At 00:18 09-10-2009, Dave CROCKER wrote:
>The IESG is demanding a change. The IESG has failed to achieve
>community rough
>consensus for that change, but the IESG is still claiming a mandate
>for change.
There doesn't seem to be a concern about achieving rough community
consensus in this case as the IESG really wants the change.
And regrettably, I have to agree with this as well.
Ned
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf