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  写道：
> 
> 
> 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 
> 

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

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