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

[peter van der Stok <[e-mail]>]

Hi Toerless,

thanks for this reminder about terminology in keyinfra.
I have made several attempts at explaining the authors the possible 
misunderstandings on terminology.
Let's hope your input helps.

I will look at your other comments later this week.

Peter
> 
> 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.
> 
> 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" ?
> 
> d) "Domain Registrar" vs. "Join Registrar", JRC. Especially because
> the text mostly
> uses "Domain Registrar" and very seldom "Join Registar".
> 
> 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.
> 
> Suggest to use "(Domain Join) Registar (and Coordinator) in 1.2 and
> say for example
> that the text uses "Join Registrar" when referring to the mechanics of
> building the
> connection (Join Proxy and Join Registrar) and Domain Registrar when 
> discussing
> authentication and any other aspects of the registrar (where the
> domain is relevant).
> 
> 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).
> 
> 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.
> 
>   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.
>