Re: [sidr] WGLC: draft-ietf-sidr-rpsl-sig - End Jul 02 2015

[Brian Haberman <[e-mail]>]

Hi Geoff,
     Thanks for the review.  Some responses in-line...


On 6/23/15 10:26 PM, Geoff Huston wrote:
> section 3.1, bullet 4 - s/notaion/notation/

Will fix.

> 
> Bullet 4 of this list looks confused
> 
> * Date and time fields MUST be converted to 64-bit NTP Timestamp Format [RFC5905].
> 
>      thats a binary value, 32 bits of seconds since epoch and 32 bitss of fractions - right?

In the code I wrote a few years ago, I convert the timestamp to an ascii
string representation. Some of the conversion logic is in 5905 and the
rest is based on the C libraries for managing time.

>      Does this also mean that the Era is 1 January 1900?

Yes, it does... and that may be a problem in 21 years. Changing this to
the 128-bit Date Format from 5905 doesn't appear to be an issue.  When I
get some time in the next few days, I will update my prototype code and
test it out.

> 
> *  AS numbers MUST be converted to ASPLAIN syntax [RFC5396].
> 
>      hang on - thats ascii - why is the time field binary and this field ascii?

As noted above, the time is converted to ASCII.

> 
> *  IPv6 addresses must be canonicalized as defined in [RFC5952].
> 
>      this is also ascii 

Yes.

> 
> *  IPv4 addresses MUST be converted to a 32-bit representation
>           (e.g., Unix's inet_aton()).
> 
>      inet_aton returns a binary struct - which is NOT ascii. 
> 

But can be converted to the ASCII representation of the 32-bit number.
I will update the draft to be explicit about that.

>     
> *  All IP prefixes (IPv4 and IPv6) MUST be represented in CIDR
>           notaion [RFC4632].
> 

Yes, as described in RPSL (RFCs 2280 and 2622).

> 
>      I assume that this means that at times this will be a list of addresses
>      (i.e. the range of addresses 10.0.0.1 - 10.0.0.2 is 10.0.0.1/32 and 10.0.0.2/32)
> 
>      Are you wanting a cononical CIDR form? (i.e. should the pair of prefixes 10.0.0.0/24 and 10.0.1.0/24
>      be represented as 10.0.0.0/23?)
> 
> 
>      Other RPKI specs (e.g. RFC6487) referenced the canonical representation of a
>      set of addresses as defined in RFC3779. I assume you had a good reason not to
>      use the same approach
> 

The 3779 approach moves away from the RPSL representation of prefixes.
Introducing ASN.1-based representations to RPSL seems... odd.

Regards,
Brian