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

[Geoff Huston <[e-mail]>]

Thanks for the responses Brian. Some followup responses interleaved with your text follow.



>     Thanks for the review.  Some responses in-line...
> 
> 
> On 6/23/15 10:26 PM, Geoff Huston wrote:
>> 
>> 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.


So the document needs to define the epoch and the exact method of encoding to ascii I would’ve thought.


> 
>>     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.

code is good. A clear unambiguous spec is also good!


> 
>> 
>> *  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.


Better if the document makes this clear.


> 
>> 
>> *  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.


explicit is good - but why not use dotted quad notation?


> 
>> 
>> *  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.
> 


so I think we are talking past each other.  Lewt me try to explain myself with a simply question

How should I represent the following ranges of number resources in a canonical format according to this draft?

a) the IPv4 address range 10.0.0.0 through to 10.0.2.255 ?

b) the ASN range 131072 through to 131075

c) the IPv6 range 2001:0:0:0:0:2:0:0:0 through to 2001:0:0:0:0:5:ffff:ffff:ffff


Geoff




> Regards,
> Brian
> 
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr