Hi Alex,

Thank you for your review of the draft and thoughtful comments, sincerely 
appreciated.
Sorry for the delay, please find my answers and notes in-line tagged DXJ>>.

Regards,
Xiaojian

-----邮件原件-----
发件人: Alex Campbell [mailto:alex.campb...@aviatnet.com] 
发送时间: 2017年10月27日 6:30
收件人: dingxiaojian (A) <dingxiaoji...@huawei.com>; i-d-annou...@ietf.org
抄送: netmod@ietf.org
主题: Re: New Version Notification for draft-ding-netmod-arp-yang-model-00.txt

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?

DXJ>>  Thank you for remind us  of  RFC 7277. 
For / interfaces / interface / ipv4 / neighbor, it does describe entries of 
mappings from IPv4 addresses to link-layer addresses, which is similar to / arp 
/ arp-static-tables in our draft. We will take your suggestion. 
For / interfaces-state / interface / ipv4 /neighbor, the list describes the ARP 
Cache. That is, we can only obtain ARP entries for an interface. However, in 
our / arp / arp-tables, we can not only obtain ARP entries for an interface, 
but also obtain ARP entries for a VPN (use vrf-name as the key).

* 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.

  DXJ>> Good point. We take your suggestion. 'augment' can be used to refactor 
the module of possible / interfaces / interface in RFC 7223.

* 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.

  DXJ>> Good point. As discussed in the first part, vrf related entry is 
deleted in / arp / arp-static-tables.

Alex
________________________________________
From: netmod <netmod-boun...@ietf.org> on behalf of dingxiaojian (A) 
<dingxiaoji...@huawei.com>
Sent: Thursday, 26 October 2017 10:27 p.m.
To: i-d-annou...@ietf.org
Cc: netmod@ietf.org
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.
Thanks,

Xiaojian


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
URL:            
https://www.ietf.org/internet-drafts/draft-ding-netmod-arp-yang-model-00.txt
Status:         
https://datatracker.ietf.org/doc/draft-ding-netmod-arp-yang-model/
Htmlized:       https://tools.ietf.org/html/draft-ding-netmod-arp-yang-model-00
Htmlized:       
https://datatracker.ietf.org/doc/html/draft-ding-netmod-arp-yang-model-00


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 tools.ietf.org.

The IETF Secretariat

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to