Re: [netmod] New Version Notification for draft-ding-netmod-arp-yang-model-00.txt

Alex Campbell <> Thu, 26 October 2017 22:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FCBE13F623; Thu, 26 Oct 2017 15:30:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9TdBPmxXs0uD; Thu, 26 Oct 2017 15:30:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C7B0113F61D; Thu, 26 Oct 2017 15:30:01 -0700 (PDT)
From: Alex Campbell <>
To: "dingxiaojian (A)" <>, "" <>
CC: "" <>
Thread-Topic: New Version Notification for draft-ding-netmod-arp-yang-model-00.txt
Thread-Index: AdNOPIiM+GAErL7MSeeuMv3UOyh70wAauoJU
Date: Thu, 26 Oct 2017 22:29:59 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-NZ, en-US
Content-Language: en-NZ
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [netmod] New Version Notification for draft-ding-netmod-arp-yang-model-00.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Oct 2017 22:30:05 -0000

Hi Xiaojian,

* The published module ietf-ip (RFC 7277) overlaps the data being provided in this module.
  Especially your /arp/arp-tables and /arp/arp-static-tables seem to correspond to /interfaces-state/interface/ipv4/neighbor and /interfaces/interface/ipv4/neighbor from ietf-ip.
  I think we should avoid duplication of data where possible; can you refactor this module to augment what is already there?

* Data relating to a specific interface should be inside /interfaces/interface (and -state) (ietf-interfaces, RFC 7223) where it is possible and relevant.
  I don't see any reason to have a completely separate list with a leafref as a key, when you could use 'augment' to have the data as part of the interface itself.

* ARP as a feature is not dependent on VRFs, but implementing this module requires the server to also implement ietf-network-instances.
  If the ARP-related data was under /interfaces(-state) then this draft wouldn't need to rely on ietf-network-instances.
  The network-instances draft already takes care of making sure each VRF has a separate list of interfaces.

From: netmod <> on behalf of dingxiaojian (A) <>
Sent: Thursday, 26 October 2017 10:27 p.m.
Subject: Re: [netmod] New Version Notification for draft-ding-netmod-arp-yang-model-00.txt

Hi all,

The ARP YANG module defined in this document has common properties that need to be configured.
It provides freedom for service providers to adapt this data model to different product implementations.

Please have a look and provide comments on the list.


A new version of I-D, draft-ding-netmod-arp-yang-model-00.txt
has been successfully submitted by Xiaojian Ding and posted to the IETF repository.

Name:           draft-ding-netmod-arp-yang-model
Revision:       00
Title:          YANG Data Model for ARP
Document date:  2017-10-26
Group:          Individual Submission
Pages:          16

   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

netmod mailing list