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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
