Subject: Re: [INDEP] Issues in draft-klensin-rfc-independent-02.txt

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 6 Jul 2006 17:40:19 +0200

Dear colleagues,  mostly John and Brian,

So I went back once more and reread the the thread.

Here is a straw-man. I hope we can conclude the discussion by  
incorporating the following changes.

I propose that any alternative is being motivated with actual text to  
be put into the document.

In section 4.8 there are two paragraph that both cover the 3rd item  
in section 3 of RFC 3932. The current version of the draft reads:

>    If the IESG, after completing its review, concludes that  
> publication
>    of the document should be delayed for a reasonable period of time,
>    the RFC Editor will grant that request.  The current agreement
>    between the RFC Editor and the IESG on requested delays is expected
>    to continue.  That agreement permits the IESG to ask for a delay of
>    up to six months and, if necessary, to renew that request twice,  
> for
>    a total possible delay of 18 months.
>
>    If the IESG concludes that the document should not be published  
> as an
>    RFC, it will request that the RFC Editor not publish, providing
>    appropriate justification.  The RFC Editor will consider the  
> request
>    to not publish the document.

I think it is clear that the last paragraph is in conflict with 3932  
text: 'request for not publishing the document at this time'. That  
paragraph should therefore be removed.

RFC 3932 makes clear that the IESGs only responsibility is to judge  
how the work relates to work inside current work in the IETF and if  
IETF procedures are followed or not. It leaves management of further  
technical review to the RFC-editor (management in agreement with the  
IAB). But if you think that the IESG will also be in a position to  
notice possible harmful technology, it might be helpful to add this  
paragraph after the text above:

>    If  in its review the IESG concludes that the document does not
>    conflict with the IETF work or procedures but notices that the
>    work may be harmful for the Internet then it should make this
>    known to the RFC editor. The RFC editor will treat these reviews
>    as unsolicited reviews (section 4.7).

Now for a slight modification of the appendix. I think that RFC 3932  
is clear in setting the scope of the IESG responsibility. That  
responsibility excludes technical review. This fact is I think not  
clearly identified in the appendix.  I suggest changing the  
introduction paragraph
of the appendix and leaving the principles as stated:

>   The discussions that led to this document and experience since RFC
>   3932 was published suggests that a review and corresponding  
> adjustment
>   of specific boilerplate text in RFC 3932 is in order. Besides  
> there might
>   be cases where the RFC editor, base on its technical review may  
> want to
>   add a boilerplate text.
>
>   The guiding principles for updating or designing such the  
> boilerplate texts
>   should be:
[original text follows for context]
>    1.  No document should be published on an independent submission
>        basis that would cause confusion with an active IETF protocol
>        development or specification effort.  The IESG is normally the
>        best-positioned body to determine whether such conflicts exist.
>    2.  No independent submission should be so written as to state or
>        imply that it is a standard, or a specification that will be
>        standardized, from the IETF or any other body unless that  
> is, in
>        fact, the case.  Similarly, no claim should be made about IETF
>        consensus unless the IESG determines, after a Last Call or
>        equivalent process, and such consensus actually exists.
>    3.  Some, although certainly not all, independent submissions are
>        extensively discussed and reviewed within the IETF  
> community, or
>        the Internet community more generally, prior to submission for
>        publication.  Just as no statement should appear in a published
>        document that states or implies level of adoption,  
> agreement, or
>        consensus that did not occur, no statement should appear that
>        states that significantly less review occurred than was  
> actually
>        the case.  Similarly, no statement should appear that suggests
>        that the IETF community has a negative view of the document
>        unless such a view has been established via formal consensus-
>        determining mechanisms.
>    4.  It is desirable that well-reasoned critical reviews and  
> critiques
>        of, and even dissents from, IETF standards and conclusions be
>        published in the RFC series.  These documents must be clear  
> about
>        their status and purpose.  Such clarity in the text is  
> preferable
>        to "boilerplate" disclaimers that few people will read: such
>        boilerplate is, at best, a second-choice alternative to clarity
>        in the text.  Conflict with an IETF position is not a reason to
>        deny, or even significantly defer, publication.  The potential
>        for confusion with an IETF Standard or position, or its
>        interpretation, usually will be a reason to deny or defer
>

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

_______________________________________________
INDEPENDENT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/independent

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 6 Jul 2006 13:00:20 -0400

Folks, I sent input to the IAB and Leslie.  One thing that is very
important is for some text to be stated in all such documents  the work
is in no way, shape, or form an IETF tracked effort or standard or
anything other than individual submission.  We do not want marketing
departments of vendors claiming papers have IETF consensus or other
absurd statements from this good will gesture on the part of the IETF. 

I also suggest someone send a list of why IESG would not accept a
submission and also why it would.  That should be an additional
appendix.

Thanks
/jim 

> -----Original Message-----
> From: Olaf M. Kolkman [mailto:[email-masked]] 
> Sent: Thursday, July 06, 2006 11:40 AM
> To: [email-masked]
> Cc: John C Klensin; Bob Braden; Brian E Carpenter
> Subject: Re: [INDEP] Issues in draft-klensin-rfc-independent-02.txt
> 
> 
> 
> I propose that any alternative is being motivated with actual 
> text to be put into the document.
> 
> In section 4.8 there are two paragraph that both cover the 
> 3rd item in section 3 of RFC 3932. The current version of the 
> draft reads:
> 
> 
> >    If the IESG concludes that the document should not be 
> published as 
> > an
> text: 'request for not publishing the document at this time'. 
> That paragraph should therefore be removed.
> 
> RFC 3932 makes clear that the IESGs only responsibility is to 
> judge how the work relates to work inside current work in the 
> IETF and if IETF procedures are followed or not. It leaves 
> management of further technical review to the RFC-editor 
> (management in agreement with the IAB). But if you think that 
> the IESG will also be in a position to notice possible 
> harmful technology, it might be helpful to add this paragraph 
> after the text above:
> 
> Now for a slight modification of the appendix. I think that 
> RFC 3932 is clear in setting the scope of the IESG 
> responsibility. That responsibility excludes technical 
> review. This fact is I think not clearly identified in the 
> appendix.  I suggest changing the introduction paragraph of 
> the appendix and leaving the principles as stated:
> 
> >   of specific boilerplate text in RFC 3932 is in order. 
> Besides there 
> > might
> >   be cases where the RFC editor, base on its technical 
> review may want 
> > to
> >   add a boilerplate text.
> >
> >        standardized, from the IETF or any other body unless 
> that is, 
> > in
> community, 
> > or
> agreement, 
> > or

---

From: Bob Braden <[email-masked]>
Date: Thu, 06 Jul 2006 13:27:54 -0700

>>        best-positioned body to determine whether such conflicts exist.

Or in some cases they can be (have been) the worst-positioned.

The claim of "confusion" is very much a question of interpretation.
Indeed, there are some on the IESG who really feel that ALL
publication of independent submissions is automatically a
source of confusion with standards track documents.  And
IESG members are on the whole exceedingly protective
of their process.  There are very few, if any, indepndent
submissions that some zealous IESG member could not
claim to cause confusion with SOME IETF effort.  Note that
the IESG has claimed confusion with a WG that *has not
yet been formed*, but which they THINK they will happen
sometime in the next 6 months!

So, for all your fine lawyerly language, I am not sure
any real clarity has resulted.

>>        equivalent process, and such consensus actually exists.

Even for a lawyer, this seems gratuitous, considering the
boilerplate the IESG adds to an independent submission.

  \How about just saying,
"No independent submission should tell a lie"?

The RFC Editor has always been quite careful
about false claims; we have sometimesrequired modification of
indepndent submissions to make their non-standardness
very clear.

Of course, we are willing to assume that
the reader of an RFC actually reads the RFC.  Some are
not willing to make that assumption.

>>        unless such a view has been established via formal consensus-

Note  that this implies a significant watering down of the current
IESG statement, which certainly does cast doubt on every
independent submission.

>>        published in the RFC series.  These documents must be clear

We certainly wish that the community agreed on this point, and
acted on it.  I cannot imagine the "all RFCs are standards" people
ever agreeing.

>>        interpretation, usually will be a reason to deny or defer

The last two sentences confused me; they seem to be
contradictory.

Bob Braden (for himself)

---

From: John C Klensin <[email-masked]>
Date: Thu, 06 Jul 2006 23:04:14 -0400

--On Thursday, 06 July, 2006 13:27 -0700 Bob Braden
<[email-masked]> wrote:

>>>    1.  No document should be published on an independent
>>>    submission basis that would cause confusion with an
>>>        active IETF protocol development or specification
>>>        effort.  The IESG is normally the best-positioned
>>>        body to determine whether such conflicts exist.
> 
> 

Bob, I would suggest that they are best-positioned to make the
determination of whether a conflict exists.  They are also
best-positioned to abuse the process and that role and
authority.  See below.

>>>    2.  No independent submission should be so written as to
>>>    state or imply that it is a standard, or a specification
>>>        that will be standardized, from the IETF or any other
>>>        body unless that is, in
>>>        fact, the case.  Similarly, no claim should be made
>>>        about IETF consensus unless the IESG determines,
>>>        after a Last Call or equivalent process, and such
>>>        consensus actually exists.
> 
> 

The intention was to prevent the IESG from adding a disclaimer
that implied a negative IETF evaluation unless there actually
was a negative IETF evaluation.
 
> "No independent submission should tell a lie"?

Today, once the IESG disclaimer is added, independent
submissions generally tell lies, since they clearly imply that
the IETF has evaluated the work and found it wanting.
 
> not willing to make that assumption.

But, if that is the case, then disclaimers are not helpful
either.
 
>>>    3.  Some, although certainly not all, independent
>>>    submissions are extensively discussed and reviewed within
>>>        the IETF
>>> community, or
>>>        the Internet community more generally, prior to
>>>        submission for publication.  Just as no statement
>>>        should appear in a published document that states or
>>>        implies level of adoption,
>>> agreement, or
>>>        consensus that did not occur, no statement should
>>>        appear that states that significantly less review
>>>        occurred than was actually
>>>        the case.  Similarly, no statement should appear that
>>>        suggests that the IETF community has a negative view
>>>        of the document unless such a view has been
>>>        established via formal consensus- determining
>>>        mechanisms.
> 
> 

that was certainly the intent.
 
>>>    4.  It is desirable that well-reasoned critical reviews
>>>    and critiques
>>>        of, and even dissents from, IETF standards and
>>>        conclusions be published in the RFC series.  These
>>>        documents must be clear about
> 
> acted on it.  I cannot imagine the "all RFCs are standards"
> people ever agreeing.

I cannot imagine the "all RFCs are standards" people ever being
happy about any independent submission or even about
IESG-processed Informational or Experimental documents.  I also
believe that they are a minority in the community.  Part of the
purpose of this document was to clarify just that.    If there
really were community consensus to do away with independent
submissions or force them into some third-class status (and,
again, I don't believe there is), then we should be having a
different discussion, probably one about separation IETF
Standards Track documents from the RFC series.
 
>>>        to "boilerplate" disclaimers that few people will
>>>        read: such boilerplate is, at best, a second-choice
>>>        alternative to clarity in the text.  Conflict with an
>>>        IETF position is not a reason to deny, or even
>>>        significantly defer, publication.  The potential for
>>>        confusion with an IETF Standard or position, or its

The text may well need tuning, but the intent of the original
was that there are two cases which I will break into three for
further clarity below:

	* Conflict or disagreement with an IETF Standard or
	position.  In an extreme and interesting case, an
	independent submission might explain, in careful detail,
	just why an IETF-approved Standards Track specification
	will not work as intended, is inappropriate from an
	interoperability standpoint, and is generally a crock.
	It is the position of the document that such a
	submission, if well-reasoned, carefully and clearly
	written, and very clear that it is a dissenting
	position, should be published.   Note that "very clear
	that it is a dissenting position" is inconsistent with a
	legitimate and just claim of causing confusion.
	
	* Documents that could actually cause confusion with
	materials that are being developed as IETF Standards but
	that have not yet been approved, or even that dissent
	from such pre-Standard IETF documents.  It is reasonable
	to defer publication of independent submissions of this
	type as long as the standards-track efforts are making
	good progress toward a successful conclusion and
	publication.  If the relevant WG or other process gets
	bogged down, some solution other than delay should be
	sought.
	
	* Documents that could cause confusion with published
	IETF standards.   These documents should be revised to
	eliminate the confusion, with making them clear as in
	the first category above preferred to inserting
	disclaimers.

And turning the third into the first is an RFC Editor
responsibility, not an IESG one, even if an IESG-supplied
disclaimer might be a minimum condition.

     john

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 07 Jul 2006 10:20:31 +0100

>absurd statements from this good will gesture on the part of the IETF. 
I completely agree with this point.

- Stewart

---

From: John C Klensin <[email-masked]>
Date: Fri, 07 Jul 2006 08:04:32 -0400

--On Friday, 07 July, 2006 10:20 +0100 Stewart Bryant
<[email-masked]> wrote:

> Bound, Jim wrote:
> 
>> Folks, I sent input to the IAB and Leslie.  One thing that is
>> very important is for some text to be stated in all such
>> documents  the work is in no way, shape, or form an IETF
>> tracked effort or standard or anything other than individual
>> submission.  We do not want marketing departments of vendors
>> claiming papers have IETF consensus or other absurd
>> statements from this good will gesture on the part of the
>> IETF.   
>> 

Stewart, Jim,

I don't think we disagree about anything practical, but I'm not
sure.    There are, I believe, some differences in perspective
and, although I hope it is unintentional, I detect the smell of
red herring:

(1) The IETF made an explicit decision to publish its
standards-track documents and other outputs as part of the RFC
Series.  The RFC Editor agreed to perform that publication
service.  Funding for the RFC Editor to perform its various
functions, including but not exclusively limited to IETF
publications, comes from ISOC channels and sponsors, not the
IETF or its direct participants.   Ergo, if you are assuming
that the independent submission stream and its publication are
somehow "good will gestures" by the IETF, you are historically
and practically incorrect.   It would be at least as accurate,
historically probably more so, to refer to publication of
standards track documents as part of the RFC series as a good
will gesture by the RFC Editor.

(2) No one, at least to my knowledge, has proposed any language
in independent submissions that would imply that an independent
submission document is an "IETF tracked" or approved effort or
result.  You believe in truth in advertising, I believe in truth
in advertising.  So, in principle, we should agree about what
should and should not be said.  The place where I get into
difficulty is that Informational RFCs that are processed via "AD
Sponsorship" bear the classic disclaimer 

		This memo provides information for the Internet
		community.  It does not specify an Internet standard of
		any kind.  

That strikes me as fairly clear.  As Bob points out, it won't do
much good if people refuse to read it, but nothing in the text
of a document will solve that problem.

However, the notes "suggested" in RFC 3932 go considerably
beyond that for any document that was not AD-sponsored.  If you
refer to Section 4 of 3932, you will first find an ambiguity
between the first and second cases.  Because of the requirement
that independent submissions first be posted as I-Ds, most of
these documents have been "considered in the IETF at one time".
So far, we have not required formal IESG approval for something
to be "considered in the IETF" and the document does not say
anything like "made a formal part of a WG's task list and then
dropped".  Let us consider the second case, which is the one
most often applied to independent submissions.  It says, in part,

		The IETF disclaims any knowledge of the fitness of this
		RFC for any purpose... 

This statement is false.  The IETF does nothing of the sort.
The document _may_ have actually been extensively reviewed in
the IETF community.  From experience, some fraction of them
receive considerably more discussion and review outside the
group of people who developed them than some WG documents do.
The community has repeatedly established the principle that
statements about what "The IETF" has concluded or believes are
not made in the absence of a formal consensus process that
really determines a community position.   What the IETF
disclaims should be no different from what the IETF approves or
endorses in this respect: the IESG is not equivalent to the
IETF, we do not assume that what the IESG does or does not
believe is automatically the same as what the IETF believes, and
the IESG is not permitted to substitute their judgment for that
of the community.  

If the statement had said, instead, "The IETF has made no formal
determination about the fitness...", that would be correct and
we would not be having this discussion.

The paragraph goes on to say:

		Readers of this document should exercise caution in
		evaluating its value for implementation and deployment.

This one is true, but obnoxious and discriminatory.  I suggest
that the reader should exercise caution in evaluating the value
of a P)Proposed Standard for implementation and deployment.
Indeed, such evaluations are part of what Proposed Standards are
supposed to be about.  We recognize that in a different way:
every RFC, even Full Standards, published these days bears a
disclaimer that says

		This document and the information contained herein are
		provided on an "AS IS" basis and THE CONTRIBUTOR, THE
		ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF
		ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
		TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
		INCLUDING BUT NOT LIMITED TO [...] OR ANY IMPLIED
		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
		PARTICULAR PURPOSE.

Seems to me that is a call for "caution" as well.  Whether
"extreme caution" is required for independent submissions is an
open question, but I suggest there is no basis for claiming
blanket community consensus that "extreme caution" is required
for independent submissions while no caution or only "standard
caution" (whatever that is) is required for AD-Sponsored
independent submissions.  The RFC Editor has _never_ been
whimsical or arbitrary about what documents are published: every
independent submission undergoes careful review, it just isn't
review by the IESG.

It is, I suggest, those issues that we are talking about here,
not about whether someone can write "this is an IETF standard"
into a document that is not approved via normal IETF processes.
That has never happened and IESG disclaimers are not needed to
prevent it.

     john

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 7 Jul 2006 09:42:28 -0400

John, understand about the historical perspective.  But the bottom line
is vendors have used IETF publications that are not standards tracked in
a not optimal fashion in the market.  I still strongly support a simple
disclosure of what the paper is to the RFC process as required boiler
plate in the document.  Not sure but we may simply have to agree to
disagree and see what consensus will be.

Best,
/jim 

> From: John C Klensin [mailto:[email-masked]] 
> Sent: Friday, July 07, 2006 8:05 AM
> To: Stewart Bryant; Bound, Jim
> Cc: Olaf M. Kolkman; [email-masked]
> >> important is for some text to be stated in all such documents  the 
> >> work is in no way, shape, or form an IETF tracked effort 
> or standard 
> >> or anything other than individual submission.  We do not want 
> >> marketing departments of vendors claiming papers have IETF 
> consensus 
> >> or other absurd statements from this good will gesture on 
> the part of 
> >> the
> >> IETF.   
> >> 
> and, although I hope it is unintentional, I detect the smell 
> of red herring:
> 
> standards-track documents and other outputs as part of the 
> RFC Series.  The RFC Editor agreed to perform that 
> publication service.  Funding for the RFC Editor to perform 
> its various functions, including but not exclusively limited 
> to IETF publications, comes from ISOC channels and sponsors, not the
> that the independent submission stream and its publication 
> are somehow "good will gestures" by the IETF, you are historically
> (2) No one, at least to my knowledge, has proposed any 
> language in independent submissions that would imply that an 
> independent submission document is an "IETF tracked" or 
> approved effort or result.  You believe in truth in 
> advertising, I believe in truth in advertising.  So, in 
> principle, we should agree about what should and should not 
> be said.  The place where I get into difficulty is that 
> Informational RFCs that are processed via "AD Sponsorship" 
> bear the classic disclaimer 
> 
> That strikes me as fairly clear.  As Bob points out, it won't 
> do much good if people refuse to read it, but nothing in the 
> text of a document will solve that problem.
> 
> beyond that for any document that was not AD-sponsored.  If 
> you refer to Section 4 of 3932, you will first find an 
> ambiguity between the first and second cases.  Because of the 
> requirement that independent submissions first be posted as 
> I-Ds, most of these documents have been "considered in the 
> IETF at one time".
> So far, we have not required formal IESG approval for 
> something to be "considered in the IETF" and the document 
> does not say anything like "made a formal part of a WG's task 
> list and then dropped".  Let us consider the second case, 
> which is the one most often applied to independent 
> submissions.  It says, in part,
> 
> statements about what "The IETF" has concluded or believes 
> are not made in the absence of a formal consensus process that
> disclaims should be no different from what the IETF approves 
> or endorses in this respect: the IESG is not equivalent to 
> the IETF, we do not assume that what the IESG does or does 
> not believe is automatically the same as what the IETF 
> believes, and the IESG is not permitted to substitute their 
> judgment for that of the community.  
> 
> If the statement had said, instead, "The IETF has made no 
> formal determination about the fitness...", that would be 
> correct and we would not be having this discussion.
> 
> This one is true, but obnoxious and discriminatory.  I 
> suggest that the reader should exercise caution in evaluating 
> the value of a P)Proposed Standard for implementation and deployment.
> Indeed, such evaluations are part of what Proposed Standards 
> are supposed to be about.  We recognize that in a different way:
> "extreme caution" is required for independent submissions is 
> an open question, but I suggest there is no basis for 
> claiming blanket community consensus that "extreme caution" 
> is required for independent submissions while no caution or 
> only "standard caution" (whatever that is) is required for 
> AD-Sponsored independent submissions.  The RFC Editor has 
> _never_ been whimsical or arbitrary about what documents are 
> published: every independent submission undergoes careful 
> review, it just isn't review by the IESG.
> 
> It is, I suggest, those issues that we are talking about 
> here, not about whether someone can write "this is an IETF standard"
> That has never happened and IESG disclaimers are not needed 
> to prevent it.
> 
>      john
> 
>

---

From: John C Klensin <[email-masked]>
Date: Fri, 07 Jul 2006 10:52:29 -0400

--On Friday, 07 July, 2006 09:42 -0400 "Bound, Jim"
<[email-masked]> wrote:

> John, understand about the historical perspective.  But the
> bottom line is vendors have used IETF publications that are
> not standards tracked in a not optimal fashion in the market.
> I still strongly support a simple disclosure of what the paper
> is to the RFC process as required boiler plate in the
> document.  Not sure but we may simply have to agree to

Yes.  

Two observations, however... 

* Some of the same vendors have claimed, or implied, that I-Ds
submitted for consideration by WGs, or even I-Ds they are
considering submitting to a WG, are IETF standards.  The remedy
for those problems is not, IMO, more boilerplate but a
willingness in the community to call out deliberately fraudulent
behavior in the courts if that is needed.  So far, no one has
chosen to do that at least as far as I know.

* I object, in general, to cluttering RFCs with more and more
boilerplate.  However, if the community concludes that
boilerplate is appropriate in this case, I want that boilerplate
to be true.  IMO, we put ourselves at far more risk in the
marketplace by publishing claims about IETF beliefs that have
not been validated by normal IETF process than we could save
ourselves by pushing back on an extra case of document misuse by
hyperbolic language.

      john

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 07 Jul 2006 11:04:13 -0400

I presume from the expression of concern that you feel that the notes 
John has proposed are not sufficient.
Can you propose wording that could go into such documents that would 
accomplish what you want without claiming that the IETF has actually 
found the document to be bad work?

Yours,
Joel M. Halpern

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 07 Jul 2006 17:06:31 +0100

> found the document to be bad work?

Perhaps the simplest approach is to use a different series designator for
non-IETF output.  For example IETF process == RFC,
non-IETF == XFC or somesuch.

My concern is that no matter what goes in the boilerplate most
readers regard RFC as synonymous with the output of the IETF
standards process.

- Stewart

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 07 Jul 2006 12:19:11 -0400

That would make sense if we also used different series designators 
for experimental and informational RFCs produced by IETF WGs.  Those 
often produce as much confusion about 'standards" as the independent 
submissions.
We could also choose to use something other than RFC for IETF 
standards track publications.

I personally don't think those changes would be a good idea.

Yours,
Joel M. Halpern

At 12:06 PM 7/7/2006, Stewart Bryant wrote:
>Joel M. Halpern wrote:
>
>>I presume from the expression of concern that you feel that the 
>>notes John has proposed are not sufficient.
>>Can you propose wording that could go into such documents that 
>>would accomplish what you want without claiming that the IETF has 
>>actually found the document to be bad work?
>>
>>Yours,
>>Joel M. Halpern
>

---

From: David R Oran <[email-masked]>
Date: Fri, 7 Jul 2006 12:39:32 -0400

> disagree and see what consensus will be.
Presenting a long slender neck to the knife:

I happen to agree with the people who have commented that vendors to  
sow marketing pixie dust around informational RFCs of all provenances  
and dispositions, and that this has in fact caused heartburn for  
users and other significant participants in the Internet community.

I also happen to agree with John Klensin and others that NOTHING in  
the text of the published document will do anything significant to  
ameliorate the situation.

I also think that trying to craft a clean dividing line among regular  
Informational RFCs, individual IESG-reviewed contributions, and  
direct to RFC-editor contributions would be exceedingly difficult and  
not really solve the underlying problem of people mis-characterizing  
documents as "blessed" by the IETF as "standards".

The only solution that I think really works is to put IETF standards- 
track (and possibly experimental) documents in a different document  
series from the others. That would be a major change and also require  
going back and renaming all the existing PS/DS/S RFCs into that  
series. That would be exceedingly painful.

Would it be worth the pain? I think it would - which is why my neck  
is so exposed.

That's my 2 cents - speaking as an individual and not an IAB member.

Dave Oran.

---

From: Bob Braden <[email-masked]>
Date: Fri, 07 Jul 2006 11:20:55 -0700

>series. That would be exceedingly painful.

Dave,

Did I hear you say, "ISD"?  If so, I agree.   But if you are just changing the
series name, I think that would be ineffective, short-sighted, and chaotic.

Bob Braden

---

From: Bob Hinden <[email-masked]>
Date: Fri, 7 Jul 2006 11:17:30 -0700

Jim,

> disagree and see what consensus will be.

Instead of deciding what disclaimers should be in non-IETF standard  
track document, I think it would be better to put a big label in the  
standards track RFCs.  For example (hope it makes it through the  
email systems):

IIIII EEEEEEE TTTTTTT FFFFFFF
  III  EE        TTT   FF
  III  EEEEE     TTT   FFFF
  III  EE        TTT   FF
IIIII EEEEEEE   TTT   FF

  SSSSS  TTTTTTT   AAA   NN   NN DDDDD     AAA   RRRRRR  DDDDD
SS        TTT    AAAAA  NNN  NN DD  DD   AAAAA  RR   RR DD  DD
  SSSSS    TTT   AA   AA NN N NN DD   DD AA   AA RRRRRR  DD   DD
      SS   TTT   AAAAAAA NN  NNN DD   DD AAAAAAA RR  RR  DD   DD
  SSSSS    TTT   AA   AA NN   NN DDDDDD  AA   AA RR   RR DDDDDD

We may not want to use ASCII art, but we could make the labeling of  
standards track RFCs a lot clearer than they are now.  This approach  
seems a lot better to me than trying to craft disclaimers.

Bob

p.s. ASCII art produced at http://www.network-science.de/ascii/ .

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 7 Jul 2006 23:11:49 -0400

Agree strongly on the courts that is actually a very good idea.

Also good point on adding IETF statements that did not have time for
consensus that is good vision to John.

I am just very nervous on this one as use said it is done now with IDs
even.

I consider any who do this quite dishonorable.

Best,
/jim 

> Sent: Friday, July 07, 2006 10:52 AM
> To: Bound, Jim; Stewart Bryant
> Subject: RE: [INDEP] Issues in draft-klensin-rfc-independent-02.txt
> 
> 
> 
> > John, understand about the historical perspective.  But the bottom 
> > line is vendors have used IETF publications that are not standards 
> > tracked in a not optimal fashion in the market.
> > I still strongly support a simple disclosure of what the 
> paper is to 
> > the RFC process as required boiler plate in the document.  Not sure 
> > but we may simply have to agree to disagree and see what consensus 
> > will be.
> 
> Yes.  
> 
> * Some of the same vendors have claimed, or implied, that 
> I-Ds submitted for consideration by WGs, or even I-Ds they 
> are considering submitting to a WG, are IETF standards.  The 
> remedy for those problems is not, IMO, more boilerplate but a 
> willingness in the community to call out deliberately 
> fraudulent behavior in the courts if that is needed.  So far, 
> no one has chosen to do that at least as far as I know.
> 
> boilerplate is appropriate in this case, I want that 
> boilerplate to be true.  IMO, we put ourselves at far more 
> risk in the marketplace by publishing claims about IETF 
> beliefs that have not been validated by normal IETF process 
> than we could save ourselves by pushing back on an extra case 
> of document misuse by hyperbolic language.
> 
>       john
> 
>

---

From: John C Klensin <[email-masked]>
Date: Fri, 07 Jul 2006 23:16:15 -0400

--On Friday, 07 July, 2006 23:11 -0400 "Bound, Jim"
<[email-masked]> wrote:

> Also good point on adding IETF statements that did not have
> time for consensus that is good vision to John.
> 
> I am just very nervous on this one as use said it is done now
> with IDs even.
> 

We are in violent agreement on the last point at least.

    john

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 7 Jul 2006 23:17:47 -0400

I agree with Stewart.  XFC sounds good?
/jim 

> From: Stewart Bryant [mailto:[email-masked]] 
> Sent: Friday, July 07, 2006 12:07 PM
> To: Joel M. Halpern
> Cc: [email-masked]
> Perhaps the simplest approach is to use a different series 
> designator for non-IETF output.  For example IETF process == 
> RFC, non-IETF == XFC or somesuch.
> 
> My concern is that no matter what goes in the boilerplate 
> most readers regard RFC as synonymous with the output of the 
> IETF standards process.
> 
> - Stewart
> 
> >
> >>> marketing departments of vendors claiming papers have 
> IETF consensus 
> the part of the IETF.

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 7 Jul 2006 23:29:11 -0400

This works for me too and as Dave O. stated too.  We need something
though me thinks or it could get more ugly than in the past with IDs.  I
am in consortia working on military and first responder wireless network
deployments 3-5 years out and have seen proprietary vendor solutions for
layer 2 to layer 3 want to claim a standard without even coming to any
SDO.  They could send in their archtitecture to this IND series get an
RFC and that will permit them to wiggle word how they are working with
the IETF.  Clearly folks that work in our community or even indirectly
with standards or even info RFC that had working group discussion will
know the truth.  But Exec Councils and Advisory Councils of CTOs, High
Ranking Military personnel, or SVPs/CEOs as advisor may not when they
see the marketing glossy that RFC mumbo jumbo is being worked in the
IETF.  Of course folks from here and other places will go fix it but
doing something I suggest will save a lot of us a lot of work or a way
to clearly respond that note this is XFC series or this is not the same
as the Dave O. new RFC series or it does not have Bob H. ascii art.

I think we have enough senior long time folks here speaking up it is at
least worth a bit more discussion and pause.

/jim 

> From: Bob Hinden [mailto:[email-masked]] 
> Sent: Friday, July 07, 2006 2:18 PM
> To: Bound, Jim
> Cc: John C Klensin; Olaf M. Kolkman; [email-masked]; 
> Stewart Bryant
> > tracked in a not optimal fashion in the market.  I still strongly 
> > support a simple disclosure of what the paper is to the RFC 
> process as 
> > required boiler plate in the document.  Not sure but we may simply 
> > have to agree to disagree and see what consensus will be.
> 
> Instead of deciding what disclaimers should be in non-IETF 
> standard track document, I think it would be better to put a 
> big label in the standards track RFCs.  For example (hope it 
> makes it through the email systems):
> 
> We may not want to use ASCII art, but we could make the 
> labeling of standards track RFCs a lot clearer than they are 
> now.  This approach seems a lot better to me than trying to 
> craft disclaimers.
> 
> Bob
>

---

From: David R Oran <[email-masked]>
Date: Sat, 8 Jul 2006 19:03:52 -0400

On Jul 7, 2006, at 2:20 PM, Bob Braden wrote:

>
>
>
>
>> The only solution that I think really works is to put IETF  
>> standards- track (and possibly experimental) documents in a  
>> different document
> Did I hear you say, "ISD"?  If so, I agree.
I'm saying something that appears in the first-class identifier by  
which the document is retrieved and cited, and which means "this  
something which is on the IETF standards track".

> But if you are just changing the
I'm not sure I understand you here, so Iet me ask what you mean by  
"just changing the series name". The underlying difficulty is that  
all the citations look the same - if you say "RFCmumble" it could be  
anything. We have BCPmumble, but do we have PSmumble, DSmumble,  
ISmumble? And do those things *not* have an alternative designation  
RFCmumble? As long as they do, I think the abuse will continue.

If I'm in left field here, be gentle.

Dave.

>>>>>> very

---

From: Leslie Daigle <[email-masked]>
Date: Sun, 09 Jul 2006 10:27:43 -0400

All,

This is an interesting discussion -- but, to be clear, it (and any
apparent conclusions) are not in scope for the discussion of
how to do the approval of non-IETF, independent submissions to the
RFC series.

Because, as *has* been noted at various points in this thread,
there are a lot of sharp edges and potential for unintended consequences
in relabelling.

Furthermore, relabelling of *IETF* stream documents would need
to be discussed within the IETF (e.g., NEWTRK).

Leslie.

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Jul 2006 10:33:37 -0700

This is silly; will you include statements that these docs have not bee
reviewed by the IEEE, ACM, IFIP, etc?

The only docs the IETF reviews are the ones it states it reviews.

There are too many previous independent submissions that lack a
disclaimer of IETF involvement (including those that predate the IETF).
It is the IETF that is borrowing the RFC submission process, not the
other way around.

The IETF has no business including text in an individual submission -
EVER. If that's unacceptable, I suggest the IETF create _ITS OWN_ series
of documents to do with as it wants.

Joe