On Mar 20, 2013, at 8:45 PM, SM <sm@xxxxxxxxxxxx> wrote: > Ok. I'll defer to the learned individuals of the IETF in respect > to the intended status. It is my understanding that the document > also aims to replace BCP 12. Excellent question; it's my belief that obsoleting RFC2050 would do that, but perhaps it would be best to make that point more specific in this document? > I can only say that in my opinion the omission of the finer details > does not have any negative consequences for the RIRs. IN-ADDR maintenance is explicitly in RFC 2050, and has not been overtaken by events to my knowledge, hence it is included in this successor document. > "Per the delineation of responsibility for Internet address policy > issues specified in the IETF/IAB/ICANN MOU [RFC2860], discussions > regarding the evolution of the Internet Numbers Registry System > structure, policy, and processes are to take place within the ICANN > framework and will respect ICANN's core values [ICANNBL]." > > How does the above affect the IETF, e.g. what process changes happened between RFC 2050 and draft-housley-rfc2050bis-00? Why is it even relevant to the IETF? The IETF/IAB signed an MOU with ICANN for performance of certain IANA tasks, including a framework which recognized that ICANN would be dealing with policy issues related to the domain name system and the IP address system. At the same time, the Regional Internet Registries worked with ICANN to perform the community- based regional and global IP policy development coordinated with ICANN's overall framework. This is clearly a different way of establishing IP address policy than described in the current RFC2050, and hence material to the IETF. > "These core values encourage broad, informed participation reflecting > the functional, geographic, and cultural diversity of the Internet at > all levels of policy development and decision-making, as well as the > delegation of coordination functions and recognition of the policy > roles of other responsible entities that reflect the interests of > affected parties." > > I do not understand what the above means in practice. There are lots of folks over in the DNS world wondering that same question... ;-) Seriously, one could write volumes about ICANN, its structure, processes oversight role, etc., but at the end of the day you'd be creating a fixed copy of what is an evolving organization. The IETF does not decide today when and which new top-level domains are added to the DNS root, that is an example of a question which requires "broad, informed participation reflecting the functional, geographic, and cultural diversity of the Internet at all levels of policy development and decision-making." > "The discussions regarding Internet Numbers Registry evolution must > also continue to consider the overall Internet address architecture > and technical goals referenced in this document." > > After reading draft-housley-rfc2050bis-00 it is my understanding that the Internet Numbers Registry is out of scope for the IETF. I read the above as meaning that the IETF is telling RIRs and ICANN that they must also follow technical guidance from the IETF in respect to the Internet address archtecture. The IETF defines the architecture of the Internet Protocol, and this includes the IP address space. Regardless of whether policy development has been delegated to the RIRs under the ICANN framework, the address architecture is still established by the IETF. > "The foregoing does not alter the IETF's continued responsibility for > the non-policy aspects of Internet addressing such as the architectural > definition of IP address and AS number spaces and specification of > associated technical goals and constraints in their application, assignment > of specialized address blocks, and experimental technical assignments as > documented in RFC 2860." > > The above sounds like something from the legal department. I unfortunately cannot hire a lawyer to tell me whether that text matches the text in RFC 2860. I don't see how one can expect informed participation when the text to be read might be unclear to the people from the rest of the world. To my knowledge, it does correctly represent the terms in RFC 2860, but I understand that the language is rather dense and may be hard to parse. We do not want to repeat the entirety of RFC 2860 here, but it is useful for readers to know that per that MOU, there is a has a delineation of responsibilities between the IETF and the ICANN/RIR system. > By the way I read my previous message [1] again and the reply [2] I received and I noticed that there wasn't any response to two of the questions. Agreed. I commented on those aspects where my remarks may add value to the discussion; there are others on this list with greater experience and knowledge which may help with other questions you have raised. Thanks for the feedback - I hope I've helped explain at least some of the reasoning behind the language in the draft. /John Disclaimer: My views alone.