On 2015-07-16 07:09, Sandra Murphy wrote: > Could you please respond to the list and say whether the > draft-ietf-sidr-rpki-rtr-rfc6810-bis-04.txt version satisfies your > comments? It would help the process.
Not all of them, and I noticed some new (mostly minor) issues in -04. I sent a new round of comments to the authors off-list, and they replied saying they'll take a look after the Prague busyness subsides. I'll report my comments to the list after the authors and I have had a chance to discuss them. -Richard > > --Sandy > > On Apr 16, 2015, at 12:37 AM, Richard Hansen <[email protected]> wrote: > >> Hi all, >> >> Here are my comments, some of which overlap with what others have said: >> >> * The name of the draft says "rfc6810-bis", but the XML <rfc> tag >> doesn't have an obsoletes="6810" attribute. And I don't think it >> should -- Section 7 has a normative reference to RFC6810 when >> discussing downgrades to version 0, which isn't specified in this >> document. So perhaps the title and abstract should be worded to >> make it clear that this is not a replacement for RFC6810, but >> rather a new version of the protocol specified in RFC6810. (Or >> maybe this document should be worded as an update to RFC6810?) >> (Also mentioned in <http://article.gmane.org/gmane.ietf.sidr/6871>.) >> >> * The protocol is mostly query-response lockstep, but there are no >> timeouts. If the cache is taking unreasonably long to respond to a >> query, what should the router do? How long is unreasonably long? >> If timeouts are added, should the router reset its timeout timer >> for each response PDU (Cache Response, payload, and End of Data), >> or only after it receives the End of Data PDU? >> >> * Should the cache time out the router if the router doesn't send a >> Query soon after connecting? >> >> * Notify/Query race: What is supposed to happen if the router sees a >> Serial Notify right after it sends a Serial Query or Reset Query? >> This could happen if the two are sent at the same time -- the >> messages will cross paths and the router might think that the >> Serial Notify is an erroneous response to the query, and that the >> subsequent Cache Response came out of the blue. >> >> * The name "Session ID" is misleading. Section 2 clearly defines it, >> but unless you pay attention to the definition it's easy to assume >> that "session" refers to the transport session with the peer. I >> would prefer a different name such as "Cache Instance ID", though >> that name may be insufficient when you consider the protocol >> upgrade problem brought up by David in >> <http://article.gmane.org/gmane.ietf.sidr/6896>. Maybe something >> like "Data Series ID"? >> >> * In Section 5.1 (fields) under "Session ID", what is the definition >> of "completely drop the session"? Do you mean send a fatal error >> PDU, do a transport-layer disconnect, and let the router reconnect >> (possibly to a more preferred cache)? Or do you mean send a Cache >> Reset (cache->router) or Reset Query (router->cache) and continue >> the existing transport session? Or is either reaction acceptable? >> >> * What is the definition of "payload PDU", mentioned in Sections 5.3, >> 5.5, 8.1, 8.2, and 8.3? (I assume it means IPv4 Prefix, IPv6 >> Prefix, and Router Key, but it should be explicitly stated.) >> >> * Suppose an IPv4 Prefix was announced in serial 5 and withdrawn in >> serial 6, and a router does a Serial Query against serial 4. Is >> it OK if the cache elides the announce/withdraw pair? MUST it? If >> it doesn't, it seems like the cache MUST send the payload PDUs in >> serial number order, and the router MUST process the payload PDUs in >> serial number order (which implies that the transport MUST provide >> in-order delivery of the PDUs because the router has no idea which >> PDUs correspond to which serial number). >> >> * Section 5.1 (fields) says that the serial number is the serial >> number of the cache, but Section 5.3 (Serial Query) talks about >> serial numbers as if they are properties of a PDU. Perhaps 5.3 >> should be worded like: >> >> The router sends a Serial Query to ask the cache for the >> announcements and withdrawals that have occurred since the >> Serial Number in the Serial Query. >> >> Section 5.5 (Cache Response) has similarly problematic wording. >> >> * The two sentences in 5.3 (Serial Query) paragraph 2 seem to >> contradict each other in the case where there are no (net?) >> changes: The first sentence suggests that the cache sends a Cache >> Response (maybe followed by something?), while the second suggests >> that it only sends an End of Data (no Cache Response). I think the >> intention is for the cache to send a Cache Response immediately >> followed by an End of Data. Is that correct? >> >> * I don't think the set of valid responses to a Query (Reset or >> Serial) is clearly specified. I think the intention is for these >> to be the only valid responses: >> >> - Reset Query: >> * Cache Response followed by 0 or more payload PDUs followed >> by End of Data >> * Error Report >> - Serial Query: >> * Cache Response followed by 0 or more payload PDUs followed >> by End of Data >> * Error Report >> * Cache Reset >> >> Is this correct? >> >> * Is there a particular reason for omitting a payload PDU count field >> from the Cache Response PDU? If one was present, the router could >> pre-allocate an appropriate amount of memory to handle the payload >> PDUs (and perform additional sanity checks). >> >> I guess a PDU count field would prevent an implementation from >> opportunistically sending additional PDUs if there happened to be a >> serial number bump during the middle of a Cache Response. >> (Instead, the cache would have to follow the End of Data PDU with a >> Serial Notify, which is almost as good.) >> >> * Section 5.6 (IPv4 Prefix) mentions duplicates, but are redundant >> entries OK? Examples: >> - {65536,192.0.2.0/24-26} and {65536,192.0.2.0/26-26} (the latter >> is redundant) >> - {65536,192.0.2.0/24-26} and {65536,192.0.2.0/24-25} (the latter >> is redundant) >> >> * The fixed-length SKI field doesn't permit algorithm changes. Note >> that there has been some discussion about using SHA-256 for the SKI >> and AKI fields for the RFC6487(bis) profile (I'm guessing that's >> probably not going to happen, but still...). >> (Also mentioned in <http://article.gmane.org/gmane.ietf.sidr/6869>.) >> >> * Section 5.11 (Error Report) says that Error Reports are only sent >> as responses to other PDUs. Why the restriction? This prevents a >> side from raising a timeout error, and it prevents the cache from >> raising an internal error if a problem is detected when it's time >> to send a Serial Notify. >> >> * If error reports are only sent as responses to other PDUs, how is >> it possible for an Error Report to not be associated with the PDU >> to which it is responding? (Section 5.11 paragraph 4) >> >> * For version negotiation, what is supposed to happen if the router >> starts with a PDU with version > 1? There is an Unsupported >> Protocol Version error type, but nothing requires that to be sent. >> >> * Suppose a router connects and issues a v0 Query. If the cache >> doesn't support protocol v0, Section 7 says it MUST either >> downgrade or disconnect. Can it issue an Error Report before >> disconnecting? I would prefer it if the server MUST issue an >> Unsupported Protocol Version Error Report before disconnecting. >> >> * The second-to-last paragraph of Section 10 talks about deleting >> data from a cache when it has been unable to refresh from that >> cache for twice the polling period (by default). Why not have the >> time to delete equal the Expire Interval as specified in Section 6? >> >> Thanks, >> Richard >> >> >> _______________________________________________ >> sidr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/sidr > > > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
