Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03

[Richard Hansen <[e-mail]>]

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