Simplified Local Internet Number Resource Management with the RPKI (SLURM)
RFC 8416

Received changes through RFC Editor sync (created alias RFC 8416, changed title to 'Simplified Local Internet Number Resource Management with the RPKI (SLURM)', changed abstract to 'The Resource Public Key Infrastructure (RPKI) is a global authorization infrastructure that allows the holder of Internet Number Resources (INRs) to make verifiable statements about those resources.  Network operators, e.g., Internet Service Providers (ISPs), can use the RPKI to validate BGP route origin assertions.  ISPs can also use the RPKI to validate the path of a BGP route.  However, ISPs may want to establish a local view of exceptions to the RPKI data in the form of local filters and additions.  The mechanisms described in this document provide a simple way to enable INR holders to establish a local, customized view of the RPKI, overriding global RPKI repository data as needed.', changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2018-08-07, changed IESG state to RFC Published)

[Ballot comment]
Thank you for addressing my concerns / DISCUSS - I'm clearing my position.

W
-----

I have a few questions and editorial comments:

1: Section Abstract:
ISPs can also be able to use the RPKI to validate the path of a BGP route.
I think you meant "ISPs can also use the RPKI..."

2: Section 1.  Introduction
"However, an "RPKI relying party" (RP) may want to override some of the information expressed via putative Trust Anchor(TA) and the certificates downloaded from the RPKI repository system."
I think this should be either "a putative Trust Anchor (TA)" or "putative Trust Anchors (TA)" (single vs plurals). I agree with others that "putative TA" is not a well known term - perhaps you can find a better one?

Section 3.4.1.  Validated ROA Prefix Filters
In the "prefixFilters examples", I think it would be helpful to update the comments to be more explicit about what is being matched (e.g"All VRPs covered by 198.51.100.0/24 and matching AS 64497")



--- Original DISCUSS for hysterical raisins ---
I don't understand the targeting as it related to domain/host names (and suspect that others will have the same issue).

From section 3.3:
"  If a "slurmTarget" element is
  present, an RP SHOULD verify that the target is an acceptable value,
  and reject this SLURM file if the "slurmTarget" element is not
  acceptable.... Accordingly, the SLURM file
  source needs to indicate which RP(s) should make use of the file by
  adding the domain name(s) of the RP(s) to the SLURM file target...
  Such a target value is a server name expressed in FQDN.

  "slurmTarget": [
    {
      "hostname": "rpki.example.com",
      "comment": "This file is intended for RP server rpki.example.com"
    }
] 

So, if I want to target multiple RPs (rpki1.example.com, rpki2.example.com) can I do:

  "slurmTarget": [
    {
      "hostname": "example.com",
      "comment": "This file is intended for RP server rpki.example.com"
    }
]

?
The "domain names(s)" versus "hostname" vs "server name expressed in FQDN" text is handwavey.
I'm assuming that I'd need to do:

  "slurmTarget": [
    {
      "hostname": "rpki1.example.com",
      "comment": "This file is intended for RP server rpki1.example.com"
    },
{
      "hostname": "rpki2.example.com",
      "comment": "This file is intended for the RP server, rpki2.example.com"
    },
]"
Can you please make this clearer, and hopefully add more targets to the examples?
This seems like an easy fix / clarification, happy to clear once it is, er, clear.

[Ballot discuss]
Thanks to everyone who worked on this document. The mechanism seems useful.

I'm concerned that the document doesn't describe the file format itself;
rather, it relies on examples to provide vital, nonsupplemental information
such as the names of JSON object members, expected encodings (e.g., strings
versus numbers), and distinction between arrays and objects. I'm making this a
DISCUSS because I think the ambiguity here -- and, in particular the ambiguity
about IP address prefix notation -- will lead to non-interoperable
implementations.

Using section §3.2 as an example:

>  A SLURM file consists of:
>
>  o  A SLURM Version indication that MUST be 1
>
>  o  A slurmTarget element (Section 3.3) consisting of:
>
>      *  Zero or more target elements.  In this version of SLURM, there
>        are two types of values for the target: ASN or Fully Qualified
>        Domain Name(FQDN).  If more than one target line is present,
>        all targets MUST be acceptable to the RP.
>
>  o  Validation Output Filters (Section 3.4), consisting of:
>
>      *  An array of zero or more Prefix Filters, described in
>        Section 3.4.1
>
>      *  An array of zero or more BGPsec Filters, described in
>        Section 3.4.2
>
>  o  Locally Added Assertions (Section 3.5), consisting of:
>
>      *  An array of zero or more Prefix Assertions, described in
>        Section 3.5.1
>
>      *  An array of zero or more BGPsec Assertions, described in
>        Section 3.5.2
>

As this is the normative description of the structure, I would have expected an
indication that the file contains a JSON object (rather than, say, a JSON
array), an indication that the version is to be encoded as a number (rather than
a string), and clarification of what value members are expected to contain.

For example, the following JSON object is in compliance with the preceding
normative description (and, as far as I can tell, all other normative text
in the document):

["1",
  ["65536", "rpki.example.com"],
  [
    ["192.0.2.0/255.255.255.0", "All VRPs encompassed by prefix"],
    ["64496", "All VPRs maching ASN"],
    ["198.51.100.0/255.255.255.0", "64497", "All VRPs encompassed by prefix,
      matching ASN"]
  ],
  [
    ["64496", "All keys for ASN"],
    ["Zm9v", "Key matching Router SKI"],
    ["64497", "YmFy", "Key for ASN 64497 matching Router SKI"],
  ],
  [
    ["64496", "198.51.100.0/255.255.255.0", "My other important route"],
    ["64496", "2001:DB8::/FFFF:FFFF::", "48",
    "My other important de-aggregated routes"],
  ],
  [
    ["64496", "My known key for my important ASN",
    "", ""]
  ]
]

Fixing this should be pretty easy; the document simply needs text added that
describes the JSON structure explicitly, with clear indications of how values
are to be encoded. For example, the preceding text I quote becomes:

  A SLURM file consists of a single JSON object containing the following
  members:

  o  A  "slurmVersion" member that MUST be set to 1, encoded as a number

  o  A "slurmTarget" member (Section 3.3) If more than one target line is
      present, all targets MUST be acceptable to the RP. The "slurmTarget"
      member is encoded as an array of zero or more objects. Each object in the
      array contains exactly one member.  In this version of SLURM, the member
      may be named either:

      * "asn", in which case it contains an ASN, or

      * "hostname", in which case it contains a Fully Qualified Domain
        Name (FQDN).

  o  A "validationOutputFilters" member (Section 3.4), whose value is an
      object. The object MUST contain exactly two members:

      *  A "prefixFilters" member, whose value is described in
        Section 3.4.1

      *  A "bgpsecFilters" member, whose value is described in
        Section 3.4.2

  o  A "locallyAddedAssertions" member (Section 3.5), whose value is an
      object. The object MUST contain exactly two members:

      *  A "prefixAssertions" member, whose value is described in
        Section 3.5.1

      *  A "bgpsecAssertions" member, whose value is described in
        Section 3.5.2


Gotchas to watch out for include:

- If you're using the word "element" to describe something in a JSON object,
  you probably need to find a more specific word. This document, for example,
  uses "element" instead of "member" in most places.

- Everywhere you use the word "structure," replace it with either "array" or
  "object," as appropriate.

- When values can be encoded as either a number or a string (e.g., as with
  "slurmVersion" above, or with AS numbers), indicate which encoding is
  expected.

- For IP prefixes, be clear about acceptable syntax. For example: is
  the RFC 950 syntax ("192.0.2.0/255.255.255.0") acceptable? My suggestion is
  to cite RFC 4632 §3.1 for prefix-length notation (both for IPv4 and IPv6),
  and RFC 5952 for the syntax of IPv6 addresses.

[Ballot comment]
The remaining comments are in document order.

---------------------------------------------------------------------------

Title:

It seems odd to use the stylized capitalization (e.g., "nUmber") without
following it by the "SLURM" acronym. Consider adding "(SLURM)" to the title.

---------------------------------------------------------------------------

§3.1:

>  This document describes responses in the JSON [RFC8259] format.

I don't think this means to say "responses," does it? It appears to be
describing a JSON document rather than a request/response protocol.


---------------------------------------------------------------------------

§3.3:

>  A SLURM file MUST specify a "slurmTarget" element that identifies the
>  environment in which the SLURM file is intended to be used.  The
>  "slurmTarget" element MAY have an empty array as its value, which
>  means "applies to all".  The meaning of the "slurmTarget" element, if
>  present, is determined by the user.  If a "slurmTarget" element is
>  present, an RP SHOULD verify that the target is an acceptable value,
>  and reject this SLURM file if the "slurmTarget" element is not
>  acceptable.  Each "slurmTarget" element contains merely one "asn" or
>  one "hostname".  An explanatory "comment" MAY be included in each
>  "slurmTarget" element so that it can be shown to users of the RP
>  software.

When reworking this paragraph in particular, please be careful to distinguish
between the "slurmTarget" member and the elements in the array that constitutes
its value. The preceding text calls both of these things '"slurmTarget"
element,' which is very confusing.

[Ballot comment]
Major Comments:

§6: I also agree with Benjamin's sadness about the security considerations. The section really should at least discuss the potential consequences of an adversary inserting a false slurm file, modifying one on the fly, or eavesdropping on one.

Minor Comments:

§1.1: The document contains at least a few lower case instances of "must". Please consider using the boilerplate from RFC 8174.

§3.3, 1st paragraph: "RP SHOULD verify that the target is an acceptable value"
What is the criteria for acceptability?

§8.2, " [RFC4648]": The document requires Base64 encoding. Doesn't that make this a normative reference?

Editorial Comments and Nits:

[significant] Abstract (and throughout the document):

I don't find the term "local view of the RPKI" to be descriptive. IIUC, we are talking about overriding assertions that come from the RPKI based on local (or possibly 3rd party) knowledge. This seems to me to be a different thing than providing a "local view of the RPKI", and I certainly would not have gotten a sense of that difference from the Abstract alone, and possibly not the introduction.

§1, last paragraph: Please expand or define rpki-rtr on first mention.

§3.4.1: Please expand SKI on first mention. (You do so in the second mention :-) )

[Ballot comment]
  path of a BGP route.  However, ISPs may want to establish a local
  view of the RPKI to control its own network while making use of RPKI
  data.  The mechanisms described in this document provide a simple way

Nit: their network


  the information expressed via putative Trust Anchor(TA) and the
  certificates downloaded from the RPKI repository system.  For
  instances, [RFC6491] recommends the creation of ROAs that would

I don't really understand this sentence. Why "putatve"


  operators are hereby called Simplified Local internet nUmber Resource
  Management with the RPKI (SLURM).

It would help here to say that this includes filtering.



  In general, the primary output of an RP is the data it sends to
  routers over the rpki-rtr protocol.  The rpki-rtr protocol enables
  routers to query an RP for all assertions it knows about (Reset

citation for rpki-rtr plese.



  members that are not defined here MUST NOT be used in SLURM Files.
  An RP MUST consider any deviations from the specification an error.
  Future additions to the specifications in this document MUST use an

Nit: errors.



  acceptable.  Each "slurmTarget" element contains merely one "asn" or
  one "hostname".  An explanatory "comment" MAY be included in each
  "slurmTarget" element so that it can be shown to users of the RP

Is this exclusive or?



  Emergency Response Team Coordination, the SLURM file source may
  generate a SLURM file that is to be applied to only one specific RP.
  This file can take advantage of the "target" element to restrict the

I am having trouble reading this sentence. Can you please rephrase.



  [RFC6487].  This is the value of the ASN.1 OCTET STRING without the
  ASN.1 tag or length fields.
IMPORTANT: There is an opportunity for ambiguity here in case the SPKI was not DER-encoded. I assume you mean this must be taken directly from the cert?



  The following JSON structure represents an array of
  "prefixAssertions" with an element for each use case listed above:

I guess that the semantics here are obvious, but perhaps you could state them explicitly, given that this is actually not exactly the same as an ROA.



3.5.2.  BGPsec Assertions
IMPORTANT: It seems even less obvious what the semantics are here for injecting BGPSec assertions. How do you reconstruct the BGPSec data.



          contained by any prefix in any  or
          in file Z.

OK, so you are going to error out even if there are assertions which are identical?

[Ballot comment]
I agree with Warren's DISCUSS.

I also share Benjamin's sadness about the Security Considerations section.

Additionally, one little, but important thing that I would like you to fix:

In Section 3.4.2 and 3.5.2, when referencing Base64 [RFC4648], you need to specify which version you are using. I think you want to use the version in Section 4 (and not Section 5) of this document. It would also be useful to specify whether trailing "=" need to be present in base64 values.

[Ballot comment]
I agree with Warren's DISCUSS.

Additionally, one little, but important thing that I would like you to fix:

In Section 3.4.2 and 3.5.2, when referencing Base64 [RFC4648], you need to specify which version you are using. I think you want to use the version in Section 4 (and not Section 5) of this document. It would also be useful to specify whether trailing "=" need to be present in base64 values.

[Ballot discuss]
I don't understand the targeting as it related to domain/host names (and suspect that others will have the same issue).

From section 3.3:
"  If a "slurmTarget" element is
  present, an RP SHOULD verify that the target is an acceptable value,
  and reject this SLURM file if the "slurmTarget" element is not
  acceptable.... Accordingly, the SLURM file
  source needs to indicate which RP(s) should make use of the file by
  adding the domain name(s) of the RP(s) to the SLURM file target...
  Such a target value is a server name expressed in FQDN.

  "slurmTarget": [
    {
      "hostname": "rpki.example.com",
      "comment": "This file is intended for RP server rpki.example.com"
    }
] 

So, if I want to target multiple RPs (rpki1.example.com, rpki2.example.com) can I do:

  "slurmTarget": [
    {
      "hostname": "example.com",
      "comment": "This file is intended for RP server rpki.example.com"
    }
]

?
The "domain names(s)" versus "hostname" vs "server name expressed in FQDN" text is handwavey.
I'm assuming that I'd need to do:

  "slurmTarget": [
    {
      "hostname": "rpki1.example.com",
      "comment": "This file is intended for RP server rpki1.example.com"
    },
{
      "hostname": "rpki2.example.com",
      "comment": "This file is intended for the RP server, rpki2.example.com"
    },
]"
Can you please make this clearer, and hopefully add more targets to the examples?
This seems like an easy fix / clarification, happy to clear once it is, er, clear.

[Ballot comment]
I have a few questions and editorial comments:

1: Section Abstract:
ISPs can also be able to use the RPKI to validate the path of a BGP route.
I think you meant "ISPs can also use the RPKI..."

2: Section 1.  Introduction
"However, an "RPKI relying party" (RP) may want to override some of the information expressed via putative Trust Anchor(TA) and the certificates downloaded from the RPKI repository system."
I think this should be either "a putative Trust Anchor (TA)" or "putative Trust Anchors (TA)" (single vs plurals). I agree with others that "putative TA" is not a well known term - perhaps you can find a better one?

Section 3.4.1.  Validated ROA Prefix Filters
In the "prefixFilters examples", I think it would be helpful to update the comments to be more explicit about what is being matched (e.g"All VRPs covered by 198.51.100.0/24 and matching AS 64497")

[Ballot comment]
The directorate reviews have some good comments, especially about expanding acronyms/defining terms.

I think Section 3.3 would benefit from greater clarity about individual components of the JSON array that is the
value of the "slurmTarget" element, versus that element itself.  (Also, slurmTarget appears to be mandatory,
so talking about cases where it is present seems strange, and presumably a nonempty value being present is
the desired criterion.)

I'm also not entirely sure I understand the intended semantics --
when first introduced in Section 3.2, we say that "all targets MUST
be acceptable to the RP".  (Presumably that includes both ASN and
FQDN entries.) Does this mean that if the same SLURM file is
provided to multiple RPs, those RPs both need to be "responsible
for" all the ASNs and FQDNS contained therein?  Would this present a
limit on the ability to reuse SLURM files for multiple recipients
within a single administrative domain (that may span multiple ASNs
and FQDNs)?

Some editorial suggestions follow.

Abstract:

OLD:

  [...] ISPs can also be able to use the RPKI to validate the
  path of a BGP route.

NEW:

  [...] ISPs can also use the RPKI to validate the
  path of a BGP route.

Section 3.2

OLD:
  o  A SLURM Version indication that MUST be 1

NEW:
  o  A SLURM Version indication.  This document specifies version 1.

Also, in

      *  Zero or more target elements.  In this version of SLURM, there
        are two types of values for the target: ASN or Fully Qualified
        Domain Name(FQDN).  If more than one target line is present,
        all targets MUST be acceptable to the RP.

What's the difference between a target element and a target line?

Section 3.5 (both subsections):

"is locally configured with" does not mention SLURM at all as being
involved in that configuration; perhaps it should.

Section 4.2

  [...] To do so, the RP MUST
  check the entries of SLURM file with regard to overlaps of the INR
  assertions and report errors to the sources that created these SLURM
  files in question.

The "report errors to the sources" part seems ineligible for
MUST-level requirement.

Also, in case of conflict, does the "MUST NOT use them" apply to all
SLURM files, only the ones with directly conflicting inputs, or only
enough files to remove the conflict?

Section 6

I'm always a little sad to see security-relevant functionality (such
as the transport with authenticity and integrity protection of SLRUM
files over the network) left as out of scope with no examples of
reasonable usage given.

I also wonder if we would benefit from a little discussion of the
potential routing issues that could arise from using a "broken" (or
deliberately adversarial) SLURM file, though I expect that the
target audience is probably pretty familiar with these already.

[Ballot comment]
A few comments:

1. Document uses all capital form of AND for filters containing both prefixes and ASNs, and filters containing ASNs and SKIs. That is not part of RFC2119 language.

2. s/Route Origination Authorization/Route Origin Authorization

3. If a local assertion is added without a matching filter, does it take priority over existing assertion?

4. The term 'putative TA' has been flagged a couple of times in various reviews as being not known. It does not appear to be formally defined, RFC7730 seems to be the closest source - while it is not formally defined there either.

[Ballot comment]
A few comments:

1. Document uses all capital form of AND for filters containing both prefixes and ASNs, and filters containing ASNs and SKIs. That is not part of RFC2119 language.

2. s/Route Origination Authorization/Route Origin Authorization

3. If a local assertion is added without a matching filter, does it take priority over existing assertion?

4. A term 'putative TA' has been flagged a couple of times in various reviews as being not known. It does not appear to be formally defined, RFC7730 seems to be the closest source - while it is not formally defined there either.

[Ballot comment]
A few comments:

1. Document uses all capital form of AND for filters containing both prefixes and ASNs, and filters containing ASNs and SKIs. That is not part of RFC2119 language.
2. s/Route Origination Authorization/Route Origin Authorization
3. If a local assertion is added without a matching filter, does it take priority over existing assertion?
4. A term 'putative TA' has been flagged a couple of times in various reviews as being not known. It does not appear to be formally defined, RFC7730 seems to be the closest source - while it is not formally defined there either.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-sidr-slurm-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-02-21):

From: The IESG
To: IETF-Announce
CC: draft-ietf-sidr-slurm@ietf.org, aretana.ietf@gmail.com, morrowc@ops-netman.net, Chris Morrow , sidr-chairs@ietf.org, sidr@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Simplified Local internet nUmber Resource Management with the RPKI) to Proposed Standard


The IESG has received a request from the Secure Inter-Domain Routing WG
(sidr) to consider the following document: - 'Simplified Local internet
nUmber Resource Management with the RPKI'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-02-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  The Resource Public Key Infrastructure (RPKI) is a global
  authorization infrastructure that allows the holder of Internet
  Number Resources (INRs) to make verifiable statements about those
  resources.  Network operators, e.g., Internet Service Providers
  (ISPs), can use the RPKI to validate BGP route origination
  assertions.  In the future, ISPs also will be able to use the RPKI to
  validate the path of a BGP route.  However, ISPs may want to
  establish a local view of the RPKI to control its own network while
  making use of RPKI data.  The mechanisms described in this document
  provide a simple way to enable INR holders to establish a local,
  customized view of the RPKI, overriding global RPKI repository data
  as needed.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/ballot/


No IPR declarations have been submitted directly on this I-D.

=== AD Review of draft-ietf-sidr-slurm-04 ===
https://mailarchive.ietf.org/arch/msg/sidr/K7y1URe1tkh78vjHhZHAIJJ6L4M/?qid=36ea3c3d3fe32249b4cb2494651338ab

Dear authors:

I just finished reading this document.

I have some comments (below) that should be easy to address — please take a
look.  I need you to address the References before I start the IETF Last
Call because of the DownRef to rfc6483.

Thanks!

Alvaro.



Major:

M1. Section 3.1:  I'm not sure what the Normative result is form this piece
of text: "JSON members that are not defined here MUST not be used in SLURM
Files, however Relying Parties SHOULD ignore such unrecognized JSON members
at the top level, while any deviations from the specification at lower
levels MUST be considered an error."  (s/MUST not/MUST NOT)  If the not
defined members MUST NOT be used, when would the RPs not ignore (or even
better, treat as errors) them?  IOW, why use SHOULD instead of MUST?


M2. Section 4.2: "Before an RP configures SLURM files from different source
it MUST make sure there is no internal conflict among the INR assertions in
these SLURM files.  To do so, the RP SHOULD check the entries of SLURM
file..."  I think there's a Normative mismatch: "MUST make
sure...no...conflict" vs "SHOULD check the entries"; the SHOULD leaves the
door open to not always checking -- are there cases when the entries
wouldn't be checked *and* the MUST can still be guaranteed?  It seems to me
like both keywords should be MUST.


M3. Section 6: "...but if the RP updates its SLURM file over the network,
it MUST verify the authenticity and integrity of the updated SLURM file."
Please indicate that the mechanism to update files, and the
authentication/integrity verification are outside the scope of this
document.


M4. References:

M4.1. s/I-D.ietf-sidr-bgpsec-overview/rfc8205  ...and should be Normative.

M4.2. I believe the following references should also be Normative:
ietf-sidr-rpki-rtr-rfc6810-bis/rfc8210, rfc6483, rfc6810, rfc6811 and
rfc7159.

M4.3. [minor] Please update the references according to the Nits [1].

[1]
https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-sidr-slurm-04.txt





Minor:

P1. "Relying party software MAY modify other forms of output in comparable
ways, but that is outside the scope of this document."  If it's out of
scope, then there shouldn't be any Normative language. s/MAY/may

P2. "Locally Added Assertions" are sometimes called "Locally Adding
Assertions".


Nits:

N1. s/control make use of RPKI data/control use of RPKI data

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 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?

Internet Standard

(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

  The Resource Public Key Infrastructure (RPKI) is a global
  authorization infrastructure that allows the holder of Internet
  Number Resources (INRs) to make verifiable statements about those
  resources.  Network operators, e.g., Internet Service Providers
  (ISPs), can use the RPKI to validate BGP route origination
  assertions.  In the future, ISPs also will be able to use the RPKI to
  validate the path of a BGP route.  However, ISPs may want to
  establish a local view of the RPKI to control its own network while
  making use of RPKI data.  The mechanisms described in this document
  provide a simple way to enable INR holders to establish a local,
  customized view of the RPKI, overriding global RPKI repository data
  as needed.

Working Group Summary

  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 working group discussion was a bit long for this draft, and eventually concluded successfully.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? 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?

there is no protocol here, just a method of implementing a local Trust anchor for rpki/bgpsec/sidr operations.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Shepherd: chris morrow (morrowc@ops-netman.net)
ResponsibleAD: Alvaro Retana (aretana@cisco.com)

(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.

The shepherd has read the document a few times during it's lifecycle, it seems in good shape and seems to fulfill a real need in the space.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

nope.

(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.

they do not.
if a JSON person wants to review section: 3
that would be fine, too, though :)


(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 concernts

(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

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

no 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? 


as with all SIDR documents, consensus was reached...after a time :)

(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 threats of appeal/etc.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.


There's one 2119 language issue which the authors are addressing and the normal 'this id is actually a later version now' stuff  that auth48 catches with get.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

no formal review required, but the json folk could review if they are feeling peppy. :)

(13) Have all references within this document been identified as
either normative or informative?

yes

(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?

no, though waiting on algs/profiles (two bgpsec docs) would be nice.

(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.

no

(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

(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).

no considerations to consider! win!

(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.

none

(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.

The json examples seem ok to e and to a validator, but as before if somene in json land is feeling frisky please feel free to review :)