On 6/7/2014 6:20 AM, Stephen Farrell wrote:
Yes, source addresses leak information that affects privacy. But
we do not have a practical way to mitigate that. So therefore
BCP188 does not call for doing stupid stuff, nor for new laws of
physics (unlike -04 of the draft we're discussing;-)
On 6/11/2014 8:09 AM, Stephen Farrell wrote:
On 11/06/14 15:54, Joe Touch wrote:
On 6/7/2014 6:20 AM, Stephen Farrell wrote:
Yes, source addresses leak information that affects privacy. But
we do not have a practical way to mitigate that. So therefore
BCP188 does not call for doing
On Jun 7, 2014, at 6:20 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote:
NATs have both good and bad properties. The slightly better privacy
is one of the good ones.
Better for the hosts they 'hide'; worse as a common network access point.
Consider an enterprise. There are two things we
On 6/5/2014 5:48 AM, Stephen Farrell wrote:
I share those concerns. And adopting this without any consideration
of BCP188 would fly in the face of a very recent, very thoroughly
discussed, IETF consensus.
That BCP thankfully includes zero RFC2119 language except the single
word should (not
On 6/5/2014 1:28 PM, Brian E Carpenter wrote:
...
As a matter of fact I tend to agree with many of your criticisms
of the draft, and I like the idea (below) of adding what we might
call the misuse cases. That's a discussion the intarea WG could have.
Brian
I'd vote for WG adoption, and
On 9/6/2013 10:17 AM, Michael Richardson wrote:
I will be happy to participate in a pgp signing party.
Organized or not.
I suggest that an appropriate venue is during the last 15 minutes of the
newcomer welcome and the first 15 minutes of the welcome reception.
Because:
1) the WG-chairs
On 9/6/2013 5:10 PM, Ted Lemon wrote:
On Sep 6, 2013, at 6:42 PM, Joe Touch to...@isi.edu wrote:
I've noted elsewhere that the current typical key-signing party
methods are very weak. You should sign only the keys of those who you
know well enough to claim you can attest to their identity
On 8/22/2013 12:44 AM, Martin Sustrik wrote:
On 21/08/13 19:00, Joe Touch wrote:
So what would you use for muxing, if TCPMUX is not a good idea?
You need to roll your own. The requirements of systems vary widely, as
do the costs/benefits of different approaches.
I listed a few before
On 8/21/2013 12:50 AM, Martin Sustrik wrote:
On 20/08/13 17:01, Joe Touch wrote:
However, see my other message - it's hard to recommend an approach when
we don't understand the problem you're trying to solve.
The scenario is simple.
You want admin to open one port in the firewall when
On 8/21/2013 12:50 AM, Martin Sustrik wrote:
...
You want admin to open one port in the firewall when the project is
started. Going through the corporate process at this point is bearable
and makes sense.
Afterwards, you want to be able to expose arbitrary services through
that port without
On 8/21/2013 8:31 AM, Martin Sustrik wrote:
On 21/08/13 17:12, Joe Touch wrote:
The real problem here IMO is how to distinguish between adding a
completely new application -- which should require approval process --
and adding a new component within an existing distributed application
On 8/20/2013 5:35 AM, Martin Sustrik wrote:
If you want a multiplexer to serve different connections from a single
service port, you need a multiplexer server (tcpmux daemon, websockets,
whatever you want to call it).
Ack. The web server is a problem though, because you typically don't
have
On 8/15/2013 10:19 PM, Martin Sustrik wrote:
On 15/08/13 22:18, Joe Touch wrote:
Does anyone have any idea how widely is TCPMUX (RFC 1078) protocol
used?
Is it the case that there are inetd daemons in TCPMUX mode running
everywhere, or can it be rather considered a dead protocol
On 8/15/2013 10:38 PM, Martin Sustrik wrote:
On 16/08/13 03:23, Wesley Eddy wrote:
There are semantics issues to; see draft-touch-tcp-portnames-00 for
information (this is being revised for resubmission shortly, FWIW).
I totally agree. In fact, in the update to the TCP roadmap [1], we
On 8/10/2013 12:29 PM, Wesley Eddy wrote:
On 8/10/2013 1:43 AM, Martin Sustrik wrote:
Hi all,
Does anyone have any idea how widely is TCPMUX (RFC 1078) protocol used?
Is it the case that there are inetd daemons in TCPMUX mode running
everywhere, or can it be rather considered a dead
On 8/1/2013 2:16 AM, Simon Leinen wrote:
For the first couple of years that I had an ISP connection (which soon
had an early NAT box on it), whenever I called up the ISP (then, and
still, one of the largest in the US) with a service call, the first
thing I had to do was unplug the NAT box and
On 7/30/2013 5:17 AM, Roland Bless wrote:
Hi,
my impression from several presentations seen this week at the IETF
as well as at the ISOC Panel on Improving Internet Experience
is that we probably need to do something on reducing the number
of _broken_ middleboxes (or their implementations
On 7/30/2013 6:23 AM, Noel Chiappa wrote:
The IETF doesn't have a police force, or any enforcement mechanism. If we're
going to head off these boxes, the only tool we have to do that is to build
better mousetraps - i.e. design stuff that does what people want, is more
cost-effective, and is
Paul Wouters p...@cypherpunks.ca writes:
Hugh Daniel passed away on June 3rd after what appears to have been a
heart attack.
I met Hugh many years ago when we were working on our overlay system,
and had problems integrating it with FreeS/WAN's IPsec implementation.
And yes, I too remember
On 5/30/2013 7:59 AM, Paul Hoffman wrote:
On May 29, 2013, at 11:53 PM, Adrian Farrel adr...@olddog.co.uk wrote:
I can also see potential for adding some info to the Tao, but the danger there
is that document becomes too big and too detailed to be of use.
Many would claim it already is.
This doc seems more useful as a section of an update to the TAO of the
IETF. I agree with Brian that putting it forth as a separate document
may give the unintended impression that this is the formal procedure.
Joe
On 5/28/2013 1:26 PM, Brian E Carpenter wrote:
On 28/05/2013 21:32, Adrian
On 5/29/2013 10:36 AM, Dave Crocker wrote:
On 5/29/2013 7:31 PM, Joe Touch wrote:
This doc seems more useful as a section of an update to the TAO of the
IETF. I agree with Brian that putting it forth as a separate document
may give the unintended impression that this is the formal procedure
On 5/29/2013 10:51 AM, Dave Crocker wrote:
On 5/29/2013 7:42 PM, Joe Touch wrote:
Yes, to some - especially newbies who don't know the process. Except
that's exactly whom you're trying to reach.
Consider yourself a newbie who has been told that the TAO gives all the
informal information
On 5/29/2013 11:56 AM, Dave Crocker wrote:
On 5/29/2013 7:57 PM, Joe Touch wrote:
My premise is that when introducing people to a new game, it makes sense
to keep things simple and in one place p the TAO.
You can continue to disagree with that if you prefer.
I haven't disagreed with doing
On 5/14/2013 5:53 PM, Ted Lemon wrote:
On May 14, 2013, at 8:27 PM, Joe Touch to...@isi.edu wrote:
That is what happens exactly because the DISCUSS holds up the
document, and most ADs don't want to burn time stalling their documents
if there's a way around that delay.
It can only happen
On 5/14/2013 4:57 PM, Joel M. Halpern wrote:
And your bottom line is exactly what te rules say, what I said, what Ted
said, and what Joe agreed is reasonable.
Unfortunately, it's not what happens/is happening right now.
Joe
On 5/14/2013 4:03 PM, Ted Lemon wrote:
The whole point of a DISCUSS is to have a discussion.
The *whole* point of a DISCUSS is to hold a document in IETF review
until a discussion is *resolved*.
There are thus three parts:
- having a discussion
- pausing the document
On 5/14/2013 9:54 PM, Keith Moore wrote:
Publishing broken or unclear documents is not progress.
Keith
Broken, agreed.
Unclear, nope - please review the NON-DISCUSS criteria, notably:
The motivation for a particular feature of a protocol is not clear
enough. At the IESG review stage,
On 5/14/2013 10:05 PM, Keith Moore wrote:
...
For that matter, working groups are too often echo chambers where a set
of people manage to isolate themselves from input from those whose work
they might otherwise effect.Some people seem to think that working
group output should be
On 5/15/2013 7:55 AM, Ted Lemon wrote:
On May 15, 2013, at 10:41 AM, Keith Moore mo...@network-heretics.com wrote:
The motivation for a particular feature of a protocol is not
clearenough. At the IESG review stage, protocols should not be blocked
because they provide capabilities beyond what
On 5/15/2013 10:15 AM, Ted Lemon wrote:
On May 15, 2013, at 12:36 PM, Joe Touch to...@isi.edu wrote:
I'm impressed that you have such a specific interpretation that this
criteria refers to the entire document, even when it talks about the
feature of a protocol.
The motivation for a feature
On 5/15/2013 11:08 AM, Ted Lemon wrote:
On May 15, 2013, at 1:23 PM, Joe Touch to...@isi.edu wrote:
You don't agree that the motivation for the difference between using 16-bit vs.
32-bit ExIDs is sufficient, even though that is already discussed in the
document.
I don't think
On 5/15/2013 7:49 AM, Ralph Droms wrote:
The DISCUSS isn't there to make documents better - that's for COMMENTs. A
DISCUSS there to catch a set of problems and to*block* the document's progress until that
problem is resolved.
I'll agree with you *if* you consider an unclear description
Brian, et al.,
On 5/14/2013 1:10 PM, Brian E Carpenter wrote:
I think this exchange between Cullen and Ted says it all, except
for one tweak: the IESG is allowed, even encouraged, to apply common
sense when considering the DISCUSS criteria. They are guidance,
not rules.
Also, everybody needs
On 5/14/2013 10:18 AM, Dave Crocker wrote:
And a Discuss should be required to assert which criteria apply and how.
+1
Joe
On 5/14/2013 1:59 PM, Stephen Farrell wrote:
Joe,
On 05/14/2013 09:45 PM, Joe Touch wrote:
As important as the DISCUSS criteria are, there are NON-DISCUSS criteria
that ought to be more carefully followed - including the point that
disagreements with the WG or clarifications
to clar is
the wrong picture as far as I can tell.
Point taken - at least some indication on what is expected to be changed
toward a path of resolution.
As you note, otherwise it's not a DISCUSS.
Joe
Yours,
Joel
On 5/14/2013 5:12 PM, Joe Touch wrote:
I am *not* suggesting getting rid
On 5/14/2013 4:03 PM, Ted Lemon wrote:
If the authors think that the goal is to please the AD, something's
wrong. This would suggest that they will just do what the AD says
without debate, which is exactly the wrong thing. The whole point of
a DISCUSS is to have a discussion. Frankly, it's
On 4/19/2013 2:02 AM, Yoav Nir wrote:
Only that you know enough people so that you could push a new technology even
without attending,
IETF work officially happens on IETF lists, not at in-person meetings.
As per the Tao of the IETF: Any decision made at a face-to-face meeting
must also
On 4/15/2013 7:23 AM, Ted Lemon wrote:
So it's hard to see the harm in [late non-area input by the IESG],
It gives the IESG an exemption to participating in WG and IESG last call
processes, which then frustrates the rest of the community that does not
have this opportunity.
It says that
On Apr 15, 2013, at 9:09 AM, Ted Lemon ted.le...@nominum.com wrote:
On Apr 15, 2013, at 11:36 AM, Joe Touch to...@isi.edu wrote:
It gives the IESG an exemption to participating in WG and IESG last call
processes, which then frustrates the rest of the community that does not
have
Hi, all,
As an author who has had (and has) multiple documents in IESG review,
I've noticed an increasing trend of this step to go beyond (IMO) its
documented and original intent (BCP 9, currently RFC 2026):
The IESG shall determine whether or not a specification submitted to
it
On 4/11/2013 11:55 AM, Paul Hoffman wrote:
On Apr 11, 2013, at 10:54 AM, Joe Touch to...@isi.edu wrote:
As an author who has had (and has) multiple documents in IESG review, I've
noticed an increasing trend of this step to go beyond (IMO) its documented and
original intent (BCP 9
.
For the IETF list - if anyone knows why these sort of questions are not
being answered, please post.
Thanks,
Joe
On 3/20/2013 10:05 AM, Joe Touch wrote:
Hi, Nevil,
I sent this message back in November; the current version addresses all
received comments. I do not know of any pending comments
On 3/22/2013 4:43 AM, Margaret Wasserman wrote:
...
Granted, it may be that the list of _qualified_ candidates is less
diverse than the set of all people who are willing to run. But, if so,
that isn't because there aren't companies who are willing/able to
On 3/5/2013 2:52 PM, Henning Schulzrinne wrote:
While the IETF is unique in many ways, the staff-volunteer issue
isn't all that unique. Many organizations face this. As one example,
organizations like IEEE and ACM struggle with this. (For example,
they have, over the years, delegated many
On 3/4/2013 2:19 PM, Dave Crocker wrote:
...
ADs do not 'lead' the work of their area. They do not initiate
the work, produce the charters or write the specifications. Work that
fails or succeeds does so because it has community consensus and demand,
not because an AD was diligent
On 3/5/2013 10:33 AM, Dave Crocker wrote:
Joe,
On 3/5/2013 10:28 AM, Joe Touch wrote:
On 3/4/2013 2:19 PM, Dave Crocker wrote:
...
ADs do not 'lead' the work of their area. They do not initiate
the work, produce the charters or write the specifications. Work that
fails
On 2/26/2013 11:23 AM, joel jaeggli wrote:
On 2/26/13 11:12 AM, Michael Tuexen wrote:
On Feb 26, 2013, at 8:01 PM, Dale R. Worley wrote:
From: James Polk jmp...@cisco.com
Personally, I'd trust date -u much sooner than any random person.
Even better:
$ date --date='00:00 Feb 26, 2013
On 2/26/2013 11:47 AM, Marc Petit-Huguenin wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/26/2013 11:39 AM, Joe Touch wrote:
On 2/26/2013 11:23 AM, joel jaeggli wrote:
On 2/26/13 11:12 AM, Michael Tuexen wrote:
On Feb 26, 2013, at 8:01 PM, Dale R. Worley wrote:
From: James
On 2/15/2013 12:19 AM, Stephane Bortzmeyer wrote:
On Thu, Feb 14, 2013 at 03:02:48PM -0800,
Joe Touch to...@isi.edu wrote
a message of 16 lines which said:
By popular request, I've restored the DNS calculator function as an
operational service.
Why no delegation from postel.org
On 2/14/2013 3:07 PM, Marco Davids (Prive) wrote:
Op 15-02-13 00:02, Joe Touch schreef:
By popular request, I've restored the DNS calculator function as an
operational service. See:
http://www.isi.edu/touch/tools/dns-calc.html
Great! But I was hoping it would do DNSSEC by now.
Like
On 2/15/2013 2:06 PM, Patrik Fältström wrote:
On 15 feb 2013, at 18:19, Joe Touch to...@isi.edu wrote:
- the Bert version uses DNS strings that aren't valid
(*, +, ',', ++)
Are we going to open again the question whether the DNS protocol can handle any
value in the octets
On 2/15/2013 3:17 PM, John C Klensin wrote:
--On Friday, February 15, 2013 14:10 -0800 Joe Touch
to...@isi.edu wrote:
Let's just say that there doesn't appear to be disagreement
that the DNS can handle a-z/0-9/'-'.
Other values _may or may not_ be permitted or handled opaquely
Hi, all,
By popular request, I've restored the DNS calculator function as an
operational service. See:
http://www.isi.edu/touch/tools/dns-calc.html
(this was designed for a Sigcomm OO session, but it's been used several
places as an example why the DNS should NOT be anything more than a
On 1/28/2013 3:12 AM, Stephen Farrell wrote:
On 01/28/2013 04:27 AM, Joe Touch wrote:
...
If this is an experiment, then you presumably answers to the following
questions:
1- what is your an hypothesis?
2- what you intend to measure?
3- what is your 'control' against which
About the idea of an experiment:
On 1/25/2013 5:07 AM, Stephen Farrell wrote:
Responses to some points below but I'd really like to ask
people to consider a few things here:
- what's proposed is an experiment, it'd likely get tried out
a few times and won't consume any huge resource
FWIW, this document includes text that somewhat defeats the previous
recommendations of TCPM regarding RFC5927.
RFC5927 includes specific text indicating that the techniques described
are being documented, but that the TCP standard was NOT being changed to
include those ICMP validation
On 1/24/2013 1:24 PM, Fernando Gont wrote:
Joe,
On 01/24/2013 04:35 PM, Joe Touch wrote:
FWIW, this document includes text that somewhat defeats the previous
recommendations of TCPM regarding RFC5927.
RFC5927 includes specific text indicating that the techniques described
are being
from that
sentence entirely.
Allison
On Jan 24, 2013 7:19 PM, Joe Touch to...@isi.edu
mailto:to...@isi.edu wrote:
On 1/24/2013 1:24 PM, Fernando Gont wrote:
Joe,
On 01/24/2013 04:35 PM, Joe Touch wrote:
FWIW, this document includes text that somewhat defeats the previous
Hi, all,
On 1/11/2013 8:21 AM, Adrian Farrel wrote:
Hi Alexa,
Please be aware of this document that has just entered a four-week IETF last
call. The document describes a proposed IETF process experiment under the rules
of RFC 3933.
The proposed experiment calls on the IETF Secretariat to take
On 1/22/2013 9:00 AM, Stephen Farrell wrote:
Hi Joe,
On 01/22/2013 04:39 PM, Joe Touch wrote:
...
This is a silly idea.
So you're in two minds about it eh:-)
First, running code should already be considered as part of the context
of review.
Second, running code is not correlated
On 1/7/2013 6:01 PM, John Day wrote:
All standards groups that I am aware of have had the same view. This is
not uncommon.
Although, I would point out that the TCP specification nor do most
protocols specifications of this type follow this rule. State
transitions are not visible on the wire.
Taleb, NEC Europe, Germany
TPC co-Chairs
• Dr. Tuncer Baykas, Tohoku University, Japan
• Dr. Alex Reznik, InterDigital, USA
• Dr. Konstantinos Samdanis , NEC Europe, Germany
Publicity co-chairs
• Prof. Joe Touch, Univ. of Southern California, USA
• Dr. Periklis Chatzimisios, Alexander TEI
On 11/27/2012 10:07 AM, Marc Blanchet wrote:
Le 2012-11-27 à 13:00, Barry Leiba a écrit :
So here's my question:
Does the community want us to push back on those situations? Does the
community believe that the real IETF work is done on the mailing
lists, and not in the face-to-face
-chairs
• Prof. Joe Touch, Univ. of Southern California, USA
• Dr. Periklis Chatzimisios, Alexander TEI of Thessaloniki, Greece
IMPORTANT DATES
PAPER REGISTRATION: Jan. 04, 2013 SUBMISSION DEADLINE: Jan. 11, 2013
ACCEPTANCE NOTIFICATION: Feb. 22, 2013 FINAL MANUSCRIPT: Mar. 08, 2013
Hi, Russ,
FWIW, you seem to be conveniently ignoring at least two issues:
1) all the IDs before March 1994
which should not be published at all until
permission is given (opt-in)
2) all the IDs published before boilerplate inclusion was required
the IETF cannot merely
On 9/21/2012 2:48 PM, Paul Hoffman wrote:
On Sep 21, 2012, at 1:54 PM, Joe Touch to...@isi.edu wrote:
And, ultimately, this won't be determined by analysis, but by a court.
These kinds of threats seem a bit over the top.
It was an observation, not a threat (at all).
No analysis of legal
...
--On Friday, September 21, 2012 13:54 -0700 Joe Touch
to...@isi.edu wrote:
Hi, Russ,
FWIW, you seem to be conveniently ignoring at least two issues:
1) all the IDs before March 1994
which should not be published at all until
permission is given (opt-in)
While I agree, I think
On 9/19/2012 3:31 PM, John Levine wrote:
In article 505a2b08.70...@isi.edu you write:
On 9/19/2012 11:24 AM, John Levine wrote:
Utility can determine whether it's worth the effort/expense to run a
public archive, but your utility never undermines my rights as an author.
We're very deep
On 9/16/2012 6:56 AM, Lawrence Conroy wrote:
...
It is VERY useful to be able to search through drafts to see how we
got here, AND to see things that were explored and abandoned.
Thieves find it very useful to have what they steal. That doesn't
legitimize their theft.
Utility can
On 9/19/2012 11:24 AM, John Levine wrote:
Utility can determine whether it's worth the effort/expense to run a
public archive, but your utility never undermines my rights as an author.
We're very deep into Junior Lawyer territory here.
I'm not. I'm simply refuting *any* argument that
On 9/12/2012 11:01 PM, Martin Rex wrote:
While the 6-month timer (or any earlier I-D update!!) will, in fact,
change how the*IETF* distributes and promotes a particular I-D (version),
there is actually*NO* limitation in what folks downloading I-Ds
with the URLs from the i-d-announce I-D
On 9/13/2012 12:02 AM, Dave Crocker wrote:
On 9/12/2012 11:30 PM, John C Klensin wrote:
But nothing in the above, nor in the text you cite, requires
that _keep_ imply guarantee to have available for retrieval
over the network by any interested party, with no requirement
for a special
On 9/13/2012 12:28 PM, Martin Rex wrote:
Joe,
So it's not a slam dunk that you have the rights you think for every
I-D; you definitely don't have those rights for IDs
We're NOT talking about rights that were transfered from the document
author to arbitrary third parties here, but about
On 9/13/2012 11:04 AM, Melinda Shore wrote:
On 9/12/12 11:19 PM, Joe Touch wrote:
PirateBay believes this too, and helps make movies available for public
access, honoring pragmatics.
I'm not sure I understand this analogy. Are you saying that there are
IPR issues related to making expired
There were times when there were no rights granted explicitly, at least.
I indicated the three ranges in a previous mail.
Joe
On 9/13/2012 8:40 PM, John Levine wrote:
I'm not sure I understand this analogy. Are you saying that there are
IPR issues related to making expired drafts available?
.
Joe
On 9/13/2012 10:10 PM, Martin Rex wrote:
Joe Touch wrote:
There were times when there were no rights granted explicitly, at least.
I indicated the three ranges in a previous mail.
In which case the Note Well concludently applies to the I-D contents,
which seems to have first appeared
On 9/12/2012 5:59 PM, Martin Rex wrote:
Barry Leiba wrote:
This raises the question of what expires means.
At the least, if IDs are published publicly forever, then expires is no
longer meaningful and the entirety of that notion needs to be expunged
from the ID process.
You seem to think
Hi, Barry,
On 9/12/2012 8:13 PM, Barry Leiba wrote:
I think it means no longer current for the purposes of work and
discussion.
Nothing in the Note Well, but there is specific text in the ID Guidelines
(written by the IESG):
http://www.ietf.org/ietf-ftp/1id-guidelines.txt
8. Expiring
On 9/10/2012 8:24 AM, David Borman wrote:
...
The original reason for expiring drafts, along with giving them long,
complicated names that includes the word draft, was to keep them
from being referenced as if they were standards, based on experience
gathered from the short lived IDEA document
On 9/8/2012 1:14 AM, Brian E Carpenter wrote:
...
The factual reality is that I-D's have always been more or less perpetual,
given that anonymous FTP has existed longer than any I-D.
It has always been the case that some sites have violated the copyright
and explicit instructions of IDs.
On 9/8/2012 8:19 AM, Melinda Shore wrote:
On 9/7/12 7:58 PM, Joe Touch wrote:
What can that mean if it remains available to the public? What
purpose does such an automatic timeout have if it is left up? IMO,
none.
It seems to me that the timeout takes the draft out of consideration
On 9/8/2012 11:59 AM, Melinda Shore wrote:
On 9/8/12 10:51 AM, Joe Touch wrote:
Nothing about an ID is inherently obsolete or out of date after 6 months
except its being publicly available on authorized sites (up until now).
I think this is absolutely incorrect. Internet Drafts are IETF
On 9/5/2012 7:51 AM, SM wrote:
...
Creating a perpetual I-D archive for the sake of rfcdiff is not a good
idea as it goes against the notion of letting an I-D expire gracefully.
+1
Let's not forget there was a reason for expiration.
I'm OK with the archive being public so long as at least
Hi, all,
This statement seems fine, but it's worth noting that it would apply
only to *IETF* protocol specs. The IESG has, IMO, no authority to make
such claims for independent submissions (and what about IRTF ones?), and
the IEEE should recognize that such protocols are described by RFCs
On 9/7/2012 8:32 AM, Brian E Carpenter wrote:
On 07/09/2012 15:48, Joe Touch wrote:
...
Let's not forget there was a reason for expiration.
Expired != invisible
Expired = no longer *published*.
IMO, the expires indication on an ID indicates the expiration of the
ability of the ISOC
PS - to note an astonishing concept:
On 9/7/2012 8:32 AM, Brian E Carpenter wrote:
On 07/09/2012 15:48, Joe Touch wrote:
On 9/5/2012 7:51 AM, SM wrote:
...
Creating a perpetual I-D archive for the sake of rfcdiff is not a good
idea as it goes against the notion of letting an I-D expire
On 9/7/2012 8:56 AM, Dave Crocker wrote:
On 9/7/2012 8:45 AM, Joe Touch wrote:
It's not always about what is best for *you* or for other reviewers.
Actually, it is. The documents are issued by the IETF to facilitate
public discussion. It's the only reason to have the mechanism
:15 AM, Ralph Droms wrote:
On Sep 7, 2012, at 10:51 AM 9/7/12, Joe Touch wrote:
Hi, all,
This statement seems fine, but it's worth noting that it would apply only to
*IETF* protocol specs.
What did you have in mind as noting? This text seems pretty clear to me as applying
only to IETF
On 9/7/2012 9:21 AM, Dave Crocker wrote:
...
And by the way, formally, I-D's are not published. That's a
semantic point, but apparently it's important for this discussion.
At lease one of the ISOC's boilerplates states:
This document may not be modified, and derivative works of
On 9/7/2012 11:37 AM, SM wrote:
At 08:43 07-09-2012, Joe Touch wrote:
IMO, the expires indication on an ID indicates the expiration of the
ability of the ISOC to publish the draft.
This raises the question of what expires means.
At the least, if IDs are published publicly forever
On Sep 7, 2012, at 7:36 PM, Barry Leiba barryle...@computer.org wrote:
This raises the question of what expires means.
At the least, if IDs are published publicly forever, then expires is no
longer meaningful and the entirety of that notion needs to be expunged
from the ID process.
On 8/13/2012 7:14 AM, philip.eard...@bt.com wrote:
Ben,
Thanks for your review.
The right status isn't clear-cut (I think), but when we (Chairs Wes)
discussed it, Info seemed best
* mainly because precedent seems to be that API docs are informational, for
example socket API extensions for
On 8/13/2012 2:45 AM, Masataka Ohta wrote:
Joe Touch wrote:
Again, this doc is about updating the IPv4 ID specification in RFC791 -
which has not yet been updated.
But, the way you update rfc791 requires updating rfc2460,
rfc2765 and their implementations, for which
Hi,
On 8/7/2012 12:26 AM, Masataka Ohta wrote:
Joe Touch wrote:
RFC2765 specifies that translators can merely copy the
low-order bits of the field.
Yes, but this is not compatible with RFC791.
Then, which should we revice? RFC791, RFC2765 or both?
2765.
There is no useful way
On 8/3/2012 4:19 PM, Masataka Ohta wrote:
Joe Touch wrote:
Translators violate RFC791. They cannot merely copy the
low-order bits of the field, since that is insufficiently
unique, and isn't specified as being generated at the
IPv6 source in compliance with IPv4 requirements.
RFC2765
On Jul 17, 2012, at 11:16 PM, Masataka Ohta wrote:
Joe Touch wrote:
Or, are 6 to 4 translators are required to rate limit and
drop rate-violating packets to make the stateless
translators full of states.
I would expect that the translator would be responsible
for this, though
Do you
Hi,
On 6/20/2012 5:57 PM, Masataka Ohta wrote:
Though the ID states:
This
document underscores the point that not only is reassembly (and
possibly subsequent fragmentation) required for translation, it can
be used to avoid issues with IPv4 ID uniqueness.
according to
I will include a response to the rest of this in my summary of the last
call concerns. Regarding your last point:
On 6/18/2012 5:39 AM, Masataka Ohta wrote:
...
PS
While your draft is rather harmful than useless, I'm fine
if the following point of the draft:
Originating sources MAY
1 - 100 of 482 matches
Mail list logo