Subject: IESG review of RFC Editor documents

From: Keith Moore <[email-masked]>
Date: Fri, 26 Mar 2004 16:21:11 -0500

Okay, I read draft-iesg-rfced-documents-00.txt regarding a proposed 
change in IESG policy regarding RFC-Ed documents.

I'm opposed to the change, because I believe it would make it too easy 
for harmful documents to be published as RFCs.

Part of the problem is the familiar one that RFCs are often used as 
standards even when they carry the Informational or Experimental label. 
  Publishing an Informational RFC is therefore a way to get the 
appearance of standardization and IETF imprimatur without actually 
having to produce a sound technical design, achieve rough consensus, 
and endure review from IESG and interested parties.

A big part of the problem is that the proposed policy would only allow 
IESG to object to the publication of a document in the case where there 
was an active working group in an area, or where the document would 
violate a pre-established procedure.   Since working groups are 
typically chartered to work on a narrow topic and for a limited time, 
at any given time many technical subject areas are not covered by a 
working group, and many new protocols would not conflict with any 
particular working group even if they would conflict with (for 
instance) the operation of established protocols.

Many believe it's unreasonable for IESG to spend its time reviewing 
documents for which there is no broad support.  However, if it is 
unreasonable to expect IESG volunteers to perform adequate technical 
review on documents for which there is no broad support, surely it is 
even less reasonable to expect the RFC Editor (which appears to have 
even more limited resources and less breadth than the IESG) to perform 
such review.   And while the RFC Editor could (and I assume does) 
enlist volunteers to assist it in such review, this amounts to an 
approval process for IETF publications that isn't accountable to the 
IETF community, not even with a noncom-like mechanism.

I do think we need to find a better way to deal with individual 
submissions.  I don't think that for IESG to simply say "this is the 
RFC Editor's problem" is sufficient.

Here's an alternate proposal:

- In order to be considered worthy of review, any individual submission 
must first have the support of two (maybe three) members of the group 
consisting of all current IESG members, all current IAB members, and 
all current WG chairs.

- Such proposals are then subject to a 4-week Last Call for 
Informational or Experimental.

- A significant show of support in the form of Last Call comments would 
normally be required for publication.

- Review of such proposals and their Last Calls would be conducted by a 
panel of volunteers appointed by IESG.  For instance, each AD could 
appoint one person.  The review panel could vote on whether to 
recommend publication, request revisions in light of Last Call or 
reviewers' comments, or to recommend against publication in light of 
Last Call comments (or lack of support).

- If the review board recommends publications, the RFC Editor would 
perform the same functions on these documents that it performs for WG 
Informational and/or Experimental documents.

- Decisions of the review board would be subject to appeal to IESG.

---

From: Pete Resnick <[email-masked]>
Date: Fri, 26 Mar 2004 16:22:21 -0600

I disagree with Keith and think the document should be moved forward 
(with John's caveats about the notes for different types of 
documents). However, to address one of Keith's specific points:

On 3/26/04 at 4:21 PM -0500, Keith Moore wrote:

>A big part of the problem is that the proposed policy would only 
>allow IESG to object to the publication of a document in the case 
>where there was an active working group in an area, or where the 
>document would violate a pre-established procedure.   Since working 
>groups are typically chartered to work on a narrow topic and for a 
>limited time, at any given time many technical subject areas are not 
>covered by a working group, and many new protocols would not 
>conflict with any particular working group even if they would 
>conflict with (for instance) the operation of established protocols.

No, there is one other item mentioned which covers this case:

    o  The IESG thinks that this document extends an IETF protocol in a
       way that requires IETF review, and should therefore not be
       published without IETF review.

If the IESG thinks that a protocol "would conflict with the operation 
of established protocols", they can recommend rejection on that basis.

>And while the RFC Editor could (and I assume does) enlist volunteers 
>to assist it in such review, this amounts to an approval process for 
>IETF publications that isn't accountable to the IETF community, not 
>even with a noncom-like mechanism.

Of course, even in the current de facto system of IESG review, the 
RFC Editor has the ability (under the current written "rules") to 
ignore the IESG even if it recommends against publication and publish 
anyway. As far as I know, we've never come to that particular 
"constitutional crisis".

Suffice it to say, I think Keith's suggested alternative proposal is 
just wrongheaded.
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 26 Mar 2004 15:00:10 -0800

I have read draft-iesg-rfced-documents-00.txt and generally support
this change in the current practices.   In review of background BCPs,
in particular RFC 2026, I find this change can, and in my opinion,
should be returning to the procedures outlined in RFC 2026.  However,
I do have some concerns (see below) and some editorial suggestions
(which I will send separately to the I-D's authors).

General support:

It is my opinion that RFC 2026 did not intend for the IESG, nor the
RFC Editor for that matter, to undertake a "full scale" technical
review of the individual submission.

RFC 2026 described the IESG review propose "[t]o ensure that the
non-standards track Experimental and Informational designations are
not misused to circumvent the Internet Standards Process."

RFC 2026 described the RFC Editor's review purpose as ensuring
"editorial suitability" and subject to "editorial considerations".

While I support the RFC Editor continued right to "refuse to publish
a document which, in the expert opinion of the RFC Editor, is unrelated
to Internet activity or falls below the technical and/or editorial
standard for RFCs", we should continue the long standing tradition
of allowing publication of alternative ideas, alternative protocols,
and April Fool's RFCs.

Concerns:

I am concerned is the document by this Section 3 paragraph:
   Note that judging the technical merits of submissions,
   including considerations of possible harm to the Internet,
   will become solely the responsbility of the RFC Editor. The
   IESG assumes that the RFC Editor will create its own
   mechanisms for additional technical review.

I argue that the RFC Editor should not refuse publication of a work
because, in the opinion of the RFC Editor, that work would be harmful
to the Internet.  While I can see that cases where a document fails to
met the technical standards of RFCs, a document that causes harm to
the Internet does not necessarily below those technical standards.

Determining whether a document would cause harm requires more detailed
review than simply determining whether the document fails to met the
technical standards of RFCs.  Certainly the technical standard of RFCs
(including those produced by the IETF) is, at times, quite low.  Hence,
I recommend the phrase "including considerations of possible harm
to the Internet" be dropped or, better yet, this paragraph be replaced 
with language more consistent with that used in RFC 2026.

Also, as the kind of harm discussed in section 5 is about confusion
with standardization efforts, not about harm caused by technical
flaws in the technical specification itself (as discussed in Section 3),
the meaning of 'harmful' is confused in this document.  Deleting the
phrase as suggested above would remove that confusion and focus the
issue on proper standards coordination and not in-depth technical
review of the document.

Kurt

---

From: Eliot Lear <[email-masked]>
Date: Fri, 26 Mar 2004 15:19:10 -0800

Keith,

> for harmful documents to be published as RFCs.

As I'm sure you well know, the RFC Editor takes very seriously their 
obligations to provide thorough review of non-IETF documents.  In fact, 
what makes you think that the IESG is more conservative than the RFC Editor?

Eliot

---

From: Keith Moore <[email-masked]>
Date: Fri, 26 Mar 2004 18:48:14 -0500

> Of course, even in the current de facto system of IESG review, the RFC 
> Editor has the ability (under the current written "rules") to ignore 
> the IESG even if it recommends against publication and publish anyway. 
> As far as I know, we've never come to that particular "constitutional 
> crisis".

IIRC it happened at least twice while I was on IESG.

---

From: Keith Moore <[email-masked]>
Date: Fri, 26 Mar 2004 18:51:58 -0500

>> I'm opposed to the change, because I believe it would make it too 
>> easy for harmful documents to be published as RFCs.
>
> obligations to provide thorough review of non-IETF documents.

not in my experience.

Keith

---

From: John C Klensin <[email-masked]>
Date: Fri, 26 Mar 2004 18:54:03 -0500

Keith,

Pete has covered most of what I would have said, but I want to 
address one other issue with your comments/ suggestions.

It seems to me that at least latent in your suggestions is the 
assumption that the RFC Editor should publish only IETF 
consensus documents or documents that are in general agreement 
with IETF consensus.  My sense is almost exactly the opposite. 
The IESG is not omniscient and wouldn't be omniscient even if 
they had a lot more time.  The IETF isn't omniscient either. 
And nothing in our process, including the appeals process, is 
designed to deal effectively with something that has consensus, 
including IESG consensus, but is still wrong-headed.

IMO, one of the most valuable types of documents the RFC Editor 
could publish would be an independent, in-depth analysis of why 
some standards-track document was an operational hazard and 
generally a complete crock of excrement.  Now I would expect 
that a very high editorial and technical standard would be 
applied to the arguments of such a document.  I would expect it 
to be excruciatingly clear that the positions it was taking were 
in disagreement with an IETF Standards-Track procedure.  But I 
would hope it would be publishable, and, given those document 
quality standards, published, even if every single member of the 
IESG disagreed with its stated position.

Clearly-stated dissent is not "harmful".   Indeed, I suggest 
that it is healthy.  And the procedure you propose would tend to 
suppress such dissent, no matter how well reasoned that dissent 
was.

More broadly, our standards process has an almost-unique 
property relative to most other standards groups in the 
information technology area (and relative to all of those I 
would consider even moderately successful).  In their processes, 
there comes a point in the approval process in which people who 
disagree with the proposed document are explicitly identified 
along with their disagreements and, in some form, exactly what 
it would take to get them to agree.  Then there is a very 
serious process to try to resolve the disagreements and, if that 
fails, often nearly-automatic appeals on the substance of the 
proposal, documentation of the disagreements, and so on.  That 
model has some advantages and many disadvantages but the 
important thing is that we don't use it.

Instead, we use the notion of "rough consensus" to essentially 
run over dissent by small minorities, even small minority 
dissent that is well-reasoned and has significant merit.  And 
our appeals is useless in dealing with that issue because the 
"rough consensus" really does exist.  And that makes the ability 
for the dissenters to write a dissent, and have it published in 
near proximity to the official/standard specification, really 
important to preserving the openness and honesty of the system. 
Without it, all sorts of theories about cabals become very 
plausible.

Now we haven't used that mechanism very much.   In my personal 
opinion, we haven't used it nearly often enough -- especially in 
the last several years, the losing dissenters have tended to 
just go away rather than documenting their positions --but that 
is another issue.  But taking it away, which I think your 
suggestion would ultimately do, could ultimately be extremely 
harmful to our standardization model.

    john

--On Friday, 26 March, 2004 16:21 -0500 Keith Moore 
<[email-masked]> wrote:

> Okay, I read draft-iesg-rfced-documents-00.txt regarding a
> proposed change in IESG policy regarding RFC-Ed documents.
>
> I'm opposed to the change, because I believe it would make it
> too easy for harmful documents to be published as RFCs.
>...

---

From: Keith Moore <[email-masked]>
Date: Fri, 26 Mar 2004 19:41:03 -0500

> assumption that the RFC Editor should publish only IETF consensus 
> documents or documents that are in general agreement with IETF 
> consensus.

Actually, my assumption is that only documents for which there is a 
significant supporting constituency should be considered for 
publication as RFCs.  So for instance, if a different well-recognized 
standards body wants to publish something as an RFC, I don't have a 
problem with that, as long as it's clearly labeled as being from that 
standards body.  Or if a WG specification doesn't manage to meet the 
requirements for standards track but the WG wants to publish that 
specification as an Informational RFC, as a record of the work that was 
done in case the problems can be solved in the future, I don't have a 
problem with that either, as long as it's clearly marked and the 
identified problems are also mentioned in the document.

What I have a problem with is individuals demanding the right to have 
their half-baked specifications published as RFCs, and for the RFC 
Editor to publish those documents as RFCs without public review, or (as 
has happened in the past) even when substantial oversights or design 
flaws in those specifications have been pointed out to the RFC Editor.

>   My sense is almost exactly the opposite. The IESG is not omniscient 
> and wouldn't be omniscient even if they had a lot more time.  The IETF 
> isn't omniscient either.

Nor, for that matter, is the RFC Editor.  But IESG is IMHO much more 
likely to catch problems in an individual submission than the RFC 
Editor.  And unlike RFC Editor decisions, IESG decisions can be 
appealed.

> IMO, one of the most valuable types of documents the RFC Editor could 
> publish would be an independent, in-depth analysis of why some 
> standards-track document was an operational hazard and generally a 
> complete crock of excrement.  Now I would expect that a very high 
> editorial and technical standard would be applied to the arguments of 
> such a document.  I would expect it to be excruciatingly clear that 
> the positions it was taking were in disagreement with an IETF 
> Standards-Track procedure.  But I would hope it would be publishable, 
> and, given those document quality standards, published, even if every 
> single member of the IESG disagreed with its stated position.

I don't have an inherent problem with that either.  However I haven't 
seen any defined "very high editorial and technical standard" for such 
documents, which makes me wonder if this amounts to the whim of the RFC 
Editor.  I think we're long past the day when any two or three people, 
no matter how intelligent or experienced, can profess to understand 
Internet protocols in enough breadth to be the sole judge of what 
should merit publication on behalf of IETF.  And like it or not, if 
there is no other well-identified supporting consistency for an RFC, 
it's assumed by the public to have IETF backing.

> Clearly-stated dissent is not "harmful".   Indeed, I suggest that it 
> is healthy.  And the procedure you propose would tend to suppress such 
> dissent, no matter how well reasoned that dissent was.

Clearly-stated dissent is not harmful.  But inflating it to appear to 
have equal or near-equal standing with community consensus can be 
misleading.

I can think of a number of topics for which I'd like to get on a soap 
box and have my "clearly-stated dissent" published as RFCs:  scoped 
addressing, encoding routing policy in address bits, and 
autoconfiguration systems being a few of the "interesting" and timely 
topics that come to mind.  However I don't think I have the right to 
demand that the RFC Editor provide, and ISOC fund, a soap box that 
appears to give my personal opinion near-equal weight to the consensus 
of IETF.  And I don't think it scales very well.

OTOH, I would certainly like to see a process that allowed 
"well-supported minority opinions" to get some recognition.

> Instead, we use the notion of "rough consensus" to essentially run 
> over dissent by small minorities, even small minority dissent that is 
> well-reasoned and has significant merit.  And our appeals is useless 
> in dealing with that issue because the "rough consensus" really does 
> exist.  And that makes the ability for the dissenters to write a 
> dissent, and have it published in near proximity to the 
> official/standard specification, really important to preserving the 
> openness and honesty of the system. Without it, all sorts of theories 
> about cabals become very plausible.
>
> opinion, we haven't used it nearly often enough -- especially in the 
> last several years, the losing dissenters have tended to just go away 
> rather than documenting their positions --but that is another issue.  
> But taking it away, which I think your suggestion would ultimately do, 
> could ultimately be extremely harmful to our standardization model.

My opinion is that if we're going to pretend to have such a mechanism, 
we need to actually define it - establish publication criteria and the 
procedure for requesting publication and set up a vetting process that 
can hope to scale.  I don't think saying "whatever the RFC Editor 
wants" is a good way to do this.

Keith

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 26 Mar 2004 17:09:16 -0800

At 04:41 PM 3/26/2004, Keith Moore wrote:
>What I have a problem with is individuals demanding the right to have their half-baked specifications published as RFCs, and for the RFC Editor to publish those documents as RFCs without public review, or (as has happened in the past) even when substantial oversights or design flaws in those specifications have been pointed out to the RFC Editor. 

Personally, I'm more concerned by WGs demanding their right to
have their half-baked specifications published as RFCs, and the
for IESG to approve them without any IETF review or other
community review, or (as has happened in the past) even when
substantial oversights or design flaws in those specifications
were pointed out by individuals.

Kurt

---

From: Eliot Lear <[email-masked]>
Date: Fri, 26 Mar 2004 17:35:37 -0800

> were pointed out by individuals.

Please cite an example.  In what case was there not a last call?

Eliot

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 26 Mar 2004 18:14:11 -0800

At 05:35 PM 3/26/2004, Eliot Lear wrote:
>Please cite an example.

That, I think, would be counter productive.  I think it fairly
apparent that there is a fair amount of crap (by mine, your, or
anyone's opinion) published as RFCs.  I content that much of
that crap was produced by the IETF.

But my point, in regards to this proposal, is that the bar for Informational/Experimental is not "half-baked" nor "won't cause
harm" nor "crap", but whether it provides information is of
reasonable use to the Internet technical community and meets
the (low) editorial/technical standards for RFCs.

Keith is trying to raise the bar.  I prefer to keep the bar
low.  I, frankly, don't see a problem with there being more
crap published as RFCs, whether produced by WGs or produced by
individuals.

>In what case was there not a last call?

WG documents submitted for Informational and Experimental
publication are not necessarily subject to IETF Last Call.
Also note that IESG review of such document is "minimal"
(per RFC 2418).

Kurt

---

From: Keith Moore <[email-masked]>
Date: Fri, 26 Mar 2004 22:06:34 -0500

> But my point, in regards to this proposal, is that the bar for 
> Informational/Experimental is not "half-baked" nor "won't cause
> harm" nor "crap", but whether it provides information is of reasonable 
> use to the Internet technical community and meets

For information to be of "reasonable use" it needs to be reasonably 
accurate.

Opinions can also be useful, if nothing else to students of history, if 
the opinions are clearly labeled as such, and if they help illustrate a 
historically important debate.

These days, for a protocol specification to be of "reasonable use" on a 
wide scale it needs to avoid causing harm.  There have been too many 
exploits of security holes and privacy holes in poorly-designed 
protocols.  While it might be useful to publish an informational 
specification of a widely-deployed protocol on the theory that 
publishing it will make the public more aware of its limitations and 
help them migrate to better protocols, publishing a specification of a 
hazardous protocol that is not widely deployed can encourage wider 
deployment and increase the risk of harm.

> Keith is trying to raise the bar.  I prefer to keep the bar low.  I, 
> frankly, don't see a problem with there being more

Publishing crap dilutes the value of the RFC series, and makes it more 
difficult for the public to recognize the good work that IETF does.  It 
also costs money which could be better put to other uses.

Keith

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 26 Mar 2004 21:52:20 -0800

At 07:06 PM 3/26/2004, Keith Moore wrote:
>>harm" nor "crap", but whether it provides information is of reasonable use to the Internet technical community and meets
>For information to be of "reasonable use" it needs to be reasonably accurate.

I disagree.  A document which has significant technical errors and
omissions can still be reasonable useful to the technical community.
The document need only be meet general editorial and technical
standards, it need not nor should be subjected to anything more than
a minimal review (beyond that provided by its producers).

>Opinions can also be useful, if nothing else to students of history, if the opinions are clearly labeled as such, and if they help illustrate a historically important debate.

I have no objection to labels (e.g., Experimental) and standardized
disclaimers in such memos.

>These days, for a protocol specification to be of "reasonable use" on a wide scale it needs to avoid causing harm.

Experimental and Informational memos need not be engineered for
wide scale use.  They might just detail an small scale experiment
or detail an existing limited-use protocol.

The standardized disclaimer should caution readers that the document
may not be suitable for implementation/use on the Internet.  

>There have been too many exploits of security holes and privacy holes in poorly-designed protocols.  While it might be useful to publish an informational specification of a widely-deployed protocol on the theory that publishing it will make the public more aware of its limitations and help them migrate to better protocols, publishing a specification of a hazardous protocol that is not widely deployed can encourage wider deployment and increase the risk of harm.

I consider this part of the Informational/Experimental v Standard
Track trade-off.  In having a series with minimal review, we accept
risk that such documents will have not adequately address various
considerations.

>>Keith is trying to raise the bar.  I prefer to keep the bar low.  I, frankly, don't see a problem with there being more
>>crap published as RFCs, whether produced by WGs or produced by individuals.
>
>Publishing crap dilutes the value of the RFC series, and makes it more difficult for the public to recognize the good work that IETF does.

I agree that it hard to distinguish IETF-produced RFCs from
individually-produced RFCs (this seems to be somewhat by design)
and, I think, a separate issue from crap on the RFC series.

The only distinction I see is that the IETF can produce (by WG
or individual submission to it) crap on any track and Individuals
can only produce crap on Informational/Experimental.  While
detailed review focused on the latter might reduce the latter,
I don't see it nearly as problematic as the former.

A certain amount of crap RFCs is to be expected and reasonable
especially on Informational and Experimental tracks (regardless
of producer).  Minimal review has been, IMO, sufficient to keep
the amount of crap to acceptable amount.

>It also costs money which could be better put to other uses.

Personally, I believe the money spent doing minimal review is
money well spent.  However, I would be supportive of use of
volunteer minimal reviewers to cut review costs.

Kurt

---

From: "Marge" <[email-masked]>
Date: Sat, 27 Mar 2004 10:15:54 -0500

Sometimes, if a half-baked idea is put on a back burner for a while it
might become palatable or at least partly usable.

Marge
 
Effort does not necessarily lead to progress.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kurt
D. Zeilenga
Sent: Friday, March 26, 2004 8:09 PM
To: Keith Moore
Cc: John C Klensin; Keith Moore; IETF Discussion
Subject: Re: IESG review of RFC Editor documents

>flaws in those specifications have been pointed out to the RFC Editor.

Personally, I'm more concerned by WGs demanding their right to have
their half-baked specifications published as RFCs, and the for IESG to
approve them without any IETF review or other community review, or (as
has happened in the past) even when substantial oversights or design
flaws in those specifications were pointed out by individuals.

Kurt 

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.642 / Virus Database: 410 - Release Date: 3/24/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.642 / Virus Database: 410 - Release Date: 3/24/2004

---

From: Eliot Lear <[email-masked]>
Date: Sat, 27 Mar 2004 09:09:02 -0800

Keith,

> wide scale it needs to avoid causing harm.  

First, something can be of reasonable use while still causing harm. 
Fossil based fuels prove that.  And while I agree that there are certain 
areas where causing harm to others needs to be considered (such as 
UDP-based protocols that lack well known congestion avoidance 
algorithms), we as a community cannot be so risk averse that we drive 
development elsewhere.

Consider the case where someone *DID* invent a UDP-based file transfer 
protocol (FSP).  The work was done completely outside the IETF and 
satisfied a demand.  When that demand subsided use of that protocol 
diminished.  And yet does not have a specification for this Historic 
protocol.

Similarly, SOCKS went quite far before the IETF ever got a look at it. 
Why?  Because we are no longer viewed as a place where development can 
seriously take place.  Risk averse.  You know that thing about running 
code?  Taken too far we fail what I think part of our mission is, which 
is to be a place to collaborate, because everyone will have shown up 
with their respective running code, only to fight over whose running 
code (if anybody's) will become the standard.  See, for instance, the 
XMPP/IMPP wars.

> There have been too many 

This was never the series' intent.  We've attempted to warp it into 
this, and the result has been The Official Dogma, with a corresponding 
lack of development within the IETF.  If we want to allow for REAL 
innovation WITHIN the IETF, then you have to let some crap through, and 
you have to trust the RFC Editor and others to hold the bar at some level.

Eliot

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sat, 27 Mar 2004 09:36:03 -0800

Kurt,

> that crap was produced by the IETF.

permit me to disagree..... not with your core statement, but with the 
statement that citing examples would be counterproductive.

The statement that "a fair amount of crap is published as RFCs" has been 
repeated for so long that it's almost become a mantra.
However, in my opinion, for *every single one* of those RFCs, there's a 
reason why it was published. Usually there was a supporting constituency, 
and at least some opinion that publishing it was better for the Internet 
than not publishing it - certainly, for every standards-track RFC, there 
was at one time a majority view in the IESG that such was the case.

If we are to change the process that produces this stuff, we HAVE to 
understand what the reasons are that reasonable, competent people produce 
things that are sub-par, broken or "crap". And IMHO, we can't do that 
without saying what these unacceptable results of the process are.

Moving from the generic to the specific might actually be an useful 
catharsis for the community - and just might change the community opinion 
from "a lot of our 3000 RFCs are crap" to "there are 30 bad RFCs, 300 that 
could have been better and 3000 reasonably OK ones", or even to "the 
quality control system does not work well enough, there are too many 
borderline cases".

I don't think anonymous, class-based criticism will get us much further. We 
need to be specific about what our problems are.

                    Harald

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 27 Mar 2004 11:09:26 -0800

At 09:36 AM 3/27/2004, Harald Tveit Alvestrand wrote:
>permit me to disagree..... not with your core statement, but with the statement that citing examples would be counterproductive.

I was attempting to make a few points:
        1) the series is not intended to be "crap" free
        2) what is "crap" is quite subjective
        3) we need to continue to allow others to publish
          what we might consider to be "crap".

which may have been missed by some.

What I personally view as "crap" has no bearing in regards to these
points, excepting that where I feel strong enough to produce an I-D
detailing why I think something is "crap" I should be allowed
(if I can met general editorial and technical standards) to publish
that opinion as an RFC even though consensus of the IETF (or Keith's
review board or the RFC Editor) might be that my opinion is "crap".
(That opinion could be expressed in the form of an alternative protocol
specification.)

>The statement that "a fair amount of crap is published as RFCs" has been repeated for so long that it's almost become a mantra.

Yes.  But normally its uttered as an argument to increase publishing requirements.  I am arguing that we should not increase publishing requirements here.

>However, in my opinion, for *every single one* of those RFCs, there's a reason why it was published. If we are to change the process that produces this stuff, we HAVE to understand what the reasons are that reasonable, competent people produce things that are sub-par, broken or "crap".  And IMHO, we can't do that without saying what these unacceptable results of the process are.

Yes.  I argue that we should not change the process (as described
in RFC 2026) that produces this stuff as that process is producing
acceptable results (e.g., the current level of crap is acceptable).

>Moving from the generic to the specific might actually be an useful catharsis for the community - and just might change the community opinion from "a lot of our 3000 RFCs are crap" to "there are 30 bad RFCs, 300 that could have been better and 3000 reasonably OK ones", or even to "the quality control system does not work well enough, there are too many borderline cases".

It would be interesting to see how many of documents folks consider
to be crap would have been blocked under a different process.  If
I look at the documents that stand out to me as crap, I note that
Keith's new review process would have no impact... as most of the
documents I consider to be crap were produced by the IETF or
underwent some IETF review.  But I'm not of the opinion that the
documents I consider to be crap should have been blocked (though
I might argue that some of them shouldn't be on the Standard Track).

>I don't think anonymous, class-based criticism will get us much further. We need to be specific about what our problems are.

The problem I see with being specific here is that what's crap to me
is not necessarily the same as to you, and we'll just end up arguing
over wether something is crap or not, and that will overshadow the
key aspect of my argument that we should each be allowed to own
opinions as to what is crap and be able to act on those opinions,
including publication of what others might consider to be crap.

Kurt

---

From: "James Seng" <[email-masked]>
Date: Sun, 28 Mar 2004 07:49:29 +0800

Sound nice but isn't this go against the "rough consensus" principle?

You are free to doc your opinion (even if it is not rough consensus) in the
mailing list.

-James Seng

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 27 Mar 2004 15:58:51 -0800

>Sound nice but isn't this go against the "rough consensus" principle?

The "rough consensus" principle applies to IETF documents,
not to RFCs in general.

---

From: grenville armitage <[email-masked]>
Date: Sun, 28 Mar 2004 11:32:32 +1000

"Kurt D. Zeilenga" wrote:
	[..]
> including publication of what others might consider to be crap.

You do have avenues for publishing 'crap' outside the RFC series. Put your
content up on a website. Send it to a mailing list. Shout it from the
treetops.

Your argument against improved expectations of standards in the RFC
publication process seems unconvincing. I see Vanity Press written all
over it.

cheers,
gja
-- 
Grenville Armitage
http://caia.swin.edu.au
I come from a LAN downunder.

---

From: "James Seng" <[email-masked]>
Date: Sun, 28 Mar 2004 08:42:02 +0800

Ah, that never cross my mind:

I always assumed that RFCs, been a "product" of the IETF (since it is
published by IETF copyrighted by ISOC) should also adopt the IETF principle.

But you may be right..no where in 2026 and 1543 say anything about RFC needs
to have rough consensus..hmm...

-James Seng

----- Original Message ----- 
From: "Kurt D. Zeilenga" <[email-masked]>
To: "James Seng" <[email-masked]>
Cc: "Harald Tveit Alvestrand" <[email-masked]>; "IETF Discussion"
<[email-masked]>
Sent: Sunday, March 28, 2004 7:58 AM
Subject: Re: Naming crap (Re: IESG review of RFC Editor documents)

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Sat, 27 Mar 2004 15:53:20 -0800

>standards even when they carry the Informational or Experimental 

With respect to Informational RFCs, that was more true five years ago 
than it is now. The IETF has been largely successful at nailing 
vendors who try to pass off Informational RFCs as having any weight. 
It still happens, but is often followed by public rebuke from active 
IETF members. The last time someone asked me about whether or not 
they should try "elevating the importance" of an Informational RFC, 
my response was "sure, if you want to be exposed as a liar".

Experimental RFCs are unfortunately a different matter. We see 
Working Groups passing out fully-deployed, non-experimental protocols 
as "Experimental" due to political reasons such as lack of consensus, 
or as consolation prizes when a different protocol received louder 
hums.

Noel's observation about the lack of need for RFC publication due to 
the easy publication on the Web is exactly right. People can find out 
about information Foo or experiment Bar with a quick search. The 
Internet might be helped by publication in the RFC series, but it 
also might not be.

The material in draft-iesg-rfced-documents-00.txt can be greatly 
improved with a few changes:

- Require that all documents published without IESG technical review 
say so explicitly in a standardized boilerplate: "The technology in 
this document was reviewed the RFC Editor, but was not approved by 
the IESG or any IETF Working Group. See RFC xxxx for more information 
on the process used in the publication of this document" This will 
help readers of the RFC who haven't read 2026 et. al., and will also 
serve as a hindrance to over-marketing the document.

- Require that the RFC Editor not publish any document as an 
Experimental RFC unless it meets the definition on RFC 2026 or its 
successors. Publish a non-standards-track protocol as an 
Informational RFC with the above wording unless it really is "a 
specification that is part of some research or development effort". 
It is the responsibility of the RFC Editor to make this determination.

- Add text saying that publication as an RFC may not meet the needs 
of many publication requesters, and that having an RFC can actually 
inhibit innovation and flexibility due to the limitations of the 
series such as long publication times, difficulty of revision, and so 
on.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 27 Mar 2004 17:44:47 -0800

At 05:32 PM 3/27/2004, grenville armitage wrote:
>You do have avenues for publishing 'crap' outside the RFC series.
>Put your content up on a website. Send it to a mailing list. Shout it from the treetops.

Yes, other avenues are available publishing independent works.
However, it has been a long standard tradition of the RFC series
to provide an avenue for publication of independent works
(subject to minimal review).  There is merit to the Internet
technical community in this tradition as it combines opposing
opinions into a single series of documents.

I strongly believe that hindering the publication of individual
submissions, as Keith suggests, will have long term negative
impact upon the overall technical merit of the series.  That
is, you'll get want you seem to wish, individuals will go elsewhere.
And I don't mean just in terms of publication avenues, but
in terms of where and how Internet engineering is done.

>publication process seems unconvincing.

Arguments that we should reenforce the false expectations of
the quality and/or community acceptance of documents in the
RFC series are unconvincing to me.  We'll always have documents
of different quality (including crap) and community acceptance
(including none) in the series, we should focus more on how to
distinguish the levels of quality and community acceptance.
Attempting to restrict the series to those documents
believed to be of high quality and broad community acceptance
is simply infeasible (if not impossible).

>I see Vanity Press written all over it.

Minimal review undertaken by the RFC Editor appears to be
sufficient to address such concerns.

Kurt

---

From: Paul Vixie <[email-masked]>
Date: 28 Mar 2004 05:03:04 +0000

> repeated for so long that it's almost become a mantra.

i guess the fact that noone objects to this characterization is either due
to everyone agreeing with it or to what else exactly are you thinking of?

> reason why it was published. Usually there was a supporting constituency, 

how about "it was a measurable dayjob objective for at least one editor"
or "because the WG was completely exhausted and the only way they could
get the document out of their collective face was to fling it over the wall?"

when it comes to crap, few documents can compete with RFC's 2065 and 2535.
i don't think that the editors or WGchairs were in any way incompetent, but
even a cursory reading of either document at this stage will demonstrate that
noone had actually read or tried to understand them in their submitted form.
(our long-suffering AD eventually started reading our docs and asking the
kind of simple questions that are really cover for "did you read this
yourself and were you hoping that nobody else would?")  i'm one of the
guilty parties -- both as a draft-editor and a positive-hummer.

but it actually does seem counterproductive to me to name documents, WGs,
WGchairs, ADs, authors, and editors as having produced "crap".  i think if
we focus on the general crap-fact we can do much good to reduce overall-crap
and that no special focus is needed on specific crap-fact like which docs
are actually crap.

> was at one time a majority view in the IESG that such was the case.

well, no.  the iesg at the time of 2065 was clearly out smoking pot on the
back deck, there is no possible way that it could have been seen as "good
for the internet" or even "good, at all."  exhaustion, dayjobs, and miasma.

> without saying what these unacceptable results of the process are.

to your first statement i agree.  to your second i very much disagree.

> quality control system does not work well enough, there are too many 

unfortunately there's universal/objective crap, like 2065 or 2535, and on
the other hand there's subjective crap where just because i don't like it
doesn't make me expect that noone else found it useful (2181, 1995).  if
we try to move from the generic to the specific we'll probably just bog down
in nonuniversal standards for crap and i don't think that's going to help us.

> I don't think anonymous, class-based criticism will get us much
> further. We need to be specific about what our problems are.

well, if highlighting a difference of opinion is the first step toward
resolving it, then we're on our way.
-- 
Paul Vixie

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 28 Mar 2004 13:38:13 +0200

On 27-mrt-04, at 18:36, Harald Tveit Alvestrand wrote:

> understand what the reasons are that reasonable, competent people 
> produce things that are sub-par, broken or "crap". And IMHO, we can't 
> do that without saying what these unacceptable results of the process 
> are.

[...]

> further. We need to be specific about what our problems are.

To me it seems that the IETF can't make up its mind: are RFCs just 
drafts that don't expire, or are they hugely important documents that 
must be absolutely perfect before they are published?

The problem is version control. We're engineers. That means we are, 
more so than mere mortals, doomed never to get anything right the first 
time out. However, the RFC publishing model doesn't really allow for 
incremental changes: you have to write a completely new RFC, which then 
gets a new number that has no relation to the original RFC.

What we need is a way to add information to RFCs whithout the need to 
rewrite the original RFC or make the new information a full-blown RFC 
of its own.

---

From: "Dassa" <[email-masked]>
Date: Mon, 29 Mar 2004 07:37:15 +1000

|> -----Original Message-----
|> From: [email-masked] [mailto:[email-masked]] On
|> Behalf Of Iljitsch van Beijnum
|> Sent: Sunday, March 28, 2004 9:38 PM
|> To: Harald Tveit Alvestrand
|> Cc: IETF Discussion
|> Subject: Re: Naming crap (Re: IESG review of RFC Editor documents)
|>
|> On 27-mrt-04, at 18:36, Harald Tveit Alvestrand wrote:
|>
|> > If we are to change the process that produces this stuff,
|> we HAVE to
|> > understand what the reasons are that reasonable, competent people
|> > produce things that are sub-par, broken or "crap". And
|> IMHO, we can't
|> > do that without saying what these unacceptable results of
|> the process
|> > are.
|>
|> [...]
|>
|> > I don't think anonymous, class-based criticism will get us much
|> > further. We need to be specific about what our problems are.
|>
|> To me it seems that the IETF can't make up its mind: are
|> RFCs just drafts that don't expire, or are they hugely
|> important documents that must be absolutely perfect before
|> they are published?
|>
|> The problem is version control. We're engineers. That means
|> we are, more so than mere mortals, doomed never to get
|> anything right the first time out. However, the RFC
|> publishing model doesn't really allow for incremental
|> changes: you have to write a completely new RFC, which then
|> gets a new number that has no relation to the original RFC.
|>
|> What we need is a way to add information to RFCs whithout
|> the need to rewrite the original RFC or make the new
|> information a full-blown RFC of its own.

Personally and from observation it would appear RFCs are stand alone
documents that do not get revised.  They get superseded by new RFCs covering
the same topic.  Perhaps the way to approach this particular issue is to
provide better navigation aids through the various RFCs so that it is easier
for users to find all the related documents showing the relationship
(timeline and validity) between the documents.  A more involved and
comprehensive document management system.

Darryl (Dassa) Lynch

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sun, 28 Mar 2004 20:56:18 -0600

From: "Dassa" <[email-masked]>
To: "'Iljitsch van Beijnum'" <[email-masked]>; "'Harald Tveit
Alvestrand'" <[email-masked]>
Cc: "'IETF Discussion'" <[email-masked]>
Sent: Sunday, March 28, 2004 3:37 PM
Subject: RE: Naming crap (Re: IESG review of RFC Editor documents)
> comprehensive document management system.

Yes, exactly, and if anyone following this thread has not read
http://www.ietf.org/internet-drafts/draft-loughney-what-standards-01.txt
yet, that's unfortunate. John Loughney is faithfully working this
issue, without a lot of feedback, positive or negative, and he is SO
right.

My suggestion is to read this draft and provide feedback on Newtrk
(http://darkwing.uoregon.edu/~llynch/newtrk.html).

Thanks,

Spencer

---

From: Donald Eastlake 3rd <[email-masked]>
Date: Sun, 28 Mar 2004 23:16:37 -0500 (EST)

On Sun, 28 Mar 2004, Iljitsch van Beijnum wrote:

> Date: Sun, 28 Mar 2004 13:38:13 +0200
> From: Iljitsch van Beijnum <[email-masked]>
> Cc: IETF Discussion <[email-masked]>
>
> ...
>

Why does it have to be one of your two alternatives?

RFC's are like books. No book is perfect. Almost all books undergo
significant review, copy editing, etc,, before publication.

> gets a new number that has no relation to the original RFC.

While it is normally the case that an RFC is "revised" by the
publication of a new RFC which obsoletes the old, this is not
necessarily the only way to do it. If there are a significant volume of
changes but still only a small amount compated to the size of the
original RFC, it is possible to publish and updating RFC, at least for
Informational RFCs. See RFC 2801 and 3504. There is also an errata
mechanism maintained by the RFC Editor.

> rewrite the original RFC or make the new information a full-blown RFC

There is clearly no way to do what you want with printed books, which
are what RFCs are modelled after. To get the effect you want, people
would need to go to a web resource or the like. But if they are willing
to do that, then they can almost as eaily find out about errata and
whether the RFC they are looking for has been obsoleted.

I also notice that you ignore all the problems of fluid specifications
that constantly change on line so that no two people/implementers can be
sure they are working from the same spec unless they agreed on a time
stamp, etc.

Thanks,
Donald
======================================================================
 Donald E. Eastlake 3rd                       [email-masked]
 155 Beaver Street              +1-508-634-2066(h) +1-508-786-7554(w)
 Milford, MA 01757 USA                   [email-masked]

---

From: David Morris <[email-masked]>
Date: Sun, 28 Mar 2004 23:17:47 -0800 (PST)

> sure they are working from the same spec unless they agreed on a time

Without changing any of the publication process, RFC identification could
be changed to more clearly show the history and make it very clear what
the current RFC version was by using a -N suffix (where N is an
incremental version following the original). No external index would be
required to document that RFC xxx-2 supercedes RFC xxx-1. There is a small
loss of the obvious time series relationship one can now determine from
the simple number. A penalty I'd gladly pay to have obvious documentation
of relationships. In the case where an RFC (e.g. abc-3) was superceded by
another RFC (e.g., bcd), then RFC abc-4 could be published to be a small
placeholder reference to RFC bcd. Whether HTTP/1.1 superceded HTTP/1.0 or
was a new -number should be determined by the IESG on the recommendation
of the WG/AD.

Dave Morris

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 29 Mar 2004 11:36:00 +0200

> Why does it have to be one of your two alternatives?

Above I'm not describing what should be, or even what is, but what it 
seems like to me.

> significant review, copy editing, etc,, before publication.

The book analogy can work up to a point, but for certain types of 
documents it makes very little sense. A book can't be changed after it 
has been printed, so it reflects knowledge at a certain point in time 
by its nature (and also often times by design).

However, true engineering documents change from time to time, no matter 
how hard the push is to get it right the first time. There is no 
copyediting like trying to implement a protocol...

It would of course help if RFC authors would stick to the point of 
their RFC rather than discuss all the potential ways in which their 
protocol could be useful. Draft authors are even worse, 75% of most 
drafts is spent justifying the draft.

> mechanism maintained by the RFC Editor.

Then explain to me the existence of RFC 1918 with regards to RFC 1597.

> are what RFCs are modelled after.

And email is modeled after letter writing, so what's up with this 
quoting thing that we're doing here???

> To get the effect you want, people

The alternative is that they use a printout of an RFC. Anyone willing 
to create such a printout can just as easily print the whole family of 
documents that make up a standard.

> sure they are working from the same spec unless they agreed on a time

Oh yes, the current situation where people implement drafts, RFCs 
continue to have small but potentially lethal errors in them and new 
replacement RFCs are published in a way that is impossible to determine 
from looking at the RFC they're replacing is so much better.

I suggest we form a task force of people who all implemented at least 
three RFCs times as many RFCs as they authored and let them tell us 
what's right and what's wrong here.

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 Mar 2004 09:07:53 -0800

> for harmful documents to be published as RFCs.

As someone who has been waiting over a year to publish an informational 
RFC, I could not disagree more.

The RFC-Editor (disclaimer - also at ISI) has sufficient authority to 
reject submissions which are either 'clearly bogus' or do not cross the 
hurdle from marketing blurb to protocol spec.

...
> violate a pre-established procedure. 

To the extent that the IESG has done otherwise in the past, IMO it has 
violated its authority. I appreciate that the IESG has 'voted' to do 
otherwise, but I don't recall how it ever got the authority to act as 
TPC for individual submissions in the first place.

...
>  Since working groups are 
> typically chartered to work on a narrow topic and for a limited time, at 
> any given time many technical subject areas are not covered by a working 
> group, and many new protocols would not conflict with any particular 
> working group even if they would conflict with (for instance) the 
> operation of established protocols.

Alternatively - speaking from experience - new protocols or techinques 
could be developed and circulate ad-infinitum among the churn of 
emerging WGs, in a continuing effort to avoid perceived potential overlap.

 > -In order to be considered worthy of review, any individual submission
 > consisting of all current IESG members,all current IAB members,and all
 > current WG chairs.

Sometimes these docs are 'reviewed' by 'informed' ADs who request WG 
review - of a WG to whom the document _has already been repeatedly 
presented_. Asking for the consensus of any UNANIMOUS snapshot of IESG, 
IAB, and WG chairs would certainly cut down on the published RFCs. We 
might end up with none.

These proposals further don't consider the historical value of minority 
opinions or alternative approaches. Those docs won't ever be published 
if unanimous consent is required.

IMO, the IESG already has a series over which it has complete editorial 
control - standards track. Leave something for the rest of the Internet 
community, please.

Joe

---

From: jfcm <[email-masked]>
Date: Mon, 29 Mar 2004 20:29:10 +0200

Far too obvious!
jfc

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 30 Mar 2004 07:23:54 -0800

> for the internet" or even "good, at all."  exhaustion, dayjobs, and

:-)

I remember 2065 well, because that was the first time this freshly-minted 
AD ever cast a "DISCUSS" position in the IESG - pointing out one obvious 
error, and saying that "I don't understand the wildcard 
specification".......

Once one was fixed, and the other revised, I was told by the responsible AD 
at the time that securing the DNS was of primary importance (which I 
continue to believe is true) and that the WG understood the specification 
(which I now doubt) and its operational implications (about which history 
has produced the consensus - it wasn't so. But we needed to try it before 
we learned that lesson properly).

So I let it pass.... in retrospect, I don't think that kicking it back to 
the WG once more would have been better for the Internet. Shutting down the 
WG without a result and doing something different might have been better. 
But we didn't think so at the time.

One point to learn is probably that specifications need to make it out of 
the WG before the WG is exhausted. And that it's really, really hard to do 
disaster recovery when that doesn't happen.

Sigh.

---

From: Keith Moore <[email-masked]>
Date: Tue, 30 Mar 2004 12:23:32 -0500

> Fossil based fuels prove that. 

Interesting analogy.  Though I'll note that there are different approaches 
to the use of fossil fuels in different parts of the world, one of which 
is "use as much as you can afford and we'll do our best to keep prices low
for the whole country" and another is "tax the worst wastage of fossil 
fuels and use the taxes to fund public transportation which has less impact
on the environment", and the latter is at least arguably saner.  

In other words, if some practice causes harm when that practice is 
widespread, then _some_ kind of caution or restraint might be in order.
Pretending that the problem doesn't exist doesn't seem wise.

>  And while I agree that there are certain 

I disagree with the statement as writen, but more importantly, with the 
implications of the statement.  IETF cannot possibly be a home for all
protocol development on the Internet.  There are simply too many protocols.
After all the Internet is supposed to be a general-purpose communications
framework that can support an arbitrary number of applications.

So a lot of protocol development will always be done outside of IETF, 
and this is a Good Sign.  If we ever get to the point that protocol 
development can only be done within IETF (perhaps because the network
imposes so many constraints that IETF is the only place they can be 
sorted out), we will have failed miserably.

Furthermore there will always be vendors who prefer to "let the market
decide" which protocol will be used than to "let IETF decide" for reasons
that have nothing to do with IETF being too risk averse.  Any vendor which 
has a substantial lead in market share will in general prefer to deploy 
first and later insist that IETF (or other standards-making body) either
rubber-stamp or fix the bugs in its "de facto" standard - thus ensuring
that they keep the competition in catch-up mode.  There's nothing new 
about that, it's been happening for years.

I'd also argue that much of the value that IETF adds (if it is doing its
job right) consists of risk minimization - specifically minimizing the 
risk that customers who invest in deploying IETF standards will have 
substantial incentive to have to completely discard that investment 
within a short time.

Now, clearly there's such a thing as being too risk averse, but I don't
think that's our main problem.  I am more concerned that we don't pay 
attention to some substantial risks until very late in our processes - 
when it's too late to fix the problems.

> seriously take place.  Risk averse. 

Maybe the problem is not just being risk averse, but our development style.
Something tells me that having random, unstructured conversations for
months on end and gaining consensus by exhaustion are not good ways 
to do protocol development.  And only after the WG is exhausted do we
do any serious external review.  But it's not fair to blame the reviewers
for being too risk averse  when the WG failed to pay attention to those
risks in the first place.

Now the *perception* might be that we're too risk averse, just because
we take so long to get protocols out the door.  But while there are 
lots of ways to speed up the process, to simply be less risk adverse is
to fail to do our jobs.

> You know that thing about running 

Those wars would have cropped up anywhere else that didn't simply 
cave in to pressure from one faction.   You can't force people to agree,
particularly when they think they gain a competitive advantage from
not agreeing.

> This was never the series' intent.  

Face it, there's no way that the RFC series could have continued to be 
the Engineering Notebook for the Internet for all this time.  The Internet 
has long since become too large and too diverse.  The RFC series structure
could never have accommodated it.  Maybe something like a Wiki, but even
that's a stretch.  For that matter, no matter what the structure, there 
would always be people who didn't want to go along with that.  Heck, we
can't even get everyone to agree on the structure of domain names, and 
those are far, far simpler and with obvious advantages to uniformity.

The truth is that we've long since abandoned the original intent of the
RFC series, and appropriately so.  Except as a historical note the original
intent is scarcely relevant now.

> We've attempted to warp it into 
> lack of development within the IETF. 

Oh, BS.  The change in the RFC series hasn't hindered development a whit.
If you don't want to jump through the minimal hoops required to get your
protocol published as Informational or Experimental, there are plenty of 
other ways to publicly document your protocol.

> If we want to allow for REAL 

non sequitor.
 
--
Power corrupts; Powerpoint corrupts absolutely. 	- Vint Cerf

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 30 Mar 2004 07:32:15 -0800

--On 27. mars 2004 15:53 -0800 "Paul Hoffman / VPNC" 
<[email-masked]> wrote:

> The material in draft-iesg-rfced-documents-00.txt can be greatly improved
> with a few changes:
>
> - Require that all documents published without IESG technical review say
> so explicitly in a standardized boilerplate: "The technology in this
> document was reviewed the RFC Editor, but was not approved by the IESG or
> any IETF Working Group. See RFC xxxx for more information on the process
> used in the publication of this document" This will help readers of the
> RFC who haven't read 2026 et. al., and will also serve as a hindrance to
> over-marketing the document.

The concept of boilerplate disclaimers is already in there. Are you 
suggesting alternate text for the disclaimers?
Do you intend XXXX to point to draft-iesg-rfced-documents when it's 
published, or to some other resource?

> - Require that the RFC Editor not publish any document as an Experimental
> RFC unless it meets the definition on RFC 2026 or its successors. Publish
> a non-standards-track protocol as an Informational RFC with the above
> wording unless it really is "a specification that is part of some
> research or development effort". It is the responsibility of the RFC
> Editor to make this determination.

Requirement on the RFC Editor - doesn't sound unreasonable, but out of 
scope for this document.

> - Add text saying that publication as an RFC may not meet the needs of
> many publication requesters, and that having an RFC can actually inhibit
> innovation and flexibility due to the limitations of the series such as
> long publication times, difficulty of revision, and so on.

I don't quite see the point of this, but anyway think that such a 
disclaimer belongs on the RFC Editor's pages, not in this document....

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 30 Mar 2004 09:51:43 -0800

>suggesting alternate text for the disclaimers?

I'm suggesting that this be added to, not replace, the current 
boilerplate for non-IESG-reviewed RFCs.

>published, or to some other resource?

To the RFC that comes from draft-iesg-rfced-documents.

>Requirement on the RFC Editor - doesn't sound unreasonable, but out 
>of scope for this document.

Not really. Currently, when the IESG reviews non-standards-track 
documents, it makes a decision (or approves a request) for the 
status. This document puts that decision into the RFC Editor's hands. 
It would be good to give on-record advice for how the RFC Editor 
should make that decision, particularly since the recent experiences 
with making things Experimental are not consistent with the wording 
in 2026.

>disclaimer belongs on the RFC Editor's pages, not in this 

Probably true. Just taking another opportunity to try to reduce the 
work load of the IETF...

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 30 Mar 2004 09:51:43 -0800

--Paul Hoffman, Director
--VPN Consortium

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 30 Mar 2004 12:29:17 -0800

--On 30. mars 2004 09:51 -0800 "Paul Hoffman / VPNC" 
<[email-masked]> wrote:

> documents, it makes a decision (or approves a request) for the status.
> This document puts that decision into the RFC Editor's hands. It would be
> good to give on-record advice for how the RFC Editor should make that
> decision, particularly since the recent experiences with making things
> Experimental are not consistent with the wording in 2026.

it would be good, but that's not the IESG's role .... it is the IAB's.
While the IAB has seen this document (and made encouraging noises), it is a 
document from the IESG, saying how the IESG intends to behave (and how it 
expects future IESGs to behave, once the IETF consensus that this procedure 
makes sense). I'd like to keep it at that....

                Harald

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 30 Mar 2004 12:29:17 -0800

Harald

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 30 Mar 2004 13:29:43 -0800

>it would be good, but that's not the IESG's role .... it is the IAB's.

Ah, good point. Nevermind...

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 30 Mar 2004 13:29:43 -0800

--Paul Hoffman, Director
--VPN Consortium