Re: Last Call: draft-carpenter-renum-needs-work (Renumbering still needs work) to Informational RFC
Masataka, The reality, instead, is that actual networks running IPv4 and IPv6 ***CAN'T*** deal with renumbering, because of their inertia. While I obviously have sympathy for the sentiment, I think your statement is too strong. I believe it would be better to say that end users have an economic incentive to avoid having to renumber, and most are able to make use of RFC 1918 / ULAs and NAT with attendant consequences to avoid the effort involved. Still, I would argue strongly for inclusion of a fuller discussion about technologies that obviate the need to renumber. Eliot ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Important Information about IETF 76 Meeting Registration
Eric Rescorla wrote: Can you clarify what, if any, the security properties of this system are: In particular: 1. Will the RFID tag in question respond to any reader or just those controlled by the secretariat? 2. Is the information on the tag in the clear or encrypted? normal 125khz tags don't contain much data. The radio equivalent of a 1 dimensional barcode is just a serial number. any data is a product of association with that token stays in the network rather than the chip. These are vulnerable to (trivial) replay attacks. but challenge response requires more logic. more powerful card systems of course exist in profusion it's just a matter of picking one. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Important Information about IETF 76 Meeting Registration
At Thu, 10 Sep 2009 05:05:08 -0700, Joel Jaeggli wrote: Eric Rescorla wrote: Can you clarify what, if any, the security properties of this system are: In particular: 1. Will the RFID tag in question respond to any reader or just those controlled by the secretariat? 2. Is the information on the tag in the clear or encrypted? normal 125khz tags don't contain much data. The radio equivalent of a 1 dimensional barcode is just a serial number. any data is a product of association with that token stays in the network rather than the chip. These are vulnerable to (trivial) replay attacks. but challenge response requires more logic. more powerful card systems of course exist in profusion it's just a matter of picking one. Yes. This is why I asked. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Some more background on the RFID experiment in Hiroshima
At Thu, 10 Sep 2009 12:23:31 -0700 (PDT), Ole Jacobsen wrote: An Overview of the RFID Experiment for IETF 76 in Hiroshima. Some of the details are still being worked out, but here is a summary: Basics -- * Each attendee will be issued an RFID card at the registration desk. The information stored on the card is ONLY a number, no personal data is stored on the card. (Note: the attendee can opt out at any time, including not collecting the card, see below). Note that removing your name from the database doesn't remove the ability of someone to track you via the tag. * The information (number) on the card is not encrypted and could be read by any RFID reader, but again, it's only a number. How are the numbers assigned? * The number is linked to a back-end database through the readers provided at the meeting. * The database will contain only the following information from the registration data: First Name, Last Name, Affiliation (if present), and ISO-3166 Code * Each attendee will also be issued a username and password. This will give him/her access to the back-end database (via a web interface) where the user can: Does the Web UI make sure to hide the number-attendee mapping? -Ekr ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Some more background on the RFID experiment in Hiroshima
Inline. On Fri, 11 Sep 2009, Eric Rescorla wrote: At Thu, 10 Sep 2009 12:23:31 -0700 (PDT), * Each attendee will be issued an RFID card at the registration desk. The information stored on the card is ONLY a number, no personal data is stored on the card. (Note: the attendee can opt out at any time, including not collecting the card, see below). Note that removing your name from the database doesn't remove the ability of someone to track you via the tag. If this is a great concern I would suggest either returning the card or not collecting it in the first place. Also, the type or readers used require close proximity to trigger, you literally have to touch the reader with your card to make it work. So nobody from the host organization at least will be tracking you. I am also not sure what value there is in knowing that 3478273983421 spent 10 minutes in trill and then moved on to behave (pun intended). * The information (number) on the card is not encrypted and could be read by any RFID reader, but again, it's only a number. How are the numbers assigned? Don't know, but I have asked. I am guessing they are pre-assigned in the sense that each card has a unique ID that is later mapped to the database. Does the Web UI make sure to hide the number-attendee mapping? Don't know that either, but I agree that it should. It hasn't been fully designed yet. Will ask that they do this. -Ekr Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Some more background on the RFID experiment in Hiroshima
Ole Jacobsen wrote: Inline. On Fri, 11 Sep 2009, Eric Rescorla wrote: At Thu, 10 Sep 2009 12:23:31 -0700 (PDT), * Each attendee will be issued an RFID card at the registration desk. The information stored on the card is ONLY a number, no personal data is stored on the card. (Note: the attendee can opt out at any time, including not collecting the card, see below). Note that removing your name from the database doesn't remove the ability of someone to track you via the tag. If this is a great concern I would suggest either returning the card or not collecting it in the first place. Also, the type or readers used require close proximity to trigger, you literally have to touch the reader with your card to make it work. Actually the strength of the field dictates the distance at which the card can be energized. It is the reader not the passive rfid tag that is operative in this regard. More than 12-18 is fairly hard for 125khz tags... So nobody from the host organization at least will be tracking you. I am also not sure what value there is in knowing that 3478273983421 spent 10 minutes in trill and then moved on to behave (pun intended). * The information (number) on the card is not encrypted and could be read by any RFID reader, but again, it's only a number. How are the numbers assigned? Don't know, but I have asked. I am guessing they are pre-assigned in the sense that each card has a unique ID that is later mapped to the database. Does the Web UI make sure to hide the number-attendee mapping? Don't know that either, but I agree that it should. It hasn't been fully designed yet. Will ask that they do this. -Ekr Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj ___ 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
IPv6 standard?
Hi, It occurs to me that a small but potentially meaningful thing that the IETF could do to push IPv6 adoption is move RFC 2460 from draft standard to standard. Iljitsch ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Noel Chiappa wrote: From: Stephan Wenger st...@stewe.org For the IETF as an organization, I see no value beyond traditions in staying with the RFC publication model. (The marketing value of using the RFC series is IMHO contradicted by the lack of control of the IETF over the RFC series). If I understand you correctly, you're suggesting creating a new document series for use by the IETF, for its standards documents? If so, I don't recall this possibility being discussed before, although I can't believe it hasn't been suggested at some point. Well, there's STDs. Do you also want PSTD and DSTD numbers? Such a change would be acceptable to me - although it might take a while to build up the distribution system that already exists for RFCs. Using STD/DSTD/PSTD would just be additional numbers. Joe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkqqbLsACgkQE5f5cImnZrv5WwCg58JSLLQTkOPBJWZzkNx8HyDJ ahkAn2O/m6u2U6jUTxybaR1myDUEwscm =2c62 -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Sullivan wrote: On Wed, Sep 09, 2009 at 09:19:05AM -0700, Dave CROCKER wrote: First, you lack empirical data to substantiate your assessment of the perception. Well, Wikipedia (which IMO is primarily useful as a repository for finding out what everyone knows) has this first sentence in its description of the RFC series: It's certainly *not* what everybody knows; it's more like what everybody's being told. If you don't like a Wikipedia definition, change it. ;-) Joe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkqqbTMACgkQE5f5cImnZruATgCePexWhxGHNJR2ygAU1iig4Smk EaQAn110fNjgej7dQhiF+XKxXvmOY7w0 =4tjN -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
On Sep 10, 2009, at 5:35 PM, Ahmad Muhanna wrote: Hi Ben, Thanks for the follow up. Please see answers inline. Regards, Ahmad -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Subject: Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 This is a followup on revision 12, since it came out before I got to revision 11: Overall, I think this revision is much better. Most of my concerns have been addressed, but I have a few minor ones remaining. Specific comments: -- Section 10.1, 2nd bullet: I don't think we resolved my concern about the SHOULD in the last sentence. To recap, I think that needs to either be a MUST, or the draft should offer guidance about the reasoning for the SHOULD and the consequences of not following it. I'm picking on this one in particular because it seems like not sending a BRA when the A bit was set is likely to cause retransmissions on the part of the initiator. [Ahmad] If the MN does NOT have a binding in its BUL for the HoA address that is included in the Type 2 Routing header, the mobile node should not respond back (that was specifically discussed in details on the wg ml). It is like instructing the MN to delete a session that does not exist. Although, the (A) bit is set, it is up to the mobile node whether to send a BRA or not. I do not believe we need to mandate that via a MUST. I am sure some handset vendors will not like that at all. Did the work group consider that if a MN doesn't respond, it can expect to get a bunch of retransmissions--each of which it will need to parse, check for bindings, etc.; possibly eating more resources than responding in the first place would have? I could understand if the concern was that the MN might get irrelevant (or even malicious) BRIs from arbitrary sources, but since they should only be arriving from trusted peers over established SAs, I find the choice surprising. But in any case, my concern was that it should be a MUST _or_ it should have discussion of the consequences of not doing it. A line or two mentioning why this is a should, under what circumstances it makes sense to not respond, and most importantly pointing out the potential for needless retransmission would help. Also, the last sentence does not seem to make grammatical sense after the edits. Thx, here is the new text, please let me know if you are okay with it. o If the Acknowledge (A) bit is set in the Binding Revocation Indication and its Binding Update List contains an entry for the IP address in the Type 2 routing header, the mobile node MUST send a Binding Revocation Acknowledgement. However, in all other cases when the Acknowledge (A) bit is set in the BRI, the mobile node SHOULD sends a Binding Revocation Acknowledgement following Section 10.2. That's better, depending on the resolution of the SHOULD discussion above. -- Same section, 4th bullet: This one still seems to ignore the A bit value. Given the other edits, am I correct in assuming that you expect a BRA if the A bit was set, otherwise a silent discard? [Ahmad] I believe we discussed this a little before. It is a fatal error and the MN should never receive a BRI with the (P) bit set. That why this behavior is the same regardless of the (A) bit is set or not. If you feel that some clarification about the (A) bit needs to be added, I can say, .. regardless if the Acknowledge (A) bit is set or not, the mobile node MUST silently discard the BRI message. From previous discussion, I thought we had converged on the idea that the A-bit should always be authoritative, rather than having the A-bit treatment change due to context. Again, my concern is that the sender is likely to retransmit multiple times if you don't respond. -- Section 11, (InitMINDelayBRIs) (I think I commented on this, but can't find the resolution) Did you intend for the _default_ to be a range (between .5 and 1 sec), or did you mean to say the default was 1 second, and it must not be configured to less than .5 seconds? I suspect the latter, but it's not clear from the text. [Ahmad] Sure, will fix this as follows: Initial Minimum Delay Between BRI messages (InitMINDelayBRIs) This variable specifies the initial delay timeout in seconds before the revoking mobility entity retransmits a BRI message. The default is 1 second but not to be configured less than 0.5 seconds. That's better, thanks! -- Security Considerations: I think there is enough potential for confusion about when IPSec is required to put some non-normative description of when it is and isn't required, along with references to the normative requirements. [Ahmad] I suppose this is just a comment that does not need clarification or anything like that. It was more a suggestion that you add a sentence or two to the SA discussion in the security considerations section, of
RE: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
Hi Ben, Thanks for the follow up. Please see answers inline. Regards, Ahmad -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Subject: Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 This is a followup on revision 12, since it came out before I got to revision 11: Overall, I think this revision is much better. Most of my concerns have been addressed, but I have a few minor ones remaining. Specific comments: -- Section 10.1, 2nd bullet: I don't think we resolved my concern about the SHOULD in the last sentence. To recap, I think that needs to either be a MUST, or the draft should offer guidance about the reasoning for the SHOULD and the consequences of not following it. I'm picking on this one in particular because it seems like not sending a BRA when the A bit was set is likely to cause retransmissions on the part of the initiator. [Ahmad] If the MN does NOT have a binding in its BUL for the HoA address that is included in the Type 2 Routing header, the mobile node should not respond back (that was specifically discussed in details on the wg ml). It is like instructing the MN to delete a session that does not exist. Although, the (A) bit is set, it is up to the mobile node whether to send a BRA or not. I do not believe we need to mandate that via a MUST. I am sure some handset vendors will not like that at all. Also, the last sentence does not seem to make grammatical sense after the edits. Thx, here is the new text, please let me know if you are okay with it. o If the Acknowledge (A) bit is set in the Binding Revocation Indication and its Binding Update List contains an entry for the IP address in the Type 2 routing header, the mobile node MUST send a Binding Revocation Acknowledgement. However, in all other cases when the Acknowledge (A) bit is set in the BRI, the mobile node SHOULD sends a Binding Revocation Acknowledgement following Section 10.2. -- Same section, 4th bullet: This one still seems to ignore the A bit value. Given the other edits, am I correct in assuming that you expect a BRA if the A bit was set, otherwise a silent discard? [Ahmad] I believe we discussed this a little before. It is a fatal error and the MN should never receive a BRI with the (P) bit set. That why this behavior is the same regardless of the (A) bit is set or not. If you feel that some clarification about the (A) bit needs to be added, I can say, .. regardless if the Acknowledge (A) bit is set or not, the mobile node MUST silently discard the BRI message. -- Section 11, (InitMINDelayBRIs) (I think I commented on this, but can't find the resolution) Did you intend for the _default_ to be a range (between .5 and 1 sec), or did you mean to say the default was 1 second, and it must not be configured to less than .5 seconds? I suspect the latter, but it's not clear from the text. [Ahmad] Sure, will fix this as follows: Initial Minimum Delay Between BRI messages (InitMINDelayBRIs) This variable specifies the initial delay timeout in seconds before the revoking mobility entity retransmits a BRI message. The default is 1 second but not to be configured less than 0.5 seconds. -- Security Considerations: I think there is enough potential for confusion about when IPSec is required to put some non-normative description of when it is and isn't required, along with references to the normative requirements. [Ahmad] I suppose this is just a comment that does not need clarification or anything like that. Thanks again Ben for your review and comments! Thanks! Ben. On Sep 5, 2009, at 3:04 AM, Ahmad Muhanna wrote: Hello, We have updated the draft to address all comments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation -1 1.txt In summary, here is a list of the major changes: 1. Enhanced to the security text mainly under section 6.1. and section 13 (Security Considerations) to address Ben comments. In addition, we eliminated the Security Model section based on Ralph's comment. 2. Enhanced the text for MAG authorization and defined a default mechanism as specified under section 13, Security Considerations. 3. Addressed Pasi's comments by adding text to clearly specify that the current specification uses mobile node identifier option, MN-ID, with subtype 1, as stated mainly under section 5.1. In addition, we defined the format of wild card NAI as per the use of this specification, text under section 8.1.1. 4. Addressed all the remaining of Ralph's detailed comments in several places of the document. 5. Clarified that the responder sends BRA only if the Acknowledge (A) bit is set. Text was tweaked in several places. 6. all nits and editorial comments Please let me know
Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
This is a followup on revision 12, since it came out before I got to revision 11: Overall, I think this revision is much better. Most of my concerns have been addressed, but I have a few minor ones remaining. Specific comments: -- Section 10.1, 2nd bullet: I don't think we resolved my concern about the SHOULD in the last sentence. To recap, I think that needs to either be a MUST, or the draft should offer guidance about the reasoning for the SHOULD and the consequences of not following it. I'm picking on this one in particular because it seems like not sending a BRA when the A bit was set is likely to cause retransmissions on the part of the initiator. Also, the last sentence does not seem to make grammatical sense after the edits. -- Same section, 4th bullet: This one still seems to ignore the A bit value. Given the other edits, am I correct in assuming that you expect a BRA if the A bit was set, otherwise a silent discard? -- Section 11, (InitMINDelayBRIs) (I think I commented on this, but can't find the resolution) Did you intend for the _default_ to be a range (between .5 and 1 sec), or did you mean to say the default was 1 second, and it must not be configured to less than .5 seconds? I suspect the latter, but it's not clear from the text. -- Security Considerations: I think there is enough potential for confusion about when IPSec is required to put some non-normative description of when it is and isn't required, along with references to the normative requirements. Thanks! Ben. On Sep 5, 2009, at 3:04 AM, Ahmad Muhanna wrote: Hello, We have updated the draft to address all comments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-1 1.txt In summary, here is a list of the major changes: 1. Enhanced to the security text mainly under section 6.1. and section 13 (Security Considerations) to address Ben comments. In addition, we eliminated the Security Model section based on Ralph's comment. 2. Enhanced the text for MAG authorization and defined a default mechanism as specified under section 13, Security Considerations. 3. Addressed Pasi's comments by adding text to clearly specify that the current specification uses mobile node identifier option, MN-ID, with subtype 1, as stated mainly under section 5.1. In addition, we defined the format of wild card NAI as per the use of this specification, text under section 8.1.1. 4. Addressed all the remaining of Ralph's detailed comments in several places of the document. 5. Clarified that the responder sends BRA only if the Acknowledge (A) bit is set. Text was tweaked in several places. 6. all nits and editorial comments Please let me know if you still have any issue. Thanks for all of your comments and help! Regards, Ahmad -Original Message- From: Muhanna, Ahmad (RICH1:2H10) Sent: Thursday, August 27, 2009 1:33 PM To: 'Ben Campbell' Cc: Khalil, Mohamed (RICH2:2S20); sgund...@cisco.com; kchowdh...@starentnetworks.com; pyeg...@juniper.net; General Area Review Team; ietf@ietf.org; Jari Arkko; marc...@it.uc3m.es; Laganier, Julien Subject: RE: [PART-I] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 Hi, Ben, -Original Message- Summary: This draft is on the right track, but there are open issues. Additionally, I have a number of editorial comments. Major issues: -- I think the security considerations need quite a bit of work. In particular, there is very little guidance on authorization for sending BRI messages. This seem to me have utility for DoS attacks, particularly with the G bit set. There is mention of reusing existing security associations if IPSec is used--but no mention of what to do if IPSec is not used. [Ahmad] Binding Revocation is used between two peers to revoke/terminate a mobility session(s) that have been created using an IPv6 mobility protocol signaling (Client Mobile IPv6 or Proxy MIP6). RFC3775 and RFC5213, which are the main protocols targeted by this specification, specify that IPsec SHOULD be used. On the other hand, there is NO other standard track specification which specify other security mechanisms to secure the IPv6 mobility signaling. Therefore, Binding Revocation specification assumes the use of whatever security mechanism that currently available to secure the IPv6 mobility signaling. I think there are still a couple of issues here. First, Since the underlying RFCs only specify IPSec at SHOULD strength, this draft needs to discuss the consequences of not using it for BRI. Depending on those consequences, it might be enough to just warn implementors that, if you don't use IPSec, certain bad things can happen. [Ahmad] It is NOT expected that BRI/BRA will use a different security mechanism than what is being used for securing IPv6 mobility signaling. Therefore, in order to alert implementors of the danger if IPsec is NOT used,
Re: [IAB] Call for Comments: Peer-to-peer (P2P) Architectures
Hi Stanislav, thanks for your comments. With respect to including more examples of P2P systems, we received similar comments in the past. Some people thought (like you) that a document having a high number of examples (maybe even an almost-exhaustive list) would be useful for the community. At that point, we decided not to include all those examples in this document and focus instead on general properties and guidelines. However, you are right that such a document could be helpful. During our past discussions, we identified the P2P RG, which was being rechartered at the time of writing the document, as a potential venue to write such a document (we were in touch with the chairs of the RG while writing this document). We realize that there are many potentially-useful documents that can be written in the area of P2P systems and that this document only covers a tiny part of the area. Regarding a correct definition of a P2P system, one of the points the document stresses is the fact that there are multiple definitions in the literature. The document discusses them and describes what they have in common in order to find a common denominator. We believe this approach is more useful than providing our own definition without referencing existing ones. With respect to the taxonomy, you are right that the document provides several taxonomies and not a single one. Section 4 states that but both the Abstract and the title of Section 4 talk about a taxonomy in singular. We will clarify this point so that it does not confuse readers. With those explanations for why the document is the way it is, and with the commitment to clean up the single vs multiple taxonomy, would you like to suggest any specific textual edits to this document with these goals? If so, we would happily consider them to the document's next revision. Thanks, Gonzalo Stanislav Shalunov wrote: I fail to understand the purpose of this document or of publishing it. The abstract promises three things: * a survey of P2P systems * a definition of a P2P system * a taxonomy of P2P systems I found no traces of a survey, no actual taxonomy, and only an inadequate definition in the document. A survey would enumerate P2P systems and describe them. The document only mentions two P2P systems of which, one is universally known and the other is theoretical at present. Kazaa, or current #2 behind BitTorrent eDonkey, or the numerous academically interesting P2P systems are not mentioned, let alone described or classified. There's a section called Taxonomy for P2P Systems, but it doesn't contain any taxonomy, for P2P systems or otherwise. Instead, it contains an attempted literature survey of P2P taxonomies. An actual taxonomy would list the types of P2P systems and their differentiating principles. It would be natural to combine it with a survey, classifying known P2P systems according to the taxonomy you choose. An unmarked paragraph four of Section 2 does provide a definition of a P2P system. A discussion follows it, but it's not clear if it's part of the definition proposed by the document. The definition is weak and generic, yet needs to be substantially stretched so that even BitTorrent, the most common P2P system in use today, fits it. The document is so bad that proposing specific textual changes is besides the point. Here's a sketch of an example of what a more useful document might look like: Definition: A distributed system implemented on a computer network to provide a service is called P2P if it involves a substantial number of nodes that, in addition to consuming the service, also provide it. These nodes are called peers. Note: P2P systems are often contrasted with client/server systems. In the latter, the functions of providing (servers) and consuming (clients) the service are separated into different nodes; in the former, the same nodes (peers) can do both. The distinction sometimes goes deeper and is reflected on the wire protocol level, where P2P protocols are symmetrical in nature, with both sides being able to issue the same set of messages. This, however, is accidental and not a defining part of P2P. Taxonomy 0. Type of service P2P systems can provide various services, such as file distribution and sharing; voice and video calling; audio and video streaming, recorded or live; data backup, etc. 1. Administrative control P2P systems can be under single administrative control, provide multiple realms each under its own administrative control, or be fully administratively decentralized. 2. Tracker P2P systems can include the use of a central server that can provide functions such as peer location and possibly extra services like content indexing. Other systems are trackerless and rely on DHTs and other techniques. 3. Peer equality P2P systems can contain peers that are elected to perform specialized functions, perhaps elevating these peers to near-server status, or all peers can
Re: Last Call: draft-carpenter-renum-needs-work (Renumbering still needs work) to Informational RFC
Eliot, We'll respond in detail to your helpful comments in due course. However, Still, I would argue strongly for inclusion of a fuller discussion about technologies that obviate the need to renumber. The hypothesis of the document is there will always be circumstances in which partial or complete renumbering is needed, whatever such technologies may be available. We should maybe make that clearer in the Introduction. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 standard?
For this and other RFCs, we started some years ago the work at http://www.ipv6-to-standard.org Just waiting for the IESG to take on it ... Regards, Jordi From: Iljitsch van Beijnum iljit...@muada.com Reply-To: ietf-boun...@ietf.org Date: Fri, 11 Sep 2009 17:24:54 +0200 To: IETF Discussion ietf@ietf.org Subject: IPv6 standard? Hi, It occurs to me that a small but potentially meaningful thing that the IETF could do to push IPv6 adoption is move RFC 2460 from draft standard to standard. Iljitsch ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-carpenter-renum-needs-work (Renumbering still needs work) to Informational RFC
Eliot Lear wrote: The reality, instead, is that actual networks running IPv4 and IPv6 ***CAN'T*** deal with renumbering, because of their inertia. While I obviously have sympathy for the sentiment, I think your statement is too strong. I believe it would be better to say that end users have an economic incentive to avoid having to renumber, and most are able to make use of RFC 1918 / ULAs and NAT with attendant consequences to avoid the effort involved. I mean the obstacle against renumbering is inertia of existing implementations, which will not be modified regardless of whatever RFCs published later. The only chance to have deployable renumbering mechanism was in early stages of IPv6 development. It's too late now. The next chance will be when yet another IPng will be developped. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
ICANN NOMCOM 2010 appointment
L.S. This is to inform you that the IAB selected Henk Uijterwaal as the IETF appointed member to the ICANN 2010 Nomcom. The IAB would like to thank Ole Jacobsen for serving on the 2008 and 2009 ICANN Nomcom. For the IAB, --Olaf Kolkman IAB chair. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-ipsecme-ikev2-ipv6-config (IPv6 Configuration in IKEv2) to Experimental RFC
The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'IPv6 Configuration in IKEv2 ' draft-ietf-ipsecme-ikev2-ipv6-config-02.txt as an Experimental RFC 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 2009-09-25. 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 http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-ipv6-config-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18004rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
