Re: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT)

[Andy Newton <[e-mail]>]

On Oct 29, 2014, at 2:47 PM, Ted Lemon <[e-mail]> wrote:

> Point 1:
> 
> In section 3.1.1, it's not clear which of three alternative things you
> may have been specifying: (1) the ASCII representation of the IP address
> is intended to be converted to binary before use, (2) the ASCII
> representation is intended to be used directly, or (3) whether the IP
> address is converted to binary prior to use is an implementation choice. 
> If (1) is what's intended, you should say so explicitly.   If either (2)
> or (3) is intended, then the representation that's used needs to be in
> some canonical form, and the text as written does not ensure that it will
> be.
> 
> So to address this discuss, you should either update the text to say that
> (1) is what's intended, and it won't work otherwise, or you need to
> require, not suggest, a canonical representation.   If you go with the
> second option, your reference to RFC 5952 isn't adequate: you need to
> specifically reference section 4, and specifically exclude section 5.   I
> have no preference as to how you resolve this.

It is option 3. However, the implementer wishes to construct a database is up to the implementer. They need to be able to parse IPv6 addresses and use them to construct whatever key their database uses, be it textual or binary. Having implemented both forms, you cannot simply take the textual representation and use that as a key.

All that being said, I don’t understand the suggested fix. Section 5 of RFC 5952 is about IPv4 embedded addresses in IPv6 addresses. But they are different addresses. There is no collision so the need for canonicalization isn’t obvious. Cutting embedded-IPv4 addresses does make implementation easier, and I don’t think anybody would actually care if they were explicitly forbidden.


> In 3.2.1 and 3.2.2, the main use cases I can see for nameserver searches
> are for spammers to identify related domains, and for eavesdroppers to do
> the same.   What's the motivation for including these capabilities?   At
> a minimum, the privacy considerations for this search ought to be
> discussed in a privacy considerations section or in the security
> considerations section.

Nameserver searches return nameserver objects. I don’t know how useful that would be a to a spammer, but to a nameserver operator trying to determine which registrations are pointing to their nameserver, that seems useful.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Point A:
> 
> In 3.1.2:
> 
>   For example, the following URL would be used to find information
>   describing autonomous system number 12 (a number within a range of
>   registered blocks):
> 
>   http://example.com/rdap/autnum/12
> 
>   The following URL would be used to find information describing 4-byte
>   autonomous system number 65538:
> 
>   http://example.com/rdap/autnum/65538
> 
> The examples don't really seem to illustrate what is said in the text.  
> The syntax for both examples is the same, and we don't see any return
> results.   So to say that one example is an example of a number within a
> range of registered blocks, while the other is a 4-byte number, doesn't
> make sense because the query formats are identical.   The preceding text
> is clear, if I understand it correctly: a number in the path element
> following 'autnum' is an autonomous system number, which references a
> block of one or more numbers.   If there are additional semantics, e.g.,
> byte size boundaries for AS numbers, that are also encoded in the query,
> those should be described explicitly.   But IMHO that doesn't make sense:
> in _this_ context, these are just decimal numbers of arbitrary precision,
> and how many bytes they are, or whether any particular number references
> a block or just a single number, is not something that should be
> mentioned in the examples.

Those examples seem far away from that reference to ASPLAIN and RFC 5396. The point is: don’t do ASDOT… which is an issue for 4-byte as numbers. We should probably actually say that, and split apart the first paragraph to put the examples closer to it.

-andy