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

[Lixia Zhang <lixia@xxxxxxxxxxx>]

On Jan 11, 2011, at 1:09 AM, John C Klensin wrote:

--On Saturday, January 08, 2011 07:37 -0800 Lixia Zhang
<lixia@xxxxxxxxxxx> 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.

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

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf