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

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

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

Minor Comments:

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

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

§8.2, " [RFC4648]": The document requires Base64 encoding. Doesn't that make
this 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.

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

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


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