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