Re: [netconf] Pullback tcp-client-server also?

Hi Kent, all,

I hear Michael’s argument about keepalives even if I’m not aware of any formal IETF document that says explicitly so.

OK to proceed with the proposed structure (*).

Cheers,
Med

(*) If the document was still within the WG, I would suggest to define local-bind as a separate grouping. Other transport protocols can use that grouping and therefore ensure by design that we have consistent structures between TCP/UDP, for example. Concretely, we would not need to have "ietf-udp-server" in draft-ietf-netconf-udp-client-server.

OLD:
        grouping tcp-server-grouping:
          +-- local-bind* [local-address]
          |  +-- local-address?   inet:ip-address
          |  +-- local-port?      inet:port-number
          +-- keepalives! {keepalives-supported,tcp-server-keepalives}?
             +-- idle-time?        uint16
             +-- max-probes?       uint16
             +-- probe-interval?   uint16

NEW:

        grouping basic-server-grouping:
          +-- local-bind* [local-address]
             +-- local-address    inet:ip-address
             +-- local-port?      inet:port-number

        grouping tcp-server-grouping:
          +-- local-bind* [local-address]
          |  +-- local-address    inet:ip-address
          |  +-- local-port?      inet:port-number
          +-- keepalives! {keepalives-supported,tcp-server-keepalives}?
             +-- idle-time?        uint16
             +-- max-probes?       uint16
             +-- probe-interval?   uint16

That is in YANG:

NEW :

      grouping basic-server-grouping {
        description
          "A reusable grouping for configuring a TCP server.”;
        list local-bind {
          key local-address;
          description
            "A list of bind (listen) points for this server
             instance.  A server instance may have multiple
             bind points to support, e.g., the same port in
             different address families or different ports
             in the same address family.";
          leaf local-address {
            type inet:ip-address;
            description
              "The local IP address to listen on for incoming
               TCP client connections.  To configure listening
               on all IPv4 addresses the value must be '0.0.0.0'
               (INADDR_ANY).  To configure listening on all IPv6
               addresses the value must be '::' (INADDR6_ANY).";
          }
          leaf local-port {
            type inet:port-number;
            default "0";
            description
              "The local port number to listen on for incoming TCP
               client connections.  An invalid default value (0)
               is used (instead of 'mandatory true') so that an
               application level data model may 'refine' it with
               an application specific default port number value.";
          }
        }
      }

      grouping tcp-server-grouping {
        description
          "A reusable grouping for configuring a TCP server.

           Note that this grouping uses fairly typical descendant
           node names such that a stack of 'uses' statements will
           have name conflicts.  It is intended that the consuming
           data model will resolve the issue (e.g., by wrapping
           the 'uses' statement in a container called
           'tcp-server-parameters').  This model purposely does
           not do this itself so as to provide maximum flexibility
           to consuming models.";
        uses basic-server-grouping;
        uses tcpcmn:tcp-common-grouping {
          refine "keepalives" {
            if-feature "tcp-server-keepalives";
            description
              "An if-feature statement so that implementations
               can choose to support TCP server keepalives.";
          }
        }
      }

De : Kent Watsen <kent+ietf@watsen.net>
Envoyé : mercredi 27 mars 2024 18:08
À : netconf@ietf.org
Cc : Scharf, Michael <Michael.Scharf@hs-esslingen.de>; wim.henderickx@gmail.com; Joe Clarke (jclarke) <jclarke@cisco.com>; BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>
Objet : Re: [netconf] Pullback tcp-client-server also?

Dear WG (especially Joe, Med, and Wim).

Michael and I discussed offline.   We discussed 1) a possibility of aligning the model/text with draft-ietf-tcpm-yang-tcp, 2) how best to support keep-alives, and 3) better wording for the “list local-bind” description statement.

1) Regarding aligning the model/text with draft-ietf-tcpm-yang-tcp, there are two considerations:

    A) the tcpm model uses a “union” for the “local-address” node, in represent values
        from the TCP MIB.   However, since the netconf model doesn’t need to support
        the TCP MIB values, this union in unnecessary.

    b) the tcpm description text for the “local-address” and “local-port” nodes are written
        In context of a list containing three keys.  However, since the netconf model has
        only two keys (and rightly so), this text would have to be adjusted to suit.  This
        being the case, keeping what we have seems better.

2) Regarding how to best support keep-alives.   There was some discussion earlier in this thread about moving it to be per list-entry (for maximum flexibility).  However Michael says that this may be unsupported in some TCP-stacks.  Furthermore, as a general observation, the IETF is trying to NOT promote the use to TCP-level keepalives, and hence adding complexity for them isn’t worth it.

3) Regarding the “list local-bind” description statement, where it says “¸as well as the case where a single service family may use different local-ports for different address families”, Michael says that this should be s/address families/addresses/.  That said, after looking more carefully, I found that the description could be simplified in a way that eliminated the problematic sentence altogether (see below).

In addition to the above, I found the proposal for the “local-bind” list to be keyed by both the “local-address” and “local-port” problematic.  The issue is that YANG doesn’t allow “default” values for keys (https://github.com/netmod-wg/yang-next/issues/62), and forcing well-known port values to always have to be specified seems overkill to support what appears to be an edge-case (listening to two different ports for the same "local-address” value.  Thus, I simplified the key to be just the “local-address” node.

The net-net follows:

  Tree Diagram:

        grouping tcp-server-grouping:
          +-- local-bind* [local-address]
          |  +-- local-address?   inet:ip-address
          |  +-- local-port?      inet:port-number
          +-- keepalives! {keepalives-supported,tcp-server-keepalives}?
             +-- idle-time?        uint16
             +-- max-probes?       uint16
             +-- probe-interval?   uint16

  YANG:

      grouping tcp-server-grouping {
        description
          "A reusable grouping for configuring a TCP server.

           Note that this grouping uses fairly typical descendant
           node names such that a stack of 'uses' statements will
           have name conflicts.  It is intended that the consuming
           data model will resolve the issue (e.g., by wrapping
           the 'uses' statement in a container called
           'tcp-server-parameters').  This model purposely does
           not do this itself so as to provide maximum flexibility
           to consuming models.";
        list local-bind {
          key local-address;
          description
            "A list of bind (listen) points for this server
             instance.  A server instance may have multiple
             bind points to support, e.g., the same port in
             different address families or different ports
             in the same address family.";
          leaf local-address {
            type inet:ip-address;
            description
              "The local IP address to listen on for incoming
               TCP client connections.  To configure listening
               on all IPv4 addresses the value must be '0.0.0.0'
               (INADDR_ANY).  To configure listening on all IPv6
               addresses the value must be '::' (INADDR6_ANY).";
          }
          leaf local-port {
            type inet:port-number;
            default "0";
            description
              "The local port number to listen on for incoming TCP
               client connections.  An invalid default value (0)
               is used (instead of 'mandatory true') so that an
               application level data model may 'refine' it with
               an application specific default port number value.";
          }
        }
        uses tcpcmn:tcp-common-grouping {
          refine "keepalives" {
            if-feature "tcp-server-keepalives";
            description
              "An if-feature statement so that implementations
               can choose to support TCP server keepalives.";
          }
        }
      }

Please review/bless the above - thank you!

Kent // author

On Mar 22, 2024, at 4:44 PM, Kent Watsen <kent@watsen.net<mailto:kent@watsen.net>> wrote:

Thank you Michael and Med for carrying thing conversation forward.

On Mar 22, 2024, at 4:51 PM, Scharf, Michael <Michael.Scharf@hs-esslingen.de<mailto:Michael.Scharf@hs-esslingen.de>> wrote:

Hi Med,

I agree that reusable structures make sense.

This is why I try to understand whether draft-ietf-netconf-tcp-client-server could use the same structure like draft-ietf-tcpm-yang-tcp.

As far as I understand so far, there may be two challenges in this discussion:

-        A TCP listener (server) that supports dual-stack (i.e., 0.0.0.0 and ::)

This is for sure the primary goal, to support v4 to v6 transition…

I almost wonder if the YANG model shouldn’t have “max-elements 2” and “key type”, as opposed to key "type address port".

-        A server application that listens on multiple different IP addresses (other than 0.0.0.0 and ::, possibly with different AF), which might require separate sockets when the sockets API is used

This may be a goal.  For instance, having ‘sshd’ listen to both a public and private V4 address [1].

But this is rather app-specific.  Just because SSHD can do this doesn’t mean every TCP-based app can.

[1] https://www.cyberciti.biz/tips/howto-openssh-sshd-listen-multiple-ip-address.html

 Please let me know if this is a misunderstanding.

The latter may be relevant for a service model, but AFAIK the network stack considers this as separate TCP listeners.

For max flexibility, the model can allow lists with no “max-elements” and overlapping AFs.   But, since the max-flex case isn’t universal, I’d hope that consuming models could restrict it as needed (e.g., to the simple dual-stack case)

 MIchael

Kent

From: mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>
Sent: Thursday, March 21, 2024 10:52 PM
To: Scharf, Michael <Michael.Scharf@hs-esslingen.de<mailto:Michael.Scharf@hs-esslingen.de>>; Joe Clarke (jclarke) <jclarke=40cisco.com@dmarc.ietf.org<mailto:jclarke=40cisco.com@dmarc.ietf.org>>; Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>>
Cc: Netconf <netconf@ietf.org<mailto:netconf@ietf.org>>
Subject: RE: [netconf] Pullback tcp-client-server also?

Hi Michael,

> At first sight, this leaf can model the example below. Or do I miss something?

It can be modeled in draft-ietf-tcpm-yang-tcp because you have a list indexed per AF:

==
       list tcp-listeners {
         key "type address port";
         config false;

         description
           "A table containing information about a particular
            TCP listener.";

         leaf type {
           type inet:ip-version;
           description
             "The address type of address.  The value
              should be unspecified (0) if connection initiations
              to all local IP addresses are accepted.";
         }
==

The common model does not have that. The point was to have a reusable structure that would capture typical combinations, including when the structure is used in upper layers (service and network models).

Cheers,
Med

De : Scharf, Michael <Michael.Scharf@hs-esslingen.de<mailto:Michael.Scharf@hs-esslingen.de>>
Envoyé : vendredi 22 mars 2024 03:10
À : Joe Clarke (jclarke) <jclarke=40cisco.com@dmarc.ietf.org<mailto:jclarke=40cisco.com@dmarc.ietf.org>>; BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>; Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>>
Cc : Netconf <netconf@ietf.org<mailto:netconf@ietf.org>>
Objet : RE: [netconf] Pullback tcp-client-server also?

Hi all,

Sorry for chiming in late. This week I am very busy in my day job.

I still try to fully understand the problem while catching up. I apologize if I miss something.

To start with, I’d like to highlight that at first sight draft-ietf-tcpm-yang-tcp has to solve a similar problem.

Well, draft-ietf-netconf-tcp-client-server is more about the application view, whereas draft-ietf-tcpm-yang-tcp is about the stack-internal view. But they are related, and draft-ietf-tcpm-yang-tcp waits in the RFC editor queue…

In draft-ietf-tcpm-yang-tcp, the solution for a TCP listener (i.e., server) is:

     leaf address {
        type union {
          type inet:ip-address;
          type string {
            length 0;
          }
        }
        description
          "The local IP address for this TCP connection.

           The value of this node can be represented in three
           possible ways, depending on the characteristics of the
           listening application:

           1. For an application willing to accept both IPv4 and
              IPv6 datagrams, the value of this node must be
              ''h (a zero-length octet-string), with the value
              of the corresponding 'type' object being
              unspecified (0).

           2. For an application willing to accept only IPv4 or
              IPv6 datagrams, the value of this node must be
              '0.0.0.0' or '::' respectively, with
              'type' representing the appropriate address type.

           3. For an application which is listening for data
              destined only to a specific IP address, the value
              of this node is the specific local address, with
              'type' representing the appropriate address type.";
      }

This solution also supports dual-stack. As far as I recall, there was some discussion on how to model dual-stack, and this is what we ended up with.

At first sight, this leaf can model the example below. Or do I miss something?

Thanks

Michael

From: netconf <netconf-bounces@ietf.org<mailto:netconf-bounces@ietf.org>> On Behalf Of Joe Clarke (jclarke)
Sent: Wednesday, March 20, 2024 3:34 AM
To: mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>; Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>>
Cc: Netconf <netconf@ietf.org<mailto:netconf@ietf.org>>
Subject: Re: [netconf] Pullback tcp-client-server also?

As I thought about this more and consider Med’s DHC example, I kept coming back to how services are defined in a UNIX /etc/services file.  In Med’s example, DHCPv4 and DHCPv6 each have different services for client and server.  If I were implementing the “tcp-server-grouping” for a given service on a host, a leaf-list would be sufficient (as I’d have two different daemons or at least two different config blocks for v4 and v6).

However, Med is making the point that if this was to be implemented at a controller or higher abstraction level he wants to offer a “DHC” service as a single entity.  In this case, he’d like to have all DHC-capabilities under one service config (albeit that is more of an example for UDP server).

Concretely, I think he is proposing something like the attached snippet (Med, correct me if I’m wrong).  In this case, if I had an SSH server as an example that used different ports for different address families I would have (in XML):

<tcp-server xmlns="urn:ietf:params:xml:ns:yang:ietf-tcp-server">
  <local-bind>
    <local-address>0.0.0.0</local-address>
    <local-port>22</local-port>
    <keepalives>
      <idle-time>7200</idle-time>
      <max-probes>9</max-probes>
      <probe-interval>75</probe-interval>
    </keepalives>
  </local-bind>
  <local-bind>
    <local-address>::</local-address>
    <local-port>22022</local-port>
    <keepalives>
      <idle-time>7200</idle-time>
      <max-probes>9</max-probes>
      <probe-interval>75</probe-interval>
    </keepalives>
  </local-bind>
</tcp-server>

Yes, this adds complexity in order to get more flexibility, but you can still do the same ports for a given server such as:

<tcp-server xmlns="urn:ietf:params:xml:ns:yang:ietf-tcp-server">
  <local-bind>
    <local-address>0.0.0.0</local-address>
    <local-port>22</local-port>
    <keepalives>
      <idle-time>7200</idle-time>
      <max-probes>9</max-probes>
      <probe-interval>75</probe-interval>
    </keepalives>
  </local-bind>
  <local-bind>
    <local-address>::</local-address>
    <local-port>22</local-port>
    <keepalives>
      <idle-time>7200</idle-time>
      <max-probes>9</max-probes>
      <probe-interval>75</probe-interval>
    </keepalives>
  </local-bind>
</tcp-server>

  Joe

From: netconf <netconf-bounces@ietf.org<mailto:netconf-bounces@ietf.org>> on behalf of mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com><mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>
Date: Tuesday, March 19, 2024 at 21:31
To: Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>>
Cc: Netconf <netconf@ietf.org<mailto:netconf@ietf.org>>
Subject: Re: [netconf] Pullback tcp-client-server also?
Re,

Yes.

Cheers,
Med

De : Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>>
Envoyé : mercredi 20 mars 2024 11:27
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>
Cc : Kent Watsen <kent+ietf@watsen.net<mailto:kent+ietf@watsen.net>>; Netconf <netconf@ietf.org<mailto:netconf@ietf.org>>
Objet : Re: [netconf] Pullback tcp-client-server also?

Hi Med,

On Mar 20, 2024, at 11:04 AM, mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> wrote:

Re-,

As Joe rightfully mentioned, running different instances is likely to happen at the device level. For that case, the leaf-list approach is just fine.

Now, when the model is reused in upper layers (network or service models), that would not be sufficient. Think about a DHC service model which hides the internal of the service (whether this is dhcp or dhcpv6) but simply needs to expose where the dhc service is enabled: distinct ports are required for that case.

[mj] So a list of local-address and local-port?

Cheers.

Cheers,
Med

De : Kent Watsen <kent+ietf@watsen.net<mailto:kent+ietf@watsen.net>>
Envoyé : mercredi 20 mars 2024 10:48
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>
Cc : Joe Clarke (jclarke) <jclarke@cisco.com<mailto:jclarke@cisco.com>>; Rob Wilton (rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>>; netconf@ietf.org<mailto:netconf@ietf.org>
Objet : Re: [netconf] Pullback tcp-client-server also?

Hi Med,

Do you mean a list of “local-address + local-port” tuples?

Can you post a concrete proposal?

K.

On Mar 20, 2024, at 10:36 AM, mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> wrote:

Re-,

This would address the first cases I mentioned, but not the third one.

At least some narrative text is needed to explain the intended use of distinct port per AF. A cleaner approach would to model this is as a list keyed per AF.

Cheers,
Med

De : Kent Watsen <kent+ietf@watsen.net<mailto:kent+ietf@watsen.net>>
Envoyé : mercredi 20 mars 2024 10:29
À : Joe Clarke (jclarke) <jclarke@cisco.com<mailto:jclarke@cisco.com>>
Cc : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>; Rob Wilton (rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>>; netconf@ietf.org<mailto:netconf@ietf.org>
Objet : Re: [netconf] Pullback tcp-client-server also?

Thanks Med and Joe.  I had a sidebar with Rob and Mahesh, and we’re going to do this update in Auth48.

Let us (the WG) agree on the exact change.
  1) change ‘leaf’ to ‘leaf-list’
  2) tweak the ‘description’ to say that it’s a list

Anything else?  Do we need to disallow shadows?  (e.g., two wildcards)

K.

On Mar 20, 2024, at 9:02 AM, Joe Clarke (jclarke) <jclarke@cisco.com<mailto:jclarke@cisco.com>> wrote:

I agree with Med.  Your description is an either/or, but one server might do something like:

tcp46      0      0 *.9100                 *.*                    LISTEN <== Listen on all v4 and v6 addresses

Or:

tcp4       0      0 127.0.0.1.25           *.*                    LISTEN <==Listen on just v4 on an explicit address

Or:

tcp6       0      0 ::1.25   *.*                              LISTEN <== Listen on just v6 on an explicit address

In the first case, I’d think you’d at least need a leaf-list to hold both 0.0.0.0 and ::.  In the second two cases, you’d want this service to have a leaf list for 127.0.0.1 and ::1.

Joe

From: netconf <netconf-bounces@ietf.org<mailto:netconf-bounces@ietf.org>> on behalf ofmohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com><mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>
Date: Tuesday, March 19, 2024 at 18:23
To: Kent Watsen <kent+ietf@watsen.net<mailto:kent+ietf@watsen.net>>, Rob Wilton (rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>>
Cc: netconf@ietf.org<mailto:netconf@ietf.org> <netconf@ietf.org<mailto:netconf@ietf.org>>
Subject: Re: [netconf] Pullback tcp-client-server also?
Hi Kent, all,

When I initially raised the issue for the UDP grouping, I had in mind any, IPv4/IPv6 explicit address bindings, and eventually listening on distinct port numbers per AF. Given this is a reusable model, these cases should be all covered.

Cheers,
Med

De : netconf <netconf-bounces@ietf.org<mailto:netconf-bounces@ietf.org>> De la part deKent Watsen
Envoyé : mercredi 20 mars 2024 06:54
À : Rob Wilton <rwilton@cisco.com<mailto:rwilton@cisco.com>>
Cc : netconf@ietf.org<mailto:netconf@ietf.org>
Objet : [netconf] Pullback tcp-client-server also?

Rob, Netconf,

Regarding support for “dual-stack”, do we need to convert from a “leaf” to a “leaf-list”?

Please note that the existing text says that a wildcard card may be used to bind to all addresses:

leaf local-address {

      type inet:ip-address;

      mandatory true;

      description

        "The local IP address to listen on for incoming

         TCP client connections.  INADDR_ANY (0.0.0.0) or

         INADDR6_ANY (0:0:0:0:0:0:0:0 a.k.a. ::) MUST be

         used when the server is to listen on all IPv4 or

         IPv6 address.";

    }

Good enough?

Kent

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.
_______________________________________________
netconf mailing list
netconf@ietf.org<mailto:netconf@ietf.org>
https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.
_______________________________________________
netconf mailing list
netconf@ietf.org<mailto:netconf@ietf.org>
https://www.ietf.org/mailman/listinfo/netconf
_______________________________________________
netconf mailing list
netconf@ietf.org<mailto:netconf@ietf.org>
https://www.ietf.org/mailman/listinfo/netconf

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.