Re: Last Call: <draft-wu-l3sm-rfc8049bis-04.txt> (YANG Data Model for L3VPN Service Delivery) to Proposed Standard

Benoit Claise <> Sat, 14 October 2017 06:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E0C5913263F; Fri, 13 Oct 2017 23:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n_aeR6EeXIhi; Fri, 13 Oct 2017 23:55:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0F95E124B17; Fri, 13 Oct 2017 23:55:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=9230; q=dns/txt; s=iport; t=1507964118; x=1509173718; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=yxxMxuMjX7j+N5nZGp7nIOJrP0MymiSWMXV19WLcnZI=; b=BczoViPzbIuxCE3dUC+h3k9qISa+9hamzwr3Xgbjrtpe/AhwTMW4ob6H 0xphgbYY2+ltE6eBNchQOgw+/Lm8VgaGCDXoSLqnryfRrgv1N8GdsbKrk zeL97PA+EhNfYhhr/v2Jm2OJkwrMavpJ9L4kqO6NWWISPx2Wnie7CESUd Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.43,374,1503360000"; d="scan'208,217";a="658075399"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Oct 2017 06:55:13 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id v9E6tBuM027283; Sat, 14 Oct 2017 06:55:12 GMT
Subject: Re: Last Call: <draft-wu-l3sm-rfc8049bis-04.txt> (YANG Data Model for L3VPN Service Delivery) to Proposed Standard
To:, IETF-Announce <>
Cc:,, Jan Lindblad <>
References: <>
From: Benoit Claise <>
Message-ID: <>
Date: Sat, 14 Oct 2017 08:55:11 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------695E72A641E10EBED46D5A00"
Content-Language: en-US
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 14 Oct 2017 06:55:21 -0000

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 <>  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 <>] cannot be implemented because
        of issues around the use of XPATH.  This document obsoletes [RFC8049 <>]
        by creating a new module with the same name that is not backward
        compatible (in the sense described in YANG 1.1 [RFC7950 <>]).  The
        changes (listed in full inSection 1.4
    <>) are small in scope, but
        include fixes to the module to make it possible to implement.

Changes are highlighted here:
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
> The IESG has received a request from an individual submitter to consider the
> following document: - 'YANG Data Model for L3VPN Service Delivery'
>    <draft-wu-l3sm-rfc8049bis-04.txt> as Proposed Standard
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> mailing lists by 2017-10-11. Exceptionally, comments may be
> sent to instead. In either case, please retain the beginning of
> the Subject line to allow automated sorting.
> Abstract
>     This document defines a YANG data model that can be used for
>     communication between customers and network operators and to deliver
>     a Layer 3 provider-provisioned VPN service.  This document is limited
>     to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364.  This
>     model is intended to be instantiated at the management system to
>     deliver the overall service.  It is not a configuration model to be
>     used directly on network elements.  This model provides an abstracted
>     view of the Layer 3 IP VPN service configuration components.  It will
>     be up to the management system to take this model as input and use
>     specific configuration models to configure the different network
>     elements to deliver the service.  How the configuration of network
>     elements is done is out of scope for this document.
>     If approved, this document obsoletes RFC 8049.  The changes are a
>     series of small fixes to the YANG module, and some clarifications to
>     the text.
> The file can be obtained via
> IESG discussion can be tracked via
> No IPR declarations have been submitted directly on this I-D.
> Working Group Summary
>    RFC 8049 was the product of the L3SM working group, but that WG has been closed.
>    No other WG covers this topic.
>    However, the L3SM list remains open: changes and revisions were publicised and discussed there
> The document contains these normative downward references.
> See RFC 3967 for additional information:
>      rfc3022: Traditional IP Network Address Translator (Traditional NAT) (Informational - IETF stream)
> .