DNSSEC is hard to get right
% check-sig iab.org Name iab.org has an expired signature (20100829223019) :-( ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Optimizing for what? Was Re: IETF Attendance by continent
- Original Message - From: Iljitsch van Beijnum iljit...@muada.com To: Olaf Kolkman o...@nlnetlabs.nl Cc: IETF-Discussion list ietf@ietf.org Sent: Monday, August 30, 2010 10:33 PM On 30 aug 2010, at 21:57, Olaf Kolkman wrote: If you want to be fair to the individual participants you have to optimize in such a way that attending 6 meetings costs the same for every individual that regularly attends the IETF. Obviously one can only approximate that by putting fairly large error bars on the costs but isn't the X-Y-Z distribution where X= approx Y= approx Z the closest optimum? (or finding one place that sucks equally for everybody) Am I missing something? Yes. Optimizing for min(X+Y+Z) WITH the constraint X=Y=Z is almost certainly going to produce a higher X+Y+Z than without that constraint. In other words, if you want to be fair the total expense for the entire community will be larger. Contrary to popular belief, distance is not the most important factor in travel expenses. My flight from Madrid to Dublin cost almost what I paid to fly from Amsterdam to Minneapolis a few years before. Hotel rates have a much bigger impact, especially now that the official IETF hotels seem to be getting more expensive every time we meet. I agree about the distance. I see America as the travel industry's equivalent of the sociometric star, and would happily go for 6:0:0 since it is travel costs that dictate my presence (usually absence:-( By contrast, almost anywhere in Europe is more expensive to get to (from the UK). Tom Petch ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is hard to get right
Another view, for the visually inclined: http://dnsviz.net/d/iab.org/dnssec/ On Aug 31, 2010, at 2:41 AM, Stephane Bortzmeyer wrote: % check-sig iab.org Name iab.org has an expired signature (20100829223019) :-( ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Optimizing for what? Was Re: IETF Attendance by continent
On Aug 31, 2010, at 10:43 AM, t.petch wrote: If you want to be fair to the individual participants you have to optimize in such a way that attending 6 meetings costs the same for every individual that regularly attends the IETF. Obviously one can only approximate that by putting fairly large error bars on the costs but isn't the X-Y-Z distribution where X= approx Y= approx Z the closest optimum? (or finding one place that sucks equally for everybody) One place that sucks for everybody has the great advantage of reducing the stress associated with travel. A lot of people were stressed about the various ways of getting to Maastricht, and a lot more are stressed about getting to Beijing (what with various kinds of visas, hotels and taxi drivers who don't speak any language other than Chinese) If we standardize on one place, then by your second meeting, you know everything about the place, and people can cutpaste their complaints from the previous meeting. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Attendance by continent
On 31 aug 2010, at 1:13, Tobias Gondrom wrote: My vote is strongly in favor of 1:1:1. 1. First, the location _is_ a significant barrier to entry for newcomers and other contributors. Optimizing only for the current status quo does create a strong perpetual cycle of self reinforcing structure of contributors from the favored location(s). You assume that having a meeting on your home continent magically makes attending a meeting much easier. I don't think that's necessarily the case. Just consider the language issue. I think we can safely assume that everyone who thinks about attending IETF meetings speaks English. So attending a meeting in a country where English is the official language is much easier than in a place where few people speak it. Even in the Netherlands, where virtually everyone speaks at least some English, there was a bit of a language barrier because signs, menus, etc where often only available in Dutch. Also, flying across a big continent can take just as long as flying across an ocean. And although there is a correlation between travel distance and cost, that correlation is well below 1. Sometimes intercontinental flights are the same price or cheaper than regional flights, and often the difference is small enough that it disappears in the noise of hotel prices, ground transportation costs, food expenses and the like. Last but not least, attendance is only one metric. If it were the only relevant one, we'd have to meet on a Cisco campus once every three years, as about 10% of the attendees are employed by Cisco. Even though Asian attendance has been on the rise, contributions from Asian IETFers seem to be lagging their attendance numbers. (For instance, as far as I can tell from the names, none of the IESG members is from Asia.) For all these reasons, I think that 1:1:1 is not warrented at this time. Maybe it will be in a few more years, but I think we should first see how well meetings in places like Beijing go before committing to having a meeting in Asia every year. Meeting in Europe seems to lead to compromises. Maybe Asia will turn out to be better in this regard, maybe worse. I don't think we want to have meetings with more compromises just to appear balanced. Consider that contributors usually start as newcomers, attend several meetings, then write a draft, I don't know about you, but I wrote drafts before my first meeting. join more WGs and maybe chair a WG. But if you make it hard for newcomers to attend several meetings they are at a severe disadvantage to become future contributors. If that were true we'd need to go to places where we _don't_ have attendees yet, not to Asia which has been sending a steady supply in recent years. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC
Community - The DNS zone files have been re-signed, and we will look into alternatives to the original DNSSEC tools that were in use (which seem to be broken.) And just a reminder that, while posting complaints to this list might feel more therapeutic, the secretariat has an address set up for trouble reports, which is ietf-act...@ietf.org . Sending complaints to that address will generally get much faster results. Thank you! Glen Glen Barney IT Director AMS (IETF Secretariat) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC
On 8/31/2010 7:36 AM, Glen Barney (AMS) wrote: Community - The DNS zone files have been re-signed, and we will look into alternatives to the original DNSSEC tools that were in use (which seem to be broken.) And just a reminder that, while posting complaints to this list might feel more therapeutic, the secretariat has an address set up for trouble reports, which is ietf-act...@ietf.org . Sending complaints to that address will generally get much faster results. Thank you! Glen Glen Barney IT Director AMS (IETF Secretariat) Glen your real issue is why DNSSEC was released in this condition and the damage to the world in the form of wasted effort this causes. Something that for what its worth provides yet another black-eye for the IETF (and the parties making GSO and the IETF their career). Todd Glassey ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3103 - Release Date: 08/30/10 11:34:00 -- //- This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Meeting Venue Preference Survey
On Sat, Aug 28, 2010 at 10:17:20AM -0700, Dave CROCKER wrote: We really need to get these surveys produced by someone with training in survey design. Or stop using the surveys. It isn't clear to me that the surveys are a good idea at all, not just because of sampling biases and survey design issues, but because they may lead to apparent statements of preference that don't conform to the general principles that ought to undergird IAOC decisions. Surveys are a good way to make a decision look democratic, but there are well-known and serious problems with collective preference expression. (If you don't believe this, you might start by looking up Kenneth Arrow, whose exploration of this issue is the most famous. There's a large body of work around this general topic, however.) If we have general principles for venue selection (for instance), then asking people to complete a survey is not the right thing to do: either a given site can be shown to conform to the venue selection principles, or it can't. If it does conform, then a survey might actually reveal a collective preference to go elsewhere, but that would not be a rational preference. (I wonder in fact whether the decision to go to Québec will turn out this way.) A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Is this true?
No, if IP to the edge had been the only idea in the Internet architecture it would have been no different and no better than any of the other networking schemes on offer at the time. What made the Internet unique was the fact that it was the only inter-network that was designed to play nice with other networks that existed at the time. You could run DECNET or SNA or anything you chose on your campus and still exchange mail with the rest of the world. IP to the edge was a special case. The technology we need to manage the IPv4 to IPv6 transition is already in the Internet DNA. All it takes is to jettison the ideology and accept that for at least the next twenty years we will be dealing with heterogeneous networks, only this time they will be IPv4/IPv6 rather than IPv4/DECNET/OSI/SNA/CHAOS etc as was the case in the 80s and early 90s. The endpoints that matter are people. Unless I am mistaken, people don't have IPv4 or IPv6 addresses. So no HMI protocol is ever IP clean end to end. On Mon, Aug 30, 2010 at 11:45 AM, Noel Chiappa j...@mercury.lcs.mit.edu wrote: From: Phillip Hallam-Baker hal...@gmail.com Ironically we are returning to the original model of the Internet. Only we are returning to the 1970s model of Clark, Cerf et. al. in which the only constant is that every network uses the Internet Protocol for communication across the Internetwork. IP to the endpoint was actually a later idea. Say what? Internetwork packets directly to the end-host (with TCP on top) was a constant in the internet architecture from before IP even existed (i.e. TCP 1, TCP 2, etc). Noel -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Meeting Venue Preference Survey
On 8/30/2010 10:53 AM, Marshall Eubanks wrote: On Aug 29, 2010, at 8:10 PM, Dave CROCKER wrote: The premise to these anecdotes appears to be that IETF meetings are designed for people who have: * hefty corporate travel funding-- so money is largely no object As someone who frequently pays for IETF travel out of my own pocket, I can assure you that this is not true for me. Ditto for meeting and travel time sinks. Since my note specifically challenged the tendency to indulge in personal anecdotes, I can't guess why you responded with a personal perspective. Worse, it appears to have had nothing to do with the point I was making. Since you are on the IAOC, your posting is particularly confusing. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Is this true?
At the time email was a special case because it was the *only* application. In any case, my point was not that we should follow the original intent of the founders except to the extent that they faced a particular set of problems and technical and social constraints and looked for the best ways to solve them. We should certainly understand why they came to the conclusions they did, but refusing to accept a particular interpretation of their intent does not make someone 'ignorant' or 'marginally informed'. On Mon, Aug 30, 2010 at 1:58 PM, Noel Chiappa j...@mercury.lcs.mit.edu wrote: From: Phillip Hallam-Baker hal...@gmail.com What made the Internet unique was the fact that it was the only inter-network that was designed to play nice with other networks that existed at the time. You could run DECNET or SNA or anything you chose on your campus and still exchange mail with the rest of the world. IP to the edge was a special case. Ah, no. There were eventually tweaks to the _email_ system to enable it to interoperate with other email systems (others will remember those far better than I), but that has nothing to do with the network/transport layers. The vast bulk of the early Internet work was focused on just the people using TCP/IP - and to run any of that, you needed IP to the edge. (I am remembering of the pain we suffered at LCS before we got an IMP port so we could bring up our first IP gateway to the rest of the world...) And as for ability to run DECNET and IP on one's campus at the same time as IP - that was not the original direction taken at many places. Certainly at MIT we spent (wasted, to be honest) a lot of time trying to create an underlying data-carriage layer to carry both IP and CHAOS (and other stuff) before we went with the 'ships in the night' approach, and the multi-protocol router. But this is getting a bit off track. If you want to continue, let's move this to 'internet-hist...@postel.org'. Noel -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Attendance by continent
On 8/30/2010 12:54 PM, Peter Saint-Andre wrote: On 8/30/10 1:53 PM, Patrik Fältström wrote: I was expecting something like: pi:e:sqrt(-1) Given the irrationality this topic evokes, that seems about right. ;-) could lead to a new branch of the field: affective computing. or at least an extension to related work: affective logic. the result of a computation depends upon how you feel about it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is hard to get right
I propose a lightweight DNSSEC. http://www.ietf.org/id/draft-yao-dnsext-msig-00.txt which may push the dnssec to be deployed easily. :) Jiankang Yao - Original Message - From: Stephane Bortzmeyer bortzme...@nic.fr To: ietf@ietf.org Sent: Tuesday, August 31, 2010 2:41 PM Subject: DNSSEC is hard to get right % check-sig iab.org Name iab.org has an expired signature (20100829223019) :-( ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is hard to get right
DNSSEC is a PKI and running a PKI is never a trivial matter. One of the reasons I have serious concern about the prospects for deployment of DNSSEC is that the answer to many of my questions is either a blank stare, an off the cuff answer clearly made up on the spot or the claim that it is something for the market to decide on. As things stand we have an excellent architecture for securing distribution of DNS A and records. We are thus confident of our ability to transfer attacks from the DNS system where the effect of attacks is pretty much localized to the BGP system whose fragility was demonstrated only last Friday by RIPE. Is this really progress? Out in Iraq, there is a water treatment plant that cost $110 million to build. So far it has delivered absolutely no clean water to any homes because nobody considered the need to build a pipe to connect the water treatment plant to the city water mains. There is a metaphor there if people want to see it. On Tue, Aug 31, 2010 at 7:07 AM, Richard L. Barnes rbar...@bbn.com wrote: Another view, for the visually inclined: http://dnsviz.net/d/iab.org/dnssec/ On Aug 31, 2010, at 2:41 AM, Stephane Bortzmeyer wrote: % check-sig iab.org Name iab.org has an expired signature (20100829223019) :-( ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC
Whether or not the IAB zone is signed is of negligible consequence. But the fact that the IAB zone signatures had expired is a highly significant data point: DNSSEC administration is not quite as easy as some of the glib claims of its more enthusiastic supporters would lead one to believe. On Tue, Aug 31, 2010 at 10:36 AM, Glen Barney (AMS) g...@amsl.com wrote: Community - The DNS zone files have been re-signed, and we will look into alternatives to the original DNSSEC tools that were in use (which seem to be broken.) And just a reminder that, while posting complaints to this list might feel more therapeutic, the secretariat has an address set up for trouble reports, which is ietf-act...@ietf.org . Sending complaints to that address will generally get much faster results. Thank you! Glen Glen Barney IT Director AMS (IETF Secretariat) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC
Hi Phil, On Tue, Aug 31, 2010 at 11:02 AM, Phillip Hallam-Baker hal...@gmail.com wrote: Whether or not the IAB zone is signed is of negligible consequence. But the fact that the IAB zone signatures had expired is a highly significant data point: DNSSEC administration is not quite as easy as some of the glib claims of its more enthusiastic supporters would lead one to believe. Sounds like a straw man to me. Can you provide a pointer to some of these glib claims? For years I have been hearing, correctly I believe, that lack of logistical and administrative tools and support for DNSSEC was the main problem slowing deployment. Recent developments like RFC 5011 (Automated Updates of DNS Security (DNSSEC) Trust Anchors) have improved things a lot. And, as an original architect of DNSSEC, I admit that the early proposal set was deficient in this area. Donald On Tue, Aug 31, 2010 at 10:36 AM, Glen Barney (AMS) g...@amsl.com wrote: Community - The DNS zone files have been re-signed, and we will look into alternatives to the original DNSSEC tools that were in use (which seem to be broken.) And just a reminder that, while posting complaints to this list might feel more therapeutic, the secretariat has an address set up for trouble reports, which is ietf-act...@ietf.org . Sending complaints to that address will generally get much faster results. Thank you! Glen Glen Barney IT Director AMS (IETF Secretariat) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Optimizing for what? Was Re: IETF Attendance by continent
On Aug 30, 2010, at 6:21 PM, Randall Gellens wrote: Why Kauai? You list detailed reasons why Hawaii is logical and solves for many of the problems, but you don't say why this island. Because it's the nicest, obviously. :) We can even rotate islands if people get bored. Well, there are extensive conference facilities on Oahu, the Big Island, Maui, and Kauai. I have no information as to if they would work for a group of our size and with our need for breakout rooms. I used to attend IEEE 802 and they met in Kauai (Grand Hyatt in Poipu) every few years, but they were a smaller group. There aren't many restaurants nearby, but I certainly don't remember anyone ever complaining about it. ;) -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Tools logins -- Aaaargh!
There is probably a better place to complain about this, but... There are various IETF tools web pages. But I have a devil of a time using them because they do not identify themselves usefully when asking for a login. There are multiple login databases in the whole IETF tools suite, and experienced users know which database controls access to which tool. But for us unwashed masses, there is no way to guess which web pages demand which password because they are named inconsistently. Let me propose: * Each password database has a *single* name which is the only name that it is ever referred to by, such as IETF tools login and IETF datatracker login. * Each login prompt gives the *single* name of the password database that it is driven by. Otherwise we get such messes as trac.tools.ietf.org demanding an IETF tools login -- not IETF datatracker login -- and its login prompt identifying the realm only as IETF. Which is pretty useless to the uninitiated, since track, tools, and IETF are all present. (I'm continuously amused by the fact that a roomful of computer geeks, who spend their days making unambiguous descriptions of operations to computers are unable to make an unambiguous description of an operation to humans.) Dale ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: secdir review of draft-ietf-simple-msrp-sessmatch
Hi, The purpose of this e-mail is to address the secdir comments given by Richard Barnes and Ted Hardie. Due to summer vacations, standardization meetings etc it took a while to put the e-mail together, and we appologise for that. GENERAL === First, the draft does NOT propose any changes to the TLS authentication procedures – that will be clarified. The changes are only related to the procedure for matching an incoming MSRP message to an MSRP session that has been negotiated using SDP – once any TLS authentication procedure has already taken place. So, in case of TLS and name based authentication, if an SBC/ALG modifies the a=path MSRP URI, the TLS authentication WILL fail. That is the current behavior, and sessmatch doesn’t change that. We understand that this fact needs to be clearly indicated in the draft. Basically sessmatch allows so that, when using peer to peer MSRP, SIP SBCs and SIP aware firewalls can be in the SIP signaling path without acting as MSRP B2BUAs. But, for an SBC or ALG to interwork correctly with MSRP relays the SBC/ALG needs to act as MSRP B2BUA, as today. Sessmatch aims to extend the usability of MSRP peer to peer communication to scenarios where simple ALGs/SBCs are used, and at least in our experience customer interest for standard MSRP has grown (from more or less zero) dramatically due to sessmatch. And, OMA, which previously used a *non-standard* version of MSRP (with no interoperability with standard MSRP), has also agreed to switch to sessmatch (even if it required a number of changes in their specifications). Second, the intention of sessmatch is not to modify the MSRP URI matching rules, but rather to not use MSRP URI matching for session matching. Please also note that when we talk about SBCs/ALGs, we refer to entities that normally do NOT have the capability to act as MSRP B2BUAs. We will comment the individual comments based on the assumptions above. Comments from Richard = I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document changes the URI matching algorithm used in MSRP. MSRP sessions are typically initiated using SDP bodies in SIP. These SDP bodies contain MSRP URIs that the peers use to contact each other. When one peer receives a request to initiate a session, he verifies that the URI being requested is one that he initiated in SDP, thereby using the URI as a shared secret to authenticate that the originator of the session actually received the SDP body in question. According to the current SDP specification, this comparison is performed over the whole URI; this document restricts the comparison to the session-id component, omitting the host, port, and transport components. The goal of the document is to facilitate a certain class of man-in-the-middle attack, namely to allow a signaling intermediary to insert a media intermediary. The restriction on the URI comparison is needed in order for the media intermediary not to have to modify URIs in MSRP packets to reflect the modifications to URIs in SDP bodies performed to redirect traffic through the media intermediary. When an MSRP UA receives an MSRP packet it performs msrp session matching in order to verify that the msrp packet belongs to an existing SDP negotiated msrp session at the UA. RFC4975 prescribes that URI matching should be used for session matching. We argue that the namespace scoping of the session-id values that use of URI matching brings is unnecessary. The 80-bit randomness of the session-id and the fact that it was the UA itself that decided on the session-id value and can ensure that it is unique within the UA makes the session-id sufficiently unique for session matching. Sessmatch is not changing the MSRP URI matching algorithm, it is changing the session matching algorithm not to use MSRP URI matching. I have a few significant reservations about this document: 1) This extension makes it more difficult for MSRP entities to secure their communications against attackers in the signaling path. The current model provides a basic integrity protection, in that signaling intermediaries cannot redirect traffic to an arbitrary third party; they must at least advise the third party about how to modify MSRP packets. The proposed modification would remove even this cost. If we do not introduce the sessmatch change then the only alternative for MSRP connections to be able to be set up when SBCs or SIP aware firewalls are in the SIP signaling path is for these to introduce MSRP B2BUA support. This is probably not feasible for most SBCs and SIP aware firewalls, and if it actually were feasible then it would mean as big a security problem, or even bigger, than sessmatch.
Re: Is this true?
Phillip Hallam-Baker wrote: At the time email was a special case because it was the *only* application. As far as I recall *reading* (I wasn't around at the time :-) ) email was a couple of FTP commands? -- I seem to recall John Day writing about this in his book.. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Is this true?
From: Fernando Gont ferna...@gont.com.ar As far as I recall *reading* (I wasn't around at the time :-) ) email was a couple of FTP commands? That was more back in the NCP days (prior to TCP/IP). SMTP came in about the time TCP/IP was really starting to roll (don't recall the exact timing, but it would have been circa 1980 or so). Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Review of draft-saintandre-tls-server-id-check
On 8/30/10 5:10 PM, Bernard Aboba wrote: Peter St. Andre said: an SRV record can be used for two quite different purposes: 1. To point from an application service name to a particular host/domain name in the same administrative domain (e.g., _imap._example.com points to mailhost.example.com for its IMAP service). 2. To delegate an application service name to a hosting provider outside in the administrative domain of the application service (e.g., example.com delegates its IMAP service to apps.example.net). As I see it, RFC 4985 glosses over the foregoing distinction. [BA] It took some adjustment for me, but as I understand it, the underlying assumption of RFC 4985 is that if the certificate is considered valid by RFC 5280 path validation (e.g. chains to a valid trust anchor, etc.) then delegations both within and outside the source administrative domain can be validated. This logic, if pursued, could apply beyond SRV RR validation, to things like NAPTR validation via a URI/IRI in the certificate. If that's the logic, I'd at the least like to see a 4985bis spec make that clear, because IMHO it's not spelled out now. Scoping (EKUs, name constraints, etc.) is a different question. Agreed. Peter also said: However, the question arises: what is the client supposed to check if an SRV lookup for _imap._example.com yields apps.example.net? My reading of RFC 4985 leads me to think that the certificate presented by apps.example.net is supposed to contain an SRV-ID of _imap.example.com, which means roughly this certificate indicates that this provider is authorized to provide IMAP service for the example.com domain. (How the certification authority determines that the delegation is indeed authorized is outside the scope of this I-D.) [BA] That's also my reading of RFC 4985, but I'll let others more knowledgeable (like the author) weigh in. That would indeed be helpful. Peter -- Peter Saint-Andre https://stpeter.im/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Is this true?
The history of the development of email protocols is contained in the RFC series. Those interested might for example look at RFCs 196, 458, 524, 772, and 788. Bob Braden On 8/31/2010 10:54 AM, Noel Chiappa wrote: From: Fernando Gontferna...@gont.com.ar As far as I recall *reading* (I wasn't around at the time :-) ) email was a couple of FTP commands? That was more back in the NCP days (prior to TCP/IP). SMTP came in about the time TCP/IP was really starting to roll (don't recall the exact timing, but it would have been circa 1980 or so). Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Is this true?
--On Tuesday, August 31, 2010 13:54 -0400 Noel Chiappa j...@mercury.lcs.mit.edu wrote: From: Fernando Gont ferna...@gont.com.ar As far as I recall *reading* (I wasn't around at the time :-) ) email was a couple of FTP commands? That was more back in the NCP days (prior to TCP/IP). SMTP came in about the time TCP/IP was really starting to roll (don't recall the exact timing, but it would have been circa 1980 or so). Yes. But, regardless of whether one counts from FTP-based email or from SMTP, the statement that email was the only application is simply nonsense. Telnet was alive and well, FTP was heavily used (and I trust it is obvious that we could have had FTP-based email without FTP), user and system information protocols like finger and whois were around and in use, and so were a bunch of things that are applications or not depending on one's definitions and a fairly large collection of applications (not just applications-support protocols) built directly on TCP (or NCP, or later on various socket layers) whose descriptions never made it into the RFC series. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
NAT behavior for IP ID field
I'm trying to locate an RFC that spells out the behavioral requirements, expectations or guidelines for NAT handling of the IP ID field, particularly for UDP messages. Section 3.2.5 in RFC 3235 briefly mentions issues surrounding IP fragmentation and reassembly, but it doesn't specifically say if NATs should re-write IDs as a general rule. RFC 4787 doesn't seem to address this either. If this is not written down anywhere, do NATs generally rewrite the ID field with or without the MF bit set? For background and reference, I refer you to Steve Bellovin's 'A Technique for Counting NATted Hosts', particularly section IV. Thanks for any pointers, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Optimizing for what? Was Re: IETF Attendance by continent
On Tue, Aug 31, 2010 at 12:06 PM, Hadriel Kaplan hkap...@acmepacket.com wrote: On Aug 30, 2010, at 6:21 PM, Randall Gellens wrote: Why Kauai? You list detailed reasons why Hawaii is logical and solves for many of the problems, but you don't say why this island. Because it's the nicest, obviously. :) See http://www.pothole.com/~dee3/kauai.html Donald We can even rotate islands if people get bored. Well, there are extensive conference facilities on Oahu, the Big Island, Maui, and Kauai. I have no information as to if they would work for a group of our size and with our need for breakout rooms. I used to attend IEEE 802 and they met in Kauai (Grand Hyatt in Poipu) every few years, but they were a smaller group. There aren't many restaurants nearby, but I certainly don't remember anyone ever complaining about it. ;) -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Optimizing for what? Was Re: IETF Attendance by continent
--On Monday, August 30, 2010 21:57 +0200 Olaf Kolkman o...@nlnetlabs.nl wrote: The recent remark on bias against individuals[*] made me think about weighing the location preference by number of participants from certain regions. Suppose an individual from Asia attends all IETFs then her costs are that for attending 6 IETFs she gets to travel 1x regional and 5x interregional. While an individual from the US travels 3x regional and 3x interregional. Clearly there is a bias agains our Asian colleague in with respect of the costs. Using participation/contribution numbers to weigh locations minimizes the global costs (total amount of miles flown, carbon spend, lost hours by the collective, total amount of whining) but nothing of that flows back to the individual engineer that attends every time. If you want to be fair to the individual participants you have to optimize in such a way that attending 6 meetings costs the same for every individual that regularly attends the IETF. Obviously one can only approximate that by putting fairly large error bars on the costs but isn't the X-Y-Z distribution where X= approx Y= approx Z the closest optimum? (or finding one place that sucks equally for everybody) Am I missing something? Well,... Speaking as one of those independent consultants who, in the last eight years or so has attended every IETF meeting and paid all of my own costs to all but one of them (I had a registration fee waived once), and who was previously sometimes in the approval loop for corporate permission/sponsorship by others... If you want to go very far down the path you outline, you have to ask some questions that we have never asked and to which you/we may not want to know the answers. Examples: * Are there differences in different regions as to the ratio between those who are really participating as individuals and those who have corporate sponsorship? * If a corporation typically sends a lot of people to IETF but has overall cost constraints such that some choices of location might reduce the total number of people they sent, would that really reduce overall IETF effectiveness? Put differently, if such a corporation cut participation by Go-ers and various other forms of tourists and damage-preventers, leaving only those who actively contribute to the IETF's work, would that result in a worse or slower IETF product? * Coming back to another optimization discussion, would you want to adjust the weightings to favor those who are actively participating in a variety of IETF efforts over those who come to participate in one or two WGs and otherwise have spare time? * Remember that, for some people and some companies, the perceived costs of having someone with real design or product responsibility away from his or her desk may completely dominate any travel or registration costs. For other situations, that is definitely not the case. If one really wants to look at costs in depth, I would also point out that the Beijing meeting has a de facto minimum registration fee (registration + minimum visa fee) for US citizens of $775 and one for most others of $110 less. Because of differences in visa policies in other countries, meetings in other locations may impose differentials disfavoring other groups. And all of that is in addition to points made by others including that distance is not a very good surrogate for overall costs (or even airfares), that some of these optimizations may pessimize overall attendance or attendance by active participants, etc. So, while I might personally benefit from the sort of revision in formula you suggest, I have significant doubts that you can really make those measurements and that optimization correctly (for some sensible value of correct). Unless we can figure out how to control overall costs and the cost-efficiency ratio for just about everyone, I know I'm going to need to stop attending meetings face to face for which I don't have (or seek) sponsorship. That is just how it is; I'd much rather see the focus on controlling overall costs to everyone, examining locations and meeting schedules for their consequences on time away from home (which translates into lost billable hours for some of us and irritated families for some others), whether a meeting in a particular location requires making a tradeoff between staying in an inconvenient place and staying in an expensive luxury hotel, and so on. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Fwd: IPR Disclosure: CNRS's Statement about IPR related to RFC 4768, RFC 2069, RFC 4169, and draft-ietf-httpbis-p7-auth-11
Dear Msr DE FURST I note your filing of an IPR claim against the HTTP Digest Authentication method described in RFC 4768 and RFC 2069. I note further that the claim is made in respect of a patent application made in 2008 whereas RFC 2069 was published in 1997 and the original proposal on which it was based was published by myself on the www-talk mailing list in 1993. In what imaginable universe could you possibly conceive that a patent application made in 2008 would establish a proprietary claim over prior art published as an international standard fifteen years prior? The purpose of an IPR filing is to declare an interest in an existing specification. It is not for soliciting interest in the addition of features to support a subsequent invention. Further, I believe that if your clients were to fully consider their proposed realization that it is in any case anticipated in United States Patent Application 20050021982, to which an offer of Royalty-Free Reasonable and Non-Discriminatory licensing for implementation in RFC 4226 is already on file: https://datatracker.ietf.org/ipr/1104/ I am Sir, yours etc, Phillip Hallam-Baker -- Forwarded message -- From: IETF Secretariat ietf-...@ietf.org Date: Tue, Aug 31, 2010 at 11:14 AM Subject: IPR Disclosure: CNRS's Statement about IPR related to RFC 4768, RFC 2069, RFC 4169, and draft-ietf-httpbis-p7-auth-11 To: j...@math.nwu.edu, j...@spyglass.com, ph...@hallambaker.com Cc: alexey.melni...@isode.com, stpe...@stpeter.im, ipr-annou...@ietf.org, hous...@vigilsec.com Dear John Franks, Jeffery Hostetler, Phillip Hallam-Baker: An IPR disclosure that pertains to your RFC entitled An Extension to HTTP: Digest Access Authentication (RFC2069) was submitted to the IETF Secretariat on 2010-08-31 and has been posted on the IETF Page of Intellectual Property Rights Disclosures (https://datatracker.ietf.org/ipr/1398/). The title of the IPR disclosure is CNRS's Statement about IPR related to RFC 4768, RFC 2069, RFC 4169, and draft-ietf-httpbis-p7-auth-11. The IETF Secretariat -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Is this true?
On 8/31/2010 10:54 AM, Noel Chiappa wrote: From: Fernando Gontferna...@gont.com.ar email was a couple of FTP commands? That was more back in the NCP days (prior to TCP/IP). SMTP came in about the time TCP/IP was really starting to roll (don't recall the exact timing, but it would have been circa 1980 or so). SMTP was defined in 1982. So was the DNS. It took both some years to gain production levels of use of each. The Internet's TCP/IP had code start running in 1976 and went into production operation in 1983. Hence there was a period of time during which the Internet relied on the original FTP-based mail commands. SMTP's primary enhancement was support for multiple addressees per transaction. By and large, this improvement was invisible to email users. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Review of draft-saintandre-tls-server-id-check
fwiw, I concur with Peter's analysis and conclusions. =JeffH ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC
In message aanlktinwmo6sw-rvfrax-_vnn8x1kejc9iakrnqgb...@mail.gmail.com, Phil
lip Hallam-Baker writes:
Whether or not the IAB zone is signed is of negligible consequence.
But the fact that the IAB zone signatures had expired is a highly
significant data point: DNSSEC administration is not quite as easy as
some of the glib claims of its more enthusiastic supporters would lead
one to believe.
It's more a matter of choosing the right tools. I've got signed
zones that haven't been hand signed in 3 years using a 2 month
signature validity interval. The nameserver just re-signs the
records as they fall due. That's several thousand automatic updates
of the zones in that period. Yes, I've changed the non DNSSEC
content of the zones in that time.
This isn't a protocol issue. It's a tools issue and DNSSEC tools
from all vendors are improving.
It's also extremely easy to construct tools that can warn you to
re-sign if you are doing it by hand. You could replace awk with
perl and have a cross platform tool. Such tools can easily be
added to network management platforms as they are just small
scripts. If you don't have a network managment platform use
cron.
e.g.
% dig axfr dv.isc.org @bsdi.dv.isc.org | awk '$4 == RRSIG $9 WARN {
print }' WARN=`date -u -v +7d +%Y%m%d%H%M%S`
%
% dig axfr dv.isc.org @bsdi.dv.isc.org | awk '$4 == RRSIG $9 WARN {
print }' WARN=`date -u -v +1m +%Y%m%d%H%M%S`
bind9-test-8.dv.isc.org. 86400 IN RRSIG NSEC 5 4 86400 20100929190221
20100731184853 14436 dv.isc.org.
2jHCGeJqH23dO0RV48Uqqp2hXIl1wp3kIslqmdz686uaCNz3WZZUhKzX
EH+8iKc6QQWMZhFzhJoqruiTO6RyIA==
BRNEE8E63.dv.isc.org. 1800IN RRSIG A 5 4 1800 20100929190221
20100731184853 14436 dv.isc.org.
ZhD6uAbGQYDWJ6rob9iyvRNWZ7Tod1as4WEtPV8C+mLF8aJbakwp/76/
f7r7jz/fQOtIMQ/NjXBRT7O4507gIA==
BRNEE8E63.dv.isc.org. 1800IN RRSIG TXT 5 4 1800 20100929190221
20100731184853 14436 dv.isc.org.
Xl3nk8lf2exwGGy2iI2BxVjXO3emvI+8GRmkj+vi7n8rddmP6oJRqPGZ
wmNoZVxMN9XMTghly6w6Cmj8aNAILQ==
BRNEE8E63.dv.isc.org. 86400 IN RRSIG NSEC 5 4 86400 20100929190221
20100731184853 14436 dv.isc.org.
JUR1M8GmlFFYF73v6oh+bdwYuKK0YBMe7b4mDsMBs1bdBqHB52KUZ8eS
KNCRD3GTp8VzwxB1TGmuIq+dGr57lQ==
%
With a minor change it will print out just the zone.
% dig axfr dv.isc.org @bsdi.dv.isc.org | awk '$4 == RRSIG $9 WARN {
print WARNING:, $12, needs re-signing ; exit }' WARN=`date -u -v +1m
+%Y%m%d%H%M%S`
WARNING: dv.isc.org. needs re-signing
%
Wrap it is a while loop and you can do all your zones. The getline
is so we don't generate error messages in the nameserver logs by
causing the axfr to be aborted.
#!/bin/sh -f
WARN=`date -u -v +7d +%Y%m%d%H%M%S`
while read zone server
do
dig axfr $zone @$server | \
awk '$4 == RRSIG $9 WARN
{ print WARNING:, $12, needs re-signing.; while (getline) ; }' \
WARN=$WARN
done
Mark
On Tue, Aug 31, 2010 at 10:36 AM, Glen Barney (AMS) g...@amsl.com wrote:
Community -
The DNS zone files have been re-signed, and we will look into alternative=
s to
the original DNSSEC tools that were in use (which seem to be broken.)
And just a reminder that, while posting complaints to this list might feel
more therapeutic, the secretariat has an address set up for trouble repor=
ts,
which is ietf-act...@ietf.org . =A0Sending complaints to that address will
generally get much faster results.
Thank you!
Glen
Glen Barney
IT Director
AMS (IETF Secretariat)
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
-- =
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
RE: Optimizing for what? Was Re: IETF Attendance by continent
Hadriel Kaplan [mailto://hkap...@acmepacket.com] writes: ... Why Kauai? You list detailed reasons why Hawaii is logical and solves for many of the problems, but you don't say why this island. Because it's the nicest, obviously. :) I strongly disagree: the leeward coast of Maui (in particular, Kihei south) is far better. Kauai is way too rainy... We can even rotate islands if people get bored. Well, there are extensive conference facilities on Oahu, the Big Island, Maui, and Kauai. I have no information as to if they would work for a group of our size and with our need for breakout rooms. I used to attend IEEE 802 and they met in Kauai (Grand Hyatt in Poipu) every few years, but they were a smaller group. There aren't many restaurants nearby, but I certainly don't remember anyone ever complaining about it. ;) 3GPP2 used to (still does?) meet in Wailea every December. Although that is also a much smaller group than the IETF, the hotels dwarfed it so it might be possible to find a reasonable venue for the IETF. However, I think that this is just an idle fantasy: the IETF has too much moral fiber to meet someplace that might actually be fun ;-). -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Optimizing for what? Was Re: IETF Attendance by continent
At 10:08 AM +0700 9/1/10, Glen Zorn wrote: Why Kauai? You list detailed reasons why Hawaii is logical and solves for many of the problems, but you don't say why this island. Because it's the nicest, obviously. :) I strongly disagree: the leeward coast of Maui (in particular, Kihei south) is far better. Kauai is way too rainy... On this point I am in agreement with Glen. However, any of the Hawaiian islands would be a great choice, given the ease of travel arrangements, the warm weather which reduces the need for much of the luggage (no need for warm clothes), and the general difficulty of being disagreeable in such an environment. Many of the conference facilities are open-air, with roofs and protection from rain but still providing ample fresh air and natural light. -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly selected tag: --- Anything labeled NEW and/or IMPROVED isn't. The label means the price went up. The label ALL NEW, COMPLETELY NEW, or GREAT NEW means the price went way up. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RFC 5669 on The SEED Cipher Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP)
A new Request for Comments is now available in online RFC libraries. RFC 5669 Title: The SEED Cipher Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP) Author: S. Yoon, J. Kim, H. Park, H. Jeong, Y. Won Status: Standards Track Stream: IETF Date: August 2010 Mailbox:seok...@kisa.or.kr, se...@kisa.or.kr, hrp...@kisa.or.kr, hcj...@kisa.or.kr, yj...@kisa.or.kr Pages: 13 Characters: 24918 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-avt-seed-srtp-14.txt URL:http://www.rfc-editor.org/rfc/rfc5669.txt This document describes the use of the SEED block cipher algorithm in the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS TRACK] This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5748 on IANA Registry Update for Support of the SEED Cipher Algorithm in Multimedia Internet KEYing (MIKEY)
A new Request for Comments is now available in online RFC libraries. RFC 5748 Title: IANA Registry Update for Support of the SEED Cipher Algorithm in Multimedia Internet KEYing (MIKEY) Author: S. Yoon, J. Jeong, H. Kim, H. Jeong, Y. Won Status: Informational Stream: IETF Date: August 2010 Mailbox:seok...@kisa.or.kr, jije...@kisa.or.kr, rinyf...@kisa.or.kr, hcj...@kisa.or.kr, yj...@kisa.or.kr Pages: 5 Characters: 8198 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-seokung-msec-mikey-seed-05.txt URL:http://www.rfc-editor.org/rfc/rfc5748.txt This document updates IANA registries to support the SEED block cipher algorithm for the Secure Real-time Transport Protocol (SRTP) and the secure Real-time Transport Control Protocol (SRTCP) in Multimedia Internet KEYing (MIKEY). This document is not an Internet Standards Track specification; it is published for informational purposes. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5963 on IPv6 Deployment in Internet Exchange Points (IXPs)
A new Request for Comments is now available in online RFC libraries. RFC 5963 Title: IPv6 Deployment in Internet Exchange Points (IXPs) Author: R. Gagliano Status: Informational Stream: IETF Date: August 2010 Mailbox:rogag...@cisco.com Pages: 10 Characters: 22786 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-v6ops-v6inixp-09.txt URL:http://www.rfc-editor.org/rfc/rfc5963.txt This document provides guidance on IPv6 deployment in Internet Exchange Points (IXPs). It includes information regarding the switch fabric configuration, the addressing plan and general organizational tasks that need to be performed. IXPs are mainly a Layer 2 infrastructure, and, in many cases, the best recommendations suggest that the IPv6 data, control, and management plane should not be handled differently than in IPv4. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5965 on An Extensible Format for Email Feedback Reports
A new Request for Comments is now available in online RFC libraries. RFC 5965 Title: An Extensible Format for Email Feedback Reports Author: Y. Shafranovich, J. Levine, M. Kucherawy Status: Standards Track Stream: IETF Date: August 2010 Mailbox:i...@shaftek.org, standa...@taugh.com, m...@cloudmark.com Pages: 25 Characters: 47452 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-marf-base-06.txt URL:http://www.rfc-editor.org/rfc/rfc5965.txt This document defines an extensible format and MIME type that may be used by mail operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used in Internet email. [STANDARDS TRACK] This document is a product of the Messaging Abuse Reporting Format Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Call Control UUI Service for SIP (cuss)
A new IETF working group has been formed in the Real-time Applications and Infrastructure Area. For additional information, please contact the Area Directors or the WG Chairs. Call Control UUI Service for SIP (cuss) --- Current Status: Active Working Group Chair(s): Vijay K. Gurbani (v...@alcatel-lucent.com) Enrico Marocco (enrico.maro...@telecomitalia.it) Real-time Applications and Infrastructure Area Director(s): Gonzalo Camarillo (gonzalo.camari...@ericsson.com) Robert Sparks (rjspa...@nostrum.com) Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo (gonzalo.camari...@ericsson.com) Mailing Lists: General Discussion: c...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cuss Archive: http://www.ietf.org/mail-archive/web/cuss/ Description of Working Group: The Call control UUI Service for SIP (CUSS) working group is chartered to define a Session Initiation Protocol (SIP) mechanism for transporting call-control related user-to-user information (UUI) for applications using SIP to establish media sessions. The information transported is essentially opaque to SIP, but is tagged with the application that generated it and the encoding method. One important application of this mechanism is interworking with the ISDN User to User Information Service. This application, defined by ITU-T Q.931, is extensively deployed in the PSTN today supporting such applications as contact centers, call centers, and automatic call distributors (ACDs). A major barrier to the movement of these applications to SIP is the lack of a standard mechanism to transport this information in SIP. For interworking with ISDN, minimal information about the content of the UUI is available to the PSTN-SIP gateways. In this special case, the application tag will indicate ISDN UUI Service 1 interworking. Call control UUI is a small piece of application information conveyed between user agents during call control operations. As a result, the information must be conveyed with the INVITE transaction. A goal is to avoid a dependency on multipart MIME support. The mechanism must interwork with the existing ISDN service but should also be extensible for use by other applications and non-ISDN protocols. Even though interworking with the PSTN is an important requirement, call control UUI can be exchanged between native SIP clients that do not have any ISUP support. Therefore, existing SIP-T encapsulation-based approaches defined in RFC3372 do not meet the requirements to transport this type of information. Mechanisms based on the SIP INFO method, RFC2976, will not be considered by the working group since the UUI contents carry information that must be conveyed during session setup at the user agent - the information must be conveyed with the INVITE transaction. The information must be passed with the session setup request (INVITE), responses to that INVITE, or session termination requests. As a result, it is not possible to use INFO in these cases. The working group will define guidelines for other applications to utilize the mechanism and the information that each application must specify to utilize the mechanism. New applications of the mechanism will require a standards-track document. The mechanism developed in this working group is applicable in the following situations: 1. The information is generated and consumed by an application during session setup using SIP, but the application is not necessarily even SIP aware. 2. The behavior of SIP entities that support it is not significantly changed (as discussed in Section 4 of RFC 5727). 3. User Agent Clients (UAC) and User Agent Servers (UAS) are the generator and consumer of the UUI data. Proxies may route based on the application tag. 4. Intermediary elements or proxies can remove or insert UUI information This mechanism is not applicable in the following situations: 1. The behavior of SIP entities that support it is significantly changed (as discussed in Section 4 of RFC 5727). 2. The information is generated and consumed at the SIP layer by SIP elements. 3. SIP elements besides the UAC and UAS might be interested in consuming (beyond adding or removing) the information. 4. There are specific privacy issues involved with the information being transported (e.g., geolocation or emergency-related information). The group will produce: - A problem statement and requirements document for implementing a SIP call control UUI mechanism. - A specification of the SIP extension to best meet those requirements. - An application usage specification for the ISDN UUI Service. Goals and Milestones: Dec 10 - Problem statement and requirements document to IESG (Informational) Jun 11 - SIP call control UUI specification to IESG (PS) Jun 11 - ISDN UUI Service application usage specification to IESG (PS)
WG Action: Port Control Protocol (pcp)
A new IETF working group has been formed in the Internet Area. For additional information, please contact the Area Directors or the WG Chairs. Port Control Protocol (pcp) --- Current Status: Active Working Group Chairs: Alain Durand (adur...@juniper.com) Dave Thaler (dtha...@microsoft.com) Internet Area Directors: Ralph Droms (rdroms.i...@gmail.com) Jari Arkko (jari.ar...@piuha.net) Internet Area Advisor: Jari Arkko (jari.ar...@piuha.net) Mailing Lists: General Discussion: p...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/pcp Archive: http://www.ietf.org/mail-archive/web/pcp/current/maillist.html Description of Working Group: Middleboxes such as NATs and firewalls have seen significant deployment in residential and enterprise networks for years. Applications have adapted to such environments. A first family of solutions involves some form of static configuration on the middlebox to perform port opening and/or port forwarding. Another family of solutions works indirectly, using external services to help the establishment of connections and work around the NAT. STUN (RFC 5389) and TURN (RFC 5766) are examples of such solutions. A third family of solutions include protocols that work directly with the middlebox to dynamically open up ports. Universal Plug and Play Internet Gateway Device (UPnP-IGD) and NAT Port Mapping Protocol (NAT-PMP) are examples of such solutions. IPv4 address exhaustion is now forcing ISPs to deploy carrier-grade NAT devices in their network. Those devices could operate either in addition to or instead of an existing NAT device. An example of the former case is a double NAT configuration and an example of the latter case is the application of Dual Stack Lite (DS-Lite) in a network. These deployments will break a fundamental assumption made by protocols, such UPnP or NAT-PMP, that the NAT is located on the same link as the host running the client application. As a result, such applications may break in the presence of a carrier grade NAT. The PCP working group is chartered to standardize a client/server Port Control Protocol (PCP) to enable an explicit dialog with a middlebox such as a NAT or a firewall to open up and/or forward TCP or UDP port, regardless of the location of that middlebox. A PCP client can be used by applications to directly dialog with the middlebox running a PCP server. It can also be used by a home gateways on behalf of applications. This eases the deployment of PCP in situations where applications have already changed to support the APIs necessary for communicating with UPnP-IGD or NAT-PMP. Those applications only work today when the home gateway gets a public address, but may no longer work in situations where the gateway is behind another NAT. Home gateways could use PCP to translate and relay those UPnP and NAP-PMP messages to the PCP server, thus allowing such applications to continue working as they do today. The functionality that enables the control of IPv4 middleboxes such as NAT devices or firewalls can also be useful in IPv6 context, to control IPv6 functionality in firewalls. As such, PCP will be defined for both IPv4 and IPv6. The discovery PCP servers, using classic methods such as DHCP options, is in scope for the PCP working group. The working group will also ensure that the protocol has the necessary security mechanisms. The IETF will make no changes to either NAT-PMP or UPnP-IGP protocols, and they will be used only as is. Deliverables: - PCP protocol description and terminology document - PCP service discovery document - PCP relay of UPnP document - PCP relay of NAT-PMP document Goals and Milestones: - Oct 2010 First WG draft on PCP protocol description - Dec 2010 First WG draft on PCP service discovery - Feb 2011 First WG draft on UPnP relay - Feb 2011 First WG draft on NAT-PMP relay - May 2011 Send PCP protocol description to IESG for publication as Proposed Standard - May 2011 Send PCP service discovery to IESG for publication as Proposed Standard - Oct 2011 Send UPnP relay to IESG for publication as Proposed Standard - Oct 2011 Send NAT-PMP relay to IESG for publication as Proposed Standard ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5982 on IP Flow Information Export (IPFIX) Mediation: Problem Statement
A new Request for Comments is now available in online RFC libraries. RFC 5982 Title: IP Flow Information Export (IPFIX) Mediation: Problem Statement Author: A. Kobayashi, Ed., B. Claise, Ed. Status: Informational Stream: IETF Date: August 2010 Mailbox:ak...@nttv6.net, bcla...@cisco.com Pages: 25 Characters: 56005 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-ipfix-mediators-problem-statement-09.txt URL:http://www.rfc-editor.org/rfc/rfc5982.txt Flow-based measurement is a popular method for various network monitoring usages. The sharing of flow-based information for monitoring applications having different requirements raises some open issues in terms of measurement system scalability, flow-based measurement flexibility, and export reliability that IP Flow Information Export (IPFIX) Mediation may help resolve. This document describes some problems related to flow-based measurement that network administrators have been facing, and then it describes IPFIX Mediation applicability examples along with the problems. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the IP Flow Information Export Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: RECHARTER: Network Configuration (netconf)
The Network Configuration (netconf) working group in the Operations and Management Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Network Configuration (netconf) --- Current Status: Active Working Group Chairs: Bert Wijnen (berti...@bwijnen.net) Mehmet Ersue (mehmet.er...@nsn.com) Operations and Management Area Directors: Dan Romascanu (droma...@avaya.com) Ronald Bonica (rbon...@juniper.net) Operations and Management Area Advisor: Dan Romascanu (droma...@avaya.com) Mailing Lists: General Discussion: netc...@ietf.org To Subscribe: netconf-requ...@ietf.org or: https://www.ietf.org/mailman/listinfo/netconf Archive:http://www.ietf.org/mail-archive/web/netconf/ Description of Working Group: Configuration of networks of devices has become a critical requirement for operators in today's highly interoperable networks. Operators from large to small have developed their own mechanisms or used vendor specific mechanisms to transfer configuration data to and from a device, and for examining device state information which may impact the configuration. Each of these mechanisms may be different in various aspects, such as session establishment, user authentication, configuration data exchange, and error responses. The NETCONF Working Group has produced a protocol suitable for network configuration, with the following characteristics: - Provides retrieval mechanisms which can differentiate between configuration data and non-configuration data - Is extensible enough so that vendors can provide access to all configuration data on the device using a single protocol - Has a programmatic interface (avoids screen scraping and formatting-related changes between releases) - Uses an XML-based data representation, that can be easily manipulated using non-specialized XML manipulation tools. - Supports integration with existing user authentication methods - Supports integration with existing configuration database systems - Supports multiple (e.g. candidate and running) data-stores to optimize configuration preparation and activation - Supports network wide configuration transactions (with features such as locking and rollback capability) - Runs over a secure transport; SSH is mandatory to implement while TLS, BEEP, and SOAP are optional transports. - Provides support for asynchronous notifications. The NETCONF protocol has been designed independent of the data modeling language. The IETF recommends to use YANG as the NETCONF modeling language, which introduces advanced language features for configuration management. In the current phase of the incremental development of NETCONF the workgroup will focus on following items: 1. NETCONF implementations have shown that the specification in RFC4741 is not 100% clear and has lead to different interpretations and implementations. Also some errors have been uncovered. So the WG will do an rfc4741bis with following constraints: - bug fixes are to be done - clarifications can be done - extensions can be done only when needed to fix bugs or inconsistencies (i.e. we are not doing a NETCONF V2) - The work was started based on the discussion in IETF #73 (see http://www.ietf.org/proceedings/08nov/slides/netconf-3.pdf). 2. A technical errata has been posted on rfc4742. The work on rfc4741bis also uncovered some additional fixes/clarifications that need to be made to rfc4742, the WG has been working on rfc4742bis and is nearly done with this work item. 3. Netconf Access Control Model (NACM) Requirements and Solution. There is a need for standard mechanisms to restrict NETCONF protocol access for authenticated users to a pre- configured (by operator) subset of all available NETCONF operations and content. The WG will produce a document which identifies the access control requirements specific to the NETCONF protocol, as defined in [4741bis]. This document will also provide a standard YANG data model which addresses these requirements. It is possible that the WG will not reach solution consensus on every possible requirement identified in the document. In this case, it is expected that the solution will evolve over time to meet the the remaining unmet requirements. 4. The NETCONF server may want to notify interested clients about particular NETCONF protocol/server events. The WG will work on a NETCONF specific YANG module(s) to define suitable notifications. 5. As implementation and deployment experience gained with the NETCONF monitoring data model, the WG may revise the NETCONF monitoring data model to add additional objects that can be used to check the status of the server
WG Action: RECHARTER: Mobility EXTensions for IPv6 (mext)
The Mobility EXTensions for IPv6 (mext) working group in the Internet Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Mobility EXTensions for IPv6 (mext) - Status: Active Working Group Chairs: Marcelo Bagnulo (marc...@it.uc3m.es) Julien Laganier (juli...@qualcomm.com) Internet Area Directors: Ralph Droms (rdroms.i...@gmail.com) Jari Arkko (jari.ar...@piuha.net) Internet Area Advisor: Jari Arkko (jari.ar...@piuha.net) Mailing Lists: General Discussion: m...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mext Archive: http://www.ietf.org/mail-archive/web/mext Description of Working Group: Mobile IPv6 specifies routing support which permits an IPv6 host to continue using its home address as it moves around the Internet, enabling continuity of sessions. Mobile IPv6 supports transparency above the IP layer, including maintenance of active transport level sessions. In addition, network mobility (NEMO) mechanisms built on top of Mobile IPv6 allow managing the mobility of an entire network, as it changes its point of attachment to the Internet. The base specifications consist of: o RFC 3775 (Mobile IPv6) o RFC 3963 (NEMO) o RFC 4877 (Mobile IPv6 Operation with IKEv2) o RFC (Dual Stack Mobile IPv6) o RFC 5648 (Multiple Care-of Addresses Registration) o RFC 5846 (Binding Revocation) o RFC-to-be (Flow Binding Policy Transport and Flow Binding Policy Format) The MEXT Working Group continues the work of the former MIP6, NEMO, and MONAMI6 Working Groups. The primary goal of MEXT will be to enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments and specific deployment scenarios. Additionally, the working group will ensure that any issues identified by implementation and interoperability experience are addressed, and that the base specifications are maintained. The group will also produce informational documentation, such as design rationale documents or description of specific issues within the protocol. The MEXT WG will also explore experimental alternative security mechanisms. The security mechanism specified in the existing standard track RFCs (RFC3775bis, RFC4877) remains the mandatory to implement mechanism that guarantees interoperability between different implementations. The MEXT WG is chartered to deliver one or more experimental alternative mechanisms. All the alternative solutions will be published as experimental RFCs. In addition, the working group will bring to completion earlier work on prefix delegation for NEMO, RADIUS support for Mobile IPv6, Mobile IPv6 operation with firewalls, and home agent reliability specifications. Work items related to base specification maintenance include: Create and maintain issue lists that are generated on the basis of implementation and interoperability experience. Address specific issues with specific updates or revisions of the base specification. Currently known specific issues include support for overlapping (private) IPv4 home addresses, negotiation of the protection required for payload traffic, and discovery of the home agent address in IPv4-only networks. Goals and Milestones: Dec 2010 Submit the final doc on Prefix Delegation for NEMO to the IESG, for Proposed Standard Dec 2010 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a proposed standard. Dec 2010 Submit I-D(s) related to specific updates and corrections of RFC 3775 to IESG for publication as Proposed Standard. Jan 2011 Submit I-D 'Home agent reliability' to IESG for publication as a Proposed Standard. Jan 2011 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational. Aug 2011 Submit I-Ds on alternative security mechanisms to the IESG for publication as Experimental. Sep 2011 Submit I-D 'Overlapping IPv4 address support' to IESG for publication as Proposed Standard. Sep 2011 Submit I-D 'Home agent discovery in IPv4-only networks via DHCP' to IESG for publication as Proposed Standard. Dec 2011 Submit I-D 'Negotiation of the protection for payload traffic' to IESG for publication as Proposed Standard. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-eai-frmwrk-4952bis-07.txt (Overview and Framework for Internationalized Email) to Proposed Standard
The IESG has received a request from the Email Address Internationalization WG (eai) to consider the following document: - 'Overview and Framework for Internationalized Email' draft-ietf-eai-frmwrk-4952bis-07.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2010-09-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-eai-frmwrk-4952bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-eai-frmwrk-4952bis/ No IPR declarations were found that appear related to this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
