Re: [netmod] draft-clacla-netmod-yang-model-update-00.txt : Re: [RTG-DIR] handling module incompatibility => handling module transition

Andy Bierman <andy@yumaworks.com> Fri, 03 November 2017 18:05 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB45E13FF17 for <netmod@ietfa.amsl.com>; Fri, 3 Nov 2017 11:05:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2zXnTg-4wTf for <netmod@ietfa.amsl.com>; Fri, 3 Nov 2017 11:05:43 -0700 (PDT)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84FCA13FF1F for <netmod@ietf.org>; Fri, 3 Nov 2017 11:05:41 -0700 (PDT)
Received: by mail-lf0-x236.google.com with SMTP id 90so4066469lfs.13 for <netmod@ietf.org>; Fri, 03 Nov 2017 11:05:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=3jfObJvV6W9svHnpjtLScI1QigbMyPF5s+7Lxp1i0ew=; b=r+GXcRjxc4pCABJazlIUdOVm9WYyuVcZn8gkilyEQ710kLQspTiIKqBJKOZyKxuKH8 OQ1GEL4Jnm2Xm22XyccZ7wIg0m7fTv8DFu7AUJh0dyWo16c1OUo7HZycq3xXWeky0Lwp 34VeEJjufdEXMqLek6ESPMPS81k8OLzwJ8PlYupA3r5kkGUTDoATHyqAnN0vnWk22TDH be4CkAEX5fdvQM1b/sHb2Ur1W7eZG2lwjzPO2B8AefNaz1TirN0qNgG/4rFqr+fq3Nz1 LOtwD/IFyEjWjvH4N6b+Yc5nHCm9r8g05c6rnbTdrHPlmP+eS08Vk13ZOyw+neA4vu2h 1Psw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=3jfObJvV6W9svHnpjtLScI1QigbMyPF5s+7Lxp1i0ew=; b=k+wVV4p9MLtuyi4HjNBeYslzpamWW03KEHdqnSIjK5kmhwn5RWxReyzSpuU1FzujW8 QnKAL5m+uYSgcHc/Ti2jIg89rvFl6cALIQFW1tWS9bwyfRgdQMp8yAX+7zNnQ8yZ1ZC8 YaV3rH1zXaUfX7/45Cfaq0IJWm5+7vSUcm8mxrKqN6eRWm/6TPiCbHb7HrAAXWjHDRe2 RJlYedrXq0pL4E/ZMg/vJb80JQLGqpABBtErmFzDTB/g1yq56mhZlIW38rVBG9/HXcUa UWGIVsJP6xKyJZ7xJTdwpotCUOG/tJvABht8VYBtisAIzmalxMR9wpdlvwIov8ypRWxy 56Bg==
X-Gm-Message-State: AMCzsaUQEIJEGmo4VpCQbDjbCA7cqggdRxOWYZ4wUnYoJiaEnGgOm34h wogAO8hDdfU0lCRRYz4wzSTZwYdn4yWLwkg2MxNl2Q==
X-Google-Smtp-Source: ABhQp+QYk9TmuiOolRkYex4+30Z1oYd8E8OTPD4t3rZswNX2QV7RoESEqdw6oMbd85Cblpgsy3qnsbS7O//8YmCegiI=
X-Received: by 10.46.2.197 with SMTP id y66mr3251090lje.151.1509732339694; Fri, 03 Nov 2017 11:05:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.214.9 with HTTP; Fri, 3 Nov 2017 11:05:38 -0700 (PDT)
In-Reply-To: <20171103174811.vmsgcsdt5u5avxgu@elstar.local>
References: <caa884d9-9d71-e7ad-cffd-427b58750c58@labn.net> <751fa015-a917-a104-f6c6-25cc9a5accba@cisco.com> <15f105bf980.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <708ad6ca-e37b-6236-59b2-80c611b132ae@cisco.com> <a623bac8-cf84-9c46-2fc8-1556197d295f@cisco.com> <db5b506a-cb4f-e74b-cf4c-a175c56ee5c3@cisco.com> <20171103174811.vmsgcsdt5u5avxgu@elstar.local>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 3 Nov 2017 11:05:38 -0700
Message-ID: <CABCOCHRLZbWaUYeYtZp2NcCQGghbwtbCDZ4TiHQkKVL2Xx5-8Q@mail.gmail.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Benoit Claise <bclaise@cisco.com>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c1cddead0959d055d17f3c9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/3hLrGWFQUZbEimK80TwhyoUKXgo>
Subject: Re: [netmod] draft-clacla-netmod-yang-model-update-00.txt : Re: [RTG-DIR] handling module incompatibility => handling module transition
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2017 18:05:47 -0000

On Fri, Nov 3, 2017 at 10:48 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de>; wrote:

> My take here is that structured version numbers do only partially
> solve the problem. Andy's work years ago on packages offers in my view
> a superior foundation for a solution. Once we can bundle modules that
> are designed and known to work together into meaningful packages, then
> it may be possible to relax some of the strict RFC 7950 update
> rules.
>
> Once the NETMOD WG gets the work on NMDA "completed", I believe "YANG
> packages" are a worthwhile target to work on. There is a need to get
> more structure into the module space, not just additional structured
> version numbers.
>
>
I agree ;-)

It is nice to have a way to know current implementations will probably
break if they upgrade to the new version. It is even nicer if the APIs
are stable and don't break existing code.

It is not encouraging that the IETF cannot produce stable YANG modules
published in RFCs.  We expect I-Ds to ignore the YANG update rules,
but not RFC versions.

Since the semantic versioning is only per-module, it is not usefull for
determining if module foo will work with module bar.  If it is OK
to break backward-compatibility then it will become increasingly
difficult to just use the latest version of a module. Real interoperability
at the granularity of modules will become more difficult. YANG packages
can dramatically reduce the number of API permutations.


/js
>


Andy


>
> On Fri, Nov 03, 2017 at 06:30:52PM +0100, Benoit Claise wrote:
> > Dear all,
> >
> > Let me present this draft
> > https://datatracker.ietf.org/doc/draft-clacla-netmod-yang-model-update/
> >
> >                     New YANG Module Update Procedure
> >                 draft-clacla-netmod-yang-model-update-01
> >
> > Abstract
> >
> >    This document specifies a new YANG module update procedure in case of
> >    non backward-compatible changes, as an alternative proposal to the
> >    YANG 1.1 specifications.  This document updates RFC 7950.
> >
> >
> > Problem statement:
> > Changing a YANG module name each time there is a non backward compatible
> > change (as RFC7950 requires) adds a lot of complexity to automation,
> from an
> > import and service composition point of view.
> >
> > Solution:
> > We need a different mechanism. The solution in the draft is based on the
> > semantic versioning YANG extension: it was proposed openconfig in the
> past
> > and is currently used by the openconfig YANG modules
> >
> > Note: there might other solutions, such as new YANG keywords, but at this
> > point in time, it's important to recognize that we need to change the
> way we
> > produce YANG modules at the IETF. Let's discuss on the list and during
> the
> > NETMOD meeting.
> >
> > Regards, Benoit.
> > > On 10/12/2017 3:30 PM, Benoit Claise wrote:
> > > > Hi Lou,
> > > > >
> > > > > So circling back to the original question: what do we do about
> > > > > the non backward-compatible module being defined in rfc8049bis?
> > > > >
> > > > > While being sympathetic to many of the comments made below as
> > > > > well as the "do over" concept, I find the comments about
> > > > > adhering to the rules of 7950 compelling - which leads to
> > > > > renaming the module in the bis to ietf-l3vpn-svc-2.
> > > > >
> > > > > It would be good to ensure that this is the consensus of the
> > > > > group before asking the authors make this change.
> > > > >
> > > > Since this draft is AD sponsored, I'll evaluate the consensus on
> > > > RFC8049bis.
> > > > Moving to ietf-l3vpn-svc-2 is the easy path not to break backward
> > > > compatibility. However, since ietf-l3vpn-svc is unimplementable (it
> > > > has broken XPATH expressions, so a compliant implementation is
> > > > impossible), so technically, ietf-l3vpn-svc does not even exist.
> > > See my message on this topic, as the IETF LC follow up.
> > > https://www.ietf.org/mail-archive/web/ietf-announce/
> current/maillist.html
> > > If a follow up is required, I propose that we use a single public email
> > > thread: the ietf@ietf.org
> > >
> > > Regards, Benoit
> > > >
> > > > What NETMOD should focus on is closing on the NMDA transition: the
> > > > ietf-routing versus ietf-routing-2 issue.
> > > > Way bigger impact in terms of dependent YANG modules
> > > >
> > > > Regards, Benoit (as OPS AD)
> > > > See below.
> > > > >
> > > > > This change course doesn't solve the versioning issue discussed
> > > > > below, but this is not a new issue it's just the first time
> > > > > we'll actually executing the steps envisioned as part of the
> > > > > rules laid out in yang. My personal take away is that means that
> > > > > we should immediately start work on an extension defining along
> > > > > the lines of  ' *_obsolete|update_*' mentioned below.
> > > > >
> > > > I believe that option 1 is the more pragmatic and complete solution.
> > > > option 2 is just half a step in the right direction.
> > > > I believe we should discuss this topic in Singapore.
> > > >
> > > > Regards, Benoit (as individual contributor)
> > > > >
> > > > > Lou
> > > > >
> > > > > On October 8, 2017 10:59:15 AM Benoit Claise <bclaise@cisco.com>;
> wrote:
> > > > >
> > > > > > Dear all,
> > > > > >
> > > > > > Focusing on draft-wu-l3sm-rfc8049bis, the big problem is:
> > > > > > RFC8049 is broken. The small problem is: trying to maintain
> > > > > > backward compatibility.
> > > > > > draft-wu-l3sm-rfc8049bis has rightly focused on the big problem.
> > > > > >
> > > > > > Let me extend the scope of this email thread from "handling
> > > > > > module incompatibility" to "handling module incompatibility
> > > > > > and NMDA transition".
> > > > > > As I mentioned in the past (see "semver.org comparison of
> > > > > > two YANG modules" email in NETMOD), I believe the IETF will
> > > > > > have to change its way of working in terms of backward
> > > > > > compatibility. See also the email "ietf-routing or
> > > > > > ietf-routing-2? module naming convention for NMDA
> > > > > > transition. Re: [netmod] upcoming adoptions" in NETMOD.
> > > > > >
> > > > > > However, we will have to tackle this discussion one day or the
> other:
> > > > > > - we need _an automatic way_ to make the link between the
> > > > > > YANG module in RFC8049 and the YANG module in
> > > > > > draft-wu-l3sm-rfc8049bis, or any non backward compatible
> > > > > > YANG modules.
> > > > > > - we need _an automatic way_ to make the link between the
> > > > > > YANG module in RFC8022 and the YANG module in
> > > > > > draft-acee-netmod-rfc8022bis, or any new YANG module names
> > > > > > used for NMDA transition.
> > > > > > Note: actually, we face two different problems.
> > > > > > draft-wu-l3sm-rfc8049bis might be declared backward
> > > > > > incompatible with RFC8049, while RFC8022bis is backward
> > > > > > compatible with RFC8022. The RFC8022bis went for a new YANG
> > > > > > module name ietf-routing-2 to avoid to document the -state
> > > > > > tree (as deprecated), based on the argument that
> > > > > > ietf-routing is not yet implemented.
> > > > > >
> > > > > > Which solutions do we have from here?
> > > > > > #1. We keep the same module name and express that the YANG
> > > > > > module in draft-wu-l3sm-rfc8049bis is not backward
> > > > > > compatible with the RFC8049 one. This is the openconfig way.
> > > > > > See draft-clacla-netmod-model-catalog (and
> > > > > > draft-openconfig-netmod-model-catalog before)
> > > > > >
> > > > > >        // extension statements
> > > > > >           extension openconfig-version {
> > > > > >             argument "semver" {
> > > > > >               yin-element false;
> > > > > >             }
> > > > > >             description
> > > > > >               "The OpenConfig version number for the module.
> This is
> > > > > >               expressed as a semantic version number of the form:
> > > > > >                 x.y.z
> > > > > >                where:
> > > > > >                 * x corresponds to the major version,
> > > > > >                 * y corresponds to a minor version,
> > > > > >                 * z corresponds to a patch version.
> > > > > >               This version corresponds to the model file within
> which it is
> > > > > >               defined, and does not cover the whole set of
> OpenConfig models.
> > > > > >               Where several modules are used to build up a
> single block of
> > > > > >               functionality, the same module version is
> specified across each
> > > > > >               file that makes up the module.
> > > > > >
> > > > > >               A major version number of 0 indicates that this
> model is still
> > > > > >               in development (whether within OpenConfig or with
> industry
> > > > > >               partners), and is potentially subject to change.
> > > > > >
> > > > > >               Following a release of major version 1, all
> modules will
> > > > > >               increment major revision number where backwards
> incompatible
> > > > > >               changes to the model are made.
> > > > > >
> > > > > >               The minor version is changed when features are
> added to the
> > > > > >               model that do not impact current clients use of
> the model.
> > > > > >
> > > > > >               The patch-level version is incremented when
> non-feature changes
> > > > > >               (such as bugfixes or clarifications to
> human-readable
> > > > > >               descriptions that do not impact model
> functionality) are made
> > > > > >               that maintain backwards compatibility.
> > > > > >
> > > > > >               The version number is stored in the module
> meta-data.";
> > > > > >           }
> > > > > >
> > > > > > Similarly, we always keep the same YANG module name in case
> > > > > > of NMDA transition. So ietf-routing-2 should be changed back
> > > > > > to ietf-routing.
> > > > > > The email thread "[Rtg-dt-yang-arch] ietf-routing or
> > > > > > ietf-routing-2? module naming convention for NMDA
> > > > > > transition. Re: [netmod] upcoming adoptions" seems to go in
> > > > > > that direction.
> > > > > >
> > > > > > #2. Or we have a different module name, let's say
> > > > > > ietf-l3vpn-svc-2 or ietf-routing-2 but then, how do we make
> > > > > > the link with the previous module?
> > > > > > Then ...  What? We create extension that will link the
> > > > > > draft-wu-l3sm-rfc8049bis YANG module to the RFC8049 YANG
> > > > > > module? Same principle as #1, but just more complex.
> > > > > > Or we have a new YANG keyword (this implies YANG 2.0)
> > > > > >
> > > > > >     <CODE BEGINS>file"ietf-l3vpn-svc@2017-09-14.yang";
> > > > > >     module ietf-l3vpn-svc-2 {
> > > > > >       yang-version 1.1;
> > > > > >       namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc";
> > > > > >       prefix l3vpn-svc;
> > > > > >       *_obsolete|update _*ietf-l3vpn-svc@2017-01-2
> > > > > >
> > > > > > And whose responsibility is this to warn/push all authors of
> > > > > > ietf-routing YANG modules to move to ietf-routing-2? (*)
> > > > > >
> > > > > > The following are non solution IMO:
> > > > > > - Going from the draft-wu-l3sm-rfc8049bis YANG _module _to
> > > > > > the draft-wu-l3sm-rfc8049bis _document _to lookup the IETF
> > > > > > "obsolete" flag in order to understand that the RFC8049 YANG
> > > > > > module is obsolete is not an automatic solution.
> > > > > > - Using the yangcatalog.org might be a solution as we track
> > > > > > the derived semantic, but this is just an offline trick.
> > > > > > This is not what I call "automatic way"
> > > > > > - Using the YANG module description field might be
> > > > > > interesting, but again this is not an "automatic way":
> > > > > >
> > > > > >       description
> > > > > >        "This YANG module defines a generic service configuration
> > > > > >         model for Layer 3 VPNs. This model is common across all
> > > > > >         vendor implementations. This obsoletes the RFC8049 YANG
> > > > > >         module, ietf-l3vpn-svc@2017-01-2";
> > > > > >       revision 2017-09-14 {
> > > > > >        description
> > > > > >     "First revision ofRFC8049 <https://tools.ietf.org/html/
> rfc8049>.";
> > > > > >        reference
> > > > > >         "RFC xxxx: YANG Data Model for L3VPN Service Delivery";
> > > > > >
> > > > > >
> > > > > > In conclusion, I believe openconfig got this right and that
> > > > > > solution #1 is the solution to go ... while waiting for a
> > > > > > new YANG keyword in YANG 2.0
> > > > > >
> > > > > > (*) If you want to change the module from ietf-routing to
> > > > > > ietf-routing-2, then you should follow with all authors of
> > > > > > dependent modules to make sure they transition to
> > > > > > ietf-routing-2
> > > > > > In the yangcatalog.org, because I needed the information as
> > > > > > OPS AD, we created a small script to get that authors list
> > > > > > for IETF drafts. For the ietf-routing, this produces the
> > > > > > following
> > > > > > {
> > > > > >     "output": {
> > > > > >         "author-email": [
> > > > > > "draft-ietf-mpls-static-yang@ietf.org";,
> > > > > > "draft-ietf-mpls-base-yang@ietf.org";,
> > > > > > "draft-ietf-ospf-sr-yang@ietf.org";,
> > > > > > "draft-ietf-pim-yang@ietf.org";,
> > > > > > "draft-ietf-bier-bier-yang@ietf.org";,
> > > > > > "draft-zhang-bier-te-yang@ietf.org";,
> > > > > > "draft-ietf-isis-yang-isis-cfg@ietf.org";,
> > > > > > "draft-ietf-teas-yang-rsvp-te@ietf.org";,
> > > > > > "draft-ietf-mpls-mldp-yang@ietf.org";,
> > > > > > "draft-zhao-pim-igmp-mld-snooping-yang@ietf.org";,
> > > > > > "draft-ietf-isis-sr-yang@ietf.org";,
> > > > > > "draft-acee-rtgwg-yang-rib-extend@ietf.org";,
> > > > > > "draft-ietf-pim-igmp-mld-yang@ietf.org";,
> > > > > > "draft-ietf-i2rs-fb-rib-data-model@ietf.org";,
> > > > > > "draft-ietf-ospf-yang@ietf.org";,
> > > > > > "draft-ietf-rtgwg-yang-rip@ietf.org";,
> > > > > > "draft-ietf-spring-sr-yang@ietf.org";,
> > > > > > "draft-ietf-teas-yang-rsvp@ietf.org";,
> > > > > > "draft-ietf-i2rs-pkt-eca-data-model@ietf.org";,
> > > > > > "draft-ietf-mpls-ldp-yang@ietf.org";,
> > > > > > "draft-ietf-bfd-yang@ietf.org";,
> > > > > > "draft-ietf-pim-msdp-yang@ietf.org";
> > > > > >         ]
> > > > > >     }
> > > > > > }
> > > > > >
> > > > > > Fortunately, we only deal with IETF dependent YANG modules
> > > > > > in case of the ietf-routing. That's an easier case.
> > > > > > If we would change ietf-interfaces to ietf-interfaces-2, we
> > > > > > would have an cross SDO issue ... Btw, there are no
> > > > > > automatic ways to extract the authors of YANG modules from
> > > > > > different SDOs: it's only a metadata that that the different
> > > > > > SDOs should insert in the yangcatalog. So we would have to
> > > > > > rely on liaisons or direct emails, assuming we know the
> > > > > > authors. Time consuming, believe me.
> > > > > >
> > > > > > Regards, Benoit
> > > > > > > Hi,
> > > > > > >
> > > > > > >      As part of the my Routing Directorate review of
> > > > > > > draft-wu-l3sm-rfc8049bis I noted that there were several
> incompatible
> > > > > > > changes being made to the ietf-l3vpn-svc module without
> changing the
> > > > > > > name.  I raised this with the YANG doctors and others involved
> with the
> > > > > > > draft and it surfaced some topics which really should be
> discussed here
> > > > > > > in NetMod.
> > > > > > >
> > > > > > > The background (as explained off-list by others, so I hope I
> have it
> > > > > > > right)  is that one of the YANG Doctors noted that RFC8049 was
> broken
> > > > > > > and could not be implemented as defined, and therefore a fix
> was
> > > > > > > needed.  L3SM has concluded so the fix is in the individual
> draft
> > > > > > > draft-wu-l3sm-rfc8049bis.  Since the rfc8049 version of
> ietf-l3vpn-svc
> > > > > > > module could not be implemented, the feeling by the YANG Dr
> was that
> > > > > > > even though the new module is incompatible with the original
> definition
> > > > > > > the module the rule defined in Section 11 of YANG 1.1 (or
> section 10 of
> > > > > > > RFC 6020) didn't have to be followed and the same name could
> be used.
> > > > > > >
> > > > > > > In the subsequent discussion with the YANG Drs., the general
> discussion
> > > > > > > was heading down the path of using a new module name, and
> thereby not
> > > > > > > violating YANG module update rules.  This lead us back to the
> a similar
> > > > > > > discussion we've been having in the context of 8022bis: how
> best to
> > > > > > > indicate that a whole module is being obsoleted.  RFCs do this
> by adding
> > > > > > > 'metadata' to the headers, e.g., "Obsoletes: 8049", but this
> doesn't
> > > > > > > help YANG tooling.  For 8022, we have one approach -
> publishing an
> > > > > > > updated rev of the original module marking all nodes as
> deprecated - but
> > > > > > > that doesn't really make sense for rfc8049bis.
> > > > > > >
> > > > > > > So the discussion for the WG is:
> > > > > > >
> > > > > > > How do we handle incompatible module changes, notably when one
> module
> > > > > > > 'obsoletes' another module --  from both the process and
> tooling
> > > > > > > perspectives?
> > > > > > >
> > > > > > > I know Benoit plans to bring in some thoughts/proposals,
> perhaps there
> > > > > > > are others.
> > > > > > >
> > > > > > > Cheers,
> > > > > > >
> > > > > > > Lou
> > > > > > >
> > > > > > > (as contributor/reviewer)
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > >
> > >
> >
>
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>