Re: [dhcwg] >> YANG Data Model for DHCPv6 Configuration-16

ianfarrer@gmx.com Thu, 21 January 2021 16:29 UTC

Return-Path: <ianfarrer@gmx.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830713A1299 for <dhcwg@ietfa.amsl.com>; Thu, 21 Jan 2021 08:29:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level:
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, 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=gmx.net
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 MJiDtdhvMHzL for <dhcwg@ietfa.amsl.com>; Thu, 21 Jan 2021 08:29:29 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E60283A1298 for <dhcwg@ietf.org>; Thu, 21 Jan 2021 08:29:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1611246558; bh=8QuGscRdyF5EbMBL78H7KKw/gwBDQLz+8VMuFlc2C4s=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=VkxfkkZDC1nhh3EIyy5/6uO7vFVQhcDNyjyxIJCfhM7xmhiPGYrbprFWkgANG8atW tjNfhj4c3gx0TGol3JoXvPTJy12x0yr69PDXMuUxe7TacLoMycvV9bUpUbxGFk8KEx ylCbrVEaHo/ky7QdHkIeRQomckky1BanJSt5hO7I=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from mbp-big-sur.fritz.box ([78.35.205.160]) by mail.gmx.net (mrgmx005 [212.227.17.184]) with ESMTPSA (Nemesis) id 1MDQiS-1lD2hX3pEE-00AZPD; Thu, 21 Jan 2021 17:29:17 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\))
From: ianfarrer@gmx.com
In-Reply-To: <60082100.9070802@btconnect.com>
Date: Thu, 21 Jan 2021 17:29:16 +0100
Cc: dhcwg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <DC5EA7AA-6342-4C9C-B055-672CC9F1C938@gmx.com>
References: <A4876940-038E-43B7-8FDF-7C6B8DCA546E@gmx.com> <5449AD17-B1CE-4612-A5A9-D3A0115104EE@gmx.com> <DB7PR07MB55462FF61FE03534A710D851A2A30@DB7PR07MB5546.eurprd07.prod.outlook.com> <60082100.9070802@btconnect.com>
To: t petch <ietfa@btconnect.com>
X-Mailer: Apple Mail (2.3654.40.0.2.32)
X-Provags-ID: V03:K1:oQq2kpe3LFYm7KnQovUuJA2uHSWKVSTsBTVYRibid/lsLPnYjJL kzqWHIKHGcuBK1N/TmupXSJ9yLwZ1YfY3OcnuQ4TMIMgzb5hTKoGKGN8M7Z6MKw9GACf5P+ Ms/wZ5JCRRsMAeyH5/jF2trMaMtxO1UrI1B0Tupp43/6eSFYaI3OuxWx65mpn4B4uX93v8m F9ibZnr5Q9TF9I34Cugtw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:M4YwbWYi69c=:WLtt+8wqAG4St9BmejH9aj apoWEFdXqman9eggF/509rgUdApCfRYR/AFoje92VDL/jnevcCRXZb2dXOSrNS8gd1I4L55CP Sit0Jd4by1vNi+Ol5hyWdsBLqZnEPAw3AkbgwBVz4gD5hUAaFFl340iFpQnJkSpLIWquxP9yF OSj3IUpTJrYttateXdsQhZF4pV2wvZisp9fa0CjnloGeI9ovedyM0Pv51A8/QF3VpamQR97p8 GI+OYsu2CHW5MIrWT8PyVjnxQeMHuUbTvzjlriMBJ/smWJuH77GmBqn2BP3dECjNi450qTCth hgWU4vhqeEorfrbg7UcIu3ovr0lAXDt/zkEcrmBBDYxYqZvPF0nFlP1IGWpkdnM04GuWYGqub CIKIwA89Ei68/J75y0y3vGNcOED8H3Y4cfPf4lSmuWAEAiK5dd+GMYuCgrFXpX/vHWZix0bbu 6rexcPCK6hyFWLReq8VF0MXEo4Qz+I3FhQZHF5FKP+dHLNxBVlWakcu8OvubznOBb3azCGhfd CD46lL8Ut24myJD5IOaSVO2jloUm86coVziEzV4tFgKHSRfm3vEYhsOq+OYYyLX2ntAJGkqQN UkSgsFHyZGCNWQ0GrItA8KInhgdjFkEM8sh6sPY6QG0zB7te/88qJEHGJchozjo/dCcGEt8AO N9qDihbXVF07Z0AaTGRtBPQFsYR4eU7IrDfD7eitieBqnE/YGArNlNhwCyo1XWEp8ohcvTiDS +/+0bfB0uP52F99L3+ZLfKveBlonf1EWDYH87PYYPAV0kjQeKKUBDZzBPGcmuaNDDq+a5Dvg1 a5Jz8Iw+HPffKdKbEgDUzS1NKomFfzD8rhknQD0HRcVMm8fc3nHgV6nh7ylkImsB7/3HEehlm IA56Ipa/GiXKV4sMuLVA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/8XifkQswvDNvkSsh44J93JuO23o>
Subject: Re: [dhcwg] >> YANG Data Model for DHCPv6 Configuration-16
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jan 2021 16:29:32 -0000

Hi Tom,

Thanks for starting the discussion on the netmod list. I’ll continue the discussion there for now and update this thread with the outcome.

Ian

> On 20. Jan 2021, at 13:24, t petch <ietfa@btconnect.com> wrote:
> 
> On 19/01/2021 11:25, tom petch wrote:
>> ________________________________________
>> From: dhcwg <dhcwg-bounces@ietf.org> on behalf of ianfarrer@gmx.com <ianfarrer@gmx.com>
>> Sent: 19 January 2021 07:37
>> 
>> Resending as the original message didn’t appear on the m/l.
>> 
>> 
>> Hi Tom,
>> 
>> Thanks for your comments. Please see inline below.
>> 
>> Ian
>> 
>> On 14. Jan 2021, at 13:40, t petch <ietfa@btconnect.com<mailto:ietfa@btconnect.com>> wrote:
>> 
>> 
>> Ian
>> 
>> I do not understand this I-D; I have tracked it for a number of years and my understanding of it is diminishing.
>> 
>> Currently, it is seven YANG modules: why?
>> 
>> [if - The separation into client/server/relay, and DHCP options has been in the draft since -05 and the changes were presented and discussed at IETF101 - I’ve described the reasoning for this split in the next answer. Beyond that, the common module was added to avoid (well reduce as you point out below) duplication.
>> 
>> The separation of the option modules came at a later stage based on import dependencies of a single options module. When the options module imports the client/server/relay modules so it can augment the relevant module based on identity, an implementation also needs to import these modules and will declare them in it’s capabilities as available even though it doesn’t implement them. Dividing the options modules avoids the need for deviations.
>> 
>> Even though there are 7 modules defined here, the likely hood is that an element implementation would require 3 modules to be implemented (e.g. client, common and client options).]
>> 
>> 
>> Other WG have models with multiple roles and many options and have a single YANG module, using the features of YANG to tailor the module to different configurations.
>> 
>> [if - It’s not really tailoring the module to different configurations, they are for the most part separate functional elements in the network with any device only implementing one of the client, relay or server functions.
>> 
>> However, even in the case that a device is both a server and a client (e.g. a home gateway with a client on the WAN and a server on the LAN), the likelihood is that these will be done using different software implementations, so having separate modules for server and client offers implementation flexibility.
>> 
>> In the case of a monolithic module with the relevant client/relay/server functionality enabled by features, the module would do nothing unless one or more of the features was enabled, and Is unlikely that you’d ever enable more than one. Is this approach used by other WGs? Could you point me to some some examples as I've only seen features been used as relatively small optional extensions used when the bulk of the nodes are common?]
> 
> Ian
> 
> Almost all the YANG models I know of are single module.  For example,
> draft-ietf-ospf-yang supports two versions modelled as identity and 28 options modelled as features.
> 
> draft-ietf-tcpm-yang supports client and server as containers with if-feature and has other features as well
> 
> draft-ietf-pim-igmp-mld-yang supports five versions of two protocol using identity
> 
> draft-pce-pcep-yang offers the roles of pcc or pce or both using typedef.
> 
> And so on and so on.  if-feature, when and suchlike provide the necessary customisation.
> 
> I think that your problems with options are because the identity are defined in the wrong place.  The base, the common module (or part of the one and only module) should define what is common, what everyone needs; if there are three roles and a dozen options, than that is where they need to be defined.
> 
> Then there can be an object which is configured with the roles of a particular box, client or server or relay, or if required, a combination of the there - simpler if that is out of scope as you suggest.
> 
> My startng point would be a dhc container with a role and then containers for client, relay, server, added by augment and controlled by when pointing at the rold.
> 
> I will post something to the netmod WG list - there are lots of people there with greater exposure than mine who can give better guidance than I.
> 
> Tom Petch
> 
>> Here you have modelled the options as YANG grouping. The intent of a grouping is to provide a block of statements that can be reused so avoiding duplication with the attendant problems.  Here you have the same grouping in triplicate in three different YANG modules which seems to me to be the antithesis of a grouping.
>> 
>> [If - We could move the option definitions for "status-code-option-group” (client, server, relay) and “rapid-commit-option-group, vendor-specific-information-option-group; reconfigure-accept-option-group” (client, server) into the common module to resolve the duplication. I didn’t do this previously as the intention was to keep options definitions in the options modules for consistency, but it  would be simple to change. ]
>> 
>> 
>> Likewise I find the specification of server v client v relay unusual.
>> 
>> [If - A similar approach for separated client/server modules is also used in RFC8676, where the client and server have discrete function, as with DHCP.]
>> 
>> 
>> I wonder if it is worth consulting a YANG doctor, NOT to show them the YANG and invite comments, rather outline in an abstract way what it is you want to model and see what they suggest; that might well be a single YANG module.
>> 
>> [if - Yes, I’d be happy to. Is there someone that you have in mind (I’ve not had much luck with getting YANG doctor input outside of the formal review process in the past)?. I’m not opposed to changing the way that the modules are structured on principal, I do however, think that the separation by functional element is logical and simpler for implementers, and I would like to know what the benefits of a single module (or other structure) might be.]
>> 
>> 
>> I do have quite a number of detailed comments but do not think them worth making until the I-D seems to me more stable.
>> 
>> [if - It’d be great if you could supply them as well so I can start going though them and fixing what’s currently fixable in parallel to the discussion above.]
>> 
>> 
>> Tom Petch
>> 
>> On 07/01/2021 16:10, ianfarrer@gmx.com<mailto:ianfarrer@gmx.com> wrote:
>> Hi Tom,
>> 
>> Many thanks for the comments. I’ve just uploaded -16 which addresses them.
>> 
>> One other change is that the wrong file was being included for the relay module. This is also resolved in this version.
>> 
>> Cheers,
>> Ian
>> 
>> On 6. Jan 2021, at 13:50, tom petch <daedulus@btconnect.com<mailto:daedulus@btconnect.com>> wrote:
>> 
>> Ian
>> 
>> Looking at -15, it looks a bit screwy.
>> 
>> There appear to be six YANG modules which means there must be six prefix registered but IANA Considerations registers the same prefix six times:-(
>> 
>> The lines have been chopped at 76? characters so that one character appears on a line by itself in several places towards the end in the Appendices
>> 
>> There is a convention which I find like to use
>> RFC XXXX <name of document>
>> where a reference is needed to the I-D when it becomes an RFC.  A note to the RFC Editor to replace XXXX with the number assigned is nice to have but I think that the RFC Editor is by now well acquainted with YANG modules. RFC YYYY etc can then be used for other I-D, which there often are although not I think in this I-D.
>> 
>> Tom Petch
>> 
>> 
>> On 01/01/1970 00:00,  wrote:
>> Hi,
>> 
>> I’ve just updated the draft using the correct file headers so the IETF’s automated YANG checking tools recognise the modules. This got lost a few versions back when we moved to v3 formats.
>> 
>> This also flagged up quite a few gremlins in the modules (mainly leaf orders and line length problems), so these have been fixed as well.
>> 
>> Thanks,
>> Ian
>> 
>> On 10. Dec 2020, at 14:38, internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> wrote:
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Dynamic Host Configuration WG of the IETF.
>> 
>>        Title           : YANG Data Model for DHCPv6 Configuration
>>        Authors         : Yong Cui
>>                          Linhui Sun
>>                          Ian Farrer
>>                          Sladjana Zechlin
>>                          Zihao He
>>                          Michal Nowikowski
>> Filename        : draft-ietf-dhc-dhcpv6-yang-13.txt
>> Pages           : 97
>> Date            : 2020-12-10
>> 
>> Abstract:
>>   This document describes YANG data modules for the configuration and
>>   management of DHCPv6 servers, relays, and clients.
>> 
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-yang/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-yang-13
>> https://datatracker.ietf.org/doc/html/draft-ietf-dhc-dhcpv6-yang-13
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-yang-13
>> 
>> 
>> .
>> 
>> 
>>