Re: [sidr] [Sidrops] [Technical Errata Reported] RFC8416 (7080)

[Di Ma]

I have got no objection to this erratum as the co author of RFC8416. Thanks go 
to Ben for catching this. 

And this update will not affect RPSTIR2 as we check it.

Anyway, I think this discussion will help to update SLURM in support of ASPA in 
next version as Tim mentioned.

Di

> 2022年8月22日 16:47，Ties de Kock  写道：
> 
> Hi Tim, all,
> 
>> On 22 Aug 2022, at 10:29, Tim Bruijnzeels  wrote:
>> 
>> Hi Warren, all,
>> 
>> I (co-author) agree that this was an oversight. I have no objections to the 
>> change.
>> 
>> However.. I haven't checked, but beware that current implementations might 
>> fail to parse the file if a "comment" member is added here, if they are 
>> (overly) strict. I expect that most will simply ignore this member. Perhaps 
>> it's wise that this is verified before finalising the errata.
> 
> I checked two implementations. The (archived) RIPE NCC validator accepts a
> comment field in bgpsecAssertions. StayRTR does not parse the bgpsecAssertions
> structure and I expect it to ignore additional attributes.
> 
> However, if there are any compliant implementations, following section 3.1,
> they would not accept a file that incorporates that follows the change 
> proposed
> in this erratum:
> 
> > ... An RP MUST consider any deviations from the specifications to
> > be errors.
> 
> I think we need to keep this in mind when discussing this erratum.
> 
> Kind regards,
> Ties
>> 
>> Tim
>> 
>>> On 21 Aug 2022, at 17:57, Warren Kumari  wrote:
>>> 
>>> 
>>> Dear SIDROPS, at al,
>>> 
>>> I believe that this Errata is correct, and I intends to mark it Verified 
>>> unless I hear a clear objection by this Friday (August 26th).
>>> 
>>> W
>>> 
>>> 
>>> 
>>> On Wed, Aug 10, 2022 at 5:25 PM, Ben Maddison 
>>>  wrote:
>>> Adding sidrops@
>>> 
>>> On 08/10, RFC Errata System wrote:
>>> 
>>> The following errata report has been submitted for RFC8416, 
>>> "Simplified Local Internet Number Resource Management with the RPKI 
>>> (SLURM)".
>>> 
>>> -- 
>>> You may review the report below and at: 
>>> https://www.rfc-editor.org/errata/eid7080
>>> 
>>> -- 
>>> Type: Technical 
>>> Reported by: Ben Maddison 
>>> 
>>> Section: 3.4.2
>>> 
>>> Original Text 
>>> - 
>>> The above is expressed as a value of the "bgpsecAssertions" member, as an 
>>> array of zero or more objects. Each object MUST contain one each of all of 
>>> the following members:
>>> 
>>> o An "asn" member, whose value is a number.
>>> 
>>> o An "SKI" member, whose value is the Base64 encoding without trailing '=' 
>>> (Section 5 of [RFC4648]) of the certificate's Subject Key Identifier as 
>>> described in Section 4.8.2 of [RFC6487] (This is the value of the ASN.1 
>>> OCTET STRING without the ASN.1 tag or length fields.)
>>> 
>>> o A "routerPublicKey" member, whose value is the Base64 encoding without 
>>> trailing '=' (Section 5 of [RFC4648]) of the equivalent to the 
>>> subjectPublicKeyInfo value of the router certificate's public key, 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.
>>> 
>>> Corrected Text 
>>> -- 
>>> The above is expressed as a value of the "bgpsecAssertions" member, as an 
>>> array of zero or more objects. Each object MUST contain one each of all of 
>>> the following members:
>>> 
>>> o An "asn" member, whose value is a number.
>>> 
>>> o An "SKI" member, whose value is the Base64 encoding without trailing '=' 
>>> (Section 5 of [RFC4648]) of the certificate's Subject Key Identifier as 
>>> described in Section 4.8.2 of [RFC6487] (This is the value of the ASN.1 
>>> OCTET STRING without the ASN.1 tag or length fields.)
>>> 
>>> o A "routerPublicKey" member, whose value is the Base64 encoding without 
>>> trailing '=' (Section 5 of [RFC4648]) of the equivalent to the 
>>> subjectPublicKeyInfo value of the router certificate's public key, 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.
>>> 
>>> In addition, each object MAY contain one optional "comment" member, whose 
>>> value is a string.
>>> 
>>> Notes 
>>> - 
>>> The "comment" member is allowed to appear in every other structure defined 
>>> by the document, and was clearly intended to be allowed here too, since it 
>>> appears in the examples presented in sections 3.4.2 and 3.5
>>> 
>>> Instructions: 
>>> - 
>>> This erratum is currently posted as "Reported". If necessary, please use 
>>> "Reply All" to discuss whether it should be verified or rejected. When a 
>>> decision is reached, the verifying party can log in to change the status 
>>> and edit the report, if necessary.
>>> 
>>> -- 
>>> RFC8416 (draft-ietf-sidr-slurm-08) 
>>> 

Re: [sidr] Adam Roach's Discuss on draft-ietf-sidr-slurm-07: (with DISCUSS and COMMENT)

[Di Ma]

Adam,

The version -08 of SLURM draft has just been submitted after we authors 
exchanged notes on JSON work in this document.

In addition to some editorial changes based on other ADs’ suggestion, we 
authors mainly improved the description of the specifications of the SLURM file 
with JSON format.

According to your suggestion, we have specified the syntax of SLURM file and 
normalized the usage of ‘object’ and ‘member’ and so on, not merely relying on 
the instances we provided in this document.

Thanks to Tim’s efforts on JSON work, we believe this version is much more 
clear and easier to comprehend.

Thanks again to your review and comments.

Di


> 在 2018年4月5日，21:14，Adam Roach  写道：
> 
> Thanks for your quick response! Feel free to reach out to me directly if you 
> find any particular part of the structure challenging to describe. 
> 
> /a
> 
>> On Apr 5, 2018, at 05:38, Tim Bruijnzeels  wrote:
>> 
>> Dear Adam, all,
>> 
>> Thank you for this feedback - indeed we struggled a bit with formally 
>> specifying JSON and relied on examples. I believe that with your suggestions 
>> we can improve this.
>> 
>> As for IP address prefix notation - yes.. we should follow your suggestion 
>> and cite RFC 4632 §3.1 for prefix-length notation (both for IPv4 and IPv6), 
>> and RFC 5952 for the syntax of IPv6 addresses. I am so used to doing it this 
>> way that it slipped my mind to specify this, but of course it should be 
>> unambiguous.
>> 
>> As I did most of the JSON text I will take it on me to re-work this text and 
>> ask Di to merge it with the changes he is working on. There should be a -08 
>> version coming soon.
>> 
>> Tim
>> 
>> 
>>> On 4 Apr 2018, at 21:22, Adam Roach  wrote:
>>> 
>>> Adam Roach has entered the following ballot position for
>>> draft-ietf-sidr-slurm-07: Discuss
>>> 
>>> 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/
>>> 
>>> 
>>> 
>>> --
>>> 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 

Re: [sidr] Warren Kumari's Discuss on draft-ietf-sidr-slurm-07: (with DISCUSS and COMMENT)

[Di Ma]

Warren,

The version -08 of SLURM draft has just been submitted after we authors 
exchanged notes on JSON work in this document.

Among others, we have dropped slurmTarget.

Thanks again for your review and comments.

Di


> 在 2018年4月7日，23:37，Warren Kumari <war...@kumari.net> 写道：
> 
> 
> On Fri, Apr 6, 2018 at 10:02 AM Di Ma <m...@zdns.cn> wrote:
> Warren,
> 
> Thanks very much for your comments.
> 
> Please see my responses in lines.
> 
> > 在 2018年4月2日，05:02，Warren Kumari <war...@kumari.net> 写道：
> >
> > Warren Kumari has entered the following ballot position for
> > draft-ietf-sidr-slurm-07: Discuss
> >
> > 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/
> >
> >
> >
> > --
> > 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.
> >
> >
> 
> We authors have decided to drop the slurmTarget element completely.
> 
> 
> That works for me​.​
> 
> Please ​(explicitly and loudly!) ​let me know when the new version is 
> ​submitted ​and I'll remove my discuss.
> 
> 
> ​W​
> 
> 
> Initially the implementation team was thinking that it would be useful to 
> have the ability to offer the same set of SLURM files to all RPs deployed in 
> a network, where local config of the RP would then evaluate the applicability 
> of each file. However, now that both implementations (RIPE NCC Validator and 
> RPSTIR) progressed we reconsider and we feel that it would be better to deal 
> with this on the provisioning side. I.e. only offer the SLURM file(s) 
> relevant to each RP.
> 
> 
> > --
> > 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..."
> 
> 
> ACK.
> 

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

[Di Ma]

Hi, Ben,

Thanks for reminding us:-)

Di

> 在 2018年4月10日，02:28，Ben Campbell <b...@nostrum.com> 写道：
> 
> 
> 
>> On Apr 6, 2018, at 10:06 AM, Spencer Dawkins at IETF 
>> <spencerdawkins.i...@gmail.com> wrote:
>> 
>> Hi, Di,
>> 
>> On Fri, Apr 6, 2018 at 9:33 AM, Di Ma <m...@zdns.cn> wrote:
>> Alissa,
>> 
>> Thanks very much for your comments.
>> 
>> Is BCP 14 exactly the same document as RFC 2119?
>> 
>> It was, until  https://tools.ietf.org/html/rfc8174 was added to BCP 14. 
>> That's the process doc that says readers don't have to figure out whether 
>> "must" is normative, etc.
>> 
>> Spencer, who is not Alissa, but had a second to answer the question
> 
> Also not Alissa (or Spencer), but to extend the answer a bit: RFC 8174 
> includes new boilerplate for treating only the upper case versions as 
> keywords.
> 
> Thanks!
> 
> Ben.



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

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

[Di Ma]

Spencer,

Thanks for your explanation. 

Di

> 在 2018年4月6日，23:06，Spencer Dawkins at IETF <spencerdawkins.i...@gmail.com> 写道：
> 
> Hi, Di,
> 
> On Fri, Apr 6, 2018 at 9:33 AM, Di Ma <m...@zdns.cn> wrote:
> Alissa,
> 
> Thanks very much for your comments.
> 
> Is BCP 14 exactly the same document as RFC 2119?
> 
> It was, until  https://tools.ietf.org/html/rfc8174 was added to BCP 14. 
> That's the process doc that says readers don't have to figure out whether 
> "must" is normative, etc.
> 
> Spencer, who is not Alissa, but had a second to answer the question



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

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

[Di Ma]

Alissa,

Thanks very much for your comments.

Is BCP 14 exactly the same document as RFC 2119?

Di

> 在 2018年4月5日，02:00，Alissa Cooper  写道：
> 
> Alissa Cooper 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:
> --
> 
> Please cite BCP 14 rather than RFC 2119, assuming you intend for normative
> keywords to have their normative meaning in uppercase only.
> 
> 
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr



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

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

[Di Ma]

Ben,

Thanks very much for your comments.

Please see authors' responses in lines.

> 在 2018年4月4日，03:43，Ben Campbell  写道：
> 
> Ben Campbell 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:
> --
> 
> 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.

We authors intend to work on a proposed standard mechanism for updating SLURM 
files through a secure API in the near future.

The very proposal is intended to be in a separate draft for SIDROPS. 

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

ACK. 

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

As we authors have decided to drop slurmTarget element, this is no longer an 
issue :-)

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

But it has been listed as 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.

We will make the change as follows:

OLD:
  However, ISPs may want to establish a local view of the RPKI to control
  its own network while making use of RPKI data.

NEW:
  However, ISPs may want to establish a local view of exceptions to the
  RPKI data in the form of local filters and additions.

Hopefully this will give context to the term ‘local view’ throughout the 
document.

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

ACK. 

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

Di

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

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

[Di Ma]

Eric,

Thanks very much for your comments.

Please see authors' responses in lines.

> 在 2018年4月3日，00:56，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"


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  or
>   in file Z.
> 

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

[Di Ma]

Alexey,

Thanks very much for your comments.

Please see authors' responses in lines.

> 在 2018年4月2日，18:47，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.
> 
> 

We authors think this is really a 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. 

Di



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

Re: [sidr] Warren Kumari's Discuss on draft-ietf-sidr-slurm-07: (with DISCUSS and COMMENT)

[Di Ma]

Warren,

Thanks very much for your comments.

Please see my responses in lines.

> 在 2018年4月2日，05:02，Warren Kumari  写道：
> 
> Warren Kumari has entered the following ballot position for
> draft-ietf-sidr-slurm-07: Discuss
> 
> 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/
> 
> 
> 
> --
> 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.
> 
> 

We authors have decided to drop the slurmTarget element completely. 

Initially the implementation team was thinking that it would be useful to have 
the ability to offer the same set of SLURM files to all RPs deployed in a 
network, where local config of the RP would then evaluate the applicability of 
each file. However, now that both implementations (RIPE NCC Validator and 
RPSTIR) progressed we reconsider and we feel that it would be better to deal 
with this on the provisioning side. I.e. only offer the SLURM file(s) relevant 
to each RP.


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


ACK. 

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

We will use ‘configured Trust Anchor(s)’ instead.


> 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")
> 
> 
ACK.

And we will update JSON related content in this draft based on Adam’s 
suggestions. 

Di

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

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

[Di Ma]

Benjamin,

Thanks very much for your comments.

Please see my responses in lines.


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

ACK.

> Section 3.2
> 
> OLD:
>   o  A SLURM Version indication that MUST be 1
> 
> NEW:
>   o  A SLURM Version indication.  This document specifies version 1.
> 

ACK.

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

We authors have decided to drop the slurmTarget element completely. 

Initially the implementation team was thinking that it would be useful to have 
the ability to offer the same set of SLURM files to all RPs deployed in a 
network, where local config of the RP would then evaluate the applicability of 
each file. However, now that both implementations progressed we reconsider and 
we feel that it would be better to deal with this on the provisioning side. 
I.e. only offer the SLURM file(s) relevant to each RP.


> Section 3.5 (both subsections):
> 
> "is locally configured with" does not mention SLURM at all as being
> involved in that configuration; perhaps it should.
> 

We authors are going to make changes as follows: 

3.5.1:

OLD:
Each RP is locally configured with a (possibly empty) array of ROA
Prefix Assertions.

NEW:
SLURM file(s) can be used to configure an RP with a (possibly empty) array of 
ROA
Prefix Assertions.

And similarly in 3.5.2

OLD:
Each RP is locally configured with a (possibly empty) array of BGPsec
Assertions.

NEW:
SLURM file(s) can be used to configure an RP with a (possibly empty) array of
BGPsec Assertions.


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

There is a MAY in the first sentence after all.

We will add in this section that ‘The RP gets multiple SLURM files as a set, 
and the whole set MUST be rejected in case of any overlaps between SLURM files.'

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

We authors intend to work on a proposed standard mechanism for updating SLURM 
files through a secure API in the near future.

 The very proposal is intended to be in a separate draft for 

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

[Di Ma]

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 <ka...@mit.edu> 写道：
> 
> 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
> 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.
> 
> Sect

Re: [sidr] RtgDir review: draft-ietf-sidr-slurm-06

[Di Ma]

IJsbrand,

Thanks for your review.

Please see my responses in lines.


> 在 2018年2月27日，17:18，IJsbrand Wijnands  写道：
> 
> Hello,
> 
> I have been selected as the Routing Directorate reviewer for this draft. The 
> Routing Directorate seeks to review all routing or routing-related drafts as 
> they pass through IETF last call and IESG review, and sometimes on special 
> request. The purpose of the review is to provide assistance to the Routing 
> ADs. For more information about the Routing Directorate, please see 
> ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> 
> Although these comments are primarily for the use of the Routing ADs, it 
> would be helpful if you could consider them along with any other IETF Last 
> Call comments that you receive, and strive to resolve them through discussion 
> or by updating the draft.
> 
> Document: draft-ietf-sidr-slurm-06 
> Reviewer: IJsbrand Wijnands 
> Review Date: 27-02-2018 
> Intended Status: Standards Track
> 
> Summary: 
> 
> • This document is basically ready for publication, but has nits that should 
> be considered prior to publication.
> 
> Comments:
> 
> This document reads ok.
> 
> Minor issues:
> 
> It seems to me it would be useful to have a "Terminology and Definitions” 
> section where the various acronyms are defined. That would help readers who 
> are less familiar in this area (like myself) to parse the document.

I understand your concern. 

However, the potential readers of this document are supposed to be familiar 
with the RPKI (RFC 6480) and BGPsec (RFC 8205) . All the acronyms use 
throughout this document are within the discourse system established by the 
RPKI and BGPsec. 

That is, only those who totally understand the RPKI and BGPsec would read this 
RFC for implementation and operations. 

Hoping I am making sense here :-) 

> 
> Nits:
> 
> 1. Introduction
> +++
> 
> * What is a "putative TAs”? Its not declared anywhere.

Yes. We will use Trust Anchor for its first use. 

> 
> * What is a “ROAs”? Should there be a RFC reference here?

ROA is explained as in ‘….the holder of a block of IP(v4 or v6) addresses can 
issue a Route Origination Authorization (ROA) [RFC6482]…’ in Introduction. 

> 
> 
> 2. RPKI RPs with SLURM
> ++
> 
> * What are “RPs”? Its not declared anywhere. 

Yes. We will use Relaying Party for its first use. 

> 
> 
> 3.3.  SLURM Target
> ++
> 
> * “A SLURM filer”, is that a filter or file?


Good catch. It should have been file :-)

Di

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

Re: [sidr] Secdir last call review of draft-ietf-sidr-slurm-06

[Di Ma]

Daniel,

Thanks for your review.

Please see my responses in lines.


> 在 2018年2月20日，23:00，Daniel Migault  写道：
> 
> Reviewer: Daniel Migault
> Review result: Has Nits
> 
> Hi, 
> 
> I have reviewed this document as part of the security directorate's 
> ongoing effort to review all IETF documents being processed by the 
> IESG.  These comments were written primarily for the benefit of the 
> security area directors.  Document editors and WG chairs should treat 
> these comments just like any other last call comments.
> 
> The summary of the review is Ready with nits:
> 
> • section 1: Introduction
> 
>   However, an RPKI relying party may want to override some of the
>   information expressed via putative TAs and the certificates
> 
> It seems that TA is being used for the first time here. The acronym
> should be extended to ease the reading of the document. I am reading it 
> as Trust Anchor.
> 

Yes. We will use Trust Anchor for its first use. 

> 
> • section 2.  RPKI RPs with SLURM
> 
>   SLURM provides a simple way to enable RPs to establish a local,
> 
> It seems to me the acronym RP is used for the first time. It seems that 
> it should be expanded to ease the reading of the document. I am reading it 
> as Relaying Party.

Yes. We will use Relaying Party for its first use. 

> 
> 
> • section 6 Security considerations
> 
> I My reading is that the section catches the criticality of the SLURM 
> files and that network operators are already familiar provisioning critical 
> data. As such I believe the section is sufficiently clear.
> 
> • whole document:
> 
> It seems that BGPSec, and BGPsec are used together. I believe this 
> should be harmonized to BGPsec.

We will use BGPsec throughout this document as used by RFC 8205. 

Di

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

Re: [sidr] AD Review of draft-ietf-sidr-slurm-04

[Di Ma]

Hi, Alvaro,

Thanks.

A new version (-06) has been submitted.

Di

> 在 2018年2月7日，01:48，Alvaro Retana <aretana.i...@gmail.com> 写道：
> 
> On February 5, 2018 at 10:09:18 PM, Di Ma (m...@zdns.cn) wrote:
> 
> Di:
> 
> Hi!
> 
>> A new version (-05) has been submitted for you to review.
> 
> There’s one more change I need you to make before starting the IETF Last Call.
> 
> In this latest revision you listed rfc8211 as a Normative Reference (as a 
> replacement of draft-ietf-sidr-adverse-actions, which was listed as 
> Informative).  Please move rfc8211 back to Informative.  I know this sounds 
> like a nit, but the IETF Last Call explicitly calls out DownRefs (pointing to 
> an Informational document as a Normative Reference in a Standards Track 
> document), which carry additional process…and in this case it is not needed.
> 
> While you’re at it, please update the reference to rfc7159 -> rfc8259.
> 
> Thanks!
> 
> Alvaro.

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

Re: [sidr] AD Review of draft-ietf-sidr-slurm-04

[Di Ma]

Sriram,

Thanks again for your comments.


> 在 2018年1月30日，04:36，Sriram, Kotikalapudi (Fed)  
> 写道：
> 
> David, Di, Tim:
> 
> These are minor comments in alignment with Alvaro’s.
> 
> Alvaro wrote:
> 
>> M4. References:
> 
>> M4.1. s/I-D.ietf-sidr-bgpsec-overview/rfc8205  ...and should be Normative.
> 
>> 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
>>  
> 
> With regard to updating the references, I noticed that the draft references
> [I-D.ietf-sidr-bgpsec-overview] in two places where it should reference
> BGPsec Protocol Specification [RFC 8205].  For example, on page 3:
> 
> (Validation of the origin of a route is
>   described in [RFC6483], and validation of the path of a route is
>   described in [I-D.ietf-sidr-bgpsec-overview].)
> 
> For “validation of the path of a route” the pointer should be Section 5 of 
> RFC 8205.


Yes.  We should make the change.


> 
> AFAIK, [I-D.ietf-sidr-bgpsec-overview] is expired and there are no plans to 
> publish it.
> 
> I would also suggest that both RFCs 6483 and 6811 can be referenced when
> talking about “Validation of the origin of a route.”  RFC 6811 is Standards 
> Track
> while 6483 is Informational.

Agreed.

RFC 6811 is more competent to talk about Validation of the origin of a route. 

Di


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

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

Re: [sidr] AD Review of draft-ietf-sidr-slurm-04

[Di Ma]

Hi, Alvaro,

Thanks for your comments.

Please see my responses in lines.

> 在 2018年1月30日，02:21，Alvaro Retana  写道：
> 
> 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?
> 

We authors think MUST is better than SHOULD.

And we would like to update section 3.1 saying:

"This document describes responses in the JSON [RFC7159] format.  JSON members 
that are not defined here MUST not be used in SLURM Files and additional 
top-level members MUST be defined in RFCs that update this document. Relying 
parties MUST ignore unrecognized JSON members at the top level, while any 
deviations from the specification at lower levels MUST be considered an error.”

Here is the consideration: 
The current document describes local exceptions with regards to ROAs and Router 
Certificates, which are significant to local control of routing.  The thought 
here was that we would leave an option for future other ’top-level’ elements to 
describe local exceptions with regards to other (future) RPKI objects as long 
as they have fundamental effect in routing control , while maintaining backward 
compatibility. But this is not explicit in the document as written. The risk 
here, as written, is that implementations can just add stuff at will for their 
own purpose and we can end up with the same member name being re-used.


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

Yes. 

You are making sense here. 

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

Agreed. 

We are going to add:

"Yet the mechanism to update SLURM file to guarantee authentication and 
integrity is out of  the scope of this document. "

Besides, we need to change ‘source’ to ‘sources’ :-)

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

Agreed. 

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

Agreed.

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

We authors are going to change 4.1 and 4.2 to say “Locally Added Assertions” 
because we refer to the elements.

The lower case “locally adding assertions” in 3.2 is fine, because it describes 
an action.

> 
> Nits:
> 
> N1. s/control make use of RPKI data/control use of RPKI data

Agreed.

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

Re: [sidr] AD Review of draft-ietf-sidr-slurm-04

[Di Ma]

Sriram,

Thanks for your comments.

We authors will update the draft, in response to your suggestions and comments 
from the AD.

Di


> 在 2018年1月30日，04:36，Sriram, Kotikalapudi (Fed)  
> 写道：
> 
> David, Di, Tim:
>  
> These are minor comments in alignment with Alvaro’s.
>  
> Alvaro wrote:
>  
> >M4. References:
>  
> >M4.1. s/I-D.ietf-sidr-bgpsec-overview/rfc8205  ...and should be Normative.
>  
> >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
> > 
>  
> With regard to updating the references, I noticed that the draft references
> [I-D.ietf-sidr-bgpsec-overview] in two places where it should reference
> BGPsec Protocol Specification [RFC 8205].  For example, on page 3:
>  
> (Validation of the origin of a route is
>described in [RFC6483], and validation of the path of a route is
>described in [I-D.ietf-sidr-bgpsec-overview].)
>  
> For “validation of the path of a route” the pointer should be Section 5 of 
> RFC 8205.
>  
> AFAIK, [I-D.ietf-sidr-bgpsec-overview] is expired and there are no plans to 
> publish it.
>  
> I would also suggest that both RFCs 6483 and 6811 can be referenced when
> talking about “Validation of the origin of a route.”  RFC 6811 is Standards 
> Track
> while 6483 is Informational.
>  
> Thanks.
>  
> Sriram
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

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

Re: [sidr] WGLC: draft-ietf-sidr-rtr-keying - finishes - 10/16/2017 - Oct 16, 2017

[Di Ma]

I think this document is ready to go through IESG review.

Ship it.

Di


> 在 2017年10月6日，02:36，Sean Turner  写道：
> 
> Always happy to see the “ship it” response to a WGLC :)
> 
> Note that we weren’t restrictive on purpose.   There’s a whole bunch of ways 
> how the CSR could get delivered based on where it was made and it would be 
> silly for us to have said you must do it this way. 
> 
> spt
> 
>> On Oct 5, 2017, at 05:27, Tim Bruijnzeels  wrote:
>> 
>> Hi,
>> 
>> This looks reasonable to me, but I can’t speak really to the router 
>> implementation - being neither a network operator nor a router vendor. As a 
>> CA operator I note that the draft is not restrictive about exactly how the 
>> RPKI CA gets the CSR, and the signed certificate is returned. That’s a good 
>> thing to me at this point, so I would say ship it. But I believe it would be 
>> good to keep this in mind in the sidr-ops WG - if this proves operationally 
>> difficult then it may be something to discuss further later.
>> 
>> Tim
>> 
>>> On 3 Oct 2017, at 05:14, Christopher Morrow  
>>> wrote:
>>> 
>>> WG Folk,
>>> I thought I had sent this note our previously, but... better late then 
>>> never sent:
>>> 
>>> Please consider this the WGLC for:
>>> https://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-13
>>> 
>>> Abstract:
>>> "BGPsec-speaking routers are provisioned with private keys in order to
>>>  sign BGPsec announcements.  The corresponding public keys are
>>>  published in the global Resource Public Key Infrastructure, enabling
>>>  verification of BGPsec messages.  This document describes two methods
>>>  of generating the public-private key-pairs: router-driven and
>>>  operator-driven."
>>> 
>>> Please send along comments/complaints/issues/kudos (to the authors), to the 
>>> list and I'll see you all in ~14 or so days.
>>> 
>>> Thanks!
>>> -chris
>>> co-chair
>>> ___
>>> sidr mailing list
>>> sidr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sidr
>> 
>> ___
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
> 
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr


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

Re: [sidr] suggested text to replace Section 4 in the use cases doc

[Di Ma]

Agreed:) 

在 2014年3月5日，下午1:04，Stephen Kent k...@bbn.com 写道：

 
 Steve,
  It’s  more explicit and better to understand. 
 
  But I suggest eliminating the expression concerning NIR that is  “Case 
 1 also encompasses a larger case, e.g., when all of the ISPs with a country 
 require protection for an RIR action of this sort, coordinated at a national 
 level. We cannot assume that the country operates an NIR.
 
  INR management in a country with NIR  could be very complicated, with 
 different operation models.  If necessay , a separate operation doc might be 
 presented, getting NIR stuff involved.
 
 
 Di Ma
 Internet Domain Name System Beijing Engineering Research Centre (ZDNS)
 KNET Technologies
 
 Thanks for the feedback.
 
 My point, in case 1, is that we cannot assume that a solution to this
 use case can rely on the
 existence of an NIR.
 
 That is compatible with your observation that an NIR might need to
 develop its own operations document.
 
 Steve
 
 ___
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/listinfo/sidr

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

Re: [sidr] suggested text to replace Section 4 in the use cases doc

[Di Ma]

Steve,
It’s  more explicit and better to understand. 

But I suggest eliminating the expression concerning NIR that is  “Case 
1 also encompasses a larger case, e.g., when all of the ISPs with a country 
require protection for an RIR action of this sort, coordinated at a national 
level. We cannot assume that the country operates an NIR.

INR management in a country with NIR  could be very complicated, with 
different operation models.  If necessay , a separate operation doc might be 
presented, getting NIR stuff involved.
 

Di Ma
Internet Domain Name System Beijing Engineering Research Centre (ZDNS)
KNET Technologies

在 2014年3月4日，下午3:19，Stephen Kent k...@bbn.com 写道：

 Randy,
 
 here is my suggestion for text that is not so folksy and is clearer (at least 
 to me).
 
 Steve
 
 4.  Example Uses
  
 Case 1:
 ISP C find that its CA certificate has been be revoked (or modified to 
 removed resources) by the RIR (or ISP) that issued it. ISP C believes that 
 this revocation was either an error by RIR staff, or that the RIR has been 
 compelled to revoke the certificate by a law enforcement agency in the 
 jurisdiction where the RIR operates. ISP C would like other ISPs to be able 
 to ignore the certificate revocation (or modification), at their discretion.
  
 Case 1 also encompasses a larger case, e.g., when all of the ISPs with a 
 country require protection for an RIR action of this sort, coordinated at a 
 national level. We cannot assume that the country operates an NIR.
  
 Case 2:
 ISP B makes use of private address space (RFC 1918) or makes use of address 
 space allocated to some other party , but which is not announced globally). 
 ISP B makes use of the RPKI internally, as well as for global routing. ISP B 
 would like its use of private address space to work internally with routers 
 that make use of RPKI data.
  
 Case 3:
 An organization, A, is authorized to control routing of traffic from a set of 
 ISPs to the rest of the Internet. (For example, A may want traffic to 
 selected addresses to be redirected to other addresses, or be dropped.)  
 Because these ISPs want to use the RPKI, A needs a way to coordinate their 
 use of the RPKI (in  support of A’s traffic management goal).
 ___
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/listinfo/sidr

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

Re: [sidr] wg adoption call for draft-rogaglia-sidr-multiple-publication-points

[Di Ma]

I support adoption of this document, the discussion of which is going to make a 
better RPKI deployment. 


Di Ma
China Internet Network Information Center （CNNIC）


在 2013-3-12，下午1:54，Murphy, Sandra sandra.mur...@sparta.com 写道：

 The authors of draft-rogaglia-sidr-multiple-publication-points have requested 
 wg adoption.
 
 See 
 http://tools.ietf.org/html/draft-rogaglia-sidr-multiple-publication-points 
 
 Please do respond to the list as to whether you support the wg adopting this 
 as a work item.  Note that you do not need to comment on the content of this 
 draft at this time.  You are asked to indicate if you think that this is work 
 that the wg should be doing and whether this draft is an acceptable starting 
 point.  Adding whether you can/will review or not is useful.
 
 This adoption call will end on Tuesday, March 26, 2013 (extra time because 
 many of those in the wg are busy at the ietf this week).
 
 --Sandy
 ___
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/listinfo/sidr

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