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

[David Mandelberg <[e-mail]>]

On 2015-03-06 05:22, Sandra Murphy wrote:
> Please comment to the list whether you believe that this draft is
> ready for publication.

I reviewed this draft. My substantive comments are below, and I'll send 
nits to the authors. Other than the below and the comment that Tim B 
sent to the list, I think the draft is ready for publication. (Note that 
while I have written a cache implementation of version 0 of this 
protocol, I have not yet written an implementation of version 1.)

Section 5 says "Fields with unspecified content MUST be zero on 
transmission and MAY be ignored on receipt" and Section 5.1 says "Fields 
shown as zero or reserved MUST be zero.  The value of such a field MUST 
be ignored on receipt." Are there three separate things (unspecified, 
zero, and reserved) to which these different rules apply? Or are these 
all the same thing, and the MAY in the first quote conflicts with the 
second MUST in the second quote?

The Router Key PDU (section 5.10) uses a fixed-size field for the SKI. 
What's the plan for algorithm agility, if the size of the SKI changes? 
if the size of the SKI does not change, but the algorithm does?

Section 7 adds the requirement that "A router MUST start each transport 
session by issuing either a Reset Query or a Serial Query." However, I 
don't see an additional requirement that the cache can't start sending 
PDUs (e.g., a Serial Notify) before it receives a Query from the router. 
Maybe there should be? Our current (version 0) implementation sends a 
Serial Notify whenever there is a new serial number, even if the router 
has not yet made any queries. If a version 1 router connects to our 
version 0 cache and we somehow manage to send a Serial Notify before the 
router is able to send a Query, what should the router do? Likewise, 
what should the router do if it receives any version 1 PDU before it has 
sent a Query?

What happens if version 1 is successfully negotiated, but a later PDU 
is sent (in either direction) with its version set to 0? Should the 
receiving side send an Error Report and disconnect? Likewise, what 
happens if version 0 is successfully negotiated, but a later PDU has a 
version of 1? Should the receiving side send an Error Report and 
disconnect? Even if the version 1 PDU is a Query (router to cache) and 
the cache supports version 1? I have no issue with disallowing 
re-negotiation of the protocol version, but I think it should be clearly 
specified that negotiation happens only at the beginning of a transport 
session.

-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/