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

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 03 January 2020 18:34 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B090712002F; Fri, 3 Jan 2020 10:34:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fI9I1p_jCmVk; Fri, 3 Jan 2020 10:34:35 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [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 ietfa.amsl.com (Postfix) with ESMTPS id D3CCE120045; Fri, 3 Jan 2020 10:34:34 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1DFBA3897C; Fri, 3 Jan 2020 13:34:15 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 029F710FE; Fri, 3 Jan 2020 13:34:32 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: tom petch <daedulus@btconnect.com>
cc: Alissa Cooper <alissa@cooperw.in>, IESG <iesg@ietf.org>, draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org
In-Reply-To: <5E0DE216.3020201@btconnect.com>
References: <157123777786.7830.10713306244839546046.idtracker@ietfa.amsl.com> <9637.1574756997@localhost> <2FA2728E-6484-4A69-992A-479D8053354E@cooperw.in> <20062.1576526178@localhost> <5DF90E0C.9020603@btconnect.com> <28309.1577821075@localhost> <5E0BBC17.5070709@btconnect.com> <30513.1577829694@localhost> <5E0DE216.3020201@btconnect.com>
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: <https://mailarchive.ietf.org/arch/msg/anima/QA8JtPW4b5XqdecRxyNclOBtnBk>
Subject: Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Jan 2020 18:34:38 -0000

I have pushed -33 with changes as below.

tom petch <daedulus@btconnect.com> wrote:
    > On 31/12/2019 22:01, Michael Richardson wrote:
    >>
    >> tom petch <daedulus@btconnect.com> 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:
    >> https://www.rfc-editor.org/rfc/rfc8366.html#section-7.4
    >>
    >> 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:
    reference
         "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 <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-