Re: [netmod] AD review of draft-ietf-netmod-entity-06

Benoit Claise <bclaise@cisco.com> Fri, 12 January 2018 18:56 UTC

Return-Path: <bclaise@cisco.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 924FE128D2E for <netmod@ietfa.amsl.com>; Fri, 12 Jan 2018 10:56:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 c8bR-9981xBT for <netmod@ietfa.amsl.com>; Fri, 12 Jan 2018 10:56:00 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 886AA126D0C for <netmod@ietf.org>; Fri, 12 Jan 2018 10:55:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40647; q=dns/txt; s=iport; t=1515783359; x=1516992959; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=JhxTO5W2xQs9IetLQu/vWaX8kiN4qdoApjOtpL9mNoI=; b=Agwy/WG5awSqCVKHHuvwNAi3P70sETXyJ1wAUKIP34yDq21D4MbpCLom yq+pKz4z81s+FSe57xL9oWU7ZqwzgUPe1RNLG8lvyvFa13Q9X/+5pN7dv Zhca3v8+B9qqQO/bMHRMH9i0MEkGeycXYW7zln4k6KK6MQ0Zb9ieDwkyk k=;
X-IronPort-AV: E=Sophos;i="5.46,350,1511827200"; d="scan'208,217";a="1377247"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2018 18:55:57 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w0CItv1B006176; Fri, 12 Jan 2018 18:55:57 GMT
To: Joe Clarke <jclarke@cisco.com>, "Einar Nilsen-Nygaard (einarnn)" <einarnn@cisco.com>, "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <rwilton@cisco.com>, Martin Bjorklund <mbj@tail-f.com>, "bart.bogaert@nokia.com" <bart.bogaert@nokia.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>
References: <20180109.163933.49682684192910889.mbj@tail-f.com> <AM4PR07MB1716D69A0AF0BBCD3BAF71D094110@AM4PR07MB1716.eurprd07.prod.outlook.com> <20180110.144453.957272588242505523.mbj@tail-f.com> <20180111.144705.493071366326080006.mbj@tail-f.com> <51501b53-9693-4ecd-1493-e21263b22b19@cisco.com> <A351BFBA-526E-4F85-96F7-D95E58A374F9@cisco.com> <823fdeb7-3b4b-2504-364d-ef68502adccf@cisco.com>
From: Benoit Claise <bclaise@cisco.com>
Message-ID: <64740fb9-7f4c-59ee-ecd2-4474ae5deb77@cisco.com>
Date: Fri, 12 Jan 2018 19:55:57 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <823fdeb7-3b4b-2504-364d-ef68502adccf@cisco.com>
Content-Type: multipart/alternative; boundary="------------2471BAC3EEA934B9A4AC988A"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/HWZN-9qQBNTe7Wpd8F3HfCW1PPk>
Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06
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, 12 Jan 2018 18:56:05 -0000

On 1/12/2018 2:33 PM, Joe Clarke wrote:
> On 1/12/18 05:52, Einar Nilsen-Nygaard (einarnn) wrote:
>> Yes, Option 2 seems best.
> Agreed.  I believe most assume these are static values from the vendor
> that are not field-writeable (certainly that is true from what I've seen
> here at Cisco).
Yep, this is why I wrote in a previous email:

    For example, entPhysicalSerialNum being read-write always bothered me.
    serial-num is now "config false", which is a good news IMO.

So option 2 seems about right to me.
Would be nice if the new draft explain that/how people can augment.

Regards, Benoit (as a contributor)
>
> Joe
>
>> Cheers,
>>
>> Einar
>>
>>
>>> On 11 Jan 2018, at 17:56, Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) <rwilton@cisco.com> wrote:
>>>
>>>
>>>
>>> On 11/01/2018 13:47, Martin Bjorklund wrote:
>>>> Hi,
>>>>
>>>> To summarize this, I think we have three options for the three nodes
>>>> 'model-name', 'mfg-name', and 'serial-num':
>>>>
>>>>    1.  Do nothing (keep the nodes as config true).
>>>>
>>>>    2.  Make these three nodes config false (fairly simple change).
>>>>        (vendors can augment w/ their own config true nodes).
>>>>
>>>>    3.  Add three new nodes for the configured values.
>>>>
>>>>
>>>> After thinking about this some more, and discussing with Benoit, I
>>>> think the best path forward is to do 2, i.e., mark the nodes
>>>> 'model-name', 'mfg-name', and 'serial-num' as "config false".  As such
>>>> they would not be configurable, and thus contain the detected values.
>>>> If no value is detected, the node is not present.
>>> Option 2 suits me.  It keeps it simple.
>>>
>>>> Note that 1 or 3 can be done in a future update to this module (or by
>>>> a vendor).
>>> Agreed.
>>>
>>> Thanks,
>>> Rob
>>>
>>>
>>>>
>>>> /martin
>>>>
>>>>
>>>> Martin Bjorklund <mbj@tail-f.com> wrote:
>>>>> Hi,
>>>>>
>>>>> "Bogaert, Bart (Nokia - BE/Antwerp)" <bart.bogaert@nokia.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> --- snip ---
>>>>>>
>>>>>>> state.”, so the above sentence only applies for the second case below.
>>>>>> Ok.
>>>>>>
>>>>>>> 2. The second case is that something is detected but it can’t be read.
>>>>>>> We do not see a reason to use the value configured for the leafs
>>>>>>> ‘serial-num’, ‘mfg-name’ and ‘model-name’ of a matching entry in the
>>>>>>> configuration data.  These leafs are defined as optional so why would
>>>>>>> we report something entered by an operator in the operational
>>>>>>> datastore that intends to report on what is detected?  Is it not
>>>>>>> better to not report them at all?  In an NMDA context it would be
>>>>>>> possible to have a different value (or no value at all) for certain
>>>>>>> leafs while there is something in the running/intended datastore.
>>>>>> The normal NMDA procedure for a configuration leaf is to repeat it in
>>>>>> operational state.  This is then the "applied configuration".
>>>>>> I don't think we should have a special rule for these leafs.
>>>>>>
>>>>>> This also means that a client that just wants to read all the serial
>>>>>> numbers can do so from one place, the operational state, regardless of
>>>>>> how they came into existance.
>>>>>>
>>>>>> [Bogaert, Bart ]
>>>>>>
>>>>>> We do understand that a target of NMDA is to read out the actually
>>>>>> applied data in one request.  But the result should not be
>>>>>> confusion. A key word is “applied”.
>>>>>>
>>>>>> Section 5.3 of draft-ietf-netmod-revised-datastores-09 also contains
>>>>>> (I put a part of the section between ***):
>>>>>> The datastore schema for <operational> MUST be a superset of the
>>>>>> combined datastore schema used in all configuration datastores except
>>>>>> that configuration data nodes supported in a configuration datastore
>>>>>> ***MAY be omitted from <operational> if a server is not able to
>>>>>> accurately report them ***.
>>>>> Note that this text talks about the *schema*.  It is intended for
>>>>> servers to migrate to NMDA without having to instrument all config
>>>>> nodes in <operational> immediately.  If you apply this to
>>>>> ietf-hardware, it could be a server that implements the node
>>>>> "serial-num" in config, but not in <operational> (which would be
>>>>> weird).
>>>>>
>>>>>> For example, it is expected that the value of multiple leafs need to
>>>>>> be a consistent set, e.g. the mfg-name, the model-name, and the
>>>>>> serial-num.
>>>>>> Suppose we have a use case in which a hardware component is
>>>>>> planned/configured (e.g. a board supporting DSL interfaces) but a
>>>>>> different one is plugged (e.g. a board supporting ethernet
>>>>>> interfaces).
>>>>>> Suppose it is possible to read some fields on the detected component
>>>>>> but due to an issue not to read other fields.
>>>>>> If in that case the operational datastore will be completed with the
>>>>>> data taken from the running datastore, then the presented view might
>>>>>> be inconsistent.
>>>>> This is true for other similar nodes as well - "asset-id" and "uri".
>>>>>
>>>>>> The question is also: what data is applied? Our assumption: if there
>>>>>> is a mismatch between detected versus configured hardware, then the
>>>>>> interface/service related data that is configured consistently with
>>>>>> the planned hardware is not applied on the mismatching
>>>>>> hardware. I.e. the detected hardware is not brought in service so not
>>>>>> ‘applied’, the operational datastore only (accurately) reports on what
>>>>>> is detected.
>>>>> If there is a mismatch and the server doesn't apply the configured
>>>>> values, then obviously the configured 'mfg-name' etc are not copied to
>>>>> <operational>.
>>>>>
>>>>>> We do not see this as a special rule for this data but rather would
>>>>>> apply a general rule:
>>>>>> -	if there is a ‘missing resource’, then the data is not reported in the
>>>>>>   	operational datastore.
>>>>>> -	If the server is not able to report accurately, then the data is
>>>>>>   	omitted from the operational
>>>>> I think that if you want complete separation between the values of
>>>>> 'mfg-name', 'model-name', and 'serial-num' in configuration and
>>>>> operational state, then these should be modelled as separate leafs.
>>>>> We should have a config false leaf 'serial-num' that only contains the
>>>>> detected value (if found), and a config true leaf 'config-serial-num'
>>>>> or something, that contains the configured serial number.
>>>>>
>>>>> But if this is the case, I wonder if it wouldn't be better to leave
>>>>> such additional config objects to vendors, and simply make these three
>>>>> nodes config false in ietf-hardware.
>>>>>
>>>>>
>>>>> /martin
>>>>>
>>>>>> Regards, Bart
>>>>>>
>>>>>> /martin
>>>>>>
>>>>>>
>>>>>>> Best regards, Bart
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert
>>>>>>> Wilton
>>>>>>> Sent: Thursday, December 21, 2017 4:14 PM
>>>>>>> To: Martin Bjorklund <mbj@tail-f.com>om>; netmod@ietf.org
>>>>>>> Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06
>>>>>>>
>>>>>>> Hi Martin,
>>>>>>>
>>>>>>>
>>>>>>> On 21/12/2017 11:37, Martin Bjorklund wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I need WG input on this issue.  The question is how to handle
>>>>>>>> 'serial-num', 'mfg-name', and 'model-name'.  I think they should all
>>>>>>>> be treated the same.  Based on previous WG discussion (see e.g. the
>>>>>>>> mail thread "draft-ietf-netmod-entity issue #13"), I think they
>>>>>>>> should all be configurable, but the configured value is only used in
>>>>>>>> operational state if the system cannot read it from the hardware.
>>>>>>> I think that this approach is probably OK:
>>>>>>>    - The client can always see the real value if it is available.
>>>>>>>    - If it is not available then they can assign a value via
>>>>>>> configuration.
>>>>>>>
>>>>>>> I was also considering an alternative approach of having a separate
>>>>>>> set of config false leaves for the "burnt in values".  And then having
>>>>>>> the configurable leaves always override the default operational
>>>>>>> values. E.g. similar to how an interface MAC address would expect to
>>>>>>> be handled.
>>>>>>>
>>>>>>> But one set of leaves is probably sufficient.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Rob
>>>>>>>
>>>>>>>
>>>>>>>> So I suggest the following changes:
>>>>>>>>
>>>>>>>> OLD:
>>>>>>>>
>>>>>>>>         leaf serial-num {
>>>>>>>>           type string;
>>>>>>>>           config false;
>>>>>>>>           description
>>>>>>>>             "The vendor-specific serial number string for the
>>>>>>>>              component.  The preferred value is the serial number
>>>>>>>>              string actually printed on the component itself (if
>>>>>>>>              present).";
>>>>>>>>           reference "RFC 6933: entPhysicalSerialNum";
>>>>>>>>         }
>>>>>>>>
>>>>>>>> NEW:
>>>>>>>>
>>>>>>>>         leaf serial-num {
>>>>>>>>           type string;
>>>>>>>>           description
>>>>>>>>             "The vendor-specific serial number string for the
>>>>>>>>              component.  The preferred value is the serial number
>>>>>>>>              string actually printed on the component itself (if
>>>>>>>>              present).
>>>>>>>>
>>>>>>>>              This leaf can be configured.  There are two use cases for
>>>>>>>>              this; as a 'post-it' note if the server cannot determine
>>>>>>>>              this value from the component, or when pre-provisioning a
>>>>>>>>              component.
>>>>>>>>
>>>>>>>>              If the server can determine the serial number from the
>>>>>>>>              component, then that value is always used in operational
>>>>>>>>              state, even if another value has been configured.";
>>>>>>>>           reference "RFC 6933: entPhysicalSerialNum";
>>>>>>>>         }
>>>>>>>>
>>>>>>>> And corresponding text for 'mfg-name' and 'model-name'.
>>>>>>>>
>>>>>>>> And also:
>>>>>>>>
>>>>>>>> OLD:
>>>>>>>>
>>>>>>>>            When the server detects a new hardware component, it
>>>>>>>>            initializes a list entry in the operational state.
>>>>>>>>
>>>>>>>>            If the server does not support configuration of hardware
>>>>>>>>            components, list entries in the operational state are
>>>>>>>>            initialized with values for all nodes as detected by the
>>>>>>>>            implementation.
>>>>>>>>
>>>>>>>>            Otherwise, the following procedure is followed:
>>>>>>>>
>>>>>>>>              1. If there is an entry in the /hardware/component list in
>>>>>>>>                 the intended configuration with values for the nodes
>>>>>>>>                 'class', 'parent', 'parent-rel-pos' that are equal to
>>>>>>>>                 the detected values, then:
>>>>>>>>
>>>>>>>>              1a. If the configured entry has a value for 'mfg-name'
>>>>>>>>                  that is equal to the detected value, or if the
>>>>>>>>                  'mfg-name' value cannot be detected, then the list
>>>>>>>>                  entry in the operational state is initialized with the
>>>>>>>>                  configured values for all configured nodes, including
>>>>>>>>                  the 'name'.
>>>>>>>>
>>>>>>>>                  Otherwise, the list entry in the operational state is
>>>>>>>>                  initialized with values for all nodes as detected by
>>>>>>>>                  the implementation.  The implementation may raise an
>>>>>>>>                  alarm that informs about the 'mfg-name' mismatch
>>>>>>>>                  condition.  How this is done is outside the scope of
>>>>>>>>                  this document.
>>>>>>>>
>>>>>>>>              1b. Otherwise (i.e., there is no matching configuration
>>>>>>>>                  entry), the list entry in the operational state is
>>>>>>>>                  initialized with values for all nodes as detected by
>>>>>>>>                  the implementation.
>>>>>>>>
>>>>>>>>            If the /hardware/component list in the intended
>>>>>>>>            configuration is modified, then the system MUST behave as if
>>>>>>>>            it re-initializes itself, and follow the procedure in
>>>>>>>> (1).";
>>>>>>>>
>>>>>>>> NEW:
>>>>>>>>
>>>>>>>>            When the server detects a new hardware component, it
>>>>>>>>            initializes a list entry in the operational state.
>>>>>>>>
>>>>>>>>            If the server does not support configuration of hardware
>>>>>>>>            components, list entries in the operational state are
>>>>>>>>            initialized with values for all nodes as detected by the
>>>>>>>>            implementation.
>>>>>>>>
>>>>>>>>            Otherwise, the following procedure is followed:
>>>>>>>>
>>>>>>>>              1. If there is an entry in the /hardware/component list in
>>>>>>>>                 the intended configuration with values for the nodes
>>>>>>>>                 'class', 'parent', 'parent-rel-pos' that are equal to
>>>>>>>>                 the detected values, then the list entry in operational
>>>>>>>>                 state is initialized with the configured values,
>>>>>>>>                 including the 'name'.  The leafs 'serial-num',
>>>>>>>>                 'mfg-name', and 'model-name' are treated specially; see
>>>>>>>>                 their descriptions for details.
>>>>>>>>
>>>>>>>>              2. Otherwise (i.e., there is no matching configuration
>>>>>>>>                 entry), the list entry in the operational state is
>>>>>>>>                 initialized with values for all nodes as detected by
>>>>>>>>                 the implementation.
>>>>>>>>
>>>>>>>>            If the /hardware/component list in the intended
>>>>>>>>            configuration is modified, then the system MUST behave as if
>>>>>>>>            it re-initializes itself, and follow the procedure in
>>>>>>>> (1).";
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> /martin
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Benoit Claise <bclaise@cisco.com> wrote:
>>>>>>>>> On 12/20/2017 4:00 PM, Martin Bjorklund wrote:
>>>>>>>>>> Benoit Claise <bclaise@cisco.com> wrote:
>>>>>>>>>>> Hi Martin,
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>> Only kept the relevant excerpts.
>>>>>>>>>>>>> - Some objects are read-write in RFC6933:
>>>>>>>>>>>>>           entPhysicalSerialNum
>>>>>>>>>>>>>           entPhysicalAlias
>>>>>>>>>>>>>           entPhysicalAssetID
>>>>>>>>>>>>>           entPhysicalUris
>>>>>>>>>>>>>
>>>>>>>>>>>>> For example, entPhysicalSerialNum being read-write always bothered
>>>>>>>>>>>>> me.
>>>>>>>>>>>>> serial-num is now "config false", which is a good news IMO.
>>>>>>>>>>>> Actually, this was not the intention.  In
>>>>>>>>>>>> draft-ietf-netmod-entity-03 this is configurable.  I missed this
>>>>>>>>>>>> in the conversion to NMDA.
>>>>>>>>>>> Ah. So no good news in this case...
>>>>>>>>>>>>> In the reverse direction, entPhysicalMfgName is read-only in
>>>>>>>>>>>>> RFC6933, while it's "config true" in draft-ietf-netmod-entity
>>>>>>>>>>>> Yes, this was added per request from the WG.  See e.g. the
>>>>>>>>>>>> thread "draft-ietf-netmod-entity issue #13".
>>>>>>>>>>> Sure. It was mainly an observation.
>>>>>>>>>>>> However, I think that what we have now is probably not correct.
>>>>>>>>>>>> I think that all nodes 'serial-num', 'mfg-name', and 'model-name'
>>>>>>>>>>>> should be config true, and the description of list 'component'
>>>>>>>>>>>> updated to reflect that all these tree leafs are handled the same way.
>>>>>>>>>>>>
>>>>>>>>>>>> I would like to know what the WG thinks about this.
>>>>>>>>>>> Talking as a contributor this time.
>>>>>>>>>>> It seems that inventory management is kind of broken when someone
>>>>>>>>>>> can change 'serial-num', 'mfg-name', and 'model-name.
>>>>>>>>>> They can't really change them.  The configured values are only
>>>>>>>>>> used (i.e. visible in the operational state) if the device cannot
>>>>>>>>>> detect them automatically.  I.e., they work as "post-it" notes only.
>>>>>>>>> If I look at, for example, the mfg-name, description, this is not
>>>>>>>>> what it says.
>>>>>>>>>
>>>>>>>>>      leaf mfg-name {
>>>>>>>>>              type string;
>>>>>>>>>              description
>>>>>>>>>                "The name of the manufacturer of this physical component.
>>>>>>>>>                 The preferred value is the manufacturer name string
>>>>>>>>>                 actually printed on the component itself (if present).
>>>>>>>>>
>>>>>>>>>                 Note that comparisons between instances of the model-name,
>>>>>>>>>                 firmware-rev, software-rev, and the serial-num nodes are
>>>>>>>>>                 only meaningful amongst component with the same value of
>>>>>>>>>                 mfg-name.
>>>>>>>>>
>>>>>>>>>                 If the manufacturer name string associated with the
>>>>>>>>>                 physical component is unknown to the server, then this
>>>>>>>>>                 node is not instantiated.";
>>>>>>>>>              reference "RFC 6933 <https://tools.ietf.org/html/rfc6933>:
>>>>>>>>>              entPhysicalMfgName";
>>>>>>>>>
>>>>>>>>> Regards, Benoit
>>>>>>>>>
>>>>>>>>>> /martin
>>>>>>>>>> .
>>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> netmod mailing list
>>>>>>>> netmod@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>>> .
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> netmod mailing list
>>>>>>> netmod@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod