Re: [RTG-DIR] RtgDir review: draft-wu-l3sm-rfc8049bis-07

[Benoit Claise <[e-mail]>]

Hi Lou,

Thanks for initiating this discussion on the YANG doctors and on the 
NETMOD mailing list.
The authors have produced v7 to address this comment.
I replied to the IETF LC message on this very specific topic, giving one 
week for feedback.
I can't point you to the archive, as my message awaits moderator 
approval (not sure why).
So here a cut/paste:

    Dear all,

    Based on the feedback received, the authors produced version 7.
    I would like to highlight those two changes (the only two changes btw).
    In the abstract:

        This document obsoletesRFC 8049 <https://tools.ietf.org/html/rfc8049>  to replace the unimplementable
        module in that RFC with a new module with the same name that is not
        backward compatible.  The changes are a series of small fixes to the
        YANG module, and some clarifications to the text.

    In section 1:

            The YANG module described in [RFC8049 <https://tools.ietf.org/html/rfc8049>] cannot be implemented because
            of issues around the use of XPATH.  This document obsoletes [RFC8049 <https://tools.ietf.org/html/rfc8049>]
            by creating a new module with the same name that is not backward
            compatible (in the sense described in YANG 1.1 [RFC7950 <https://tools.ietf.org/html/rfc7950>]).  The
            changes (listed in full inSection 1.4
        <https://tools.ietf.org/html/draft-wu-l3sm-rfc8049bis-07#section-1.4>) are small in scope, but
            include fixes to the module to make it possible to implement.

    Changes are highlighted here:
    https://tools.ietf.org/rfcdiff?url2=draft-wu-l3sm-rfc8049bis-07.txt
    Since RFC8049 is not implementable and therefore not implemented,
    keeping the same YANG module name seems about right.
    I'll collect feedback for a week. Note that this draft is on the
    IESG telechat on Oct 26th.

    Regards, Benoit


If a follow up is required, I propose that we use a single public email 
thread: the [e-mail]

Regards, Benoit
> 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.)
>
> .
>