Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)

Michael Richardson <> Fri, 03 January 2020 18:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B090712002F; Fri, 3 Jan 2020 10:34:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fI9I1p_jCmVk; Fri, 3 Jan 2020 10:34:35 -0800 (PST)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D3CCE120045; Fri, 3 Jan 2020 10:34:34 -0800 (PST)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 1DFBA3897C; Fri, 3 Jan 2020 13:34:15 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 029F710FE; Fri, 3 Jan 2020 13:34:32 -0500 (EST)
From: Michael Richardson <>
To: tom petch <>
cc: Alissa Cooper <>, IESG <>,,,,
In-Reply-To: <>
References: <> <9637.1574756997@localhost> <> <20062.1576526178@localhost> <> <28309.1577821075@localhost> <> <30513.1577829694@localhost> <>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Fri, 03 Jan 2020 13:34:31 -0500
Message-ID: <18823.1578076471@localhost>
Archived-At: <>
Subject: Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 03 Jan 2020 18:34:38 -0000

I have pushed -33 with changes as below.

tom petch <> wrote:
    > On 31/12/2019 22:01, Michael Richardson wrote:
    >> tom petch <> wrote:
    >> > Security Considerations, the YANG Guidelines RFC says that you must mention
    >> > TLS, HTTPS, etc and give pro forma text for doing so.  As long as you still
    >> > have a YANG module, as you do in s.3.4, I would expect those guidelines to
    >> > apply and so to see something like the pro forma text
    >> Please see:
    >> TLS is already specified and discussed at length in the document.
    >> If you want me to copy the second paragraph from there in, I can do that, but
    >> it seems like needless text.  You can't implement BRSKI without reading
    >> RFC8366.

    > Looking at -32:

    > Security; OK, leave it be.

    > IANA yes, that is (almost) what I wanted - I suggest that the title of 8.2
    > should be 'YANG Module Names Registry.

fixed, sorry, stupid copy and paste error.

    > References still trouble me.

    > The YANG module has
    > reference "RFC xxxx Voucher Profile for Bootstrapping Protocols"

    > I cannot find an I-D of that name - it is not the name of this I-D; do you
    > mean "Bootstrapping Remote Secure Key Infrastructure" which is the current
    > title of this I-D and which I would I think would not appear to be the same
    > reference to a layman?

I have fixed it to say:
         "RFC XXXX: Bootstrapping Remote Secure Key Infrastructure";

But, as this is actually the voucher-request, should it instead say something
about that?

I also saw:
    reference "RFC 8366: Voucher Profile for Bootstrapping Protocols";

I have fixed it to:
    reference "RFC 8366: Voucher Artifact for Bootstrapping Protocols";

    > Also on References, in -31 you had X.690 as a Normative Reference which I
    > thought spot on - now you have removed the reference which I think wrong.
    > YANG 'leaf proximity-registrar-cert' mentions X.690 so I think that
    > a) you need a YANG reference clause for the leaf

Dang. I removed that because I couldn't find a reference to it, because in
the YANG, the reference is not in the normal fashion.  I've restored the
reference and fixed the YANG description

    > b) you need a XML/HTML reference in the body of the I-D so as to avoid an
    > unused ref error - 'The YANG module makes reference to [X.690] ' {or
    > [ITU.X690.1994] }  is the way most authors address this

I've put a reference into an appendix that the RFC editor should remove,
which is what I started doing earlier this week, then discovered the section
appeared empty.

Michael Richardson <>, Sandelman Software Works
 -= IPv6 IoT consulting =-