Draft: draft-ietf-crisp-iris-areg-12.txt Reviewer: Harald Tveit Alvestrand [harald@alvestrand.no] Review Date: Sept 16, 2005 LC Date: Sept 21, 2005 Summary: This document seems to describe technology that is in good shape. The presentation could be improved. Review: -------- Details on presentation: The high level content of the document is as follows: 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Document Terminology . . . . . . . . . . . . . . . . . . . . 5 3. Schema Description . . . . . . . . . . . . . . . . . . . . . 6 3.1 Query Derivatives . . . . . . . . . . . . . . . . . . . . 6 3.2 Result Derivatives . . . . . . . . . . . . . . . . . . . . 11 3.3 Support for . . . . . . . . . . . . . 15 4. Terminology for Nesting of Networks . . . . . . . . . . . . 17 The problem I have with this layout is that it never gets around to specifying what an address registry actually is, and how it is structured. I found this reasonably readily apparent from reading section 3.2 and 4 - but others might not; I've found from the way people's eyes glaze over when they read MIBs that not everyone can read a data definition and infer the structure of the database it describes. A short description, somewhat like: An address registry stores information about: - Address ranges - AS number ranges - Maintainers - Organizations - Nameservers AS number ranges can contain other ranges; address ranges can contain other address ranges. Address ranges and AS number ranges can refer to maintainers and organizations, but do not contain them. Organizations can refer to maintainers. And something about nameservers.... I think that's actually enough of a description.... if I got it wrong, it argues strongly that it's needed; if I got it right, it is just nice to have.... Details that might be worth looking at (but not important enough to hold back the document if they're a hassle to fix): Intro: > This schema and registry type are provided to > demonstrate the extensibility of the IRIS framework beyond the use of > domains, a criteria defined in CRISP [4]. If it's a technology demonstrator, it should not be going for PS. If you delete "are provided to", the sentence changes to just be praise for the extensibility of the CRISP framework. If you add "The schema given is intended for use by address registries to provide in a structured way the information currently provided by WHOIS", I'd be even more happy..... 3.1: > > > This query also provides optional elements containing > language tags. Clients MAY use these elements to give a hint about > the natural language(s) of the affected element. Servers MAY use > this information in processing the query, such as tailoring > normalization routines to aid in more effective searches. As a language-tag person, I don't understand what "the affected element" refers to. It MAY mean "the element in the same sequence as the language element", or "all elements inside the findByName element", or something else. An interpretation unlikely to be correct is that in the case of multiple matching elements in the set of possible return values that differ by their "xml:lang" attribute, the client wants only the return values that have the same "xml:lang" attribute. But since "affected" isn't bound properly.... (also - this is a repeated element in multiple descriptions. I *really* dislike this form of boilerplate repetition, since it provides a fertile breeding ground for small differences that either don't matter or really, really matter..... I'd prefer it to be factored out and said ONCE). 3.1.4: > Clients > MUST convert any short-form notation ot the fully-qualified > notation. apart from the speling eror - what is "the fully-qualified notation"? My first guess is that it's the "dotted-quad" format - but there exist notations that also allow such numbers as 1.4.2341 (16-bit "host number"). > o - same as but the child addresses > contain IPv6 addresses. Clients MUST convert any short-form > notation to the fully-qualified notation. Same comment here - does it mean expanding FF02::1 to FF02:0000:0000:0000:0000:0000:0000:0001 or to FF02:0:0:0:0:0:0:1? Or is FF02::1 OK? 3.1.6 specifies "specificity" for AS number ranges. Is this exactly the same concept as for address ranges? Do you say so? > 3.1.8 > > The element allows a search for IP > networks based on their associated name servers. I had a little heartburn over "associated" until I managed to realize that this is the reverse-mapping servers (in-addr.arpa / ip6.arpa). Might be nice to say so. 3.2.1: > o contains a string denoting the type of network. > > o is an entity reference to a definition of the > values explained in a plain natural language. The referent MUST > be a as defined by [2]. After a little head-scratching, I thought that "the values" referred to "the possible values for networkType". I'm not entirely sure what an "entity reference" is - if this had been SGML, it would have been something like "&entityidentifier;". But I think not. Providing an example with would clear this up entirely. 3.2.2: > * contains an entity reference to the parent autonomous > system of this autonomous system. The referent MUST be an > (Section 3.2.2) result. > > * signifies that this autonomous system as no parent > autonomous system. Apart from the missing "h" in , I was a bit thrown off by the reference to "autonomous system" here rather than "autonomous system range" - I started wondering whether you were referring to some representation of some business relationship between AS owners, but then concluded that it was more likely that the word "range" was missing. 3.2.3: > o contains a information for reaching the contact > via postal mail. It is composed of the following child elements: The elements that follow are neither consistent with the elements given in draft-ietf-geopriv-dhcp-civil, nor are they chickening out on the nightmare of postal addresses and saying "six lines of no more than 40 characters" like the UPU does. Reason to believe this particular combination works? In section 7.3, it would be nice to have an example of the URI that is going to be resolved. It may be obvious to those well versed in IRIS, but it's not obvious to me..... Kudos: If anyone doesn't get the concept of specificity for network address searches after reading Appendix B, they're not ever going to get it!