Early Review of draft-ietf-intarea-arp-yang-model-00
review-ietf-intarea-arp-yang-model-00-yangdoctors-early-liu-2026-03-31-01

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