Subject: Re: [newtrk] Re: I-D ACTION:draft-rosenberg-mankin-newtrk-rfc-00. txt

From: "John Loughney" <[email-masked]>
Date: Thu, 11 Nov 2004 15:44:04 -0500

Hi Joe,
> FYI, Informational != non-IETF

Yes, I agree.

> E.g., what is a doc that is submitted as individual at the suggestion of 

> a WG, even after substantial WG (and IESG) review and editing? (e.g., 

> RFC-3884)

Anything that is any of the following
1) product of a wg
2) IETF last called
3) is sponsored by an AD,
4) comes from the IESG/IAB

I would consider an IETF document. Did IÂ leave anything out?

John
[email-masked] wrote:
> Aaron,
> 
> 
>>BCP92 specifies the following boilerplate added to 
independent
>>submissions.  Doesn't this make it clear "that something IS NOT 
an
>>IETF produced/reviewed document"?
> 
> 
> This is good, but I'd like to see an example. What is at the top of the 

> RFC header, and what is the entry in the RFC Index?
> 
> 4155 Aaron's Damn Good Protocol. A. Falk. Janary 2008. (Format: 
TXT=1043 bytes) (Status:
>      Non-IETF Submission)
> - and - 
> No Working Group                                                A. Falk 

> Request for Comments: 4155                                          
ISI
> Category: Non-IETF Submission
> 
> 
> 					Aaron's Damn Good Protocol
> 
> blah, blah, blah ....
> 
> .
> 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: Joe Touch <[email-masked]>
Date: Thu, 11 Nov 2004 13:09:32 -0800

> I would consider an IETF document. Did IÂ leave anything out?

You didn't address the case for 3884, though that just argues that more 
docs will end up going through the IETF process offically than now, if 
this moves forward.

Joe

---

From: John C Klensin <[email-masked]>
Date: Sun, 14 Nov 2004 14:51:52 -0500

>...
> You didn't address the case for 3884, though that just argues
> that more docs will end up going through the IETF process
> offically than now, if this moves forward.

Independent of the other issues raised about this approach,
including the ones about the futility of trying to change the
definition of a "brand" mid-series (see below), "more docs will
end up going through the IETF process" implies, I think
(apologies in advance for the sarcasm in the second point -- I
don't know how else to make it).

	* More Last Calls, with perhaps proportionate (or worse)
	reduction in the amount of time the community spends on
	each of them.
	
	* More work for the IESG whose members, as we all know,
	have so much free time on their own that the current
	workload moves swiftly through the process, leaving them
	sitting around waiting anxiously for the next document
	to arrive

If your "more documents" conclusion is correct, and my inference
about impact is also correct, then this proposed change will
actually be very expensive to our allegedly primary goal of
efficiently producing high-quality standards in a timely manner.
Hence we'd better be _really_ sure that it would accomplish its
purpose and that its purpose is valuable before agreeing to move
forward with it.

With regard to the rebranding issue, I should repeat here a
comment I made in a discussion just after the BOF.  My apologies
for overlapping some comments that have been made already.  In
terms of the practical impact of this proposal if adopted, we
should, I think, understand that much of the audience is pretty
lazy.  If they were not, we wouldn't have problems with
Informational or Experimental documents being confused with
Standards Track ones, independent of where the former came from.
That implies that only very simple solutions and distinctions
have any hope of working.  If we say "well, any RFC with a
number about NNNN is an IETF document, but, if the number is
earlier, then one needs to try to deduce something from the
document, find a protocol action notice, etc.", then we will,
IMO, lose it before we start.  Starting over with new names
might do it, but a complicated rule just won't.  And I'd also
note that "Internet Standards are documented in ISDs, no ISD, no
standard" is a clear rule, one in which "having an RFC number
means that something was published as an RFC, but communicates
no information about status" is complementary.

Remember that those who want to deliberately mislead tell their
audiences that information specs (whether processed by the IETF
or not) are IETF standards, that I-Ds are pending IETF standards
(or "being standardized in the IETF"), and that I-Ds they are
considering posting are "submitted to the IETF for
standardization".

If we want to fix those problems, we need to try to do what Bell
Labs tried to do with UNIX -- take out a trade or service mark
on a term that would qualify for that designation ("RFC" almost
certainly would not) and then be prepared to take legal action
against anyone who misused the new term until people stopped.  I
don't think we want to go there, and note that Bell Labs, even
with AT&Ts lawyer collection, couldn't quite pull it off for
long.

   john

.

---

From: Joe Touch <[email-masked]>
Date: Mon, 15 Nov 2004 11:07:30 -0800

John C Klensin wrote:
...
> with AT&Ts lawyer collection, couldn't quite pull it off for

This seems clear, and was one of my first points: short of an 
enforcement mechanism, as noted above, there's little utility in 
reacting to misrepresentation of the IETF standards process.

I see substantial utility to the revision/updating of the STD series to 
be more useful to the community that is willing to use it appropriately, 
however. I.e., I don't see the above as precluding the ISD discussion.

Joe