A YANG Data Model for Interface Management
draft-ietf-netmod-interfaces-cfg-16

I have no objection to the publication, but I have a few small points
you may want to consider before passing this document to the RFC Editor.

===

Section 2

   o  The data model should include read-only counters in order to
      gather statistics for octets, packets and errors, sent and
      received.

Very pedantically, out-errors is not a count of errors sent. It is a
count of what could not be sent because of some error.

---

Section 4 Paragraphs 1, 2, 4, and 5

When I see "typically" or "in most cases" or "generally" (or "usually"
or "normally") I look for the explanation of the variation. I don't find
one in these cases. Is that significant?

---

Section 4

There are two scalars in IF-MIB (ifNumber and ifTablelastChange). It 
would be good if this section mentioned those objects and why they are
not mapped to anything in this YANG module.

---

The two tables in Section 4 give good guidance on mapping between this
YANG module and the objects in the tables in IF-MIB. For one object in
ifXEntry, the text explains why there is no mapping (ifPromiscuousMode).
Two objects in ifEntry are deprecated so it is probably reasonable to
not mention them (ifOutQLen, ifSpecific). And the low capacity counters
are also covered in the text. However, that leaves eight objects
unmentioned. It would be helpful to show how these are mapped or 
explain why they are not needed.

ifEntry
        ifDescr                 DisplayString,
        ifMtu                   Integer32,
        ifAdminStatus           INTEGER,
        ifOperStatus            INTEGER,
        ifLastChange            TimeTicks,

ifXEntry
        ifHighSpeed             Gauge32,
        ifConnectorPresent      TruthValue,
        ifCounterDiscontinuityTime TimeStamp

I agree with Adrian's comments on the relationship between this YANG module and the IF-MIB.

I had not reviewed a YANG data model previously. This document is about as clear as I can imagine a document with this content being. Nice work!

1.1: Maybe it won't be confusing but I think those
definitions mean a USB stick GSM modem would be a system
controlled interface and not a user controlled interface
which seems counterintuitive. Would it be worth adding an
example like that to avoid potential confusion?

The document seems to gloss over the problem of interface name stability for removable interfaces.There is some mention of naming interfaces based on slots in the appendixes, but no talk about what to do if interface names aren't stable across inserts and removals of network hardware.

I'm not convinced that there is anything that can be done about this here, but it might be worth mentioning as an issue, and I didn't see it mentioned.