Last Call Review of draft-wu-l3sm-rfc8049bis-07
review-wu-l3sm-rfc8049bis-07-rtgdir-lc-berger-2017-10-16-00

• Status
• Email expansions
• History

• Versions
• 00

The IETF LC ends on Oct/11, which may put this document on the IESG Telechat the next day.  There's not much room for extensions.

Review
review-wu-l3sm-rfc8049bis-07-rtgdir-lc-berger-2017-10-16

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-wu-l3sm-rfc8049bis-07
Reviewer: Lou Berger
Review Date: Oct 13 2017
IETF LC End Date: date-if-known
Intended Status: Standards Track

Summary:

I have some major concerns about this document that I think should be
resolved before publication.

Comments:

This document is intended to provide a technical correction to the
syntactic flaws of the ietf-l3vpn-svc yang module defined in RFC 8049.
The changes are straightforward and have been cleared by the YANG Doctor
team with the one exception as discussed below.

Major Issues:

>From a strict reading of this document and the YANG Language definition
(RFC6020 or RFC7950) this document violates the MUST clauses in
https://tools.ietf.org/html/rfc7950#section-11 insofar as that
rfc8049bis has several definitions that are not compatible with those
defined in rfc8049 for the ietf-l3vpn-svc yang module, yet the bis does
not follow the requirement of RFC7950 to change the module
name/identifier. In discussion on the netmod WG list, the point has been
raised that this is acceptable as the module defined in rfc8049 should
never have been published in the first place as it is syntactically broken.

So there is a choice to be made, i.e., to either:

(a) publish this document as is and note a special exception to the
requirement of RFC7950 (an IETF consensus document), or

(b) update/change the module identifier in this document to conform with
RFC7950.

I think who makes this decision is an IETF process call and I deffer to
the IESG on this matter.

Lou
(as RtgDir reviewer, who also happens to co-chair the WG that has
technical responsibility for rfc7950.)