Re: [Anima] Alvaro Retana's No Objection on draft-ietf-anima-bootstrapping-keyinfra-28: (with COMMENT)

[Michael Richardson <[e-mail]>]

Alvaro Retana via Datatracker <[e-mail]> wrote:
    > (1) §1.3.2 (Constrained environments): "Those types of networks SHOULD NOT use
    > this solution."  The use of Normative language seems out of place: if this
    > document is not applicable to constrained environments, then there's no way to
    > enforce (SHOULD NOT)...   s/SHOULD NOT/should not

okay, fixed.

    > (2) §2.1: In Figure 2, should the "rejected" action be a result of step 3
    > (instead of 2)?

The Pledge provides it's identity to the JRC at step 2.
(Effectively during the TLS setup)
If the JRC doesn't like (invalid manufacturer), then the TLS connection does
not complete.  It doesn't get to attempt to join.
If the voucher doesn't check out, then it's Enroll Failure.

    > (3) s/The serialNumber fields is defined in [RFC5280], and is a SHOULD field in
    > [IDevID]./The serialNumber field is defined in [RFC5280], and is a recommended
    > field in [IDevID].   Note that SHOULD is not used properly here because it does
    > not have a Normative quality (as it refers to the other document).  I'm
    > assuming that the replacement is "recommended" (per rfc2119), but it may be
    > "required".

802.1AR says it is SHOULD.  We need to increase this to MUST.
RECOMMENDED is a synonym for SHOULD according to 2119.
REQUIRED is a synonym for MUST, so if I changed it to REQUIRED then it would
still be a problem according to your thinking...?

So I could reword as:

   IDevID certificates for use with this protocol are REQUIRED to
   include the "serialNumber" attribute with the device's unique
   serial number (from [IDevID] section 7.2.8, and [RFC5280] section
   4.1.2.4's list of standard attributes).

which might be an easier read.  Please let me know if I am mis-understanding you.

    > (4) [nits]

    > s/Bootstrapping to is complete/Bootstrapping is complete

Thanks.

    > §1: "This bootstrap process satisfies the [RFC7575] section 3.3 of making all
    > operations secure by default."  Satisfies the what?  Requirement,
    > maybe?

requirements, yes, thank you.

    > s/explains the details applicability/explains the detailed
    > applicability

thank you.

    > s/out-of-band" information"/out-of-band" information

fixed.

    > s/This section applies is normative for uses with an ANIMA ACP./This section is
    > normative for uses with an ANIMA ACP.

fixed.

    > s/RFC XXXX: Manufacturer Usage Description Specification/RFC 8520: Manufacturer
    > Usage Description Specification

I can't find that in -28, I think it was already fixed.

    > s/might be previous deployed/might be previously deployed

fixed.

    > s/were receives by/were received from

    > s/{{...}}/[...]

Oh. markdown style infested the XML document.
I think this is my last .xml document.  At least, I hope.

Your changes in the diff:  https://tinyurl.com/y5l4xz3z

YANG doctor comments to come for -29, sometime after the RIPE IOT session
tomorrow.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [







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