On 05/03/2018 00:04, Eliot Lear wrote: > Hi, > > I'm not Max but I hope you won't mind me commenting in three places: > > > On 02.03.18 23:59, Michael Richardson wrote: > >> Section 2.1 >>> a) The term "Request Join" is only used here, and its IMHO not very logical >>> (disclaimer: toerless: en.wikipedia.org/wiki/ESL). It sounds to me like the >>> pledge says "i want to join". And also sounds as if the pledge could be >>> disappointed if rejected. I would rather call it "Domain membership >>> inquiry". >>> Or if you're hooked up on the term "joining", then maybe "Join Inquiry". >> QUESTION? what do you think? >> Was "Request Voucher" one of the options you were thinking about? > > I would very much prefer that we not use "Domain membership inquiry". > If a change is necessary, I would prefer "Join Inquiry", to avoid > introducing ambiguities about domains.
Yes. We have explicitly left the (tricky) issue of AN domain boundaries and membership for later. (Recharter alert!) Brian >> >>> Whatever best makes it clear that rejection is a perfect and important >>> outcome option. >>> >>> b) Please see my issue section 5.1 a). If you agree with that statement, >>> then there >>> should be no "rejected" arrow in Figure 2 coming out of the "Identify" >>> block. >> okay, I'll deal with this in that section. >> >>> I would also suggest that the "Bad Vendor response" arrow does not come out >>> of the "Imprint" block but out of the "Request Join" block. AFAIK, this is >>> an error reply to the Request Voucher, so it happens before imprinting >>> (imprinting happens only when there is a vocker reply. AFAIK). >> [It says, "Bad MASA response" now, just for the reader who is following] >> >>> I don't think "Bad Vendor reply" in Figure 2 is a good term. Most logical >>> to me would >>> be "Error or not member". In any case, the text in section 2 below should >>> mention the exact words used on the labels, the text is missing ll the >>> labels on the left: "Factory reset", "Enroll Failure", "Bad Vendor >>> response",... >> more discussion. >> >>> c) >>> >>> Point 1 nicely explains how this is done during TLS. >>> >>> Likewise, Point 2 should mention that this is the "Voucher Request", and >>> Point 3 should mention that it is the "Voucher Reply" - so readers can match >>> up section 2.1 with the rest of the document. >>> >>> remove the "e.g." from "protocol, e.g. Enrollment over". Otherwise some text >>> outlining when something else than EST is to be used. (see next comment). >> QUESTION: I couldn't figure out what text this applies to. > > I can't be sure. I think Toerless may be referring to both the Diagram > and the text in Section 2.1, as compared to, say, Figure 3 in Section > 2.4. I think the main change, IMHO is Figure 3, just to change > <---voucher--- to <---voucher reply--. > > ??? > >> >>> d) >>> >>> I am missing in the initial chapters a succinct summary how EST enrollment >>> is optional and >>> what can be achieved with/without it, there is only some side sentences >>> later in the >>> EST sections. I would suggest to insert such an explanation here. >>> >>> After point 4 insert (unnumbered) paragraph: >>> >>> | After step 4, the pledge has received and authenticated an explicit TA >>> (trust anchor) >>> | (pinned-domain-cert in the Voucher response). In some use cases this may >>> be sufficient >>> | and the bootstrap can be terminated here. The pledge can now use this TA >>> to securely >>> | trust domain members, but it can not securely identify itself to them as >>> a domain member. >>> | Therefore BRSKI usually proceeds with the following steps that support >>> this via EST >>> | enrollment (see also 5.5.1 for the limitations of the trust feasible >>> through the imprint). >>> >>> Also maybe insert some dotted line between imprint and enroll in Figure 2 to >>> highlight this distinction. Maybe with "mandatory" / "optional" (EST enroll >>> part) >>> on the right hand side >> QUESTION: Max? > > If it is just a dotted line, ok. But then use text at the beginning of, > or just before, Step 5 to indicate that the step is optional. > > Regards, > > Eliot > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
