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

[Benjamin Kaduk]

Hi Di,

Thank you for the extra clarification.  I think that my question is
basically the same as in Warren's DISCUSS, so perhaps we should let
this thread stop and just have the discussion on that thread.

Having said that, I think my question was more about the case when
there were two differet elements in the slurmTarget array, with
different hostnames in them -- exactly as Warren lays out at the end
of his DISCUSS.

Thanks again,

Benjamin

On Sat, Mar 31, 2018 at 03:49:39AM +0800, Di Ma wrote:
> Benjamin,
> 
> Thanks very much for your comments.
> 
> I will exchange notes with co-authors on your editorial suggestions.
> 
> Yet as for your question about slurmTarget, here is the explanation.
> 
> First of all, the FQDN is used by the SLURM file distributor to determine 
> which RP will use this slurm file, noting that RP is identified by FQDN. 
> 
> People might think this design is sort of redundancy, arguing that if the 
> SLURM file distributor does not want a specific RP to effect SLURM, just not 
> do that, why bother to throw this file to that RP, indicating ’this file is 
> not for you’.
> 
> The reason why we do this is to provide the scalability for SLURM in 
> operations.
> 
> Given a SLURM file distributor service several RPs and SLURM file need to 
> change at times to reflect local policy. 
> 
> An easy to do so is that all the registered RPs simply synchronize with SLURM 
> file distributor, telling from the slurmTarget to decide whether to effect ‘a 
> specific version’ of slurm file 'this time'. 
> 
> All in all, to answer your question, if the same SLURM file is provided to 
> multiple RPs, those RPs identified by FQDN, will first to see whether ‘this 
> version’ of slurm file is for itself 'this time'. 
> 
> And then an RP uses this slurm file to form different views for different BGP 
> speakers as specified by slrumtarget ASN.
> 
> BTW, as stated in the document, if the operator does not want to use 
> slrumtarget ‘hostname’ to gain management granularity, just not put it into a 
> slrumtarget element.
> 
> I hope my clarification is making sense here.
> 
> Di
> 
> 
> > 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)?
> 
> 
> 
> Di  Ma
> RPSTIR
> https://bgpsecurity.net
> 
> > 在 2018年3月31日，01:54，Benjamin Kaduk  写道：
> > 
> > Benjamin Kaduk 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:
> > --
> > 
> > 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
> > 

[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

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

[Alexey Melnikov]

Alexey Melnikov 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:
--

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.


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