> On 28 Mar 2018, at 05:49, Ignas Bagdonas <ibagd...@gmail.com> wrote: > > Ignas Bagdonas has entered the following ballot position for > draft-ietf-sidr-slurm-07: No Objection > > 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-slurm/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > A few comments: > > 1. Document uses all capital form of AND for filters containing both prefixes > and ASNs, and filters containing ASNs and SKIs. That is not part of RFC2119 > language.
Emphasis was intended, but lower case ‘and’ is fine. > 2. s/Route Origination Authorization/Route Origin Authorization ack > > 3. If a local assertion is added without a matching filter, does it take > priority over existing assertion? No, local assertions are similar to ROA VRPs or Router Certificates found through validation. They are complementary. > 4. The term 'putative TA' has been flagged a couple of times in various > reviews > as being not known. It does not appear to be formally defined, RFC7730 seems > to > be the closest source - while it is not formally defined there either. I believe the word ‘putative’ can be dropped. It’s not like this is special kind of Trust Anchor. Regards Tim > > > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
