v1.1 8/20/2018 removed concern about "voucher" registry in IANA section. Fixed in -17 rev of document. It is now a BRSKI registry with a voucher status telemetry table (perfect). Added NIT about request details though (see NITS section). Recommended Max/Michael as expert reviewers for new IANA registry (BRSKI parameters). Removed NITs about down-references (fixed in -17). removed NIT about Pledge authorization (fixed in -17).
v1.0 Original version 7/25/2018
Shepherd writeup for For draft-ietf-anima-bootstrapping-keyinfra-16
Shepherd: Toerless Eckert, email@example.com
> https://www.ietf.org/iesg/template/doc-writeup-qa-style.html of 24 February 2012.
> (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
RFC type requested: Proposed Standard. Correctly indicated in title page header.
This document describes a protocol based on EST/RFC730 run between nodes of different
roles - pledge, registrar, masa, proxy. It is intended to be useable across all type of
networks and requires standardization for products of all roles from different vendors.
> (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:
> Technical Summary:
This document specifies automated bootstrapping of a remote secure
key infrastructure (BRSKI) using manufacturer installed X.509
certificate, in combination with a manufacturer's authorizing
service (MASA), both online and offline. Bootstrapping a new device can
occur using a routable address and a cloud service, or using only
link-local connectivity, or on limited/disconnected networks.
Support for lower security models, including devices with minimal
identity, is described for legacy reasons but not encouraged.
Bootstrapping is complete when the cryptographic identity of the new
key infrastructure is successfully deployed to the device but the
established secure connection can be used to deploy a locally issued
certificate to the device as well.
> Working Group Summary:
This document was called draft-pritikin-anima-bootstrapping-keyinfra before it was
adopted. There was unanimous support for it in favor of adoption and
none against, so this document was adopted by the ANIMA WG in February 2016.
There was ongoing interest in this work posts since its adoption. There was never
any opposition for this work. Since it adoption, a core mechanism of the
work called the voucher was seen as useful that it was forked off into a separate
document, which is now https://www.rfc-editor.org/rfc/rfc8366.txt after it was
determined that there wa interest to not only use it in this documents protocol
BRSKI, but also in draft-ietf-netconf-zerotouch.
This document went through a long and intense document development
period (9 months for individual document period, 28 months for WG
document period). It has been reviewed well and passed last call without
> Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?
The most important change process was the above mentioned fork of the voucher
text from the document. The concept itself grew through the WG work on the
BRSKI document. BRSKI also inspired derived work in further working groups
There was no noteworthy controversy about items of the document, instead, optional
elements that could have delayed the document where forked off into future work
(e.g. IPinIP proxy).
> Document Quality:
> Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification?
There is a range of existing implementations, and seemingly vendors working on BRSKI.
Here are points from the mail thread opened during WG last call.
Starting with <firstname.lastname@example.org>
(WG Last Call on draft-ietf-anima-bootstrapping-keyinfra-15 -> references to code)
Toerless: github.com/cisco/libest supports BRSKI
Brian Carpenter, GRASP part of BRSKI: https://github.com/becarpenter/graspy
Eliot Lear: I have reviewed the document and we have a PoC. I am also aware of
others that have done PoC code.
Eliot Lear: The 2nd piece of code is not open source and not by Cisco.
Michael Richardson (<1234.1527803470@localhost>): https://minerva.sandelman.ca/
there are two MASA "live" on the Internet, see:
- more technical explanation in his email.
An overview of other efforts inspired or related to BRSKI can be found in
> Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?
The document received numerous detailed reviews during its WG time, including,
but not limited to the reviews by Brian Carpenter and the Shepherd, with the
conclusion that the document has no substantive issues.
There was no dedicated expert review for BRSKI IANA allocation requests. There was
YANG review for Voucher RFC8366 which BRSKI inherits and extends so BRSKI YANG complies
to the YANG review conclusions from RFC8366.
> Who is the Document Shepherd? Who is the Responsible Area Director?
Document Shepherd: Toerless Eckert
Responsible Area Director: Ignas Bagdonas
> (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
First shepherd review from 2017:
Second shepherd review 2018:
Shepherd also parrticipated often in the authors ongoing work meeting
and provided input.
Summary: extensive repeated shepherd review, primarily focussed on document clarity,
correct integration with the other ANIMA charter items and various technical
an formalistic details.
> (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No concerns. The document is comprehensive and conclusive.
> (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
The shepherd thinks that standard IESG review is appropriate. The three
key areas are OPS and SEC:
Operational complexity review: Baked into the documents goal and WG process:
This document automates often very painfull manual processes (secure device enrollment),
so the WG thinks that the document actually is a solution and not a perpetrator
wrt. operational complexity.
Being in OPS, the design choices by the authors and WG did focus on this aspect.
Pretty much all of the options in the document address the problem of allowing
deployability in different operational environment (specifically different
form of vouchers and discovery).
There was to the memory of the shepherd no prior external (non-WG) SEC review
for BRSKI, but the fundamental new security concept voucher introduced for
BRSKI is already an RFC (8366), which includes a SEC review understanding the
whole concept how the voucher is used in BRSKI. The authors also include experts
of prior security protocol standards (e.g.: RFC7030).
> (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
No concerns by the document shepherd or the WG (in the memory of the shepherd).
> (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
Yes. The authors, have confirmed in writing or verbally that they are not aware
of other IPR than what is listed on datatracker:
> (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
The Cisco and Silver Sprint disclosures where brought up by the WG when they
where filed (2014/2016) with no concerns raised. All three IPR where brought
up during Shepherd Writeup when it was it was discovered that the Juniper
IPR had only been disclosed against draft-netconf-zerotouch (which shares the
voucher with BRSKI). Juniper immediately also filed the disclosure against BRSKI
because it might be applicable to BRSKI to. No concerns against the document
processing where raised because of any of the disclosures.
> (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
There is broad support for this document. It was reviewed by active WG
> (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No. There was unanimous support for this work and nobody raised any objections.
> (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
This document is now free of officially tracked nits.
There is a small number of other nits discoverded through this shepherd writeup,
the authors have been asked to fix them in the next rev, and this email
is appended at the end of this writeup.
> (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.
The document requires IANA review and YANG doctor review.
Datatracker already shows the included YANG definitions to pass YANG validation.
> (13) Have all references within this document been identified as either normative or informative?
> (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
> (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
rfc7228 defined terminology is used in this document and therefore that
document is listed as a normative reference even though it is an informational
document. Shepherd thinks this is appropriate because this documents terminology is now widely
accepted and there is no standard document alternative for this terminology.
> (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
No change to existing RFCs suggested.
> (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).
The All requests in IANA section are correct correct except for the request details for the voucherstatustelemetry. See NITs below.
> (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
The new registry requested is "BRSKI parameters". Shepherd suggests to list two volunteering authors as experts: Max Pritkin and Michael Richardson.
> (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.
YANG definitions in the document where generated by YANG toolchain and
are passing datatracker syntax check. For source of toolchain see:
A) - D) resolved
E.1) The text for for requesting pledgestatustelemtry is ok (reigstry+table), but
i think the text for decribing how the table should look like is
The text is just requesting some initial values(version,...), but no
context associated with it.
A comparable JSON table is requested in rfc7519 section 10.1. In
subsection 10.1.1 is defines the requested registration template,
which include (using current BRSKI terminology): "item", "item description",
"change controller", "specification document(s)".
Resulting registry is in https://www.iana.org/assignments/jwt/jwt.xhtml
I would suggest to amend the IANA section text to match such an example
in spirit. The four columns in rfc7519 look reasonable. IMHO the "item"
and "specification document" are mandatory, "change controller" is
very useful, "description" is nice to have.
E.2) There are two unclear text tags in the PKIX registry text:
EDNOTE (if this is meant to be an AUTH48 or RFC-editor action, please change tag accordingly).