Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
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;-) Again, BCP188 does not *call* for doing anything. There are no SHOULD- or MUST- level requirements in that doc. Let's please not wave it in the air as if there are. Joe ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
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 stupid stuff, nor for new laws of physics (unlike -04 of the draft we're discussing;-) Again, BCP188 does not *call* for doing anything. There are no SHOULD- or MUST- level requirements in that doc. Let's please not wave it in the air as if there are. I don't buy that argument at all and didn't wave anything anywhere. BCP188 very clearly says: Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible. and Those developing IETF specifications need to be able to describe how they have considered PM, and, if the attack is relevant to the work to be published, be able to justify related design decisions. This does not mean a new pervasive monitoring considerations section is needed in IETF documentation. It means that, if asked, there needs to be a good answer to the question Is pervasive monitoring relevant to this work and if so, how has it been considered? Reverting to RFC2119-keyword-lawyering is not IMO credible here. That's what RFC2119 is for and how we interpret BCPs. The doc goes out of its way - as you note - to include wiggle phrases like where possible and by not requiring a new considerations section. Yes, it's fine to discuss it here, and I've already outlined a way forward - with the caveat that my view is do no harm, not necessarily fix the lack of privacy already inherent in the Internet - at least in this doc. Joe ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
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 can learn about it from IP addresses: - without a NAT, we learn about activity of individual hosts - with a NAT, we learn the common network access point If I want to track host activity - or attack a host, the former is better. If I want to know what to DOS to take down the entire enterprise, the latter is better. Think of it this way: a NAT hides the host *at the expense* of exposing a router If we're serious about considering privacy issues, there's a LOT more homework to be done. Joe ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
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 capitalized) in the abstract, thus every new document is trivially compliant with its recommendations. (I really wish the IETF community cared as much about technical correctness and protocol robustness as they did about issuing that IMO largely political statement, which flies in the face of 40+ years of using globally-assigned, globally-unique IP addresses as endpoint identifiers as the basis of the Internet architecture). Joe ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
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 agree with the above with the caveat that such misuse should focus on: a) ways proposed mechanisms undo current mechanisms that *might* have been intended to preserve privacy (e.g., NATs are deployed for lots of reasons, and we never know intent per se, but privacy preservation CAN be a reason) b) ways proposed mechanisms can exceed restoring what such devices undo and be used to track hosts, processes, or other identities beyond what the original packet *would have already exposed*. I.e., for a device that inserts the source IP address and TCP source port for NAT traversal, it would at best be considered to 'undo' the potential privacy-creation intent of a NAT, but would NOT be considered to exceed what the original packet conveyed. Joe ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: pgp signing in van
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 and IESG will all be there, and a web of trust still needs some significant good connectivity, and we already know each other rather well, without needing ID (I am not interested myself in verifying anyone's NSA^WGovernment identity. I don't trust that Certification Authority...) 2) getting newbies on-board, meeting them well enough to sign their key seems like a good thing. And whose key would you sign? Anyone who showed up with a form of ID? 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. If that's the case, how will this get newbies on-board except to invite them to have keys whose signatures aren't relevant, and to devalue the trust in WG-chairs and IESG members? Joe
Re: pgp signing in van
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. This is a ridiculously high bar. The bar should be about at the level of a facebook friend request. Given I'm not on Facebook, the latter bar is infinitely high. As per the PGP description: --- There are several levels of confidence which can be included in such signatures. Although many programs read and write this information, few (if any) include this level of certification when calculating whether to trust a key. --- And that's the problem - as long as endorsements are equal, they're only as good as your weakest one. Joe
Re: TCPMUX (RFC 1078) status
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, but here's a more comprehensive list: - service per message demux based on message ID use IPC (interprocess comm) to handoff internal to your system - service per connection demux based on the first message in an association (TCP or UDP), and either continue to forward messages to a different process or handoff the connection So, if I proceed with this option why not use RFC1078 to implement it? Why write a new RFC if there's an old one that fits the bill? There are two cases to consider: - you're creating your own set of services, at which point you'll need to roll your own dispatch mechanism - you want to use TCPMUX, either for your own services or for all services you should already realize why that's a dead-end. any sysadmin that blocks *any* ports will always block TCPMUX One final reason TCPMUX isn't deployed is that it changes the semantics of many existing services, many of which are defined as if the connection opens, then the service is there. If you roll your own version, you can define your services to accept those semantics. Joe
Re: TCPMUX (RFC 1078) status
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 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 having to go through port-opening process over and over again. There's nothing new about multiplexing services over a single port; it's a known problem with a few common solutions: - dispatch the connections inside your system based on in-band info - initiate connections inside a handler, and transfer them to spawned subprocesses - use initial connections to exchange inband info for other connections on dynamic ports (as done in FTP) They each have their challenges. The services are actually different aspects of the same distributed application, say, data distribution service, management service, heartbeating service etc. so not requiring additional process for adding them makes sense. Each distinct, independently-useable service may warrant a new port or could all be muxed together. Which of these you seek is up to you. That's a design decision. 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 -- which should be managed by devs themselves. IMO it's easy - any group of services you want others to be able to use independently could justify a new port, but you can always mux them all together if you want to avoid additional firewall configuration issues. I.e., this is your call. But it doesn't appear to have anything to do with the notion of a single port to access any *existing* service, which is what TCPMUX and its descendants does. Joe
Re: TCPMUX (RFC 1078) status
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 having to go through port-opening process over and over again. One additional point - if you really mean arbitrary, including existing services, I hope you understand that a network operator that shuts down ANY current services would conclude they must then block yours too. I.e., if I don't want FTP over the firewall (because it uses cleartext passwords), I definitely don't want TCPMUX (which allows FTP), or any other accesses arbitrary services port. So that seems like a non-starter, unless by arbitrary you mean extensions within your system - which is how all current ports already work. Joe
Re: TCPMUX (RFC 1078) status
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 -- which should be managed by devs themselves. IMO it's easy - any group of services you want others to be able to use independently could justify a new port, but you can always mux them all together if you want to avoid additional firewall configuration issues. 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, but here's a more comprehensive list: - service per message demux based on message ID use IPC (interprocess comm) to handoff internal to your system - service per connection demux based on the first message in an association (TCP or UDP), and either continue to forward messages to a different process or handoff the connection - subservice on different ports determine what subservice you want to initiate, start it on an ephemeral port, and indicate the port number in-band (e.g., as with FTP and others) Given you want to keep things on a single port, the first two are probably more useful. Joe
Re: TCPMUX (RFC 1078) status
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 control of it. I.e. you cannot randomly plug-in your code into it. You have control over a web server you install. Yes, that would eat one IP address, but there are a lot more IP addresses than port numbers (i.e., using a port to avoid using a separate IP address consumes the wrong resource). However, see my other message - it's hard to recommend an approach when we don't understand the problem you're trying to solve. Joe
Re: TCPMUX (RFC 1078) status
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? Specifically, if I implement a new TCPMUX daemon how likely I am to clash with an existing TCPMUX daemon listening on port 1? It's in the FreeBSD inetd, among others, but to to my knowledge, nobody actually turns it on. There are probably security issues. There are semantics issues to; see draft-touch-tcp-portnames-00 for information (this is being revised for resubmission shortly, FWIW). Nice, however, it requires changes to TCP stack, so even if it succeeds it won't be a practical option for at least few years to come. There have been other stack changes that have been deployed fairly quickly. However, that's not relevant to the reason I cited the doc; the doc has a discussion of TCPMUX and its problems. Joe
Re: TCPMUX (RFC 1078) status
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 added TCPMUX to the section on Historic and Undeployed Extensions, though it definitely bears further discussion than is currently in the roadmap. I think we should add a reference to your portnames doc to explain why this should be Historic plus check a bit more to see if the code that's out there is really being used or whether it's just hanging out like a vestigal limb in the various inetd packages. If it's fair to ask Martin ... I'm kind of curious why you might want to be using it or think it sounds useful? I think a lot of admins would be concerned that it could be used to get around port-based firewall rules, etc. Ok, let me explain. I am coming from enterprise messaging world (think of IBM MQ series, JMS, ActiveMQ, RabbitMQ et c.) Once I was participating on AMQP protocol development (now at OASIS). So, what AMQP and other enterprise messaging products do is exposing a message broker on a single TCP port, which then forwards messages to any connected services. As can be seen, single open firewall port can be used to access any internal service. I don't understand that statement. Services are currently indicated by the destination port. If there is only one destination port available, there is only one service provided - because very few services can be identified solely by in-band information. That being obviously the *wrong* way to do things, I've written ZeroMQ later which takes the strict approach: If you want to expose a new service, you have to use a separate TCP port number. Since then it turned out that this as a limitation that people are most complaining about. It would be useful if you could be more specific about the problem you are trying to solve. So far I hear people want one port that serves multiple services. I'd like a pony ;-) I.e., just because they want it, doesn't mean it either makes sense or should get it. Now, the reason seems to be that ZeroMQ requires you to use different TCP connections for doing different kinds of stuff to avoid head-of-line blocking et c. (think of SCTP channels simulated via TCP) Different connections don't have anything to do with the use of a single port. A single port can serve multiple connections, and yes - that's a useful way to avoid HOL blocking. What that means is that you have a lot of fine-grained services and as the development of your application proceeds you add more of them, remove them and so on. That in turn requires admins (and the corporate approval process!) to get into the deployment cycle and open the TCP ports as appropriate. The result is that the development basically grinds to halt. That sounds a lot like the desires of admins is in conflict with the desires of your users. I.e., an admin that wants to block anything they don't explicitly allow WANTS to block this sort of mechanism too. The solution IMO is to preserve the port-based services functionality for those that truly care about security and -- optionally -- support some kind of multiplexer such as TCPMUX for those that care more about short deployment cycle. TCPMUX won't do what you're asking - if you're asking to block based on the service type. If it did, then the sysadmin would just block TCPMUX connections to services they didn't know, and you'd be right back where you are now (i.e., without TCPMUX). Again, what is the goal? (note: the goal of the portnames approach is NOT to provide a single multiplexing port; it's to decouple the dest port's two uses - demux info and service identifier. the primary reason for portnames is to allow more than 65K concurrent/timewait connections to a single service; FWIW, I cited it because of its description of the limitations of TCPMUX, not because the approach there was relevant here). That being said, IIRC, there's such functionality in WebSockets as well. Open a connection to fixed pot (80) and particular URL (string), then after the initial negotiation, switch to raw TCP mode and hand the connection to whatever application is suppose to handle it. The reason I don't like that solution is that you have to have web server installed to work as a multiplexer, which is kind of strange. 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). Joe
Re: TCPMUX (RFC 1078) status
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 protocol? Specifically, if I implement a new TCPMUX daemon how likely I am to clash with an existing TCPMUX daemon listening on port 1? It's in the FreeBSD inetd, among others, but to to my knowledge, nobody actually turns it on. There are probably security issues. There are semantics issues to; see draft-touch-tcp-portnames-00 for information (this is being revised for resubmission shortly, FWIW). Joe
Re: Bringing back Internet transparency
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 plug in a host directly! I don't think your anecdote contradicts Joe's claim. In the eyes of your ISP, you were misbehaving, because you were violating their assumption that you would use ONE (1) computer with that connection. If you had been what they consider an honest citizen, you would have gotten a commercial connection to connect more than one. Another data point is Google's recent reversal on network transparency focused on artificially differentiating between perceived commercial and individual customers: http://www.listbox.com/member/archive/247/2013/07/sort/time_rev/page/1/entry/4:390/20130731102314:B16998B8-F9EC-11E2-AF78-DB9DE151F03B/ My experience has been that there are four ways ISPs try to break the Internet's assumption that all nodes are equivalent (any port, any time, any where, IMO), with: 1. asymmetric BW provisioning and throttling 2. NATs 3. short-lease DHCP (i.e., spinning IP addrs every day or faster, to interfere with registering an assigned IP in the DNS) 4. legal means ISPs use a combination of these, but the cheapest one is NATs. Joe
Re: Bringing back Internet transparency
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 respectively) - I'm not focusing on NAT boxes here. Hmm. I don't know what a non-broken middlebox is then ;-) Joe
Re: Bringing back Internet transparency
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 better than these local 'point deployment' boxes. Although I appreciate the sentiment, what people want (ISP operators, or at least some of them), was an artificial way to differentiate home customers from commercial providers. I.e., they wanted to create a differentiation that wasn't part of the Internet architecture, so they put one in. NATs did other things (reuse addresses, block services, etc.), but IMO mostly as a by-product of this primary motivation. It's very hard to do what people want when what they want is to defeat the core concept of the architecture - that all endpoints are 'equal'. Joe
Re: Hugh Daniel has passed away
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 the LED lights. He correlated wavelength with clue - the shorter the wavelength, the higher you stood in his view, AFAIR. -- He visited my office about 12 years ago - unannounced, as was more typical than not. After talking at length, he invited me to dinner with a group of his friends in a nearby town. I mentioned that I was 'closing' on a house in that same town, and would show him after dinner. He rolled up just under a large tree and parked on the street. I asked him why he picked that location, and he said it was because his friend was three lots up the street, and this was the closest vacant spot. He had parked directly at my new house. Through him I met a very interesting sci-fi writer, Renfair frequenter, and food historian that evening, among others, at a restaurant I walk past nearly every day. His contributions to my six degrees was sincerely appreciated and will be missed. Joe
Re: When to adopt a WG I-D
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. We discussed that here a few years ago, and informally decided too long was better than too short and with a lot of pointers to other documents that needed to be read. Is this a tutorial? Mainly. To quote... NOTE:This draft is intentionally non-normative. It is meant as a guide to common practice, rather than as a formal definition of what is permissible. Proposal: maybe don't do this as an Internet Draft, but do it as a tutorial. Or in the TAO, which is fairly clearly non-normative even when issued as an RFC. :-) Joe
Re: When to adopt a WG I-D
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 Farrel wrote: Hi, Dave Crocker and I have this little draft [1] discussing the process and considerations for creating formal working group drafts that are targeted for publication. We believe that this may help clarify some of the issues and concerns associated with this part of the process. We are targeting this as Informational (i.e. commentary on existing process, not new normative definition of process) and would like your input. What is not clear? What have we got wrong? I haven't read the draft yet, and *before* I do so, I'd like to express some doubt whether we should even informally describe this using the word process. It seems to me that it's each WG's prerogative how it does this; it has no impact on the standards process as a whole. The word adopt doesn't even occur in RFC 2418, and it is not used in the context of WG adoption in RFC 2026. In other words, I don't think this action is part of the standards process. It's WG folklore. Brian How should we resolve the remaining editor notes? Thanks, Adrian (per pro Dave) [1] http://www.ietf.org/internet-drafts/draft-crocker-id-adoption-02.txt .
Re: When to adopt a WG I-D
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. Nevermind that it isn't standards track or BCP and that it says quite explicitly that it isn't normative? Yes, nevermind that. ;-) Just the mere fact that it's a separate document will somehow impart and implication of official normativeness? 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 how the IETF works. Then you find out about this doc. Wouldn't you wonder why it was treated separately? Was it that important? Was it not informal enough for the TAO? There's a lot of nuance here, but overall, I said what I meant - it would give the *unintended* *impression* of something beyond what I think is the goal. Joe
Re: When to adopt a WG I-D
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 how the IETF works. OK. So your premise is that someone has been given seriously flawed guidance and based on that we need to fear their misunderstanding of things? 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. Joe
Re: When to adopt a WG I-D
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 that. I disagreed with saying that that document contains everything they need to know. Agreed, but if we have more to say, it would be useful to keep it in a single place - esp. given we have that vehicle for doing so. Entirely different semantics to the two statements. I think it's a dandy starting document. But it's a really crappy 'last' document. Good reason to make it better, rather than fracturing that sort of info, though. And by the way, the draft that's been put forward isn't just for beginners... Nor is the TAO, AFAICT, either. Joe
Re: call for ideas: tail-heavy IETF process
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 if an author values getting their document through the process more than getting it right, in which case one has to wonder why they tried to publish the document in the first place. (I assume you meant authors, not ADs above). No; there are times when the document authors are pressured by ADs to do anything to resolve pending DISCUSSes, rather than stand up to the fact that the issue is either incorrect or the DISCUSS is invalid. The IESG processes documents quite quickly; I don't think it's valid to say that there is some terrifying stall in the document process as a result of the IESG, such that an author needs to chew off their leg to finally get the thing through. Well, there are IESG members who stand their ground even when it's incorrect, such as: - claiming that determining WG consensus is up to the AD, then repeatedly demanding evidence of that consensus - failing to drop a DISCUSS even when it meets their own criteria Those hold up a document too, as you should know (these are examples from your review of my doc). As does demanding a document revision while there remain open ballot positions, as was done today - on this document, to address your pending DISCUSS. Joe
Re: call for ideas: tail-heavy IETF process
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
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 - waiting for resolution Nothing limits the IESG to having a discussion by issuing a DISCUSS; they can issue COMMENTs in any position and simply ask for a dialogue. Because DISCUSS includes these other properties, it influences authors to make changes simply to make a DISCUSS go away, due to pressure by the IESG or their own ADs. That's why they need to be used only where that pressure is appropriate and not inappropriate; that's the reason there are both DISCUSS and NON-DISCUSS criteria, and why it's very important for those in IESG review to hold the IESG to that distinction. Joe
Re: call for ideas: tail-heavy IETF process
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, protocols should not be blocked because they provide capabilities beyond what seems necessary to acquit their responsibilities. 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. Joe
Re: call for ideas: tail-heavy IETF process
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 sacrosanct. There's absolutely no reason to believe that. WGs often make technical mistakes that are uncovered by external review. Even when no such mistakes are encountered, WG output rarely represents rough consensus of all interested parties, and WGs often fail to do due diligence in considering the interests of the broad spectrum of those potentially affected by their work. Of course IESG isn't infallible either, and shouldn't behave as if it is. But review by experts from outside of the WG generally seems to improve the IETF's output. Sure, but note that there is a specific NON-DISCUSS criteria on this point: Disagreement with informed WG decisions that do not exhibit problems outlined in Section 3.1 (DISCUSS Criteria). In other words, disagreement in preferences among technically sound approaches. Finding technical mistakes is good, but imposing the IESG's preferred technical solution over the WG's preference is inappropriate, but happens. 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 are not justification for DISCUSS. Strongly disagree. First, DISCUSS only means that there's something the AD wants to discuss. As noted in another post, it means hold this doc until the DISCUSS is resolved. Discussions can happen as a result of COMMENTs in any IESG position. In particular, disagreements with the WG about technical quality are always appropriate for IESG to raise. Yes. same is true of requests for clarification. Sometimes - there's a specific NON-CRITERIA about clarification, however: The motivation for a particular feature of a protocol is not clear enough. At the IESG review stage, protocols should not be blocked because they provide capabilities beyond what seems necessary to acquit their responsibilities. Ted pointed out that DISCUSS doesn't mean the IESG doesn't like a document - agreed, but it *does* hold up a document until the IESG member clears it. But there are also procedures within IESG to ignore a single DISCUSS vote. So ultimately it takes multiple DISCUSS votes to hold up a document indefinitely. Those procedures take time, so even a single DISCUSS holds things up. DISCUSS is a heavyweight mechanism that holds up document resolution; it should be used only where absolutely appropriate. If the IESG wants to have a discussion with the authors, they are welcome to participate in the WGs or IETF LC, or to contact them out of band. DISCUSS is not supposed to be a heavyweight mechanism, and actually it's hard to imagine a lighter weight mechanism that gives IESG review any weight. Oh, I'm not suggesting removing the DISCUSS mechanism. First, it ought to have a new name - one that makes clear that this is heavyweight. Perhaps HOLD FOR REVISION, which is the net effect it already has. The key bug is that the IESG can't easily issue a question without casting a ballot position, but that may also be a feature. It might be useful to be able to issue a QUESTION withouth changing a ballot position, though. Informal communication doesn't generally work well in practice because it lacks transparency, and it can cause additional delay without resolving the problem. Voting DISCUSS puts pressure on BOTH the AD and the WG to resolve the issue. Which is appropriate only when the IESG should have the right to force that resolution, and when the path to that resolution is sufficiently clear. If there is no path, then vote NO. If forcing resolution and putting pressure isn't warranted, issue a COMMENT on any other ballot position. Joe
Re: call for ideas: tail-heavy IETF process
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 seems necessary to acquit their responsibilities. I strongly disagree with what the NON-DISCUSS criteria say. DISCUSS isn't just for blocking documents. And document quality is as important (in the sense that poor document quality can lead to as many interoperability or other problems) as technical correctness. The interpretation of this particular NON-DISCUSS criterion that Joe has given is simply wrong. The key word to pay attention to to see the error is motivation. The point of this criterion is to eliminate a very specific sort of stall that has been known to happen in the past: the stall where the AD doesn't understand why the document is being put forward at all, and therefore blocks the document until the authors explain the motivation behind the document to the satisfaction of the AD who is holding the DISCUSS. 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. So now we're supposed to accept your interpretation of this rather than the explicit text? This is a real issue that has created real problems in the past, and that is why it is in the NON-DISCUSS criteria. But this criterion _does not_ mean that a criticism that the document itself is unclear is not a valid reason to hold a DISCUSS on it. Agreed - this does not refer to the document. It refers to a specific feature of a protocol. In fact, it's an excellent reason to hold a DISCUSS on it. A lack of clarity in a document can result in it being implemented incorrectly, or in the case of a BCP, interpreted incorrectly. I agree that THESE are good reasons for a DISCUSS, but simply not being clear is NOT. Or in extreme cases, not read at all. There's nothing you can do about that; RFCs are not read all the time. Joe
Re: call for ideas: tail-heavy IETF process
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 of a protocol is not clear enough. What's ambiguous or subject to interpretation about that? The commentary exactly echoes what I said. This does not mean that all lacks of clarity are not DISCUSS criteria: only that a lack of clarity with respect to motivation is not. And yet that is the precise issue of your pending DISCUSS on my current document. 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. Joe
Re: call for ideas: tail-heavy IETF process
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 this is a topic that the IETF as a whole is likely to find very interesting. However, if anyone is curious, they are welcome to read the DISCUSS here and see if they agree with your characterization of my question: http://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options/ballot/ For those who may be interested, the last sentence of the first paragraph is the motivation for this being a DISCUSS position (as opposed to a comment). Which is I think that using a 4-byte ExID runs a real risk of overflowing the available space in the TCP header in real-world circumstances. Except that the document already describes the ExID as either 16-bit or 32-bit: All ExIDs MUST be either 16-bits or 32-bits long. Motivation for the additional two bytes is already explained in the document in several places, notably: The second two bytes serve as a magic number. ... Using the additional magic number bytes helps the option contents have the same byte alignment in the TCP header as they would have if (or when) a conventional (non-experiment) TCP option codepoint is assigned. Use of the same alignment reduces the potential for implementation errors, especially in using the same word-alignment padding, if the same software is later modified to use a conventional codepoint. Use of the longer, 32-bit ExID further decreases the probability of such a false positive compared to those using shorter, 16-bit ExIDs. ... Use of the longer, 32-bit ExID consumes more space, but provides more protection against false positives. Which is why I feel this motivation isn't sufficient for a DISCUSS. I'd be glad to hear others' view of this as well. Joe
Re: call for ideas: tail-heavy IETF process
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 of a feature of a protocol, severe enough that reader of the specification are not able to build interoperable implementations, as a problem for which a DISCUSS can be posted. In my opinion, there are many ways in which document can be unclear beyond the motivation for a particular feature of a protocol is not clear enough. - Ralph Absolutely. Note that issues interfering with interoperability or correctness are among the explicit DISCUSS criteria. Joe
Re: call for ideas: tail-heavy IETF process
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 to take the word discuss literally. An entirely possible outcome is that after discussion, the AD says Oh. You're correct. Pretend I never spoke!. Or the author says Oh. You're correct. We'll change it. Either outcome is good. The trouble with this assumption is the IESG review process. COMMENTS are appropriate for feedback, but the IESG review process is too often considered an *opportunity* for the IESG to make the document better, or (in some case) have an opportunity for their input. 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 are not justification for DISCUSS. Ted pointed out that DISCUSS doesn't mean the IESG doesn't like a document - agreed, but it *does* hold up a document until the IESG member clears it. That can - has - and is - being used as leverage to force changes to documents that are sometimes clearly out of scope (e.g., listed as NON-DISCUSS). DISCUSS is a heavyweight mechanism that holds up document resolution; it should be used only where absolutely appropriate. If the IESG wants to have a discussion with the authors, they are welcome to participate in the WGs or IETF LC, or to contact them out of band. Joe
Re: call for ideas: tail-heavy IETF process
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
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 are not justification for DISCUSS. I had assumed that the term discuss-criteria meant [1] which includes both. Not sure if that's also what you meant but worth adding the URL here just in case some folks aren't familiar with it. [1] https://www.ietf.org/iesg/statement/discuss-criteria.html DISCUSS is a heavyweight mechanism that holds up document resolution; Agreed. But its a keystone in the current process. So getting rid of it would be fairly revolutionary. (Not that I'm against a bit of revolving now and then:-) I am *not* suggesting getting rid of it. I *am* suggesting that it needs to be used only where necessary, and that 'necessary' ought to be clearly proved by: - citing the specific DISCUSS criteria involved - providing explicit information on what would be required to clear the DISCUSS it should be used only where absolutely appropriate. s/absolutely appropriate/appropriate/ would be better. If the IESG wants to have a discussion with the authors, they are welcome to participate in the WGs or IETF LC, or to contact them out of band. With our current tail-heavy process, and ~100 WGs that's impossible in almost all cases. The NON-DISCUSS criteria imply that DISCUSS is not an opportunity for late input. I appreciate that early input isn't practical, but that does NOT provide a rationale for violating the NON-DISCUSS criteria (technical disagreement with the WG, etc. - see the list). The IESG can offer its advice in COMMENTS in other positions. It can make suggestions, and let the authors and ADs decide what to do. But it should NEVER hold a document hostage with a DISCUSS without specific merit. Since some of you asked, here's a *current* example: -- Ted Lemon issued a DISCUSS on a doc I have pending - here's the link: http://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options/ballot/ Note that his DISCUSS raises the point that 32-bit ExIDs don't add value and are pointless (despite having several paragraphs of justification in the doc). That's second-guessing the WG, which is listed among the explicit NON-DISCUSS criteria. There's no clear no collateral damage to the Internet, just damage to those who might use a longer TCP option, and there are implementations that already use this (as well as other TCP options that are much less frugal in their use of option space). It affects only shared use of experimental option codepoints, a situation that's intended to be transient if an option becomes widely used. The choice of 32-bit ExIDs has pros and cons listed in the doc, and both 16-bit and 32-bit ExIDs are allowed. Right now, he's waiting for the doc to be changed to recommend 16-bit ExIDs. I don't disagree with that suggestion, but is it really appropriate to hold a document hostage using a DISCUSS this way? I don't think so. I questioned this process, and he suggested that debating the validity of a DISCUSS was out of scope during IESG review. That's not acceptable to me, and I hope to others. Joe
Re: call for ideas: tail-heavy IETF process
On 5/14/2013 3:00 PM, Joel M. Halpern wrote: It seems to me that if it is really a discussion, then there may be many possible things which could resolve it, and the AD raising the question may not know exactly what is feasible to clear it. Otherwise it is a demand, not a discussions. And in my experience while ADs can be pushy (like the rest of us), they are generally prepared to have discussion. Thus, I find your second item below to be inappropriate. At the same time, discussions do have to be resolvable. If there is no way to address it, then it is not a discuss. But required 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 of it. I *am* suggesting that it needs to be used only where necessary, and that 'necessary' ought to be clearly proved by: - citing the specific DISCUSS criteria involved - providing explicit information on what would be required to clear the DISCUSS
Re: call for ideas: tail-heavy IETF process
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 pretty disrespectful both to the AD and to the working group if the authors make changes to please the AD. 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. If the suggestion is a suggestion, then change your DISCUSS to some other position, and issue the suggestion as a COMMENT. Yes, that's both general advice and specific to the case we have pending, Ted. Joe
Re: The Purpose of WG participants Review (was Re: Purpose of IESG Review)
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 gain consensus on the WG mailing list. Team-building is also useful, but not necessary, and also can happen off-list and at other non-IETF meetings. Joe
Re: Purpose of IESG Review
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 the opinion of the IESG is more important than that of the WG; we should be judging ideas on their own merit, not their origin. Joe
Re: Purpose of IESG Review
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 this opportunity. You could equally say that the IETF last call frustrates the WG process, since a document can fail IETF last call, and this can be extremely frustrating for working groups. Witness the fiasco in the MIF working group when they tried to advance a DHCP route option, for example. IETF LC does not come with a list of constraints of what is in and not in scope. The IETF last call process is important, but it's not a panacea. Too many documents come through the last call process for each one to get thorough review by every IETF participant. The IESG are effectively the sacrificial lambs of the IETF who have to read every single document on the IETF track that makes it through last call. If docs get out of WG LC with no review, then there's a failure of IETF process. Every such doc should be read at least by a few independent reviewers, by the WG chairs, and by the ADs in that area. The same failure can - and does - happen at the IESG level. We can continue to appoint groups with additional rounds of review, but IMO, they are scoped (and the IESG review guidance appears to back up that point). Joe
Purpose of IESG Review
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 according to section 6.1.1 satisfies the applicable criteria for the recommended action (see sections 4.1 and 4.2), and shall in addition determine whether or not the technical quality and clarity of the specification is consistent with that expected for the maturity level to which the specification is recommended. Although I appreciate that IESG members are often overloaded, and the IESG Review step is often the first time many see these documents, I believe they should be expected to more clearly differentiate their IESG Review (based on the above criteria) - and its accompanying Position ballot, with their personal review. My concern is that by conflating their IESG position with their personal review, the document process is inappropriately delayed and that documents are modified to appease a small community that does not justify its position as representative. How do others feel about this? Joe
Re: Purpose of IESG Review
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, currently RFC 2026): The IESG shall determine whether or not a specification submitted to it according to section 6.1.1 satisfies the applicable criteria for the recommended action (see sections 4.1 and 4.2), and shall in addition determine whether or not the technical quality and clarity of the specification is consistent with that expected for the maturity level to which the specification is recommended. Although I appreciate that IESG members are often overloaded, and the IESG Review step is often the first time many see these documents, I believe they should be expected to more clearly differentiate their IESG Review (based on the above criteria) - and its accompanying Position ballot, with their personal review. My concern is that by conflating their IESG position with their personal review, the document process is inappropriately delayed and that documents are modified to appease a small community that does not justify its position as representative. How do others feel about this? That it is too vague to comment on? Please point to specific examples where you feel an IESG member's review went beyond determining the technical quality or clarity of the specification. That would help make the sure-to-be ensuing flamefest more light-filled. I've already done that within the IESG; the point of the message wasn't to have dozens of opinions of whether my feedback was beyond scope, but whether others were getting that feeling as well. At least first... Joe
Re: question about draft-touch-tcp-ao-nat
Hi, Nevil (and the IETF list, now). This is my third attempt at requesting clarification about the status of this document. I have been trying to reach you since November. Since you have not responded to any of my previous posts, I'm cc'ing the IETF list, which I sincerely hope you track. 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 that have not been addressed. Can you please clarify the change of state yesterday from None to Response to Review Needed? AFAICT, the doc has been ready to go into final processing for nearly 4 months now... Joe On 11/28/2012 3:19 PM, Joe Touch wrote: Hi, Nevil, An update draft-touch-tcp-ao-nat-04 has been submitted and should appear in the drafts directory shortly. (the remainder has been deleted for brevity)
Re: Less Corporate Diversity
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 ^ support candidates.. If you define diversity as many different *companies*, sure. There are organizations besides companies that used to participate in the IETF more. Joe
Re: Appointment of a Transport Area Director
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 functions in conference management that used to be done by volunteers to paid staff.) Even government regulatory bodies operate with a mixture of volunteer labor (advisory councils) and paid staff. The solution space seems rather constrained: ... (2) Pay the person a salary while on leave from their home institution/employer. As an example, NSF and DARPA do this for their program managers. The employer still takes a hit and there's some risk to the person that they won't get their job back, but it allows a larger number of individuals to participate. In the US government version of this (IPA), the person remains officially an employee of their home institution; it's a grant/contract to the home institution. So I would break this into two sub-categories: a) pay the person while on leave b) pay the home institution for the person's work as a contract/grant (this is closer to how the NSF, DARPA, and other US govt visiting positions work) They work out quite differently; the latter means you're paying overhead, and can be quite costly but might be more attractive. Joe
Re: Appointment of a Transport Area Director
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 or clever. The job of an AD is to facilitate community efforts, not to direct them. ADs also comprise the IESG, which reviews RFCs before publication. We should not expect to appoint IESG members that need a tutorial on basic protocol principles. Further, if the TSV AD can't stand up for cong control and other TSV-specific work or TSV-specific concerns raised on other drafts, then who will? Joe
Re: Appointment of a Transport Area Director
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 or succeeds does so because it has community consensus and demand, not because an AD was diligent or clever. The job of an AD is to facilitate community efforts, not to direct them. ADs also comprise the IESG, which reviews RFCs before publication. We should not expect to appoint IESG members that need a tutorial on basic protocol principles. Further, if the TSV AD can't stand up for cong control and other TSV-specific work or TSV-specific concerns raised on other drafts, then who will? If you can explain how your note relates to mine, I'd appreciate it. I took your point as suggesting that an AD could get by with less background because they weren't leaders. In the past, ADs have either been people who do lead, or have led in the recent past. If that's not your intent, I still stand by my post as relating to the overall thread, but apologize for any confusion. Joe
Re: Internet Draft Final Submission Cut-Off Today
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 UTC' Mon Feb 25 19:00:00 EST 2013 $ Requires a Unix like system... Finding the current time in UTC could reasonably be left as an exercise for the reader... It could be posted on the Internet Draft submission tool page, including a countdown clock too, if you really want useful ;-) Then again, having these deadlines at all is a bit silly. It just forces authors to informally distribute updates directly on the list, and cuts off access to work that doesn't need to happen in sync with an IETF meeting. Joe
Re: Internet Draft Final Submission Cut-Off Today
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 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 UTC' Mon Feb 25 19:00:00 EST 2013 $ Requires a Unix like system... Finding the current time in UTC could reasonably be left as an exercise for the reader... It could be posted on the Internet Draft submission tool page, including a countdown clock too, if you really want useful ;-) Then again, having these deadlines at all is a bit silly. It just forces authors to informally distribute updates directly on the list, and cuts off access to work that doesn't need to happen in sync with an IETF meeting. Something like documents published less than two weeks before a WG session cannot be discussed in this session would be better. Also, slides published less than one week before a WG session cannot be used in this session. That's fine, though it still puts minor mods in the same class as complete revisions. Maybe we need a two-tiered numbering system, e.g., major revs cannot occur less than two weeks before a meeting where they will be discussed, but minor mods are OK up to 48 hours in advance. :-) Joe
Re: back by popular demand - a DNS calculator
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? It is not really DNS if you have to use an explicit name server. I don't follow your logic. FYI, postel.org entries are hosted on a hidden master DNS server inside the postel.org domain on a research host. The public masters for that domain are hosted elsewhere on production machines. The response you got below is because the public masters hadn't caught up. I'm checking on why that hasn't happened, but in the meantime (as per the web page) you can go directly to the hidden master: dig @dns.postel.org ANY 3.4.add.calc.postel.org Joe % dig @128.9.160.161 ANY 3.4.add.calc.postel.org ; DiG 9.7.3 @128.9.160.161 ANY 3.4.add.calc.postel.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 30695 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;3.4.add.calc.postel.org. IN ANY ;; AUTHORITY SECTION: postel.org. 15 IN SOA dns.postel.org. touch.postel.org. 2013021402 60 30 1209600 15 ;; Query time: 195 msec ;; SERVER: 128.9.160.161#53(128.9.160.161) ;; WHEN: Fri Feb 15 09:19:33 2013 ;; MSG SIZE rcvd: 98
Re: back by popular demand - a DNS calculator
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 Bert's tool has been doing for ages: dig 2.3.*.2.+.rp.secret-wg.org TXT +dnssec http://bert.secret-wg.org/Tools/index.html I'd be glad to know how long that's been up (mine was posted in 2001 for the Sigcomm OO session). AFAICT, that web page was put up in 2003, but I'd be glad to hear otherwise. Some key differences, FWIW: - my variant returns the response as an IP address, rather than inside a TXT record (there's a point to that, as per the OO slides posted on the page above) - the Bert version uses DNS strings that aren't valid (*, +, ',', ++) - my variant has a static number of entries (40,003). That's intentional to avoid potential impact on DNS caches. Joe
Re: back by popular demand - a DNS calculator
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, as compared to the hostname definition that says something more limited? ;-) Patrik 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 in the lookup, AFAICT. It remains a question AFAICT. Joe
Re: back by popular demand - a DNS calculator
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 in the lookup, AFAICT. It remains a question AFAICT. Joe, Except for IDNs (or labels starting with xn-- more specifically), for which there are special rules, it appears to me that the spec is _extremely_ clear that a lookup operation that fails to deal with those other values in labels --including even properly-escaped embedded . characters -- is unambiguously non-conforming. Seems clear to me: RFC1035: The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less. -- If any label were allowed, then why does IDN conversion go so far out of its way to exclude particular strings, e.g., those beginning/ending with '-' and encodes everything 0..7F into a-z/0-9? (I was focused on looking up A records given FQDNs) Joe
back by popular demand - a DNS calculator
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 mapping service) Joe PS - if you do happen to use it as an example, please do drop me a note; I'd be very glad to track that info. and/or include a pointer to any classes that use it.
Re: FW: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFCwith Running Code) to Experimental RFC
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 to compare the results? 4- what is your objective metric for success/failure? Well, its not a scientific experiment, and nor does it need to be. Quoting 3933: -A statement of the problem expected to be resolved is desirable but not required (the intent is to keep the firm requirements for such an experiment as lightweight as possible). Similarly, specific experimental or evaluative criteria, although highly desirable, are not required -- for some of the process changes we anticipate, having the IESG reach a conclusion at the end of the sunset period that the community generally believes things to be better (or worse) will be both adequate and sufficient. My take is that even though 3933 says desirable a couple of times there, it's probably best to not go there, at least in this case, but for now probably more generally. The reason I think that is that I reckon the IETF has got itself into a log-jam that almost prevents us from modifying our processes in any way and every additional word provides additional barriers to doing anything, since there'll always be someone for whom those added words raise what seems to them to be a red flag. Lightweight != vacuous. Perhaps the lack of the discussion of these issues is part of the reason so many previous proposals have not been tried. That isn't a reason to ignore those issues here. But a bigger concern is your reasoning as presented in this response: I've heard only one hypothesis - that this reduces time to publication. I disagree that this is a useful hypothesis to test for the following reasons: - time to publication isn't a goal of the IETF IMO, any doc that isn't useful in 5 years ought to not be published here; we don't need to document every sneeze IMO reduced time to publication is definitely *a* goal. I've heard lots of IETF participants complain about how long things take, lots of times. Perhaps you're in the rough on that. (I also note that this experiment doesn't actually aim for any major reduction in time to publication as it says in the draft.) There are plenty of places where existing process is in a logjam. My experience over the past 15 years is most of the delay happens during the following: - changes in the IETF process where ideas like this throw a wrench into the process, and create confusion I had a few informational docs wait over a year in the queue because a process change was put into effect before the necessary boilerplate was resolved. -- this has a *simple* solution. Grandfather everything that has been submitted to a given queue to changes in that queue's process. - IESG review, during which issues are often raised that were addressed during WG review that are then re-hashed, even though they are not relevant to the area of their appointment Overlapping community review has no impact on either of these. The draft itself also discusses reasons why running code might also lead to better quality specifications. No disagreement there, but better quality doesn't mean the doc wouldn't still need - and substantively benefit from - serial review in increasingly larger communities. - thorough review ought to be a requirement and this 'experiment' potentially compromises that by reducing the overall time of review I think the likelihood of that doing damage during the experiment is very small. Damage = - publishing ideas not sufficiently vetted that later need to be updated/errata'd - wasting the community's time by having a large group review an issue that could have been addressed and corrected within a smaller community Do you seriously think these concerns should outweigh a few weeks of reduced time to publication? In addition, I might be wrong, but the thoroughness of review doesn't correlate that well with the duration of review would be my guess. I've heard many on this list - including myself - point out specific reasons why this should not be believed. If still believe every process can be accelerated, I encourage you to review Brooks the Mythical Man Month. Having this entire community burn cycles on this document speaks for itself. It should have been vetted in a smaller, more invested community first. I'm following the 3933 process. I don't know of any smaller but open venue for discussing rfc 3933 experiments. Perhaps there ought be such, but given how rarely 3933 experiments
Re: FW: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFCwith Running Code) to Experimental RFC
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 anywhere 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 to compare the results? 4- what is your objective metric for success/failure? I've heard only one hypothesis - that this reduces time to publication. I disagree that this is a useful hypothesis to test for the following reasons: - time to publication isn't a goal of the IETF IMO, any doc that isn't useful in 5 years ought to not be published here; we don't need to document every sneeze - thorough review ought to be a requirement and this 'experiment' potentially compromises that by reducing the overall time of review - community resources ought to be considered and this 'experiment' burns group resources due to having a broad group concurrently review a doc that could have been reviewed by smaller groups first Given the limited cycles this community has to review docs, I cannot see a benefit to this experiment that is worth the cost. Having this entire community burn cycles on this document speaks for itself. It should have been vetted in a smaller, more invested community first. Calling something an 'experiment' doesn't make it worthwhile to test. Joe
Re: TSV-DIR review of draft-ietf-6man-ipv6-atomic-fragments-03
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 checks. This document states that: Many implementations fail to perform validation checks on the received ICMPv6 error messages, as recommended in Section 5.2 of [RFC4443] and [RFC5927]. I.e., the second RFC does NOT recommend changes; it documents them. This document should be VERY carefully reviewed to ensure that it does not undo the previous TCPM concerns about these techniques. Joe
Re: TSV-DIR review of draft-ietf-6man-ipv6-atomic-fragments-03
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 documented, but that the TCP standard was NOT being changed to include those ICMP validation checks. This document states that: Many implementations fail to perform validation checks on the received ICMPv6 error messages, as recommended in Section 5.2 of [RFC4443] and [RFC5927]. Are we fine if I remove and [RFC5927]? -- Because RFC4443 does recommend that ICMPv6 messages be validated. Sure. I.e., the second RFC does NOT recommend changes; it documents them. This document should be VERY carefully reviewed to ensure that it does not undo the previous TCPM concerns about these techniques. We can remove and [RFC5927] or change it to ...Section 5.2 of [RFC4443] and documented in [RFC5927] That might do it, but it would be useful if another pair of eyes would check. Joe Thoughts? Thanks,
Re: TSV-DIR review of draft-ietf-6man-ipv6-atomic-fragments-03
Thanks - I wasn't positive about the second one. Glad to have it resolved quickly. Joe On 1/24/2013 5:57 PM, Allison Mankin wrote: Joe and Fernando, I just looked at how RFC 5297 is handled in the draft, to be that other pair of eyes. The first fix is right, to remove reference to RFC 5297 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 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 checks. This document states that: Many implementations fail to perform validation checks on the received ICMPv6 error messages, as recommended in Section 5.2 of [RFC4443] and [RFC5927]. Are we fine if I remove and [RFC5927]? -- Because RFC4443 does recommend that ICMPv6 messages be validated. Sure. I.e., the second RFC does NOT recommend changes; it documents them. This document should be VERY carefully reviewed to ensure that it does not undo the previous TCPM concerns about these techniques. We can remove and [RFC5927] or change it to ...Section 5.2 of [RFC4443] and documented in [RFC5927] That might do it, but it would be useful if another pair of eyes would check. Joe Thoughts? Thanks,
Re: FW: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC with Running Code) to Experimental RFC
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 specific actions under certain circumstances in corner cases of the experiment. C This is a silly idea. First, running code should already be considered as part of the context of review. Second, running code is not correlated to correctness, appropriateness, or safety. See Linux for numerous examples. Third, running code doesn't mean the doc is sufficient that multiple parties can generate interoperable instances. It's merely the sound of one hand clapping ;-) Finally, NOTHING should circumvent the multi-tiered review process. That process helps reduce the burden on the community at large via the presumption that smaller groups with more context have already reviewed proposals before they get to the broader community. This is a bad idea even as an experiment. Joe
Re: FW: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC with Running Code) to Experimental RFC
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 to correctness, appropriateness, or safety. See Linux for numerous examples. Third, running code doesn't mean the doc is sufficient that multiple parties can generate interoperable instances. It's merely the sound of one hand clapping ;-) Your second and third and points seem opposed to your first. The latter ones imply that running code is useless, the first one says its not. I never said useless; I explained several ways in which it alone is correlated to any of the issues relevant to speeding up the review process. Multiple interoperable implementations helps ensure a doc sufficiently describes a protocol - nothing less, but also NOTHING MORE. I don't believe any of us have any quantitative basis on which to base assertions that this will improve or dis-improve our processes or output, or be neutral. (Hence proposing it as an experiment.) It takes more than an unknown to make an experiment. There has to be an hypothesis. Near as I can tell, yours is running code means it's OK to run concurrent review at multiple levels. Please explain why you think that is true. I gave multiple reasons why it is not. Finally, NOTHING should circumvent the multi-tiered review process. That process helps reduce the burden on the community at large via the presumption that smaller groups with more context have already reviewed proposals before they get to the broader community. I disagree with the shouted NOTHING - if there are non-silly ways in which we figure we can improve our processes then we ought be open to trying 'em out. You may or may not be right that this is silly, but merely asserting that it is doesn't make it so. Being stuck with current processes or only ever adding more review tiers would IMO be sillier than this proposal. But that seems to be where we're mostly at. OK, so let's try an experiment where authors with the first name Stephen pay everyone $1,000 to review their docs. It certainly hasn't been tried, so - by your metric - it's worth considering? Some things are simply not. This is a bad idea even as an experiment. Sorry, I don't get the bad aspect - rhetoric aside, in what way do you see running this experiment doing harm? It puts more work on the community at large to review an idea that could have been either rejected or significantly improved in a smaller community before wasting the larger communities time. This document is a prime example of such. Joe
Re: A proposal for a scientific approach to this question [was Re: I'm struggling with 2219 language again]
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. The rules for sliding window are not described entirely in terms of the behavior seen on the line, etc. I have seen specifications that attempted this and the implementations built from them were very different and did not come close to interoperating or in some cases of even doing the same thing. In fact, I remember that we thought the new Telnet spec (1973) was a paragon of clarity until a new site joined the Net that had not been part of the commuity and came up with an implementation that bore no relation to what anyone else had done. This problem is a lot more subtle than you imagine. +1 A protocol *is*: - the states at the endpoints - the messages on the wire - a description of input events (message arrival, upper-layer interface requests, timer expiration) that indicates the subsequent change of state and output event (message departure, upper layer indication, or timers to set) (i.e., a Mealy machine, attaching events to arcs) The wire is the second of these, and entirely insufficient as a protocol spec. Yes, there are two ways to try to write a protocol spec: - procedural defining the above explicitly - behavioral defining a protocol only from its external behavior The difference between these is easy to see for sort algorithms: procedural: quicksort heapsort etc. behavioral: sort AFAICT, on the wire often implies behavioral equivalence, but it's a lot more complicated than just the on-wire messages. A behavioral description of a protocol would treat the protocol as a black box and explain its behavior under every possible input. I'll take procedural descriptions of protocols over behavioral any day. Joe
call for papers - IEEE From Research to Standards workshop
Hi, all, I'm helping disseminate the following CFP for a research to standards workshop at IEEE ICC 2013 in Budapest, Hungary. This meeting is directly soliciting the participation of various standards community members, including the IETF and IRTF. Last year I spoke on a panel contrasting the IEEE, ITU, and IETF/IRTF. I hope this might be of interest to some people on this list, and encourage you to consider submitting a paper on your experiences. If you have any questions on this, please let me know. Thanks, and apologies for any diversion, Joe -- CALL FOR PAPERS 2nd IEEE Workshop On Telecommunications Standards “From Research to Standards” June 9-13, 2013, Budapest, Hungary Co-located with IEEE ICC 2013 http://www.research2standards.net/ Paper abstract deadline Jan 4, 2013 Paper submission deadline Jan 11, 2013 Building on the success of the first edition of the IEEE Workshop on Telecommunications Standards: From Research to Standards (which won the Best IEEE ComSoc Workshop Award at IEEE ICC 2012), we are happy to announce the organization of its second edition in Budapest, Hungary, collocated with IEEE ICC 2013. The goal of this Workshop is to bridge the gap between researchers, scientists, and standards experts in both academia and industry and to promote standardization as an important vehicle for information sharing and cooperation between academia and industry. An additional goal is to bring together experts from different standardization bodies, providing opportunities for closer understanding and collaboration; catalyzing development of more interoperable standards and more efficient and effective communication systems. The Workshop technical program will deliver high quality technical as well as visionary papers that will be reviewed and selected by an international program committee representing both academia and industry with a strong standardization background. All submissions are required to comply with ICC’s guidelines. Accepted papers will appear in IEEE Xplore. Looking forward your submissions to the 2nd IEEE Workshop on Telecommunications Standards: From Research to Standards. Kind regards, Workshop Official Website: http://www.research2standards.net Workshop General Chair • Dr. Tarik 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 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: IETF work is done on the mailing lists
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 meetings, to the extent that the community would want the IESG to refuse to publish documents whose process went as I've described above, on the basis that IETF process was not properly followed? no. Our work is done both on mailing lists and f2f meetings. As co-chair of a few wg, we have been doing great progress during f2f meeting with high-bandwidth interactions. RFC2418 says that business happens in either place: ... All working group actions shall be taken in a public forum, and wide participation is encouraged. A working group will conduct much of its business via electronic mail distribution lists but may meet periodically to discuss and review task status and progress, to resolve specific issues and to direct future activities. ... Overall, WG *decisions* are supposed to be consensus of the WG, not just those who happen to be present at a given meeting, so I would expect that such decisions would be confirmed on the mailing list even if initiated at a meeting. At most meetings I've attended, this is how action items were confirmed. So my conclusion is that: - activity/participation can happen in either place - consensus should include mailing list confirmation YMMV. Joe so document shepherd and AD should exercise judgement on how to see the community consensus/participation. Marc. I realize that this question is going to elicit some vehemence. Please be brief and polite, as you respond. :-) Barry, Applications AD
CFP - 2nd IEEE Workshop On Telecommunications Standards
Hi, all, The following is hopefully of interest to the IETF community. Joe -- CALL FOR PAPERS 2nd IEEE Workshop On Telecommunications Standards “From Research to Standards” June 9-13, 2013, Budapest, Hungary Co-located with IEEE ICC 2013 http://www.research2standards.net/ Paper abstract deadline Jan 4, 2013 Paper submission deadline Jan 11, 2013 Building on the success of the first edition of the IEEE Workshop on Telecommunications Standards: From Research to Standards (which won the Best IEEE ComSoc Workshop Award at IEEE ICC 2012), we are happy to announce the organization of its second edition in Budapest, Hungary, collocated with IEEE ICC 2013. The goal of this Workshop is to bridge the gap between researchers, scientists, and standards experts in both academia and industry and to promote standardization as an important vehicle for information sharing and cooperation between academia and industry. An additional goal is to bring together experts from different standardization bodies, providing opportunities for closer understanding and collaboration; catalyzing development of more interoperable standards and more efficient and effective communication systems. The Workshop technical program will deliver high quality technical as well as visionary papers that will be reviewed and selected by an international program committee representing both academia and industry with a strong standardization background. All submissions are required to comply with ICC’s guidelines. Accepted papers will appear in IEEE Xplore. Looking forward your submissions to the 2nd IEEE Workshop on Telecommunications Standards: From Research to Standards. Kind regards, Workshop Official Website: http://www.research2standards.net Workshop General Chair • Dr. Tarik 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 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
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 assert its rights; authors need to consent (and if submission were consent then the IEEE, ACM, et al. wouldn't need the copyright transfer statements they regularly use) Others have noted that click-based rights transfer may not be sufficient as well (the organizations above largely still use explicit signature agreements). And, ultimately, this won't be determined by analysis, but by a court. Joe On 9/21/2012 1:28 PM, Russ Housley wrote: I believe that the IETF has all of the necessary rights to reproduce, distribute, and display publicly all Internet-Drafts. Here is my analysis: In RFC 1310, March 1992, the IAB describes Internet-Drafts, but it does not define the rights that contributors grant. As best I can determine, the very first I-D was posted shortly after this RFC was published. In RFC 1602, March 1994, the grant of rights becomes very explicit: Contributor agrees to grant, and does grant to ISOC, a perpetual, non-exclusive, royalty-free, world-wide right and license under any copyrights in the contribution to reproduce, distribute, perform or display publicly and prepare derivative works that are based on or incorporate all or part of the contribution, and to reproduce, distribute and perform or display publicly any such derivative works, in any form and in all languages, and to authorize others to do so. In RFC 2026, BCP 9, October 1996, the explicit grant of rights is published in a consensus BCP: Some works (e.g. works of the U.S. Government) are not subject to copyright. However, to the extent that the submission is or may be subject to copyright, the contributor, the organization he represents (if any) and the owners of any proprietary rights in the contribution, grant an unlimited perpetual, non-exclusive, royalty-free, world-wide right and license to the ISOC and the IETF under any copyrights in the contribution. This license includes the right to copy, publish and distribute the contribution in any way, and to prepare derivative works that are based on or incorporate all or part of the contribution, the license to such derivative works to be of the same scope as the license of the original contribution. Internet-Drafts provide important historical records for the open and transparent operation of the IETF. For this reason, removal of an I-D from the Public I-D Archive is a significant action. If someone posted an I-D under RFC 1310, when the grant was not explicit, and they want to have their Internet-Draft removed from the Public I-D Archive, then they ought to request that action from the IESG. However, RFC 1602 and RFC 2026 are quite clear about the grant. The request for removal of an Internet-Draft posted after March 1994 needs to be associated with some legal action or some form of abuse. Russ
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
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 matters is ever decided until a court weighs in. Lawyers will say what they are willing to defend - pro and con - but their statements aren't fact. So even if they claim this is cut-and-dry, it isn't until case is decided. Joe
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
On 9/21/2012 4:38 PM, John C Klensin wrote: Joe, While I've somewhat sympathetic to your position -- I don't think the IETF should be supporting a public archival collection of expired I-Ds, especially older ones, either-- I think you are getting a little over the top. Specifically... --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 that most of the reason for that has to do with implicit or explicit IETF commitments to individuals rather than legal constraints. That is not to say the legal constraints aren't there. IANAL, much less a judge, and have no opinion on that which anyone else should pay attention to. IMO, the IETF should not set an example of post what you want, and take things down only on legal threat. It's reasonable to post what the IETF has rights to. Posting things that the IETF *wants* but does *not* have explicit rights too seems a non-starter. Suppose that, as a modified form of opt-out under the latest proposed policy, you were to send a note to the IESG asking that all of your old I-Ds be taken down from the public archive on the grounds that having them public is abusive of commitments you have good reason to believe were made to you.If the IESG said nope, not abusive enough, you could then either appeal (probably a more constructive way of airing things under our rules than involving the legal process) or claim that the IETF had no rights to keep a document posted to which you believe you have retained copyright and get a DMCA take-down request issued. Such a request would give the IESG and IETF Trust the opportunity to consider how much risk they wanted to assume to keep your documents posted and possibly to discuss that with the community. Sadly, they might consider the odds that you would actually choose to sue in their risk assessment (see below). I expect that might be what transpires here, but if we're in an organization that does that I would seriously reconsider writing future contributions. That wouldn't let you made document availability decisions by default for anyone else (e.g., by forcing opt-in), but would, IMO, focus the discussion in a way that increasingly heated comments on the IETF list would not. Sure, having the IETF step on authors' rights certainly focuses the discussion. I sincerely hope this organization understands its responsibility to the community better, and respects the rights of others in its action (not merely the cost of legal entanglements). ... And, ultimately, this won't be determined by analysis, but by a court. Well, it would be determined by a court only if someone felt strongly enough about a particular document or set of documents to go to the expense of going down that path. Agreed; I'm only noting that this is all conjecture, not fact. ... If no one feels mean-tempered enough to launch such a court case, then the policy won't be settled by a judge, it will stand because no one challenges it. Perhaps. Perhaps those of us who feel the IETF is setting a bad example should just walk away. That solves the problem, right? Joe
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
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 into Junior Lawyer territory here. I'm not. I'm simply refuting *any* argument that starts with because it's useful to the community. Could you answer the question, please? Are you saying that you are unaware, or do not believe that you have already given the IETF a permanent license for all of your I-Ds and all your other IETF contributions, which means it can publish them any way it wants whether you like it or not? I definitely have IDs that predate the new policies, and did not transfer rights to the IETF for those. This horse left the barn so long ago that the barn has long since been torn down and replaced by a parking lot. So could you answer this question - do you pirate DVDs too? That horse also left the barn, and presumably wild horses determine what you think is both legal and appropriate. Joe
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
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 determine whether it's worth the effort/expense to run a public archive, but your utility never undermines my rights as an author. Joe
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
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 starts with because it's useful to the community. There are other arguments - that lawyers will make - that depend on the particular boilerplate used, when the ID was published, whether click-based copyright transfer holds up, and so forth. But utility doesn't drive the law. There are rights -rights of the author, and rights of the copyright holder - which are protected here, and they trump any perceived benefit to the community. Joe
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
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 Action: EMails do with any of the I-Ds that they download. At least one limitation is here: c. Pre-5378 Material. In some cases, IETF Contributions or IETF Documents may contain material from IETF Contributions or IETF Documents published or made publicly available before November 10, 2008 as to which the persons controlling the copyright in such material have not granted rights to the IETF Trust under the terms of RFC 5378 (“Pre-5378 Material”). If a Contributor includes the legend contained in Section 6.c.iii of these Legal Provisions on such IETF Contributions or IETF Documents containing Pre-5378 Materials, the IETF Trust agrees that it shall not grant any third party the right to use such Pre-5378 Material outside the IETF Standards Process unless and until it has obtained sufficient rights to do so from the persons controlling the copyright in such Pre-5378 Material. Where practical, Contributors are encouraged to identify which portions of such IETF Contributions and IETF Documents contain Pre-5378 Material, including the source (by RFC number or otherwise) of the Pre-5378 Material. Note that the standards process is defined in a way that includes archiving, but does not explicitly include publication: b. IETF Standards Process. The term IETF Standards Process has the meaning assigned to it in RFC 5378. In addition, the IETF Trust interprets the IETF Standards Process to include the archiving of IETF Documents in perpetuity for reference in support of IETF activities and the implementation of IETF standards and specifications. 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 published before Nov 10, 2008 since the copyright was not transferred to the ISOC/IETF or their Trustees. Joe
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
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 request. It's interesting how this line of analysis entirely ignores pragmatics. It has been noted by a number of folk that public access has repeatedly been demonstrated to be... useful. That's why they were made accessible. d/ PirateBay believes this too, and helps make movies available for public access, honoring pragmatics. Good luck with that line of reasoning. Joe
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
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 rights that were given to the IETF (IETF contribution), and which have never been time-limited. The expires term and corresponding entire text of the ID submissions guidelines suggest otherwise. So archival and making accessible I-D contributions past the expiration of an I-D is perfectly legal for the IETF, unless the I-D contains an explicit copyright notice to the contrary (most I-Ds from 199x do not seem to carry any copyright notice at all). I've already pointed out text that, e.g., someone might use to make the case to the contrary. Finally, in the US, lawyer isn't who would decide this; a jury would. Where you are _correct_ is, copypasting parts of such an old I-D or the whole document into new documents will in fact require contacting the original author(s)/copyright holder(s) and obtain permission, the Note Well provisions likely will not be sufficient, at least for those old I-Ds. (it is not just a matter of courtesy, but a requirement). I assume the latter is what rfc5378 is supposed to fix. There are several variants of issues that apply, at least three I recall: pre 1994 1994-2008 2008-now This isn't the first time this issue has been discussed on this list. RFC 5378 is intended to address reuse of material, as you suggest - not whether that material can be publicly posted. Joe
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
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 drafts available? Yes. Depends on the IDs, when they were authored, and which version of the boilerplate they contain. Joe
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
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? Yes. Depends on the IDs, when they were authored, and which version of the boilerplate they contain. Can you give a concrete example of an I-D with this problem? I don't ever recall a time when the grant of rights to the IETF had a time limit. R's, John
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
Note well, as you noted well, does not go back to the beginning of all IDs. I.e., this is a tangled mess of different copyrights, different note wells, etc., and it's not as simple as it's the IETF's right to do anything except - maybe - going forward with a new copyright statement for IDs. 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 www.ietf.org around 2001, http://web.archive.org/web/20010413091132/http://ietf.org/overview.html and slightly extended in 2002: http://web.archive.org/web/20020605140239/http://ietf.org/overview.html primarily refering to the IETF process described in rfc2026 section 10: http://tools.ietf.org/html/rfc2026#section-10 10.2, 10.3, 10.3.1 (2), 10.3.1 (5), 10.3.1 (7) 10.3.1. All Contributions 7. The contributor represents that there are no limits to the contributor's ability to make the grants acknowledgments and agreements above that are reasonably and personally known to the contributor. By ratifying this description of the IETF process the Internet Society warrants that it will not inhibit the traditional open and *free access to IETF documents for which license and right have *been assigned according to the procedures set forth in this *section, including Internet-Drafts and RFCs. This warrant is *perpetual and will not be revoked by the Internet Society or its *successors or assigns. So which specific part of including Internet-Drafts and RFCs and This warrent is perpetual caused your impression that there was a time-limit on an I-D contribution? -Martin btw. rfc2026 10.3.1 (2) looks like an explicit non-policy for dissemmination or termination of dissemination to me: 2. The contributor acknowledges that the ISOC and IETF have no duty to publish or otherwise use or disseminate any contribution. I would be OK with a single person from (IESG member or IETF Chair) quickly decides about suspending dissemination of a document based on personal judgement and that the IESG wiggles out by themselves an informal procedure (rather than a formal policy) for safeguarding the process (from bias and abuse). This cuts into their time budget and seems to not be a concerningly frequent occurence to spend much polish on it at this point.
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
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 it means something like expunged from the record, and no longer available for viewing. I think it means no longer current for the purposes of work and discussion. I fully agree to the latter. Expunging I-Ds that are older than 6 months looks like a silly idea to me. Nothing in Note Well indicates that an IETF contribution that is not published as RFC or regurgitated as a successor I-D will be automatically un-contributed from the IETF. 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 An Internet-Draft will expire exactly 185 days from the date that it is posted on the IETF Web site (http://www.ietf.org/id-info/) unless it is replaced by an updated version (in which case the clock will start all over again for the new version, and the old version will be removed from the I-D repository), or unless it is under official review by the IESG (i.e., a request to publish it as an RFC has been submitted)... I.e., this is not a matter of interpretation. If you want to change the rules, then it cannot apply to past IDs unless authors give explicit permission, because the IETF would be changing the terms of this statement. Joe
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
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 An Internet-Draft will expire exactly 185 days from the date that it is posted on the IETF Web site (http://www.ietf.org/id-info/) unless it is replaced by an updated version (in which case the clock will start all over again for the new version, and the old version will be removed from the I-D repository), or unless it is under official review by the IESG (i.e., a request to publish it as an RFC has been submitted)... I.e., this is not a matter of interpretation. 'tis, apparently, because you are still interpreting it differently to how I am. There's nothing in the quote above that says that the expired document will not be available *in the archive*. There's nothing that says it won't be available by Santa Claus delivery either. However, the document states how things will be made available, and how that will change upon expiration. And then the statement you cite further goes on to say this: An expired I-D may be unexpired when necessary to further the work of the IETF, including IETF liaison with other standards bodies. Such action will be taken by request of an IESG member, a chair of the working group associated with the I-D, or one of the document authors. That *clearly* implies that it's not *gone*, else how could it be unexpired when necessary, by anyone's request? Nobody is debating whether the IETF can/should have an archive. The question is whether that archive should be public - which effectively negates the concept of taking the doc out of the I-D repository. And I see you selectively omitted the rest of that paragraph: Such a request may be overridden; e.g., a chair of the working group associated with the I-D will be notified if an author requests unexpiration and may request that the action not occur. This request should be sent to internet-dra...@ietf.org (using the suggested subject line Resurrect I-D filename) and should come from an author, a working group chair, or an IESG member. I recognize the IETF might change this policy, but I want to be clear that I don't consider this is ambiguous to date. If the IETF wants to put all old IDs on a public site, I consider that equivalent to unexpiration, and the authors must be given the right to opt-out. Joe
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
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 series. It was also to encourage authors to post half-baked* ideas without having them persist - either as standards, or in general as something the author needed to continue to defend. I don't think that having an archive of expired drafts weakens that original goal. It weakens both goals. A key complaint has been that the doc disappears from an IETF site. Neither the length nor the name has been an impediment Joe
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
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. The difference today is that we are sort-of admitting officially that obsolete drafts can be found, and that this is useful. Admitting that there is piracy is not the same as the IETF posting them publicly on their site. The word expired is perhaps not ideal; obsolete or out of date would perhaps be more precise, but it's probably too late to change it now. 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). If we remove that rule, then the notion of expiration is outdated. If it's not too late to change the they are removed from the IESG site rule, it's absolutely not too late to remove the Expires: indication on all IDs published as we go forward. Note - I don't agree that past IDs should be posted after expiration without the author's consent. They were submitted with that understanding, and post-facto changing it by the IETF is not appropriate. Joe
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
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. A new draft supercedes that timeout. And if they're useful, then you're admitting that continued discussion can occur after 6 months. At which point there is no meaning to expiration. Any note regarding how long the discussion of a draft should occur would be on the mailing list anyway, and thus no longer would belong on the document. --- I'm baffled by the notion that posting IDs forever is OK, but that simply removing the Expires statement is so controversial. Joe
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
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 documents, and expiration changes the relationship between the draft and the IETF. I have to say that I think it's terribly unprofessional not to hang onto archival material Draft != archival Or do you keep copies of all versions of papers you publish, including the ones submitted for review? In case lawyers might need it, or for the benefit of the public? and frankly it's in the interest of the IETF as an *open* standards organization to keep archival material accessible. Agreed. When you're working on a problem that's been around forever and still hasn't been solved (like, oh, I dunno - firewall/NAT traversal?), easy access to expired drafts is an enormous help. The needs of the community - including the lawyers - do not outweigh the rights of the author or the agreement they make with the IETF to date. The original point of having drafts expire seems to have been forgotten here. That's a pity. It did have a reason, and it was useful. Would you be more comfortable if there were some sort of visual flag that a draft had expired? If you post it, it's not expired. There's no point in claiming otherwise. Joe
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
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 the authors can remove an ID *without needing to provide a reason*. Yes, removal from the IETF site will not expunge copies from the entire Internet, but the IETF site should set the example here, and respect the original intent of allowing an ID to expire. Joe
Re: Draft IESG Statement on Ethertype Assignments for IETF Protocols
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 too. Joe On 9/3/2012 5:02 PM, IETF Chair wrote: The IESG is considering this IESG Statement. Comments from the community are solicited. On behalf of the IESG, Russ --- DRAFT IESG STATEMENT --- Subject: Ethertype Assignments for IETF Protocols The IEEE Registration Authority Committee (RAC) assigns Ethertypes. (See http://standards.ieee.org/develop/regauth/ethertype/.) Some IETF protocol specification make use of Ethertypes. Since Ethertypes are a fairly scarce resource, the IEEE RAC will not assign a new Ethertype to a new IETF protocol specification that needs one until the IESG has approved the protocol specification for publication as an RFC. To let the IEEE RAC know that the IESG has approved an IETF protocol specification for publication, all future requests for assignment of Ethertypes for IETF protocol specifications will be made by the IESG. Note that playpen Ethertypes have been assigned in IEEE 802 [1] for use during development and experimentation. [1] IEEE Std 802a-2003 (Amendment to IEEE Std 802-2001). IEEE standard for Local and Metropolitan Area Networks: Overview and Architecture -- Amendment 1: Ethertypes for Prototype and Vendor-Specific Protocol Development.
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
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 to publish the draft. So IMO the ISOC is then violating the terms of submission of a doc if it posts it publicly in perpetuity. ... I think making it clear that the archive contains expired documents is necessary, but expiry by obscurity isn't going to work. It worked for a very long time. If you're now claiming it cannot work, you need to consider the potential effect on the ID process. If IDs are published forever, ***WHY BOTHER WITH RFCS***? Joe
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
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 gracefully. Speaking as a document reviewer for both Gen-ART and the Independent Submission stream, and for that matter as a generic reviewer of various WG documents, I consider the I-D archive to be an invaluable resource. Looking back to see when a particular change was made can be quite important. It's not always about what is best for *you* or for other reviewers. It's about what encourages a more open exchange of ideas. If the community doesn't think that ID expiration serves that purpose anymore, fine. However, let's make this decision on *that* basis. Joe
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
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. There are reasons not to have this too. As I noted, if the IETF publishes IDs, why bother with RFCs? What other publishing arena keeps its drafts public? Joe
Re: Draft IESG Statement on Ethertype Assignments for IETF Protocols
Hi, Ralph, I agree with your assessment below, but historically the IETF guidelines work more smoothly when cases are spelled out rather than dealt with by omission. I think a few sentences being more explicit about what is not covered would be useful, esp. for the IEEE. Joe On 9/7/2012 9: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 protocol specifications: the IEEE RAC will not assign a new Ethertype to a new IETF protocol specification that needs one until the IESG has approved the protocol specification for publication as an RFC. 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 too. Where do you see any such claims in this statement? What would you change? - Ralph Joe On 9/3/2012 5:02 PM, IETF Chair wrote: The IESG is considering this IESG Statement. Comments from the community are solicited. On behalf of the IESG, Russ --- DRAFT IESG STATEMENT --- Subject: Ethertype Assignments for IETF Protocols The IEEE Registration Authority Committee (RAC) assigns Ethertypes. (See http://standards.ieee.org/develop/regauth/ethertype/.) Some IETF protocol specification make use of Ethertypes. Since Ethertypes are a fairly scarce resource, the IEEE RAC will not assign a new Ethertype to a new IETF protocol specification that needs one until the IESG has approved the protocol specification for publication as an RFC. To let the IEEE RAC know that the IESG has approved an IETF protocol specification for publication, all future requests for assignment of Ethertypes for IETF protocol specifications will be made by the IESG. Note that playpen Ethertypes have been assigned in IEEE 802 [1] for use during development and experimentation. [1] IEEE Std 802a-2003 (Amendment to IEEE Std 802-2001). IEEE standard for Local and Metropolitan Area Networks: Overview and Architecture -- Amendment 1: Ethertypes for Prototype and Vendor-Specific Protocol Development.
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
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 it may not be created, and it may not be published except as an ^ Internet-Draft. The term published is used throughout the process. Web postings are often considered published. Joe
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
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, then expires is no longer meaningful and the entirety of that notion needs to be expunged from the ID process. Joe
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
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. But you haven't addressed SM's comment. The point is that you and I have different views of what it means for a draft to expire. You seem to think it means something like expunged from the record, and no longer available for viewing. I seem to think it means what it wk ways has. The desire to change that is the basis of this thread. I think it means no longer current for the purposes of work and discussion. 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. And I think those are very different things. The fact that expired drafts used to not be available for public viewing on the IETF site does not, by itself, mean that that was or is the intent of expiration. That is exact what it meant. Or are you claiming that it was a coincidence that this entire time that derafts were removed in sync with that expiry? Joe
Re: Gen-ART LC Review of draft-ietf-mptcp-api-05
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 SCTP http://datatracker.ietf.org/doc/rfc6458/ This has been a big mistake in the past, IMO. A key part of the definition of any protocol is its API. It is exactly as important as the on the wire component and the endpoint state and semantics of message exchanges. See RFC793 for a great example. What we know as sockets there is basically a direct implementation of the *specified* API for TCP. I can't argue that this document is a reason for the IETF to correct its past mistake, but the sooner it does the better. APIs ought to be a *mandatory* part of any protocol specification. As such, they should be at the same level as any other part of that spec (e.g.., standards track or experimental). Joe
Re: Last Call: draft-ietf-intarea-ipv4-id-update-05.txt (Updated Specification of the IPv4 ID Field) to Proposed Standard
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 there is no consensus. It certainly does not. That is, though your draft claims to more closely reflect current practice and more closely match IPv6, the way you update rfc791 does not reflect current practice nor match IPv6. It does - it doesn't reflect the errors in IPv6-IPv4 translation, which is not IPv6. Joe
Re: Last Call: draft-ietf-intarea-ipv4-id-update-05.txt (Updated Specification of the IPv4 ID Field) to Proposed Standard
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 to revise 791 to make the text in 2765 correct. Without such a decision, there is no point to publish something based on RFC791 and is not compatible with RFC2765. Sure there is - when IPv6 is not involved. That is the case for ipv4-id-update. At best it makes things a little better for some cases of IPv6-IPv4 translation - which can be noted - but it does not correct for the failings of 2765, which are out of scope. The case above occurs only when the source gets back a packet too big message with a desired MTU less than 1280. which means RFC2460 expects it. Note that this might never happen, in which case there would never be any Fragment header. If you can assume so, let's better assume that accidental ID match never happen and we all can be very happy. My words were ambiguous; permit me to clarify: An IPv6 source might never send packets larger than IPv4 can natively handle - i.e., it could send packets 576 bytes or smaller. In that case, the IPv6 source would never get an ICMP too big because they're not as far as IPv4 is concerned. In that case, the IPv6 source would never insert the Fragmentation Header. That is the fundamental flaw in these IPv6 RFCs, but it is behavior that is out of scope for an IPv4 source. My doc focuses on the behavior of IPv4 sources. However, even when it does happen, there is no instruction above about how to construct the header that is compliant with RFC791. That is the problem. That is, if you insist on RFC791 as is, not enough is specified on how to generate IPv6 ID. Yes, but that does not affect an IPv4 source; it remains a problem, but out of scope for this doc. Further, the source might already be inserting the fragmentation header (e.g., on a 2KB packet). Thus, there can be only one way (the one in RFC2765) to map IPv6 ID to IPv4 ID I have no idea why the fantasy exists that IPv6 packets MUST be translatable into IPv4 based on the existing specs. As specified in RFC2460, this simply isn't the case. Yes, this is a nice goal, but it would have required IPv6 hosts insert 16-bit IDs into *every* packet and make them just as unique as IPv4 does. ... There's no instruction in how fragment headers are constructed in general that complies with RFC791. Is it a problem of RFC791 or RFC2460/2765? RFC2460/2765. Simply using the low 16 bits is not correct. In particular, RFC2460 suggests that its 32-bit counter can wrap once a minute, and that only one such counter might be needed for an endpoint for all connections. Never mind. IPv6 specification is not self consistent at all. Correct - not regarding translation to IPv4. That's what I've been trying to say ;-) Or, are you saying RFC2460 and RFC2765 violate RFC791? Yes. Then, as fixing RFC2460 is politically impossible, we must abandone IPv6 and live with IPv4 forever. I didn't say we couldn't fix - or at least try to fix - this situation. But it remains out of scope for this doc. This document updates RFC791, but does not fix either RFC2460 or RFC2765. This document does not make any statements about how IPv6 generates its IDs. You draft says: This document updates the specification of the IPv4 ID field to more closely reflect current practice, and to include considerations taken into account during the specification of the similar field in IPv6. but, the specification of the similar field in IPv6 is, in your opinion, incomplete, let's finish it first, IPv6 is fine when it talks to IPv6 only. The goal is to make IPv4 work in a similar way. The goal is NOT to deal with translation. IPv6-IPv4 translation has two directions - IPv4-IPv6 (which might be in scope for this doc, but isn't really affected by the changes - we can add a statement on that) and IP6-IPv4 (this doc similarly doesn't break that; if anything, it makes it easier. it doesn't make it completely correct, though - there remain problems that have nothing to do with the changes in this doc that need to be addressed separately. only after which you can revise your draft to include considerations taken into account during the specification of the similar field in IPv6. More specifically, for example, the following statement in your draft: The latter case is relevant only for IPv6 datagrams sent to IPv4 destinations to support subsequent fragmentation after translation to IPv4. is incorrect because NAT646 refer RFC2765. That will be fixed, yes. For another example, Finally, the IPv6 ID field is 32 bits, and required unique per source/destination address pair for IPv6, is, in your opinion, violation of RFC791. No; the violation occurs only
Re: Last Call: draft-ietf-intarea-ipv4-id-update-05.txt (Updated Specification of the IPv4 ID Field) to Proposed Standard
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 specifies that translators can merely copy the low-order bits of the field. Yes, but this is not compatible with RFC791. Moreover, RFC2460 specifies: In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 1280, but must include a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. That is, RFC2460 guarantees that translators can obtain a suitable Identification value from IPv6 Fragment header. The case above occurs only when the source gets back a packet too big message with a desired MTU less than 1280. Note that this might never happen, in which case there would never be any Fragment header. However, even when it does happen, there is no instruction above about how to construct the header that is compliant with RFC791. Further, the source might already be inserting the fragmentation header (e.g., on a 2KB packet). There's no instruction in how fragment headers are constructed in general that complies with RFC791. Simply using the low 16 bits is not correct. In particular, RFC2460 suggests that its 32-bit counter can wrap once a minute, and that only one such counter might be needed for an endpoint for all connections. In that case, the entire number space wraps twice as fast as RFC791/RFC1122 require for IPv4, and it's half the bit-width, so the low-order bits alone wrap 120,000x faster. Or, are you saying RFC2460 and RFC2765 violate RFC791? Yes. I'm afraid you must say so, if you insist on existing systems violate the current specification (quote from abstract of your draft). It quotes IPv6 examples, but does not propose to change IPv6 processing. That may be needed, but that would be outside the scope of this doc. It is inside the scope because RFC2765 specifies how IPv4 ID is generated from RFC2460 fragment header, which is, according to your draft, a violation of RFC791. This document updates RFC791, but does not fix either RFC2460 or RFC2765. This document does not make any statements about how IPv6 generates its IDs. Finally, the IPv6 ID field is 32 bits, but lower 16 bits are required unique per source/destination address pair for IPv6, That's incorrect as per RFC2460. Other RFCs may violate that original spec, but that needs to be cleaned up separately. As I stated above, RFC2460 guarantees a suitable Identification value for IPv4 ID is there in IPv6 fragmentation ID. Not the way I interpret the text, especially because there are other ways to generate IDs in RFC2460 that could be translated to IPv4 that might not result from ICMP errors, or that might never have Fragmentation headers anyway. Or, if you think RFC2460 does not mind ID uniqueness (of IPv4, at least) so much, RFC791 should not either. I think there are a lot of IETF documents that are not reviewed in the correct context of existing standards. I don't think that applies to this draft, though. Joe
Re: Last Call: draft-ietf-intarea-ipv4-id-update-05.txt (Updated Specification of the IPv4 ID Field) to Proposed Standard
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 mean translators must rate limit, or translators violate RFC2765: 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. there is the problem that multiple translators interfere with each other. Yes, even rate limiting translators may interfere each other, which means rate limiting must be done at the IPv6 source node. Regardless, this is outside the scope of the ipv4-id-update doc. In the ID, there are a lot of references to IPv6. It quotes IPv6 examples, but does not propose to change IPv6 processing. That may be needed, but that would be outside the scope of this doc. For example, the following statement of the ID: Finally, the IPv6 ID field is 32 bits, and required unique per source/destination address pair for IPv6, whereas for IPv4 it is only 16 bits and required unique per source/destination/protocol triple. must be modified as: Finally, the IPv6 ID field is 32 bits, but lower 16 bits are required unique per source/destination address pair for IPv6, That's incorrect as per RFC2460. Other RFCs may violate that original spec, but that needs to be cleaned up separately. Joe
Re: Last Call: draft-ietf-intarea-ipv4-id-update-05.txt (Updated Specification of the IPv4 ID Field) to Proposed Standard
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 RFC2765, which does not need port numbers for address mapping: If the IPv6 packet contains a Fragment header the header fields are set as above with the following exceptions: Identification: Copied from the low-order 16-bits in the Identification field in the Fragment header. Flags: The More Fragments flag is copied from the M flag in the Fragment header. The Don't Fragments flag is set to zero allowing this packet to be fragmented by IPv4 routers. the translated IPv4 packets are not atomic with 16bit IDs. Note that the RFC is referred by NAT646 etc. Then, aren't IPv6 nodes are required to rate limit packets they generate with fragment headers assuming 16bit IDs? 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 there is the problem that multiple translators interfere with each other. Regardless, this is outside the scope of the ipv4-id-update doc. Or? Masataka Ohta PS As the RFC specifies ID=0 when DF is set 0, it should also be updated to conform to the robustness principle. That is an error in this RFC, which also is outside the scope of the ipv4-id-update doc. Joe
Re: Last Call: draft-ietf-intarea-ipv4-id-update-05.txt (Updated Specification of the IPv4 ID Field) to Proposed Standard
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 set the IPv4 ID field of atomic datagrams to any value. is changed to: Originating sources MUST set the IPv4 ID field of atomic datagrams to values as unique as possible. which is what the current BSD implementations do. There are implementations that set DF=1 and ID=0 (cellphones). BSD does not make IDs as unique as possible; it selects them according to a pseudorandom algorithm that does not take into account the datagram's source IP, destination IP, or protocol. I.e., BSD code repeats the IDs more frequently than necessary when a host concurrently sources datagrams with different (srcIP, dstIP, proto) tuples. So it would already be in violation of your proposed wording, as would most ID generation mechanisms. Joe
