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

Di Ma <madi@zdns.cn> Fri, 06 April 2018 14:29 UTC

Content-Type: text/plain; charset="gb2312"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Di Ma <madi@zdns.cn>
In-Reply-To: <152278460436.22775.8518027666585390285.idtracker@ietfa.amsl.com>
Date: Fri, 06 Apr 2018 22:29:44 +0800
Cc: The IESG <iesg@ietf.org>, morrowc@ops-netman.net, draft-ietf-sidr-slurm@ietf.org, sidr@ietf.org, sidr-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <4339A019-F124-4B01-8554-88A8C085A430@zdns.cn>
References: <152278460436.22775.8518027666585390285.idtracker@ietfa.amsl.com>
To: Ben Campbell <ben@nostrum.com>
Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign4
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/fZX2Y6xRVbDgLDfT37ZWeN8r9n4>
Subject: Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT)
Precedence: list

Ben,

Thanks very much for your comments.

Please see authors' responses in lines.

> 在 2018年4月4日，03:43，Ben Campbell <ben@nostrum.com> 写道：
> 
> 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] Ben Campbell's No Objection on draft-ietf-… Ben Campbell
Re: [sidr] Ben Campbell's No Objection on draft-i… Di Ma