RE: Gen-ART LC Review of draft-ietf-dhc-forcerenew-nonce-03
Hello Ben, Thanks for reviewing this document. Please see answers inline [RM] Best regards, Roberta -Original Message- From: Ben Campbell [mailto:b...@nostrum.com] Sent: martedì 7 febbraio 2012 0.17 To: draft-ietf-dhc-forcerenew-nonce@tools.ietf.org Cc: gen-...@ietf.org Review Team; The IETF Subject: Gen-ART LC Review of draft-ietf-dhc-forcerenew-nonce-03 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-dhc-forcerenew-nonce-03 Reviewer: Ben Campbell Review Date: 2012-02-06 IETF LC End Date: 2012-02-06 Summary:This draft is not quite ready for publication as a proposed standard. There are some potentially significant issues that should be addressed first. [Note: Hopefully this draft has had or will have a SecDir review, since it seems ripe for significant security implications.] *** Major issues: -- I admit to not being a DHCP expert, but If I understand this draft correctly, it proposes to send what is effectively a secret-key in a DHCPACK request, then use that key to authenticate a force renew message. It seems like any eavesdropper could sniff that key, and use it to spoof force renew requests. The introduction mentions that there may be some environments where the use of RFC3118 authentication could be relaxed, and offers an example of such an environment. But nowhere does this draft appear to be limited in scope to such environments. [RM] The intention is to use this method only for environments with native security mechanisms, such as the Broadband Access network. You are right it is not clearly said in the document I can add the following sentence at the end of the introduction in order to clarify this point: This mechanism is intended to be use in networks that already have native security mechanisms that provide sufficient protection against spoofing of DHCP traffic. I think some additional text in (perhaps in the security considerations) is needed to explain either why the vulnerability to eavesdroppers is either okay in general, or limits the mechanism's use to environment where it is okay. It also seems like that, in the best case, this mechanism proves only that a Forcerenew request comes from the same DHCP server as in the original transaction, but otherwise does not prove anything about the identity of that server. If so, it would be worth mentioning it. [RM] That's correct this mechanism only proves only that a Forcerenew request comes from the same DHCP server: let me say this is a trade off between the total security provided by RFC 3118 and no security at all. In addition this method relays on the same mechanism already used for DHCPv6 Reconfigure message -- The mechanism appears to be limited to HMAC-MD5, and there does not appear to be any way of selecting other algorithms. Is HMAC-MD5 really sufficient as the only choice? Is there some expectation that stronger mechanisms or algorithm extensibility would be too expensive? (Perhaps the extensibility method would be to specify another mechanism that's identical except for a different HMAC algorithm. But if that's the intent it should be mentioned.) [RM] This is because this mechanism relays on the authentication protocol defined in section 21.5 of RFC 3315 for DHCPv6 Reconfigure and there HMAC-MD5 is used. *** Minor issues: -- Section 1 In such environments the mandatory coupling between FORCERENEW and DHCP Authentication [RFC3118] can be relaxed. It's not clear to me what connection that assertion has with this draft. Is there an intent that the proposed mechanisms be used only in such environments? I don't find any language scoping this proposal to any particular environment. [RM] The intention is to use this method only in environments with native security mechanisms, I'll try to clarify this point -- section 3: Does this draft update either 3203 or 3118? If so, please state that explicitly in the abstract, introduction, and draft headers. (I think it must at least update 3203, since that draft requires the use of 3118, and this draft relaxes that.) [RM] Yes that's correct, it updates 3203, I'll add it in the document. -- section 3.1, last paragraph: ...only if the client and server are not using any other authentication... That seems to conflict with the statement in section 3 that this mechanism is only used if RFC3118 is not used. That is, it's not a choice between this mechanism or any other mechanism, it's a choice between this mechanism or 3118. [RM] I'll clarify the sentence -- section 3.1.3, 2nd paragraph: The server SHOULD NOT include this option unless the client has indicated its capability in a DHCP Discovery message. Why not; what harm would it do? And on the other hand, if you want to discourage it, why not go all the way
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 2/9/12 3:40 PM, Mark Andrews ma...@isc.org wrote: In message 6.2.5.6.2.20120209091221.082cb...@resistor.net, SM writes: Hi Chris, At 08:57 AM 2/9/2012, Chris Grundemann wrote: http://www.apnic.net/publications/news/2011/final-8 I am aware of the APNIC announcement. That's one out of five regions. Are you proposing that every ISP on the planet be given a /10 for inside CGN use, rather than one single /10 being reserved for this purpose? No. If I am not mistaken, IPv4 assignments are on a needs basis. In my previous comment, I mentioned that RIRs are still providing unique IPv4 assignments to service providers that request IPv4 addresses. Even if the IANA pool was not exhausted, it is unlikely that an ISP would get a /20 due to the slow-start mechanism. Regards, -sm In none of the discussions I've seen has anyone proposed forcing ISP's to use this space. It is being provided as a alternative, the same away RFC 1918 space is offered as a alternative. Today you get ask have you considered RFC 1918 space? You can still get space even if RFC 1918 space would have worked. I suspect a similar question, will be part of allocation proceedures, for this space in the future. You need to know that the applicant is aware of this space. Please remember that this draft is in support of ARIN Draft Policy 2011-5. Should this draft become an RFC, and should ARIN pony up the /10, ARIN's staff is likely to look askance at requests for address space for CGNs. IMO, an IETF RFC is not the correct place to tell ARIN or other RIRs how to allocate space; the ARIN/RIR policy processes can be much more targeted to the needs of the community, and in this case, I think your concern has already been addressed. Chris Mark -- 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
--On Friday, February 10, 2012 08:47 -0700 Chris Donley c.don...@cablelabs.com wrote: ... Please remember that this draft is in support of ARIN Draft Policy 2011-5. Should this draft become an RFC, and should ARIN pony up the /10, ARIN's staff is likely to look askance at requests for address space for CGNs. IMO, an IETF RFC is not the correct place to tell ARIN or other RIRs how to allocate space; the ARIN/RIR policy processes can be much more targeted to the needs of the community, and in this case, I think your concern has already been addressed. Chris, To follow up on an earlier comment, the rate at which ARIN (or other RIRs) are running out of /10s (or /8s) is probably irrelevant, as are hypotheses about what ARIN staff might do about requests for allocation for CGN use with or without this policy/ block. But, since people want to talk about it in those terms, I'd be interested in some real data and projections. In particular, how many large ISPs have expressed significant interest in this, where large is defined as big enough that an application for a /10 would be taken seriously. Now, if one /10 block is allocated to this use versus all of those ISPs applying for separate ones, how much does that change the likely date at which all of the currently-unallocated /8s are exhausted. If that difference is less than years, I, personally, don't think that particular argument is useful. Other arguments may be, but not that one. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Fri, Feb 10, 2012 at 11:15, John C Klensin john-i...@jck.com wrote: To follow up on an earlier comment, the rate at which ARIN (or other RIRs) are running out of /10s (or /8s) is probably irrelevant, as are hypotheses about what ARIN staff might do about requests for allocation for CGN use with or without this policy/ block. But, since people want to talk about it in those terms, I'd be interested in some real data and projections. In particular, how many large ISPs have expressed significant interest in this, where large is defined as big enough that an application for a /10 would be taken seriously. Now, if one /10 block is allocated to this use versus all of those ISPs applying for separate ones, how much does that change the likely date at which all of the currently-unallocated /8s are exhausted. This is not about IPv4 life-support. This is about providing the best answer to a difficult problem. Run-out date is not nearly as important as efficient use at this point. It is not efficient for multiple ISPs to use different space when a shared space will function optimally. If that difference is less than years, I, personally, don't think that particular argument is useful. Other arguments may be, but not that one. Please see https://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space for a more thorough analysis of the motivations, pros, cons, and alternatives for this shared CGN space. I think you'll find that those other arguments are laid out there. Cheers, ~Chris john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- @ChrisGrundemann http://chrisgrundemann.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Furthering discussions about BCP79 sanctions
There has been some discussion on this list about draft-farrresnickel-ipr-sanctions-00. Thanks for the input. The conversation seems to be partitioned into: - discussion of sanctions and how to apply them - discussion of measures that can be taken to help people to adhere to BCP79 - discussion about whether the IETF's IPR policy needs further work. I think it is important to have all three of these discussions, but in this thread I am focussing only on sanctions. Within the sanctions conversation I see three broad responses: 1. Sanctions must be applied very flexibly, taking into account all circumstances and without hard rules. 2. Sanctions must be algorithmically and repeatedly/predictably deduced from a full analysis of the situation. 3. Detailed rules are not needed, but there must be a clear line that defines bad breakage of BCP79 and a well-defined sanction to use in all such cases. Furthermore, there is some debate about who should/can be responsible for applying sanctions. The authors of the draft are of the opinion that in the case of work produced by a working group, the disruption caused by breaking BCP79 is directly to the smooth running of the WG. The Chair has the responsibility and the authority to make decisions, on behalf of the working group, regarding all matters of working group process and staffing, in conformance with the rules of the IETF. The AD has the authority and the responsibility to assist in making those decisions at the request of the Chair or when circumstances warrant such an intervention. The authors also believe that all attempts to codify programmatic mechanisms or red lines will always be subject to special cases, interpretation, and leniency. We would like to hear more from you about these points and about anything else you have found in the I-D. Thanks Adrian (and Pete) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
--On Friday, February 10, 2012 11:22 -0700 Chris Grundemann cgrundem...@gmail.com wrote: On Fri, Feb 10, 2012 at 11:15, John C Klensin john-i...@jck.com wrote: To follow up on an earlier comment, the rate at which ARIN (or other RIRs) are running out of /10s (or /8s) is probably irrelevant, as are hypotheses about what ARIN staff might do about requests for allocation for CGN use with or without this policy/ block. ... This is not about IPv4 life-support. This is about providing the best answer to a difficult problem. Run-out date is not nearly as important as efficient use at this point. It is not efficient for multiple ISPs to use different space when a shared space will function optimally. Indeed, although I note that it isn't a huge step from the above to get to we could really make _much_ more efficient use of IPv4 space by partitioning the Internet into regions and using explicit routing or X.75-like gateways to route traffic between regions, thereby permitting each region to use almost all of the IPv4 space. One could even use CGNs to establish that model with each ISP using almost the entire IPv4 space inside its castle walls.Now, I think either of those would be terrible ideas but, as you and others are probably aware, people who believe themselves to be serious and competent have proposed them, almost exactly Anything that moves us closer to those models gives me visions of slippery steep cliffs and the creeps, so I feel a need to be careful about efficiency arguments too. YMMD, either because you see the efficiency arguments differently, because you have reason to be less afraid of an ultimate islands connected by gateways outcome, or for other reasons. If that difference is less than years, I, personally, don't think that particular argument is useful. Other arguments may be, but not that one. Please see https://tools.ietf.org/html/draft-bdgks-arin-shared-transition -space for a more thorough analysis of the motivations, pros, cons, and alternatives for this shared CGN space. I think you'll find that those other arguments are laid out there. I have and I agree those arguments are there (their interaction with my fear of the scenarios above is another matter). Again, my main suggestion was that we just stop the discussions based on allocation strategies or IPv4 exhaustion alone... because they are distractions rather than helpful. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 02/10/2012 07:47, Chris Donley wrote: Please remember that this draft is in support of ARIN Draft Policy 2011-5. Partially, sure. But RFCs apply to the whole Internet. IMO, an IETF RFC is not the correct place to tell ARIN or other RIRs how to allocate space; I'm not going to parse the nuances of what you wrote, but I think generally you're wrong. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Nomcom 2011-2012: Selection Summary and I* Composition
Hi all, Several people had asked for a summary of the Nomcom selections, and the composition of the I* bodies after the selected persons assume office. Here they are. IESG Selection Summary and Composition === The Nomcom selected the following persons to serve as Area Directors in the open IESG positions: APP: Barry Leiba INT: Brian Haberman OPS: Benoit Claise RAI: Gonzalo Camarillo RTG: Stewart Bryant SEC: Sean Turner TSV: Martin Stiemerling The complete composition of the IESG after these persons assume their duties will be: APP: Pete Resnick, Barry Leiba GEN: Russ Housley INT: Ralph Droms, Brian Haberman OPS: Ronald Bonica, Benoit Claise RAI: Robert Sparks, Gonzalo Camarillo RTG: Adrian Farrel, Stewart Bryant SEC: Stephen Farrell, Sean Turner TSV: Wesley Eddy, Martin Stiemerling Liaison and Ex-officio Members: Bernard Aboba - IAB Chair Joel Halpern - IAB Liaison Alexa Morris - IETF Executive Director Michelle Cotton - IANA Liaison Sandy Ginoza - RFC Editor Liaison IAB Selection Summary and Composition == The Nomcom selected the following persons to serve in the open IAB positions: Bernard Aboba Jari Arkko Marc Blanchet Ross Callon Spencer Dawkins Hannes Tschofenig The complete composition of the IAB after these persons assume their duties will be: Bernard Aboba Jari Arkko Marc Blanchet Ross Callon Alissa Cooper Spencer Dawkins Joel Halpern Russ Housley David Kessens Danny McPherson Jon Peterson Dave Thaler Hannes Tschofenig Liaison and Ex-officio Members: Mary Barnes - IAB Executive Director Lars Eggert - IRTF Chair Sean Turner - Liaison from the IESG Heather Flanagan - Liaison from the RFC Editor, RSE Mat Ford - Liaison from ISOC IAB Executive Assistant: Cindy Morgan IAOC Selection Summary and Composition === The Nomcom selected Marshall Eubanks to serve in the open IAOC position. The complete composition of the IAOC after he assumes his duties will be: Bernard Aboba - IAB Chair (ex officio) Eric Burger - appointed by the ISOC Board of Trustees Dave Crocker - appointed by Nomcom Marshall Eubanks - appointed by Nomcom Bob Hinden (IAOC Chair) - appointed by the IAB Russ Housley - IETF Chair (ex officio) Ole Jacobsen - appointed by the IESG Ray Pelletier - IETF Administrative Director (non-voting) Lynn St.Amour - ISOC President/CEO (ex officio) Suresh Krishnan Chair, NomCom 2011-2012 nomcom-ch...@ietf.org suresh.krish...@ericsson.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 02/10/2012 10:22, Chris Grundemann wrote: This is not about IPv4 life-support. Seriously? This is about providing the best answer to a difficult problem. The best answer is to make sure that CPEs that will be doing CGN can handle the same 1918 space inside the user network and at the CGN layer. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 2012-02-11 11:09, Doug Barton wrote: On 02/10/2012 07:47, Chris Donley wrote: Please remember that this draft is in support of ARIN Draft Policy 2011-5. Partially, sure. But RFCs apply to the whole Internet. Hear hear. IMO, an IETF RFC is not the correct place to tell ARIN or other RIRs how to allocate space; I'm not going to parse the nuances of what you wrote, but I think generally you're wrong. The RIRs get their space from IANA@ICANN, so s/ARIN/ICANN/ and read clause 4.3 of RFC 2860 carefully. The IAB decided that the current issue *is* the IETF's business under that clause. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 2/9/12 10:47 PM, Doug Barton wrote: As I (and many others) remain opposed to this entire concept I think it's incredibly unfortunate that the IESG has decided to shift the topic of conversation from whether this should happen to how it should happen. As an AD who is now comfortable with going forward with the document, I do want to point out that the IESG as a whole has *not* come to consensus on this document. There are still not the required number of Yes or No objection ballots for the document to move forward. So I don't think it's accurate to say that the IESG is only deciding how it should happen. Shared Address Space is IPv4 address space designated for Service Provider use with the purpose of facilitating CGN deployment. Also, Shared Address Space can be used as additional [RFC1918] space I think it's a feature that we're finally willing to admit that this new block is going to be used as 1918 space. I expect there will be clarifications as per the earlier messages in this thread: This is *not* to be used as additional 1918 space. (See my message of 2/1/12 4:33 PM -0600. ) 1918 space is guaranteed to be private, and devices have been built that have made the assumption that the space is private and they will not see it on a network that is not within its administrative control. This proposed space is most assuredly not that. It's shared and therefore has additional constraints on use that 1918 space does not. It is certainly *similar* to 1918 space in that it is not globally routeable, but it is not 1918 space. Given that previous requests for new 1918 space have been (rightly) denied, I think this document should describe why this request is better/more important than previous requests, and what the bar will be for future requests for new 1918 space. I hope it does, and if it is not sufficient, I expect text will be accepted by the authors. In particular, the text suggested in the aforementioned message was: Shared Address Space is similar to [RFC1918] private address space in that it is not global routeable address space and can be used by multiple pieces of equipment. However, Shared Address Space has limitations in its use that the current [RFC1918] private address space does not have. In particular, Shared Address Space can only be used on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces. When I previously proposed this as *the* proper solution I was told that it wasn't in any way practical. Now that we're apparently willing to discuss it as *a* possible solution one wonders why a new block is necessary at all. See above paragraph. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 02/10/2012 15:42, Pete Resnick wrote: On 2/9/12 10:47 PM, Doug Barton wrote: As I (and many others) remain opposed to this entire concept I think it's incredibly unfortunate that the IESG has decided to shift the topic of conversation from whether this should happen to how it should happen. As an AD who is now comfortable with going forward with the document, I do want to point out that the IESG as a whole has *not* come to consensus on this document. There are still not the required number of Yes or No objection ballots for the document to move forward. So I don't think it's accurate to say that the IESG is only deciding how it should happen. I suppose that's some small comfort. Shared Address Space is IPv4 address space designated for Service Provider use with the purpose of facilitating CGN deployment. Also, Shared Address Space can be used as additional [RFC1918] space I think it's a feature that we're finally willing to admit that this new block is going to be used as 1918 space. I expect there will be clarifications as per the earlier messages in this thread: This is *not* to be used as additional 1918 space. The following is not meant to be a snark (nor is anything else I've written on this topic, for that matter), but I think it's a huge problem that you think *saying* Don't use this as 1918 space is going to make any difference at all. Given that previous requests for new 1918 space have been (rightly) denied, I think this document should describe why this request is better/more important than previous requests, and what the bar will be for future requests for new 1918 space. I hope it does, For my money, it does not. and if it is not sufficient, I expect text will be accepted by the authors. In particular, the text suggested in the aforementioned message was: Shared Address Space is similar to [RFC1918] private address space in that it is not global routeable address space and can be used by multiple pieces of equipment. However, Shared Address Space has limitations in its use that the current [RFC1918] private address space does not have. In particular, Shared Address Space can only be used on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces. When I previously proposed this as *the* proper solution I was told that it wasn't in any way practical. Now that we're apparently willing to discuss it as *a* possible solution one wonders why a new block is necessary at all. See above paragraph. So if we're saying the same thing about CPEs capable of doing CGN needing to understand the same block(s) on the inside and outside, why is the new block necessary? Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Fri, Feb 10, 2012 at 15:13, Doug Barton do...@dougbarton.us wrote: On 02/10/2012 10:22, Chris Grundemann wrote: This is not about IPv4 life-support. Seriously? Seriously. The birth of a shared CGN space in no significant way extends the life of IPv4. It does provide the best possible solution to a necessary evil (CGN inside addresses). This is about providing the best answer to a difficult problem. The best answer is to make sure that CPEs that will be doing CGN can handle the same 1918 space inside the user network and at the CGN layer. Are you volunteering to buy everyone on earth a new CPE? If not, who do you suggest will? My bet is that no one is willing to drop the billions of dollars required - if they were, we could just sign everyone up for IPv6 capable CPE and skip the whole debate... ;) Cheers, ~Chris Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ -- @ChrisGrundemann http://chrisgrundemann.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 02/10/2012 16:12, Chris Grundemann wrote: On Fri, Feb 10, 2012 at 15:13, Doug Barton do...@dougbarton.us wrote: On 02/10/2012 10:22, Chris Grundemann wrote: This is not about IPv4 life-support. Seriously? Seriously. The birth of a shared CGN space in no significant way extends the life of IPv4. It does provide the best possible solution to a necessary evil (CGN inside addresses). Ok, now THIS is a snark: Dude, don't bogart the good stuff, pass it around man. /snark We were specifically asked not to reopen the debate on the necessity of CGN to start with, so I won't go there feel free to dig through the archives on all the reasons why this evil isn't actually necessary. This is about providing the best answer to a difficult problem. The best answer is to make sure that CPEs that will be doing CGN can handle the same 1918 space inside the user network and at the CGN layer. Are you volunteering to buy everyone on earth a new CPE? If not, who do you suggest will? My bet is that no one is willing to drop the billions of dollars required - if they were, we could just sign everyone up for IPv6 capable CPE and skip the whole debate... ;) Everyone doesn't need a new one. In fact, the only end users who need new ones are those behind ISPs that chose to ignore IPv6, need to deploy CGN, and can't actually get CGN done with existing 1918 space. I strongly suspect that the latter number will be very small, and what this allocation request is really about is to make lives easier (read, cheaper) for those that didn't want to invest in IPv6, and now don't want to have to think hard about how they do their network design. It's also in no way clear to me how many extant CPEs would break if CGN were deployed with 1918, and/or how many of the extant CPEs will have to be replaced anyway to do CGN in the first place. Repeated requests for hard data on this (by me and others) have gone unanswered, I suspect because collecting such data would also be expensive. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Fri, Feb 10, 2012 at 05:12:31PM -0700, Chris Grundemann wrote: On Fri, Feb 10, 2012 at 15:13, Doug Barton do...@dougbarton.us wrote: On 02/10/2012 10:22, Chris Grundemann wrote: This is not about IPv4 life-support. Seriously? Seriously. The birth of a shared CGN space in no significant way extends the life of IPv4. It does provide the best possible solution to a necessary evil (CGN inside addresses). We do not need another reason for people to delay v6 deployment. Just saying this isn't about sticking your head in the sand does not make it any more so. This _will_be_used_ as an excuse for not rolling out v6. This is about providing the best answer to a difficult problem. The best answer is to make sure that CPEs that will be doing CGN can handle the same 1918 space inside the user network and at the CGN layer. Are you volunteering to buy everyone on earth a new CPE? If not, who do you suggest will? My bet is that no one is willing to drop the billions of dollars required - if they were, we could just sign everyone up for IPv6 capable CPE and skip the whole debate... ;) There are more than 1 prefix in RFC1918. Tell the customers to use another one than the one you inflict on them as bad excuse for not doing v6 quick enough. That there will be increased support load on any provider not giving customers public space is a suitable punishment for above mentioned failure to deliver v6. I still strongly oppose the publication of this draft. In any form except a complete rewrite telling providers to use RFC1918 and be done with it. -- Måns, sadly enough not surprised by the fact that this bad idea still isn't properly killed. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Pete Resnick wrote: and can be used by other people who build sane equipment that understands shared addresses can appear on two different interfaces. With so complicated functionality of NAT today, the only practical approach to build such equipment is to make it a double NAT as: +-+ +-+ (a private space)-| NAT |---| NAT |-(same private space) +-+ +-+ the only problem is that we need another private address space used only between element NATs within the double NAT. Can IETF allocate such address? Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Feb 10, 2012 4:25 PM, Måns Nilsson mansa...@besserwisser.org wrote: On Fri, Feb 10, 2012 at 05:12:31PM -0700, Chris Grundemann wrote: On Fri, Feb 10, 2012 at 15:13, Doug Barton do...@dougbarton.us wrote: On 02/10/2012 10:22, Chris Grundemann wrote: This is not about IPv4 life-support. Seriously? Seriously. The birth of a shared CGN space in no significant way extends the life of IPv4. It does provide the best possible solution to a necessary evil (CGN inside addresses). We do not need another reason for people to delay v6 deployment. Just saying this isn't about sticking your head in the sand does not make it any more so. This _will_be_used_ as an excuse for not rolling out v6. +1. This is all business. Companies have made their choices. This is about providing the best answer to a difficult problem. The best answer is to make sure that CPEs that will be doing CGN can handle the same 1918 space inside the user network and at the CGN layer. Are you volunteering to buy everyone on earth a new CPE? If not, who do you suggest will? My bet is that no one is willing to drop the billions of dollars required - if they were, we could just sign everyone up for IPv6 capable CPE and skip the whole debate... ;) There are more than 1 prefix in RFC1918. Tell the customers to use another one than the one you inflict on them as bad excuse for not doing v6 quick enough. That there will be increased support load on any provider not giving customers public space is a suitable punishment for above mentioned failure to deliver v6. I still strongly oppose the publication of this draft. In any form except a complete rewrite telling providers to use RFC1918 and be done with it. This is the logical path for the cgn minded. They need to deal with the challenge of renumbering users. I also oppose this draft. Cb -- Måns, sadly enough not surprised by the fact that this bad idea still isn't properly killed. ___ 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: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
From: =?iso-8859-1?Q?M=E5ns?= Nilsson mansa...@besserwisser.org We do not need another reason for people to delay v6 deployment. The last time this issue (CGNAT space) was discussed, we were asked not to open this can of worms. I don't know if that request still holds, but seriously, nothing good can come of a discussion on this topic. It will just be a lot of rhetoric, and _zero_ minds will be changed. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 2/10/12 3:57 PM, Doug Barton wrote: On 02/10/2012 15:42, Pete Resnick wrote: I expect there will be clarifications as per the earlier messages in this thread: This is *not* to be used as additional 1918 space. The following is not meant to be a snark Not taken as such. ...I think it's a huge problem that you think *saying* Don't use this as 1918 space is going to make any difference at all. Neither the text of the current draft nor the proposed text that Brian and I seem to like says Don't use this as 1918 space, nor do I think saying so would be a good idea or make any difference. I apologize that I was not clear when I said that it is *not* to be used as 1918 space. What I meant was that the document should be clear that this so-called Shared Address Space has limitations and can't be used in circumstances where 1918 addresses can be used. Now, I am under no delusions that some equipment won't *try* to use this new space in ways that will cause problems (any more than I think that people won't use port numbers for non-registered uses, or won't use bogus SMTP protocol return codes, etc.). But like those situations, folks who want to use this new address space *don't care* if other people do stupid things with it; they're making their own beds and they can lie in them. Remember, the whole purpose of using new address space is that the 1918 space has specific semantics that folks have already implemented and deployed in equipment *in compliance with the spec* in that they don't NAT what they consider an outside address. If people with current equipment call and complain when a CGN uses 1918 space and screws up their equipment, they've got a legitimate beef. But if new folks start using Shared Address Space without NATing it properly, they've only got themselves to blame. The new and suggested text makes this all clear: You can safely use this non-globally-routeable Shared Address Space so long as you NAT it on both ends. If you don't, you're going to have routing problems. You want routing problems? Have at it. I don't care. Like any good IETF spec, we're just telling you what the rest of us intend to do. If the text is not clear, please help. Given that previous requests for new 1918 space have been (rightly) denied, I think this document should describe why this request is better/more important than previous requests, and what the bar will be for future requests for new 1918 space. I hope it does, For my money, it does not. Again, text welcome. Shared Address Space is similar to [RFC1918] private address space in that it is not global routeable address space and can be used by multiple pieces of equipment. However, Shared Address Space has limitations in its use that the current [RFC1918] private address space does not have. In particular, Shared Address Space can only be used on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces. So if we're saying the same thing about CPEs capable of doing CGN needing to understand the same block(s) on the inside and outside, why is the new block necessary? I believe this has been said multiple times before (and is not the subject of this Last Call, AFAICT), but: The new block is necessary because current equipment, which will be connected to CGNs (or any other kinds of devices that use this new space), and which conforms to a reasonable interpretation of 1918, is not able to understand the same block on the inside and the outside, and therefore will not be able to route through CGNs (or other such new equipment) if they used 1918 space. Again, if the current text is not clear on this point, please identify where clarification is needed. (If you disagree with my assessment, let's please take that conversation offlist and we can figure out where the disagreement is and maybe bring our collective wisdom back to the list. And that invitation is to anyone who feels that they disagree with the above reasoning. You have my email address.) pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 2/10/12 6:38 PM, Masataka Ohta wrote: Pete Resnick wrote: and can be used by other people who build sane equipment that understands shared addresses can appear on two different interfaces. With so complicated functionality of NAT today, the only practical approach to build such equipment is to make it a double NAT Correct. That's what a CGN is, and that is what other equipment of this sort would be. as: +-+ +-+ (a private space)-| NAT |---| NAT |-(same private space) +-+ +-+ the only problem is that we need another private address space used only between element NATs within the double NAT. Can IETF allocate such address? That's what this document is doing: Allocating address space to go between 2 NATs. Maybe I don't understand your question? pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Thanks for your response, mine is below, with snipping. On 02/10/2012 19:19, Pete Resnick wrote: On 2/10/12 3:57 PM, Doug Barton wrote: On 02/10/2012 15:42, Pete Resnick wrote: I expect there will be clarifications as per the earlier messages in this thread: This is *not* to be used as additional 1918 space. The following is not meant to be a snark Not taken as such. ...I think it's a huge problem that you think *saying* Don't use this as 1918 space is going to make any difference at all. Neither the text of the current draft nor the proposed text that Brian and I seem to like says Don't use this as 1918 space, nor do I think saying so would be a good idea or make any difference. I apologize that I was not clear when I said that it is *not* to be used as 1918 space. What I meant was that the document should be clear that this so-called Shared Address Space has limitations and can't be used in circumstances where 1918 addresses can be used. I'm sorry, I was trying to be concise in order to not re-open the debate on the topic of should, but your response indicates that you're not seeing my point. The premise of this draft is that a new block is necessary because the same prefixes can't be used in the customer network and the CGN layer. So, let's allocate a new block to use *only* in the CGN layer. That way it can never conflict. My point is that no matter how loudly you say, Don't use this as 1918 space! some users will do it anyway. There have already been several requests for more IPv4 1918 space because a non-zero number of end user networks have run out. So we know that people *will* use this new block internally. Therefore we can be fairly certain that at some point there will be a conflict. That means that there is no reason to allocate this new block. But if new folks start using Shared Address Space without NATing it properly, they've only got themselves to blame. That's interesting ... so you're saying that the people who created the problem should be responsible for dealing with their own mess? :) More seriously, you seem to be saying that because the draft says Don't do it it's Ok for us to do the allocation because if someone does screw up it's not our fault because we told them not to do it. My point is that because we can see the trap, we shouldn't walk right into it with a smile on our face. If the text is not clear, please help. I don't think any amount of text-twiddling can help, since I feel that this is a bad idea from the ground up. I believe this has been said multiple times before (and is not the subject of this Last Call, AFAICT), but: The new block is necessary because current equipment, which will be connected to CGNs (or any other kinds of devices that use this new space), and which conforms to a reasonable interpretation of 1918, is not able to understand the same block on the inside and the outside, and therefore will not be able to route through CGNs (or other such new equipment) if they used 1918 space. Yes, that's been *said* multiple times, but it hasn't been backed up with solid data. OTOH, numerous people (many of whom are in a much better position to know than I am) have pointed out that the overwhelming majority of consumer CPE devices use one of 192.168.[01] as their internal networks. That number is likely to be in the 80% range, if not much higher. Therefore it's very likely that most of this problem is solved already if the ISPs simply stay away from those 2 ranges. What I, and others, have said repeatedly now is that given how easy most of this problem is to solve, the people who have a fiduciary interest in solving the rest of it should do so, without asking the rest of the Internet to subsidize their (arguably flawed) business model. Or put more simply, if the problem is that CPEs don't know how to deal with the same block on the inside and outside, there are (at least) 2 ways for the ISPs to solve that which do not involve allocating a new block. Again, if the current text is not clear on this point, please identify where clarification is needed. (If you disagree with my assessment, let's please take that conversation offlist and we can figure out where the disagreement is and maybe bring our collective wisdom back to the list. I appreciate the invitation, but I don't know how much more I can bring to the topic that I haven't already. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
From: Doug Barton do...@dougbarton.us My point is that no matter how loudly you say, Don't use this as 1918 space! some users will do it anyway. And if they do, any problem that results is _their_ problem. That means that there is no reason to allocate this new block. No. If people are using thing X in way A, _which is allowed by the definition of X_, then it's really rude/unfair for a responsible standards body to turn around and say 'ooops, now you can't use thing X in way A'. If, on the other hand, the standards body then says 'here's a new thing Y; don't use thing Y in way A', and people go ahead and use thing Y in way A, then the standards body can reasonably sit back and laugh at them and blow a raspberry at them when they complain. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 02/10/2012 20:04, Noel Chiappa wrote: From: Doug Barton do...@dougbarton.us My point is that no matter how loudly you say, Don't use this as 1918 space! some users will do it anyway. And if they do, any problem that results is _their_ problem. You snipped the bit of the my post that you're responding to where I specifically disallowed this as a reasonable argument. That means that there is no reason to allocate this new block. No. Let me boil it down even more for you. The new block's purpose is to make collisions impossible. It cannot fulfill that purpose. So it shouldn't be allocated. If people are using thing X in way A, _which is allowed by the definition of X_, then it's really rude/unfair for a responsible standards body to turn around and say 'ooops, now you can't use thing X in way A'. If, on the other hand, the standards body then says 'here's a new thing Y; don't use thing Y in way A', and people go ahead and use thing Y in way A, then the standards body can reasonably sit back and laugh at them and blow a raspberry at them when they complain. Setting aside the fact that what you're suggesting is a silly and childish way for any human to act (even taking hyperbole into account), it's a very irresponsible way for an SDO to conduct themselves. And that's assuming that this action doesn't have a cost, whereas the truth is that it has several, both direct and indirect. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
From: Doug Barton do...@dougbarton.us
You snipped the bit of the my post that you're responding to where I
specifically disallowed this as a reasonable argument.
What an easy way to win a debate: 'I hereby disallow the following
counter-arguments {A, B, C}, and since you have no other
counter-arguments, I win.'
Just because you don't think much of it, doesn't mean the rest of us have
to agree with you on that.
The new block's purpose is to make collisions impossible.
Ah, no.
If you were to say 'to make collisions very unlikely if it is used in the
way it is specified', then I could agree with that. But to take a
straw-man absolutist position like impossible, and then knock it down
with great pomp:
It cannot fulfill that purpose.
is not exactly a plausible argument. Outlawing cell-phone use while driving
may make accidents caused by cell-phone usage less likely, but it can't make
them impossible. Only physics (and math) make things _absolutely_ impossible
it's a very irresponsible way for an SDO to conduct themselves.
What, to say 'if you use this in a way that we specifically direct it not
be used, any problems are your fault'?
That's odd, because my lawnmower says much the same thing: 'Don't use this
as a hedge-trimmer. If you do, and cut off your arm, don't even bother
thinking of suing us, because we warned you not to.' (OK, so I translated
the legalese into something more amusing, but the basic message is exactly
that.)
And that's assuming that this action doesn't have a cost, whereas
the truth is that it has several, both direct and indirect.
And that would be...? How exactly does simply allocating a chunk of
address space - something the Internet engineering community does every
day - for a specific purpose have a cost ... both direct and indirect?
If you're actually thinking of 'deploying CGNAT' in the text above, this
discussion is not about that. That's going to happen no matter what the
IETF says/does. (Just like all those other NAT boxes the IETF huffed and
puffed until it turned blue in the face about.)
This is only about allocating a chunk of address space.
Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On 02/10/2012 20:44, Noel Chiappa wrote:
From: Doug Barton do...@dougbarton.us
You snipped the bit of the my post that you're responding to where I
specifically disallowed this as a reasonable argument.
What an easy way to win a debate: 'I hereby disallow the following
counter-arguments {A, B, C}, and since you have no other
counter-arguments, I win.'
Just because you don't think much of it, doesn't mean the rest of us have
to agree with you on that.
I understand that. Do you understand that I understand what you're
saying, and I don't agree with you?
The new block's purpose is to make collisions impossible.
Ah, no.
If you were to say 'to make collisions very unlikely if it is used in the
way it is specified', then I could agree with that.
Ok, let's go with that. We already have a way to make collisions very
unlikely, don't use either of 192.168.[01]. Fortunately this method
doesn't require allocation of a new block.
So now what we're talking about is how much we're willing to pay to make
the collisions how much more unlikely?
But to take a
straw-man absolutist position like impossible, and then knock it down
with great pomp:
It cannot fulfill that purpose.
I was using shorthand (or argumentum ad absurdum if you prefer) to point
out that given the fact that this new block can't fix the whole problem,
and also given the fact that there are already solutions available that
fix most of the problem for free, allocating the new block is a bad idea.
it's a very irresponsible way for an SDO to conduct themselves.
What, to say 'if you use this in a way that we specifically direct it not
be used, any problems are your fault'?
Again, you snipped the bit where I answered this. Go back and re-read my
previous post if you're confused.
And that's assuming that this action doesn't have a cost, whereas
the truth is that it has several, both direct and indirect.
And that would be...? How exactly does simply allocating a chunk of
address space - something the Internet engineering community does every
day - for a specific purpose have a cost ... both direct and indirect?
Again, I'm really trying not to dive back into the should we question,
but just as an example, there are 4,096 /22s in a /10. That's 4k new
SMBs that cannot get IPv4 space if this block is allocated.
If you want more, go look at the archives.
If you're actually thinking of 'deploying CGNAT' in the text above, this
discussion is not about that. That's going to happen no matter what the
IETF says/does.
Yep, I get that.
(Just like all those other NAT boxes the IETF huffed and
puffed until it turned blue in the face about.)
FWIW I always said that the IETF sticking its collective fingers in its
ears and singing la la la la la instead of acknowledging the reality
of NAT and trying to figure out how to do it right was a big mistake.
This is only about allocating a chunk of address space.
I wish that were true. :)
Doug
--
It's always a long day; 86400 doesn't fit into a short.
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Pete Resnick wrote: and can be used by other people who build sane equipment that understands shared addresses can appear on two different interfaces. With so complicated functionality of NAT today, the only practical approach to build such equipment is to make it a double NAT Correct. Note that the double NAT, here, is AN equipment. Can IETF allocate such address? That's what this document is doing: Allocating address space to go between 2 NATs. Maybe I don't understand your question? My point is that those who are arguing against the proposed allocation because of the capability of a double NAT equipment should argue for allocation of another space to enable development of the double NAT equipment. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Protocol Action: 'RADIUS Support for Proxy Mobile IPv6' to Proposed Standard (draft-ietf-netext-radius-pmip6-08.txt)
The IESG has approved the following document: - 'RADIUS Support for Proxy Mobile IPv6' (draft-ietf-netext-radius-pmip6-08.txt) as a Proposed Standard This document is the product of the Network-Based Mobility Extensions Working Group. The IESG contact persons are Jari Arkko and Ralph Droms. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-netext-radius-pmip6/ Technical Summary This document defines new attributes to facilitate Proxy Mobile IPv6 operations using the RADIUS infrastructure. The protocol specified here uses RADIUS based interfaces of the mobile access gateway and the local mobility anchor with the AAA server for authentication, authorization and policy functions. The RADIUS interactions between the mobile access gateway and the RADIUS-based AAA server take place when the Mobile Node attaches to the network, authenticates and authorizes within a Proxy Mobile IPv6 domain. Furthermore, this document defines the RADIUS-based interface between the local mobility anchor and the AAA RADIUS server for authorizing received Proxy Binding Update messages for the mobile node's mobility session. Additionally, this document specifies the baseline for the mobile access gateway and the local mobility anchor generated accounting. Working group summary: The document has been reviewed by several RADIUS protocol experts as well as key members within the working group. It has undergone two working group last calls and has been revised based on feedback from reviewers as well as implementation experience. There is strong WG consensus behind this document. Document quality: There is at least one known implementation of the protocol. Multiple vendors have indicated plans to implement this specification. All the key people who have reviewed this I-D are acknowledged in the document. Personnel The Document Shepherd is Basavaraj Patil, and the responsible Area Director is Jari Arkko. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Nomcom 2011-2012: Selection Summary and I* Composition
Hi all, Several people had asked for a summary of the Nomcom selections, and the composition of the I* bodies after the selected persons assume office. Here they are. IESG Selection Summary and Composition === The Nomcom selected the following persons to serve as Area Directors in the open IESG positions: APP: Barry Leiba INT: Brian Haberman OPS: Benoit Claise RAI: Gonzalo Camarillo RTG: Stewart Bryant SEC: Sean Turner TSV: Martin Stiemerling The complete composition of the IESG after these persons assume their duties will be: APP: Pete Resnick, Barry Leiba GEN: Russ Housley INT: Ralph Droms, Brian Haberman OPS: Ronald Bonica, Benoit Claise RAI: Robert Sparks, Gonzalo Camarillo RTG: Adrian Farrel, Stewart Bryant SEC: Stephen Farrell, Sean Turner TSV: Wesley Eddy, Martin Stiemerling Liaison and Ex-officio Members: Bernard Aboba - IAB Chair Joel Halpern - IAB Liaison Alexa Morris - IETF Executive Director Michelle Cotton - IANA Liaison Sandy Ginoza - RFC Editor Liaison IAB Selection Summary and Composition == The Nomcom selected the following persons to serve in the open IAB positions: Bernard Aboba Jari Arkko Marc Blanchet Ross Callon Spencer Dawkins Hannes Tschofenig The complete composition of the IAB after these persons assume their duties will be: Bernard Aboba Jari Arkko Marc Blanchet Ross Callon Alissa Cooper Spencer Dawkins Joel Halpern Russ Housley David Kessens Danny McPherson Jon Peterson Dave Thaler Hannes Tschofenig Liaison and Ex-officio Members: Mary Barnes - IAB Executive Director Lars Eggert - IRTF Chair Sean Turner - Liaison from the IESG Heather Flanagan - Liaison from the RFC Editor, RSE Mat Ford - Liaison from ISOC IAB Executive Assistant: Cindy Morgan IAOC Selection Summary and Composition === The Nomcom selected Marshall Eubanks to serve in the open IAOC position. The complete composition of the IAOC after he assumes his duties will be: Bernard Aboba - IAB Chair (ex officio) Eric Burger - appointed by the ISOC Board of Trustees Dave Crocker - appointed by Nomcom Marshall Eubanks - appointed by Nomcom Bob Hinden (IAOC Chair) - appointed by the IAB Russ Housley - IETF Chair (ex officio) Ole Jacobsen - appointed by the IESG Ray Pelletier - IETF Administrative Director (non-voting) Lynn St.Amour - ISOC President/CEO (ex officio) Suresh Krishnan Chair, NomCom 2011-2012 nomcom-ch...@ietf.org suresh.krish...@ericsson.com ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-rmt-flute-revised-13.txt (FLUTE - File Delivery over Unidirectional Transport) to Proposed Standard
The IESG has received a request from the Reliable Multicast Transport WG (rmt) to consider the following document: - 'FLUTE - File Delivery over Unidirectional Transport' draft-ietf-rmt-flute-revised-13.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 2012-02-24. 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. Abstract This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. This document obsoletes RFC3926. This document contains downrefs: It creates a registry that includes values for content encoding algorithms defined in Informational RFCs 1950, 1951, and 1952. It discusses a potential weakness created by using WEBRC congestion control, a mandatory to implement algorithm for ALC. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-rmt-flute-revised/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-rmt-flute-revised/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/733/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
IAB solicits candidates for the Internet Society Board of Trustees
The Internet Society (ISOC) provides organizational and financial support for the IETF. As part of the arrangements between ISOC and the IETF, the IETF is called upon to name 3 Trustees to its Board (BoT), with staggered 3 year terms. This requires that the IETF select one Trustee each year. This year, the IAB will select one person for a term ending in mid 2015. A description of the IAB's process for selecting the Trustee each year can be found in RFC 3677, with this year's timeline as follows: * Feb 10, 2012 : Open nomination period * March 9, 2012 : Close of the nomination period * No later than April 14, 2012 : IAB selection delivered to IESG for confirmation * No later than May 25, 2012 : Delivery of final confirmed selection to the ISOC Elections Committee for announcement with the rest of the new ISOC BoT slate. Nominations --- Nominations (including self-nominations) should be sent to the IAB chair-- iab-ch...@iab.org. Please include e-mail contact details with the nomination. Nomination Details - Nominees should be aware that ISOC Trustees are elected to three year terms with approximately one third of the Board of Trustees elected each year. The responsibilities of a Trustee include fiscal management of the Internet Society, fundraising, and participation in 3 physical Board meetings plus 3 conference-call meetings per year. The desirable characteristics of a candidate that are specific to the IETF-selected ISOC BoT member are outlined in section 2 of RFC 3677. Nominees will be asked to provide to the IAB: 1. Confirmation of their willingness to be considered within this process. 2. Full name and contact information. 3. A statement confirming willingness and ability to devote an appropriate level of time to activities associated with the position of Trustee. 4. A brief biography outlining experience and background. 5. A statement of interests, concerns about the Internet Society, goals as a Trustee and motivation to serve as a Trustee. 6. Any further information that is relevant to the work of the IAB in considering your nomination. Time Commitment --- Trustees are expected to commit the time necessary to perform regular board and committee business. Trustees are also expected to allocate some time to attend and prepare for meetings. The ISOC Board of Trustees holds three physical meetings and two 2-hour teleconference meetings annually. Care of Personal Information The following procedures will be used by the IAB in managing this process: - The candidate's name will be published, with all other candidate names, at the close of the nominations period - Excerpts of the information provided to the IAB by the nominated candidate will be passed to the IESG as part of the confirmation process. The IESG will be requested to maintain confidentiality of the candidate's information - Except as noted above, all information provided to the IAB during this process will be kept confidential to the IAB. Current IETF-Selected Trustees --- The current IETF-Selected ISOC Trustees and their term of appointment are: - Eric Burger 2009 - 2012 - Bob Hinden2010 - 2013 - Bert Wijnen2011 - 2014 -- Bernard Aboba IAB Chair. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
