[Sidrops] Adam Roach's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT)

Adam Roach <adam@nostrum.com> Wed, 23 January 2019 04:09 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach <adam@nostrum.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-sidrops-rtr-keying@ietf.org, Chris Morrow <morrowc@ops-netman.net>, sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154821657076.13328.13662061490601279410.idtracker@ietfa.amsl.com>
Date: Tue, 22 Jan 2019 20:09:30 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/tDRItUSdLS4m-xxDXXOQT6HZaME>
Subject: [Sidrops] Adam Roach's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT)

Adam Roach has entered the following ballot position for
draft-ietf-sidrops-rtr-keying-03: 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-sidrops-rtr-keying/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to the authors for a well-written and clear document. I have one
substantive comment, and a minor editorial nit.

---------------------------------------------------------------------------

§3:

>  - Using FTP or HTTP per [RFC2585], and

It's not clear from a casual examination whether use of unencrypted and
non-integrity-protected channels for these operations are safe. I would expect
to see a discussion of this in this section and/or section 10. The closest I
could find is the SHOULD-strength (!) recommendation for transport-level
security for private key transport.

Without a more thorough analysis, I suspect we should more strongly deprecate
the use of unencrypted/non-integrity-protected transports. This document is,
after all, supposed to be calling out best practice; and, in 2019, that really
does entail transport security except under the most exceptional circumstances.

---------------------------------------------------------------------------

§2:

>  Though other configuration mechanisms might be used, e.g.  NetConf
>  (see [RFC6470]), the protected the protected channel between the

Nit: duplicate "...the protected..."

[Sidrops] Adam Roach's No Objection on draft-ietf… Adam Roach
Re: [Sidrops] Adam Roach's No Objection on draft-… Sean Turner