Re: [Anima] Review draft-ietf-anima-brski-cloud-08
Toerless Eckert wrote: > Wrt. the process: As a reviewer, keeping everything in a single file is > always easier than breaking it up into issues. Especially because the > more you revisit a document, the more you go back and forth and maybe > delete comments or change them. I don't mind it as a single file, although the parts with no comments, maybe could be removed if file size is an issue. > I think i should have created the tags for each review point that would > have allowed to auto-create github issues from them. I remember that > someone in IESG did provide such feedback, but i could not find it > again. WOuld be nice to have a very simple way to find such a preferred > tagging method documented on authors.ietf.org.. That was Lars, and the tool is https://github.com/larseggert/ietf-reviewtool As I said, it didn't work for me last time I tried, but that was many months ago. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Review draft-ietf-anima-brski-cloud-08
Thanks a lot, Michael
Wrt. the process: As a reviewer, keeping everything in a single file is always
easier
than breaking it up into issues. Especially because the more you revisit a
document, the
more you go back and forth and maybe delete comments or change them.
When i sent this as an attachment, i was under the (mis)interpretation, that
attachments
would give me different file-size limits. I did learn in the meantime this is
not the case,
but in that review (for another WG doc), i ended up having to zip the review so
it could
go through *sigh*.
I think i should have created the tags for each review point that would have
allowed to
auto-create github issues from them. I remember that someone in IESG did
provide such feedback,
but i could not find it again. WOuld be nice to have a very simple way to find
such a
preferred tagging method documented on authors.ietf.org..
Thanks again!
Toerless
On Tue, Dec 19, 2023 at 09:53:29AM -0500, Michael Richardson wrote:
>
> Hi, I have processed the complete review from Toerless.
> (Making it a file attach is a bit hostile to the archives, btw)
>
> I have opened 40 issues at: https://github.com/anima-wg/brski-cloud/issues
>
> A few have text fixes on the branch
> https://github.com/anima-wg/brski-cloud/pull/88
> A few will require some discussion, and I've marked them for Toerless'
> attention. Most can be handled by authors, however, and I'll endeavour to
> get that posted by Jan. 2.
>
> Here is my comments/issues for the comments that Toerless made.
> (In two parts)
> Some comments inline as well.
>
> 1) many typos are at: https://github.com/anima-wg/brski-cloud/pull/88
>
> > 10 BRSKI Cloud Registrar 11 draft-ietf-anima-brski-cloud-05
>
> > 13 Abstract
>
> > 15 This document specifies the behavior of a BRSKI Cloud Registrar, and
> > 16 how a pledge can interact with a BRSKI Cloud Registrar when 17
> > bootstrapping.
>
> > If you can, add an explanation what the core aspects of a Cloud
> > Registrar are for tthe purpose of this document... discovery ?
> > untrusted connection, ?
>
> https://github.com/anima-wg/brski-cloud/issues/48
>
> > 95 1. Introduction
>
> > 97 Bootstrapping Remote Secure Key Infrastructures [BRSKI] specifies 98
> > automated bootstrapping of an Autonomic Control Plane. BRSKI
>
> > Suggest to replace after BRSKI with:
>
> > ... BRSKI specifies automated and secure provisioning of nodes (which
> > are called pledges) with cryptographic keying material (trust anchors
> > and certificates) to enable authenticated and confidential
> > communication with other similarily enrolled nodes. This is also called
> > enrolment.
>
> > No need to mention Autonomic Control Plane here IMHO (just sounds like
> > limiting scope of BRSKI Cloud).
>
> > If you really want folks to understand what is happening here, i
> > suggest to include explanations such as the following.
>
> > In BRSKI, the pledge performs enrolment by communicating with a BRSKI
> > Registrar belonging to the domain that provides the cryptopgraphic
> > keying material and usually is or acts upon the owner of the
> > pledge. The pledge does not know who its owner is. Insted, in BRSKI it
> > is assumed that the network to which the pledge connects belongs to the
> > owner of the pledge and therefore network-supported discovery
> > mechanisms can resolve generic, non-owner specific names to the owners
> > Registrar. To support enrolment of pledges without such an owner based
> > access network, the mechanisms of BRSKI Cloud are required which assume
> > that Pledge and Registrar simply connect to the Internet. The Internet
> > ("Cloud") connected Registrar will then determine ownership of the
> > Pledge and redirect the Plege to its owners Registar.
>
> https://github.com/anima-wg/brski-cloud/issues/49
>
> > 99 Section 2.7 describes how a pledge "MAY contact a well-known URI of
> > a 100 cloud registrar if a local registrar cannot be discovered or if
> > the 101 pledge's target use cases do not include a local registrar".
>
> > I would remove parenthesis and lowercase the MAY. No need for this
> > formalism to expose your internal repetition of sentence. This is still
> > introduction, repetition is perfectly fine.
>
> https://github.com/anima-wg/brski-cloud/issues/50
>
> > 131 * Local Domain Registrar: The Registrar discovered on the Local 132
> > Domain. There may not be a Local Domain Registrar in all 133
> > deployment scenarios.
>
> > Isn't one core aspect of interest (which should be discussed in the
> > text), that the pledge does discover a Registar locally, but its not of
> > its owner ?
>
> https://github.com/anima-wg/brski-cloud/issues/51
>
> > 135 1.2. Target Use Cases
>
> > 137 Two high level use cases are documented here. There are more
> >
Re: [Anima] Review draft-ietf-anima-brski-cloud-08
Hi, I have processed the complete review from Toerless.
(Making it a file attach is a bit hostile to the archives, btw)
I have opened 40 issues at: https://github.com/anima-wg/brski-cloud/issues
A few have text fixes on the branch
https://github.com/anima-wg/brski-cloud/pull/88
A few will require some discussion, and I've marked them for Toerless'
attention. Most can be handled by authors, however, and I'll endeavour to
get that posted by Jan. 2.
Here is my comments/issues for the comments that Toerless made.
(In two parts)
Some comments inline as well.
1) many typos are at: https://github.com/anima-wg/brski-cloud/pull/88
> 10 BRSKI Cloud Registrar 11 draft-ietf-anima-brski-cloud-05
> 13 Abstract
> 15 This document specifies the behavior of a BRSKI Cloud Registrar, and
> 16 how a pledge can interact with a BRSKI Cloud Registrar when 17
> bootstrapping.
> If you can, add an explanation what the core aspects of a Cloud
> Registrar are for tthe purpose of this document... discovery ?
> untrusted connection, ?
https://github.com/anima-wg/brski-cloud/issues/48
> 95 1. Introduction
> 97 Bootstrapping Remote Secure Key Infrastructures [BRSKI] specifies 98
> automated bootstrapping of an Autonomic Control Plane. BRSKI
> Suggest to replace after BRSKI with:
> ... BRSKI specifies automated and secure provisioning of nodes (which
> are called pledges) with cryptographic keying material (trust anchors
> and certificates) to enable authenticated and confidential
> communication with other similarily enrolled nodes. This is also called
> enrolment.
> No need to mention Autonomic Control Plane here IMHO (just sounds like
> limiting scope of BRSKI Cloud).
> If you really want folks to understand what is happening here, i
> suggest to include explanations such as the following.
> In BRSKI, the pledge performs enrolment by communicating with a BRSKI
> Registrar belonging to the domain that provides the cryptopgraphic
> keying material and usually is or acts upon the owner of the
> pledge. The pledge does not know who its owner is. Insted, in BRSKI it
> is assumed that the network to which the pledge connects belongs to the
> owner of the pledge and therefore network-supported discovery
> mechanisms can resolve generic, non-owner specific names to the owners
> Registrar. To support enrolment of pledges without such an owner based
> access network, the mechanisms of BRSKI Cloud are required which assume
> that Pledge and Registrar simply connect to the Internet. The Internet
> ("Cloud") connected Registrar will then determine ownership of the
> Pledge and redirect the Plege to its owners Registar.
https://github.com/anima-wg/brski-cloud/issues/49
> 99 Section 2.7 describes how a pledge "MAY contact a well-known URI of
> a 100 cloud registrar if a local registrar cannot be discovered or if
> the 101 pledge's target use cases do not include a local registrar".
> I would remove parenthesis and lowercase the MAY. No need for this
> formalism to expose your internal repetition of sentence. This is still
> introduction, repetition is perfectly fine.
https://github.com/anima-wg/brski-cloud/issues/50
> 131 * Local Domain Registrar: The Registrar discovered on the Local 132
> Domain. There may not be a Local Domain Registrar in all 133
> deployment scenarios.
> Isn't one core aspect of interest (which should be discussed in the
> text), that the pledge does discover a Registar locally, but its not of
> its owner ?
https://github.com/anima-wg/brski-cloud/issues/51
> 135 1.2. Target Use Cases
> 137 Two high level use cases are documented here. There are more
> details
> This document specifies and standardizes procedures for two high level
> use cases.
> (use case documentation is fine, but the beef of standard tracks RFCs
> is the specification of standardized procedures).
https://github.com/anima-wg/brski-cloud/issues/52
> 152 or vertically (more equipment at one site) scaled. It is also 153
> entirely possible that all devices sold by through a particular VAR
> ^^ 154 might be preloaded with a configuration that changes the
> Cloud 155 Registrar URL to point to a VAR. Such an effort would
> require 156 unboxing each device in a controlled environment, but the
> 157 provisioning could occur using a regular BRSKI or SZTP [RFC8572]
> 158 process.
> I think VAR is an unnecessary term and the whole paragraph is somewhat
> confusing.
> If i understand it correctly, the core argument is like this:
> The procedures specified in this document are an alternative to
> mechanisms possible with just BRSKI to reduce operational cost.
> Consider pledges are to be enrolled when being connected solely to the
> Internet, but no owner
Re: [Anima] Review draft-ietf-anima-brski-cloud-08
On Tue, Dec 05, 2023 at 01:05:42PM -0500, Michael Richardson wrote: > > > Earlier this year, i did a review of draft-ietf-anima-brski-cloud-05: > > https://mailarchive.ietf.org/arch/msg/anima/fxFBwoUUUc31eHUcDhdTmWdkFdk > > I see that email refers to your review, but it is not the review itself. Review is attachment of that email. https://mailarchive.ietf.org/arch/msg/anima/fxFBwoUUUc31eHUcDhdTmWdkFdk/2/ Cheers Toerless > > The acknowledgemeent section of -08 does not mention my name. There is > no > > changelog in the document explaining whether or not my review was taking > > into account. I tried to look through the github closed issues, but > > could not figure out > > I will locate your previous review and work on it, as well as your comments > below. > > > Below, i am not repeating what i wrote for the -05 review, which i > think was > > often editorial to improve text quality. Instead, i'll try below to > raise > > mostly functional issues in the core spec. Feel free to also go back to > the -05 review > > and check if stuff from there is still relevant. > > okay, thank for this. > > > -- > Michael Richardson. o O ( IPv6 IøT consulting ) >Sandelman Software Works Inc, Ottawa and Worldwide > > > > -- --- t...@cs.fau.de ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Review draft-ietf-anima-brski-cloud-08
> Earlier this year, i did a review of draft-ietf-anima-brski-cloud-05: > https://mailarchive.ietf.org/arch/msg/anima/fxFBwoUUUc31eHUcDhdTmWdkFdk I see that email refers to your review, but it is not the review itself. > The acknowledgemeent section of -08 does not mention my name. There is no > changelog in the document explaining whether or not my review was taking > into account. I tried to look through the github closed issues, but > could not figure out I will locate your previous review and work on it, as well as your comments below. > Below, i am not repeating what i wrote for the -05 review, which i think was > often editorial to improve text quality. Instead, i'll try below to raise > mostly functional issues in the core spec. Feel free to also go back to the -05 review > and check if stuff from there is still relevant. okay, thank for this. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] Review draft-ietf-anima-brski-cloud-08
Dear BRSKI-cloud authors, Earlier this year, i did a review of draft-ietf-anima-brski-cloud-05: https://mailarchive.ietf.org/arch/msg/anima/fxFBwoUUUc31eHUcDhdTmWdkFdk The acknowledgemeent section of -08 does not mention my name. There is no changelog in the document explaining whether or not my review was taking into account. I tried to look through the github closed issues, but could not figure out if any of them where opened in response to my review. I tried to compare -08 with -05 to determine if / what of my review was taken into account but couldn't find much. There is also no email thread on anima WG mailing list replying to my review. If we should have discussed any of this review in the BRSKI meetings, i apologize, but i do not remember. Below, i am not repeating what i wrote for the -05 review, which i think was often editorial to improve text quality. Instead, i'll try below to raise mostly functional issues in the core spec. Feel free to also go back to the -05 review and check if stuff from there is still relevant. Some better tracking of what feedback was or was not taken into account would be helpful. Cheers Toerless idnits 2.17.1 draft-ietf-anima-brski-cloud-08.txt: Checking references for intended status: Proposed Standard == Outdated reference: A later version (-07) exists of draft-ietf-lamps-rfc7030-csrattrs-06 -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. 2 Network Working Group O. Friel 3 Internet-Draft Cisco 4 Intended status: Standards Track R. Shekh-Yusef 5 Expires: 25 February 2024 Auth0 6 M. Richardson 7 Sandelman Software Works 8 24 August 2023 10 BRSKI Cloud Registrar 11 draft-ietf-anima-brski-cloud-08 13 Abstract 15 Bootstrapping Remote Secure Key Infrastructures defines how to 16 onboard a device securely into an operator maintained infrastructure. 17 It assumes that there is local network infrastructure for the device 18 to discover and to help the device. This document extends the new 19 device behaviour so that if no local infrastructure is available, 20 such as in a home or remote office, that the device can use a well 21 defined "call-home" mechanism to find the operator maintained 22 infrastructure. 24 To this, this document defines how to contact a well-known Cloud 25 Registrar, and two ways in which the new device may be redirected 26 towards the operator maintained infrastructure. 28 About This Document 30 This note is to be removed before publishing as an RFC. 32 Status information for this document may be found at 33 https://datatracker.ietf.org/doc/draft-ietf-anima-brski-cloud/. 35 Discussion of this document takes place on the anima Working Group 36 mailing list (mailto:anima@ietf.org), which is archived at 37 https://mailarchive.ietf.org/arch/browse/anima/. 39 Source for this draft and an issue tracker can be found at 40 https://github.com/anima-wg/brski-cloud. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on 25 February 2024. 59 Copyright Notice 61 Copyright (c) 2023 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents
