Re: Gen-ART LC Review of draft-ietf-eai-simpledowngrade-07
On 09/19/2012 04:24 AM, Ben Campbell wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-eai-simpledowngrade-07 Reviewer: Ben Campbell Review Date: 2012-09-18 IETF LC End Date: 2012-09-20 Summary: This draft is mostly on the right track, but has open issues Major issues: -- I'm concerned about the security considerations related to having a mail drop modify a potentially signed message. ... Hm, sounds like a misunderstanding. Did you understand that the modification happens in RAM, and that the message stored unmodified and has the valid signature? If not I suppose extra verbiage is needed. The signature issue has been discussed. The answer is more or less: The WG expects EAI users to use EAI-capable software, and to accept partial failure when using software that cannot be updated. This entire draft is draft is about damage limitation when an EAI user uses EAI-ignorant software (e.g. your phone, if you do your main mail handling on a computer but occasionally look using the phone). That there will be damage is expected and accepted. IMO it's unavoidable. The WG tries to ensure that the damage is not permanent (in the same example: so you can still read the mail, properly signed and addressed, on your computer). FWIW, I mangled a message by hand to see what happened to a signature, and got an angry-looking complaint above the body text. Or maybe it was above the headers. Whatever. Minor Issues: -- It's not clear to me why this is standards track rather than informational. I don't remember. Perhaps because it needs to update 3501. -- section 3, 2nd paragraph: Are there any limits on how much the size can differ from the actual delivered message? Can it be larger? Smaller? It's worth commenting on whether this could cause errors in the client. (e.g. Improper memory allocation) An input message can be constructed to make the difference arbitrarily large. For instance, just add an attachment with a suggested filename of a million unicode snowmen, and the surrogate message will be several megabyte smaller than the original. Or if you know that the target server uses a long surrogate address format, add a million short Cc addresses and the surrogate will be blown up by a million long CC addresses. I doubt that this is exploitable. You can confuse or irritate the user by making the client say downloading 1.2MB when the size before download was reported as 42kb, that's all. I wish all my problems were as small. I'll add a comment and a reminder that the actual size is supplied along with the literal during download. -- Open Issues section: Should Kazunori Fujiwara’s downgrade document also mention DOWNGRADED? Good question. It seems like they should be consistent on things like this. (This is really more a comment on that draft than this one.) I think I've made up my mind that in this case it doesn't matter. Kazunori's task is complex reversible downgrade and has the Downgraded-* header fields, why then bother with the DOWNGRADED response code? But it's not my decision. -- Abstract should mention that this updates 3501 Really? A detail of this document updates a minor detail of that document, that's hardly what I would expect to see in a single-paragraph summary. I know someone who likes to repeat the Subject in the first line of the email body text. Just in case I didn't see it the first time, I suppose. -- section 1: Can you more explicitly define conventional? I assume this means clients not supporting the relevant UTF8 capabilities? This terminology is inconsistent between this and draft-ietf-eai-popimap-downgrade. OK. Arnt
Re: [sieve] Second Last Call: draft-ietf-sieve-notify-sip-message-08.txt (Sieve Notifica tion Mechanism: SIP MESSAGE) to Proposed Standard
Pete Resnick wrote: We were told by the other company employees who facilitated the disclosures, at the time of the disclosures, that this was strictly an individual's failure to comply with the IETF IPR Policy, that the author in question claims not to have understood the IETF IPR Policy, and that the company proceeded to make these disclosures as soon as it discovered that this IPR existed. I have no information to contradict that claim. Barry also said that company procedures have been improved to prevent this particular type of failure in the future. Speaking as Sieve WG member and sieve developer, I'm in favour of treating this as a mishap (albeit a bad one), not an attempt at deception. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Alternate entry document model
On 10/30/2010 10:39 AM, John C Klensin wrote: If that were to be the case, discussion of maturity levels is basically a waste of time. I think it is. The general public perceives RFCs as RFCs, not equally weighty, but NOT ACCORDING TO ANY FORMAL CRITERIA. We might as well get used to that. Therefore, I'd like to have maturity levels as follows. 1. draft-foo-0: No requirements, not even that it passes idnits. 1b. draft-foo-nonzero: Number of nits should decrease. 2. Final draft: No nits, IPR done, Last Call, archival document, foo-area review, etc. 3. RFC, whether good and weightly, flimsy and ignored, or April joke. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Extending the Datatracker to display user-specific lists of drafts
On 10/23/2010 11:27 AM, Julian Reschke wrote: I thought that's what we have Atom feeds for? (at https://datatracker.ietf.org/doc/...) There isn't an atom feed for draft*-foo*-*, only for specific documents/urls. Right? Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: can we please postpone the ipv6 post-mortem?
On 10/11/2010 04:40 PM, Rémi Després wrote: Le 9 oct. 2010 à 02:50, Fred Baker a écrit : Having the same prefix on each side of the residential NAT could be a real pain... With my understanding of how NATs work, I don't see why. Could you elaborate? Admin pain. Many unixes today let you configure the same IP/netmask on two interfaces, and it can be used (don't ask, ok?), and it works as long as it works, but as soon as you get a problem it's a hard one. (Btw, I've seen NATs that reject/discard all packets coming in on the world interface with source addresses in the inside-NAT range.) Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: existing (and questionable) application designs [was Re: US DoD and IPv6]
The problem with such opinions is that a bunch of purple are deploying ipv6, so that in a couple of years you will have to extend your NAT draft to cover communicating with v6 nodes anyway, and what's the point then? Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Tools logins -- Aaaargh!
On 09/03/2010 03:36 PM, Henrik Levkowetz wrote: We've had as a goal for some time to move to having the same login/pw for both the datatracker and the tools pages; I think we'll have to try to move forward with that plan in order to handle the situation, rather than the quick fix proposed above. If you're going to make a substantial change (as opposed to a two-minute fix), then I suggest accepting openid. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Is this true?
It's true that someone said all that. It's probably true that the firewall your boss bought in 2006 doesn't support IPv6. It's probably even true that some people consider this a problem of IPv6 rather than of the firewall. The rest is all bullshit. Conferences with presentations should have a most bullshit per minute prize, with some sort of plaque. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Ad Hoc BOFs
On 08/06/2010 02:45 PM, Ralph Droms wrote: I will confess to describing a problem here without suggesting an associated solution. The natural consequence of your mail seems to be to allow attendees to book spare space at IETF events. Suggested rules: 1. Space is booked by an individual (or up to two, perhaps). 2. The IETF keeps no plan or record of the usage. 3. If an IETF activity needs the space, out goes the individual. 4. The meeting web site shows a map of the free rooms. 5. Large rooms aren't available, only ones. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF privacy policy - still a bad idea
On 07/22/2010 12:33 AM, John Levine wrote: It would be helpful for someone, anyone, to explain in terms specific to the IETF what a privacy policy will accomplish. Prevent cockups. Too much time is spent discussing these issues over and over again. Remember that RFID experiment and how the IETF list blew up with privacy discussion? I'd love to have a privacy policy done, so that next time the poor fools won't accidentally cause another of those threads. (God, it must suck to want to run an experiment and run into one of those threads.) Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSV-DIR review of draft-daboo-srv-caldav-05
Patrik Fältström writes: On 17 jul 2010, at 21.39, Joe Touch wrote: Are you suggesting a new RR instead of the SRV or in addition to the SRV? The latter seems useful; the former begs the question of how many SRV variants we would want. A new RR that is a replacement for the SRV for the cases where one need a URI and not only hostname+port. Otherwise, same syntax and usage as SRV (i.e. prefix of the owner decide the protocol and service etc). It is therefore more a replacement for SRV than replacement for NAPTR (that give back a list of services given a domain name). I feel bad about this proposal. When I published the SRV draft, about a dozen people told me they'd wanted such a thing, for very diferent purposes, which made me feel that I was on the right track. For this draft I have the opposite feeling. People are deploying HTTP redirects, pointers in known or computable locations, pointers in link rel tags, etc, etc. See http://www.sitemaps.org/protocol.php#submit_robots for an example. What I can NOT remember is someone posting gee, I wish we had something like SRV but with URIs, that's what we really need. So, I feel rather uncertain that your proposed RR meets a deeply felt need. It might. Or not. I worry that it'll either be unused, or shortly be found to be insufficient. Maybe more people would want an RR containing a URI template in which clients can insert a userid and whatnot? And really, as Joe asks, how many SRV variants would we want? Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Protocol for TCP heartbeats?
Put differently: The proper job of TCP heartbeats isn't to proclaim a connction dead, it is to proclaim it alive and working, so that L7 heartbeats don't have to be so upgefucked. IMO, a TCP keepalive API needs contain only three functions. Two to answer the questions are any acks overdue, and if so, by how long? and what are the current RTT and bandwidth estimates? and one to provoke the peer into sending an ack. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Protocol for TCP heartbeats?
Ted Faber writes: If an application needs a heartbeat, it almost always needs to be an application to application (layer 7 to layer 7) heartbeat. ... My point is that if you need that layer 7 heartbeat, the layer 4 (TCP) one doesn't help much. I can't think of an application that needs the TCP heartbeat and not the application heartbeat. I can think of several whose L7 heartbeat needs TCP data in order to avoid false alarms. It's really difficult to write an L7 heartbeat which works well with fast connections (ie. detects death soon after it occurs), also works with slow connections (ie. makes few false alarms), and makes no use of TCP data. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 78: getting to/from/around Maastricht
On 07/13/2010 09:23 AM, Jaap Akkerhuis wrote: When in doubt, consult www.bahn.de Since Brussles is i Belgie the last timeI looked, you might be better of looking athttp://www.b-rail.be/main/E/ That's the same software. If b-rail.be is competent about updating its route database with other companies' trains, then the results will be exactly as good as for bahn.de. Sadly, bahn.de seems to have restricted its scope to Europe. Last week I searched for a connection from Oslo to Pyongyang, and bahn.de couldn't show me any. I think there are trains from Vladivostok and/or Beijing, but they're not in the database. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 78: getting to/from/around Maastricht
On 07/13/2010 11:38 AM, Jaap Akkerhuis wrote: I'm not really planning to take a train to IETF-79 but it is an interesting idea. The Dutch internatial railway site http://www.nshispeed.nl/nl/internationale-trein planner does show you the Oslo- Peking trip which seems to take 196 hrs 2 min (including transfers). Enough time to read the drafts on the way and arrive well prepared. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF privacy policy - update
On 07/07/2010 06:57 PM, Iljitsch van Beijnum wrote: In the meantime, BGP and HTTP, to name just two of the protocols without which the internet and the web wouldn't exist, still don't have standard status. What do we want to spend our time on? Create more text that people will end up reading that doesn't add anything to their life or the good of the internet, or make some progress on our chartered work? Didn't you post a message earlier today criticising IETF navel-gazing? And now you suggest that changing an adjective in the boilerplate on the first page of an RFC would be progress? Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Protocol for TCP heartbeats?
A lot of the application code I've seen could be described as second-guess one or more TCP timers, add pepper and salt, serve as desired. The second half of that is obviously not amenable to standardisation. The TCP stack cannot take any action. But the first part seems more... reasonable. I think the TCP stack can inform the application of its state, better than it does via the APIs I know. Of course it's a local matter, not really IETFish. Where is the boundary these days? Didn't some RFC extend the Berkeley sockets API for v6? Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The IPv6 Transitional Preference Problem
On 06/17/2010 01:38 PM, Sabahattin Gucukoglu wrote: Just in case someone here wants to take sides, have a look at this thread on the IPv6 discussion list at Apple: http://lists.apple.com/archives/ipv6-dev/2010/Jun/msg0.html (the thread actually goes back earlier than that, but I can't be bothered going looking for it because I can't stand that awful PiperMail interface) What I've never understood is why (almost) everyone tries addresses in sequence instead of in parallel. Even applications that routinely open two or more concurrent connections to the server first try IPvX, then wait many seconds, then try IPvY. Why not try both in parallel and use whatever address answers first? Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The IPv6 Transitional Preference Problem
On 06/17/2010 07:24 PM, Martin Rex wrote: If you look at hostnames such as hp.com which have 13 IPv4 listed in the DNS, it would probably have a significant effect on their infrastructure if suddenly every client would attempt 13 parallel TCP-connects and kill 12 of them pre-natal or during infancy. Set up a strawman and shoot him down. Feel clever. I said try v4 and v6 in parallel, not try every IPv4 address in parallel. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
Mark Andrews writes: Seriously, I do think it is time that the root and TLD's had IPv6 only name servers. Why (and do you mean all 6-only or one 6-only)? Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
On 05/31/2010 03:49 AM, Phillip Hallam-Baker wrote: So we need to extend the UPNP protocol so that when the local NAT box receives a request to open up an external port, it relays the request to the carrier NAT. So what are you waiting for? Go ahead, read http://upnp.org, find the relevant WG, propose the extension, talk to implementers, you know the routine as well as I do. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
On 05/30/2010 04:44 PM, Sabahattin Gucukoglu wrote: BitTorrent is popular, yes. People at home *are* behind NAT boxes, with all the usual pain that implies *. It's just that BitTorrent, being a straightforward TCP protocol with no embedded payload addresses **, can operate behind NATs, and those NATs can be configured either manually or automatically by users or their client software ***. If the NAT should move to the ISP, it seems possible that this is no longer true. Not quite. 1. Bittorrent clients connect to each other via TCP. Each connection is incoming at one end. Torrent clients mostly use UPNP to accept incoming connections. 2. UPNP is an ethernet-level protocol (it uses UDP/IP broadcasts), so it works only if the USER is on the public internet. Hence, NAT within the user's network is now very different from NAT within the ISP's network. That's why I said the wide popularity of bittorrent shows that USERS are on the public internet. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
On 05/28/2010 03:42 PM, Jari Arkko wrote: We will need also mainstream news articles in the latter. Expect that around the end of July, intoning «In one year, the Internet Assigned Numbers Authority is expected…» Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
On 05/28/2010 05:01 PM, David Conrad wrote: On May 28, 2010, at 1:29 AM, Brian E Carpenter wrote: Today, most users are *not* behind ISP NAT or some other form of global address sharing. An interesting assertion. I'd agree on the ISP NAT part. Not sure about the other form of global address sharing part, since single NAT is address sharing. Do you have any data? Consider bittorrent. Bittorrent clients generally can run behind NAT, but in that case they have to be on the same ethernet as the NATbox, so it's a safe bet that the bittorrent USER has a real address. Am I stepping out on a limb if I state that most users can run bittorrent? Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Formal SPAM Compliant filed against Anderson...
On 05/05/2010 03:48 PM, todd glassey wrote: What that means is like auditors NO email may be excluded from the history of the vetting process lest the practice be subjected to random and uncontrolled censorship. You seem to be saying that pests cannot be kicked off WG/IETF lists... or do I misunderstand? Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Formal SPAM Compliant filed against Anderson...
On 05/03/2010 08:21 PM, todd glassey wrote: These are extensions for Sendmail. No. Sendmail is just one implementer. There's at least a dozen others. The problem is that Dean created a list outside of the IETF and subscribed IETF members to it. Just use a sieve script (or anything else) to reject the mail. The list software will eventually see that mail to you is persistently undeliverable, and unsubscribe you. The members have NO passwords and cant get them without interacting with Dean making this harassment. You don't need the password to unsubscribe. Just let the mail bounce, and have a nice day. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Formal SPAM Compliant filed against Anderson...
On 05/03/2010 07:48 PM, todd glassey wrote: Maybe Joe but I do not want to be a party to his mailing lists, and he will not allow me off of them, so I have no choice but to file the spam compliant. I direct your attention to the IETF's standard for unilateral list unsubscription, RFC 5228 as extended by RFC 5429. Dean subscribed me too, but I had forgotten about it until just now. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Pointing to IANA registries
Ned Freed quotes Jari Arkko: (That being said, I wonder if some tool magic would display these references as pointers, just as already happens for normal references.) 1925, 6a. This wierd resistance to including useful information in our documents may have made some small amount of sense in the past when things were less clear. It is completely silly and totally counterproductive now. +1 It's 2010 now, lots of people know how to set up the URL scheme for a site so URLs can be stable for a long, long time. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Rationale for public, non-subscribable mailing lists
Florian Weimer writes: Okay, you're using Mailman to administrate team membership. Let me say that I think this is a bit bizarre, but it's some sort of technical reason. (Other organizations keep team rosters and mailinglist membership separate.) The IETF doesn't have members, it has participants. See? Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publishing call for discussion?
On 04/18/2010 06:58 PM, Martin Sustrik wrote: Is there a standard way to publish a call for discussion memo? Yes, an internet-draft, perhaps containg prose such as this draft is intended to initiate discussion. At this time, the author does not intend it to reach RFC status. A little later, a BOF session invitation serves some of the same purposes. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: T-shirts?
Simon Josefsson writes: Mark Atwood m...@pobox.com writes: Their quality is not that great, and they want too big of a cut. Is the alternative -- i.e., no t-shirt and no revenue for IETF -- better? That would be like publishing -00 drafts that suffer from lots of idnits: Simply unthinktable. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Why the normative form of IETF Standards is ASCII
On 03/19/2010 01:49 AM, Tony Finch wrote: Boggle. A major advantage of xml2rfc compared to HTML is that it does the numbering for you, and you don't have to manually maintain cross references. I don't have any problem editing the source in one window while viewing the presentation document in another. (I do. Short version: One window good, two good, three bad, and there's already the email I'm answering and an editor.) Let me restate your message in unkind terms: A major advantage of xml2rfc is that it handles the numbering for you. You handle the numbering by opening an extra window. That's unkind phrasing, but hopefully not bad enough to offend. If a tool handles something for me, then I expect not to have to handle that same thing. In my opinion, xml2rfc just changes that problem instead of solving it, and the changed problem isn't noticeably better _for_me_. It could be solved within xml2rfc, e.g. by having it edit the source and record the number the number there. But xml2rfc doesn't do that now. (That would also help with the other kind of cross references, see [19] section 4.2 when [19] is updated. The likelihood that 4.2 is renumbered shrinks, since xml2rfc can warn when it happens.) Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Why the normative form of IETF Standards is ASCII
On 03/18/2010 09:37 PM, Julian Reschke wrote: And how are numbered lists a problem? I thought it was a pain because I got comments referring to x and the file I edited contained no x. xml2rfc generated numbers, people used them to me, I didn't see them in the source. In general I think the RFC format should use author-visible numbers in the cases where those numbers are used in email, and might benefit from being unchanged in the next revision of the RFC: Sections, list items. Not references, people don't often refer to those by number in email. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
Doug Ewell writes: So Microsoft Word inserted a registered-trademark symbol into an *internal properties field* of a PDF file whose *contents* were claimed to be pure ASCII, and now it is claimed that this demonstrates not only that the contents of a PDF file cannot be plain ASCII, but also that HTML is too unstable for a reduced-feature profile to be successful? For an Engineering Task Force, this group sure does surprise me sometimes with its logical reasoning No, Ohta-san surprises you. FYI this is an invariant: Ohta-san continues to surprise you, even after you grow used to him. (At this point I would like to remark that I am sure Ohta-san has good and valuable insights, and that I wish they were easier to notice.) Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: What day is 2010-01-02
Cullen Jennings writes: I just got abused by someone reading the IESG web pages and pointing out dates like 2010-01-02 , are confusing. Is there a better way to do dates that we should be using on the ietf.org web pages? Those are RFC 3339 dates. Tell him to write a draft-rfc3339bis if he's unhappy with RFC 3339. If he thinks that's unreasonable, explain that you're being restrained, and that his proper punishment would be to specify imperial replacements for kilobyte, megabit and their ilk. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Why the normative form of IETF Standards is ASCII
Hi Dave, why don't you write a draft? Some possible section headlines: 0. Introduction, abstract, boilerplate 1. Lessons learned from 1.1. xml2rfc 1.2. XSF 1.2.1. Why the XYZ doesn't use RFCs 1.3. W3C 2. Tools to be leeched 3. Generating ASCII 3.1. Limitations on the source 4. Turning existing documents into the new format 5. Why HTML and unicode instead of... 5.1. PDF/A 5.2. Microsoft Word 5.3. 72-column ASCII 5.4. 72-column UTF-8 5.5. Undocumented running code 6. Author, references, acknowledgments 7. More boilerplate And so on. Personally, I see the sense in moving from ASCII to UTF-8. Unicode has beaten off everything else now, it's a clear and safe choice, and non-ASCII characters are used more and more often. It's not so clear to me that bold/italics/hyperlinks are worth the change, not to mention graphics. Btw, when you say the authoring format, I think you may overestimate IETFers' willingness to march in step. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: xml2rfc 1.34 on Ubuntu
On 02/04/2010 05:25 PM, Melinda Shore wrote: Suresh Krishnan wrote: If you are one of the persons who were frustrated waiting for the new 1.34 version of xml2rfc to get into the Ubuntu disribution channels, I'm unclear on this - why wouldn't they pick it up from resource.org? apt-get update is so much easier. apt-get update handles 99.9% of what I need to update, why should the last fraction of a percent be different? Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-jabley-sink-arpa, was Last Call: draft-jabley-reverse-servers ...
Shane Kerr writes: Various top-level domains are reserved by [RFC2606], including INVALID. The use of INVALID as a codified, non-existent domain was considered. However: o INVALID is poorly characterised from a DNS perspective in [RFC2606]; that is, the specification that INVALID does not exist as a Top Level Domain (TLD) is imprecise given the various uses of the term TLD in policy forums; Hm. Then why doesn't this document supersede 2606's imprecise specification with a better one? o the contents of the root zone are derived by interaction with many inter-related policy-making bodies, whereas the administrative and technical processes relating to the ARPA zone are much more clearly defined in an IETF context; That can be put that more clearly: The IETF doesn't have sufficient authority over the root zone to publish 2606 and ensure its continued accuracy. My answer to that is that if so, then most of 2606 is broken, and it's necessary to much fix more than just the paragraph that defines .invalid. o the use of ARPA for purposes of operational infrastructure (and, by inference, the explicit non-use of a particular name in ARPA) is consistent with the purpose of that zone, as described in [RFC3172]. Ie. if .invalid has to be dumped, the replacement should be in .arpa. I can accept that. _If_ it has to be dumped. Maybe .invalid was a bad choice in the first place. But that's water under the bridge. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Internet Wideband Audio Codec (codec)
Mans Nilsson writes: But we are not running out of proposals for codecs to adapt. Both CELT and SILK seem reasonable. Speaking for me as a user, MP3 and AAC are at least worthy of consideration. Someone said on this list that they waste bandwidth, but VoIP's main problem for me as a user is low speech quality, not unacceptable traffic. I hear fine voice quality on 128kbps mp3 radio streams and really fine on 176kbps ogg; I'd like to have that for phone calls. rnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP
Joe Abley writes: I'm saying that the body that administers the root zone is not the IETF. Not being a policy person I don't have any specific fears, but I'll observe that the set of people who make policy that affects administration of the root zone has a fairly small intersection with the set of people who participate in the IETF. Yes. Which is a reason, but IMO not a sufficient one. Your judgment obviously differs. I appreciate that the set of ARPA servers and the set of root servers today are very nearly the same, but it is a difference. Yes. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
John Levine writes: If other people agree that it's a good idea to have a place that IANA can point to for the reserved names, I'd be happy to move this ahead. Or if we think the situation is OK as it is, we can forget about it. I'd be happier with some sort of list (I was surprised by its length, and IMO that's a sign that the list is needed) and like your document. (BTW. You mention _proto and _service. Neither is reserved for SRV. SRV uses_tcp, _udp and other _proto names. I think it would be stupid by use them for any other purpose in the DNS, but don't think that justifies reserving _ah, _ax25, _ddp, _egp, _eigrp, _encap, _esp, _etherip, _fc, _ggp, _gre, _hmp, _icmp, _idpr-cmtp, _idrp, _igmp, _igp, _ip, _ipcomp, _ipencap, _ipip, _ipv6, _ipv6-frag, _ipv6-icmp, _ipv6-nonxt, _ipv6-opts, _ipv6-route, _isis, _iso-tp4, _l2tp, _ospf, _pim, _pup, _rdp, _rspf, _rsvp, _sctp, _skip, _st, _tcp, _udp, _vmtp, _vrrp, _xns-idp and_xtp. But we have a fun game of TLA bingo on the list and see who uses/remembers most of those!) Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
I seem to have a problem with short words this week (can, to etc.). They spontanteously mutate or disappear. Sorry. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP
Joe Abley writes: On 2009-12-25, at 06:02, Arnt Gulbrandsen wrote: What is the actual difference between the proposed sink.arpa and the existing .invalid? (a) Our idea when we chose that name was to try and make the policy environment within which the (non-) assignment rule was to be instituted clear. The administration of ARPA is fairly clearly defined, and lies fairly clearly within the policy control of the IETF and the IAB. The administration of the root zone has a far greater audience of participation, and is hence more likely to be subject to future change. Naming the (non-existent) name under ARPA avoided this potential headache. I don't get it. Are you saying that you think it's possible that someone will come along and overturn RFC 2606, and that that someone wouldn't overturn any .arpa-related rules? (b) SINK.ARPA is a hostname whereas INVALID is not, This is a strawman; every subdomain of .invalid, so 2606 provides something like 36^254 invalid hostnames. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP
John C Klensin writes: I guess the issue for me is that I want to see either (i) Exactly one name allocated, with no hand waving about registries and other, similar names. +1, but I want to add a question: What is the actual difference between the proposed sink.arpa and the existing .invalid? Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: but ipv6 wasn't dead
Dave CROCKER writes: They think v6 is not ready for production use? Production quality is one thing, headline-worthy selling point is another. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)
Simon Josefsson writes: Arnt Gulbrandsen a...@gulbrandsen.priv.no writes: Simon Josefsson writes: There is no requirement in the IETF process for organizations to disclose patents as far as I can see. The current approach of only having people participate, and disclose patents, in the IETF is easy to work around by having two persons in an organization doing different things: one works on specifying and standardizing technology, and the other is working on patenting the technology. How can you practically avoid the first person knowing about it? Make sure (through confidentiality agreements) that the second one do not talk with the first? Putting them in different continents helps. The patent submitter has to be the inventor, so the person who works on standardisation has to not talk to the inventor at all for this scheme to work. This seems rather far-fetched to me. Not one of my greatest worries. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
james woodyatt writes: If it could be published as standards-track, instead of informational, *without* *any* *further* *delay*, that would be excellent. However, I believe there is nothing to be gained for the Internet community by any further delay in publishing this important document. It should have been published years go, fergawdzakes. Faster, please. It's not difficult to get a standards-track RFC out quickly from this point. Unusual, yes, but not difficult. Mark Crispin did it in a week or so for RFC 4315 (another basically sound document with severe but superficial problems). The document author/editor has to react to comments and fix issues promptly. That's all there really is to it. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)
Simon Josefsson writes: There is no requirement in the IETF process for organizations to disclose patents as far as I can see. The current approach of only having people participate, and disclose patents, in the IETF is easy to work around by having two persons in an organization doing different things: one works on specifying and standardizing technology, and the other is working on patenting the technology. How can you practically avoid the first person knowing about it? Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] secdir review of draft-melnikov-imap-keywords-06
Samuel Weiler answers Alexey: Isn't it enough to have them in a consensus doc?) And how do you expect the expert to encourage/enforce the SHOULD, given the favour registering it over requiring perfect documentation guideline? Again, the current text isn't as clear as I'd like. This is intentional. This is a judgment call by the expert. This sounds inconsistent. I'm hearing it's within the scope of the expert's judgement to require an IETF Consensus doc and In cases when an IMAP Keyword being registered is already deployed, Expert Reviewers should favour registering it over requiring perfect documentation. If I were an implementer who got told you need a consensus doc, I'd be more than a little tempted to go ahead and deploy, then reapply for the registration. That's now how it happens. The consensus issues mostly have been about naming (different names for the same thing), and IMO were caused by lack of knowledge/communication. Merely talking two the expert would likely fix most. Also, I'd like to mention that Lisa asked two people whether they could serve; both of her nominees are people who would be likely to give helpful answers, not send implementers away with one-sentence answer such as go write a consensus doc. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
Dave Cridland writes: So I reiterate - I see no reason not to charter a working group to revise this specification (and dns-sd), and I would welcome such a group being chartered such that it cannot make any incompatible changes to the protocol. +1 Except that I'd put the compatibility requirement in terms of deployed code rather than the current draft. Mumble SRV RR mumble compression mumble. The final RFC must be compatible with a version b, c version d and e version f, and if possible with other deployed implementations known to the WG for some values of a-f. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Logging the source port?
Phillip Hallam-Baker writes: If people are required to track the source port, it is hardly unrealistic to expect them to abandon a file format that does not meet their legal obligations. A misunderstanding, perhaps. Where I live, what's being talked about is laws that govern residents of this jurisdiction (connecting to servers here, or abroad, or often in the neverland of botnets). You seem to be thinking about laws that govern the relationship between servers located here and users everywhere. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Logging the source port?
Stephane Bortzmeyer writes: On Fri, Nov 13, 2009 at 10:49:36AM +0100, Arnt Gulbrandsen a...@gulbrandsen.priv.no wrote a message of 11 lines which said: Therefore, I think it's safer to say that it's the NAT operator's responsibility to log enough. Umpteen million web sites will continue to use apache's common log format, so the NAT operator has to log what's needed to work with that format anyway. How could it be possible? The only way I see for the NAT operator to be able to say that the customer X went to www.priv.no at 2241 UTC is to log not only the source-address/source-port mapping but also the *destinations*, which create obvious privacy issues (and would make the log *much* larger). Yes. But do you see a way to avoid that, except by unrealistic declarations such as all apache installations that use the common log format must be changed? It's not just apache either, all other (web and other) servers that don't log source port. (Btw, there is no www.priv.no, and these days I don't think you can get anything else under .priv.no either. The dozen-odd people who have .priv.no domains are allowed to keep them, that's all.) Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Logging the source port?
A really big NAT serving, say, eighteen million customers, can easily be so dense that if there's a bit of clock skew between a web server and the NAT operator, another customer might have used the same port at the time recorded by the web server. Therefore, I think it's safer to say that it's the NAT operator's responsibility to log enough. Umpteen million web sites will continue to use apache's common log format, so the NAT operator has to log what's needed to work with that format anyway. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before
Fred Baker writes: I'm not sure I agree that Friday is a problem; the problem is that we have N working groups asking for M meetings and N*M needs to be = that fixed number. Friday is a solution, one that has certain downsides. Stanislaus doesn't like the solution and IMHO has not proposed a solution that tells us how to better manage the demands on the resource. The hotel has X meeting rooms, and X is known when the location is announced. If N*M/X=4 and the increased density doesn't lead to more problems than Friday does, then Friday is unnecessary for that particular meeting. Right now, the agenda is based on the chairs' perceptions of conflicts. It could be based on registrants' wishes, instead, which I think will permit a higher degree of parallelism without an increase in conflicts. That is, when you register, you click which WGs you really want to attend and which ones are also interesting, and the agenda is computed from that. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before
Scott Brim writes: Even a full Friday isn't enough to remove the conflicts. In fact I'm triple-booked on Friday itself. There is no chance the IETF will fit in 4 days. That hasn't been possible for years. Why do so many people in WG meetings read mail, look bored and hardly say a word, then? Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before
Scott Brim writes: Seriously, are you suggesting that it might be possible to cluster WGs together so that people can stay for parts of the week? I hadn't thought of that... No, I was suggesting that if registrants explicitly say which WGs are really interesting (conflicts in that set spoil my trip) and which are less interesting (I'll attend those since I'm there anyway), then it may be possible to use more meeting rooms for a shorter period, without spoiling people's trips. It really depends on how many people would include forty WGs in the really important for me set. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: OK, final NAT66 argument (Was: NAT Not Needed To Make Renumbering Easy
Masataka Ohta writes: Only if IPv6 were worth deploying. Isn't this a little... late? A few hundred million devices are deployed with IPv6, including all the commonly deployed versions of Windows and IOS. By comparison, here's an overview of how an alternative might fare: 1. Some drafts are published. 2. A BOF is held at IETF77 (fortunately for this BOF, IETF77 is held in a country that cherishes free speech). 3. Some more drafts are published. 4. There's fighting over whether to do a WG at all, and vile fighting over the design of the perfect IPng. 5. A WG has its first meeting at IETF79. 6. On the Tuesday of IETF80 the IANA switches to armageddon rules and transfers the last ten /8s to RIRs. 7. On the following Wednesday, the press reports that the internet is out of addresses and IPv6 becomes a big buzzword. Game over. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IPv4 addresses eaten by... what? (was: IPv6 standard)
There is another question, which isn't nearly as thoroughly discussed. Clearly, IPv4 processes are allocated as part of a number of different processes. Chain X opens the 16001st outlet and wants that to have exactly the same computer/network setup there as in other 16000. Telco Y adds another UMTS customer and needs another IP address for that. And so on, and so forth. Once there aren't any more IPv4 addresses (on terms acceptable to the people involved) these processes have to change in some way. I'm not interested in _how_ they have to change. My question now is instead: What are the processes that are responsible for most allocation at the moment? Has anyone surveyed that? Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: One level up on the IAOC decision in re: China.
Bill Manning writes: hum... from a strictly social POV, this whole argument seems to hinge on an us v. them mentality. To me half the participants sound like Germans going on vacation to Italy and wringing their hands because of all the horrible things that could happen if the Italians ever enforced their laws. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [sasl] Last Call: draft-ietf-sasl-scram
IMO, this is a close relative of a different problem, one that's old and well-understood: Characters that shift to different keys when you cross a boundary. I (now) live in Germany and come from Norway. Germany has Y and Z swapped. Shortly after I started travelling to Germany, I stopped using Y and Z in passwords. They were too much trouble. This is (at least among the people I know) the common solution. I may well be making a silly mistake, but my gut says that the compatibility mappings will not have a serious enough impact on password entropy that we must make an effort to migrate from SASLprep. I agree, because I think that if a character doesn't have a reliable, unchanging representation, then using that character in a password today is begging for trouble. Can't be typed on the wrong keyboard/OK, can't be transmitted through a program that happens to normalize the right/wrong way, etc. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 standard?
Steve Crocker writes: Today, one can pretty much count on IPv4 connectivity around the world, and one can also count on being to reach almost any service (Google, Amazon, CNN, etc.) via IPv4. What's the estimated date when those two statements stop being true? When colo vendors start renting 6-only servers cheaper than 4+6 servers. Amazon and other well-known servers will still provide IPv4, but a first few game servers and private/secret warez depots will not. Arnt (original ftp admin of the great warez site langnese.nvg.unit.no) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 standard?
Steve Crocker writes: I have trouble believing this will all happen in less than 20 years. I do not have trouble imagining it might take much longer. There is one thing that makes me think it'll happen more quickly: 1. I assume that there'll be a market in IPv4 addresses. 2. And that people will want to tradel smallish blocks. 3. And that random ISPs won't be inclined to stop filtering small BGP announcements. 4. So, to combat point 3, IPv4 will be increasingly tunnelled, and thereby more fragile and unreliable than IPv6. Much like how the IPv6 tunnels have made IPv6 unreliable and fragile in the past. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 standard?
Eliot Lear writes: Historic is appropriate when we want to make a statement about the appropriateness of the technology. However, we probably enter a huge bureaucratic entanglement of what happens to all of the docs that normatively reference 791, 792, and 793. And that's another question, what precisely DO we make Historic? In five years, someone who shows up in a WG saying that so-and-so doesn't work with NAT will be met with relieved smiles, and someone will say that's history ;) Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iana-ipv4-examples (IPv4 Address Blocks Reserved for Documentation) to Informational RFC
Jari Arkko writes: What should we do about this block? Some of the potential answers include documenting its role, ... Document its role. There are too many examples out there that use 10/8, and I think the reason for the many 10s is that they're easy to use in good writing. It's hard to write good examples and lucid text if all the different identifiers must start with the eight characters 192.0.4.. The other alternatives I could think of don't seem to have significant advantages. Delaying armageddon is surely desirable, but a delay of a few hours is not significant. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Actual IPv6 deployment observed
Jeroen Massar writes: No, it is not Native IPv6 over DSL or any other form unfortunately. You have to start thanking Microsoft for pushing 6to4 and especially Teredo, having it automatically on new platforms and having clients like uTorrent auto-enable it on install for those that don't. uTorrent seems to be the guilty party, since it correlates with TPB. This must mean that silently enabling IPv6 increases the number of people for whom IPv6 works by a factor of around 100 (from 0.01% in the general population to ~1% among TPB users). That's good news. Native IPv6 would be better than Teredo, but seeing a couple of hundred thousand random-user endpoints work isn't bad. (http://asert.arbornetworks.com/2008/08/the-end-is-near-but-is-ipv6/ said 0.01%.) Anrt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Actual IPv6 deployment observed
I quote from thepiratebay.org home page: IPv4 21.613.113 peers (10.992.697 seeders + 10.620.416 leechers) in 1.969.865 torrents on tracker. IPv6 210.410 peers (115.584 seeders + 94.826 leechers) in 174.895 torrents on tracker. Most numbers are about 1%, and about 9% of torrents contain one or more IPv6-capable peers. Ooh aah. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Actual IPv6 deployment observed
Iljitsch van Beijnum writes: You do have to understand that IPv6 support was available in BitTorrent clients for a long time, but then the Pirate Bay deployed trackers (servers) that were incompatible with the existing clients, so only people who both have IPv6 and a recent IPv6-capable client are in those numbers. I had to null-route the PB IPv6 address to get my old client to work again over IPv4... So considerably more than 1% of random filesharing users have IPv6 already? I assume that also means 1% of random DSL connections have IPv6 already. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
Ned Freed writes: But that's the problem - this is not what RFC 5321 says. It's not what 3501 says either ;) More of a one-sentence simplification than a full and exact description. ... SMTP server do stuff like expand lists all the time. For those tests to be done competently some amount of interpretation of local parts may be needed, such as ignoring the possibility that the local part is case sensitive. Oh, this makes sense. I wasn't aware of that. I ran into the same issue whem implementing group reply in a MUA, but hadn't realised that MTAs could run into that. While there may not be any conflict between RFC 3501 and RFC 5321 since they deal with separate components, the fact remains that there's a conflict between what real world implementations do and what RFC 5321 says must not be done. I agree with that. Email-arch, however, deals with both, and attempts to describe the running code too, so IMO it can't just cite 5321. That would be overly simplistic. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
s...@resistor.net writes: If there isn't an authoritative reference and there are differences in semantics or syntax between the draft and RFC5321/5322 or future revisions of these documents, it can lead to serious issues. Standards Track documents are around years. The documents may be edited by different authors as they get updated. Errors can happen; the documents can diverge. In my opinion, it is better to clarify that now or else we will end up having discussions ten years from now to determine which interpretation is correct or which standard to follow. So. RFC 3501 (page 50-51), says that the localpart of a From: address is matched case-insensitively when IMAP servers process SEARCH or UID SEARCH commands. RFC 5321 says that SMTP servers process localparts case-sensitively. Both rules go back essentially unchanged to very old RFCs. Do we need to discuss which is correct or which standard to follow? I fail to see any conflict. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Strong Opposition due to spam backscatter. Re: Last Call: draft-ietf-sieve-refuse-reject-07 and -08 (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard
Matthew Elvey writes: If a system implementing the specs we're working on works on a store-and-forward basis, then it MUST NOT MISLEAD, i.e. LIE TO ITS USERS by claiming to support the enhanced standard we are writing. -07 allows an implementation to mislead its users by claiming to support enhanced functionality when it does no such thing. Why not? My code (I implemented -07 a few weeks ago) advertises support for the standard even if it may or may not provide enhanced functionality. I think that's fine. It does provide in-protocol rejection when possible, and the rules have very pleasant consequences. Most importantly, it's possible to make system configuration changes that affect system's ability to to in-protocol rejection without invalidating anyone's sieve script. That would simply be dishonest. It's just another RFC about best-effort something something. There are many others already, so most implementers are familiar with the concept. And AFAICT, implementers generally implement a best effort, not behave dishonestly. (I read some more of this monster mail, but IMHO it degenerates into a pure rant around the point where Aaron Stone is first called «the author of -07». Not worth answering.) Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Stephane Bortzmeyer writes:
On Wed, Feb 27, 2008 at 10:26:44AM -0800,
Mark Crispin [EMAIL PROTECTED] wrote a message of 162 lines which said:
The actual correct collation, assuming(!) surname-first collation
and Latin character ordering(!!), is:
...
due to where the surname is located in various cultures.
Is it a good idea to sort on the ordering of the sender's culture? If
the ordering is to be useful for the human user, it should be
according the receiver's culture, no?
There's support for that. You have to read a few drafts and RFCs, though.
The draft in question defines a sort command and some sort keys, and it
permits defining more sort keys. Other documents allow defining
collations (sort orders) and using them im IMAP.
Sorting by From field the way most MUAs do requires defining a new
collation and a new sort key, since this draft's from key uses only
the localpart ('arnt' in the case of this message). Personally I think
that sort key isn't at all fortunate, but it's too late to change that.
There's decade-old running code already and the most important thing is
to document the deployed extension.
Arnt
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Dan: The draft can't be changed any more. But there's good news. Like you, I have a database, and I've implemented SORT. It took less than a day. A part of those hours was wasted time, because as you point out, only Mark's client wants the kind of address sorting which the draft offers. But it was less than a day. Wasting part of a day isn't really something to get excited about. Worse things happen every month. Arnt ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
Hallam-Baker, Phillip writes: I don't see how such an architectural limitation can be enforced. There is no way that the IETF can prevent an ISP issuing IPv6 customers a /128 if they choose. Not directly, but there's the indirect route: a) IETF designs IPv6 autoconfiguration. b) Linksys, D-Link, Netgear and friends make boxes that support autoconfiguration. c) ISP hand out /128s. d) Autoconfiguration doesn't work well. e) Customers call ISP support. f) ISP loses $$$. g) ISP starts issuing /48s instead. I don't know the first thing about how IPv6 autoconfiguration works. It worked very well in my previous office. Will it work better when the router has a /48 at hand than a /64 or /128? Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
Hallam-Baker, Phillip writes: Looks to me like people are trying to use technology to effect their political goals. Guilty as charged, and proud of it. My political goal is to make computers help people in their daily life, and I believe that eliminating the class of users without the ability to subnet, leaving only one type of internet user, helps towards that goal. If there's only one type of network to autoconfigure, testing and deploying autoconfiguring devices is simpler, and autoconfiguration will do the right thing in a larger percentage of cases, leaving more people happy and making fewer people call support. Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
Christian Huitema writes: The definition of a small network is pretty much single subnet. Yes, I understand very well that the average home of the future will have a mixed wiring. Of course, my own home does have Ethernet and Wi-Fi. In the not so distant future, it will have several Wi-Fi networks operating on different frequencies, some form of power-line networking, and some rooms may have their own high speed wireless wiring using UWB or some similar technology. But I am pretty much convinced that all of these will be organized as a single subnet. You mean that the faster actual subnets will not be subnets in the IETF sense, right? If a number of devices have some extremely fast special network, and a bridge or router to connect them to the rest of the world, presumably they need the extra bandwidth: If their traffic were to leak onto the slower net, it would be more or less unusable. But there are several ways in which the fast devices can leak traffic, often involving broastcast or multicast. (I have some neat audio boxes that multicast to group all-devices-from-manufacturer-x, very nice, but I'm glad my backbone isn't 802.11.) Either the IETF subnet has to be usable to describe these actual subnets (ie. people get more than a /64 automatically so it's the common case and random consumerboxes are built for it) or there'll eventually be some new subber-than-subnet concept so devices can broadcast or multicast traffic onto their fast subber-than-subnet without overwhelming the slow parts of the subnet. Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
Mark Andrews writes: Cable companies need this amount of address space for controlling the CPE boxes. The customers still get public addresses. That's a minimum of two addresses per customer. One of which can easily be an IPv6 address, so allocating 240/x for this would seem to cater to those people who can and will modify their devices to accept 240/4, but cannot or will not give them IPv6 ability. Large corporations need more than a /8. A /48 is that, too... Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Joel Jaeggli writes: Arnt Gulbrandsen wrote: IMNSHO, the sensible time is to do it when the relevant RIR runs out of addresses. I'm sure the IETF can get a couple of thousand IPv4 addresses for temporary use even years after that time, but it would seem a little hypocritical to do so. The network at both of IETF meetings I've attended felt a little archaic: abundant addresses, no paperwork, no firewall, no NAT. So basically, you're complaining that you came to the IETF and received production quality Internet service? I'm not complaining just yet. Mumbling. But if «production quality internet» would soon (e.g. IETF75 or -80) mean getting an IPv4 /19 when noone else can get that, I would complain. The discrepancy between the dogfood dispensed and the that eaten should not be _too_ wide. Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Noel Chiappa writes: Guess that's the only way you can get people to convert to IPv6, huh - cut off their IPv4 access? Isn't that exactly what'll happen in a few years, and why IPv6 exists at all? Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
Douglas Otis writes: The draft classifies Class-E as Limited Use for Large Private Internets. What large private internets are these, really? Are we discussing Google potentially needing more than one /8 for its web servers, or are we discussing providers (DSL, Wimax, 802.11, GSM, 3G or other) giving customers addresses from 240/4 via DHCP or PPP? Employees using 240/4 is one thing. Your mother-in-law getting 247.1.76.22 from her cable modem is quite another. Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
Brian E Carpenter writes: On 2007-08-08 09:40, Rémi Denis-Courmont wrote: ... Some widespread IPv4 stacks refuse to handle these addresses, so nobody would ever want to use them on the public IPv4 Internet. That will be a bit of a challenge in private networks too :-) Much smaller. If example.com wants to use them, example.com will have to upgrade its own computers and routers to a version which supports this new class E. Nontrivial, rather expensive, but doable. If you were to get 240.24.42/24 from your RIR, most/all of the public internet would have to upgrade before you could use the addresses. (Kind of like IPv6 but with a piddly little address space.) Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
Carsten Bormann writes: Cheaper to use IPv6, then. Non-starter, I'd say. I'm not sure using this class e thing + ipv6 is significantly more expensive than using either alone, so we may be looking at way to let some people transition with less pain: A big network can grow bigger before some hosts have to use pure 6. Whether that makes the reclassification worthwhile is another matter. Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: selling IPv4 addresses vs. the POTS number model
Hallam-Baker, Phillip writes: We cannot afford to indulge in faith based planning here. A question. Is anyone trying to mitigate effects of the End of Time in any other way than by working on IPv6? Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: selling IPv4 addresses vs. the POTS number model
Roger Jorgensen writes: On Mon, 6 Aug 2007, Arnt Gulbrandsen wrote: Hallam-Baker, Phillip writes: We cannot afford to indulge in faith based planning here. A question. Is anyone trying to mitigate effects of the End of Time in any other way than by working on IPv6? why bother when IPv6 are ready and can be used? :) Well, some people obviously don't like the transition to IPv6, so I'm wondering what sort of alternative approaches these people are working on. Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Funding (was Re: Charging I-Ds)
Suresh Krishnan writes: How would you write documents which warn against people doing funny things? I wrote a draft about the issues with hop-by-hop options in IPv6 and cautioning against their use. I see that there are still proposals coming out which depend on new hbh options? What should I do instead of writing a draft? Well read RFC 1925 and attain zen? Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Do you want to have more meetings outside US ?
Adrian Farrel writes: Well, the fee charged would appear to be directly correlated to the number of people attending. That is, because the IETF must cover its costs not just for the meetings but also for the rest of the year, a good proportion of the cost is independent of the meetings and so must increase per capita as the number of attendees decreases. But wait! There is also a direct correlation between the number of people attending and the cost. That is, the cost is a direct deterrent. But the two costs aren't the same... The deterrent is the sum of the IETF charge, the hotel charge, the cost of food, liquid refreshment and so on, travel, getting a visa, and finally the cost of being away from one's desk. Economists out there will recognise this problem, and will understand where the spiral is headed. The choice and cost of location can compound the problem, and it seems to me that one of the main objectives of setting meeting venues (both geography and hotel) must be to increase attendance and so to increase revenue. Decreasing the IETF meeting attendees' other costs ought to help: a) make it easier to attend by partially freezing the agenda early. If the secretariat could say from now on only times can change, not days early, that would help. (The WG meetings I care about are in a two-day block almost every time. Just coincidence or good work on part of the secretariat?) b) avoid meeting locations with obnoxious travel or visa issues, or very high costs otherwise. c) try to keep travel short for as many attendees as possible. How sad that there's a conflict between b) and c). Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Do you want to have more meetings outside US ?
Stewart Bryant writes: Do we have any firm evidence that we would get more work done if we had more meetings outside the US? I do get work done instead of spending two days applying for a US visa. My two cents. (But in all honesty, I'm not sure I'd go anyway. If an IETF meeting is held in a place I've always wanted to visit, I'll go there. Minneapolis isn't that. Five days in Minneapolis + travel time + US visa chores compares poorly with jabber and audio streaming for the few WGs that interest me. Maybe the attendee questionnaire should be extended with another question, «how much time did you spend playing Windows Solitaire?».) Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Annoying auto-reply messages
Ole Jacobsen writes: Is there a way we could have these things filtered at the source? Do you mean broken autoresponders or acronyms like RTCPXNQ? If the former, the esteemed volunteer or secretariat who runs this list can add a couple of lines like 'subject:.*out of office' and 'subject: auto[^ ]**:' to the list in 'privacy options - spam filters - bounce matching headers' list. If the latter, I suppose you have to petition the IESG (and please add my name on the petition). Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Dave Crocker writes: Bob Hinden wrote: Maybe we are getting to the point in time where we should only have IPv6 at IETF meetings or it that's premature run IPv4 behind a couple of layers of NAT. On the theory that the ietf meeting net is for production services, wouldn't it make sense to have the time to cut over to pure ipv6 be when production use of ipv4 becomes minimal? IMNSHO, the sensible time is to do it when the relevant RIR runs out of addresses. I'm sure the IETF can get a couple of thousand IPv4 addresses for temporary use even years after that time, but it would seem a little hypocritical to do so. The network at both of IETF meetings I've attended felt a little archaic: abundant addresses, no paperwork, no firewall, no NAT. Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA registration constraints (was: Re: Withdrawing sponsorship...)
Bob Braden writes: I would note that the purveyors of a non-standard specification that is already deployed and in successful use must have somehow obtained their own number assignment without the IANA's help, or this situation could not arise. And before that specification was successfully deployed, it may well have been a wild idea. There seems to be a logical disconnect here. What am I missing? Cases like managesieve. Managesieve is almost a decade old and in real use at many sites. Tens of thousands? Even more? No idea. The port it uses was allocated to another purpose about four years after managesieve was deployed. Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Use of LWSP in ABNF -- consensus call
I suggest that a version of this sentence goes into 4234bis: I thought the problem is that protocols that have used LWSP correctly have had too many interop problems, so they have replaced it with a simpler rule such as FWS. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IAOC Communications Plan: Review Requested
There are at least four feed to email gateways: http://exo.org.uk/code/rss2mail/ http://www.aaronsw.com/2002/rss2email/ http://newspipe.sourceforge.net/ http://home.gna.org/feed2imap/ Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Just one comment: Brian E Carpenter writes: On 2007-04-11 10:08, Simon Josefsson wrote: What typically happens in practice, among good-faith practitioners, is that there won't be any GPL (or Apache, or Mozilla, or ...) implementation of the patented technology at all, because the necessary rights cannot be acquired. Doesn't that sound like a bug in the OSS licenses to you, assuming the desired result is to make the Internet work better? In this kind of situation, what would _you_ choose? [ ] Apply for an IPR license/sign an NDA/do other paperwork [ ] Violate someone's something [ ] Go do something else My choice tends to be the last, because my goal is generally not to implement some specific technology, it is to increase people's happiness and productivity. I can do that by implementing whatever Mark has patented. Or in any of ten thousand other ways. See? Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: item for discussion - IAOC QA
Bob Braden writes: So, would it surprise you to find out now that someone else actually owns your text and can restrict the way others use it? I'll be you would be surprised... you ASSUMED it was public domain, in those simpler times. Mu. I just wrote it. Nothing and noone forced me to make any such assumption. The question did not (AFAICR) ever enter my mind. Let me try it again: Back then randoms like myself could write an RFC and never think about legal matters. You're now assuming that we would have assumed, and that's a large dose of assumption. (In my case I'm sure I'll sign and fax whatever I need to sign and fax, and I hope everyone will. But I wouldn't feel sure until all the signatures are on file.) Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: item for discussion - IAOC QA
Bob Braden writes: There should be no problem getting pre-1998 authors to sign such a document, since it merely memorializes in modern legalese the implicit agreement between authors and the RFC Editor since the beginning of time. In the less legally-toxic atmosphere of the time, authors were simply assumed to agree with the announced IPR policy (called something like Copyright Story, authored by Jon Postel, and available on the RFC Editor web site for as long as I can remember. As an early RFC author, I certainly ASSUMED the contents of your license statement, and I assume that other authors did as well. I'm on the other end of the spectrum - I wrote most of a single RFC in 1995-6 and have no memory of ever seeing the Copyright Story. (I wrote the original draft text, Paul Vixie graciously took over at some point, when my wrists gave up, and the result was published in October 1996.) I assume most/all IETF regulars at the time knew the Copyright Story. But tourists like myself could also publish RFCs, and I wouldn't jump to conclusions about their/our agreeing with the unstated agreement. Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Prague
Tim Chown writes: On Wed, Mar 07, 2007 at 12:23:21PM -0500, Ralph Droms wrote: I visited Prague about two years ago and had the same experience as Ed. I traveled via the Metro and on foot, visited all the tourist traps; had no problems and never felt unsafe. I second that. The metro system was excellent; it would be interesting to know what the closest stop to the hotel is on the metro map: http://www.dpp.cz/download/schema-metra-v-praze.pdf Florenc. Really close to the holte. For those wishing to get to the hotel by public transport: Florenc is one of the hubs right in the middle of the map. Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DNS role (RE: NATs as firewalls, cryptography, and curbing DDoS threats.)
A prediction: Sooner or later, IPv4 addresses become so scarce that renting a colo server with IPv4 becomes more expensive than IPv6. When that happens, a few NAT-hating spoilsports will set up the first few IPv6-only servers and a year later, the transition to IPv6 starts. I wonder what kind of server that'll be - game servers, perhaps? Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Referencing BCPs [Re: ion-procdocs open for public comment]
Dave Crocker writes: Eric Gray (LO/EUS) wrote: Interestingly enough, your observation provides the strongest argument I've yet seen for assigning a standard number to any RFC that has becomes a Proposed Standard. Well, it's a double-edged capability. All of the concerns about citing the latest version rather than a specific version are entirely warranted... We have STD numbers already. There's only one catch: The internet runs on proposed standards, not STDs. Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Tracking resolution of DISCUSSes
Steven M. Bellovin writes: On Mon, 15 Jan 2007 14:26:33 -0500 John C Klensin [EMAIL PROTECTED] wrote: Perhaps we should make it a requirement that any document that is Last Called must be associated with a mailing list, perhaps one whose duration is limited to the Last Call period and any follow-ups until the document is either published or finally rejected. If there were a WG, then the WG list should be a proper subset of that list, anyone commenting during the Last Call should be added to it, and others could be added on request. Actually, I think it's an excellent idea. Tracking Last Call comments was always difficult, since the email tended to end up in several different folders and wasn't archived elsewhere. I wish something like this had been in place a year ago. People sent last call comments I needed to read to five different lists (IIRC), and I subscribed to only to three of those. But it could be less bothersome than having to set up a specific list. Just require that the draft specifies where comments should go and mention the address in the Last Call announcement. Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Alan DeKok writes: The people I talk with plan on using NEA to catch the 99% case of a misconfigured/unknown system that is used by a well-meaning but perhaps less clueful employee or contractor. The purpose of NEA is to enhance network security by allowing fewer insecure end hosts in the network. I think the requirements document and/or charter would do well to stress this. Perhaps even exclude the 1% case explicitly. Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-dusseault-caldav-15 and draft-newman-i18n-comparator-14
Lisa Dusseault writes: Last week Ted I were discussing whether one could define a Very Liberal Comparator (VLC) for general use. It would be handy to have one which matched e with E, é, è É... and matched o with O, ø, ô, and so on. That would help in calendar searching use cases, e.g. a user who can't type in accents (or doesn't know how) wants to find the invitation from André by searching for andre. You're talking about i;basic;level=1 ;) You may also be talking about i;basic: During its life as part of draft-newman-i18n-comparator the default level was partly 1 and partly 3 (IIRC and don't hold me to it). I don't know which level is the best default (which was one of the reasons for splitting it out). Comments welcome (to me personally, please): Which level is the right default? http://unicode.org/reports/tr10/#Multi_Level_Comparison lists the possibilities. Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
