Terry: Hi! Any thoughts on this document?
Thanks! Alvaro. On December 22, 2017 at 9:52:21 AM, Tim Bruijnzeels (t...@ripe.net) wrote: Dear Terry, We just uploaded version -10 that we hope addresses your points. This version adds: - explicit text in the abstract stating that this document considers validation under a Trust Anchor only, and that overlaps between multiple TAs are out of scope - three examples using the validation algorithm in this document: 1- Old OID only 2- New OID only 3- A mix of old and new OIDs in a single RPKI tree - the deployment considerations section clearly says discussion still needs to be had, but points at example 3 as a possible deployment scenario Kind regards, Tim Bruijnzeels, and co-authors > On 31 Aug 2017, at 05:29, Terry Manderson <terry.mander...@icann.org> wrote: > > Terry Manderson has entered the following ballot position for > draft-ietf-sidr-rpki-validation-reconsidered-08: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for considering the stability of the internet's routing system during > administrative changes to resources. > > One thing isn't quite clear to me, so I'm balloting this as a DISCUSS with the > plan that a small amount discussion will resolve it. > > With the definition of the new validation OID (a idea that I like BTW), at any > stage of the certificate issuance can the validation OID be switched? That is a > TA has a particular OID and down the tree an issued certificate has a different > OID? If that can't happen (and please make that clear in the document) is there > plan to migrate the set of all issued certificates to the new OID? and > deprecate the old OID? > > Logically speaking a trust anchor cannot be thought of as over-claiming. (eg > you trust where the self signed cert came from, and its contents) However the > new validation constructs suggest that a TA can over-claim, but it seems like > there won't be any warning (as the example in S4.3) to highlight this possible > eventuality when (in the model where all RIRs issue a TA) a resource is > transferred from one RIR to another for the clients use. Is that interpretation > correct? OR does this new model espouse the belief that all RIRs each issue a > TA that covers 0/0 and ::/0 in perpetuity? In that construct does this mean > that RFC6491 should be updated or made historic? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I get the sense that many of the ramifications for this validation change are > yet to be discovered. It worries me that from the shepherd writeup "The > existing CA/RP code implementations will support this once published." What > experiments have been done to identify any gaps and assumptions? > > > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
