[RTG-DIR] Rtgdir telechat review of draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04

[Carlos Pignataro via Datatracker <[e-mail]>]

Reviewer: Carlos Pignataro
Review result: Has Issues

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document: draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04
Reviewer: Carlos Pignataro
Intended Status: Proposed Standard

Summary:
This document specifies the algorithms and parameters for BGPsec (Border
Gateway Protocol Security).

Comments:
This is a clear, comprehensive, and well written document. It states it updates
(if approved) RFC 8208, and I particularly appreciate Section 1.2, "Changes
from RFC 8208", in explicitly showing how. However, it is unclear to me if the
right relationship is to "update" or to "obsolete" RFC 8208. Should this
document be approved and published, would RFC 8208 still be active and
relevant, only updated, or re-written?

Minor Issues:

1.  Introduction

   This document updates [RFC7935] to add support for a) a different
   algorithm for BGPsec certificate requests, which are issued only by
   BGPsec speakers; b) a different Subject Public Key Info format for

CMP: Does this document update RFC7935 or RFC8208 on these issues? Meaning, if
it really updates RFC7935, then it would obsolete RFC 8208. If it does not
obsolete RFC 8208, then it would update RFC 8208 and RFC 7935, perhaps? CMP: I
believe the right metadata would be: Updates: 7935 Obsoletes: 8208

CMP: Also, an editorial: this is a very thick paragraph to parse containing an
enumerated list embedded in it. Should clarity be improved if turned into an
actual list? (a), (b), etc.

   Appendix A contains example BGPsec UPDATE messages as well as the
   private keys used to generate the messages and the certificates
   necessary to validate the signatures.

CMP: Maybe overkill, but might be useful to explicitly say that the Appendix is
non-normative. Just a thought for your consideration.

2.1. Algorithm ID Types

   o  Special-Use Algorithm ID

      Special-Use algorithm IDs span from 0xFA (250) to 0xFE (254).  To
      allow documentation and experimentation to accurately describe

CMP: I was wondering if it is appropriate to use a common block for both
documentation (paper) and experimentation (wire in labs). CMP: In this, I note
that RFC 4727 says:

"  It is not
   appropriate to use addresses in the documentation prefix [RFC3849]
   for experimentation."

CMP: So, while I have no strong position (I think), it might be useful to
consider separating these two semantics with different allocations.

8.  References

CMP: Lastly, I am sure ADs are checking downrefs and the such.

Also Nits:

Found possible IPv6 address '2001:0010:0000:0000:0000:0000:c633:6464' in
position 783 in the paragraph; this doesn't match RFC 3849's suggested
2001:DB8::/32 address range or RFC 4193's Unique Local Address range FC00::/7.

CMP: I hope these are useful.

Thank you,

Carlos Pignataro.