Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers

2014-06-11 Thread Joe Touch
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;-)

Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers

2014-06-11 Thread Joe Touch
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

Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers

2014-06-08 Thread Joe Touch
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

Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers

2014-06-06 Thread Joe Touch
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

Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers

2014-06-06 Thread Joe Touch
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

Re: pgp signing in van

2013-09-06 Thread Joe Touch
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

Re: pgp signing in van

2013-09-06 Thread Joe Touch
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

Re: TCPMUX (RFC 1078) status

2013-08-22 Thread Joe Touch
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

Re: TCPMUX (RFC 1078) status

2013-08-21 Thread Joe Touch
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

Re: TCPMUX (RFC 1078) status

2013-08-21 Thread Joe Touch
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

Re: TCPMUX (RFC 1078) status

2013-08-21 Thread Joe Touch
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

Re: TCPMUX (RFC 1078) status

2013-08-20 Thread Joe Touch
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

Re: TCPMUX (RFC 1078) status

2013-08-16 Thread Joe Touch
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

Re: TCPMUX (RFC 1078) status

2013-08-16 Thread Joe Touch
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

Re: TCPMUX (RFC 1078) status

2013-08-15 Thread Joe Touch
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

Re: Bringing back Internet transparency

2013-08-01 Thread Joe Touch
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

Re: Bringing back Internet transparency

2013-07-30 Thread Joe Touch
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

Re: Bringing back Internet transparency

2013-07-30 Thread Joe Touch
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

Re: Hugh Daniel has passed away

2013-06-06 Thread Joe Touch
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

Re: When to adopt a WG I-D

2013-06-04 Thread Joe Touch
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.

Re: When to adopt a WG I-D

2013-05-29 Thread Joe Touch
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

Re: When to adopt a WG I-D

2013-05-29 Thread Joe Touch
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

Re: When to adopt a WG I-D

2013-05-29 Thread Joe Touch
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

Re: When to adopt a WG I-D

2013-05-29 Thread Joe Touch
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

Re: call for ideas: tail-heavy IETF process

2013-05-15 Thread Joe Touch
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

Re: call for ideas: tail-heavy IETF process

2013-05-15 Thread Joe Touch
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

Re: call for ideas: tail-heavy IETF process

2013-05-15 Thread Joe Touch
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

Re: call for ideas: tail-heavy IETF process

2013-05-15 Thread Joe Touch
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,

Re: call for ideas: tail-heavy IETF process

2013-05-15 Thread Joe Touch
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

Re: call for ideas: tail-heavy IETF process

2013-05-15 Thread Joe Touch
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

Re: call for ideas: tail-heavy IETF process

2013-05-15 Thread Joe Touch
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

Re: call for ideas: tail-heavy IETF process

2013-05-15 Thread Joe Touch
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

Re: call for ideas: tail-heavy IETF process

2013-05-15 Thread Joe Touch
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

Re: call for ideas: tail-heavy IETF process

2013-05-14 Thread Joe Touch
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

Re: call for ideas: tail-heavy IETF process

2013-05-14 Thread Joe Touch
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

Re: call for ideas: tail-heavy IETF process

2013-05-14 Thread Joe Touch
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

Re: call for ideas: tail-heavy IETF process

2013-05-14 Thread Joe Touch
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

Re: call for ideas: tail-heavy IETF process

2013-05-14 Thread Joe Touch
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

Re: The Purpose of WG participants Review (was Re: Purpose of IESG Review)

2013-04-22 Thread Joe Touch
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

Re: Purpose of IESG Review

2013-04-15 Thread Joe Touch
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

Re: Purpose of IESG Review

2013-04-15 Thread Joe Touch
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

Purpose of IESG Review

2013-04-11 Thread Joe Touch
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

Re: Purpose of IESG Review

2013-04-11 Thread Joe Touch
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

Re: question about draft-touch-tcp-ao-nat

2013-04-10 Thread Joe Touch
. 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

Re: Less Corporate Diversity

2013-03-22 Thread Joe Touch
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

Re: Appointment of a Transport Area Director

2013-03-06 Thread Joe Touch
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

Re: Appointment of a Transport Area Director

2013-03-05 Thread Joe Touch
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

Re: Appointment of a Transport Area Director

2013-03-05 Thread Joe Touch
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

Re: Internet Draft Final Submission Cut-Off Today

2013-02-26 Thread Joe Touch
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

Re: Internet Draft Final Submission Cut-Off Today

2013-02-26 Thread Joe Touch
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

Re: back by popular demand - a DNS calculator

2013-02-15 Thread Joe Touch
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

Re: back by popular demand - a DNS calculator

2013-02-15 Thread Joe Touch
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

Re: back by popular demand - a DNS calculator

2013-02-15 Thread Joe Touch
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

Re: back by popular demand - a DNS calculator

2013-02-15 Thread Joe Touch
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

back by popular demand - a DNS calculator

2013-02-14 Thread Joe Touch
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

Re: FW: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFCwith Running Code) to Experimental RFC

2013-01-28 Thread Joe Touch
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

Re: FW: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFCwith Running Code) to Experimental RFC

2013-01-27 Thread Joe Touch
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

Re: TSV-DIR review of draft-ietf-6man-ipv6-atomic-fragments-03

2013-01-24 Thread Joe Touch
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

Re: TSV-DIR review of draft-ietf-6man-ipv6-atomic-fragments-03

2013-01-24 Thread Joe Touch
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

Re: TSV-DIR review of draft-ietf-6man-ipv6-atomic-fragments-03

2013-01-24 Thread Joe Touch
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

Re: FW: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC with Running Code) to Experimental RFC

2013-01-22 Thread Joe Touch
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

Re: FW: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC with Running Code) to Experimental RFC

2013-01-22 Thread Joe Touch
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

Re: A proposal for a scientific approach to this question [was Re: I'm struggling with 2219 language again]

2013-01-09 Thread Joe Touch
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.

call for papers - IEEE From Research to Standards workshop

2012-12-12 Thread Joe Touch
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

Re: IETF work is done on the mailing lists

2012-11-27 Thread Joe Touch
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

CFP - 2nd IEEE Workshop On Telecommunications Standards

2012-11-05 Thread Joe Touch
-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

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

2012-09-21 Thread Joe Touch
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

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

2012-09-21 Thread Joe Touch
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

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

2012-09-21 Thread Joe Touch
... --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

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

2012-09-20 Thread Joe Touch
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

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

2012-09-19 Thread Joe Touch
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

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

2012-09-19 Thread Joe Touch
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

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

2012-09-13 Thread Joe Touch
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

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

2012-09-13 Thread Joe Touch
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

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

2012-09-13 Thread Joe Touch
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

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

2012-09-13 Thread Joe Touch
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

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

2012-09-13 Thread Joe Touch
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?

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

2012-09-13 Thread Joe Touch
. 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

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

2012-09-12 Thread Joe Touch
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

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

2012-09-12 Thread Joe Touch
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

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

2012-09-10 Thread Joe Touch
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

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

2012-09-08 Thread Joe Touch
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.

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

2012-09-08 Thread Joe Touch
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

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

2012-09-08 Thread Joe Touch
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

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

2012-09-07 Thread Joe Touch
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

Re: Draft IESG Statement on Ethertype Assignments for IETF Protocols

2012-09-07 Thread Joe Touch
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

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

2012-09-07 Thread Joe Touch
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

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

2012-09-07 Thread Joe Touch
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

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

2012-09-07 Thread Joe Touch
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

Re: Draft IESG Statement on Ethertype Assignments for IETF Protocols

2012-09-07 Thread Joe Touch
: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

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

2012-09-07 Thread Joe Touch
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

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

2012-09-07 Thread Joe Touch
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

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

2012-09-07 Thread Joe Touch
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.

Re: Gen-ART LC Review of draft-ietf-mptcp-api-05

2012-08-17 Thread Joe Touch
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

Re: Last Call: draft-ietf-intarea-ipv4-id-update-05.txt (Updated Specification of the IPv4 ID Field) to Proposed Standard

2012-08-13 Thread Joe Touch
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

Re: Last Call: draft-ietf-intarea-ipv4-id-update-05.txt (Updated Specification of the IPv4 ID Field) to Proposed Standard

2012-08-07 Thread Joe Touch
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

Re: Last Call: draft-ietf-intarea-ipv4-id-update-05.txt (Updated Specification of the IPv4 ID Field) to Proposed Standard

2012-08-03 Thread Joe Touch
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

Re: Last Call: draft-ietf-intarea-ipv4-id-update-05.txt (Updated Specification of the IPv4 ID Field) to Proposed Standard

2012-07-18 Thread Joe Touch
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

Re: Last Call: draft-ietf-intarea-ipv4-id-update-05.txt (Updated Specification of the IPv4 ID Field) to Proposed Standard

2012-07-02 Thread Joe Touch
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

Re: Last Call: draft-ietf-intarea-ipv4-id-update-05.txt (Updated Specification of the IPv4 ID Field) to Proposed Standard

2012-06-18 Thread Joe Touch
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   2   3   4   5   >