Subject: Re: I-D Action:draft-white-tsvwg-netblt-00.txt

From: John C Klensin <[email-masked]>
Date: Tue, 11 Jan 2011 04:09:29 -0500

--On Saturday, January 08, 2011 07:37 -0800 Lixia Zhang
<[email-masked]> wrote:

> I am not sure why this rush to get a new internet draft out,
> without consultation to any of its original authors, and given
> the rough consensus on ietf mailing list discussion is to keep
> NETBLT RFC as is (experimental).  

Lixia,

I'm not sure there is any rush.  I'm also not sure that the
effort that is going into this could not be better spent in
other ways.  I'm also not sure about the opposite of either -- I
actually don't have a strong opinion one way or the other.

However, it seems to me that...

(i) It has been a very long time since we published
specifications that might now be considered Experimental with
disclaimers that said, more or less, "don't even think about
implementing this without a discussion with, and maybe
permission from, the author".  If a spec is published as
Experimental, then people are assumed to be free, modulo any IPR
issues, to implement and test it.

(ii) To the extent to which it is worthwhile publishing
Experimental specifications at all, it is worthwhile (at least
if anyone is willing to do that work) to publish experimental
results, reports on implementations, and other things from which
the community might learn.  When I looked at White's original
spec a week or two ago, it appeared to be, in most respects,
just an implementation and deployment report that pointed to a
modified version of NETBLT that was then in important use.   As
of that time, White didn't know whether it was still in use or
not.  I certainly don't know.

(iii)  Despite (i), I think there may be a legitimate complaint
(at least about bad judgment) if those who created and specified
a variant of the original spec for a particular set of
applications did not consult the original authors while doing
so.   But that complaint is probably irrelevant at this late
date and, in any event, is about the behavior of various folks
whose identities I can't discern from the documentation I've
seen and not about Mykyta's behavior or even that of John While.

(iv) If you have concluded, based on your own work, what you
understand of the implications of the work While summarized, or
for other reasons what people should not be encouraged to
implement and experiment with NETBLT, then it seems to me
entirely reasonable to publish White's document and whatever
discussion you think it appropriate to provide (either as part
of that document or separately), and to do so as immediately
Historic, taking the original spec with it.

Again, I think it is an open question whether any of this is
worth the effort.  I could say the same thing for an extended
discussion of the subject on the IETF list.   But it seems clear
to me that, if the effort is going to be invested, it would be
more worthwhile to spend it documenting the status, history, and
strengths and weaknesses of the idea in a permanent form than in
having an extended conversation about procedures, modes of
consultation, etc.

Just my opinion as usual.
     best regards,
      john

---

From: Lixia Zhang <[email-masked]>
Date: Sat, 15 Jan 2011 20:21:51 -0800

> issues, to implement and test it.

Hi John,

I could see that my earlier msg could be read in a wrong way.
The reason for contacting original authors is to find out what are the things that they know about the protocol (that were not mentioned in the specification), so one can either save the time to reinvent the wheel or even overlook problems/solutions that were discovered earlier.  As I said in my earlier msg (http://www6.ietf.org/mail-archive/web/ietf/current/msg65063.html),

.......
unless there is clearly identified need for a protocol like NETBLT (as its name suggested, it is a specialized protocol for bulk data transfer only), I do not see the need to move NETBLT to standard.

In case such a need is identified, personally I think we need a clear problem statement first, so that we better understand the context the protocol will be applied to.  We (the MIT crew at the time) did various trials of NETBLT after the RFC998's publication, and collected a list of issues for further investigation.

For example, one issue I can still recall clearly is NETBLT's congestion control design and the interaction with TCP traffic (I cannot recall the whole list on top of my head now after all these years, though there may still be old notes around).

But I would like to pop up a level here: this thread started with a notion that rfc2026 was wrong regarding experimental rfcs so actions are taken now to do something with these rfcs.  I agree with Bob's comment that (http://www6.ietf.org/mail-archive/web/ietf/current/msg65072.html),
Hi,
> > I think that the author of RFC2026 was wrong while writing the definition of Historic status. This document says that Historic should be assigned only to that documents that were standards and now are obsolete. But why do we need such narrow definition? Non-standards RFCs are not made Historic while obsoleting, according to 2026. Moreover, such status will just duplicate the obsoleted-by one. When there will be the attempt to revise RFC 2026, we should put there that Historic status is to be assigned to that documents that are considered to be deprecated. I fully share the opinion of Doug here.

If you think RFC20206 is wrong, then propose changes to it and see if people agree with the changes.  Until it is changed, IMHO you should not propose actions based on what you as an individual think is incorrect.  There needs to be a community consensus that RFC2026 is wrong before any action should be taken.

Bob

Lixia