Subject: [Gen-art] Gen-ART review of draft-ietf-crisp-iris-areg-12 - at Last Call

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 16 Sep 2005 15:23:50 +0200

Document: draft-ietf-iris-areg-12.txt
Reviewer: Harald Alvestrand
Date: Sept 16, 2005

Summary: This document seems to describe technology that is in good shape. 
The presentation could be improved.

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 <iris:lookupEntity>  . . . . . . . . . . . . .  15
   4.   Terminology for Nesting of Networks  . . . . . . . . . . . .  17

<other stuff deleted>

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 <language> 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  <ipv6Address> - same as <ipv4Address> 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  <findNetworksByNameServer>
>
>    The <findNetworksByNameServer> 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  <networkType> contains a string denoting the type of network.
>
>    o  <networkTypeInfo> is an entity reference to a definition of the
>       values explained in a plain natural language.  The referent MUST
>       be a <simpleEntity> 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 <networkTypeInfo> would clear this up entirely.

3.2.2:

>       *  <parent> contains an entity reference to the parent autonomous
>          system of this autonomous system.  The referent MUST be an
>          <autonomousSystem> (Section 3.2.2) result.
>
>       *  <noParent> signifies that this autonomous system as no parent
>          autonomous system.

Apart from the missing "h" in <noParent>, 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  <postalAddress> 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!

                          Harald

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art