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

[Eric Rescorla]

On Fri, Apr 6, 2018 at 7:19 AM, Di Ma  wrote:

> >
> >  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?
> >
> >
>
> Duplicate assertions are idempotent, but the RPKI to Router Protocol
> explicitly filters out duplicates in the communication with the router.
>

Hmm... That's not how I read this text. I read it rather that if the same
exceptions
in two files, it caused an error. So maybe some clarification needed.

-Ekr


> Di
>
>
>
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

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

[Eric Rescorla]

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"

   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?


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr