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