This is a review of the YANG module in draft-ietf-intarea-arp-yang-model-00
    
1) The title of this document is “A YANG Data Model for ARP”, which implies that this is the complete model for ARP. However, the scope of the document is to cover some extensions to the existing basic ARP in RFC 8444. Would it be better and less misleading to include “extensions” or similar wording in the title?
   
2) The relation with RFC 8344 can be better clarified.
How is the ARP feature in RFC 8444 related to this model? Can each of the two be used independently? How to use them together? Any conflicts? It would be good to have clear descriptions.
    
3) This model introduces a top-level container “arp” with one leaf. In IETF all standard models are carefully organized, and I am not sure that “arp”, as one of many protocols, is justified to take this top container. There are also special requirements for a top container. Why not fit “arp” into an existing structure, such as routing protocols?
    
4) This model does not have default values for many leaves, such as expiry-time and dynamic-learning. One purpose of standard modeling is to promote consistent behaviors. It would not be a convention and a good idea to have a statement like the following in the document:
“The default behaviour is device specific, and a
          deviation could be used to specify a device specific
          default."
    
5) In the container gratuitous-arp, there is a leaf named “enable”. Should it be “enabled” to be consistent with the other names used in the document like “disabled”, and the conventions used in other IETF models?

6) The leafs in statistics use type yang:counter32. As most IETF modules have moved to yang:counter64, has the 64 bit counter type been considered?

7) In the section of Security Considerations, the XPath /ietf-arp/dynamic-learning should be /arp/dynamic-learning, or /ietf-arp:arp/dynamic-learning. It would also be good to provide contexts for other XPaths, as they are relative paths without roots.

8) For data instance examples, Sec 3.12 in RFC 9907 requires that “Example modules MUST be validated”. It may not be a good idea to put a statement like the following one in the document.
        <!-- ipv4 address configuration parameters omitted →
       If the example does not need such parameters, they can be removed, but the example should contain a complete set of valid data. It would also be useful to include notes on why some of these parameters are included or not included.

Thanks,
- Xufeng