I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the
document's authors for their information and to allow them to address
any issues
I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the
document's authors for their information and to allow them to address
any issues
I therefore request that these inappropriate changes in terminology
be backed out again. Port number obfuscation is a serious
misnomer; port numbers still are transmitted in the clear under the
methods presented in this draft; so port number randomization or,
for short, port
Mitchell-
The SHOULD type terminology is
what I thought is standard.
This is not a protocol spec. Such language is a little fuzzy in
documents that are not specs. Unless folks loudly and broadly complain
it seems to me that the language in the current document has been agreed
For other guidelines, i.e., (2), (5), (6), and (7), the author
must perform the suggested evaluations and provide recommended
analysis. Evidence that
the proposed mechanism has significantly more problems than those of
TCP should be a cause for concern in approval
- two or more implimentations using a new alternate cc algorithm
could be used as interoperability against each other and another
cc algor..
- if possible, a Linux, xBSD, etc public reference should be
available,
This is part of the standards
(0) Differences with Congestion Control Principles [RFC2914]
Proposed congestion control mechanisms that do should include a
clear explanation of the deviations from [RFC2914].
Is that more clear?
Yes (though '..that do should..' seemed weird on the first read).
I
Pekka-
1) the document appears to be slightly inconsistent wrt. what it's
actually specifying, or there are nuances that may not be sufficiently
well articulated. The introduction speaks of ..evaluating suggested
CC algorithms that _significantly differ_ from the general CC
principles
Folks-
Recently I have noticed *a bunch* of work in the measurement
community on identifying the application that generated some flow by
watching the torrent of traffic. These techniques go beyond
port-based identification to look for traffic that - for whatever
reason - uses non-standard
(catching up)
From the ICAR review team page at
http://www.machshav.com/~icar/reviews/people/
one can observe that only two review requests were ever
submitted, and just one of these (a request submitted by me)
resulted in a review (by Bernard). The other requested
review, actually on Dave
in 2005 seems too aggressive to me.
That said, making other changes outlined in Carl's document (e.g., for
IT support) before 2006 seems perfectly reasonable if we can reach
consensus and get things going before then.
allman
--
Mark Allman -- ICIR -- http://www.icir.org/mallman
[Sorry if you see this announcement more than once.]
Folks-
The ICAR WG is soliciting reviewers for an early, cross-area review
experiment within the IETF. The goal of this effort is to get solid
review from a number of angles (security, internationalization,
transport, MIB know-how, etc.)
A couple bits to add to the discussion.
Michael Richardson:
The boxes that are responsible for 90% of the ICMP lossage were also
intolerant of the ECN options in TCP, and pretty much all TCP options in
general.
This is not quite right, IMO. In the past there have been problems with
The subject line, on the other hand, is just for people.
Book titles are for people, too. Does that mean that it's okay for a
bookseller or library to change the titles on books, in order to help
the consumer indentify where they came from?
Um, my library slaps a helpful identification
Keith-
Putting [foo] in the subject header is just another example of this
trend. Sure, it might be useful to people with dysfunctional MUAs,
and there are a lot of those people out there. There were once a lot
of people whose MUAs couldn't do reply all, too.
This is just wrong.
From
Hi folks!
In the past couple of years I have been critical of the IETF, the
IESG, the problem statement WG (to the point of wrongly popping off
and quitting the list in frustration), various ADs, etc., etc., etc.
After watching recent happenings I feel compelled to transmit a bit
of a thank
protocol
stuff should be negotiated, as well.)
allman
--
Mark Allman -- ICIR -- http://www.icir.org/mallman/
commands end up taking over in the future
then that's great and we can think about moving rfc2428 to historic
at that time. But, I think the key here is that, IMO, we should
*add*, not *replace*.
allman
--
Mark Allman -- ICIR -- http://www.icir.org/mallman/
: 2003-6-10
overdone?
allman
--
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/
the above is not the case.
allman
--
Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/
--
Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/
to watch a particular document.
allman
--
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/
? Or whatever... This seems like it should be left to
individuals to filter as they see fit.
(Unless we have some notion that this would lead to a non-trivial
savings to the secratariet.)
allman
---
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/
and that goes for pdf too, given that the irs uses it too :)
I'd like to see us accept HTML
Ugh. Do we have to do this whole thread **again**???
allman
---
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/
ething new) better than the
model where we try to develop TCPng (rework something old, make
sure it still works with the old stuff, etc.). This just seems
like The Way To Go at the transport layer to me.
allman
---
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/
25 matches
Mail list logo
