Subject: Re: [newtrk] guestion 5 for newtrk (was: Re: question four for newtrk)

From: John C Klensin <[email-masked]>
Date: Sat, 10 Jul 2004 14:03:26 -0400

Responding to part of Brian's comment in the question four
thread, but it really belongs here.

Brian,

First, I don't see any possible justification for sliding from
the "question four" topic in the newtrk charter into a
discussion of the value of independent submission and
publication -- those aren't standards-track documents and,
perhaps that is just the point. Legalize about charters aside,
there is reason to presume that many people who have a
legitimate interest in the independent submission question and
its answers are not following newtrk, so a discussion here is a
sure path to a bogus consensus.

That said, I want to make sure that what is, to me, the major
argument for independent submissions and publication.  The
"rough" part of our standardization process (and I note that I
haven't heard a question yet about eliminating that term)
involves some deliberate slack.  For example, we not only don't
vote, we don't go to every possible materially concerned party
and say "is this ok with you, and, if not, what would it take to
resolve your objections"... and do that iteratively until every
possible objection is resolved or some extraordinary dispute
resolution policy has to be invoked.  Many of the ISO member
bodies do it that way, as, if I correctly understand the
procedures, do ITU-T Study Groups.  In principle, and some
occasionally-excessive zeal on the IESG's part notwithstanding,
we don't do that.  Instead, we assess rough consensus, conclude
it is there, and move on.  And we do that at both ends of the
process -- starting an effort (whether via a WG Charter or
otherwise) and approving things -- and, often, at many points in
between.

If we use it wisely, that model permits us to do things more
quickly than we might otherwise.  And it creates some risks of
our approving something that has obvious bad consequences or
with which part of the community intensely disagrees.

Independent-submission publication, _especially_ of things with
which a significant fraction of the community disagrees, is our
best remedy to that situation.    If we do something that a
member of the community considers really dumb, a "that idea is
considered harmful" document, or a "the IESG decided to not look
at this, and that was stupid because I think the issue is a
technical/engineering/operational one that is of critical
concern to the IETF and the Internet community more broadly"
one, are, ultimately, essential parts of the process.  And they
are much more useful to all concerned than appeals.

Should the RFC Editor publish all such documents?  I don't think
so -- I really like the idea of their being held to a high
standard for utility and technical and editorial quality, maybe
even a higher one than that to which we hold standards-track
materials.  That implies that the RFC Editor may need somewhat
different review procedures than have been used in the past (a
process that seems to be developing).  But more involvement by
the IESG is a mistake -- too many of their cycles and just an
opportunity to repeat the same opinions and biases that go into
standardization -- so I consider the recent moves by the IESG to
reduce its involvement back to that called for by RFC 2026 to be
a positive step.

Now, should these be appropriately qualified and labeled?  Of
course they should.  Are we doing well enough at that and could
we really do better?  Beats me, but I note that
draft-klensin-std-repurposing could be seen as addressed to the
question of clarifying that standards-track materials are
standards-track materials and RFCs are numbered documents.  And,
IMO, the current disclaimer language is sufficient, bordering on
excessive, if anyone actually reads it.

And, by contrast, if we are going to consider eliminating
independent-submission publication, or significantly restricting
it, then we need to start asking ourselves a number of other
questions that _are_ within Newtrk's charter, including
questions about more precise definitions of "consensus" to be
sure that significant stakeholders can't be ignored, that we
have the right formal mechanisms to avoid capture by loud
minorities, to have much better checks and balances on WG and
IESG behavior than the appeals process alone affords, and so on.
I don't think going there would help us; it might turn us into
some organizations who processes we traditionally don't admire
very much.

      john

--On Saturday, 10 July, 2004 10:22 +0200 Brian E Carpenter
<[email-masked]> wrote:

> Scott Bradner wrote:
>>> one point that is easily missed here - there's also a
>>> difference  between individual submissions that were
>>> reviewed to some degree within  IETF (with WG or IESG review
>>> and sometimes even a Last Call) and  individual submissions
>>> that were published by the RFC Editor without  benefit of
>>> IETF review.
>> 
>> 
>> true enough - I'm asking about the 2nd class
> 
> And nobody's mentioned the small elephant in the room:
> 
> Fundamentally this is the IETF's "First Amendment" issue, to
> use
> the terminology of one particular country. Do we want to use
> our
> publication process to allow publication of documents which
> have
> *not* successfully passed IETF/IESG, IRTF, or IAB review, and
> may even
> have been found objectionable by one of those bodies? The RFC
> Editor
> has always argued passionately for this. You can argue that
> this isn't
> a question for newtrk - in fact as BCP 39 is written, it's an
> IAB decision,
> but it would be as well to be clear about it here.
> 
> (It seems obvious to me that such RFCs should be easily
> identifiable,
> but that's really an operational issue for the RFC Editor.)
> 
>     Brian
> .
> newtrk
> resources:_____________________________________________________
> web user interface:
> http://darkwing.uoregon.edu/~llynch/newtrk.html
> mhonarc archive:
> http://darkwing.uoregon.edu/~llynch/newtrk/index.html
>  

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Keith Moore <[email-masked]>
Date: Sat, 10 Jul 2004 19:07:10 -0400

> best remedy to that situation.

I agree with the above, at least in principle.  In practice, I wonder 
how often individual submissions have served this purpose.  Offhand, I 
can't think of an example where they have done so.

OTOH, I can think of a few examples where disgruntled authors gave up 
trying to get IETF endorsement of their works and voiced their dissent 
(or stronger) in private web pages.  And yes, often there's something 
valuable to be learned from the comparison between the dissenter's 
approach and the approach taken in the RFCs he or she complains about.  
And yet I suspect the RFC Editor would not want to publish many of 
these documents without significant modification, and I suspect most of 
the authors would not want to modify the tone of their documents to 
make them acceptable to the RFC Editor.

I want to keep a clear distinction between "consensus" individual 
submissions (which are noncontroversial and are subject to an 
appropriate degree of IETF review) and "dissenting" independent 
submissions.  I'm quite sure we do not want to eliminate the former.  
It seems to me that if the latter are to serve the purpose you 
describe, we would do well to rethink the procedures for those so that 
they provide maximum benefit to the community.

At present the RFC Editor can be asked to delay publication of any 
independent submission that conflicts with the technical direction 
taken by an active working group, until that group has finished its 
work.   The intent is to avoid having the independent submission be an 
"end run" around the working group, and I agree with that intent.  But 
the effect is to quiesce the dissenting view until it can no longer be 
useful.

What we need is a way to have dissenting views aired _outside_ a 
working group long before a working group has finished its work.  That 
way there would be at least some possibility for the differences to be 
resolved before the working group completes.  And if the differences 
cannot be resolved, at least it might be possible to avoid the worst of 
the pitfalls identified by the dissenter.  And yes, ideally this would 
all be done within the context of the working group.  But for various 
reasons groups can get stuck on the wrong track.  Having a way to 
publicly raise dissenting views that are visible outside of a working 
group might provide some incentive to get them unstuck at a later date. 
  And they would be much less disruptive ways of raising divisive issues 
than Last Call comments, appeals, or fighting the WG tooth-and-nail.

Clearly, publishing a dissenter's documents in the same form as a WG's 
output (e.g. RFCs) but well prior to the WG's output, would not be 
appropriate.  And mere internet-drafts do not have a sufficient level 
of visibility.  So it may be that we need something in between an I-D 
and a RFC - perhaps akin to working group snapshot - to give more 
visibility to the intelligent dissenter's view.

Keith

.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 11 Jul 2004 11:17:36 +0200

Thanks for switching this to the appropriate subject.
(Unfortunately I didn't read Scott's Q5 until I finished
processing Q4... I'm too linear, I guess.)

I asked the question without answering it. Well, my answer is
that John is basically correct - we need an avenue for this
form of check-and-balance, but I am concerned that the RFC Editor
needs an open review process that is sufficient to avoid end-runs
and accidental endorsement of harmful proposals. That is probably
something newtrk should *say* but it's clearly for the IAB &
RFC Editor to *do* whatever is needed.

    Brian

Keith Moore wrote:
> And yet I suspect the RFC Editor would not want to publish many of these 
> documents without significant modification, and I suspect most of the 
> authors would not want to modify the tone of their documents to make 
> them acceptable to the RFC Editor.
> 
> submissions.  I'm quite sure we do not want to eliminate the former.  It 
> seems to me that if the latter are to serve the purpose you describe, we 
> would do well to rethink the procedures for those so that they provide 
> maximum benefit to the community.
> 
> independent submission that conflicts with the technical direction taken 
> by an active working group, until that group has finished its work.   
> The intent is to avoid having the independent submission be an "end run" 
> around the working group, and I agree with that intent.  But the effect 
> is to quiesce the dissenting view until it can no longer be useful.
> 
> What we need is a way to have dissenting views aired _outside_ a working 
> group long before a working group has finished its work.  That way there 
> would be at least some possibility for the differences to be resolved 
> before the working group completes.  And if the differences cannot be 
> resolved, at least it might be possible to avoid the worst of the 
> pitfalls identified by the dissenter.  And yes, ideally this would all 
> be done within the context of the working group.  But for various 
> appropriate.  And mere internet-drafts do not have a sufficient level of 
> visibility.  So it may be that we need something in between an I-D and a 
> RFC - perhaps akin to working group snapshot - to give more visibility 
> to the intelligent dissenter's view.
> 
> Keith
> 
.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sun, 11 Jul 2004 16:19:17 -0500

> and accidental endorsement of harmful proposals.

I'm reading Brian's note as further evidence that simply having the
RFC Editor publish an RFC *IS* viewed as an endorsement, at some
level.

I know that Megaco had concerns about MGCP even being published as an
Informational RFC. IIRC (and Scott would remember this far more
clearly), the concern was that as long as MGCP had an RFC number,
especially if it had an RFC number before Megaco/H.248, that RFC
number would end up in RFP checklists from people who had no idea that
MGCP wasn't an IETF standard, and that another protocol was.

We need a marker for non-IETF documents that's a lot more visible than
the current (rarely used) STD designation. Maybe "what standards" is
sufficient (hint, this is the third time this week I've typed these
words on General Area mailing lists - any interest?).

But maybe if non-IETF documents are still "RFCs", I believe that our
efforts to distinguish between non-IETF documents and IETF documents
are semi-doomed...

Spencer

.

---

From: Aaron Falk <[email-masked]>
Date: Mon, 12 Jul 2004 15:13:03 -0400

On Jul 10, 2004, at 7:07 PM, Keith Moore wrote:

> work.

Not quite.  If there is a working group conflict, the IESG can request 
a six month delay on publishing an individual submission RFC up to two 
times, resulting in around a one year delay.  See 
http://www.rfc-editor.org/policy.html.

>  The intent is to avoid having the independent submission be an "end 
> run" around the working group, and I agree with that intent.  But the 
> effect is to quiesce the dissenting view until it can no longer be 
> useful.

I disagree.  IMO, the issue is how long the document should last.  In 
our process timeliness is inversely correlated with longevity, which 
seems appropriate to me.  If you have something to say that you want 
published quickly, use the ID process and, for greater visibility, send 
email pointing to your missive to other mailing lists.

However, if one wants one's opposition to an IETF action to be 
permanently on record, i.e., if longevity is important, a one year 
delay in publishing an RFC doesn't seem to render the document 'no 
longer useful'.

--aaron (speaking for myself)

.

---

From: Keith Moore <[email-masked]>
Date: Mon, 12 Jul 2004 19:31:00 -0400

> http://www.rfc-editor.org/policy.html.

That's too bad; maybe we should change it. 

One year isn't long enough to prevent such RFCs from being used to
mislead people.  I do think we need a way for dissenting views to be
aired, but I don't think we need a way for dissenting views to be published
as RFCs sooner than the consensus views are published as RFCs. 

> > run" around the working group, and I agree with that intent.  But
> > the effect is to quiesce the dissenting view until it can no longer
> > be useful.
> 
> published quickly, use the ID process and, for greater visibility,
> send email pointing to your missive to other mailing lists.

Yes, and we do that to some degree, but it doesn't work very well.
Email messages are too ephemeral (even if archived), and I-Ds are 
too numerous.

> delay in publishing an RFC doesn't seem to render the document 'no 

Well, it might provide some historical context, or it might give the
author the ability to say "I was right" after the fact, but that's a
small consolation.  By "no longer useful" I meant no longer useful in
influencing the debate within the wider community. 

What I think would be helpful is some sort of channel to give wider 
(and earlier) exposure to dissenting views that have good technical 
foundation.
  
--
Regime change 2004 - For great justice.
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: John C Klensin <[email-masked]>
Date: Mon, 12 Jul 2004 20:54:25 -0400

--On Monday, 12 July, 2004 19:31 -0400 Keith Moore
<[email-masked]> wrote:

>> > At present the RFC Editor can be asked to delay publication
>> > of any  independent submission that conflicts with the
>> > technical direction  taken by an active working group,
>> > until that group has finished its  work.
>> 
>> Not quite.  If there is a working group conflict, the IESG
>> can request a six month delay on publishing an individual
>> submission RFC up to two
>> 
> One year isn't long enough to prevent such RFCs from being
> used to mislead people.  I do think we need a way for
> dissenting views to be aired, but I don't think we need a way
> for dissenting views to be published as RFCs sooner than the
> consensus views are published as RFCs. 

Keith,

Again, this is, I strongly believe, off topic for newtrk -- some
of the right people just aren't participating.

First of all, let's be clear about what we are talking about.
Until there is an IETF conclusion, there is no such thing as a
"dissenting view".  There are positions that we can predict will
turn out to be dissenting views, but WGs have been known to
change their minds, sometimes fairly late in the game.  That may
be a subtle distinction, but it is, IMO, important to this
discussion.

But there need to be checks and balances in both directions.  We
have both observed WGs who seem to drag things out forever.
There have been occasional claims that this has sometimes been
due to organizations for whom "no standard" is the best possible
outcome (something that has certainly happened in some other
standards bodies).  And there have been rumors of IESG members
sitting on documents for a very long time --whether individual
or WG-generated-- nearly forever because they just don't like
them.  So, to take a more extreme case than the one you are
probably thinking about, I don't think it should be possible for
a WG (or the IESG) to block an individual document forever
--whether it is a dissent or not-- by the simple expedient of
putting a related task on a WG charter and then no making any
progress on it.

This issue, of course, interacts strongly with the discussions
of a year or so ago in which various of us were asking the IETF
to consider some rather draconian "make progress or get out of
the way" measures, with my suggestion about a ceiling on the
number of WGs so there would be more incentive to kill off ones
that were not producing and the Huston/Rose suggestion about
some very specific timeouts as the two that I recall having been
written down.  Now I, and I think Marshall and Geoff, would
prefer that the IESG --without overly-rigid external rules--
manage WGs aggressively enough that those which are not making
progress are either given  more motivation or killed off.
Sometimes that doesn't happen, sometimes even for good reason.

Now I would assume that, if the second six months to which Aaron
refers is close to running out, and the IESG came to the RFC
Editor and said "look, the relevant WG documents are going into
Last Call and it is in everyone's interest that the alternate
view be published after the approved WG position", the RFC
Editor would agree to a reasonable additional deferral -- I've
never noticed them being unreasonable about such things in the
past and think that, if anything, they have waited longer than
appropriate when the IESG has essentially ignored timeouts (a
problem that we can now hope is in the past).   I would also
expect that, if the RFC Editor decides to go ahead and publish
something that might conflict with something on which the IETF
has not yet made a decision, they would hold the author to an
exceptionally high standard of being clear about the status of
the document, including its relationship to ongoing IETF
discussions.

But the idea that any group can, by inaction or failure to make
rapid progress, block something else more or less indefinitely
--and to do so privately, because these requests to the RFC
Editor for delays are rarely known to anyone but the IESG, the
RFC Editor, and the authors-- ought to be abhorrent to us.  So,
if  you (or others) are convinced that significantly longer
periods than a year are needed, I think you need to be proposing
some procedure by which the IESG can test community consensus
(not just WG consensus, or an AD or two, or even IESG consensus)
for a long delay and do so through a public process.   And I
would recommend that the process examine the proposed document
for whether it is insufficiently clear enough about intent to
cause confusion.  If there is no potential for confusion, then I
don't see much justification for deferring publication for any
lengthy period of time.

>...
>> However, if one wants one's opposition to an IETF action to
>> be  permanently on record, i.e., if longevity is important, a
>> one year  delay in publishing an RFC doesn't seem to render
>> the document 'no  longer useful'.
> 
> Well, it might provide some historical context, or it might
> give the author the ability to say "I was right" after the
> fact, but that's a small consolation.  By "no longer useful" I
> meant no longer useful in influencing the debate within the
> wider community. 

Keith, I won't claim it is common --which is a good thing
because it may imply that we mostly get our standards at least
nearly right-- but there have been several times in which the
"wider has been sufficiently unimpressed with a WG-produced
standard that they have voted with their feet by ignoring the
standard and casting around for something else to do.  If that
happens, a well-documented alternative may be viable for quite a
while.  In additional, well-documented dissenting alternatives
may make some issues clear enough to keep variations from
cropping and deserving the "bad idea list".

> What I think would be helpful is some sort of channel to give
> wider  (and earlier) exposure to dissenting views that have
> good technical  foundation.

We agree.  But I'm not sure that, if there is an active
discussion going on, that I-Ds and mailing list announcements,
etc., are not sufficient, at least most of the time.  If that is
unsuccessful, there is time for RFC publication.  In the
exceptional cases, I hope that everyone involved is reasonable
enough that some negotiation is possible.  For example, nothing
_requires_ the IESG to ask that any document that overlaps with
a WG effort be deferred.  Indeed, I can imagine a AD going to a
WG and saying "look, there is this document out there that
proposes a different point of view and if you can't produce
something solid really quickly, we are going to let them publish
with appropriate disclaimers about your work probably coming
along sooner or later".  It might help focus the attention in
positive ways.

    john

.

---

From: Aaron Falk <[email-masked]>
Date: Mon, 12 Jul 2004 21:47:14 -0400

> (and earlier) exposure to dissenting views that have good technical

Keith-

I'm really stumped on this notion of another communication vehicle 
besides mailing lists, IDs, and RFCs.  (I suppose you could put web 
pages and jabber on the list, too, although they have no formal role in 
the IETF process.)  Perhaps you could give an example of where the 
existing mechanisms for expressing dissenting views were inadequate, in 
your opinion, where some other kind of publication would have helped.

--aaron  (thinking that perhaps the problem is too many dissenting 
opinions makes it hard to separate the signal from the noise...)

.

---

From: Keith Moore <[email-masked]>
Date: Mon, 12 Jul 2004 23:25:01 -0400

> "dissenting view". 

That may have been true at one time.  I don't think it's true today. 
Working groups (or the leadership of working groups) often get locked
into mindsets early, sometimes before they are chartered.  They decide,
explicitly or implicitly, to adopt particular documents and ignore other
documents.  And yes, WGs do sometimes change their minds.  What I want
to do is to make it easier for WGs to realize when there are valid
alternatives to their mindsets, so that they can change their
minds more easily when it's appropriate for them to do so.

> standards bodies).  

It seems like the ability to have dissenting views made widely 
visible would actually help with this problem.  If it were it clear 
to the wider community that there were well-thought-out, reasonably
complete, viable solutions to the problem then it would be all the
more obvious that the WG were stalling.

But maybe we don't need to call them "dissenting" views.  Offhand I
don't see an inherent need to distinguish between "dissenting" views
and views held by a significant plurality of a working group.  I
just think it would be useful to have a mechanism by which well-thought-
out ideas and solutions could be vetted and made visible to a wider
community.

> And there have been rumors of IESG members
> them. 

The threat of an end run around IESG might be an incentive towards
termination, but I doubt that it is a incentive towards producing
documents of value to the community.  Yes, it has sometimes encouraged
IESG to review documents more quickly, but in my experience it was more
likely to cause IESG to spend lots of energy trying to fix things that
were too broken to fix with small changes in text - especially when the
RFC Editor demonstrated a willingness to publish the dubious document
verbatim (or nearly so) but insisted on censoring the IESG's comments on
that text.

> So, to take a more extreme case than the one you are

Nor I.  But there are some mechanisms, formal and informal, which should
discourage this.   The existence of a visible and apparently viable
alternative to the working group's favored approach could by itself
create pressure on a WG to either justify that approach or to work on
some compromise.  That, and working groups are not chartered "forever". 
Their work should get external review from time to time.  Lack of
progress within a working group, coupled with a visible and apparently
viable proposal (whether or not it has the support of a plurality of the
WG) should be grounds for IESG insistence that the WG either finish its
work within a few months, or be shut down, afer which all competing and
apparently viable proposals would be published simultaneously as
Informational.

> the document, including its relationship to ongoing IETF

I used to assume such things, and in my experience while on IESG the
RFC was _generally_  reasonable.  But I don't think this policy was in
place when I was on IESG, and I don't think it's good policy.  More
generally I don't believe that it serves us well to have RFC Editor
policy developed independently of IETF policy, because the two need to
work in tandem.

> for a long delay and do so through a public process.

It just seems to me that most working groups take around two years
to complete their work - and often longer.  So it doesn't seem to 
me desirable to have a policy in place that says that anybody can
write up a proposal and submit it at the time a working group
starts (or even before) and expect to have that proposal published 
_as an RFC_ before a working group can hope to finish its work.

> standard and casting around for something else to do.

Yes, and there will always be some of that.  My goal is to try to get
more WGs on the right track _before_ they finish.  Because WGs are
taking on ambitious work (= potentially disruptive work) more often than
in the past, and the impact of _not_ producing an "impressive" solution 
in a timely fashion is more severe than it used to be.

> enough that some negotiation is possible. 

Recent experience with several WGs has convinced me that these are no
longer sufficient, and that reasonableness and willingness to negotiate
can no longer be assumed.

> For example, nothing

Something like that, yes.  I'm just saying that the process as currently
defined has some known problems.  And given that the policy seems to be
designed to complement the "official" publication track, it makes sense
to re-examine the RFC Editor's policy at the same time as we re-examine
the official track.

Keith
.

---

From: Keith Moore <[email-masked]>
Date: Mon, 12 Jul 2004 23:45:00 -0400

> pages and jabber on the list, too, although they have no formal role
> in the IETF process.)  Perhaps you could give an example of where the 
> existing mechanisms for expressing dissenting views were inadequate,
> in your opinion, where some other kind of publication would have
> helped.

For various reasons, I'd rather not cite specific working groups or
discussions.

The problem, in a nutshell, is that

- all of our stable documents are lumped into the RFC category
- from a distance (e.g. a citation) any RFC number looks as "legitimate"
  or "standard" as any other.  

(actually it's worse than that - people have consistently and frequently
demonstrated the ability to quote _text_ from RFCs and cite that text as
"standard" even when the RFC clearly states that it's not a standard.)

Thus in our current process we have no way to publish any stable, 
referencable document that doesn't look like a "standard" to most
readers.

And yes, we've tried to dispel this view with April 1 RFCs and an RFC
titled "Not All RFCs Are Standards".  We failed.  There are now so many
RFCs that nobody can keep track of which ones are which, or which ones
are standard.  And the user community is much larger than it used to be,
and through no fault of our own (unless we can be faulted for success),
the potential for confusion has grown rather than lessened.

It's one thing to say we are willing to publish well-vetted ideas that
have not (yet) gained consensus.   I fully support that, as long as we
can find the resources to do the vetting and publishing in a competent
fashion.  What I don't support is that we should keep giving those
documents the same appearance, labelling, and citation format as we give 
to those documents that are supported by community consensus.  We need to
make the distinction clearer than it is now.

Keith
.

---

From: Aaron Falk <[email-masked]>
Date: Tue, 13 Jul 2004 07:56:18 -0400

Keith-

I agree that some people see this as a problem.  Indeed, as I 
understand it, it is the problem that motivated Questions 4 and 5.  
However, I think for any possible solution short of not publishing any 
non-standard documents you can probably find a 'distance' for which 
some will continue to consider this a problem.  As I understand it, 
Scott is asking: what, if any, new 'primary marking' will help? and 'is 
this so bad that non-IETF documents (individual submissions) should not 
be published at all?'

However, I don't understand how the problem described above is helped 

> (and earlier) exposure to dissenting views that have good technical

which was what I was asking about...

--aaron

.

---

From: Keith Moore <[email-masked]>
Date: Tue, 13 Jul 2004 08:46:32 -0400

> some will continue to consider this a problem.

I think this is an exaggeration.  For instance, if we were to stop 
using the letters RFC entirely and instead define new document series, 
call them "Recommendation" and "Proposal", and label them IETF-R-XXXX 
and IETF-P-YYYY-MM-XXXX (YYYY and MM being year and month) I don't 
think it likely that people would confuse the two.

(Note that this is an example chosen for the sake of simplicity, rather 
than an actual proposal for what we should do.  But I do think that 
we're over-constraining ourselves with the assumption that everything 
we publish has to look like, and be numbered like, an RFC)

> As I understand it, Scott is asking: what, if any, new 'primary 
> marking' will help? and 'is this so bad that non-IETF documents 
> (individual submissions) should not be published at all?'
>

At present we have no good way to give wider/earlier exposure to 
dissenting views without giving them the appearance of being 
"standards" or having IETF's imprimatur.   But it's not as if "publish 
as RFCs" or "don't publish in a stable form" are our only options.

Keith

.