Subject: [Anima] Comments for draft-pritikin-anima-bootstrapping-keyinfra-00

From: "Fuyu (Eleven)" <[email-masked]>
Date: Wed, 4 Feb 2015 05:55:55 +0000

Hi all,

Some comments for draft-pritikin-anima-bootstrapping-keyinfra-00

1.       Abstract: the last sentence
>When a vendor cloud service is provided devices can be forced to join only specific domains but for contrained environments we describe a variety of options that allow bootstrapping to proceed.”

What does the ” contrained” mean? A typo?

2.       Section 1 introduction : the last sentence
>Sufficient agility to support bootstrapping alternative key infrastructures (such as symmetric key solutions) is considered although no such key infrastructure is described

Does it describe the alternative key infrastructures in this draft? For example, how the symmetric key solutions work?  If not, I think a brief description is needed.

3.       Section 2:  > Domain Identity:  (A string value bound to the Domain CA's self signed root certificate subject and issuer fields is often colloqually used as a humanized identity value but during protocol discussions the more exact term as defined here is used).

I think the Domain Identity is the terminology. It is not suitable to describe it in this section for the logical component for bootstrapping architecture.
BTW，colloqually? A typo?

4.       Section 2:  > MASA Cloud Service:  encorporate > incorporate

5.       Section 4: It does not note the Figure 2 under the flow procedure.

6.       Section 4.1, > A: Search for a Proxy on the local link using Neighbor Discovery.

Is the Neighbor Discovery using ND? Does the ND can work in this use case?

7.       Section 4.3, the first word: one > once.

8.       Section 4.3.2 > In all cases a Registrar must use the globally available MASA cloud service to verify the device's history log does not include unexpected Registrars.

I am confused with how a Registrar to verify the device's history log does not include unexpected Registrars. Does it can verify the log does not include unexpected devices?

9.       Section 6 > The registrar may chose to accept

Chose > choose

10.   I think it need to describe some specific terminology such as authorization token, domain identity, device's history log in Section 1.1.

Cheers
Yu

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 5 Feb 2015 16:02:59 +0000

Thanks for the feedback. Most comments are about clarifications, we’ll work through them and clarify.

Expect a new version shortly.

Thanks,
Michael

From: Anima [mailto:[email-masked]] On Behalf Of Fuyu (Eleven)
Sent: 04 February 2015 06:56
To: [email-masked]
Subject: [Anima] Comments for draft-pritikin-anima-bootstrapping-keyinfra-00

Hi all,

Chose > choose

Cheers
Yu

---

From: Michael Behringer <[email-masked]>
Date: Thu, 12 Feb 2015 17:58:58 +0100

Hi Fuyu, thanks for your comments!
Inline...

On 04/02/2015 06:55, Fuyu (Eleven) wrote:

Hi all,

Some comments for
draft-pritikin-anima-bootstrapping-keyinfra-00

1.
Abstract:
the last sentence

>When a vendor cloud
service is provided devices can be forced to join only
specific domains but for contrained environments we describe
a variety of options that allow bootstrapping to proceed.”

What does the ”
contrained” mean? A typo?

Yes. Fixed.

2.
Section 1
introduction : the last sentence

>Sufficient agility
to support bootstrapping alternative key infrastructures
(such as symmetric key solutions) is considered although no
such key infrastructure is described

Does it describe the
alternative key infrastructures in this draft? For example,
how the symmetric key solutions work?  If not, I think a
brief description is needed.

Yes, this is missing, and will be added.

3.
Section
2:  > Domain Identity:  (A string value bound to the
Domain CA's self signed root certificate subject and issuer
fields is often colloqually used as a humanized identity
value but during protocol discussions the more exact term as
defined here is used).

I think the Domain
Identity is the terminology. It is not suitable to describe
it in this section for the logical component for
bootstrapping architecture.

Not sure I understand what you mean?

BTW，colloqually?
A typo?

Yup. colloquially. Fixed.

4.
Section
2:  > MASA Cloud Service:  encorporate > incorporate

Fixed.

5.
Section
4: It does not note the Figure 2 under the flow procedure.

Fixed.

6.
Section
4.1, > A: Search for a Proxy on the local link using
Neighbor Discovery.

Is the Neighbor
Discovery using ND? Does the ND can work in this use case?

ND could be used to discover peers.

7.
Section
4.3, the first word: one > once.

Done.

8.
Section
4.3.2 > In all cases a Registrar must use the globally
available MASA cloud service to verify the device's history
log does not include unexpected Registrars.

I am confused with how a
Registrar to verify the device's history log does not
include unexpected Registrars. Does it can verify the log
does not include unexpected devices?

Tried to clarify with "Because if a device had previously registered
with another domain, the registrar of that domain would show in the
log."

Does that make it clearer?

9.
Section
6 > The registrar may chose to accept

Chose > choose

Fixed.

10.
I
think it need to describe some specific terminology such as
authorization token, domain identity, device's history log
in Section 1.1.

Hmmm... It's all in the draft actually. For example, domain ID is
3rd definitino after figure 1. Authorization token is defined in the
client behaviour section. Will see whether we can make that clearer.

Thanks for the feedback again!

Michael

Cheers

Yu

_______________________________________________
Anima mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/anima