On Jan 11, 2011, at 1:09 AM, John C Klensin wrote:
--On Saturday, January 08, 2011 07:37 -0800 Lixia Zhang
<lixia(_at_)cs(_dot_)ucla(_dot_)edu> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf