thanks Brian, Just a couple of minor pickups left : …
>> 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). > that address range encompasses 3 x /24s 10.0.0.0/24, 10.0.1.0/24 and 10.0.2.0/24 so that list is one alternative a second alternative is the list 10.0.0.0/23, 10.0.2.0/24 a third alternative is the address range 10.0.0.0- 10.0.0.2.255, but thats not CIDR So this intent is to define a single cononical representation that allows rapid comparison, right? so you either use CIDR and allow for a list, or you revert to a range presentation and refer to start and finish addresses. But either way you need to clarify how to reer to ranges that are not conveniently aligned into a single CIDR boundary >> >> 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. right - how to represent a range of AS’s is the underlying question here. > >> >> 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. > the problem here is that the start of this block is not 2001:0:0:0:0:0:0:0, but 2001:0:0:0:0:2:0:0 so once more this is a range of addresses not a single CIDR prefix. What is the proposed canonical representation of this range of addresses? > 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. > yep - RFC3779 did that already, and you may want to use that canonical representation without the ASN.1 goop and use ascii instead, or you may have another preferred canonical format, BUT it is essential that the spec clearly and unambigously delas with address ranges. (You may also want to consider discontiguous address ranges - I dunno if they exist in the route registries, but if they do then its in scope here) Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
