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: 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: draft-housley-rfc2050bis-01
On 4/8/13 13:45 , John Curran wrote: On Apr 8, 2013, at 9:06 AM, David Farmer far...@umn.edu wrote: 3. Regarding Public WHOIS in section 4; The constituencies and stakeholders for Public WHOIS are much broader than just the technical community, a number of constituencies in civil society have legitimate interests in Public WHOIS. I guess the main point I'm trying to make is that Public WHOIS is more than just a technical issue, and section 4 seems to scope it as solely a technical issue. It's definitely a bigger issue, but it does not seem appropriate in an IETF document to assert points about all aspects of the issue, but instead better to just note the _technical considerations_ of the topic that are needed to keep the Internet running. I don't think you need to refocus section 4 from Technical Considerations I think simply recognizing that there are more than just technical considerations, especially for Public WHOIS, something like the following should be sufficient; 2) ...have included consideration of the technical and operational requirements, as well as requirements of other stakeholders, for supporting WHOIS services... This text would be the authors asserting that these requirements (those of other stakeholders of Whois) have been considered, and yet there are wide range of non-technical aspects to Whois that quite probably have not been fully considered; e.g. issues similar to those in various ongoing discussions of DNS Whois at ICANN this week... The section is about the _technical considerations_ that have been considered in establishment of the Internet Numbers Registry System, and to change the text as you suggest would significantly expand its scope into areas not currently addressed in the text and not typical of other IETF documents, i.e. problematic. You are probably right, but the first paragraph of section 4 says; As a result of the system of technical standards and guidelines established by the IETF as well as historical and operational constraints, there have been technical considerations regarding the services provided by the Internet Numbers Registry System as it evolved. These technical considerations have included: Specifically where it says as well as historical and operational constraints seems to open the door for what I'm talking about. The way it is written, the historical and seem to stand apart from, separate from, or in addition too, the technical standards and guidelines of the IETF. Historical constraints is rather broad and could easily include non-technical considerations. Which the issues of broader society and Public WHOIS are certainly some of the historical non-technical considerations. So I'd suggest that paragraph should get some work, to better represent the intent you have stated for this section. I suggest the following text, based on my interpretation of what you are saying. I feel it better constrains the discussion to the technical domain. In particular changing historical and operational constraints to something like historic operational practices. As a result of the system of technical standards and guidelines established by the IETF, as well as historic operational practices of the Internet community, there are technical considerations regarding the services provided by the Internet Numbers Registry System, these included: 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: draft-housley-rfc2050bis-01
On 4/7/13 20:34 , Russ Housley wrote: Many of the comments that were posted to this list have been incorporated. Please comment on the updated document. 1. Section 6 and the last paragraph of section 1 are mostly duplicative, I'd suggest eliminating section 6 and merging it into the last paragraph of section 1. In particular the part and omits policy and operational procedures that have been superseded by ICANN and RIR policy since RFC 2050 publication. That is the only thing in section 6 that isn't already in the last paragraph of section 1. Unless you have plans to dramatically increase whats in section 6. 2. Also, the references for RFC 1366 and RFC 1466 are missing. 3. Regarding Public WHOIS in section 4; The constituencies and stakeholders for Public WHOIS are much broader than just the technical community, a number of constituencies in civil society have legitimate interests in Public WHOIS. I guess the main point I'm trying to make is that Public WHOIS is more than just a technical issue, and section 4 seems to scope it as solely a technical issue. I don't think you need to refocus section 4 from Technical Considerations I think simply recognizing that there are more than just technical considerations, especially for Public WHOIS, something like the following should be sufficient; 2) ...have included consideration of the technical and operational requirements, as well as requirements of other stakeholders, for supporting WHOIS services... Other stakeholders are recognized in general in section 5, but this is a little different, this is recognizing while Public WHOIS is a technical issue, it is more than just a technical issue. Whereas Reverse DNS is almost entirely a technical issue. 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: Please review draft-housley-rfc2050bis-00.txt
On 3/20/13 14:04 , John Curran wrote: On Mar 19, 2013, at 9:30 PM, David Farmer far...@umn.edu wrote: I wonder if it wouldn't be appropriate to at least provide some suggestions for how this is to be accomplished. Maybe request that future RFCs related to these technical and operational considerations include an applicability statement as to the Internet Numbers Registry System, either in a separate section or maybe as a sub-section of the IANA Considerations. This evolution is discussed in Section 4. Maybe a forward pointer is needed. Did you not find Section 4 sufficient? I saw that, it says; 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. This is good, but I read it as saying the IR system, and the RIR's in particular, are obligated to consider the technical recommendations of the IETF when making policy. That is only part of the equation. I was looking for the other side, the IETF is obligated to maintain clear, relevant, and up to date technical recommendations for the IR system, including how such recommendations are intended to apply to the IR system. David - Two points: 1) Language along the lines of the IETF is obligated to ... really isn't going to work, as the point of the RFC2050 revision is to document existing relationships supporting the Internet Numbers Registry System, using pointers to existing source documents to the greatest extent possible. Even if there were 100% agreement to the concept, it would not be appropriate to establish it via this document which is intended for Informational publication. xxx is obligated to ... wasn't intended as a suggestions for text, but like I paraphrased the text from the draft above, and I intended it to paraphrase the the text that needs to be added. The text above quoted from the draft such recommendations must be taken into consideration... and I agree with that. I'll note the care in how it is worded, but it seems to flow only IETF to IR Sys 2) More importantly, who is the IETF in such a construct? Would such a task (of periodically pondering if these recommendations need updating) fall to the IAB or IESG? (I hadn't realized that they needed extra work... ;-) I believe that when you consider that we each individually are the IETF (i.e. all of the folks who participate in the working groups and writing drafts) then it is clear that any obligation to update these technical recommendations periodically would fall to those with an interest in keeping them current. You might even say that's what Russ, David, Geoff, and I are finally getting around to doing via this draft, at least for one of the key documents. FYI, /John Disclaimers: My views alone. If you are reading this email long after publication, this email may be out-of-date and I do not commit to updating its contents. ;-) -- 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: Please review draft-housley-rfc2050bis-00.txt
Whops, that escaped. Sorry. Lets start over. On 3/20/13 15:51 , David Farmer wrote: On 3/20/13 14:04 , John Curran wrote: On Mar 19, 2013, at 9:30 PM, David Farmer far...@umn.edu wrote: I wonder if it wouldn't be appropriate to at least provide some suggestions for how this is to be accomplished. Maybe request that future RFCs related to these technical and operational considerations include an applicability statement as to the Internet Numbers Registry System, either in a separate section or maybe as a sub-section of the IANA Considerations. This evolution is discussed in Section 4. Maybe a forward pointer is needed. Did you not find Section 4 sufficient? I saw that, it says; 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. This is good, but I read it as saying the IR system, and the RIR's in particular, are obligated to consider the technical recommendations of the IETF when making policy. That is only part of the equation. I was looking for the other side, the IETF is obligated to maintain clear, relevant, and up to date technical recommendations for the IR system, including how such recommendations are intended to apply to the IR system. David - Two points: 1) Language along the lines of the IETF is obligated to ... really isn't going to work, as the point of the RFC2050 revision is to document existing relationships supporting the Internet Numbers Registry System, using pointers to existing source documents to the greatest extent possible. Even if there were 100% agreement to the concept, it would not be appropriate to establish it via this document which is intended for Informational publication. xxx is obligated to ... wasn't intended as a suggestions for text, but like I paraphrased the text from the draft above, and I intended it to paraphrase the the text that needs to be added. The text above quoted from the draft ...such recommendations must be taken into consideration... and I agree with that. I'll note the care in how it is worded, but it seems to flow only from IETF to IR System. Maybe I'm just being overly sensitive to the must in ...such recommendations must be taken into consideration But, it seems to me that this says IR System must defer judgements on technical issues to the IETFs technical recommendations, even if they are old, crufty, and been left in dust by the march of technology. 2) More importantly, who is the IETF in such a construct? Would such a task (of periodically pondering if these recommendations need updating) fall to the IAB or IESG? (I hadn't realized that they needed extra work... ;-) I believe that when you consider that we each individually are the IETF (i.e. all of the folks who participate in the working groups and writing drafts) then it is clear that any obligation to update these technical recommendations periodically would fall to those with an interest in keeping them current. You might even say that's what Russ, David, Geoff, and I are finally getting around to doing via this draft, at least for one of the key documents. This is a common problem of community based, we are them they are us, type pseudo-organizations. FYI, /John Disclaimers: My views alone. If you are reading this email long after publication, this email may be out-of-date and I do not commit to updating its contents. ;-) All I ask is you admit you changed you mind, you have the right to do that. But, when the IETF changes it's mind by changing its consensus, then it needs to deprecate its old technical recommendations, or make sure everyone else is free to ignore the recommendations. -- 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: Please review draft-housley-rfc2050bis-00.txt
of the Internet registry system out of the Introduction. The Intro starts out talking about the document, its goals, and what is in scope and out of scope of the document. Then transitions to talking about the goals of the Internet registry system. I think the goals of the Internet registry system should be a separate section from the Introduction. And, the Introduction should be expanded to better describe the purpose of the document. 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: Please review draft-housley-rfc2050bis-00.txt
1) In Section 1, goal #2, Hierarchical Allocation, I believe a reference the definition in RFC 5226 - Section 4.1. Well-Known IANA Policy Definitions, should be considered. 2) I also wonder if another appropriate goal would be explicitly defining the ASN and IP address registries using RFC 5226 language including the formal linkage to ICANN and the RIRs as the mechanism for IANA to implementing the Hierarchical Allocation of these registries. See: RFC 5226, section 4.3. Updating IANA Guidelines for Existing Registries The intention wouldn't be to override RFC 2860, ICANN Policy, or IR global policy, but to provide and explicit formal technical definition for these registries that really have only been implicitly defined to date as far as I can tell. There are any number of other registries that are far less important overall, that have excellent formal technical definitions that comply with RFC 5226 or its predecessors. However, these our most important registries have no such formal technical definitions, I think its really time to fix this situation. That said, to the greatest extent possible we need a formal technical definition compliant with RFC 5226 of the as-is-state, not of the want-it-to-be-state. Or, if I'm incorrect and there are formal technical definitions for these registries that comply with RFC 5226, or its predecessors, then they should be referenced in this document. 3) The last paragraph of Section 3, Internet Numbers Registry Technical Considerations Says; As the Internet and the Internet Numbers Registry System continue to evolve, it may be necessary for the Internet community to examine these and related technical and operational considerations and how best to meet them. I wonder if it wouldn't be appropriate to at least provide some suggestions for how this is to be accomplished. Maybe request that future RFCs related to these technical and operational considerations include an applicability statement as to the Internet Numbers Registry System, either in a separate section or maybe as a sub-section of the IANA Considerations. On 3/16/13 17:13 , Russ Housley wrote: A new, I-D, draft-housley-rfc2050bis-00.txt, has been posted. I am writing to ask for your review. Russ -- 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
