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

[Brian Haberman <[e-mail]>]

Hi Geoff,
    Sorry for the delay.  These are useful comments and I have some
responses in-line...

On 6/25/15 7:57 PM, Geoff Huston wrote:
> 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.
> 

The epoch is defined within the confines of 5905, but doesn't apply to
the Timestamp format..  I will draft some text that articulates the
conversion methodology.

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

Agreed.  The NTP Date Format is more appropriate.  I will draft some
text discussing the use of the Date Format and representing it in ASCII.

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

Agreed.

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

The original thought between the authors was to normalize IPv4 addresses
to ensure consistent representation.  Having thought about this some
more, I believe we can accomplish that goal using RPSL's IPv4 address,
prefix, and range types.

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

Given the change proposed above...

> 
> a) the IPv4 address range 10.0.0.0 through to 10.0.2.255 ?

10.0.0.0/22 (<address-prefix> per RFC 2622).

> 
> b) the ASN range 131072 through to 131075

Several ways, but an as-block works well (as-block: AS131072 - AS131075,
per RFC 2725 and applying the ASPLAIN representation). It could also be
represented using as-list or as-set.  However, that would require
additional requirements that those attributes be signed as well.

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

First, I am going to assume that the last 16 bits are extraneous (unless
IPv6 addresses are now 144 bits long).

2001::/93.

Other examples that include hex digits need to apply the normalization
described in RFC 5952.

So, I think that one item that needs clarifying is the intent to re-use
RPSL attributes as much as possible and apply normalization where there
could be ambiguities.  That can be done in the intro.  I will add some
additional text to section 3 to clarify that the originator of the data
needs to pick the appropriate attributes to represent the data and
normalize the values as needed.

Thanks,
Brian