Subject: [RTG-DIR] RtgDir review: draft-ietf-netmod-interfaces-cfg-10.txt

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 29 Apr 2013 15:32:29 +0000

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-netmod-interfaces-cfg-10.txt
Reviewer: Carlos Pignataro
Review Date: 01 May 2013
IETF LC End Date: 03 May 2013
Intended Status: Proposed Standard

Summary:

I have some minor concerns about this document that I think should be resolved before publication.

Comments:

This document is very well written, and sensible. It certainly achieves what its Abstract sets up to do, cleanly. Thank you for writing it! 

However, I do believe that there are a few set of gaps that need to be resolved before publication. I identify some localized major issues below. Since I do not have context on some decisions that shaped the document, an explanation of the rational might suffice if sensible. Other of the identified issues, I believe, will require modifications or textual clarifications. In particular, I have a couple general concerns, about the generality of the data model defined in this document, details below.

I hope these review comments are clear and useful!

Major Issues:

3. Interfaces Data Model
…
            +--ro if-index?                   int32

The "?" indicates that the lead is optional. From a routing perspective, the if-index plays an important role when for example the network layer address does not identify a specific interface (e.g., IP unnumbered), or when there is no network layer address (LAG member, etc.). Why is this optional? In which case you envision it would not be present?

Additionally, a stronger relationship or at least a more detailed description of the relationship with ifIndex would help interoperable implementations. Does this "if-index" leaf follow ifIndex if it changes upon reload of interface recreation? It seems from the definition that it is the same?

3. Interfaces Data Model
…
            +--rw location?                   string
...
3.1. The interface List
…
   The "location" leaf is a string.  It is optional in the data model,
   but if the type represents a physical interface, it is mandatory.
   The format of this string is device- and type-dependent.  The device
   uses the location string to identify the physical or logical entity
   that the configuration applies to.  For example, if a device has a
   single array of 8 ethernet ports, the location can be one of the
   strings "1" to "8".  As another example, if a device has N cards of M
   ports, the location can be on the form "n/m", such as "1/0".

I think that "location" is a poorly chosen label, a misnomer. This seems to be closer to an identifier than a locator. For example, some devices number slots left to right, and some number slots right to left :-) This does not answer "where" something is; I do not mean geo-location, but I strongly suggest getting more precision on how this leaf is called. For example, interface numbering, instance id, type identifier, etc.

3. Interfaces Data Model
…
      +--rw interfaces
         +--rw interface [name]
            +--rw …

Is there a specific reason why there is no lead with the interface's MTU? It is quite important from a routing perspective for some protocols. MTU is not included even in the examples of ethernet-specific data models augmenting this base spec and appendices, which leaves it a bit underspecified…

General:

As a general major comment: it is not clear how general or how specific this definition and document is.

In terms of the definition, this definition does not include information that applies to all interfaces (e.g., MTU), but it does include very specific non-general things like is_promiscuous. What is the information model on which this data model stands? If there was not RFC 2863, would a leaf be defined as ifPromiscuousMode or phys-address? Or would that belong in an ethernet-specific module?

In terms of the examples, basically all examples are some form of ethernet interface. For a document that aims at being general for managing network interfaces, this choice seems not inclusive.

Minor Issues:

2. Objectives
...
   o  The data model should support the pre-provisioning of interface
      configuration, i.e., it should be possible to configure an
      interface whose physical interface hardware is not present on the
      device.  It is recommended that devices that support dynamic
      addition and removal of physical interfaces also support pre-
      provisioning.

It is interesting that these design criteria do not call out the applicability to "physical" and "virtual" interfaces. Moreover, the text above seems to imply that the only "dynamic creation and deletion" of interfaces happens with the "addition and removal of physical interfaces" and does not call out tunnels, loopbacks, virtuals, and other logical entities instantiated as "interfaces".

3. Interfaces Data Model

Do some of the strings need to be described as maximum access parameter? Some rw attributes cannot be changed in all practical terms. The "type" leaf is RW. However, with what applicability (different speeds of "ethernet", different serials, how can it be changed)?

3. Interfaces Data Model
…
            +--rw enabled?                    boolean
            +--ro oper-status?                enumeration

I would have expected these two not to be optional ("?").

3. Interfaces Data Model
…
      +--rw interfaces
         +--rw interface [name]
            +--ro statistics
               +--ro in-discards?          yang:counter32
               +--ro in-errors?            yang:counter32
               +--ro in-unknown-protos?    yang:counter32
               +--ro out-discards?         yang:counter32
               +--ro out-errors?           yang:counter32

It seems like some statistics are counter32 while others are counter64. The ones that are counter64 seem to coincide with the ones that have HC (High Capacity) counters in RFC 2863 (this is from memory, might be incorrect). Is that the reason? Is there any (other) specific reason why these are 32-bit counters while the rest of the statistics are 64 bit counters? I do wonder, however, if these should still be defined here as 64 bit...

4. Relationship to the IF-MIB
…
   The following table lists the YANG data nodes with corresponding
   objects in the IF-MIB.
...
               Mapping of YANG data nodes to IF-MIB objects

This section explains how name cannot always map to ifName. However, the table shows a 1:1 mapping of name <-> ifName. I suggest marking with a footnote or "*" the elements that might not always may 1:1.

For example, "enabled" also cannot map to ifAdminStatus. "enabled" is a boolean, and ifAdminStatus is an INTEGER with at least 3 values specified (up, down, testing). 

In summary, which ones map 1:1 and which ones do not?

4. Relationship to the IF-MIB
…
       | description                      | ifAlias                |

This is also a bit confusing -- the "description" maps to the ifAlias, and nothing maps to ifDescr.

4. Relationship to the IF-MIB

   The IF-MIB also defines the writable object ifPromiscuousMode.  Since
   this object typically is not a configuration object, it is not mapped
   to the "ietf-interfaces" module.

ifPromiscuousMode can actually be changed in many cases. Is that the only reason why attributes are being mapped to the "ietf-interfaces" module or not?

5. Interfaces YANG Module
...
     organization
       "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

     contact
       "WG Web:   <http://tools.ietf.org/wg/netmod/>
        WG List:  <mailto:[email-masked]>

        WG Chair: David Kessens
                  <mailto:[email-masked]>

Does the definition of the module, anchoring on a Working Group, put requirements or constraints on the existence of netmod? Meaning: what happens to these pointers when the WG ceases to exist, and the maling list is locked? Perhaps this is the usual way of defining contact for the YANG modules, but I suspect a time invariant pointer would help.

…
         leaf name {
           type string;
           description
             "The name of the interface.

              A device MAY restrict the allowed values for this leaf,
              possibly depending on the type and location.

              If the device allows arbitrarily named interfaces, the
              feature 'arbitrary-names' is advertised.

              This leaf MAY be mapped to ifName by an implementation.
              Such an implementation MAY restrict the allowed values for
              this leaf so that it matches the restrictions of ifName.
              If a NETCONF server that implements this restriction is
              sent a value that doesn't match the restriction, it MUST
              reply with an rpc-error with the error-tag
              'invalid-value'.";

Should the description of a YANG leaf be tied to NETCONF? Or are there potential uses outside NETCONF? Please note that although this comment is made once, it applies to all the descriptions that say "If a NETCONF server…", as there are quite a number of these.

         leaf location {
           type string;
           description
             "The device-specific location of the interface of a
              particular type.  The format of the location string

As mentioned above, this is not a "location".

         leaf phys-address {
           type yang:phys-address;
           config false;
           description
             "The interface's address at its protocol sub-layer.  For
             example, for an 802.x interface, this object normally
             contains a MAC address.  The interface's media-specific
             modules must define the bit and byte ordering and the
             format of the value of this object.  For interfaces that do
             not have such an address (e.g., a serial line), this node
             is not present.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifPhysAddress";
         }

Just by reading the description of this leaf, shouldn't this be part of an augmentation type-specific module? For example, for an Ethernet interface module, instead of the main YANG interface management top-level. Meaning: this specific leaf, by definition, cannot be generically specified to what it means for each type of interfaces. All the others can… if this cannot be specified outside a media-specific module, why define it here?

         leaf oper-status {
           type enumeration {
…

The description of the leaf as well as the enum values for the oper-status seem to be a bit under-defined. For example, "Ready to pass packets" seems too literal from the MIB, while I believe there are more precise definitions. Also, the description is actually listing usage of values instead of a real description.

7. Security Considerations

   The YANG module defined in this memo is designed to be accessed via
   the NETCONF protocol [RFC6241].  The lowest NETCONF layer is the
   secure transport layer and the mandatory-to-implement secure
   transport is SSH [RFC6242].

Are there security considerations for other aspects of this language definition? For example, what if YANG is used via a different method? What about storage of the data? What about AAA aspects for RW or RO leafs?

9.1. Normative References

   [I-D.ietf-netmod-iana-if-type]

This document points normatively to draft-ietf-netmod-iana-if-type-02. However, there are four additional revisions to the document and a most recent that is a year later than draft-ietf-netmod-iana-if-type-02. While things should be in sync given a common author and a hard dependency, just calling it out here since there are a few differences between those revisions of the normative reference:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-iana-if-type-06.txt&url1=draft-ietf-netmod-iana-if-type-02.txt

Appendix A. Example: Ethernet Interface Module

Do these appendices need to explicitly say that are non-normative? I would add a one-liner about it.

Appendix A. Example: Ethernet Interface Module

This applies to all appendices. I find it a bit incomplete that a specification for a language for "Interface Management" chose to ignore the richness of types of interfaces to show in the appendices :-) Basically, all of the ten (I think) different examples in the appendices are about Ethernet interfaces. While there is nothing underspecified, it is under-exemplified. How would a serial interface with sub interfaces loop like? How about a GRE Tunnel interface? Or a point-to-point satellite? Or a 3G interface? Or … 

Nits: 

2. Objectives
...
   o  The model must support interface layering, both simple layering
      where one interface is layered on top of exactly one other
      interface, and more complex scenarios where one interface is
      aggregated over N other interfaces, or when N interfaces are
      multiplexed over one other interface.

This is a nit: are "aggregated" and "multiplexed" the right words here? I believe I understand what is meant, but at the same time, it's not clear how "one interface" can be "aggregated" (i.e., aggregate a plurality/collection of elements into one). Perhaps: "and more complex scenarios where one interface results from the aggregation of N other interfaces, or when N interfaces are multiplexed over one other interface."?

5. Interfaces YANG Module

         leaf oper-status {
           type enumeration {
…

The description of the leaf as well as the enum values for the oper-status seem to be a bit under-defined. For example, "Ready to pass packets" seems too literal from the MIB, while I believe there are more precise definitions (s/packets/traffic/ at least?). Also, the description is actually listing usage of values instead of a real description.

I hope these are clear and useful!

Thank you,

Carlos Pignataro.

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 29 Apr 2013 22:46:41 +0200 (CEST)

Hi,

Thank you for your detailed review!  Comments inline.

"Carlos Pignataro (cpignata)" <[email-masked]> wrote:
> Hello,
> 
> I have been selected as the Routing Directorate reviewer for this draft. The
> Routing Directorate seeks to review all routing or routing-related drafts as
> they pass through IETF last call and IESG review, and sometimes on special
> request. The purpose of the review is to provide assistance to the Routing
> ADs. For more information about the Routing Directorate, please see
> http://www.ietf.org/iesg/directorate/routing.html
> 
> Although these comments are primarily for the use of the Routing ADs, it would
> be helpful if you could consider them along with any other IETF Last Call
> comments that you receive, and strive to resolve them through discussion or by
> updating the draft.
> 
> This document is very well written, and sensible. It certainly achieves what
> its Abstract sets up to do, cleanly. Thank you for writing it!
> 
> However, I do believe that there are a few set of gaps that need to be resolved
> before publication. I identify some localized major issues below. Since I do
> not have context on some decisions that shaped the document, an explanation of
> the rational might suffice if sensible. Other of the identified issues, I
> believe, will require modifications or textual clarifications. In particular, I
> have a couple general concerns, about the generality of the data model defined
> in this document, details below.
> 
> The "?" indicates that the lead is optional. From a routing perspective, the
> if-index plays an important role when for example the network layer address
> does not identify a specific interface (e.g., IP unnumbered), or when there is
> no network layer address (LAG member, etc.). Why is this optional? In which
> case you envision it would not be present?

I think you are right; this leaf should be mandatory.  This works
since it has an 'if-feature' statement.

But I would like to understand what role ifIndex plays - do you have
any pointers?

> Additionally, a stronger relationship or at least a more detailed description
> of the relationship with ifIndex would help interoperable implementations. Does
> this "if-index" leaf follow ifIndex if it changes upon reload of interface
> recreation? It seems from the definition that it is the same?

Yes, that is the intention.  The description says:

           The ifIndex value for the ifEntry represented by this
           interface.

> I think that "location" is a poorly chosen label, a misnomer. This seems to be
> closer to an identifier than a locator. For example, some devices number slots
> left to right, and some number slots right to left :-)

Correct, and we do not try to get into this at all.  Some
devices has 2 ports called A and B, and some have chassis of cards
with rows of ports...

> This does not answer
> "where" something is; I do not mean geo-location, but I strongly suggest
> getting more precision on how this leaf is called. For example, interface
> numbering, instance id, type identifier, etc.

The intention is really to be "where" the port is.  It is not intended
to be a virtual id.  If the operator plugs in a cable in a certain
port, he has to know how to configure this port so there must be
something in the config that connects to the physical port.  We use
the name "location" for this purpose.

> 3. Interfaces Data Model
> …
>       +--rw interfaces
>          +--rw interface [name]
>             +--rw …
> 
> Is there a specific reason why there is no lead with the interface's MTU? It is
> quite important from a routing perspective for some protocols. MTU is not
> included even in the examples of ethernet-specific data models augmenting this
> base spec and appendices, which leaves it a bit underspecified…

The mtu is specified in an accompanying document draft-ietf-netmod-ip.

> definition and document is.

It is a generic model. We tried to capture the intention in the
Introduction:

  This document defines a YANG ^RFC6020^ data model for the management
  of network interfaces. It is expected that interface type specific
  data models augment the generic interfaces data model defined in
  this document.

> In terms of the definition, this definition does not include information that
> applies to all interfaces (e.g., MTU), but it does include very specific
> non-general things like is_promiscuous.

Actually, ifPromiscuousMode is not part of this model.

> What is the information model on which
> this data model stands? If there was not RFC 2863, would a leaf be defined as
> ifPromiscuousMode or phys-address? Or would that belong in an ethernet-specific
> module?

You are right that phys-address might not have been included.

> In terms of the examples, basically all examples are some form of ethernet
> interface. For a document that aims at being general for managing network
> interfaces, this choice seems not inclusive.
> 
> 
> Minor Issues:
> 
> 2. Objectives
> ...
> It is interesting that these design criteria do not call out the applicability
> to "physical" and "virtual" interfaces. Moreover, the text above seems to imply
> that the only "dynamic creation and deletion" of interfaces happens with the
> "addition and removal of physical interfaces" and does not call out tunnels,
> loopbacks, virtuals, and other logical entities instantiated as "interfaces".

I think you are reading too much into the statement above.  It says
that IF you support addition and removal of physical interfaces, then
...  This does NOT mean that devices cannot support tunnels, loobacks
etc.  But maybe I misunderstood your point.

> 3. Interfaces Data Model
> 
> Do some of the strings need to be described as maximum access parameter? Some
> rw attributes cannot be changed in all practical terms. The "type" leaf is
> RW. However, with what applicability (different speeds of "ethernet", different
> serials, how can it be changed)?

Implementations that cannot for some reason support changing certain
parameters simply won't support it.  But that's not a reason for the
standard to not support it.  In general, there is nothing wrong in
changing the type of an interface in the configuration - if there's
physical hardware that doesn't match the type at the moment, the
oper-status will be 'not-present'.

> I would have expected these two not to be optional ("?").

Actually, 'enabled' has a default value, so that's why it is marked as
optional.  For oper-status I believe you are right; since it has the
state 'unknown' it does not have to be optional.  I think we should
change this.

> It seems like some statistics are counter32 while others are counter64. The
> ones that are counter64 seem to coincide with the ones that have HC (High
> Capacity) counters in RFC 2863 (this is from memory, might be incorrect). Is
> that the reason?

Yes.

> Is there any (other) specific reason why these are 32-bit
> counters while the rest of the statistics are 64 bit counters? I do wonder,
> however, if these should still be defined here as 64 bit...

The idea was that 64 bits are probably not needed for these counters.

> This section explains how name cannot always map to ifName. However, the table
> shows a 1:1 mapping of name <-> ifName. I suggest marking with a footnote or
> "*" the elements that might not always may 1:1.
> 
> For example, "enabled" also cannot map to ifAdminStatus. "enabled" is a
> boolean, and ifAdminStatus is an INTEGER with at least 3 values specified (up,
> down, testing).
> 

This table is supposed to be an overview.  I think I would prefer to
add a sentence that says something like "For details about thae
mappings, please see the corresponding definition in the YANG module".

> This is also a bit confusing -- the "description" maps to the ifAlias, and

Yes, this is b/c ifDescr is a read-only object defined as:

            This string should include the name of the
            manufacturer, the product name and the version of the
            interface hardware/software.

The only reason the "description" leaf is mapped to ifAlias is b/c
this is what many implementations do.  So we wanted to point out the
differences in the value space for these objects so that implementers
are aware of this.

> ifPromiscuousMode can actually be changed in many cases.

Right, but it is not typically a configuration parameter.

> Is that the only
> reason why attributes are being mapped to the "ietf-interfaces" module or not?

I wouldn't say that, bur for this particular object, the WG felt it
should be left out.

> Does the definition of the module, anchoring on a Working Group, put
> requirements or constraints on the existence of netmod? Meaning: what happens
> to these pointers when the WG ceases to exist, and the maling list is locked?
> Perhaps this is the usual way of defining contact for the YANG modules, but I
> suspect a time invariant pointer would help.

This also seems to be the usual way of defining contact info in
MIBs...

> Should the description of a YANG leaf be tied to NETCONF? Or are there
> potential uses outside NETCONF?

Currently the only standardized usage is NETCONF.  But vendors use
YANG for other purposes, and there's an individual draft that use YANG
for a RESTful api.

But the sentence really just specifies what a NETCONF server would
do.  It would be difficult to write this in a generic way, and at the
same time it is useful to specify this for NETCONF implementations.

> Please note that although this comment is made
> once, it applies to all the descriptions that say "If a NETCONF server…", as
> there are quite a number of these.

Yes, but it is only used when we specify the NETCONF protocol behavior.

> Just by reading the description of this leaf, shouldn't this be part of an
> augmentation type-specific module? For example, for an Ethernet interface
> module, instead of the main YANG interface management top-level. Meaning: this
> specific leaf, by definition, cannot be generically specified to what it means
> for each type of interfaces. All the others can… if this cannot be specified
> outside a media-specific module, why define it here?

See above - I think the reason is the relation to ifPhysAddress.

> 
>          leaf oper-status {
>            type enumeration {
> …
> 
> The description of the leaf as well as the enum values for the oper-status seem
> to be a bit under-defined. For example, "Ready to pass packets" seems too
> literal from the MIB

Yes.

> while I believe there are more precise definitions.  Also,
> the description is actually listing usage of values instead of a real
> description.
> 
> Are there security considerations for other aspects of this language
> definition? For example, what if YANG is used via a different method? What
> about storage of the data? What about AAA aspects for RW or RO leafs?

The WG recently added a note about AAA aspects to the Security
Considerations template for YANG modules.  I will update this document
as well with the new text.

> This document points normatively to draft-ietf-netmod-iana-if-type-02. However,
> there are four additional revisions to the document and a most recent that is a
> year later than draft-ietf-netmod-iana-if-type-02. While things should be in
> sync given a common author and a hard dependency, just calling it out here
> since there are a few differences between those revisions of the normative
> reference:

These documents are advanced together; but you are right, the
reference is pretty old.  I simply forgot to update it.

> Do these appendices need to explicitly say that are non-normative? I would add

Ok... but are examples ever normative?

> This applies to all appendices. I find it a bit incomplete that a specification
> for a language for "Interface Management" chose to ignore the richness of types
> of interfaces to show in the appendices :-) Basically, all of the ten (I think)
> different examples in the appendices are about Ethernet interfaces. While there
> is nothing underspecified, it is under-exemplified. How would a serial
> interface with sub interfaces loop like? How about a GRE Tunnel interface? Or a
> point-to-point satellite? Or a 3G interface? Or …

It is always tricky with examples... In this case we wanted to
examplify different features of the model, and we picked examples that
build on each other.

> This is a nit: are "aggregated" and "multiplexed" the right words here? I
> believe I understand what is meant, but at the same time, it's not clear how
> "one interface" can be "aggregated" (i.e., aggregate a plurality/collection of
> elements into one). Perhaps: "and more complex scenarios where one interface
> results from the aggregation of N other interfaces, or when N interfaces are
> multiplexed over one other interface."?

Yes, this is much better.  Thanks for the suggestion!

> The description of the leaf as well as the enum values for the oper-status seem
> to be a bit under-defined. For example, "Ready to pass packets" seems too
> literal from the MIB, while I believe there are more precise definitions
> (s/packets/traffic/ at least?). Also, the description is actually listing usage
> of values instead of a real description.

[this seems to be a duplicate comment]

> I hope these are clear and useful!

It was; thank you!

/martin

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 29 Apr 2013 23:02:44 +0000

Hi, Martin,

Thanks for the quick response! Please find some follow-ups inline. I believe some items are closed, but others need further discussion.

> since it has an 'if-feature' statement.

Thanks. Even if it works because of the clause, I'd make this mandatory.

> But I would like to understand what role ifIndex plays - do you have

Sure, you can grep for ifIndex in RFC 2328 (OSPFv2), e.g., Section 12.4.1.1., or RFC 5837.

>           The ifIndex value for the ifEntry represented by this

Ack. 

> the name "location" for this purpose.

Thanks for the explanation. While I appreciate (and I agree) that you do not get into interpreting or parsing the syntax of the field, I still think it is not a "location".

I believe there is still an underlying assumption that the language is defined for the physical world. If you have an Ethernet1/0, versus an Ethernet1/2, that identifies (not locates) which interface. Yes, you can use that to physically find them. But what if you have a "loopback123" vs "loopback112358 or a "Serial1/4:5.123"? I do not think we can "locate" the loopback, or the subinterface.

If the operator creates a "loopback", "Tunnel", or virtual interface, he or she does not need to physically locate it.

I believe that labeling the leaf as "location" can be harmful as it implies a specific meaning and shows assumptions. 

> The mtu is specified in an accompanying document draft-ietf-netmod-ip.

What draft-ietf-netmod-ip describes is the network-layer IPv4 MTU and IPv6 MTU. It does not describe the interface MTU. If that interface is used to run IS-IS, or to run MPLS, what is the MTU? It's neither the IPv4 MTU nor the IPv6 MTU.

>  data models augment the generic interfaces data model defined in

This is great, I agree with this intention and scope. My comment however was that the examples and some leafs specified make it more specific for some interfaces than others.

> Actually, ifPromiscuousMode is not part of this model.

You are correct, thank you. Sorry my bad.

> You are right that phys-address might not have been included.

OK, thanks. Do you mean that you will be removing it?

> etc.  But maybe I misunderstood your point.

I was not clear. Yes, that is an important statement. I was suggesting that an addition of something like this would help:

"o The dat amodel should support virtual interfaces as well as physical interfaces blah blah".

> oper-status will be 'not-present'.

Fair enough. Thank you.

> state 'unknown' it does not have to be optional.  I think we should

Perfect. Thank you.

>> Capacity) counters in RFC 2863 (this is from memory, might be incorrect). Is

OK.

> The idea was that 64 bits are probably not needed for these counters.

I tend to disagree with this. But as long as the WG explicitly discussed it (as opposed to blindly carry it over from the MIB).

> mappings, please see the corresponding definition in the YANG module".

No. I think that the table is a bit misleading when it says it described the "Mapping of YANG data nodes to IF-MIB objects", but some of these are related but do not really map.

> differences in the value space for these objects so that implementers

Thanks for this clarification.

> This also seems to be the usual way of defining contact info in

But not for others. Is there value in defining the contact this way? I am just asking.

> same time it is useful to specify this for NETCONF implementations.

I still find it a bit odd that the description intertwines protocol directives. 

> See above - I think the reason is the relation to ifPhysAddress.

THe question still stands -- if this is not a generic interface parameter, and instead is specific to some types of interfaces, should it be defined here or in type-specific submodules?

> as well with the new text.

Thank you.

> reference is pretty old.  I simply forgot to update it.

Thank you.

> Ok... but are examples ever normative?

Not typically. I was just suggesting demarcating normative vs. informative chunks of text.

> Yes, this is much better.  Thanks for the suggestion!

:-)

> [this seems to be a duplicate comment]

Yes, sorry. Are you planning on updating the description of the values?

>> I hope these are clear and useful!

I am glad about it. Thank you for your throughout responses.

-- Carlos.

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 30 Apr 2013 09:18:09 +0200 (CEST)

Hi,

Comments to the remaining issues inline.

> Thanks. Even if it works because of the clause, I'd make this

Yes, sorry for not being clear - it should be made mandatory, and I
meant that it is ok to make it mandatory since we have the
'if-feature' statement.

> Thanks for the explanation. While I appreciate (and I agree) that you
> do not get into interpreting or parsing the syntax of the field, I
> still think it is not a "location".
> 
> I believe there is still an underlying assumption that the language is
> defined for the physical world. If you have an Ethernet1/0, versus an
> Ethernet1/2, that identifies (not locates) which interface. Yes, you
> can use that to physically find them. But what if you have a
> "loopback123" vs "loopback112358 or a "Serial1/4:5.123"? I do not
> think we can "locate" the loopback, or the subinterface.
> 
> If the operator creates a "loopback", "Tunnel", or virtual interface,
> he or she does not need to physically locate it.
> 
> I believe that labeling the leaf as "location" can be harmful as it
> implies a specific meaning and shows assumptions.

Ok I think I understand your concern.  Personally, I think "location"
works also in this case, but we should pick a name that is as useful
as possible.  Let me bring this issue back to the WG.

> What draft-ietf-netmod-ip describes is the network-layer IPv4 MTU and
> IPv6 MTU. It does not describe the interface MTU. If that interface is
> used to run IS-IS, or to run MPLS, what is the MTU? It's neither the
> IPv4 MTU nor the IPv6 MTU.

This topic was discussed in the WG.  The result was that we did not
beleive we could define a generic mtu on the interface that would be
applicable to all types of interfaces.  Media-specific modules can
define this (maybe both configuration knobs and operational values).

> OK, thanks. Do you mean that you will be removing it?

I will have to bring this to the WG.

> I was not clear. Yes, that is an important statement. I was suggesting
> that an addition of something like this would help:
> 

Ok, this makese sense.  I will add this.

> No. I think that the table is a bit misleading when it says it
> described the "Mapping of YANG data nodes to IF-MIB objects", but some
> of these are related but do not really map.

It seems you react to the word "Mapping" here.  I am not sure why this
word would imply a one-to-one mapping, but if it helps we can change
this.

   Mapping of YANG data nodes to IF-MIB objects
   YANG data nodes and their corresponding IF-MIB objects
   YANG data nodes and their related IF-MIB objects
   ...?

> But not for others. Is there value in defining the contact this way? I

This is the currect practice that was decided (and documented in RFC
6087).

> Yes, sorry. Are you planning on updating the description of the

Oh, you actually wrote:

   The description of the leaf as well as the enum values for the
   oper-status seem to be a bit under-defined. For example, "Ready to
   pass packets" seems too literal from the MIB, while I believe there
   are more precise definitions.

Maybe we can provde more precise defintions, but I am not sure it
helps.  Since this leaf is supposed to reflect the ifOperStatus, what
happens if we have a different description of the values than the MIB?

/martin

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 30 Apr 2013 13:16:23 +0000

Martin,

Thanks again for the short RTT and the details in your response. I think this addresses most/all my concerns; details inline closing the loop. 

> as possible.  Let me bring this issue back to the WG.

Thank you. It seems to me you are "identifying" the instance.

> define this (maybe both configuration knobs and operational values).

OK, thanks. I still think that this is a big gap. Even the ethernet-specific examples that the document includes, do not include MTU configuration. A number of protocols break without MTU defined. I agree with defining IPv4 and IPv6 specific MTUs in the netmod-ip document, but it still seems to me that the interface MTU is fundamental and generic enough to be defined (that might not be applicable to every interface but enough ubiquitousness to be defined and call out exceptions).

That said, I just read the thread at http://www.ietf.org/mail-archive/web/netmod/current/msg07422.html and I can see it fit in media-specific modules. However, those are not defined (and I expect that might not be defined for every media, tunneling encap, etc.) 

Thank you.

Thank you.

Thank you.

> This is the currect practice that was decided (and documented in RFC

Thanks much for this pointer, I have not seen it.

>>>> oper-status seem

Many thanks again!

-- Carlos.