On 6/18/2012 5:09 AM, Masataka Ohta wrote:
Joe Touch wrote:
draft-generic-v6ops-tunmtu-03.txt
to fragment IPv6 packets by intermediate routers should be
very interesting to you.
It is aware of our IPv4-ID doc, and consistent with it.
What?
I looked more closely, and the doc
Hi, all,
There had been some talk of gathering experience at IETF meetings
running WIFI, and I'm not sure it went anywhere.
Although this might not be appropriate for an RFC, I'm hoping to gather
some relevant advice to put on a webpage that could be useful for future
IETF meetings, as well
On 6/18/2012 3:30 AM, Alessandro Vesely wrote:
...
I noticed no disagreement between method and mechanism, at the
time. In retrospect, those two terms might seem to allude to a
different depth of semantic explanations. Rereading that thread, I
find that the same ambiguity holds for algorithm
On Jun 15, 2012, at 11:50 PM, Masataka Ohta wrote:
Joe Touch wrote:
Again, this document doesn't change the current situation. Operators who
clear the DF bit are not innocent - they need to override a default
setting. They are active participants. They ARE guilty of violating
existing
On Jun 15, 2012, at 10:54 PM, Masataka Ohta wrote:
Joe Touch wrote:
That is not an innocent action.
It is a fair action by innocent providers.
It is a violation of standards. They may do it innocently, but it's
still a violation.
You misunderstand standardization processes
Masataka,
On 6/15/2012 3:48 AM, Masataka Ohta wrote:
After thinking more about the draft, I think it is
purposelessly hostile against innocent operators and
end users who are suffering between people filtering
ICMP and people insisting on PMTUD.
Today, innocent operators often clear DF bit
Hi, Masataka,
On 6/15/2012 5:01 AM, Masataka Ohta wrote:
Joe Touch wrote:
Hi,
Hi,
But, then,
Sources emitting non-atomic datagrams MUST NOT repeat IPv4 ID
values within one MSL for a given source address/destination
address/protocol triple.
makes most
Masataka,
On 6/15/2012 6:54 PM, Masataka Ohta wrote:
Joe Touch wrote:
After thinking more about the draft, I think it is
purposelessly hostile against innocent operators and
end users who are suffering between people filtering
ICMP and people insisting on PMTUD.
Today, innocent operators
Hi, all,
On 6/2/2012 9:21 PM, C. M. Heard wrote:
On Sat, 2 Jun 2012, Joe Touch wrote:
Hi, Eliot,
On Jun 2, 2012, at 6:00 AM, Eliot Lear wrote:
Document: draft-ietf-intarea-ipv4-id-update-05
Title: Updated Specification of the IPv4 ID Field
Reviewer: Eliot Lear
Review Date: 2 June 2012
IETF
On 6/2/2012 10:00 PM, C. M. Heard wrote:
On Sun, 3 Jun 2012, Glen Zorn wrote:
On Sat, 2012-06-02 at 21:21 -0700, C. M. Heard wrote:
...
In Section 6.1:
Datagram de-duplication can be accomplished using hash-based
duplicate detection for cases where the ID field is absent.
Kuari wrote:
On Jun 3, 2012, at 12:34 AM, C. M. Heard wrote:
On Sat, 2 Jun 2012, Masataka Ohta wrote:
Existing routers, which was relying on ID uniqueness of atomic
packets, are now broken when they fragment the atomic packets.
Such routers were always broken. An atomic packet has DF=0 and
Hi,
On 6/3/2012 12:12 PM, Masataka Ohta wrote:
C. M. Heard wrote:
Existing routers, which was relying on ID uniqueness of atomic
packets, are now broken when they fragment the atomic packets.
Such routers were always broken. An atomic packet has DF=0 and any
router fragmenting such a
Some further points...
On 6/1/2012 7:45 PM, Masataka Ohta wrote:
Joe Touch wrote:
Existing routers, which was relying on ID uniqueness of atomic
packets, are now broken when they fragment the atomic packets.
The recommendation in this doc - that such sources MUST rate-limit
Hi, Eliot,
On Jun 2, 2012, at 6:00 AM, Eliot Lear wrote:
Document: draft-ietf-intarea-ipv4-id-update-05
Title: Updated Specification of the IPv4 ID Field
Reviewer: Eliot Lear
Review Date: 2 June 2012
IETF Last Call Date: 31 May 2012
Summary: This draft is quite well written, and is
On 6/1/2012 5:03 PM, Masataka Ohta wrote:
C. M. Heard wrote:
My one reservation is that I do not think it is strictly necessary
to ban re-use of the IPv4 ID value in retransmitted non-atomic IPv4
datagrams.
Do you mean
Sources of non-atomic IPv4 datagrams MUST rate-limit their
On May 8, 2012, at 7:09 PM, Paul Wouters wrote:
On Tue, 8 May 2012, Bob Hinden wrote:
https://www.facebook.com/jon.postel
I just tried going to this page and it says it doesn't exist. Has the
problem been fixed?
Yes it has.
Many thanks to those on this list - and other lists - who
Hi, all,
My apologies for contacting this list with a non-IETF issue, but since
this community knew Jon well, I'm asking for its help (among others).
---
There is a Facebook page that falsely implies being owned by Jon Postel:
https://www.facebook.com/jon.postel
Facebook has declined
On 5/8/2012 4:35 PM, Fred Baker wrote:
question:
would it be helpful to report or block the page?
I and Jon's family have tried, to no avail thus far.
Joe
On May 8, 2012, at 6:19 PM, Joe Touch wrote:
Hi, all,
My apologies for contacting this list with a non-IETF issue, but since
Hi, Kim,
On 2/23/2012 10:57 AM, Kim Kinnear wrote:
Joe,
There were two things that I referenced in response to your initial
review that you hadn't seen. More details on those below:
On Feb 17, 2012, at 5:47 PM, Joe Touch wrote:
INTERLEAVING
path.
3. The ? issues remaining, below. I think that
the number could be 0, but probably not.
Regards -- Kim
On Feb 17, 2012, at 5:47 PM, Joe Touch wrote:
Hi, Kim,
First, thank you for your detailed response to my quite lengthy review.
Some further clarifications and confirmations
Hi, Ralph,
On 2/18/2012 4:39 AM, Ralph Droms wrote:
Joe, Kim...
On Feb 17, 2012, at 5:47 PM 2/17/12, Joe Touch wrote:
Hi, Kim,
First, thank you for your detailed response to my quite lengthy review.
Some further clarifications and confirmations appear below.
Joe
On 2/17/2012 12:09 PM
Hi, Ted,
On 2/18/2012 7:29 AM, Ted Lemon wrote:
On Feb 17, 2012, at 5:47 PM, Joe Touch wrote:
Thanks. In this case, it's important to suggest why others should not
add conventional DHCP query support to the TCP port.
The idea of doing DHCP stateful autoconfiguration over TCP is
nonsensical
On 2/24/2012 7:35 PM, Ted Lemon wrote:
On Feb 24, 2012, at 7:39 PM, Joe Touch to...@isi.edu
mailto:to...@isi.edu wrote:
OK, so although I disagree that this is the correct procedure, if it's
typical for DHCP then that's reasonable.
So just to be clear here, it seems that you are withdrawing
Hi, Kim,
First, thank you for your detailed response to my quite lengthy review.
Some further clarifications and confirmations appear below.
Joe
On 2/17/2012 12:09 PM, Kim Kinnear wrote:
Joe,
Thank you for your review.
My responses are indented, below...
On Feb 13, 2012, at 5:00 PM, Joe
Hi, Kim,
On 2/17/2012 12:22 PM, Kim Kinnear wrote:
On Feb 13, 2012, at 5:16 PM, Joe Touch wrote:
Hi, all,
One additional transport suggestion:
- it would be useful to include recommended configurations for TCP
connections. Given these are multi-byte request/response exchanges,
Nagle should
Hi, all,
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
Hi, all,
One additional transport suggestion:
- it would be useful to include recommended configurations for TCP
connections. Given these are multi-byte request/response exchanges,
Nagle should be disabled, e.g.
Joe
On 2/13/2012 2:00 PM, Joe Touch wrote:
Hi, all,
I've reviewed
On 1/3/2012 5:53 PM, Kaushal Shriyan wrote:
Hi,
Can someone please explain me the term Protocol. Does it also mean it
has some software code underlying beneath it. Please help me understand.
My 2 cents:
A protocol is a defined set of rules that function at multiple locations
Hi, all,
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
Hi, all,
Again, thanks for the suggestions.
I'll work with IANA to see if we can make things a bit more useful.
Joe
On 10/13/2011 12:28 PM, Joel jaeggli wrote:
On 10/13/11 03:41 , t.petch wrote:
Joe
When I access it, I see a 3.08Mbyte .xml file in temporary storage.
Interestingly, the text
Updating the subject line to address a separate question that was raised:
FWIW, it's 1 MB of data in a 3.8 MB XML file.
I suspect that the delay is because it may be generated on-the-fly, but
haven't been able to confirm that. It may just be network transfer delay.
Joe
On 10/10/2011 2:23
On 10/12/2011 10:58 AM, Simon Perreault wrote:
On 2011-10-12 13:44, Joe Touch wrote:
Emperically:
opening the file from disk = 30 seconds
downloading the file from the net = 33 seconds
I.e., they're both part of the problem.
Turning on gzip transfer encoding in the web server config
Hi, all,
The IANA considerations in this doc are in error and need updating as
follows. I agree that PORT is a poor acronym choice, FWIW.
Joe
11. IANA Considerations
This specification makes use of a TCP port number and a SCTP port
number for the use of PIM-Over-Reliable-Transport
Hi, all,
Please consider responding to the following survey, even if you did NOT
attend*.
Joe
*-
The following survey includes the opportunity to indicate did not
attend, and to explain why.
It was originally sent to the 81all list, which is a bit preaching to
the choir (though it
On 9/20/2011 10:09 AM, Melinda Shore wrote:
On 9/20/11 8:53 AM, Joe Touch wrote:
Please consider responding to the following survey, even if you did NOT
attend*.
So, I'm looking at the results and see that -9 people skipped
the birth year question. That seems kind of unlikely to me
Hi, Nico,
On Sep 12, 2011, at 5:56 PM, Nico Williams n...@cryptonector.com wrote:
On Mon, Sep 12, 2011 at 5:30 PM, Joe Touch to...@isi.edu wrote:
On 9/12/2011 2:43 PM, Nico Williams wrote:
On Mon, Sep 12, 2011 at 3:57 PM, Joe Touchto...@isi.edu wrote:
My claim is that:
SRVs
On Sep 12, 2011, at 8:09 PM, Keith Moore mo...@network-heretics.com wrote:
...
SRV indicates the port number (useful if not the default) and weight, etc.
right. but given that you can include the same things in a TXT record, if
you have to query for TXT RRs anyway, what's the value added
Hi, Craig,
On Sep 13, 2011, at 5:58 AM, Everhart, Craig craig.everh...@netapp.com
wrote:
Hi,
Thanks, Joe, for the thoughtful review.
Extracting some light from yesterday's discussion and RFCs 6335 and
2782, much of the contention seems to be around whether there could be
two assigned
On Sep 13, 2011, at 7:38 AM, Cullen Jennings flu...@cisco.com wrote:
Hi Rob,
Few inputs you can take with a huge grain of salt
1) some people on this list have suggest TXT records. Keep in mind this is
totally the wrong group to tell you how to use DNS. Last time I discussed TXT
On 9/13/2011 1:12 AM, t.petch wrote:
I believe that this is the first Last Call since RFC6335 was published to
request an entry in the Service Name and Transport Protocol Port Number Registry
and so a chance to understand how the RFC works in practice.
From the proforma in s.8.1.1., I was
On 9/11/2011 11:32 PM, Keith Moore wrote:
On Sep 11, 2011, at 6:23 PM, Joe Touch wrote:
On Sep 11, 2011, at 2:09 PM, Keith Moore wrote:
On Sep 11, 2011, at 4:46 PM, Joe Touch wrote:
We've been discussing this in the Transport area lately.
DNS SRVs are defined in RFC 2782 as I have
Hi, Nico,
On 9/12/2011 8:03 AM, Nico Williams wrote:
I disagree w.r.t. your comments regarding the use of SRV RRs for NFSv4
domain root location.
I think it would be a mistake to use TXT RRs to encode what SRV RR
RDATA does just fine just to get around whatever we think the rules
are or ought
Hi, Keith,
On 9/12/2011 10:47 AM, Keith Moore wrote:
...
I'm not looking for anything in particular. I just don't see any
justification for insisting that SRV records always be used with RFC
2782 style labels.
I have provided two:
1) that's the current standard (i.e., changing it
Hi, Nico,
On 9/12/2011 10:49 AM, Nico Williams wrote:
On Mon, Sep 12, 2011 at 12:39 PM, Joe Touchto...@isi.edu wrote:
On 9/12/2011 8:03 AM, Nico Williams wrote:
You're locating the NFS service. You're using that to setup a domainroot.
The former is a DNS SRV issue. The latter is an endhost
On 9/12/2011 11:41 AM, Keith Moore wrote:
I think at this point we're just talking past each other, but I
simply disagree with your assertion that RFC 2782 should be taken as
a prohibition on using SRV RRs in any way other than defined in RFC
2782.
It might be useful to explain to this list
On 9/12/2011 11:46 AM, Keith Moore wrote:
On Sep 12, 2011, at 2:31 PM, Joe Touch wrote:
The issue is that if this document wants to go outside the spec, *it*
needs to update RFC2782 - and survive the discussion that will incur.
Well, in a pedantic sense I'm sure that's true. But it doesn't
Hi, Robert,
On 9/12/2011 12:00 PM, Robert Thurlow wrote:
Joe Touch wrote:
Either this is an nfs service or it isn't.
If it is, then it should be using _nfs._tcp.example.com, etc. If it
isn't, then:
a) a new service name is required
which then *requires*
b) a new port number be assigned
Hi, Nico,
On 9/12/2011 1:00 PM, Nico Williams wrote:
On Mon, Sep 12, 2011 at 2:56 PM, Joe Touchto...@isi.edu wrote:
On 9/12/2011 12:00 PM, Robert Thurlow wrote:
Joe Touch wrote:
We don't want to enumerate all NFS servers in a domain.
That's what SRV records do. If that's not what you want
On 9/12/2011 1:15 PM, Keith Moore wrote:
On Sep 12, 2011, at 3:50 PM, Joe Touch wrote:
On 9/12/2011 11:41 AM, Keith Moore wrote:
I think at this point we're just talking past each other, but I
simply disagree with your assertion that RFC 2782 should be taken as
a prohibition on using SRV
On 9/12/2011 1:17 PM, Nico Williams wrote:
On Mon, Sep 12, 2011 at 3:08 PM, Joe Touchto...@isi.edu wrote:
On 9/12/2011 1:00 PM, Nico Williams wrote:
On Mon, Sep 12, 2011 at 2:56 PM, Joe Touchto...@isi.eduwrote:
On 9/12/2011 12:00 PM, Robert Thurlow wrote:
No We don't want to
On 9/12/2011 1:20 PM, Keith Moore wrote:
On Sep 12, 2011, at 3:50 PM, Joe Touch wrote:
On 9/12/2011 11:46 AM, Keith Moore wrote:
On Sep 12, 2011, at 2:31 PM, Joe Touch wrote:
The issue is that if this document wants to go outside the
spec, *it* needs to update RFC2782 - and survive
On 9/12/2011 1:23 PM, Nico Williams wrote:
On Mon, Sep 12, 2011 at 3:15 PM, Keith Mooremo...@network-heretics.com wrote:
On Sep 12, 2011, at 3:50 PM, Joe Touch wrote:
I think RFC 2782 inappropriately specified SRV RRs by defining both the label
syntax and the RDATA syntax at the same time
Hi, Keith,
On 9/12/2011 1:42 PM, Keith Moore wrote:
On Sep 12, 2011, at 4:22 PM, Joe Touch wrote:
On 9/12/2011 1:15 PM, Keith Moore wrote:
On Sep 12, 2011, at 3:50 PM, Joe Touch wrote:
On 9/12/2011 11:41 AM, Keith Moore wrote:
I think at this point we're just talking past each other
On 9/12/2011 2:39 PM, Keith Moore wrote:
On Sep 12, 2011, at 4:57 PM, Joe Touch wrote:
Most RRs tie some set of data to a domain name which is historically
a host name, though in recent years it's become a somewhat more
nebulous concept (e.g. a collection of services, or in the case of
MX
On 9/12/2011 2:43 PM, Nico Williams wrote:
On Mon, Sep 12, 2011 at 3:57 PM, Joe Touchto...@isi.edu wrote:
My claim is that:
SRVs represent services as they are currently assigned by IANA
a new RR could be useful for things that aren't sufficiently
expressible in the
On 9/3/2011 7:14 AM, Noel Chiappa wrote:
On Tue, 30 Aug 2011, Martin Sustrik wrote:
For an implementor it's often pretty hard to decide whether to
implement functionality marked as SHOULD given that he has zero context
and no idea whether the reason he has for not
On 9/12/2011 3:33 PM, Spencer Shepler wrote:
...
The existence proof is that many SRV names have defined TXT fields,
including the following:
ftp
sftp-ssh
ssh
telnet
http
nfs (already defines path to the mount point)
Interesting; do you have a
On 9/12/2011 3:49 PM, Keith Moore wrote:
On Sep 12, 2011, at 6:23 PM, Joe Touch wrote:
Again I'm confused.
You claim there's a clear need to revise SRV syntax, but not the registry that
basically defines that syntax?
I don't claim that there's a clear need to revise the syntax
Hi, all,
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
(and
use of TXTs for additional info) cannot do that you want?
Joe
On Sep 11, 2011, at 4:12 PM, Joe Touch wrote:
Hi, all,
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
On Sep 11, 2011, at 2:09 PM, Keith Moore wrote:
On Sep 11, 2011, at 4:46 PM, Joe Touch wrote:
We've been discussing this in the Transport area lately.
DNS SRVs are defined in RFC 2782 as I have described. Additional info is
passed in TXT records for current DNS SRVs.
I.e. what I
Not all IDs are discussed at the upcoming IETF. It is inconvenient to
need to delay an update or new submission simply because there's an IETF
coming up.
And all I've seen the deadline accomplish is that people post non-posted
updates on local websites for discussion anyway.
Unless there's
On 7/23/2011 3:13 AM, Mykyta Yevstifeyev wrote:
Hello,
The new registry says:
System Ports are assigned by IETF
process for standards-track protocols, as per [RFC1340]. User Ports
are assigned by IANA using the Expert Review process, as per
[RFC5226]. Dynamic Ports are not
are exchanged, not the messages themselves (e.g., as would be
the case with signed BGP routes), this is a crucial issue to make clear
and precise in this doc.
Joe
On 7/12/2011 8:26 PM, Joe Touch wrote:
On 7/12/2011 3:36 PM, Stewart Bryant wrote:
On 12/07/2011 23:23, Joe Touch wrote:
Hi, Joel
On 7/13/2011 11:34 AM, Joel M. Halpern wrote:
As I said in my earlier note proposing responses to Joe, we would be
happy to some text in the front clarifying the usage. Quoting from my
earlier email:
This text would note that it is a widely used term in IETF documents,
including many RFCs. It
Hi, Joel,
On 7/13/2011 1:44 PM, Joel M. Halpern wrote:
Sorry, I apparently missed part of your earlier note.
Would text like:
This document uses the term on-the-wire to talk about the information
used by routing systems. This term is widely used in IETF RFCs,but is
used in several different
than stating it clearly and explicitly.
Joe
Yours,
Joel
On 7/13/2011 2:58 PM, Joe Touch wrote:
On 7/13/2011 11:34 AM, Joel M. Halpern wrote:
As I said in my earlier note proposing responses to Joe, we would be
happy to some text in the front clarifying the usage. Quoting from my
earlier
understand 4 as protecting the *channel*
over which routing messages are exchanged (which ends up protecting the
messages too), and 3 as focusing on the routing layer messages themselves.
Is that the case?
Joe
On 7/13/2011 5:08 PM, Joe Touch wrote:
Hi, Joel,
On 7/13/2011 1:58 PM, Joel M
be clear about this, please send text.
If we agree on the above, then I can proceed to document suggested
changes and the paragraph.
Joe
Yours,
Joel
On 7/13/2011 7:02 PM, Joe Touch wrote:
Hi, Joel,
On 7/13/2011 2:26 PM, Joel M. Halpern wrote:
You wording seems to induce confusion
Hi, Joel (et al.),
On 7/10/2011 7:10 AM, Joel Halpern wrote:
Joe,
THE KARP WG Chairs have reviewed your comments, in order to figure out
what the best way to address them. We would appreciate it if you could
engage in discussion of this proposal on the KARP working group email
list. If you feel
On 7/12/2011 3:36 PM, Stewart Bryant wrote:
On 12/07/2011 23:23, Joe Touch wrote:
Hi, Joel (et al.),
On 7/10/2011 7:10 AM, Joel Halpern wrote:
Joe,
THE KARP WG Chairs have reviewed your comments, in order to figure out
what the best way to address them. We would appreciate it if you could
On 7/5/2011 6:07 PM, Dave CROCKER wrote:
On 7/5/2011 3:12 PM, Joe Touch wrote:
The SRV record allows
DNS resolvers to search for particular applications and underlying
transports (for example, HTTP running over TLS, see [RFC2818]) and to
learn the domain name and port where that service
Hi, all,
This doc also claims that:
The SRV record allows
DNS resolvers to search for particular applications and underlying
transports (for example, HTTP running over TLS, see [RFC2818]) and to
learn the domain name and port where that service resides in a given
administrative
is sufficiently addressed in this doc, and
neither can be addressed in the absence of a clear discussion of the
different properties of L2, L3, and/or L4 as they impact routing
protocols over which they operate.
Joe
Yours,
Joel M. Halpern
On 6/30/2011 1:54 AM, Joe Touch wrote:
Hi, all,
I've
statement of scope is needed.
Joe
On 6/30/2011 9:52 AM, Joe Touch wrote:
Hi Joel,
On 6/30/2011 6:13 AM, Joel M. Halpern wrote:
I am conufsed by this review of the KARP design guidelines document.
My first reaction was that I had trouble understanding the general
points. However, when I looked
(resending cc'd to the KARP WG rather than SIDR; please respond to this
post instead)
Hi, all,
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
Hi, all,
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
Hi, all,
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
On 5/17/2011 8:27 AM, Cameron Byrne wrote:
On May 16, 2011 11:41 PM, sth...@nethelp.no mailto:sth...@nethelp.no
wrote:
How much longer does this list need to be to justify choosing
better labels for this v6 dual-stack transition hack?
returning different sets of resource records
On 5/11/2011 10:17 PM, SM wrote:
Hi Joe,
At 17:05 11-05-2011, Joe Touch wrote:
Paradoxically, I-Ds do already include a similar statement:
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can
On 5/12/2011 7:58 AM, Steven Bellovin wrote:
On May 12, 2011, at 10:41 58AM, John C Klensin wrote:
--On Wednesday, May 11, 2011 16:43 -0400 Steven Bellovin
s...@cs.columbia.edu wrote:
It is a lot more time (and money) saving to search free
versions before entering transactions to
PM, Joe Touch to...@isi.edu mailto:to...@isi.edu
wrote:
Hi, all,
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
Paradoxically, I-Ds do already include a similar statement:
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Pity we don't include
Hi, all,
Although this is a minor point, it's also easy to address:
On 5/4/2011 4:56 PM, Doug Barton wrote:
...
Meanwhile, the discussion about whether or not to call this
whitelisting is pointless. The term is already well-established.
That's true, but equally true that the terms for disk
Hi, all,
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
, I'd be glad to write it up - and keep
it short. I still expect that protocol designers are familiar with the
basics of protocols. ;-)
Joe
Eliot
On 3/30/11 8:09 PM, Bob Braden wrote:
+1
Bpb Braden
On 3/30/2011 1:11 AM, Joe Touch wrote:
Hi, all,
Perhaps we're not talking about an API
On 3/30/2011 5:11 AM, Brian E Carpenter wrote:
...
I find myself very torn on this proposal. Believe me, I understand the
workload issue. But on the other hand, at the very beginning of my
time as IETF Chair, I experienced the *previous* workload issue,
when there was no IASA, IAD or IAOC.
Hi, Brian,
On 3/30/2011 5:38 AM, Brian E Carpenter wrote:
On 2011-03-31 01:18, Joe Touch wrote:
On 3/30/2011 5:11 AM, Brian E Carpenter wrote:
...
I find myself very torn on this proposal. Believe me, I understand the
workload issue. But on the other hand, at the very beginning of my
time
Hi, all,
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
As one of the authors, I'm fine with this change too.
Joe
On 3/28/2011 5:46 AM, Lars Eggert wrote:
As one of the authors/editors, I am fine with this change. Thanks!
On 2011-3-28, at 14:14, Alexey Melnikov wrote:
After discussing this new text with IESG and some participants of the TSVWG, it
Regardless, we're already moving forward to make the identities public
(not sure if it's happening, or already happened).
Regardless, though, again, this is out of scope for this doc to address
in detail, IMO.
Joe
On 2/7/2011 1:24 PM, Chris Benson wrote:
Hi folks,
Sam Hartman wrote (and
On 2/3/2011 1:48 AM, Masataka Ohta wrote:
Joe Touch wrote:
9. ICMP
I quoted the start of the section. The first sentence, without further
qualification, is inaccurate, IMO.
...
ICMP messages do not themselves have port numbers, but they are intended
to *carry* port numbers
Hi, Fernando,
On 2/2/2011 12:03 AM, Fernando Gont wrote:
On 01/02/2011 10:35 p.m., Joe Touch wrote:
...
...
7. Geo-location and Geo-proximity
?INT? This section is, IMO, odd; IP address never meant physical
location anyway, and tunnels obviate that meaning regardless of the
impact of NATs
Hi, Tom,
Thanks - yes, I can see where reordering the sentences in that paragraph
could make the issue much clearer. I'll do that in the pending update ...
Joe
On 2/2/2011 3:22 AM, t.petch wrote:
- Original Message -
From: Joe Touchto...@isi.edu
To: Paul Hoffmanpaul.hoff...@vpnc.org
Hi, Jari,
Notes below...
Joe
On 2/1/2011 10:10 PM, Jari Arkko wrote:
...
- parallel connections
i.e., that assume that a single IP address used
for multiple connections implies a single machine,
as with striping, multipath, or systems that use
multiple concurrent connections for different
On 2/2/2011 1:55 PM, Masataka Ohta wrote:
Joe Touch wrote:
9. ICMP
ICMP does not carry any port information and is consequently
problematic for address sharing mechanisms.
ICMP messages are specifically intended to include enough of the
transport header to enable port demuxing at the end
On 2/2/2011 5:04 PM, Fernando Gont wrote:
...
At the least, it's worth noting that geolocation is already broken by
tunnels, and that IP addressing does not ensure geographic proximity
before attributing breakage on NATs or other sharing.
Tunnels need not break geo-location. -- They do not
On 2/2/2011 5:30 PM, Fernando Gont wrote:
On 02/02/2011 10:24 p.m., Fernando Gont wrote:
On 2/2/2011 5:04 PM, Fernando Gont wrote:
...
At the least, it's worth noting that geolocation is already broken by
tunnels, and that IP addressing does not ensure geographic proximity
before attributing
On 2/2/2011 5:24 PM, Fernando Gont wrote:
On 02/02/2011 10:08 p.m., Joe Touch wrote:
On 2/2/2011 5:04 PM, Fernando Gont wrote:
...
At the least, it's worth noting that geolocation is already broken by
tunnels, and that IP addressing does not ensure geographic proximity
before attributing
To clarify some of this discussion, providing some context that might be
useful:
1) the current doc already explicitly states the procedures for
assignment in each range of ports (see Sec 8.1.1).
2) Sec 8.1.1 *already* states that IESG approval through IETF process is
a valid path for
101 - 200 of 482 matches
Mail list logo
