Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09

[Michael Richardson <[e-mail]>]

Toerless Eckert <[e-mail]> wrote:
    > 1.2) Terminology:

    > a) vendor vs. manufacturer.

    > The document uses 48 times "vendor" and 13 times "manufacturer". Please
    > revisit this: If there is a clear reason when/why to use vendor and when/why
    > to use the term "manufacturer", then please put these explanations into
    > terminology. Otherwise maybe eliminate "vendor".

Ha. Good catch.
I'm pretty sure we want to say manufacturer consistently.
The IETF has often talked about vendors rather than manufacturers, so this
might cause some confusion.  Let's go ahead with this and see what confusion
we cause.

There is a distinction between vendor (which generally includes VARs) and
OEMs.

    > For example: Abstract: "using vendor installed X.509 certificate" ...
    > "vendor's authorizing service". This latter one definitely seems to be
    > wrong (MASA = "manufacturer authorizied..., not vendor).

I've also condensed a number of cases like you noticed:
     "vendor authorized MASA service"  ==> MASA

I am concerned that we might lose some subtly between the entity that sold
the device to the customer, and the entity that signs the vouchers.
We used the term MASA specifically because we were sure that the service
would be outsourced by many manufacturers.

    > b)  Key infrastructure

    > There  is no definition/reference for this term.  Please describe on
    > first use and in terminology.  Is there a difference
    > between "key infrastructure" and  "keying material" ? If not, then
    > maybe remove one term otherwise pls. describe difference.

The term is in the title and in section 1.
And you are right that it does not appear again, nor is it defined.
I think it generally refers to the mechanism of PKI, but I'm not sure what to do.

    > c) (terminology) MASA definition: "A third-party Manufacturer...". Why "third-party" ?
    > who are the first two parties ? If this is only slang and we can't explain who the
    > first two parties are, delete "third-party" ?

Fixed...  The first party is the Pledge and manufacturer.
The second party is the Domain Owner.
The third party is the entity running the MASA, which may not be the manufacturer.

    > d) "Domain Registrar" vs. "Join Registrar", JRC. Especially because the text mostly
    > uses "Domain Registrar" and very seldom "Join Registar".

Yes, because we agreed that the term across WGs would be JRC, and we say
in the terminology that we shorten it to Registrar.  We say "Domain
Registrar" because we want to link it to the PKI concept of a Registration
Authority (RA).

    > JRC is used in exactly three places in the draft. I also can not find on www.google.com
    > or wikipedia any example of "The term JRC is used in common with other bootstrap
    > mechanisms" as the Terminology claims. Either provide a non-anima reference for the
    > use of that term or eliminate it in the document.

We agreed to use common terms.
It was a thread on ANIMA and 6tisch a year ago.
I can't get mailarchive to find it for me...
Ah, I see because "JRC" was never used contracted in that thread.
    https://mailarchive.ietf.org/arch/msg/anima/iotBM0-kxsIB66t8hBo4XUtZLag

As long as they Informative references.
https://tools.ietf.org/html/draft-ietf-6tisch-architecture-13#section-6.1
https://tools.ietf.org/html/draft-ietf-6tisch-terminology-09
        (yes, expired, but not forgotten, just not a priority)

    > e) Voucher
    > - misses ":" after term.
    > - please change "statement" to "artifact" so the terminology aligns with both voucher
    > draft and voucher-request text which also uses artifact. See also section 2.2
    > where you use "cryptographically protected" instead of "signed" and figure out
    > which term you want to use in all cases (hint: signed).

I've changed it to:
  <t>A voucher is a cryptographically protected artifact (a digital signature) to the Pledge

I feel that we need to say it's cryptographically signed at least once.

    > f) IMPORTANT: Please add/define the term "ANI"

    > ANI - "Autonomic Network Infrastructure". Systems that support both BRSKI and
    > Autonomic Control plane - ACP ([I-D.ietf-anima-autonomic-control-plane]). ANI
    > systems (pledges, proxies, registrar) have specific requirements detailled in
    > the document.

            <t hangText="ANI:">The Autonomic Network Infrastructure as
            defined by <xref target="I-D.ietf-anima-autonomic-control-plane"
            />.  This document details specific requirements for pledges,
            proxies and registrars when they are part of an ANI.</t>

Does this work for you?

    > Without this term we can not nail down the explicit requirements against
    > ANI Pledges, Proxies, Registrars that we need from the document (and distinguish
    > from requirements against any non-ANI adaptation of BRSKI). I added according
    > comments into other parts of the doc.

    > g) Please replace "MASA server" with "MASA service" everywhere.

I prefer to just say "MASA" actually.
Are you okay with that?

Let me wrap up here for the moment so you can see the edits and
I'll reply to the rest as Max and I digest it.  It's a lot of comments.
I'd like to push an -11 (if only to fix email for M. Behringer).

    https://github.com/anima-wg/anima-bootstrap/pull/42
    https://github.com/anima-wg/anima-bootstrap/pull/42/commits/cb7af66344ad709aaf70287a40fa13a67bbf601c


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-