Subject: [spring] Adam Roach's No Objection on draft-ietf-spring-segment-routing-ldp-interop-13: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Tue, 19 Jun 2018 23:12:38 -0700

Adam Roach has entered the following ballot position for
draft-ietf-spring-segment-routing-ldp-interop-13: 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-spring-segment-routing-ldp-interop/

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

I might have missed something; and note that this is offered as an
observation, and is explicitly not a blocking comment: this document appears
to offer operational advice for co-existence of LDP and SR, and for
transitioning from LDP to SR in an incremental fashion. I don't see any
protocol specification in here. Based on these observations, it is my opinion
that the contents of this document seem better suited for publication as a BCP
rather than a standards track document. For example: if one were to eventually
progress this document to an Internet Standard, what "implementations" would
one use to evaluate the criteria in section 2.2 of RFC 6140? If we can't
answer that question, I think it's a pretty clear indication that the document
isn't standards track.

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

General:

This document uses IPv4 addresses for example purposes in many places. Please
convert these to IPv6 or a mix of IPv4 and IPv6 addresses. See
https://www.iab.org/documents/correspondence-reports-documents/2016-2/iab-statement-on-ipv6/
for additional information.

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

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in RFC 2119 [RFC2119].

This document uses non-normative, lowercased versions of these words in several
locations. Please update this section to match the boilerplate in RFC 8174.

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

§3.1.1:

>  A SR node having LDP neighbors MUST create LDP bindings for each
>  Prefix-SID learned in the SR domain by treating SR learned labels as
>  if they were learned through an LDP neighbot.

Nit: "...neighbor."