Re: [netmod] A reworking of RFC8343

Dmytro Shytyi <> Tue, 22 October 2019 19:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 90999120096 for <>; Tue, 22 Oct 2019 12:54:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 bJRJfvrMNEs7 for <>; Tue, 22 Oct 2019 12:53:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BD16B120077 for <>; Tue, 22 Oct 2019 12:53:57 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1571774024; cv=none;; s=zohoarc; b=GWWGDTyASBCW2yhK4GhElzMu/RQUzAAW94s3tPD7MudfQM1XzAy9RHmLrkRIW4lmarysyTUJFVl5gq/D89IY7nIktyg1KQKMGLCBV6v4EAF/7Qo07317/IltXtB7szuh0lMzko9gWpa/zy6kWUPxp3uRG0uGe2WrdgnLr38f8jc=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=zohoarc; t=1571774024; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=je/tFIVyIJJ5XiJ/kALB5oy34VcMVi0KmEGpreHEYN4=; b=aSdp/kI2CAp0IieRacN1r9IjPj7Js3cQg/MxhbYt9JMRCAv1kiJNJeQAiKtglIgf1PXO+i6Kzi5boAbQx/Fpuv7EF5IAUcOV3obTphGJfROPiU2ix/dG6o6cggfBhUgWGgU1DPX1w9I8xM+F6aERUyMnhSRi3B7OZWbzCmeiECk=
ARC-Authentication-Results: i=1;; dkim=pass; spf=pass; dmarc=pass header.from=<> header.from=<>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1571774024; s=hs;;; h=Date:From:To:Cc:Message-Id:In-Reply-To:References:Subject:MIME-Version:Content-Type; l=11105; bh=je/tFIVyIJJ5XiJ/kALB5oy34VcMVi0KmEGpreHEYN4=; b=TTic7V14deuVZugDsxwPWfNz2ZiUVjqrRvdgTeIJVb/jcd9g+zisKjUzOABihQdH /23xnb+6wE8iwOTYALFy9PDfsrs8ob4Y40krlqv61Izw6Q9vQpdlrusiyrF8pvr2avv EDmQkAubCFy41wtwtwzRUm7K5MrJAj4GB4KKLibc=
Received: from ( []) by with SMTPS id 1571774022929604.5109433098424; Tue, 22 Oct 2019 21:53:42 +0200 (CEST)
Received: from by with SMTP id 1571774022836919.554910556039; Tue, 22 Oct 2019 21:53:42 +0200 (CEST)
Date: Tue, 22 Oct 2019 21:53:42 +0200
From: Dmytro Shytyi <>
To: Martin Bjorklund <>
Cc: ietfc <>, netmod <>
Message-Id: <>
In-Reply-To: <>
References: <> <> <039001d588c2$bb3d7e20$> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_271247_172018077.1571774022833"
X-Priority: Medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail
X-ZohoMailClient: External
Archived-At: <>
Subject: Re: [netmod] A reworking of RFC8343
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Oct 2019 19:54:01 -0000

Hello Martin,

We are interested in  some specific functionality provided by RFC 8343 yang model. 

So we derivied the yang model from RFC 8343, modified it and gave module name , prefix with some modifications like "ucpe-interfaces",

but in description we kept the reference to original RFC(in future we wil modify the description to say that it is not original RFC 8343 yang module.)

IMHO it is wrong to not presice in the description(reference) of the module / RFC that was we find usefull in our work.

>Clearly unacceptable.  Unclear why a ucpe can't implement 

ietf-interfaces from RFC 8343. 
I will try to give some ideas here.  

1. uCPE phy interface has "vPorts" to witch "vLinks are assigned". "vLinks "connect" the phy interface with  "vPort" of vswitch. Thus we may add to the derieved from RFC 8343 module the list of "vPorts" for each phy interface.

example with 1 phy interface:


                              |                  UCPE


                  |                        |------vPort 1---vlink---(vport_sw)vswitch(vport_sw)--vlink---.....----WAN

LAN----|   Phy             |------vPort 2

                  |   interface     |




2. If we include the yang module from the RFC 8343 to the set of yang models by default it goes in the root of config mode. i.e:


config t

      interfaces interface....

When we have a parent module we need to place the RFC 8343 module to under the parent module (like in the draft draft-shytyi-opsawg-vysm-04). 

Hence the RFC8343  may be modified to add the augment statement(as it is dome in draft-shytyi-opsawg-vysm-04)  to put the "interfaces interface" under the parent module like

conifg t

      ucpe "ucpe X" interfaces interface...


---- On Tue, 22 Oct 2019 13:31:31 +0200 Martin Bjorklund <> wrote ----

tom petch <> wrote: 
> Martin 
> I am wondering how much you know about a module that says 
>       WG List:  <> 
>       Editor:   Martin Bjorklund 
>                 <>"; 
> The module is 
>   module ietf-ucpe-interfaces { 
> in 
>   draft-shytyi-opsawg-vysm-04 
Haha!  I don't know anything about it. 
> The author appears to have taken RFC8343, changed the module and prefix 
> name (but not the Editor) and added, at the top level, 
>    augment "/ietf-vysm:ucpe" { 
> (ucpe also appears in this I-D).  I have commented on the OPSAWG list 
> about this approach not being one I have seen before and the response is 
> that the yang validator is fine with it. 
> Thoughts? 
Clearly unacceptable.  Unclear why a ucpe can't implement 
ietf-interfaces from 8343. 
> An earlier version of this module had 
>   import tailf-ncs 
> which also had me wondering. 
netmod mailing list