Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-rtr-rfc6810-bis-07

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 29 Jun 2016 17:42:14 +0000

On 5/26/16, 11:15 AM, "sidr on behalf of Stephen Kent"
<[email-masked] on behalf of [email-masked]> wrote:

[Sorry for the delay...]

>
>> ...
>>> It means that most of the code one needs to deal with version one is
>>> the same as the code one needs to deal with version zero.  Feel free
>>> to suggest better text.
>> When I think about protocol compatibility I think about on-the-wire
>> behavior and packets, not about the implementation internals.
>
>I'm not sure what the phrase "on-the-wire behavior" means. Certainly
>it is not enough to agree on data formats, i.e., the format of data on
>the wire.
>There also must be consistent behavior by each end of a
>connection/session/ ...
>(in terms of externally-visible processing) of the agreed upon data
>format.
>Otherwise,  the behavior of "compatible" implementations may vary
>significantly,
>and  users will not see the versions as "compatible."
>
>I think your latter comments match my sense of "compatibility",
>but I just wanted to make sure we are on the same page.

Yes, I think we are.

Alvaro.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 29 Jun 2016 17:45:45 +0000

Rob:

Hi!

Did you have comments on this?  I'm assuming that we're expecting an
updated document at some point, but if we need to discuss more...

Thanks!

Alvaro.

On 5/25/16, 12:09 AM, "Alvaro Retana (aretana)" <[email-masked]> wrote:

>On 4/26/16, 6:58 PM, "Rob Austein" <[email-masked]> wrote:
>
>Rob:
>
>Hi!
>
>>At Sat, 23 Apr 2016 00:09:07 +0000, Alvaro Retana (aretana) wrote:
>>>
>>>      *   Section 1.2. (Changes from RFC 6810):  "The protocol
>>>          described in this document is largely compatible with
>>>          [RFC6810]."  What does "largely compatible" mean?  It
>>>          either is compatible or it isn't.
>>
>NEW>
>   The protocol described in this document should allow
>   an implementation to largely reuse the code developed
>   for version zero.
>
>However, I would prefer if the sentence was taken out completely.
>
>
>...
>>
>>>      *   This document is marked as obsoleting rfc6810, but it
>>>          mandates its use in section 7 ("...the cache MUST downgrade
>>>          to protocol version 0 [RFC6810]...").  There are a couple
>>>          of paths forward:
>>>
>>>         *   It seems to me that this document should simply be
>>>             called "RPKI to Router Protocol version 1" and not
>>>             change the status of rfc6810 - we can always declare
>>>             version 0 historic later.
>>>
>>>         *   If you really want to obsolete version 0, then an
>>>             alternative is to eliminate the normative language when
>>>             it refers to it...  For example,
>>>
>>>            *   OLD> "If a cache which supports version 1 receives a
>>>                query from a router which specifies version 0, the
>>>                cache MUST downgrade to protocol version 0 [RFC6810]
>>>                or send a version 1 Error Report PDU with Error Code
>>>                4 ("Unsupported Protocol Version") and terminate the
>>>                connection."
>>>
>>>            *   NEW> "If a cache which supports version 1 receives a
>>>                query from a router which specifies version 0, the
>>>                cache SHOULD send a version 1 Error Report PDU with
>>>                Error Code 4 ("Unsupported Protocol Version") and
>>>                terminate the connection."
>>
>>The intent is to deprecate version zero, because it lacks features we
>>think are important.  But version zero is already in the field and we
>>have no control over how long it will take to upgrade all existing
>>copies.  So we have to specify how versions zero and one are intended
>>to interoperate.  I don't know how to specify that without normative
>>references to the older version.
>
>If you want to deprecate version zero, then Obsoleting rfc6810 is ok.
>What is not ok is mandating its use at the same time.
>
>I'm thinking that we could get away with removing Section 7 completely,
>and leaving the downgrade behavior as a "local implementation detail" --
>see below: I'm including comments on Section 7, and an optional new
>subsection.
>
>
>Notes_On_7 (my comments with [A]>
>7.  Protocol Version Negotiation
>
>   A router MUST start each transport connection by issuing either a
>   Reset Query or a Serial Query.  This query will tell the cache which
>   version of this protocol the router implements.
>
>[A] This text (above) is in conflict with Section 8.1. (Start or Restart)
>which reads: "When a transport connection is first established, the router
>MAY send a Reset Query...Alternatively...it MAY start with a Serial
>Query..."   To match the behavior in Section 7, here's a suggestion for
>alternate text (for 8.1).
>
>OLD>
>   When a transport connection is first established, the router MAY send
>   a Reset Query and the cache responds with a data sequence of all data
>   it contains.
>
>   Alternatively, if the router has significant unexpired data from a
>   broken session with the same cache, it MAY start with a Serial Query
>   containing the Session ID from the previous session to ensure the
>   Serial Numbers are commensurate.
>
>NEW>
>   When a transport connection is first established, the router MUST send
>   a Reset Query and the cache responds with a data sequence of all data
>   it contains, or a Serial Query.  The Serial Query can be used if the
>   router has significant unexpired data from a broken session with the
>   same cache; in this case the Serial Query containing the Session ID
>   from the previous session to ensure the Serial Numbers are
>commensurate.
>
>
>[A] BTW, a couple of paragraphs later the text goes back to saying that
>"The router MUST send either a Reset Query or a Serial Query..."  I think
>this text would now be redundant and can be deleted.
>
>
>
>
>   If a cache which supports version 1 receives a query from a router
>   which specifies version 0, the cache MUST downgrade to protocol
>   version 0 [RFC6810] or send a version 1 Error Report PDU with Error
>   Code 4 ("Unsupported Protocol Version") and terminate the connection.
>
>[A] The behavior of sending the Error PDU is expected if the cache doesn't
>support anything else.  In the case of the cache supporting both, it can
>just directly downgrade (as a local decision) -- see some suggested text
>below.
>
>
>   If a router which supports version 1 sends a query to a cache which
>   only supports version 0, one of two things will happen.
>
>   1.  The cache may terminate the connection, perhaps with a version 0
>       Error Report PDU.  In this case the router MAY retry the
>       connection using protocol version 0.
>
>   2.  The cache may reply with a version 0 response.  In this case the
>       router MUST either downgrade to version 0 or terminate the
>       connection.
>
>[A] In this case again, the behavior of the router can be a local
>decision: if a version 0 response (including an Error PDU) is received,
>then downgrade -- again, see suggested text below.
>
>
>   In any of the downgraded combinations above, the new features of
>   version 1 will not be available.
>
>   If either party receives a PDU containing an unrecognized Protocol
>   Version (neither 0 nor 1) during this negotiation, it MUST either
>   downgrade to a known version or terminate the connection, with an
>   Error Report PDU unless the received PDU is itself an Error Report
>   PDU.
>
>[A] Both versions react the same way to an unrecognized version...so no
>need to repeat.
>
>
>   The router MUST ignore any Serial Notify PDUs it might receive from
>   the cache during this initial start-up period, regardless of the
>   Protocol Version field in the Serial Notify PDU.  Since Session ID
>   and Serial Number values are specific to a particular protocol
>   version, the values in the notification are not useful to the router.
>   Even if these values were meaningful, the only effect that processing
>   the notification would have would be to trigger exactly the same
>   Reset Query or Serial Query that the router has already sent as part
>   of the not-yet-complete version negotiation process, so there is
>   nothing to be gained by processing notifications until version
>   negotiation completes.
>
>[A] This text (above) is in conflict with Section 5.2. (Serial Notify),
>which reads: "If the router receives a Serial Notify PDU during the
>initial start-up period...the router SHOULD simply ignore the Serial
>Notify PDU..."   Solution: update 5.2 with a "MUST" -- according to the
>explanation above, there's no real value in listening (which would not
>make it a "SHOULD").
>
>[A] Section 5.2 also says: "See Section 7 for details."  Instead of that
>reference, you can include the additional text above (after the first
>sentence).
>
>
>   Caches SHOULD NOT send Serial Notify PDUs before version negotiation
>   completes.  Note, however, that routers MUST handle such
>   notifications (by ignoring them) for backwards compatibility with
>   caches serving protocol version 0.
>
>[A] The text above is the corollary of the "MUST ignore" text before it
>(you can include it in 5.2)...and the second sentence is really redundant.
>
>
>   Once the cache and router have agreed upon a Protocol Version via the
>   negotiation process above, that version is stable for the life of the
>   session.  See Section 5.1 for a discussion of the interaction between
>   Protocol Version and Session ID.
>
>   If either party receives a PDU for a different Protocol Version once
>   the above negotiation completes, that party MUST drop the session;
>   unless the PDU containing the unexpected Protocol Version was itself
>   an Error Report PDU, the party dropping the session SHOULD send an
>   Error Report with an error code of 8 ("Unexpected Protocol Version").
>
>
>[A] Add the exception (receiving an Error PDU) to the definition of error
>code 8 in Section 12.
>
>
>
>
>Given that it is in fact possible to find older versions in the field, you
>might want to include a Section calling that out.  My suggestion is to
>create a new Section called "Deployment Considerations", include in it the
>current Section 11. (Deployment Scenarios) as a sub-section, and add a new
>sub-section called "Transition Considerations".
>
>Suggestion>
>11.2 Transition Considerations
>
>   This document Obsoletes version zero of this protocol [RFC6810].
>   The intent is to deprecate its use.  However, version zero is already
>   in the field and it is possible that deployments will encounter mixed
>   scenarios, where a router or cache may only support version zero.  It
>   is also expected that during the transition period a cache or router
>   that supports version one will also support version zero.  The
>determination 
>   that a peer (cache or router) only supports version zero is straight
>   forward: a version zero PDU is received from them.  In these cases, it
>   is up to the local implementation, and policy, whether it might prefer
>   to use version zero to establish the session, with the understanding
>   that the new features of version one will not be available.
>
>
>
>
>One new comment:
>
>Section 12. (Error Codes) says that "Errors which are considered fatal
>SHOULD cause the session to be dropped."  When is it ok not to drop the
>session?  IOW, why not use a "MUST"?
>
>
>Thanks!
>
>Alvaro.
>