RE: FW: New Version Notification for draft-ding-rtgwg-arp-yang-model-00.txt

"dingxiaojian (A)" <> Tue, 23 January 2018 03:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ECAE3126C0F for <>; Mon, 22 Jan 2018 19:25:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VQ9WW0lXl199 for <>; Mon, 22 Jan 2018 19:25:56 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E117B1205D3 for <>; Mon, 22 Jan 2018 19:25:55 -0800 (PST)
Received: from (unknown []) by Forcepoint Email with ESMTP id AD69FC4FA6F23 for <>; Tue, 23 Jan 2018 03:25:52 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 23 Jan 2018 03:25:53 +0000
Received: from ([]) by ([]) with mapi id 14.03.0361.001; Tue, 23 Jan 2018 11:25:47 +0800
From: "dingxiaojian (A)" <>
To: Robert Wilton <>
CC: "" <>
Subject: RE: FW: New Version Notification for draft-ding-rtgwg-arp-yang-model-00.txt
Thread-Topic: FW: New Version Notification for draft-ding-rtgwg-arp-yang-model-00.txt
Thread-Index: AQHTi7juHPnwBrCyHE2tV1BquJrODKN0QuMwgAH0pICACqPTEA==
Date: Tue, 23 Jan 2018 03:25:47 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Jan 2018 03:25:58 -0000

Hi Robert,

Thank you for your review of the draft and thoughtful comments, sincerely appreciated.
Please find my answers and notes in-line tagged [DXJ].


-----Original Message-----
From: Robert Wilton [] 
Sent: Wednesday, January 17, 2018 12:54 AM
To: dingxiaojian (A) <>;
Subject: Re: FW: New Version Notification for draft-ding-rtgwg-arp-yang-model-00.txt

Hi Xiaojian,

Just some quick (mostly structural) comments from a cursory review of the tree structure:

1) I don't think that you need the arp-static-tables container at all, since "if:interfaces/if:interface/ipv4/neighbor" can be used to configure static ARP entries.

[DXJ]: Yes, the static arp configuration defined in "if:interfaces/if:interface/ipv4/neighbor" can be used to configure the static ARP entries under an interface. However, there may also have another scenario, which the static ARP entries are configured global and is not independent on the interface. In this case, we describe the static arp global configuration within the arp-static-tables container.

2) I would rename the "arp-statistics" container to "statistics", since it is already under the "arp" top level container.

[DXJ]: Good point. We will change it in the next version.

3) I would delete the "arp/arp-statistics/local-statistics" container. These statistics can just be specified directly under the interface.

[DXJ]: Sorry, it was a mistake. local-statistics was defined duplicated. We will delete the redundant part in the next version.

4) It looks like "augment
/if:interfaces/if:interface/ip:ipv4/ip:neighbor:" is empty and can be deleted?

[DXJ]: This question is relate to the first comment. "augment/if:interfaces/if:interface/ip:ipv4/ip:neighbor:" was refer to the local static configuration defined in RFC 7277. I think you are right, the empty augment will be deleted in the next version.

5) Not sure about the "vrf-name" augmentation to "/if:interfaces-state/if:interface/ip:ipv4/ip:neighbor", shouldn't the VRF binding be at the interface level rather than ARP entry level?

 [DXJ]: Good point. "vrf-name" entry will be deleted in the augmentation in the next version.

?6) Put the interface augmentations under an "arp" sub-container, then you can lose the "arp" prefix on the individual leaves.

[DXJ]: Good point. The problem you said in indeed exist. In order to solve this problem, we refer to the method used in draft-ietf-netmod-rfc8022bis-09. In this draft, the "ietf-ipv6-unicast-routing" module is first defined, and its submodule "ietf-ipv6-router-advertisements" is also defined to augment the "ietf-interfaces" [I-D.ietf-netmod-rfc7223bis] and "ietf-ip" [I-D.ietf-netmod-rfc7277bis] modules. Likewise, in this case, the interface augmentations can be defined as a submodule of ARP YANG module.

7) Perhaps make "arp-gratuitous" a container with presence with arp-gratuitous-interval underneath, probably renamed just to "interval".

[DXJ]: Good point. This makes the text more readable.

8) All the "config false" state variables should follow the NMDA architecture.  I.e. for this draft, I would suggest just augmenting them under the config tree, and depend on RFC 7223bis.  So all the ARP interface counters should probably go under /if:interfaces/if:interface:/arp:arp/arp:statistics

[DXJ]: Good point. The next version will follow the NMDA architecture.

9) This is just a stylistic preference, but I would reduce (or perhaps
avoid) groupings, I think that the YANG file is easier to read without them.

[DXJ]: Good point. This comment is similar to comment 7. We will revise it together.

10) In terms of naming the statistics, I would suggest aligning them to the statistics style in RFC 7223 if possible.

[DXJ]: Good point. We will align statistics names to the statistics style in RFC 7223 in the next version.

Anyway, hopefully these comments are useful.

On 15/01/2018 03:04, dingxiaojian (A) wrote:
> Hi rtgwg,
> After IETF 100, we have received some valuable suggestions for improving the ARP YANG module. According to the suggestion of WG chair, we put the work on RTGWG and submit a new draft for ARP YANG module.
> In the new version, we have also clarified some functions (e.g., arp-static-table configuration) are different from the previously defined ones (e.g., arp static tables defined in RFC 7277).
> Please have a look and provide comments on the list.
> Best Regards,
> Xiaojian
> -----Original Message-----
> From: []
> Sent: Friday, January 12, 2018 11:20 PM
> To: Zhengfeng (Habby) <>;; dingxiaojian (A) 
> <>;; dingxiaojian (A) 
> <>;
> Subject: New Version Notification for 
> draft-ding-rtgwg-arp-yang-model-00.txt
> A new version of I-D, draft-ding-rtgwg-arp-yang-model-00.txt
> has been successfully submitted by Xiaojian Ding and posted to the IETF repository.
> Name:		draft-ding-rtgwg-arp-yang-model
> Revision:	00
> Title:		YANG Data Model for ARP
> Document date:	2018-01-11
> Group:		Individual Submission
> Pages:		16
> URL:  
> Status:
> Htmlized:
> Htmlized:
> Abstract:
>     This document defines a YANG data model to describe Address
>     Resolution Protocol (ARP) configurations.  It is intended this model
>     be used by service providers who manipulate devices from different
>     vendors in a standard way.
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at
> The IETF Secretariat
> _______________________________________________
> rtgwg mailing list
> .