Re: [core] The CORE WG has placed draft-veillette-core-yang-library in state "Call For Adoption By WG Issued"

Michel Veillette <Michel.Veillette@trilliant.com> Tue, 23 July 2019 20:22 UTC

Return-Path: <Michel.Veillette@trilliant.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0F71209B4 for <core@ietfa.amsl.com>; Tue, 23 Jul 2019 13:22:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.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 rBIUdW6Ilugs for <core@ietfa.amsl.com>; Tue, 23 Jul 2019 13:22:06 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-eopbgr790123.outbound.protection.outlook.com [40.107.79.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D701120983 for <core@ietf.org>; Tue, 23 Jul 2019 13:22:06 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kv13i9jgakytjrXfXw2tDQecKIwV92S41nFG9QIN8AqpRyHyFR3H/GLToI5tURYcg4soteNiCIrfzzp6x5aVgQqaPBTiogiLCY7yBo40imd1e+Rb4yqte4H15uuOP5fx4Sz9RiwyDnsh0TTAL11YKQlFxdiXPI+1FgZnkFa/dqHj7rJFSGFrf4o/GyxTAvST6n+Qz5JNXm1DOJP4jItBUydTLxOBgQ1p+uqeR9c8CFGHx4fb6/v3Emr9pqf8wPl3oOJZY/g20RZmGJIbedCHmR5qI+lOgpz8w6jfBaRKIAT8fgskXUyeE1OIa0atwL/wEpM0laMg13KjUzq5ispbzw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/kiyaZl2a8ZJ/sNri6R6BkKPAR9PxPAFefHfwWzjl8c=; b=IHMyqY7h6AdDlvvRmhUeDT73xsHCbL5Nu86oL08DR7axVlO4Tp/RdCfv6N24AByrYx08RuOhKSrmyJHP/xzU0ucE96z2n/6ivaD1Mg9+bKpSS/JOVyh5o5Pih/hH4R3vBdG6HCuGC9DJE62egqls+u+VUob0M1u3XhhR6FtDhAWtUz739zEJ5J5p0WwyUZLnGXtfQJ7ZwwlbLwWhrh8Tht4/h3fGdQj7Uf+bkuhfY9baCYn1mZ54gVjxuY5MEqBy/gVEot9ML6g73iK5wjy1HQwJRC2crzSf5HY/usNCBfdt73Ro62FGsbo8hRusqgUn1G/CJKatg59Jd1kiAdJGFA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=trilliant.com;dmarc=pass action=none header.from=trilliant.com;dkim=pass header.d=trilliant.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/kiyaZl2a8ZJ/sNri6R6BkKPAR9PxPAFefHfwWzjl8c=; b=nJH2AzB6hkPIaAyosQ/6eUL5bhyIWAmCDWQZMG5prOntezbwn86CR1Ab+CpnPyPircyDw3aV9oGM0uXQwl3qVAxOwLBuQkWVA3y2TV7fDXSTMvkZF+BTfZp0AETsOxhUtOCUAmPvCHr1b7k2hGa6vaxwiv7scrMOHARezXN4Arg=
Received: from BL0PR06MB5042.namprd06.prod.outlook.com (10.167.240.31) by BL0PR06MB4931.namprd06.prod.outlook.com (10.167.234.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.17; Tue, 23 Jul 2019 20:22:03 +0000
Received: from BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::1e6:493d:1ca9:ba82]) by BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::1e6:493d:1ca9:ba82%7]) with mapi id 15.20.2094.013; Tue, 23 Jul 2019 20:22:03 +0000
From: Michel Veillette <Michel.Veillette@trilliant.com>
To: Andy Bierman <andy@yumaworks.com>
CC: Core <core@ietf.org>, Carsten Bormann <cabo@tzi.org>, ivaylo petrov <ivaylo@ackl.io>
Thread-Topic: [core] The CORE WG has placed draft-veillette-core-yang-library in state "Call For Adoption By WG Issued"
Thread-Index: AQHVN/3dcAv7wXPl5UO8jjBweVNxDabHfiiAgARDusCAC6RwwIAABiEAgAESJQCAACDoAIAAE0dw
Date: Tue, 23 Jul 2019 20:22:01 +0000
Message-ID: <BL0PR06MB5042B72969017D58AE724EEC9AC70@BL0PR06MB5042.namprd06.prod.outlook.com>
References: <156285914934.12002.9400408827321248683.idtracker@ietfa.amsl.com> <CABCOCHSfqxMueiagm29zXNOJyAOS3A_-O0YonMPcRAr10d8Ykg@mail.gmail.com> <BL0PR06MB5042F6FBD47E8C3757D620C29ACF0@BL0PR06MB5042.namprd06.prod.outlook.com> <BL0PR06MB5042A438CE8CFD5F2B3796FC9AC70@BL0PR06MB5042.namprd06.prod.outlook.com> <CABCOCHRfgS5nXYNwASjPCAFJ9dtNQ5ayc+=O9EbzaaMp-EEuGw@mail.gmail.com> <BL0PR06MB50420C236A19D766E12337549AC70@BL0PR06MB5042.namprd06.prod.outlook.com> <CABCOCHQq3Q1w-GCG9v2GFwzr=iv58Qq+jeCi-3edDPBABUqxPw@mail.gmail.com>
In-Reply-To: <CABCOCHQq3Q1w-GCG9v2GFwzr=iv58Qq+jeCi-3edDPBABUqxPw@mail.gmail.com>
Accept-Language: fr-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliant.com;
x-originating-ip: [31.133.139.92]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: dc32e8a5-dda2-4ffa-42a0-08d70fab6cda
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BL0PR06MB4931;
x-ms-traffictypediagnostic: BL0PR06MB4931:
x-ms-exchange-purlcount: 7
x-microsoft-antispam-prvs: <BL0PR06MB49318F8B7EFC1A9E8A9F2BAB9AC70@BL0PR06MB4931.namprd06.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0107098B6C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(4636009)(366004)(376002)(346002)(136003)(39850400004)(396003)(189003)(199004)(186003)(54906003)(26005)(316002)(6916009)(6246003)(71200400001)(68736007)(5660300002)(53936002)(66066001)(66446008)(64756008)(33656002)(14444005)(7736002)(66476007)(81156014)(25786009)(256004)(71190400001)(8676002)(53946003)(2906002)(66556008)(99286004)(966005)(236005)(81166006)(4326008)(14454004)(446003)(55016002)(76116006)(486006)(86362001)(53376002)(54896002)(8936002)(606006)(9686003)(6306002)(790700001)(6436002)(6116002)(102836004)(66946007)(3846002)(11346002)(478600001)(476003)(53546011)(52536014)(74316002)(7696005)(6506007)(76176011)(229853002)(579004)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4931; H:BL0PR06MB5042.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 659ybWSYVDffsU+NgkAmPXN8skn7TggIf4mJX3jeqOSPOFR5f+AtkJFF21M+M2MEs39Be5uSK/2WYyL0jf4Hy7Y0r4MFlUiXGUTsAVjMPGbUAV14hocCgp81qMXD55WNIvo4Pj/0N2II3/+48jdgdjhzBtzrSmnYs+UHxGNTDRRUw6t9HR7QKJCgQGOZq7k+cCrfpmSTkvYIyc51o/45ft8u2buxGytovIVsRTpA3wppZOkPSI0H0MkoBQQIpiRBOu5Br/+uyRx4JIQliN/XNpUcjd03YZLky+dEcFrLhXy84M8g46tlqT98nfqs9MogysXT8IA3jsC78EOwxiF8XHP6srrdE1ITkAhZSilX+0IQCA73hRiVqOy6pr6TxOVOCMW2v0UNyTyIXrkBB12CKep5Gjp3wcUFtCcqjKAaSjU=
Content-Type: multipart/alternative; boundary="_000_BL0PR06MB5042B72969017D58AE724EEC9AC70BL0PR06MB5042namp_"
MIME-Version: 1.0
X-OriginatorOrg: Trilliant.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dc32e8a5-dda2-4ffa-42a0-08d70fab6cda
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2019 20:22:02.2519 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Michel.Veillette@trilliant.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4931
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/LRKfBzFsQRqPA6av6V5-2euETXc>
Subject: Re: [core] The CORE WG has placed draft-veillette-core-yang-library in state "Call For Adoption By WG Issued"
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jul 2019 20:22:20 -0000

Hi Andy

I understand that this data is transferred very infrequently. However, keeping the size under 1280 bytes has a significant advantage, it can be transferred using a single IPv6 datagram, without CoAP block for example.

ietf-constrained-yang-library also support an important scaling feature. Instead of using a content-id which is meaningful within the context of a single device, ietf-constrained-yang-library use a hash which allows caching of a YANG library for a group of devices. (e.g. thousands or millions od devices can share the same library)

For the current list of changes as listed in https://tools.ietf.org/html/draft-veillette-core-yang-library-05#section-3.2, which ones should we keep in a solution based on a deviation.

1- module-set 'name' and schema 'name' are implemented using an 8 bits unsigned integer
2- module 'name', submodule 'name' and datastore 'name' are implemented using a SID
3- 'feature' and 'deviation' are implemented using a SID
4- 'revision' fields are implemented using a 4 bytes binary string.
5- the mandatory requirement of the 'namespace' fields is removed

#5 seem to be a minimum
#2 an #3 can be optional if implemented as a union
#4 is a nice to have, 4 bytes instead of 10 bytes for each revision
#1 can also be optional if implemented as a union

Regards,
Michel

From: Andy Bierman <andy@yumaworks.com>
Sent: 23 juillet 2019 14:52
To: Michel Veillette <Michel.Veillette@trilliant.com>
Cc: Core <core@ietf.org>rg>; Carsten Bormann <cabo@tzi.org>rg>; ivaylo petrov <ivaylo@ackl.io>
Subject: Re: [core] The CORE WG has placed draft-veillette-core-yang-library in state "Call For Adoption By WG Issued"



On Tue, Jul 23, 2019 at 10:13 AM Michel Veillette <Michel.Veillette@trilliant.com<mailto:Michel.Veillette@trilliant.com>> wrote:
Hi Andy

To evaluate the need, or not,  of a compact version of ietf-yang-library, I have created a simple example containing:
- one datastore
- one schema
- one module set

The module set contains the following YANG modules:
- ietf-interfaces
- ietf-ip
- ietf-system
- iana-hardware
- my-upgrade-module
- ietf-yang-types
- ietf-inet-types

Following is this YANG library implemented using ‘ietf-yang-library’ and encoded in CBOR.
The resulting size is 642 bytes without any location URIs which are optional.

{
  2368 : {
    +8 : [
      {
        +21 : "set1",
        +10 : [
          {
            +4 : "ietf-interfaces",
            +6 : "2018-02-20",
            +5 : "urn:ietf:params:xml:ns:yang:ietf-interfaces"
          },
          {
            +4 : "ietf-ip",
            +6 : "2018-02-22",
            +5 : "urn:ietf:params:xml:ns:yang:ietf-ip"
          },
          {
            +4 : "ietf-system",
            +6 : "2014-08-06",
            +5 : "urn:ietf:params:xml:ns:yang:ietf-system",
            +2 : ["ntp", "timezone-name", "dns-udp-tcp-port"]
          },
          {
            +4 : "iana-hardware",
            +6 : "2018-03-13",
            +5 : "urn:ietf:params:xml:ns:yang:iana-hardware"
          },
          {
            +4 : "my-upgrade-module",
            +6 : "2019-07-23",
            +5 : "http://mydomain.com/yang/my-upgrade-module<https://can01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmydomain.com%2Fyang%2Fmy-upgrade-module&data=02%7C01%7C%7C74edf7c1edd04b5ca41f08d70f9ee921%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C636995047520210812&sdata=QuB6ynLZej%2BGyDvkxVM2KLs64JqZeKPa48OkYPPa8SM%3D&reserved=0>",
            +2 : ["ftp", "coap", "scheduled"]
          }
        ],
        +1 : [
          {
            +2 : "ietf-yang-types",
            +4 : "2018-02-20",
            +3 : "urn:ietf:params:xml:ns:yang:ietf-yang-types"
          },
          {
            +2 : "ietf-inet-types",
            +4 : "2013-07-15",
            +3 : "urn:ietf:params:xml:ns:yang:ietf-inet-types"
          }
        ]
      }
    ],
    +30 : [
      {
        +2 : "schema1",
        +1 : ["set1"]
      }
    ],
    +5 : [
      {
        +1 : "unified",
        +2 : ["schema1"]
      }
    ],
    +4 : "mySensorDataModel"
  }
}

The same YANG library implemented using ‘ietf-constrained-yang-library’ required 183 bytes.

{
  2368 : {
    +8 : [
      {
        +21 : 1,
        +10 : [
          {
            +4 : 1500,
            +6 : h'20180220'
          },
          {
            +4 : 1600,
            +6 : h'20180222'
          },
          {
            +4 : 1700,
            +6 : h'20140806',
            +2 : ["ntp", "timezone-name", "dns-udp-tcp-port"]
          },
          {
            +4 : 2200,
            +6 : h'20180313'
          },
          {
            +4 : 1005100,
            +6 : h'20190723',
            +2 : ["ftp", "coap", "scheduled"]
          }
        ],
        +1 : [
          {
            +2 : 1100,
            +4 : h'20180220'
          },
          {
            +2 : 1150,
            +4 : h'20130715'
          }
        ]
      }
    ],
    +30 : [
      {
        +2 : 1,
        +1 : [1]
      }
    ],
    +5 : [
      {
        +1 : "unified",
        +2 : [1]
      }
    ],
    +4 : h'9D373F629E20'
  }
}

The mandatory namespace field in the original ietf-yang-library, useless for CoREconf, is the main contributor of this increase in size. Assuming that a real device have at least 5 time more YANG modules, we can estimate that the non compact version of the YANG library will be around 3 to 4 kB, the compact version will be slightly less than 1kB.


So what is the size difference if just the XML namespace is removed?


Can we archive the same result with a deviation module instead of a complete module replacement?



Yes


   deviation /yanglib:yang-library/yanglib:module-set/yanglib:module/yanglib:namespace {
      deviate replace {
         mandatory false;
      }
   }

You could also replace the type-stmt for key leafs you want to change, but this seems like overkill.
This data will not change very often. The /yang-library/content-id leaf can be polled or yang-library-change
notification can be used. YoT devices will probably have modules hard-wired into firmware so
this data can be cached on the client (using content-id).


Regards
Michel

Andy


From: Andy Bierman <andy@yumaworks.com<mailto:andy@yumaworks.com>>
Sent: 22 juillet 2019 20:33
To: Michel Veillette <Michel.Veillette@trilliant.com<mailto:Michel.Veillette@trilliant.com>>
Cc: Carsten Bormann <cabo@tzi.org<mailto:cabo@tzi.org>>
Subject: Re: [core] The CORE WG has placed draft-veillette-core-yang-library in state "Call For Adoption By WG Issued"

Hi,

I don't think it is needed because the client is supposed to know the SID mappings outside of YANG library.
This library is likely to be very static on a YoT device. Maybe changing once per firmware upgrade.
It does not really need optimized retrieval.

I prefer to keep the models the same between NC/RC and CORECONF.
The YANG to CBOR solution should include ways to make the message encoding more efficient.
That way, the same application logic can use whatever protocol operations are needed, instead of special CORECONF models.


Andy


On Mon, Jul 22, 2019 at 5:23 PM Michel Veillette <Michel.Veillette@trilliant.com<mailto:Michel.Veillette@trilliant.com>> wrote:
Hi Andy

About “draft-veillette-core-yang-library”, should we postpone the working group adoption of this draft to get more time to work on a different solution?

I raising this topic because the current CoMI draft (https://tools.ietf.org/html/draft-ietf-core-comi-07#section-6<https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-core-comi-07%23section-6&data=02%7C01%7C%7C74edf7c1edd04b5ca41f08d70f9ee921%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C636995047520220808&sdata=0xFFD%2B1GA9ET9nvmYJYJBqHHTAPl5jYJqUHSXsPXjYE%3D&reserved=0>) have a mandatory reference to it. We either need to change the content of CoMI or commit to bring ietf-constrained-yang-library to life.

Regards,
Michel

From: Michel Veillette
Sent: 15 juillet 2019 10:37
To: Andy Bierman <andy@yumaworks.com<mailto:andy@yumaworks.com>>; IETF Secretariat <ietf-secretariat-reply@ietf.org<mailto:ietf-secretariat-reply@ietf.org>>
Cc: draft-veillette-core-yang-library@ietf.org<mailto:draft-veillette-core-yang-library@ietf.org>; core-chairs@ietf.org<mailto:core-chairs@ietf.org>; Core <core@ietf.org<mailto:core@ietf.org>>
Subject: RE: [core] The CORE WG has placed draft-veillette-core-yang-library in state "Call For Adoption By WG Issued"

Hi Andy

I effectively see some values in supporting the module names.
However, these names should be optional leaves and not mandatory keys.
Simply augmenting the existing “ietf-yang-library” will increase its size, which makes this solution even less friendly to constrained devices and networks.

Hope to see you in MTL to discuss these changes,
Michel

From: Andy Bierman <andy@yumaworks.com<mailto:andy@yumaworks.com>>
Sent: 12 juillet 2019 17:16
To: IETF Secretariat <ietf-secretariat-reply@ietf.org<mailto:ietf-secretariat-reply@ietf.org>>
Cc: draft-veillette-core-yang-library@ietf.org<mailto:draft-veillette-core-yang-library@ietf.org>; core-chairs@ietf.org<mailto:core-chairs@ietf.org>; Core <core@ietf.org<mailto:core@ietf.org>>
Subject: Re: [core] The CORE WG has placed draft-veillette-core-yang-library in state "Call For Adoption By WG Issued"



On Thu, Jul 11, 2019 at 8:32 AM IETF Secretariat <ietf-secretariat-reply@ietf.org<mailto:ietf-secretariat-reply@ietf.org>> wrote:

The CORE WG has placed draft-veillette-core-yang-library in state
Call For Adoption By WG Issued (entered by Carsten Bormann)

The document is available at
https://datatracker.ietf.org/doc/draft-veillette-core-yang-library/<https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-veillette-core-yang-library%2F&data=02%7C01%7C%7C74edf7c1edd04b5ca41f08d70f9ee921%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C636995047520220808&sdata=JESy70MJ7YNPxiOGeRIVN92lcqu8vk8v9wq16ifkqf8%3D&reserved=0>


I do not know if there is a clear problem statement presented and agreed upon by the CORE WG yet.
The YANG Library (RFC 8525) is used by a server to provide a client with details about the YANG modules
that are implemented in the server.

The draft proposed for adoption is a cut-and-paste-and-replace version of this RFC.
The strings used as list keys (e.g., /yang-library/module/name) are replaced by SID values.
Other key leafs such as /yang-library/schema/name are replaced by int8 leafs instead of strings.

IMO there are better solution approaches, considering that this data structure will be
relatively static, and there is a caching mechanism built into RFC 8525 to reduce
retrieval of the entire YANG library.

It does not seem realistic that a server would have only SIDs installed and no way to get the module names.
This is a short list, unlike the list of YANG data nodes. So it should be OK to simply augment the existing module
with SID values.  If the list key replacements are really needed, then a deviation module could be used by CORECONF
(e.g. deviate replace {type-stmt}) instead of a replacement module.

I agree it will be important for a CORECONF client to determine the YANG library details for each server.
This could be offline data or directly retrievable from the server. The solution need to be resolved by the WG.
I support the problem statement by not this solution.


Andy



Comment:
Till 2019-07-18

_______________________________________________
core mailing list
core@ietf.org<mailto:core@ietf.org>
https://www.ietf.org/mailman/listinfo/core<https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcore&data=02%7C01%7C%7C74edf7c1edd04b5ca41f08d70f9ee921%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C636995047520230800&sdata=TiSNn2E%2FQkZm2Tp359ieUosKEptM7SITfkOjFnqiN3k%3D&reserved=0>