Re: [IETF] IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
On Jun 19, 2013, at 8:43 PM, John C Klensin john-i...@jck.com wrote: ... The point, Warren (and others) is that all of these are ICANN doing technical stuff and even technical standards in a broad sense of that term. Some of it is stuff that the IETF really should not want to do (I'm tempted to say avoid like the plague). Some of it probably should be here. As an outsider to both, there is a certain amount of stuff that has ended up in SSAC and even RSAC that might have been better located in SAAG or some IETF or NOG DNS operations group. I certainly won't argue that we've got the balance right. And I think it is unfortunate that the very early redesign of the original PSO had the side effect of making it hard or impossible to work out optimal boundaries and cross-review mechanisms with ICANN and that we are instead having a discussion more than a dozen years later about keeping ICANN from doing technical work or making standards. +1 (specifically - it is unfortunate that a more operational ICANN / IETF liaison did not emerge via the PSO structure) Let's not complicate things further by making the assumption that anything that reasonably looks like technical stuff belongs in the IETF and not in ICANN. It is likely to just make having the right conversations even harder. I believe that policy issues that are under active discussion in ICANN can also be discussed in the IETF, but there is recognition that ICANN is likely the more appropriate place to lead the process of consensus development and approval. I believe that protocol development that is under active discussion at the IETF can also discussed at ICANN, but there is recognition that the IETF is likely the appropriate place to lead the process of consensus development and approval. Note that there are lots of things that are neither policy nor protocols (e.g. operational best practices and guidelines) and while one can claim that either forum is valid, it really depends on the particular situation and where those folks who are closest to the problem actually choose to go with it (and depending on the protocol, that might not be either of the above...) /John Disclaimer: My views alone - YMMV.
Re: [IETF] IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
On 6/21/13 10:46 , John Curran wrote: I believe that policy issues that are under active discussion in ICANN can also be discussed in the IETF, but there is recognition that ICANN is likely the more appropriate place to lead the process of consensus development and approval. I believe that protocol development that is under active discussion at the IETF can also discussed at ICANN, but there is recognition that the IETF is likely the appropriate place to lead the process of consensus development and approval. Note that there are lots of things that are neither policy nor protocols (e.g. operational best practices and guidelines) and while one can claim that either forum is valid, it really depends on the particular situation and where those folks who are closest to the problem actually choose to go with it (and depending on the protocol, that might not be either of the above...) /John Disclaimer: My views alone - YMMV. A version of these three paragraphs would make an excellent executive summary for the 2050bis Draft itself. -- David Farmer Email: far...@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952
Re: [IETF] IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
--On Friday, June 21, 2013 11:46 -0400 John Curran jcur...@istaff.org wrote: ... Let's not complicate things further by making the assumption that anything that reasonably looks like technical stuff belongs in the IETF and not in ICANN. It is likely to just make having the right conversations even harder. I believe that policy issues that are under active discussion in ICANN can also be discussed in the IETF, but there is recognition that ICANN is likely the more appropriate place to lead the process of consensus development and approval. I believe that protocol development that is under active discussion at the IETF can also discussed at ICANN, but there is recognition that the IETF is likely the appropriate place to lead the process of consensus development and approval. ... John, While I agree with the above (and am still trying to avoid carrying this conversation very far on the IETF list), I think another part of the puzzle is that there are also situations in which technical considerations imply real constraints on policy alternatives. Some obvious examples include physical constants like the speed of light, others, only slightly less obvious, include things like the design of the DNS as a simply hierarchy that cannot support symmetric aliases (i.e., anything that would support an actual came from function or a list of all of the names that point to a given note). The policy folks ignore those constraints, or treat them as subject to policy-making decisions at the risk of being ridiculous and/or causing considerable harm to the Internet. While they are less obvious in this community, I suggest it works the other way too -- there are policy and economic decisions and realities that are as much constraints on the technical solution space as those technical constrains are on the policy ones, with just about the same risks of ridiculousness or damage if they are ignored. That is, again, why it is so unfortunate that the original model of the IAB/PSO as one of ICANN's three everyone has to work together pillars was abandoned... and more unfortunate that it was replaced on the ICANN side by approximately nothing other than some committees and other bodies that could easily be ignored and on the IETF side by depending on individuals with feet in both camps to speak up. john
Re: [IETF] IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
On Jun 21, 2013, at 2:56 PM, John C Klensin john-i...@jck.com wrote: While I agree with the above (and am still trying to avoid carrying this conversation very far on the IETF list), I think another part of the puzzle is that there are also situations in which technical considerations imply real constraints on policy alternatives. Some obvious examples include physical constants like the speed of light, others, only slightly less obvious, include things like the design of the DNS as a simply hierarchy that cannot support symmetric aliases (i.e., anything that would support an actual came from function or a list of all of the names that point to a given note). The policy folks ignore those constraints, or treat them as subject to policy-making decisions at the risk of being ridiculous and/or causing considerable harm to the Internet. While they are less obvious in this community, I suggest it works the other way too -- there are policy and economic decisions and realities that are as much constraints on the technical solution space as those technical constrains are on the policy ones, with just about the same risks of ridiculousness or damage if they are ignored. Agreed. I believe that there is a better understanding of this situation now than in the earlier days (including among governments who are beginning to seriously engage with ICANN's GAC.) That is, again, why it is so unfortunate that the original model of the IAB/PSO as one of ICANN's three everyone has to work together pillars was abandoned... and more unfortunate that it was replaced on the ICANN side by approximately nothing other than some committees and other bodies that could easily be ignored and on the IETF side by depending on individuals with feet in both camps to speak up. It's difficult to lay blame anyone from walking away from the PSO approach; in ICANN's early years it always seemed to be a vestigial structure serving little purpose. The lack of apparent value was amplified when ICANN changed its proposed structure (from being oversight and coordination between true independent supporting organizations) into a heavily DNS-focused direction by opting to absorb the DNSO internally in the initial Singapore meeting. If ICANN were operating solely in a coordination and oversight role, with policy, process, and protocol development done in supporting organizations, then it would have been a lot easier to make the liaison and coordination function successful, both between pillars (DNSO, ASO, PSO) and to/from governmental types. For some reason, doing that in the margin of a 97% DNS-focused omnibus policy/oversight/coordination/operation organization doesn't provide the necessary level of attention. FYI, /John Disclaimers: My views alone. Apologies for length; I lacked the time to write a shorter reply.
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
On Jun 18, 2013, at 11:25 PM, Patrik Fältström p...@frobbit.se wrote: I think this is the correct strategy, BUT, I see as a very active participant in ICANN (chair of SSAC) that work in ICANN could be easier if some more technical standards where developed in IETF, and moved forward along standards track, that ICANN can reference. Same with some epp-related issues, and also DNS-related, which I must admit I think has stalled in the IETF. When that happens, ICANN start to invent or at least discuss IETF related issues -- which I think is non optimal. But on the other hand, if IETF do not move forward, then what should ICANN do? Something ICANN can do is ask the IETF for specifications. I can't promise instant delivery, but it will be slower if we don't know what they need.
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
On 18 jun 2013, at 18:54, Jari Arkko jari.ar...@piuha.net wrote: As for the rest of the discussion - I'm sure there are things to be improved in ICANN. I'd suggest though that some of the feedback might be better placed in an ICANN discussion than on IETF list. And is not like there'd be nothing to improve on our side :-) Lets focus on IETF aspects here. I think this is the correct strategy, BUT, I see as a very active participant in ICANN (chair of SSAC) that work in ICANN could be easier if some more technical standards where developed in IETF, and moved forward along standards track, that ICANN can reference. Same with some epp-related issues, and also DNS-related, which I must admit I think has stalled in the IETF. When that happens, ICANN start to invent or at least discuss IETF related issues -- which I think is non optimal. But on the other hand, if IETF do not move forward, then what should ICANN do? I will btw be the first few days (until including Tuesday or so) at IETF in Berlin and am happy to discuss this issue with anyone interested. Patrik Fältström Chair SSAC, ICANN
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
Hi Patrik, At 23:25 18-06-2013, Patrik Fältström wrote: I think this is the correct strategy, BUT, I see as a very active participant in ICANN (chair of SSAC) that work in ICANN could be easier if some more technical standards where developed in IETF, and moved forward along standards track, that ICANN can reference. Same with some epp-related issues, and also DNS-related, which I must admit I think has stalled in the IETF. When that happens, ICANN start to invent or at least discuss IETF related issues -- which I think is non optimal. But on the other hand, if IETF do not move forward, then what should ICANN do? I'll highlight part of a comment from Steve Crocker: (I sometimes have to explain to my colleagues at ICANN who have not had the benefit of the IETF experience that let's send it over to the IETF doesn't work. The IETF isn't a standing army ready to do ours or anyone else's work. Rather, I say, it's a place where the relevant people can get together to get their work done. It is easy to see why there isn't significant progress about DNS-related issues in the IETF. If nobody volunteers to do the work the work does not get done. Whether the problems are acute enough to require surgery is not for me to decide. The ITU does work as the IETF does not show interest in doing that work when it had the opportunity to do so. I would not worry too much about ICANN inventing as, to quote John Klensin: I don't know whether that is because they don't have time to write shorter reports or because they don't think the subject matter can be covered in more concise reports, but the pattern is clear, When those committees cannot agree or discover the issues are, in fact, contentious, they typically recommend the creation of more committees. Sometimes people either do not see the problems or pretend not to see them (I am not inferring that you do that). In the latter case I would be asked to explain why I think the problem is a problem when I mention it. I am somewhat suspicious when people who have much more experience than me do that. :-) I don't know whether you have been following the URNbis discussions. That WG had leisurely discussions about the drafts since over three years. It has not been able to publish a single RFC. DNSEXT has been in shutdown mode since over a year. The call for adoption of a draft in DNSOP failed as there wasn't significant interest within the working group to do that work. I'll ask a question to the other persons subscribed to this mailing list. Are there other active participants in ICANN interested in doing work in the IETF? Regards, -sm
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
On 19 jun 2013, at 10:59, SM s...@resistor.net wrote: I'll highlight part of a comment from Steve Crocker: (I sometimes have to explain to my colleagues at ICANN who have not had the benefit of the IETF experience that let's send it over to the IETF doesn't work. The IETF isn't a standing army ready to do ours or anyone else's work. Rather, I say, it's a place where the relevant people can get together to get their work done. It is easy to see why there isn't significant progress about DNS-related issues in the IETF. If nobody volunteers to do the work the work does not get done. Whether the problems are acute enough to require surgery is not for me to decide. Correct, and this is a/the weakness of both IETF and ICANN. And to some degree there might be parties that see the lack of progress as a good thing... The ITU does work as the IETF does not show interest in doing that work when it had the opportunity to do so. I would not worry too much about ICANN inventing as, to quote John Klensin: I don't know whether that is because they don't have time to write shorter reports or because they don't think the subject matter can be covered in more concise reports, but the pattern is clear, When those committees cannot agree or discover the issues are, in fact, contentious, they typically recommend the creation of more committees. This is one pattern, correct. And lack of RFCs is one of the reasons more committees is an attractive tool. I am not saying this is the only issue, I see it is one of them. Take (lack of) progress of draft-liman-tld-names for example. The need for this draft is in the ICANN context, not the IETF context, so of course it is hard to see the need in the IETF. Lack of an RFC there is by definition creating discussions in ICANN that goes on and on. And do not let me get started on EPP or Whois issues... ;-) Sometimes people either do not see the problems or pretend not to see them (I am not inferring that you do that). In the latter case I would be asked to explain why I think the problem is a problem when I mention it. I am somewhat suspicious when people who have much more experience than me do that. :-) The need is in ICANN, not in the IETF. That I see is the largest problem. Individuals then spending time in ICANN do not, although they see the need, participate in the IETF, or do not know how to participate, or fails to express the need/problem statement in IETF. I don't know whether you have been following the URNbis discussions. Oh yes! As one of the editors of the first URN documents, I have sort of a hobby to follow that :-P That WG had leisurely discussions about the drafts since over three years. It has not been able to publish a single RFC. DNSEXT has been in shutdown mode since over a year. The call for adoption of a draft in DNSOP failed as there wasn't significant interest within the working group to do that work. That is one of the problems for IETF. Can not say yes to something, while it seems (if I exaggerate) ITU and ICANN Can not say no to things. I'll ask a question to the other persons subscribed to this mailing list. Are there other active participants in ICANN interested in doing work in the IETF? Patrik
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
On Jun 19, 2013, at 2:27 AM, Patrik Fältström p...@frobbit.se wrote: And do not let me get started on EPP or Whois issues... ;-) Actually, let's let you get started. :-) Part of the problem you are seeing with the lack of RFCs desired by ICANN is that it is now harder to get an individual submission standards track RFC than it was ten years ago. ADs want more more done in WGs so they get more review before the document comes to IETF last call. But there is no EPP WG. And WEIRDS is supposed to only be forward-looking, not dealing with practices with the current protocol. The problem is that the IETF is saying two different things to ICANN: let us do the work, and we don't really care about the work you need done because it is about old protocols. The Applications Area Directors have done a good job of spinning up short-lived WGs for narrow topics, and letting single-topic documents come to AppsAWG, but ICANN's needs are greater than that. In the past, it was easy for a small group to put together a small protocol spec and get it on standards track if it was a follow-on to an existing protocol, but that is much more difficult now. ICANN needs it to be easier. The IETF should support them in that. --Paul Hoffman
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
On 19/06/2013 18:25, Patrik Fältström wrote: On 18 jun 2013, at 18:54, Jari Arkko jari.ar...@piuha.net wrote: As for the rest of the discussion - I'm sure there are things to be improved in ICANN. I'd suggest though that some of the feedback might be better placed in an ICANN discussion than on IETF list. And is not like there'd be nothing to improve on our side :-) Lets focus on IETF aspects here. I think this is the correct strategy, BUT, I see as a very active participant in ICANN (chair of SSAC) that work in ICANN could be easier if some more technical standards where developed in IETF, A pre-condition for that is that technical and operational problem statements are formulated, which could be sent to appropriate WGs or used to justify a BOF. If ICANN could focus on that instead of solutionism or committeeism, progress should be possible. Brian and moved forward along standards track, that ICANN can reference. Same with some epp-related issues, and also DNS-related, which I must admit I think has stalled in the IETF. When that happens, ICANN start to invent or at least discuss IETF related issues -- which I think is non optimal. But on the other hand, if IETF do not move forward, then what should ICANN do? I will btw be the first few days (until including Tuesday or so) at IETF in Berlin and am happy to discuss this issue with anyone interested. Patrik Fältström Chair SSAC, ICANN .
Re: [IETF] Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
On Jun 19, 2013, at 4:29 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 19/06/2013 18:25, Patrik Fältström wrote: On 18 jun 2013, at 18:54, Jari Arkko jari.ar...@piuha.net wrote: As for the rest of the discussion - I'm sure there are things to be improved in ICANN. I'd suggest though that some of the feedback might be better placed in an ICANN discussion than on IETF list. And is not like there'd be nothing to improve on our side :-) Lets focus on IETF aspects here. I think this is the correct strategy, BUT, I see as a very active participant in ICANN (chair of SSAC) that work in ICANN could be easier if some more technical standards where developed in IETF, + lots. If these are not developed in the IETF, we run the risk of ICANN doing technical stuff. As someone whose time is now[0] split between ICANN and IETF, I can tell you something -- you[1] *really* don't want ICANN developing technical standard. A pre-condition for that is that technical and operational problem statements are formulated, which could be sent to appropriate WGs or used to justify a BOF. If ICANN could focus on that instead of solutionism or committeeism, progress should be possible. Yup. This message needs to be properly communicated though -- Suzanne Woolf has been attempting (and being fairly effective) to do so. W [0]: I, along with some other IETF folk, serve on the SSAC under Patrik. [1]: You in the general sense, not you as in Brian or Patrik -- although I'm guessing you don't either. Are you confused yet with which you you are? Brian and moved forward along standards track, that ICANN can reference. Same with some epp-related issues, and also DNS-related, which I must admit I think has stalled in the IETF. When that happens, ICANN start to invent or at least discuss IETF related issues -- which I think is non optimal. But on the other hand, if IETF do not move forward, then what should ICANN do? I will btw be the first few days (until including Tuesday or so) at IETF in Berlin and am happy to discuss this issue with anyone interested. Patrik Fältström Chair SSAC, ICANN . -- She'd even given herself a middle initial - X - which stood for someone who has a cool and exciting middle name. -- (Terry Pratchett, Maskerade)
Re: [IETF] Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
--On Wednesday, June 19, 2013 17:14 -0400 Warren Kumari war...@kumari.net wrote: I think this is the correct strategy, BUT, I see as a very active participant in ICANN (chair of SSAC) that work in ICANN could be easier if some more technical standards where developed in IETF, + lots. If these are not developed in the IETF, we run the risk of ICANN doing technical stuff. Risk of ICANN doing technical stuff? You mean like the technical details of the escrow policy and how zones are supposed to be restored? Or how about Label Generation Rules for IDNs? Or how about the existing policies about registration data availability and what information is required? The point, Warren (and others) is that all of these are ICANN doing technical stuff and even technical standards in a broad sense of that term. Some of it is stuff that the IETF really should not want to do (I'm tempted to say avoid like the plague). Some of it probably should be here. As an outsider to both, there is a certain amount of stuff that has ended up in SSAC and even RSAC that might have been better located in SAAG or some IETF or NOG DNS operations group. I certainly won't argue that we've got the balance right. And I think it is unfortunate that the very early redesign of the original PSO had the side effect of making it hard or impossible to work out optimal boundaries and cross-review mechanisms with ICANN and that we are instead having a discussion more than a dozen years later about keeping ICANN from doing technical work or making standards. Let's not complicate things further by making the assumption that anything that reasonably looks like technical stuff belongs in the IETF and not in ICANN. It is likely to just make having the right conversations even harder. As someone whose time is now[0] split between ICANN and IETF, I can tell you something -- you[1] *really* don't want ICANN developing technical standard. Sorry. Too late. The horse left the barn well over a decade ago, arguably after we opened the door, led it out, and gave it a good swat. More broadly, there are lots of organizations I'd rather not have developing technical standards. In a few areas, the IETF might even be on the list. But stopping them would take not the usual Protocol Police force, but the IETF Army and I don't know where to find or how to deploy them. Perhaps you do. But, if not, the best we can do is to try to figure out and describe realistic boundaries and then try to negotiate, starting with having good arguments about what should be done where and why. And we should be really, really, careful about what we wish for because a lot of the space in which ICANN operates mixes really protocol issues with Layer 8 and 9 considerations and really heavy-duty politics. A pre-condition for that is that technical and operational problem statements are formulated, which could be sent to appropriate WGs or used to justify a BOF. If ICANN could focus on that instead of solutionism or committeeism, progress should be possible. Sure. Especially if ICANN could actually commit. where appropriate, to mandate whatever comes out of that process and then to enforce its mandates. Of course, I would also like a pony... or perhaps a stable-full. Yup. This message needs to be properly communicated though -- You mean like the requirements for variant aliases communicated to DNSEXT and other groups? Or did you have in mind the registration data requirements that went to CRISP? Or the more recent ones that have been handed off to WEIRDS after going through enough of an ICANN Policy Development Process that we can be reasonably confident that the requirements are real? Sorry, but, if we are going to have this conversation, I think it is very important that we be both real and specific, rather than engaging in fantasies about how things might work in the Best of All Possible Worlds or some other alternate reality. best, john
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
--On Tuesday, May 21, 2013 09:42 +0100 Steve Crocker st...@shinkuro.com wrote: Like the IETF, ICANN is also an open organization. ICANN meetings are free, and a veritable ocean of documents are published regularly, many in multiple languages to increase availability. ICANN is purposefully organized to include participation from a range of communities, e.g. business, civil society, governments, and the technical community. ... The roster of topics active within ICANN at any given time is fully documented and publicized, and I invite anyone who is interested to participate. We listen to everyone, and we publish tentative results, tentative policies, etc. for everyone to critique. --On Tuesday, May 21, 2013 12:25 +0200 Olivier MJ Crepin-Leblond o...@gih.com wrote: Quite frankly, I used to have the same feeling... until very recently. With Steve at the wheel, things have improved a lot. ... Today, it's still not perfect, but you cannot fix a bus by shooting it - work on it instead, to fix it. I believe it's fixable. Steve and Olivier, As I think you both know, I've made personal decisions to avoid saying what I'm about to say in places as public as the IETF list and have been largely successful in that for the last decade. I've been deliberating about the balance of advantages and disadvantages of responding to your notes; hence the delay in doing so. I've worked happily and successfully with both of you on various Internet issues and have no doubts about either your integrity or your commitment to a better Internet, with the latter more or less the way the IETF would understand. That shared background and assumptions combined with your very optimistic postings seem to call for comment. Olivier, certainly there has been change at ICANN over the last several years. You comment implies to me that you think things are monotonically improving; I don't believe that although I do believe that, if one starts from selected examples and times, huge improvements are easy to document. I'll address the issue of public input and what happens to it below. As a fairly trivial example, while issues are publicized (as Steve notes), they are publicized on a web site that seems much harder to find anything on, unless one is spending enough time working on ICANN issues for it to feel familiar with its organization, than it was a few years ago. I recommend trying the experiment of pretending you don't know the site and then trying to get quickly to information on the status, open issues, and decisions already made about any particular substantive issue in which you might be interested. Steve, participation in ICANN is certainly not free, any more than participation in the IETF is free. ICANN doesn't charge a meeting registration fee, but its meetings tend to be in more exotic places that are more costly to get to and/or stay at than IETF's choices (and some of us still whine about the IETF ones, especially when IAOC considers mid $200 range to be acceptable for hotels and when the combination of the IETF meeting schedule, associated meetings, and plane connections can easily require a six or seven day stay). My not entirely subjective impression is that participating in ICANN, f2f, is considerably more expensive in an average year than it is for IETF. More important, while I think the IETF's remote participation mechanisms could still use a lot of improvement, they do tend to work and our decisions on mailing lists rules and provisions for very public appeals and responses provide a lot of protection when they don't work. By contrast, ICANN's remote participation mechanisms for meetings often don't work (probably an unfortunate side-effect of some of the places ICANN chooses to meet) and a very large fraction of the key decision-making meetings and discussions don't even pretend to be publicly or remotely accessible. But the more important issue, at least from my perspective, is that two things keep reappearing and have either gotten worse or remained the same in recent years. They are: (1) While ICANN accepts input from anyone who is interested, there is very little evidence that any of that input has any influence on results unless it comes from a well-established constituency group. There is little evidence that either the Board or Staff actually consider any of the public input and considerable evidence (from examination of proposals before and after the public review) that they do not. It is also possible that they consider all such comments and justifiably conclude that all of them are completely bogus or uninformed, but I just can't believe that. That might be less of an issue were those established constituency groups really representative of the Internet community but, especially in the domain name space, the influential groups seems to be entirely those with a vested interest in the marketing and sales of domain names. Even in the address space, there is little
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
Did this LC end? or stated differently: What's the status of this draft LC? I'm not such a fan of the draft, mostly because it appears to remove some principles that some RIR folk hold up in their policy discussions as important... while not having a backstop in said policies to replace the originals from 2050. That can be fixed though... provided those communities see fit to keep the principles in place. Mostly then my 'not such a fan' is a timing problem I suppose, which is what prompted this LC query. -chris On Tue, Jun 18, 2013 at 10:30 AM, John C Klensin john-i...@jck.com wrote: --On Tuesday, May 21, 2013 09:42 +0100 Steve Crocker st...@shinkuro.com wrote: Like the IETF, ICANN is also an open organization. ICANN meetings are free, and a veritable ocean of documents are published regularly, many in multiple languages to increase availability. ICANN is purposefully organized to include participation from a range of communities, e.g. business, civil society, governments, and the technical community. ... The roster of topics active within ICANN at any given time is fully documented and publicized, and I invite anyone who is interested to participate. We listen to everyone, and we publish tentative results, tentative policies, etc. for everyone to critique. --On Tuesday, May 21, 2013 12:25 +0200 Olivier MJ Crepin-Leblond o...@gih.com wrote: Quite frankly, I used to have the same feeling... until very recently. With Steve at the wheel, things have improved a lot. ... Today, it's still not perfect, but you cannot fix a bus by shooting it - work on it instead, to fix it. I believe it's fixable. Steve and Olivier, As I think you both know, I've made personal decisions to avoid saying what I'm about to say in places as public as the IETF list and have been largely successful in that for the last decade. I've been deliberating about the balance of advantages and disadvantages of responding to your notes; hence the delay in doing so. I've worked happily and successfully with both of you on various Internet issues and have no doubts about either your integrity or your commitment to a better Internet, with the latter more or less the way the IETF would understand. That shared background and assumptions combined with your very optimistic postings seem to call for comment. Olivier, certainly there has been change at ICANN over the last several years. You comment implies to me that you think things are monotonically improving; I don't believe that although I do believe that, if one starts from selected examples and times, huge improvements are easy to document. I'll address the issue of public input and what happens to it below. As a fairly trivial example, while issues are publicized (as Steve notes), they are publicized on a web site that seems much harder to find anything on, unless one is spending enough time working on ICANN issues for it to feel familiar with its organization, than it was a few years ago. I recommend trying the experiment of pretending you don't know the site and then trying to get quickly to information on the status, open issues, and decisions already made about any particular substantive issue in which you might be interested. Steve, participation in ICANN is certainly not free, any more than participation in the IETF is free. ICANN doesn't charge a meeting registration fee, but its meetings tend to be in more exotic places that are more costly to get to and/or stay at than IETF's choices (and some of us still whine about the IETF ones, especially when IAOC considers mid $200 range to be acceptable for hotels and when the combination of the IETF meeting schedule, associated meetings, and plane connections can easily require a six or seven day stay). My not entirely subjective impression is that participating in ICANN, f2f, is considerably more expensive in an average year than it is for IETF. More important, while I think the IETF's remote participation mechanisms could still use a lot of improvement, they do tend to work and our decisions on mailing lists rules and provisions for very public appeals and responses provide a lot of protection when they don't work. By contrast, ICANN's remote participation mechanisms for meetings often don't work (probably an unfortunate side-effect of some of the places ICANN chooses to meet) and a very large fraction of the key decision-making meetings and discussions don't even pretend to be publicly or remotely accessible. But the more important issue, at least from my perspective, is that two things keep reappearing and have either gotten worse or remained the same in recent years. They are: (1) While ICANN accepts input from anyone who is interested, there is very little evidence that any of that input has any influence on results unless it comes from a well-established constituency group. There is little evidence that either the Board or
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
Chris: The last call on RFC 2050 bis has ended. The draft will be shortly on the IESG telechat, up for an approval decision and/or suggestion for changes. I personally think it is ready to move forward. That is not to say that we wouldn't take comments, if you have some. As for the rest of the discussion - I'm sure there are things to be improved in ICANN. I'd suggest though that some of the feedback might be better placed in an ICANN discussion than on IETF list. And is not like there'd be nothing to improve on our side :-) Lets focus on IETF aspects here. For what it is worth, I have limited experience about ICANN, but it has all been very positive. Jari
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
--On Tuesday, June 18, 2013 19:54 +0300 Jari Arkko jari.ar...@piuha.net wrote: Chris: The last call on RFC 2050 bis has ended. The draft will be shortly on the IESG telechat, up for an approval decision and/or suggestion for changes. I personally think it is ready to move forward. That is not to say that we wouldn't take comments, if you have some. Jari, For the record, I still believe that 2050bis should be published. Regardless of what I think of some of the things it says, I think it is reasonably reflective of reality and that reality is always worth documenting. As for the rest of the discussion - I'm sure there are things to be improved in ICANN. I'd suggest though that some of the feedback might be better placed in an ICANN discussion than on IETF list. And is not like there'd be nothing to improve on our side :-) Lets focus on IETF aspects here. For what it is worth, I have limited experience about ICANN, but it has all been very positive. As to my more general comments, they were not really addressed to 2050bis and I have no desire to start a discussion of them here. However, some assertions about how well ICANN is working were made on this list by people who do not usually participate actively in IETF's technical work. In part because some ICANN decisions and behaviors does affect the fate of IETF protocols and the state of the Internet generally, I concluded after a lot of consideration that those assertions should be responded to on this list. I would welcome a discussion (definitely somewhere else) about that difference in perceptions if it were possible that it would bring about either improved understanding or changes that would make the various decision-making processes that affect the Internet more open and/or more based on a general understanding of Internet technical reality. That would include an offlist discussion of why your perceptions and mine may differ should you find such a discussion useful. best, john
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
John, For the record, I still believe that 2050bis should be published. Regardless of what I think of some of the things it says, I think it is reasonably reflective of reality and that reality is always worth documenting. Thanks. As to my more general comments, they were not really addressed to 2050bis and I have no desire to start a discussion of them here. However, some assertions about how well ICANN is working were made on this list by people who do not usually participate actively in IETF's technical work. In part because some ICANN decisions and behaviors does affect the fate of IETF protocols and the state of the Internet generally, Ok. Understood. I would welcome a discussion (definitely somewhere else) about that difference in perceptions … That would include an offlist discussion of why your perceptions and mine may differ should you find such a discussion useful. Fair enough. Hopefully some of that could be fed into ICANN as well. (I should probably have indicated that my experience is very limited. I didn't want to indicate that there are no challenges - I know there are.) Jari
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
On Tue, Jun 18, 2013 at 12:54 PM, Jari Arkko jari.ar...@piuha.net wrote: Chris: The last call on RFC 2050 bis has ended. The draft will be shortly on the IESG telechat, up for an approval decision and/or suggestion for changes. I personally think it is ready to move forward. That is not to say that we wouldn't take comments, if you have some. ok, cool... my only comment was on the timing issue... which I doubt will get fixed before pub time, and isn't a show-stopper though ... will make the conversation at the RIR level a bit more challenging for some folks I imagine. -chris
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
As for the rest of the discussion - I'm sure there are things to be improved in ICANN. I'd suggest though that some of the feedback might be better placed in an ICANN discussion than on IETF list. when that feedback is that the icann does not really listen to feedback, i think there is a problem with this approach. the examples of earwax are rife. randy
IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
Dan and John, Thanks for the exchange last week. As chair of ICANN's Board of Directors and an active participant in ICANN's current effort to take a fresh look at the Whois architecture and operation, your notes catch my attention in multiple ways. But first, for the benefit of under forty crowd, let me briefly introduce myself. In the late 1960s I chaired the ARPANET's Network Working Group, which eventually morphed into today's IETF. I created the RFC series and I was one of the architects of the three facets of openness that are the foundation of the Internet protocol process, viz open architecture, open participation and open publication. In the late 1980s and early 1990s I served as the first area director for security and later on the IAB. I also co-chaired the POSIED Working Group that revised the standardization process, moving the authority from the IAB to the IESG, and in the mid 2000s I served on the ISOC board and participated in the formation and initial operation of the IETF Administrative Support Activity (IASA) and I served on its IAOC. For the past 11 years I've been active in ICANN, serving for several years as the chair of the Security and Stability Advisory Committee and also on the board of ICANN, and about two years ago I was elected chair of the ICANN board. And despite having spent a great deal of time in management and political roles in this environment, I remain fundamentally a technical person. I want to share two thoughts, one about the role of the IETF, ICANN and other organizations within the Internet ecosystem, and one about Whois. The great strength of the IETF is it's a forum for technical people to come together, work out the details of protocols, and publish consensus documents. The IETF does not have any formal powers granted by legal authorities. IETF standards are effective because they're accepted and they work, not because they're imposed on anyone. IETF standards are respected around the world because they embody the wisdom and experience of the technical community. No one is obliged to use the protocols created within the IETF, but, of course, a huge portion of the world does use these protocols. ICANN was created in 1998 to operate the IANA function and to expand and organize the marketplace in domain names. The IANA function is fundamentally a clerical service. It records the assignment of unique identifiers that are used throughout the Internet, and it does so in accordance with the values and policies established by the community. The IANA service includes publication of the IETF's protocol parameters, allocation of blocks of AS numbers, IPv6 address blocks, and, until recently, IPv4 blocks to RIRs, and administration of the top level of the domain name hierarchy. Like the IETF, ICANN is also an open organization. ICANN meetings are free, and a veritable ocean of documents are published regularly, many in multiple languages to increase availability. ICANN is purposefully organized to include participation from a range of communities, e.g. business, civil society, governments, and the technical community. As I write this, I am at a retreat for the ICANN Board focusing on strategic planning. One of the seats on the Board is allocated to a liaison from the IETF, and thus I am actually sitting at the time I drafted this note in between Thomas Narten and Jonne Soininen, the outgoing and incoming IETF liaisons to the ICANN Board. One of the large and often time-consuming activities within ICANN is the development of policies that pertain to the domain name system. John Curran wrote: To be abundantly clear, you are hypothesizing a difference of opinion between the IETF/IESG and the ICANN/RIR communities, wherein the technical guidance of the IETF was considered during the ICANN/RIR decision process, but in the end the outcome was contrary to IETF expectations. This would be an unfortunate (but not impossible) situation, as many folks in the combined community would likely have been involved during the process trying to figure out why there is such a significant difference in views and facilitating sharing of the beliefs and thought processes that underlie the situation. I agree completely with John. It is indeed possible for ICANN to adopt policies that are not perfectly aligned with IETF recommendations. Possible, but not usual. Over here at ICANN we pay a LOT of attention to the IETF. We depend heavily on the IETF's work and we never seek to duplicate or ignore it. (I sometimes have to explain to my colleagues at ICANN who have not had the benefit of the IETF experience that let's send it over to the IETF doesn't work. The IETF isn't a standing army ready to do ours or anyone else's work. Rather, I say, it's a place where the relevant people can get together to get their work done. And, indeed, a number of ICANN people actively participate in various
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
dear emperor, despite the braggadocio, there seems to be a shortage of attire. icann is notorious for pretending to be open but being effectively closed. it solicits public comment and ignores it. i could go on and on, but i am far less wordy. randy
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
On 21/05/2013 10:42, Steve Crocker wrote: As I said above, I invite anyone who is interested to participate. The IETF, ICANN, the RIRs, ISOC, W3C and other organizations have all arisen within the ecosystem that accompanies the growth and prevalence of the Internet. It is natural for there to be some tension, competition and rivalry among our institutions, but we have all been part of the same grand enterprise, we all share the same core values, and we all work toward the same goal of an open, innovative, expanding Internet. +1 to everything Steve has said. And I take this opportunity to remind you that you can directly influence the outcome of *all* the work at ICANN by taking part in it. There are several avenues for this. One of them is through the ALAC: the At-Large Advisory Committee's (ALAC) role is to facilitate input from Internet users into the ICANN policy processes. It does not purport to represent Internet users, but it tries as much as it can to act in the *best interests* of Internet users. But without your input and particularly on technical issues where we need as much help as we can get, the ALAC cannot issue Statements that adhere to the general point of view of Internet users. How can you take part? The North American region allows for individual membership. Other regions require that you are part of an At-Large Structure (ALS) to participate - but if you see the list, you'll notice there are a LOT of ALSes, many of which are ISOC Chapters. And you do NOT need to be part of an At-Large Structure to participate in the At-Large Working Groups. Membership is only needed for matters of voting - and since we operate by consensus, that's a rare occurrence, usually only kept to selection of leadership. A few links: ALAC Correspondence: http://www.atlarge.icann.org/correspondence ALAC Policy Development: https://community.icann.org/x/bwFO ALAC Working Groups: https://community.icann.org/x/loIi I know this is a shameless plug but in the face of the threat posed by non-multi-stakeholder systems of governance, I felt a follow-up on Steve's post was necessary. As Steve says so eloquently, we need to all work toward the goal of an open, innovative, expanding Internet. Warm regards, Olivier MJ Crépin-Leblond ALAC Chair https://community.icann.org/x/ppEi
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
Dear Randy, On 21/05/2013 11:58, Randy Bush wrote: dear emperor, despite the braggadocio, there seems to be a shortage of attire. icann is notorious for pretending to be open but being effectively closed. it solicits public comment and ignores it. i could go on and on, but i am far less wordy. randy Quite frankly, I used to have the same feeling... until very recently. With Steve at the wheel, things have improved a lot. Whilst as recently as 3 years ago, we often used to feel that ALAC advice was tossed over the wall and we'd never hear any feedback be blatantly ignored, things have improved and we are heard and more importantly listened to a lot more. Credit for this is due to the new Leadership Teams, both on the volunteer Staff parts of ICANN. Today, it's still not perfect, but you cannot fix a bus by shooting it - work on it instead, to fix it. I believe it's fixable. Start here: http://www.icann.org/en/news/public-comment/atrt2-02apr13-en.htm Kind regards, Olivier (not wearing any hat) -- Olivier MJ Crépin-Leblond, PhD http://www.gih.com/ocl.html
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
Hi Steve, At 01:42 21-05-2013, Steve Crocker wrote: I want to share two thoughts, one about the role of the IETF, ICANN and other organizations within the Internet ecosystem, and one about Whois. The great strength of the IETF is it's a forum for technical people to come together, work out the details of protocols, and publish consensus documents. The IETF does not have any formal powers granted by legal authorities. IETF standards are effective because they're accepted and they work, not because they're imposed on anyone. IETF standards are respected around the world because they embody the wisdom and experience of the technical community. No one is obliged to use the protocols created within the IETF, but, of course, a huge portion of the world does use these protocols. IETF standards are de facto standards. It is doubtful whether some of the RFCs embody the wisdom and experience of the IETF community. Nobody may be obliged to use these standards. However, do people have a choice? How would I contact the IETF if my mail server uses another standard? Like the IETF, ICANN is also an open organization. ICANN meetings are free, and a veritable ocean of documents are published regularly, many in multiple languages to increase availability. I note that IETF meetings are not free. Everyone can claim to be open. ICANN is purposefully organized to include participation from a range of communities, e.g. business, civil society, governments, and the technical community. As I write this, I am at a retreat for the ICANN Board focusing on strategic planning. One of the seats on the Board is allocated to a liaison from the IETF, and thus I am actually sitting at the time I drafted this note in between Thomas Narten and Jonne Soininen, the outgoing and incoming IETF liaisons to the ICANN Board. There are currently three comments about the proposed Whois Information Status Policy ( http://www.icann.org/en/news/public-comment/wisp-10may13-en.htm ). There's more comments than that for some IETF Last Calls (e.g. http://www.ietf.org/mail-archive/web/ietf/current/msg79366.html ). The IETF Chair posted an article on his blog. There is a long thread about it ( http://www.ietf.org/mail-archive/web/ietf/current/msg78984.html ). The ICANN range of communities seem to be having problems sending mail as I don't see any trace of their participation. If I want to know what the IESG is up to, I read a web page and I find: abstract: the draft does stuff, it doesn't 'set out to' do stuff, at least not anymore of the IETF experience that let's send it over to the IETF doesn't work. The IETF isn't a standing army ready to do ours or anyone else's work. Rather, I say, it's a place where the relevant people can get together to get their work done. And, indeed, a number of ICANN people Agreed. actively participate in various IETF working groups.) I do not see ICANN people participating in an IETF Last Call. I would not call it active participation. The roster of topics active within ICANN at any given time is fully documented and publicized, and I invite anyone who is interested to participate. We listen to everyone, and we publish tentative results, tentative policies, etc. for everyone to critique. I am curious about where the ICANN process is documented. I could not find anything that looks like RFC 2026. within the generic top level domains. The country code top level domains are roughly the same number, and their Whois structures and policies are each controlled by the individual ccTLD operator and their communities. With all due respect I find it hard to believe that Whois structures and policies are controlled by the respective communities. and think through whether we might be better served by a revised system. An expert working group was assembled and is currently working through these issues. Its output will be a consideration of the issues and recommendations for further work. It is not yet clear whether the result of this effort will lead to a large change, a small change, or no change at all. What is clear is that the results of this working group will become fully public, and any decisions will come through our usual policy development process. The output of that working group was lacking. If an IETF working group cannot produce useful results it should be shut down. It seems that ICANN's measure is public and process instead of a results-oriented approach. The IETF, ICANN, the RIRs, ISOC, W3C and other organizations have all arisen within the ecosystem that accompanies the growth and prevalence of the Internet. It is natural for there to be some tension, competition and rivalry among our institutions, but we have all been part of the same grand enterprise, we all share the same core values, and we all work toward the same goal of an open, innovative, expanding Internet. Please note that I can
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
Hi Olivier, At 03:00 21-05-2013, Olivier MJ Crepin-Leblond wrote: And you do NOT need to be part of an At-Large Structure to participate in the At-Large Working Groups. Membership is only needed for matters of voting - and since we operate by consensus, that's a rare occurrence, usually only kept to selection of leadership. The voting and consensus part reminds me of the ITU. The vote that happened last year has been the subject of numerous comments. I know this is a shameless plug but in the face of the threat posed by non-multi-stakeholder systems of governance, I felt a follow-up on Steve's post was necessary. As Steve says so eloquently, we need to all work toward the goal of an open, innovative, expanding Internet. I don't see any threat. What I see are words defined or redefined to suit the interests of the day. Regards, -sm
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
On 5/21/2013 8:50 AM, SM wrote: I gather that everyone is aware that civil society has been somewhat uncivil lately. That society has not made any significant negative comments about the IETF. Actually it has. Since he's such a long-active figure in those circles, check out Milton Mueller's Ruling the Root, from 10 years ago. He was quite critical and dismissive of the technical community, including the IETF: http://bbiw.net/musings.html#rootreviewl d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
Hi Dave, At 10:03 21-05-2013, Dave Crocker wrote: Actually it has. Since he's such a long-active figure in those circles, check out Milton Mueller's Ruling the Root, from 10 years ago. He was quite critical and dismissive of the technical community, including the IETF: Thanks for the reference. I have read some messages [1][2] from the person. I don't recall reading the book. As the subject line mentions Whois I found something to read [3]. Regards, -sm 1. http://lists.arin.net/pipermail/arin-ppml/2012-April/024498.html 2. http://lists.ripe.net/pipermail/address-policy-wg/2012-April/006888.html 3. http://www.mendeley.com/download/public/777611/2362103122/da394283f86f68aa168abaf59d919f78d7c8f2b8/dl.pdf
Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
On May 15, 2013, at 7:50 PM, David Farmer far...@umn.edu wrote: So lets play a little hypothetical here; What if an RIR or ICANN through a global policy decided Whois Data no longer should be public for overriding privacy reasons. My read of Section 5, is that would be proper path for such a change, and long as the technical guidance of the IETF is considered in the process. But then through RFC 2860 and Section 5, if the IETF objected on technical or architectural grounds, and formally through the IESG, then the IAB would essentially adjudicate the issue. And ICANN or the RIR are obligated to accept the decision of the IAB. Do I have that right? To be abundantly clear, you are hypothesizing a difference of opinion between the IETF/IESG and the ICANN/RIR communities, wherein the technical guidance of the IETF was considered during the ICANN/RIR decision process, but in the end the outcome was contrary to IETF expectations. This would be an unfortunate (but not impossible) situation, as many folks in the combined community would likely have been involved during the process trying to figure out why there is such a significant difference in views and facilitating sharing of the beliefs and thought processes that underlie the situation. (btw, these types of efforts happen in more contexts than just the hypothetical one you suggest, and are a good reason to ask Have you hugged your AD recently? ;-) To be clear, I'm not advocating Whois should or shouldn't remain public, or that anything is wrong with the Section 5. This just seemed like a plausible hypothetical to explore how the puzzle pieces work together to make the Internet Numbers Registry System. Also, I just want to fully understand what Section 5 really means. Ultimately, your hypothetical situation could result in the breakdown of the present relationship between IETF and ICANN/RIR organizations (ref: RFC 2860, section 2), with otherwise indeterminate consequences... i.e. It would be bad. When the various Internet organizations are aligned in the coordination of Internet critical resources (DNS, IP addresses, protocol parameter #'s), then the result is well understood. We lack experience with the alternative, and it is not clear whether chair remains upright when missing one or more legs. FYI, /John p.s. Disclaimer: My views alone.
Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
To be abundantly clear, you are hypothesizing a difference of opinion between the IETF/IESG and the ICANN/RIR communities, wherein the technical guidance of the IETF was considered during the ICANN/RIR decision process, but in the end the outcome was contrary to IETF expectations. if you s/expectations/preference/ then there is a growing track record. try the new greed top level domains (gtlds) for starters. randy
Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
--On Friday, May 17, 2013 18:54 +0300 Randy Bush ra...@psg.com wrote: To be abundantly clear, you are hypothesizing a difference of opinion between the IETF/IESG and the ICANN/RIR communities, wherein the technical guidance of the IETF was considered during the ICANN/RIR decision process, but in the end the outcome was contrary to IETF expectations. if you s/expectations/preference/ then there is a growing track record. try the new greed top level domains (gtlds) for starters. I've been trying to stay out of this thread, but let me take that a little further. I believe that IETF preferences are largely based on the overall welfare of the Internet as a complete system. I also believe that the understanding of that system among IETF participants as a group is generally pretty good. Certainly we fail sometimes; IMO, much more often that I'd like. But there still seems to be rather general agreement about success criteria and those criteria, to quote Harald's comment of some years ago, involve making the Internet work better. In addition, actual capture of the IETF consensus process is really hard. WGs can sometimes be captured by specific interests and the IESG decision processes are sometimes not ideal, but capture is hard. As several recent threads on the IETF list illustrate, large portions of the community are passionate about how decisions are made, express themselves vigorously, and are usually listened to enough to affect actions when that is appropriate. As far as I can tell, large parts of the ICANN community and its decision processes (I'm not going to comment on the RIRs because I don't have nearly enough recent exposure) don't subscribe to those same criteria. Their most-cited criteria are competitiveness. Security and stability are chanted as a mantra, but, empirically, that chant is about the avoidance of major, scandalous, problems that can be directly attributed to ICANN decisions rather than about making things better. And the price of entry and effective participation has gradually evolved (or been captured) in a way that biases issue consideration and decision making toward the wishes of a narrow range of commercial interests with short-term profitability goals plus a few symbolic public or civil constituencies whose ability to be effective is constrained by the desire to continue to participate and feed at the ICANN trough (the phrase enjoy fine lunches and dinners at the expense of others may be applicable here). Those processes seem to be self-reinforcing and self-reproducing enough, and driven in practice by a narrow enough range of interests, to meet almost any criterion for a captured label. The level of harmony and conformance between ICANN's stated principles and core values (as reflected in its bylaws, reference [ICANNBL] in the draft) and ICANN's actual influences and operational and decision-making practices would seem to lie far outside the scope of this document. I think the document reflects a certain naivety about the range of differences between theory and practice, but I'd not convinced that is harmful beyond some risks of making the authors look silly in some conceivable future scenarios. If the technical guidance of the IETF were really based on the best interests of a better Internet and then used as input to a process that doesn't consider that a particularly useful criterion, then an outcome that is contrary to that advice is nearly inevitable unless the advice coincidentally matches the criteria that are actually being used. What should be done about that is a different and, sadly complex matter (especially given the risks of significant collateral damage that could harm the Internet). But it doesn't seem to me that is the present issue. For the present document, if it accurately describes the current situation and how things have evolved since 2050, then it is worth publishing. If we don't like how things work, it seems to me that changing that is part of a different effort and that a good current description is a necessary starting point. I, however, do have one significant objection to the current draft of the document and do not believe it should be published (at least as an RFC in the IETF Stream) until the problem is remedied. The Introduction (Section 1) contains the sentence Since the publication of RFC 2050, the Internet Numbers Registry System has changed significantly.That sentence is expanded upon in Section 6, which bears the interesting title of Summary of Changes Since RFC 2050. But Section 6 contains no such summary, merely a statement that things have changed and that some material -- unidentified except by the broadest of categories -- has been omitted. I do not believe this document is complete enough to publish as an RFC in the IETF Stream without a real summary of the changes since 2050, preferably with either explanations of each significant change or references to the documents or discussions
Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
John, On 18/05/2013 05:23, John C Klensin wrote: ... I, however, do have one significant objection to the current draft of the document and do not believe it should be published (at least as an RFC in the IETF Stream) until the problem is remedied. The Introduction (Section 1) contains the sentence Since the publication of RFC 2050, the Internet Numbers Registry System has changed significantly. If we want to avoid ratholes built into the document, it might be prudent to rephrase that sentence as Since the publication of RFC 2050, the environment of the Internet Numbers Registry System has changed. That sentence is expanded upon in Section 6, which bears the interesting title of Summary of Changes Since RFC 2050. But Section 6 contains no such summary, merely a statement that things have changed and that some material -- unidentified except by the broadest of categories -- has been omitted. I took that section title to refer to changes *in the text* of 2050, not changes in the system. Maybe the authors could clarify their intent, and if it is limited to text changes, clarify the wording accordingly. Brian
Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
--On Saturday, May 18, 2013 08:14 +1200 Brian E Carpenter brian.e.carpen...@gmail.com wrote: John, On 18/05/2013 05:23, John C Klensin wrote: ... I, however, do have one significant objection to the current draft of the document and do not believe it should be published (at least as an RFC in the IETF Stream) until the problem is remedied. The Introduction (Section 1) contains the sentence Since the publication of RFC 2050, the Internet Numbers Registry System has changed significantly. If we want to avoid ratholes built into the document, it might be prudent to rephrase that sentence as Since the publication of RFC 2050, the environment of the Internet Numbers Registry System has changed. Both statements are true-- the environment has changed and the system has changed. At least in principle, the environment has changed less with three three really notable events being the advent of ICANN, the end-game of the IPv4 address space, and the growing importance of the IPv6 one. I think that can be said and the other changes summarized. From my point of view, if we have to avoid describing the changes to avoid ratholes, it would be legitimate for someone to ask what we are hiding. That sentence is expanded upon in Section 6, which bears the interesting title of Summary of Changes Since RFC 2050. But Section 6 contains no such summary, merely a statement that things have changed and that some material -- unidentified except by the broadest of categories -- has been omitted. I took that section title to refer to changes *in the text* of 2050, not changes in the system. Maybe the authors could clarify their intent, and if it is limited to text changes, clarify the wording accordingly. I just checked your hypothesis by looking at a diff between 2050 and the present draft. As far as I can tell from a quick review, there is not a single unchanged paragraph. So, if the issue is text changes, this is not an update but an almost complete replacement. john
Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
On 18/05/2013 11:59, John C Klensin wrote: --On Saturday, May 18, 2013 08:14 +1200 Brian E Carpenter brian.e.carpen...@gmail.com wrote: John, On 18/05/2013 05:23, John C Klensin wrote: ... I, however, do have one significant objection to the current draft of the document and do not believe it should be published (at least as an RFC in the IETF Stream) until the problem is remedied. The Introduction (Section 1) contains the sentence Since the publication of RFC 2050, the Internet Numbers Registry System has changed significantly. If we want to avoid ratholes built into the document, it might be prudent to rephrase that sentence as Since the publication of RFC 2050, the environment of the Internet Numbers Registry System has changed. Both statements are true-- the environment has changed and the system has changed. At least in principle, the environment has changed less with three three really notable events being the advent of ICANN, the end-game of the IPv4 address space, and the growing importance of the IPv6 one. I think that can be said and the other changes summarized. From my point of view, if we have to avoid describing the changes to avoid ratholes, it would be legitimate for someone to ask what we are hiding. That sentence is expanded upon in Section 6, which bears the interesting title of Summary of Changes Since RFC 2050. But Section 6 contains no such summary, merely a statement that things have changed and that some material -- unidentified except by the broadest of categories -- has been omitted. I took that section title to refer to changes *in the text* of 2050, not changes in the system. Maybe the authors could clarify their intent, and if it is limited to text changes, clarify the wording accordingly. I just checked your hypothesis by looking at a diff between 2050 and the present draft. As far as I can tell from a quick review, there is not a single unchanged paragraph. So, if the issue is text changes, this is not an update but an almost complete replacement. Yes, because apart from anything else, the draft leaves out a number of topics that are explicitly out of IETF scope since RFC 2860. I don't really see what we are hiding in this: This document describes the Internet Numbers Registry System as it presently exists and omits policy and operational procedures that have been superseded by ICANN and RIR policy since RFC 2050 publication. (given that there is a reference to RFC 2860 a few lines earlier). If I had the edit pen I would probably want to rephrase that paragraph a bit, but it does say what has been deleted and why. Brian
Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
On 5/14/13 13:32 , David Conrad wrote: Hi, On May 14, 2013, at 11:02 AM, David Farmer far...@umn.edu wrote: The third goal you refer to focuses on the need for accurate registration information ... in order to meet a variety of operational requirements. I believe this to be a valid technical concerns of the IETF, it is difficult to imagine how a global Internet can technically function without this. So, I think it is important for it to remain in the draft. I would also point out that the third goal makes no statement on whether the registration data is publicly available or not. However, issues of privacy, law enforcement access, and a myriad of other extremely important issues related to the Internet Numbers Registry System are outside the technical and operational scope of the IETF. The whole point of the draft is to document the issues that are properly the concern of the IETF towards the Internet Numbers Registry System and to pass the rest of it to the multi-stakeholder environment of ICANN and the RIRs to hash it out. Exactly. Section 4 notes that provision of public WHOIS has been a technical consideration and that it may be necessary for the Internet community to examine these and related technical and operational considerations and how best to meet them. I agree with everything you say above regarding public available of the registration data. However, at the same time Section 7, quoted below, makes a very strong argument for it to remain public. It is generally recognized that accuracy and public availability of Internet registry data is often an essential component in researching and resolving security and operational issues on the Internet. So lets play a little hypothetical here; What if an RIR or ICANN through a global policy decided Whois Data no longer should be public for overriding privacy reasons. My read of Section 5, is that would be proper path for such a change, and long as the technical guidance of the IETF is considered in the process. But then through RFC 2860 and Section 5, if the IETF objected on technical or architectural grounds, and formally through the IESG, then the IAB would essentially adjudicate the issue. And ICANN or the RIR are obligated to accept the decision of the IAB. Do I have that right? To be clear, I'm not advocating Whois should or shouldn't remain public, or that anything is wrong with the Section 5. This just seemed like a plausible hypothetical to explore how the puzzle pieces work together to make the Internet Numbers Registry System. Also, I just want to fully understand what Section 5 really means. Thanks. -- David Farmer Email: far...@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952
Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
On 5/11/13 10:17 , SM wrote: At 18:36 10-05-2013, David Conrad wrote: ... Is it up to the IETF to set up a one-stop shop for personal data requests? I suspect not, but I suspect it isn't up to the IETF to dictate global privacy policy either. Section 2 is about the goals for distributing number resources (re. first sentence). I suggest removing the third goal as it might be a matter of global (or other) policy. It also makes privacy a non-issue as there isn't any relationship between it and the goals. ... The third goal you refer to focuses on the need for accurate registration information ... in order to meet a variety of operational requirements. I believe this to be a valid technical concerns of the IETF, it is difficult to imagine how a global Internet can technically function without this. So, I think it is important for it to remain in the draft. However, issues of privacy, law enforcement access, and a myriad of other extremely important issues related to the Internet Numbers Registry System are outside the technical and operational scope of the IETF. The whole point of the draft is to document the issues that are properly the concern of the IETF towards the Internet Numbers Registry System and to pass the rest of it to the multi-stakeholder environment of ICANN and the RIRs to hash it out. -- David Farmer Email: far...@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952
Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
Hi, On May 14, 2013, at 11:02 AM, David Farmer far...@umn.edu wrote: The third goal you refer to focuses on the need for accurate registration information ... in order to meet a variety of operational requirements. I believe this to be a valid technical concerns of the IETF, it is difficult to imagine how a global Internet can technically function without this. So, I think it is important for it to remain in the draft. I would also point out that the third goal makes no statement on whether the registration data is publicly available or not. However, issues of privacy, law enforcement access, and a myriad of other extremely important issues related to the Internet Numbers Registry System are outside the technical and operational scope of the IETF. The whole point of the draft is to document the issues that are properly the concern of the IETF towards the Internet Numbers Registry System and to pass the rest of it to the multi-stakeholder environment of ICANN and the RIRs to hash it out. Exactly. Section 4 notes that provision of public WHOIS has been a technical consideration and that it may be necessary for the Internet community to examine these and related technical and operational considerations and how best to meet them. Regards, -drc
Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
On May 11, 2013, at 11:17 AM, SM wrote: If it's a policy it cannot be a principle. Sorry, but unless you can point to some relevant real-world examples of self-executing, self-sustaining principles, or you're a nihilist and don't really believe that such things as principles exist at all, this is a patently false, bordering on nonsense statement. I'll suggest alternative text: 1) Allocation Pool: IP addresses and AS numbers are fixed length numbers. The allocation pools for these number resources are considered as resources which are finite. The principle for the above is to avoid set any constraint unless it is necessary for IETF protocols to work. One is tempted to ask work for who? but that would entail giving this statement more credence that it merits. Since TCP/IP is only useful to the end of communication between two or more nodes, the proposed principle of finitude would perfectly consistent with this, and almost every other IETF addressing/attachment protocol *not* working at all. Or did you mean to say that The principle for the above is to avoid set any constraint unless it is necessary for IETF protocols to 'work' between two virtual machines, under lab conditions? I suggest that the proposed alternative text should be rejected. True. The document is documenting current practices and policies. At this point in time, I'm unaware of a global privacy practice or policy that is applicable to all levels of the Internet Numbers Registry System. Is it up to the IETF to set up a one-stop shop for personal data requests? I suspect not, but I suspect it isn't up to the IETF to dictate global privacy policy either. Section 2 is about the goals for distributing number resources (re. first sentence). I suggest removing the third goal as it might be a matter of global (or other) policy. Since uniqueness is a basic constraint for most if not all current addressing/attachment-related IETF protocols -- even between two virtual machines, under lab conditions -- and would still be a basic constraint even if current address protocols were not quantity constrained in any way, you seem to be suggesting that the IETF forego not only policy statements, but also your own only work principle, at least under certain circumstances. Bottom line: this word principle, I do not think it means what you think it means. I suggest leaving section three in place. TV Regards, -sm
Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
On May 11, 2013, at 7:34 PM, SM wrote: At 13:08 11-05-2013, Tom Vest wrote: Sorry, but unless you can point to some relevant real-world examples of self-executing, self-sustaining principles, or you're a nihilist and don't really believe that such things as principles exist at all, this is a patently false, bordering on nonsense statement. I am not suggesting any self-executing or self-sustaining principles. Fair enough; I will assume that we agree that policies and principles are not mutually exclusive and incompatible phenomena, and that the class of durable, self-executing, and self-sustaining principles is an empty set. One is tempted to ask work for who? but that would entail giving this statement more credence that it merits. Since TCP/IP is only useful to the end of communication between two or more nodes, the proposed principle of finitude would perfectly consistent with this, and almost every other IETF addressing/attachment protocol *not* working at all. Or did you mean to say that The principle for the above is to avoid set any constraint unless it is necessary for IETF protocols to 'work' between two virtual machines, under lab conditions? What I meant was to leave policy (PDP, etc.) to the communities interested in IP addressing. I'll quote part of a message posted on the thread: 'To date, the communities interested in IP addressing have established policies that dictate operational needs should be the primary constraint (as opposed to say constraining on geo-political boundaries, by ability to pay, etc).' The message is at http://www.ietf.org/mail-archive/web/ietf/current/msg79200.html in case what I was quoted is misrepresented. I certainly did not intend to misrepresent your position. But given the fact that the part of a message that you reproduced was offered in response to doubts that you yourself raised about the points covered therein (esp. operational need), what is your position, exactly? As David said, to date the communities have established policies that are broadly informed by the practical implications of the finitude and uniqueness constraints on address resource management. However, to conclude based on past observations that such will always be true would be tantamount to claiming that management of those constraints is assured by the operation of (unspecified self-executing, self-sustaining) principles. Based on your views as expressed in/around draft-moonesamy-rfc2050-historic-00, it's pretty clear that you don't see any durable, much less timeless principles embodied therein -- but that only makes your position on these matters all the more ambiguous. Perhaps it would help if you would answer the following clarifying questions: 1. Is it your position that some other force or principle(s) outside of the general mechanisms/practices documented in RFC2050 (and potentially, RFC2050-bis) guarantees that IETF-defined addressing protocols will just work as designed, in perpetuity, and thus the informational codification of matters related to the management of finitude and uniqueness constraints is at best unnecessary, at worst counterproductive? If so, what are those unnamed forces/principles, exactly? 2. Is it your position that, if the traditional communities interested in IP addressing one day elect to adopt policies that make it impossible for IETF addressing protocols to fulfill even the basic just work test, then from the IETF view that should be regarded as a perfectly appropriate and acceptable outcome? At 13:14 11-05-2013, Brian E Carpenter wrote: It's up to the IETF to set boundary conditions for the address space that it created (in the case of IPv6) or inherited (in the case of IPv4), in order to protect the long-term viability of the Internet. There is some text about Internet address architecture. It would cover that if the relevant communities are agreeable to it. Could you please clarify which passages about Internet address architecture you are suggesting are sufficient to make the sections about distribution and uniqueness constraints unnecessary? Thanks, TV Regards, -sm
Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
At 13:45 12-05-2013, Tom Vest wrote: I certainly did not intend to misrepresent your position. But given the fact that the part of a message that you reproduced was offered in response to doubts that you yourself raised about the points covered therein (esp. operational need), what is your position, exactly? As David said, to date the communities have established policies that are broadly informed by the practical implications of the finitude and uniqueness constraints on address resource management. However, to conclude based on past observations that such will always be true would be tantamount to claiming that management of those constraints is assured by the operation of (unspecified self-executing, self-sustaining) principles. Based on your views as expressed in/around draft-moonesamy-rfc2050-historic-00, it's pretty clear that you don't see any durable, much less timeless principles embodied therein -- but that only makes your position on these matters all the more ambiguous. I prefer to keep draft-housley-rfc2050bis-01 separate from other drafts to keep matters simple. My position is that it is better to work towards consensus. Perhaps it would help if you would answer the following clarifying questions: 1. Is it your position that some other force or principle(s) outside of the general mechanisms/practices documented in RFC2050 (and potentially, RFC2050-bis) guarantees that IETF-defined addressing protocols will just work as designed, in perpetuity, and thus the informational codification of matters related to the management of finitude and uniqueness constraints is at best unnecessary, at worst counterproductive? If so, what are those unnamed forces/principles, exactly? 2. Is it your position that, if the traditional communities interested in IP addressing one day elect to adopt policies that make it impossible for IETF addressing protocols to fulfill even the basic just work test, then from the IETF view that should be regarded as a perfectly appropriate and acceptable outcome? I don't have an opinion about questions (1) or (2). Could you please clarify which passages about Internet address architecture you are suggesting are sufficient to make the sections about distribution and uniqueness constraints unnecessary? The comment was in a reply to a comment from another person. There wasn't any mention of distribution and uniqueness constraints in the quoted text. Regards, -sm
Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
Dave, Just on this point: On 5/11/13 2:36 AM, David Conrad wrote: There isn't any mention of privacy [2] considerations in the draft. True. The document is documenting current practices and policies. At this point in time, I'm unaware of a global privacy practice or policy that is applicable to all levels of the Internet Numbers Registry System. It's probably worth saying that the various PDPs SHOULD address policy considerations. How they address them is a matter for them, individually. Eliot
Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
Uch... you can see where my head is: On 5/11/13 2:14 PM, Eliot Lear wrote: It's probably worth saying that the various PDPs SHOULD address policy considerations. How they address them is a matter for them, individually. s/policy considerations/privacy considerations/ Grr... Eliot
Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
Hi David, At 18:36 10-05-2013, David Conrad wrote: Sure, but it is also looking towards the remaining few IPv4 allocations that will be made over the next few years. I am looking at the draft from an IETF perspective. There is IPv4 address space for protocol assignments. It could be said that the IETF's role is limited to providing guidance on IP architectural and operational considerations (e.g. RFC 6177). Several years ago some RIRs adopted policies which were inconsistent with IAB/IESG recommendations. I suggest leaving IPv4 allocations unrelated to protocol assignments up to other communities to avoid further inconsistencies. The fact that the IPv6 address pool is very large does not remove the fact that it is a not an infinite resource and thus, constraints must be applied to allocation policy. The constraints are not set by the IETF. It's up to other communities to see what constraints, if any, should be applied. Lacking those constraints, I'm sure you or I could come up with an allocation policy that would blow through the IPv6 free pool quite quickly. To date, the communities Yes. I doubt that you or I would get away with it. :-) interested in IP addressing have established policies that dictate operational needs should be the primary constraint (as opposed to say constraining on geo-political boundaries, by ability to pay, etc). However, the second part of that sentence is saying that pool limitations at the time of allocation should also be taken into consideration. Since _at this time_ the IPv6 free pool is quite large, it would follow that allocation policy constraints would be minimal (as I believe they are). InternetNZ wrote a very good message, in my opinion, a few months to argue for the position it took on a proposal. It applied its principles to explain its position. I would like to look at this in terms of principles instead of politics. From the above I see that communities interested in IP addressing set the policy constraints, e.g. operational needs. If it's a policy it cannot be a principle. I'll suggest alternative text: 1) Allocation Pool: IP addresses and AS numbers are fixed length numbers. The allocation pools for these number resources are considered as resources which are finite. The principle for the above is to avoid set any constraint unless it is necessary for IETF protocols to work. True. The document is documenting current practices and policies. At this point in time, I'm unaware of a global privacy practice or policy that is applicable to all levels of the Internet Numbers Registry System. Is it up to the IETF to set up a one-stop shop for personal data requests? I suspect not, but I suspect it isn't up to the IETF to dictate global privacy policy either. Section 2 is about the goals for distributing number resources (re. first sentence). I suggest removing the third goal as it might be a matter of global (or other) policy. It also makes privacy a non-issue as there isn't any relationship between it and the goals. In Section 5: The discussions regarding Internet Numbers Registry evolution must also continue to consider the overall Internet address architecture and technical goals referenced in this document. I'll wordsmith this: It is expected that discussions regarding Internet Numbers Registry evolution will continue to consider the overall Internet address architecture and goals mentioned in this document. I removed the must. I noticed the following in Section 5: In addition, in the cases where the IETF sets technical recommendations for protocols, practices, or services which are directly related to IP address space or AS numbers, such recommendations must be taken into consideration in Internet Numbers Registry System policy discussions regardless of venue. The text does not add any value as must be taken into consideration does mean anything. The IETF publishes recommendations which people can elect to follow or ignore. If one believes that it is important to consider technical recommendations the person or organization can try and convince the appropriate venue to state that. Regards, -sm
Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
On 12/05/2013 03:17, SM wrote: ... The fact that the IPv6 address pool is very large does not remove the fact that it is a not an infinite resource and thus, constraints must be applied to allocation policy. The constraints are not set by the IETF. It's up to other communities to see what constraints, if any, should be applied. It's up to the IETF to set boundary conditions for the address space that it created (in the case of IPv6) or inherited (in the case of IPv4), in order to protect the long-term viability of the Internet. ... I'll suggest alternative text: 1) Allocation Pool: IP addresses and AS numbers are fixed length numbers. The allocation pools for these number resources are considered as resources which are finite. That doesn't set any boundary conditions beyond those imposed by mathematics, and is therefore a no-op. The mention of operational needs is a real boundary condition that makes it clear that address space is not to be wasted. As has been pointed out from time to time, it would be quite easy to design an allocation model, fully respecting the hierarchical constraint in the following guideline, that blows away galactic quantities of address space, even for IPv6. It is entirely appropriate for the IETF and IAB to write a goal that avoids this. The principle for the above is to avoid set any constraint unless it is necessary for IETF protocols to work. No IETF protocol will work if the address space is exhausted of if BGP4 runs out of steam or otherwise fails. The goals listed in Section 2 address that. ... Section 2 is about the goals for distributing number resources (re. first sentence). I suggest removing the third goal as it might be a matter of global (or other) policy. No, it's a necessity in order for the two preceding goals to be verifiably achieved, and to avoid accidental duplication of addresses. ... In Section 5: The discussions regarding Internet Numbers Registry evolution must also continue to consider the overall Internet address architecture and technical goals referenced in this document. I'll wordsmith this: It is expected that discussions regarding Internet Numbers Registry evolution will continue to consider the overall Internet address architecture and goals mentioned in this document. I removed the must. The must is necessary. I noticed the following in Section 5: In addition, in the cases where the IETF sets technical recommendations for protocols, practices, or services which are directly related to IP address space or AS numbers, such recommendations must be taken into consideration in Internet Numbers Registry System policy discussions regardless of venue. The text does not add any value as must be taken into consideration does mean anything. Er, it means what it says. It is exactly as powerful as any other must or even MUST written by the IETF. If you ignore it, your network might break. I think that the current wording of the draft is correct. Brian
Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
At 13:08 11-05-2013, Tom Vest wrote: Sorry, but unless you can point to some relevant real-world examples of self-executing, self-sustaining principles, or you're a nihilist and don't really believe that such things as principles exist at all, this is a patently false, bordering on nonsense statement. I am not suggesting any self-executing or self-sustaining principles. One is tempted to ask work for who? but that would entail giving this statement more credence that it merits. Since TCP/IP is only useful to the end of communication between two or more nodes, the proposed principle of finitude would perfectly consistent with this, and almost every other IETF addressing/attachment protocol *not* working at all. Or did you mean to say that The principle for the above is to avoid set any constraint unless it is necessary for IETF protocols to 'work' between two virtual machines, under lab conditions? What I meant was to leave policy (PDP, etc.) to the communities interested in IP addressing. I'll quote part of a message posted on the thread: 'To date, the communities interested in IP addressing have established policies that dictate operational needs should be the primary constraint (as opposed to say constraining on geo-political boundaries, by ability to pay, etc).' The message is at http://www.ietf.org/mail-archive/web/ietf/current/msg79200.html in case what I was quoted is misrepresented. At 13:14 11-05-2013, Brian E Carpenter wrote: It's up to the IETF to set boundary conditions for the address space that it created (in the case of IPv6) or inherited (in the case of IPv4), in order to protect the long-term viability of the Internet. There is some text about Internet address architecture. It would cover that if the relevant communities are agreeable to it. Regards, -sm
Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
At 16:06 16-04-2013, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The Internet Numbers Registry System' draft-housley-rfc2050bis-01.txt as Informational 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 ietf@ietf.org mailing lists by 2013-05-14. Exceptionally, comments may be This draft is well-written and it is a significant improvement compared to the previous version. In Section 2: As such, allocations must be made in accordance with the operational needs of those running the networks that make use of these number resources and by taking into consideration pool limitations at the time of allocation. The global IPv4 address pool is currently depleted. Two RIR regions are in IPv4 exhaustion phase. There is a proposal in the RIPE region to remove need [1]. I gather that this new version of the Internet Numbers Registry System looks towards a future where hosts are IPv6 accessible. Given that the free IPv6 address pool is very large and that IP addresses are not free, what is the rationale for keeping allocations in accordance with operational needs? Registration Accuracy: A core requirement of the Internet Numbers Registry System is to maintain a registry of allocations to ensure uniqueness and to provide accurate registration information of those allocations in order to meet a variety of operational requirements. There isn't any mention of privacy [2] considerations in the draft. Is it up to the IETF to set up a one-stop shop for personal data requests? Regards, -sm 1. https://www.ripe.net/ripe/policies/proposals/2013-03 2. http://lists.arin.net/pipermail/arin-ppml/2012-April/024596.html
Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
On May 10, 2013 11:51 AM, SM s...@resistor.net wrote: At 16:06 16-04-2013, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The Internet Numbers Registry System' draft-housley-rfc2050bis-01.txt as Informational 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 ietf@ietf.org mailing lists by 2013-05-14. Exceptionally, comments may be This draft is well-written and it is a significant improvement compared to the previous version. In Section 2: As such, allocations must be made in accordance with the operational needs of those running the networks that make use of these number resources and by taking into consideration pool limitations at the time of allocation. The global IPv4 address pool is currently depleted. Two RIR regions are in IPv4 exhaustion phase. There is a proposal in the RIPE region to remove need [1]. I gather that this new version of the Internet Numbers Registry System looks towards a future where hosts are IPv6 accessible. Given that the free IPv6 address pool is very large and that IP addresses are not free, what is the rationale for keeping allocations in accordance with operational needs? I disagree with need based assignment and believe this draft should remove all such language The need based policy is not equitable and is nothing but a drag in the post ipv4 exhaust world. I have made a case for moving away from need basis here, http://lists.arin.net/pipermail/arin-ppml/2013-April/026592.html The ietf should really take the time to review what the rirs have done and if their mandate needs to be updated. Ipv4 belongs to the market and ipv6 does not have scarcity issues. CB Registration Accuracy: A core requirement of the Internet Numbers Registry System is to maintain a registry of allocations to ensure uniqueness and to provide accurate registration information of those allocations in order to meet a variety of operational requirements. There isn't any mention of privacy [2] considerations in the draft. Is it up to the IETF to set up a one-stop shop for personal data requests? Regards, -sm 1. https://www.ripe.net/ripe/policies/proposals/2013-03 2. http://lists.arin.net/pipermail/arin-ppml/2012-April/024596.html
Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
SM, On May 10, 2013, at 11:40 AM, SM s...@resistor.net wrote: In Section 2: As such, allocations must be made in accordance with the operational needs of those running the networks that make use of these number resources and by taking into consideration pool limitations at the time of allocation. The global IPv4 address pool is currently depleted. The IANA IPv4 free pool is exhausted (well, modulo blocks of addresses returned to IANA), yes. Two RIR regions are in IPv4 exhaustion phase. There is a proposal in the RIPE region to remove need [1]. Yes. I gather that this new version of the Internet Numbers Registry System looks towards a future where hosts are IPv6 accessible. Sure, but it is also looking towards the remaining few IPv4 allocations that will be made over the next few years. Given that the free IPv6 address pool is very large and that IP addresses are not free, what is the rationale for keeping allocations in accordance with operational needs? The fact that the IPv6 address pool is very large does not remove the fact that it is a not an infinite resource and thus, constraints must be applied to allocation policy. Lacking those constraints, I'm sure you or I could come up with an allocation policy that would blow through the IPv6 free pool quite quickly. To date, the communities interested in IP addressing have established policies that dictate operational needs should be the primary constraint (as opposed to say constraining on geo-political boundaries, by ability to pay, etc). However, the second part of that sentence is saying that pool limitations at the time of allocation should also be taken into consideration. Since _at this time_ the IPv6 free pool is quite large, it would follow that allocation policy constraints would be minimal (as I believe they are). Registration Accuracy: A core requirement of the Internet Numbers Registry System is to maintain a registry of allocations to ensure uniqueness and to provide accurate registration information of those allocations in order to meet a variety of operational requirements. There isn't any mention of privacy [2] considerations in the draft. True. The document is documenting current practices and policies. At this point in time, I'm unaware of a global privacy practice or policy that is applicable to all levels of the Internet Numbers Registry System. Is it up to the IETF to set up a one-stop shop for personal data requests? I suspect not, but I suspect it isn't up to the IETF to dictate global privacy policy either. Regards, -drc
