Re: [dhcwg] Call for adoption for draft-cui-dhc-dhcpv6-yang-04

"Liubing (Leo)" <leo.liubing@huawei.com> Mon, 28 September 2015 10:31 UTC

Return-Path: <leo.liubing@huawei.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561EE1A00AE for <dhcwg@ietfa.amsl.com>; Mon, 28 Sep 2015 03:31:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 Pr9bNSTN8WlN for <dhcwg@ietfa.amsl.com>; Mon, 28 Sep 2015 03:31:33 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DD661A009E for <dhcwg@ietf.org>; Mon, 28 Sep 2015 03:31:32 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYC60294; Mon, 28 Sep 2015 10:31:30 +0000 (GMT)
Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 28 Sep 2015 11:31:28 +0100
Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.20]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0235.001; Mon, 28 Sep 2015 18:31:24 +0800
From: "Liubing (Leo)" <leo.liubing@huawei.com>
To: Tomek Mrugalski <tomasz.mrugalski@gmail.com>, dhcwg <dhcwg@ietf.org>
Thread-Topic: [dhcwg] Call for adoption for draft-cui-dhc-dhcpv6-yang-04
Thread-Index: AQHQ94+vTf4mPbmiu0ulmuGeESviIZ5Rqg+A
Date: Mon, 28 Sep 2015 10:31:24 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C22F77A7@nkgeml506-mbx.china.huawei.com>
References: <56054134.6020003@gmail.com>
In-Reply-To: <56054134.6020003@gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.117]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/rSHzozI9J0zE46YG5pmGftk1nTo>
Cc: "draft-cui-dhc-dhcpv6-yang@tools.ietf.org" <draft-cui-dhc-dhcpv6-yang@tools.ietf.org>
Subject: Re: [dhcwg] Call for adoption for draft-cui-dhc-dhcpv6-yang-04
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 28 Sep 2015 10:31:35 -0000

Hi, all

I think the DHCPv6 (and also DHCPv4) YANG model is necessary work, and DHC WG should be the most suitable place to work on it. So I support this adoption.

And we have some comments to the current draft:

General comments:
1. The Server, Relay, Client are defined as three containers in one DHCPv6 module in the draft. But considering the three roles are actually independent from each other, we thought maybe defining them as three separated YANG modules (still in one draft) is more proper. This might be more convenient to maintain and use them. 

Besides, do you also consider making address pool a separated module? Since the address pool could be considered as a common resource that might be utilized by functions other than DHCP.

(I think this comment also applies to the current DHCPv4 YANG model draft.)

2. (This is also a question to the WG) Do you consider this DHCPv6 YANG Model as a universal model focusing on the standard functions, or you consider it as a specific usage, e.g. HGW?
My personal opinion tends to agree with the former one.


Specific comments:
1. In Client model, the "client-interfaces" container seems redundant? I think the "list client-if" could be directly under the "client" container.
2. In Server model, Do you consider to support a feature that multiple DHCPv6 servers could be grouped together? This is an important feature in carrier networks.
3. There are lot of stings defined without assigned length.
4. There are some description still empty, need to be filled.


Best regards,
Bing

> -----Original Message-----
> From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek
> Mrugalski
> Sent: Friday, September 25, 2015 8:42 PM
> To: dhcwg
> Subject: [dhcwg] Call for adoption for draft-cui-dhc-dhcpv6-yang-04
> 
> Hi,
> Authors of draft-cui-dhc-dhcpv6-yang-04 requested adoption. This draft has
> been presented twice and received favourable comments. It defines a YANG
> data model for configuration and management of the DHCPv6 server, client
> and relay agent. This I-D is over 80 pages long, but most of the text is taken
> by formal YANG definition.
> 
> This mail initiates a call for adoption of draft-cui-dhc-dhcpv6-yang-04 as a
> WG item. If you would like the working group to work on this document,
> please say so. If you would like the WG to not adopt, please state your
> technical objections.
> 
> There are currently no IPR claimed against this draft.
> 
> Bernie and I will determine the consensus after Oct. 9th.
> 
> Bernie & Tomek
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg