Re: [sidr] Eric Rescorla's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT)

[Di Ma <[e-mail]>]

Eric,

Thanks very much for your comments.

Please see authors' responses in lines.

> 在 2018年4月3日，00:56，Eric Rescorla <[e-mail]> 写道：
> 
> Eric Rescorla has entered the following ballot position for
> draft-ietf-sidr-slurm-07: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/
> 
> 
> 
> ----------------------------------------------------------------------
> 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"


We authors will go with “configured Trust Anchor(s) (TAs)”

> 
>   operators are hereby called Simplified Local internet nUmber Resource
>   Management with the RPKI (SLURM).
> 
> It would help here to say that this includes filtering.
> 

We will make changes as follows:

OLD:
  This motivates creation of mechanisms that enable a network operator to
  publish a variant of RPKI hierarchy (for its own use and that of its customers)
  at its discretion.

NEW:
  This motivates creation of mechanisms that enable a network operator to
  publish exception to the RPKI in the form of filters and additions (for its own
  use and that of its customers) at its discretion.


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

ACK. 

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

ACK. 

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


We authors have decided to drop slurmTarget element.


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

Good point. 

We will say in next version:

The Router SKI is the Base64 encoding without trailing ‘=‘ (Section 5 of RFC4648 ) of the certificate’s Subject Public Key as described in Section 4.8.2. of RFC6487. 

The Router Public Key is router public key’s subjectPublicKeyInfo value, as described in RFC8208. This is the full ASN.1 DER encoding of the subjectPublicKeyInfo, including the ASN.1 tag and length values of the subjectPublicKeyInfo SEQUENCE.


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

ACK. 

And we will update JSON related content throughout this draft based on your suggestion together with Adam’s. 


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

We will make changes as follows:

OLD:
  Each RP is locally configured with a (possibly empty) array of BGPsec
  Assertions.  This array is added to the RP's output.

NEW:
  Each RP is locally configured with a (possibly empty) array of BGPsec
  Assertions.  Each BGPSec Assertion contains the same data that would
  otherwise be extracted from a BGPSect Router Certificate [RFC8209]
  and communicated in the RPKI to Router Protocol version 1 protocol
  [RFC8210].


> 
>          contained by any prefix in any <prefixAssertions> or
>          <prefixFilters> in file Z.
> 
> OK, so you are going to error out even if there are assertions which are
> identical?
> 
> 

Duplicate assertions are idempotent, but the RPKI to Router Protocol
explicitly filters out duplicates in the communication with the router.

Di