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. > >> 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
