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)" <aret...@cisco.com> wrote: >On 4/26/16, 6:58 PM, "Rob Austein" <s...@hactrn.net> 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. >> >>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. > >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. > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr