Mahesh:
Thanks for gathering the open issues. A few have my name on them.
> > ### Section 3.2
> >
> > Except for the first sentence, all the rest of this section appears to work
> > only with CGN and not proxies. Please clarify that this is also applicable
> > to
> > proxies.
>
> We'll add a general statement that all statements about CGN in this
> document also apply to proxies.
>
> Did Russ confirm these observations?
This is not the part that I worked on. I leave this to my co-authors.
> > Why restricting to only unsigned files `When reading data from an unsigned
> > prefixlen file, one MUST ignore data outside the referring inetnum: object's
> > address range.` ? I do not see why signed files can escape this common sense
> > check.
>
> This is implicitly done as the signature won'T be valid for address
> ranges outside the address range.
>
> @Russ can you confirm this?
I agree that this check could be done whether the prefixlen file is signed or
not. However, the RPKI certificate will not be authorized for addresses that
are outside the range.
> > ### Section 6
> >
> > Why using an IP address range rather than the usual prefix notation used
> > through all this I-D in `The RPKI Signature's IP address range MUST match
> > that
> > of the prefixlen URL in the inetnum: that points to the prefixlen file.` ?
>
> @Russ I defer to you on this one.
I think this is just a matter of field names. In RFC 3779, the structure for
the RPKI is specified, For address blocks, it uses this ASN.1 structure:
IPAddressOrRange ::= CHOICE {
addressPrefix IPAddress,
addressRange IPAddressRange }
IPAddressRange ::= SEQUENCE {
min IPAddress,
max IPAddress }
I believe that wording is intended to deal with both of the alternatives (the
CHOICE in the structure). If some other words would be more clear, I'm not
opposed to a change.
Russ
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
