-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/25/17 15:08, Michael Richardson wrote: > Joe, Max, Kent and I worked through your comments, and this will > result in a version -06 shortly. (06 will also include changes to > CMS) > > On 10/04/17 13:39, Joe Clarke wrote: >> In terms of revocation tests, it might be worth mentioning (from >> an operator perspective) that doing this may require broader >> internet connectivity than a bootstrapping device may typically >> have. Opening up that connectivity may be problematic from a >> security standpoint. There might, therefore, be some >> requirements or recommendations put on the bootstrapping services >> to make sure a device is both protected and can verify the >> validity of a cert. > > In general, the need for connectivity to check revocation is why > we prefer short-lived vouchers.
That's fine. My point was in doing this there should be some callout to the fact that the certs will require connectivity for validation. > >> >> From a terminology standpoint, the use of the word "pledge" seems >> odd. The use of this word may not translate as clearly outside >> of the US. Why not something like candidate? > > That's an interesting suggestion. It has a slightly different > connotation and implies some kind of contest. > > We picked pledge based upon the traditions of fraternities, with > inspiration from movies like Animal House. Dictionary definitions > of Pledge reinforce our usage. I speak US English, and I knew what you meant. But I, too, looked it up, and I didn't find this as a common definition. If I'm the only one commenting, pledge is likely fine. I was just curious if this would be as obvious for non-US English speakers. > >> Below are my section-by-section reviews: >> >> Section 1: >> >> There is a reference to a "second category" of vouchers, but this >> is not referenced anywhere else. I'm not sure what the >> "categories" of vouchers are. More explanation (or rephrasing) is >> required here. > > We have clarified the "second category". Also removed the word > ephemeral in the intro as being confusing here > > The categories are essentially: "nonce" (freshness by being online, > and containing data from the pledge), and "time-based" (freshness > by having a useful real-time clock and paying attention to the > expires-on attribute). So we changed that paragraph to: > > The lifetimes of vouchers may vary. In some bootstrapping > protocols the vouchers may include a nonce restricting them to a > single use, whereas in others the vouchers may have an indicated > lifetime. In order to support long lifetimes this document > recommends using short lifetimes with programatic renewal, see > Section 7.1. Thanks. > >> Section 6.1: >> >> Is this needed? Can you simply refer to >> draft-ietf-netmod-yang-tree-diagrams? > > We ripped out section 4, and referenced the document informatively, > and hope that it will get published. Thanks. Joe > > > -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTMiWQHc8wChijkr7lvaI+K/hTPhwUCWfEK+gAKCRBvaI+K/hTP h0LGAJ9h5e2wIKXkkgakNYPimAB6UUxN6ACdEQI1LKVgfEDeYWfEnrzu5giloi8= =yWEi -----END PGP SIGNATURE----- _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
