[sidr] Ben Campbell's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)

"Ben Campbell" <ben@nostrum.com> Wed, 04 January 2017 23:23 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ben Campbell <ben@nostrum.com>
To: The IESG <iesg@ietf.org>
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148357219612.13068.224046269873957367.idtracker@ietfa.amsl.com>
Date: Wed, 04 Jan 2017 15:23:16 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/MyEAT_aXYs_awGsaGAX7ciiCuJU>
Cc: draft-ietf-sidr-bgpsec-protocol@ietf.org, sidr-chairs@ietf.org, m.waehlisch@fu-berlin.de, sidr@ietf.org
Subject: [sidr] Ben Campbell's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)

Ben Campbell has entered the following ballot position for
draft-ietf-sidr-bgpsec-protocol-21: Yes

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-bgpsec-protocol/



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

I share some of the concerns about deployability, but have nothing new to
add to that conversation. Otherwise I just have a few minor comments:

-2: draft-ietf-sidr-bgpsec-protocol explicitly excludes non-capitalized
versions of 2119 words. This draft does not. It seems different 2119
approaches among the various bgpsec draft could be confusing to the
reader.

[Update: Oops, sorry,  I meant to say draft-ietf-sidr-bgpsec-ops excludes
non-capitalized versions of 2119 words. (That is to say, it treats them
as their normal English equivalents.)]

- 5.2, step 2: I'm almost sure I've missed something here, but if I
understand correctly, previous sections talked about how a peer can
propagate a BGPsec_Path attribute without modification. Will that cause a
problem in this step if the immediate peer propagated an unmodified
BGPsec_Path that came from a different AS? 

- 8.4, last paragraph: The text describes a replay attack, and delegates
the mitigation solution to draft-ietf-sidr-bgpsec-rollover. This is an
informational reference; it seems like it should be normative.

[sidr] Ben Campbell's Yes on draft-ietf-sidr-bgps… Ben Campbell