date:20180426

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

2018-04-26 Thread 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)

2018-04-26 Thread 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  写道：
> 
> 
> On Fri, Apr 6, 2018 at 10:02 AM Di Ma  wrote:
> 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.
> 
> 
> 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.
> 
> >
> > 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 
>

[sidr] I-D Action: draft-ietf-sidr-slurm-08.txt

2018-04-26 Thread internet-drafts


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Inter-Domain Routing WG of the IETF.

Title   : Simplified Local internet nUmber Resource Management 
with the RPKI (SLURM)
Authors : Di Ma
  David Mandelberg
  Tim Bruijnzeels
Filename: draft-ietf-sidr-slurm-08.txt
Pages   : 17
Date: 2018-04-26

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


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sidr-slurm-08
https://datatracker.ietf.org/doc/html/draft-ietf-sidr-slurm-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-slurm-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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

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

[sidr] I-D Action: draft-ietf-sidr-slurm-08.txt

3 matches

Site Navigation

Mail list logo

Footer information