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