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: IETF 78: getting to/from/around Maastricht
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. Yes, once you get into the former Soviet Union, you are in a totally different rail transport system and you need to use local sites to get your info, and probably buy your tickets via local companies who ask you to fax your credit card info and post you your tickets. http://www.poezda.net/en/index is a good site for checking schedules although it doesn't have all the trains on the edge of the former SU. For instance it couldn't find the Ukrainian train #401 from Praha (Prague) to Lvov when I was recently buying tickets for a trip from London to Krivoy Rog, Ukraine. Also, the station names are in the native languages so Prague is Praha, but interestingly, they don't use Ukrainian names like Lviv preferring the Russian name Lvov instead. Before you buy any tickets, do read up on Russian/ex-SU trains and ticket types because the typical 1st class/2nd class system does not really apply. And make sure you really understand what Platskartny means before you choose that type of sleeper rather than Kupe. In a nutshell, Platskartny cars are like a barracks with bunkbeds, and Kupe or Spalvagon is a car full of sleeper compartments. And Beijing is a major destination for Russian Railways with lots of regular trains from Moscow, so you definitely could get to IETF Beijing that way if you have the time to spare. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 78: getting to/from/around Maastricht
I cannot recommend http://www.seat61.com/ enough for all worldwide train travel. Adrian - Original Message - From: Michael Dillon wavetos...@googlemail.com To: ietf@ietf.org Sent: Friday, July 16, 2010 10:07 AM Subject: Re: IETF 78: getting to/from/around Maastricht 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. Yes, once you get into the former Soviet Union, you are in a totally different rail transport system and you need to use local sites to get your info, and probably buy your tickets via local companies who ask you to fax your credit card info and post you your tickets. http://www.poezda.net/en/index is a good site for checking schedules although it doesn't have all the trains on the edge of the former SU. For instance it couldn't find the Ukrainian train #401 from Praha (Prague) to Lvov when I was recently buying tickets for a trip from London to Krivoy Rog, Ukraine. Also, the station names are in the native languages so Prague is Praha, but interestingly, they don't use Ukrainian names like Lviv preferring the Russian name Lvov instead. Before you buy any tickets, do read up on Russian/ex-SU trains and ticket types because the typical 1st class/2nd class system does not really apply. And make sure you really understand what Platskartny means before you choose that type of sleeper rather than Kupe. In a nutshell, Platskartny cars are like a barracks with bunkbeds, and Kupe or Spalvagon is a car full of sleeper compartments. And Beijing is a major destination for Russian Railways with lots of regular trains from Moscow, so you definitely could get to IETF Beijing that way if you have the time to spare. --Michael Dillon ___ 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
Fwd: Historic Moment - Root zone of the Internet was just signed minutes ago!!!
I am passing on this announcement, and I want to add my thanks to everyone in the Internet community that played a role in deploying DNSSEC. Russ Housley IETF Chair -- Forwarded Message From: Rod Beckstrom rod.beckst...@icann.org Date: Thu, 15 Jul 2010 14:24:38 -0700 To: Rod Beckstrom rod.beckst...@icann.org Cc: ICANN Board of Directors icann-bo...@icann.org, Staff icann-st...@icann.org Subject: Historic Moment - Root zone of the Internet was just signed minutes ago!!! Dear Board and Staff, Now is a historic moment for the Internet, ICANN, IETF, Verisign and the Dept of Commerce. The root zone of Internet is now more secure - signed cryptographically w/ DNSSEC. Special thanks to Rick Lamb, DNSSEC lead in ICANN; Steve Crocker, SSAC; Suzanne Woolf, RSSAC; all of you on board and staff and the many people in the multi-stakeholder community who have made this happen. Congratulations. A true milestone in the history of the Internet. We’ve had a remarkable year of accomplishments. Warmly, Rod Rod Beckstrom President and CEO ICANN One World. One Internet. Everyone Connected. -- End of Forwarded Message ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Historic Moment - Root zone of the Internet was just signed minutes ago!!!
Congratulations ! A lot of hard work by a lot of people went into this, and we owe those people a vote of thanks. Regards Marshall On Jul 16, 2010, at 8:23 AM, Russ Housley wrote: I am passing on this announcement, and I want to add my thanks to everyone in the Internet community that played a role in deploying DNSSEC. Russ Housley IETF Chair -- Forwarded Message From: Rod Beckstrom rod.beckst...@icann.org Date: Thu, 15 Jul 2010 14:24:38 -0700 To: Rod Beckstrom rod.beckst...@icann.org Cc: ICANN Board of Directors icann-bo...@icann.org, Staff icann-st...@icann.org Subject: Historic Moment - Root zone of the Internet was just signed minutes ago!!! Dear Board and Staff, Now is a historic moment for the Internet, ICANN, IETF, Verisign and the Dept of Commerce. The root zone of Internet is now more secure - signed cryptographically w/ DNSSEC. Special thanks to Rick Lamb, DNSSEC lead in ICANN; Steve Crocker, SSAC; Suzanne Woolf, RSSAC; all of you on board and staff and the many people in the multi-stakeholder community who have made this happen. Congratulations. A true milestone in the history of the Internet. We’ve had a remarkable year of accomplishments. Warmly, Rod Rod Beckstrom President and CEO ICANN One World. One Internet. Everyone Connected. -- End of Forwarded Message ___ 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: Historic Moment - Root zone of the Internet was just signedminutes ago!!!
+1!!! -Original Message- From: ietf-boun...@ietf.org on behalf of Marshall Eubanks Sent: Fri 7/16/2010 5:27 AM To: Russ Housley Cc: ietf@ietf.org Subject: Re: Historic Moment - Root zone of the Internet was just signedminutes ago!!! Congratulations ! A lot of hard work by a lot of people went into this, and we owe those people a vote of thanks. Regards Marshall On Jul 16, 2010, at 8:23 AM, Russ Housley wrote: I am passing on this announcement, and I want to add my thanks to everyone in the Internet community that played a role in deploying DNSSEC. Russ Housley IETF Chair -- Forwarded Message From: Rod Beckstrom rod.beckst...@icann.org Date: Thu, 15 Jul 2010 14:24:38 -0700 To: Rod Beckstrom rod.beckst...@icann.org Cc: ICANN Board of Directors icann-bo...@icann.org, Staff icann-st...@icann.org Subject: Historic Moment - Root zone of the Internet was just signed minutes ago!!! Dear Board and Staff, Now is a historic moment for the Internet, ICANN, IETF, Verisign and the Dept of Commerce. The root zone of Internet is now more secure - signed cryptographically w/ DNSSEC. Special thanks to Rick Lamb, DNSSEC lead in ICANN; Steve Crocker, SSAC; Suzanne Woolf, RSSAC; all of you on board and staff and the many people in the multi-stakeholder community who have made this happen. Congratulations. A true milestone in the history of the Internet. We've had a remarkable year of accomplishments. Warmly, Rod Rod Beckstrom President and CEO ICANN One World. One Internet. Everyone Connected. -- End of Forwarded Message ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
SECDIR review: draft-hammer-hostmeta
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 should treat these comments just like any other last call comments. I have a number of security-related concerns with this specification. First, I'm concerned by assumptions in the document that each of: http://example.com http://example.com:8080 https://example.com https://example.com:8443 identify resources under the control of same entity. It is fairly common to there to be multiple http/https services running on a single host, each service possibly operated by different entities as delegated by the host administrator. I think it would be better (from a security perspective) to have service-level metadata, not host level meta data. That is, make no assumption that the above URIs are under control of the same entity, or even if so, that it desirable to a single policy/metadata covering multiple services. And I think it very important to always fetch the meta data from the service one is accessing. The document calls for client to fetch https://example.com/.well-known/host-meta even when https://example.com:8443 is URI wants policy for. Even worse, the document calls for the client to, if the above fetch does not produce a valid hostmeta document, for the client to fetch http://example.com/.well-known/host-meta. An attacker could easily cause https://example.com/.well-known/host-meta to fail to produce a valid hostmeta document, and serve its own hostmeta document in response to the client's http://example.com/.well-known/host-meta, without supplanting the https://example.com:8443 service. The document fails to discuss such attacks. I recommend reworking this document to provide service-level, not host-level, metadata. In particular, the metadata document should always be retrieved through the service the client is interested in using, such as by fetching /.well-known/metadata. If the authors rather continue pursuing a host-based solution, the security considerations should include a discussion of the above issues. Regards, Kurt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fwd: Historic Moment - Root zone of the Internet was just signed minutes ago!!!
On 7/16/2010 5:23 AM, Russ Housley wrote: I am passing on this announcement, and I want to add my thanks to everyone in the Internet community that played a role in deploying DNSSEC. Russ Housley IETF Chair Hey Russ - how do you think the California Appellate Court's ruling on Court Admissible evidence in California v Khaled affects this... I can tell you - - the DNSSEC design sucks as an evidentiary source of anything and now evidence from it is inadmissible per Khaled in California Courts as 'untrustworthy'... it looks like Dean will win this one eh? Todd Glassey -- Forwarded Message From: Rod Beckstrom rod.beckst...@icann.org Date: Thu, 15 Jul 2010 14:24:38 -0700 To: Rod Beckstrom rod.beckst...@icann.org Cc: ICANN Board of Directors icann-bo...@icann.org, Staff icann-st...@icann.org Subject: Historic Moment - Root zone of the Internet was just signed minutes ago!!! Dear Board and Staff, Now is a historic moment for the Internet, ICANN, IETF, Verisign and the Dept of Commerce. The root zone of Internet is now more secure - signed cryptographically w/ DNSSEC. Special thanks to Rick Lamb, DNSSEC lead in ICANN; Steve Crocker, SSAC; Suzanne Woolf, RSSAC; all of you on board and staff and the many people in the multi-stakeholder community who have made this happen. Congratulations. A true milestone in the history of the Internet. We’ve had a remarkable year of accomplishments. Warmly, Rod Rod Beckstrom President and CEO ICANN One World. One Internet. Everyone Connected. -- End of Forwarded Message ___ 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: Historic Moment - Root zone of the Internet was just signed minutes ago!!!
On 16 jul 2010, at 14:23, Russ Housley wrote: I am passing on this announcement, and I want to add my thanks to everyone in the Internet community that played a role in deploying DNSSEC. Too bad it doesn't work for me. Here IANA publishes info that needs conversion steps that I don't have tools for to perform: http://data.iana.org/root-anchors/ And pulling down the key from the root servers doesn't give me something that works. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Historic Moment - Root zone of the Internet was just signed minutes ago!!!
On Fri, Jul 16, 2010 at 06:35:15PM +0200, Iljitsch van Beijnum wrote: Here IANA publishes info that needs conversion steps that I don't have tools for to perform: http://data.iana.org/root-anchors/ The key data can be read directly from http://data.iana.org/root-anchors/root-anchors.xml. It seems to me that if you have vi (or any other favourite text editor), you have the tools to use that. What am I missing? And pulling down the key from the root servers doesn't give me something that works. Define works? A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Historic Moment - Root zone of the Internet was just signed minutes ago!!!
On 16 jul 2010, at 18:40, Andrew Sullivan wrote: Define works? Less of this: validating @0x82e9000: . DNSKEY: please check the 'trusted-keys' for '.' in named.conf. If anyone can point me to a key I can paste in my BIND config that will allow me to actually validate domains that would be great. And/or perhaps the right information hasn't propagated through the DNS system? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Historic Moment - Root zone of the Internet was just signed minutes ago!!!
On Fri, 16 Jul 2010, Iljitsch van Beijnum wrote: Too bad it doesn't work for me. BIND's trust anchors are in DNSKEY format, but IANA publishes the root key in DS format. You can fetch the root DNSKEY using dig, convert it into a DS using BIND's dnssec-dsfromkey program and compare the result to the published trust anchor to verify that you have the right DNSKEY before adding it to BIND's configuration. There is a longer explanation of the process at http://fanf.livejournal.com/107310.html unbound requires trust anchors in DS format which is somewhat more convenient, though you still have to edit IANA's XML to convert it into master file format. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ MALIN HEBRIDES BAILEY: WESTERLY OR NORTHWESTERLY 5 TO 7, OCCASIONALLY GALE 8 BAILEY, BUT CYCLONIC 4 OR 5 FOR A TIME IN NORTH HEBRIDES. ROUGH OR VERY ROUGH. RAIN OR SQUALLY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Historic Moment - Root zone of the Internet was just signed minutes ago!!!
On Fri, Jul 16, 2010 at 18:01:20 +0100, Tony Finch wrote: On Fri, 16 Jul 2010, Iljitsch van Beijnum wrote: Too bad it doesn't work for me. BIND's trust anchors are in DNSKEY format, but IANA publishes the root key in DS format. You can fetch the root DNSKEY using dig, convert it into a DS using BIND's dnssec-dsfromkey program and compare the result to the published trust anchor to verify that you have the right DNSKEY before adding it to BIND's configuration. There is a longer explanation of the process at http://fanf.livejournal.com/107310.html Thanks! That was very useful. I finally got it working. I would also like to check the output for a zone that is verifyable not correct. Any examples of signed RRs with an incorrect signature? rvdp ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
secdir review of draft-ietf-ipsecme-roadmap
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 reviews the landscape of existing IPsec-related documents, providing a list of documents (by topic) and brief descriptions. The document's claim that there are no security considerations with this document seems accurate to me. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Historic Moment - Root zone of the Internet was just signed minutes ago!!!
On Fri, 16 Jul 2010, Ronald van der Pol wrote: I would also like to check the output for a zone that is verifyable not correct. Any examples of signed RRs with an incorrect signature? Have a look at http://www.dnssec-tools.org/testzone/ Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ SOUTH BISCAY SOUTH FITZROY: WESTERLY BECOMING VARIABLE OR NORTHERLY 3 OR 4, OCCASIONALLY 5, BUT 6 LATER IN SOUTHEAST FITZROY. MODERATE OR ROUGH. SHOWERS. MODERATE OR GOOD. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Historic Moment - Root zone of the Internet was just signed minutes ago!!!
On 16 jul 2010, at 19:56, Ronald van der Pol wrote: http://fanf.livejournal.com/107310.html Thanks! That was very useful. I finally got it working. Yes, me too. I would also like to check the output for a zone that is verifyable not correct. Any examples of signed RRs with an incorrect signature? I skipped this step: In the options section of named.conf you should have the directive dnssec-lookaside auto; This enables DNSSEC lookaside validation, which is necessary to bridge gaps (such as ac.uk) in the chain of trust between the root and lower-level signed zones with the result that www.ietf.org, www.iab.org, www.isc.org, all fail to validate. Not sure what the deal is there. Only www.nic.cat works. BTW, this is great: https://addons.mozilla.org/en-US/firefox/addon/64247/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Historic Moment - Root zone of the Internet was just signed minutes ago!!!
On Fri, 16 Jul 2010, Iljitsch van Beijnum wrote: www.ietf.org, www.iab.org, www.isc.org, all fail to validate. Not sure what the deal is there. The DS record for .org has not yet been added to the root zone so the chain of trust is broken. https://addons.mozilla.org/en-US/firefox/addon/64247/ Groovy :-) Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ FAIR ISLE FAEROES: CYCLONIC BECOMING SOUTHWESTERLY 5 TO 7, OCCASIONALLY GALE 8 AT FIRST, DECREASING 4 AT TIMES. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH AT FIRST. RAIN OR SQUALLY SHOWERS. MODERATE, OCCASIONALLY POOR. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Historic Moment - Root zone of the Internet was just signed minutes ago!!!
On Fri, Jul 16, 2010 at 08:13:46PM +0200, Iljitsch van Beijnum wrote: with the result that www.ietf.org, www.iab.org, www.isc.org, all fail to validate. Not sure what the deal is there. Only www.nic.cat works. BTW, this is great: The deal is that .org doesn't have a DS record in the root zone, but it is signed. They determined that they did not want to put their DS into the root prior to the production signing of the root. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [dispatch] WG Review: Call Control UUI for SIP (cuss)
At least from my perspective (which is from supporting the capabilities of the ISDN User-to-User service) the answer is No. This is information above the SIP layer in an application, and to look at the contents, one must come out above the SIP layer into that application. It could be conditional that the SIP message itself is not processed if the information is not there, and the SIP request therefore rejected, but this has nothing to do with the contents. And personally, I do not believe that bit will every happen at a proxy, but will be at the recipient UA. regards Keith -Original Message- From: dispatch-boun...@ietf.org [mailto:dispatch-boun...@ietf.org] On Behalf Of Cullen Jennings Sent: Thursday, July 15, 2010 3:06 PM To: Gonzalo Camarillo Cc: DISPATCH list; IESG IESG; IETF-Discussion list Subject: Re: [dispatch] WG Review: Call Control UUI for SIP (cuss) I don't think this resolves the issue. The issue is if this information is used for a call control. Basically do proxies need to be able to look at this to make decision about what they are going to do. We at least need a Yes/No answer to this question from the proponents of this work and the charter to make that clear. On Jul 14, 2010, at 2:25 AM, Gonzalo Camarillo wrote: Hi, thanks for your comments on the charter proposal. Per the comments received, we will modify bullet 5 as follows so that it is clearer: OLD: 5. SIP elements may need to apply policy about passing and screening the information. NEW: 5. SIP elements may need to apply policy about passing and filtering UUI. The included application, encoding, semantics, and content information will allow endpoint or intermediary SIP elements to allow or block UUI based on the type and originator, not based on the actual UUI data, which may be end-to-end encrypted by the application. Further discussions on this topic should happen on the mailing list of this WG. Cheers, Gonzalo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ dispatch mailing list dispa...@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: web security happenings
The problems are not necessarily caused by any specific spec on its own. Many Web security issues occur because the components are developed in isolation and people really don't have a good model for how they behave as a group. The IETF needs to be involved in this work. Quite how that happens is another matter. One of the weaknesses of the IETF way of doing things is that there is no clear mechanism for performing maintenance. On Wed, Jul 14, 2010 at 11:33 AM, Cullen Jennings flu...@cisco.com wrote: On Jul 13, 2010, at 22:26 , Iljitsch van Beijnum wrote: On 13 jul 2010, at 18:49, Peter Saint-Andre wrote: fun technologies like AJAX but also opens up the possibility for new attacks (cross-site scripting, cross-site request forgery, malvertising, clickjacking, and all the rest). Isn't this W3C stuff? It's important stuff - if they are not making progress on it, some SDO with people that have skill and expertise in this area should do work on it. A BOF is a great way to find out if we have people with the expertise and the interest to do work. My gut feeling is that we probably do. ___ 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: Gen-ART LC Review of draft-ietf-tsvwg-ecn-tunnel-08
Ben, At 20:47 14/07/2010, Ben Campbell wrote: Thanks for the response. Further comments inline. (If I don't comment on a point, please take that to mean okay :-) ) On Jul 13, 2010, at 6:13 AM, Bob Briscoe wrote: Ben, Thank you for your review comments from the GEN-ART perspective. I think I have dealt with all your points in my responses, which are inline... There is just one outstanding question for you concerning updating BCP4774... At 22:23 01/07/2010, 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-tsvwg-ecn-tunnel-08 Reviewer: Ben Campbell Review Date: 2010-07-01 IETF LC End Date: 2010-07-06 IESG Telechat date: (if known) Summary: This draft is almost ready for publication as a proposed standard. I have a couple of procedural questions that should be considered first, as well as a few editorial comments. Major Issues: None. Minor Issues: -- RFC Editor request (immediately after ToC): In the RFC index, RFC3168 should be identified as an update to RFC2003. RFC4301 should be identified as an update to RFC3168. This seems odd. I assume the intent is that this draft says that things from 3168 should be applied to 2003, therefore updating 2003, etc? If so, wouldn't it be more correct to say that _this_ draft updates 2003 and 3168? Quoting from the RFC Index: /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Updates refers to other RFCs that this one merely updates but does not replace); ... Generally, only immediately succeeding and/or preceding RFCs are indicated, not the entire history of each related earlier or later RFC in a related series. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ The consensus on the TSVWG list was that the updates should be identified in the RFC Index as follows 2003 - 3168 - ecn-tunnel 3168 - 4301 - ecn-tunnel In the headers of this draft we have said: Updates: 3168, 4301 But we also noticed that the RFC Index incorrectly omits to identify that these RFCs in turn already update the earlier RFCs. The note to the RFC Editor was the result of this consensus request from the TSVWG list. [BTW, There is nonetheless text on backward compatibility between this I-D and these early RFCs in Section 6. And Appendix A; Early ECN Tunnelling RFCs explains the interactions.] Summary: I propose no change on this point. It's not entirely clear to me how the RFC index quote supports the argument one way or another. I was not proposing we needed to maintain the entire history of updates. Was the work group consensus that 3168 _already_ updated 2003 (i.e. the original intent of 3618 was to update 2003), and the notation of that fact was simply missing? Or that it _should_have_ updated 2003 but did not? If the first, then I agree with the proposed approach. But if the second, then I think you have a case of _this_ draft updating 2003 by calling out text in 3618 that should now apply to it. The first. Even though section 9 of RFC3168 on updates to tunnel processing http://tools.ietf.org/html/rfc3168#section-9 contained two parallel subsections (9.1 9.2) on respectively IP in IP tunnels referencing 2003 and IPsec tunnels referencing 2401 (IPsec), it only included 2401 in the Updates header. There can be no other explanation than simple error for omitting Updates 2003. In particular, does 3168 contain text on how it updates 2003? Could someone understand how 3168 applies to 2003 by reading that document alone? Yes Or does that text reside in this draft? No In any case, if you still believe it should stand as is, I will not push the point further. If the IESG is okay with the approach, then it's fine with me. I guess I ought to submit an erratum for RFC3168 and RFC4301 at the same time, in order to add these two Updates headers. -- 7, first paragraph: The guidance below extends RFC4774, giving additional guidance on designing any alternate ECN semantics that would also require alternate tunnelling semantics. Should this draft be listed as updating 4774? Also, you've declared this section non-normative. What does it mean to non-normatively extend a BCP? That's a very good question/point and I would appreciate your advice on how to proceed. My take was that this was an informational section of a STDS RFC. So I did not include any RFC2119 language. But your nicely succinct question throws this into better perspective. Should I: * Add 'Updates 4774' to the headers? * Scrub the line saying This section is informative not normative. ? * Shift the RFC2119 keywords in this section to upper-case? See my response to your separate email on this subject.
Re: Nomcom 2010-2011: Results of Random Selection
is it possible to record this process? we will only know the result after selection, but not know the acutal process. Jiankang Yao - Original Message - From: Thomas Walsh twa...@juniper.net To: ietf@ietf.org Sent: Friday, July 16, 2010 5:59 AM Subject: FW: Nomcom 2010-2011: Results of Random Selection -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of NomCom Chair Sent: Thursday, July 15, 2010 2:56 PM To: IETF Announcement list Subject: Nomcom 2010-2011: Results of Random Selection Hi all, The following is the list of 10 nomcom volunteers selected randomly from this list: https://datatracker.ietf.org/ann/nomcom/2395/ 87. Huub van Helvoort, Huawei Technologies; 25. Dorothy Gellert, InterDigital Communications; 14. Gregory Cauchie, France Telecom Orange; 46. Suresh Krishnan, Ericsson; 79. Pete St. Pierre, Oracle; 31. Tony Hansen, ATT Labs; 75. Jan Seedorf, NEC Laboratories Europe; 91. Rolf Winter, NEC Labs Europe; 47. Dirk Kroeselberg, Nokia Siemens Networks; 23. Mehmet Ersue, Nokia Siemens Networks; This begins the one week community review of the selection - please let me know ASAP if you see any problems with the selections. The challenge period will close at 17:00 PDT (24:00 UTC) on Thursday, July 22, 2010. I am in the process of contacting the individuals to confirm they are still able to serve on the Nomcom. The details for the selection are listed below. Seed Values: The seed values used in selecting the committee members are follows: The National Lottery: Daily Play: Thursday, July 15, 2010 Results: https://www.national-lottery.co.uk/player/p/results/dailyplay.ftl (7 numbers from 1-27) Value: 01 08 09 14 17 20 23 US National debt (Debt Held by the Public), published by the Treasury department as of Wednesday, July 14, 2010 (Published on July 15, 2010) http://www.treasurydirect.gov/NP/BPDLogin?application=np Last 8 digits, ignore the commas and periods Value: 76998828 US National debt (Intragovernmental Holdings), published by the Treasury department as of Wednesday, July 14, 2010 (Published on July 15, 2010) http://www.treasurydirect.gov/NP/BPDLogin?application=np Last 8 digits, ignore the commas and periods Value: 79622755 Massachusetts Lottery Powerball Drawing: Wednesday, July 14, 2010 Results (11:20 PM EDT draw on July 14, 2010): http://www.masslottery.com/games/lottery/powerball.html (5 numbers from 1-59 and 1 Power Ball number from 1-39) Value: 20 21 23 38 42 6 With the selection algorithm results are based on RFC 3797 as follows: $ ./selection.exe Type size of pool: (or 'exit' to exit) 101 Type number of items to be selected: (or 'exit' to exit) 15 Approximately 58.1 bits of entropy needed. Type #1 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. 01 08 09 14 17 20 23 1 8 9 14 17 20 23 Type #2 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. 76998828 76998828 Type #3 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. 79622755 79622755 Type #4 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. 20 21 23 38 42 6 6 20 21 23 38 42 Type #5 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. end Key is: 1.8.9.14.17.20.23./76998828./79622755./6.20.21.23.38.42./ indexhex value of MD5div selected 1 D092CC19DF2C1FEEB24AAC2AB125F55A 101 - 87 - 2 7FB953E77CA8324A610E79E913AD0190 100 - 25 - 3 2371D3F40C93DB58353C0293210E7761 99 - 14 - 4 388238514EE702E862D627B202DF05CD 98 - 46 - 5 007A2D4BB6183716D28D5B800676F115 97 - 79 - 6 B12DF65CFF27EB958643B7622E1CA75C 96 - 31 - 7 C307E04AB485B8ACDF1D6188F97780F5 95 - 75 - 8 C8B42FE23BD3FFE011DB7CC5275B71C1 94 - 91 - 9 545AEF5C89368BF992E93447B4381787 93 - 47 - 10 BB39831C989C6249ECF3E3D4890B3DA9 92 - 23 - 11 8F82F9BDFC95D405BD756BBB2B5F2BE2 91 - 16 - 12 1F3FCE8A3D82CF8FBB72AE1945249478 90 - 60 - 13 2A18B179BFC4D53F5ED295BC61D8F1B9 89 - 92 - 14 F4C656521040602854F0808A605D3145 88 - 89 - 15 AA8545B3E2728947D721670FD6440951 87 - 19 - Done, type any character to exit. Regards, Thomas Walsh nomcom-ch...@ietf.org twa...@juniper.net ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ 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: Historic Moment - Root zone of the Internet was just signedminutes ago!!!
+1!!! +2! I'm happy to see this happen... Thanks for all the work. :-) Russ signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
http://www.ietf.org/tools/rfcdiff
The rfcdiff tool has become critical to the IETF. Many people use it while reviewing drafts, and the RFC Editor uses it in the Auth48 process. Recognizing our dependency on this tool, it has been installed on the www.ietf.org web site, and it will be maintained by the Secretariat with assistance from the tools volunteers. http://www.ietf.org/tools/rfcdiff Enjoy, Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Nomcom 2010-2011: Results of Random Selection
Can't you repeat it yourself ? It is supposed to be a deterministic process (once the inputs are obtained). RFC 2777 A method such that public information will enable any person to verify the randomness of the selection meets this criterion. This document gives an example of such a method. Regards Marshall On Jul 15, 2010, at 10:48 PM, Jiankang YAO wrote: is it possible to record this process? we will only know the result after selection, but not know the acutal process. Jiankang Yao - Original Message - From: Thomas Walsh twa...@juniper.net To: ietf@ietf.org Sent: Friday, July 16, 2010 5:59 AM Subject: FW: Nomcom 2010-2011: Results of Random Selection -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org ] On Behalf Of NomCom Chair Sent: Thursday, July 15, 2010 2:56 PM To: IETF Announcement list Subject: Nomcom 2010-2011: Results of Random Selection Hi all, The following is the list of 10 nomcom volunteers selected randomly from this list: https://datatracker.ietf.org/ann/nomcom/2395/ 87. Huub van Helvoort, Huawei Technologies; 25. Dorothy Gellert, InterDigital Communications; 14. Gregory Cauchie, France Telecom Orange; 46. Suresh Krishnan, Ericsson; 79. Pete St. Pierre, Oracle; 31. Tony Hansen, ATT Labs; 75. Jan Seedorf, NEC Laboratories Europe; 91. Rolf Winter, NEC Labs Europe; 47. Dirk Kroeselberg, Nokia Siemens Networks; 23. Mehmet Ersue, Nokia Siemens Networks; This begins the one week community review of the selection - please let me know ASAP if you see any problems with the selections. The challenge period will close at 17:00 PDT (24:00 UTC) on Thursday, July 22, 2010. I am in the process of contacting the individuals to confirm they are still able to serve on the Nomcom. The details for the selection are listed below. Seed Values: The seed values used in selecting the committee members are follows: The National Lottery: Daily Play: Thursday, July 15, 2010 Results: https://www.national-lottery.co.uk/player/p/results/dailyplay.ftl (7 numbers from 1-27) Value: 01 08 09 14 17 20 23 US National debt (Debt Held by the Public), published by the Treasury department as of Wednesday, July 14, 2010 (Published on July 15, 2010) http://www.treasurydirect.gov/NP/BPDLogin?application=np Last 8 digits, ignore the commas and periods Value: 76998828 US National debt (Intragovernmental Holdings), published by the Treasury department as of Wednesday, July 14, 2010 (Published on July 15, 2010) http://www.treasurydirect.gov/NP/BPDLogin?application=np Last 8 digits, ignore the commas and periods Value: 79622755 Massachusetts Lottery Powerball Drawing: Wednesday, July 14, 2010 Results (11:20 PM EDT draw on July 14, 2010): http://www.masslottery.com/games/lottery/powerball.html (5 numbers from 1-59 and 1 Power Ball number from 1-39) Value: 20 21 23 38 42 6 With the selection algorithm results are based on RFC 3797 as follows: $ ./selection.exe Type size of pool: (or 'exit' to exit) 101 Type number of items to be selected: (or 'exit' to exit) 15 Approximately 58.1 bits of entropy needed. Type #1 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. 01 08 09 14 17 20 23 1 8 9 14 17 20 23 Type #2 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. 76998828 76998828 Type #3 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. 79622755 79622755 Type #4 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. 20 21 23 38 42 6 6 20 21 23 38 42 Type #5 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. end Key is: 1.8.9.14.17.20.23./76998828./79622755./6.20.21.23.38.42./ indexhex value of MD5div selected 1 D092CC19DF2C1FEEB24AAC2AB125F55A 101 - 87 - 2 7FB953E77CA8324A610E79E913AD0190 100 - 25 - 3 2371D3F40C93DB58353C0293210E7761 99 - 14 - 4 388238514EE702E862D627B202DF05CD 98 - 46 - 5 007A2D4BB6183716D28D5B800676F115 97 - 79 - 6 B12DF65CFF27EB958643B7622E1CA75C 96 - 31 - 7 C307E04AB485B8ACDF1D6188F97780F5 95 - 75 - 8 C8B42FE23BD3FFE011DB7CC5275B71C1 94 - 91 - 9 545AEF5C89368BF992E93447B4381787 93 - 47 - 10 BB39831C989C6249ECF3E3D4890B3DA9 92 - 23 - 11 8F82F9BDFC95D405BD756BBB2B5F2BE2 91 - 16 - 12 1F3FCE8A3D82CF8FBB72AE1945249478 90 - 60 - 13 2A18B179BFC4D53F5ED295BC61D8F1B9 89 - 92 - 14 F4C656521040602854F0808A605D3145 88 - 89 - 15 AA8545B3E2728947D721670FD6440951 87 - 19 - Done, type any character to exit. Regards, Thomas Walsh nomcom-ch...@ietf.org twa...@juniper.net ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RE: Nomcom 2010-2011: Results of Random Selection
From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Marshall Eubanks [...@americafree.tv] Can't you repeat it yourself ? It is supposed to be a deterministic process (once the inputs are obtained). RFC 2777 A method such that public information will enable any person to verify the randomness of the selection meets this criterion. This document gives an example of such a method. ___ Ah, yes, but if you re-read the announcement of the selection, it starts: From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org On Behalf Of NomCom Chair Sent: Thursday, July 15, 2010 2:56 PM Hi all, The following is the list of 10 nomcom volunteers selected randomly from this list: https://datatracker.ietf.org/ann/nomcom/2395/ You have to read well down into the message to be told that the process is based (somehow) on RFC 3797. It's a typical problem around here -- messages that should be stand-alone announcements aren't written carefully, and the authors forget how much background knowledge they are assuming. (Would this announcement be comprehensible to someone who was unaware of RFC 3797/2777?) A better start would be: The following is the list of 10 nomcom volunteers selected randomly by the process of RFC 3797 from this list [URL]. The input data to the RFC 3797 algorithm is detailed below. Dale ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
TSV-DIR review of draft-daboo-srv-caldav-05
Hi, all, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. We would expect that the service names caldev, caldevs, carddev, and carddevs would need to be registered in the SRV registry, which is being unified with the IANA ports registry as per pending BCP draft-ietf-tsvwg-iana-ports. None of these strings is registered in the current SRV registry. See the note #2 below. The use of these strings inside the SRV records is consistent with the description in the pending BCP draft-ietf-tsvwg-iana-ports. Some issues to discuss: 1) the document contains a section discussing the registration of caldev and caldevs (Sec 3); a corresponding section for carddev and carddevs should be added. 2) the IANA recommendation that these four service names be added as aliases to http and https (correspondingly) does not seem correct. If these are indeed aliases, then this specification should recommend the use of either http or https (correspondingly) in the SRV records, without the need for new names. However, I believe the intent is that the caldev and/or carddev servers could exist on other ports than the typical web server; as such, they should be registered as service names (as per the existing SRV registry, e.g.), NOT as aliases in either the SRV registry (which has no such concept) or the IANA ports table. I.e., these new names should be registered as service names, not as aliases. This should be sufficient for the purposes of this document. 3) The use of a required URI suffix (/carddev or /caldev) seems to be too fixed. draft-cheshire-dnsext-dns-sd (intended as standards track) indicates a way to embed this information in the a TXT record with the same DNS name as the SRV record; RFC 5507 represents the IAB (informational) position that most additional information should be included in new RR types (though it's unclear this could easily support URI suffixes). My concern is that this document does neither; it embeds this information in this document as a requirement, rather than presenting it as a configurable option with a default. I would prefer to see the latter (regardless of how), to indicate the URI suffix if not the 'default' as specified in this document. I don't see any other significant transport issues. It is always useful to note that short, multibyte transactions benefit from TCPs with Nagle disabled, but that is not a critical issue. I'd be glad to discuss this further on whatever list would be useful. Joe - ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Archiving more legacy text files
IETF Community: Earlier this year we archived some legacy text files and notified the IETF community which ones those were. This is follow-up message with a new set of registries that will be archived soon. Background: In cooperation with the IETF Community, we have been working on a project to publish the registries we maintain for the IETF in XML. With the help of RFC authors, WG chairs, Area Directors and Experts we have made considerable progress. In order to give the community plenty of time to change scripts, pointers or just become aware of the new formats, we have been updating and making available both the old legacy text files and the new XML versions for newly converted registries. Since we believe sufficient time has now passed and maintaining the legacy files has a non-trivial administrative impact, we will no longer be making available the old legacy text files and will archive them. The old URLs will contain information for the location of the new versions available (TXT, XML and XHTML). The legacy text registries will be changed to the pointer text beginning on August 9, 2010. We will repeat this step again in January 2011 with the registries that we convert between July 1, 2010 and December 31, 2010. Thank you, Michelle Cotton Manager, IETF Relations - IANA ICANN List of Registries that have been converted to XML between January 1, 2010 and June 30, 2010: http://www.iana.org/assignments/dkim-parameters http://www.iana.org/assignments/eap-numbers http://www.iana.org/assignments/eap-pax http://www.iana.org/assignments/gmpls-sig-parameters http://www.iana.org/assignments/gssapi-service-names http://www.iana.org/assignments/method-tokens http://www.iana.org/assignments/location-type-registry http://www.iana.org/assignments/gsmpv3-adapt http://www.iana.org/assignments/gsmpv3-event http://www.iana.org/assignments/gsmpv3-failure http://www.iana.org/assignments/gsmpv3-label http://www.iana.org/assignments/gstn-extensions http://www.iana.org/assignments/im-srv-labels http://www.iana.org/assignments/ipv4-tos-byte http://www.iana.org/assignments/ipv6-multicast-addresses http://www.iana.org/assignments/ip-xns-mapping http://www.iana.org/assignments/machine-names http://www.iana.org/assignments/mail-encoding http://www.iana.org/assignments/media-feature-tags http://www.iana.org/assignments/multicast-addresses http://www.iana.org/assignments/ospf-authentication-codes http://www.iana.org/assignments/ospf-sig-alg http://www.iana.org/assignments/operating-system-names http://www.iana.org/assignments/pronet80-type-numbers http://www.iana.org/assignments/radius-types http://www.iana.org/assignments/rip-types http://www.iana.org/assignments/spi-numbers http://www.iana.org/assignments/scsp-numbers http://www.iana.org/assignments/sip-events http://www.iana.org/assignments/sip-precond-types http://www.iana.org/assignments/sieve-notification http://www.iana.org/assignments/notification-capability-parameters http://www.iana.org/assignments/sgmp-vendor-specific-codes http://www.iana.org/assignments/safi-namespace http://www.iana.org/assignments/tsig-algorithm-names ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSV-DIR review of draft-daboo-srv-caldav-05
Hi Joe, --On July 16, 2010 2:55:42 PM -0700 Joe Touch to...@isi.edu wrote: 1) the document contains a section discussing the registration of caldev and caldevs (Sec 3); a corresponding section for carddev and carddevs should be added. As noted in the fourth paragraph of the introduction, the CardDAV service types have been defined in [I-D.ietf-vcarddav-carddav] currently in the RFC Editor queue. 2) the IANA recommendation that these four service names be added as aliases to http and https (correspondingly) does not seem correct. If these are indeed aliases, then this specification should recommend the use of either http or https (correspondingly) in the SRV records, without the need for new names. However, I believe the intent is that the caldev and/or carddev servers could exist on other ports than the typical web server; as such, they should be registered as service names (as per the existing SRV registry, e.g.), NOT as aliases in either the SRV registry (which has no such concept) or the IANA ports table. I.e., these new names should be registered as service names, not as aliases. This should be sufficient for the purposes of this document. In [I-D.ietf-vcarddav-carddav], after much debate with the IESG and the associated working group, the approach of registering the service types as aliases was agreed upon as a stop gap measure until the IANA SRV registry is setup. draft-daboo-srv-caldav follows that same approach. 3) The use of a required URI suffix (/carddev or /caldev) seems to be too fixed. draft-cheshire-dnsext-dns-sd (intended as standards track) indicates a way to embed this information in the a TXT record with the same DNS name as the SRV record; RFC 5507 represents the IAB (informational) position that most additional information should be included in new RR types (though it's unclear this could easily support URI suffixes). My concern is that this document does neither; it embeds this information in this document as a requirement, rather than presenting it as a configurable option with a default. I would prefer to see the latter (regardless of how), to indicate the URI suffix if not the 'default' as specified in this document. RFC5785 defines the .well-known URI - I think it is very clear that, given that CalDAV and CardDAV are in effect web-services, making use of .well-known is the right thing to do. There is no need for any additional data in the DNS. What is more, the .well-known approach is in fact useful in the absence of SRV - it can minimise the information users would have to enter. I don't see this approach as being too fixed - the whole point about .well-known is to fix things like this. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IANA Office Hours at IETF-78 in Maastricht
Greetings! IANA will be holding Office Hours at the IETF-78 in Maastricht. This will continue to give everyone an opportunity to discuss IANA Considerations in your documents, requests for registrations in existing registries or any other questions you may have. We will have a table near the IETF registration area, staffed during the following hours: Monday - Thursday, 0900 - 1600 Thank you and see you soon! Michelle Cotton Manager, IETF Relations - IANA ICANN ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5902 on IAB Thoughts on IPv6 Network Address Translation
A new Request for Comments is now available in online RFC libraries. RFC 5902 Title: IAB Thoughts on IPv6 Network Address Translation Author: D. Thaler, L. Zhang, G. Lebovitz Status: Informational Stream: IAB Date: July 2010 Mailbox:dtha...@microsoft.com, li...@cs.ucla.edu, gregory.i...@gmail.com, i...@iab.org Pages: 15 Characters: 37224 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-iab-ipv6-nat-03.txt URL:http://www.rfc-editor.org/rfc/rfc5902.txt There has been much recent discussion on the topic of whether the IETF should develop standards for IPv6 Network Address Translators (NATs). This document articulates the architectural issues raised by IPv6 NATs, the pros and cons of having IPv6 NATs, and provides the IAB's thoughts on the current open issues and the solution space. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Architecture Board. 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 5942 on IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes
A new Request for Comments is now available in online RFC libraries. RFC 5942 Title: IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes Author: H. Singh, W. Beebee, E. Nordmark Status: Standards Track Stream: IETF Date: July 2010 Mailbox:shem...@cisco.com, wbee...@cisco.com, erik.nordm...@oracle.com Pages: 11 Characters: 27035 Updates:RFC4861 I-D Tag:draft-ietf-6man-ipv6-subnet-model-12.txt URL:http://www.rfc-editor.org/rfc/rfc5942.txt IPv6 specifies a model of a subnet that is different than the IPv4 subnet model. The subtlety of the differences has resulted in incorrect implementations that do not interoperate. This document spells out the most important difference: that an IPv6 address isn't automatically associated with an IPv6 on-link prefix. This document also updates (partially due to security concerns caused by incorrect implementations) a part of the definition of on-link from RFC 4861. [STANDARDS TRACK] This document is a product of the IPv6 Maintenance 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
