Re: [MIB-DOCTORS] Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with DISCUSS and COMMENT) (UNCLASSIFIED)

["Cole, Robert G CIV USARMY CERDEC (US)" <[e-mail]>]

Tom,  thx.  Will do. Bob

----- Original Message -----
From: Thomas Nadeau [mailto:[e-mail]]
Sent: Wednesday, June 13, 2012 08:15 PM
To: Cole, Robert G CIV USARMY CERDEC (US); 'MIB Doctors (E-mail)' <[e-mail]>
Cc: Ulrich Herberg <[e-mail]>; Benoit Claise <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with DISCUSS and COMMENT) (UNCLASSIFIED)



On 6/13/12 4:02 PM, "Cole, Robert G CIV USARMY CERDEC (US)"
<[e-mail]> wrote:

>Classification: UNCLASSIFIED
>Caveats: NONE
>
>Tom,
>
>
>-you wrote-
>        I appreciate the reference but my points from earlier still apply.
>In the reference, I believe operationally you avoid entries that do not
>have
>the correct ifType for the Ipv4InterfaceEntry.  Remember that if that were
>not the case, then what you get is a direct one-to-one mapping of IPv4
>interfaces attributes for EVERY IfTable entry.  This is a bad idea given
>that there are a wide array of devices that have a small set of their
>interfaces possessing IPv4 characteristics.
>
>RGC> I do not see in reading through the reference RFC 4293, how this
>behavior is identified.  I agree with you that this is desirable.  I just
>do
>not see the mechanism that informs the implementer to scope the ifType.

TOM: The reference doesn't explicitly say this, but that is how I believe
its implemented.

>
>        In your MIB you are effectively doing this.  If you really wanted
>that you should use AUGMENTS, but that doesn't seem like what you want.
>The
>simple way to correct this situation is to define an ifType for NHDP
>interfaces and explicitly exclude non-NHDP interfaces from being returned.
> This effectively "extends" - or more appropriately - "selectively
>extends"
>the IfTable entries.
>
>RGC> You are right; it is this later case and behavior we want to achieve.
>Where do I define an ifType for NHDP interfaces?  Also more generally,
>should I be defining an ifType for MANET interfaces?

        You do this in an IANA section. Take a look at how we did this in
RFC3811/12/13. It is pretty straight-forward. You can also see how to
scope its use tightly to avoid scale issues. I think you would want an
ifType for MANET - I was mistaken earlier when I said NHDP.

        --Tom



>
>Thanks, Bob
>
>
>        --Tom
>
>
>>
>>Thanks,
>>Bob Cole
>>
>>
>>-----Original Message-----
>>From: Benoit Claise [mailto:[e-mail]]
>>Sent: Thursday, June 07, 2012 11:05 AM
>>To: [e-mail]
>>Cc: 'The IESG'; [e-mail];
>>[e-mail]
>>Subject: Re: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14:
>>(with
>>DISCUSS and COMMENT)
>>
>>Hi Adrian,
>>
>>
>>       Hi Benoit,
>>
>>       I'm going to be a bit sniffy here :-)
>>
>>
>>               - There is a clear DISCUSS coming from the MIB-doctor
>review. Please
>>               address it.
>>
>>
>>       Sorry, what is your Discuss?
>>
>>My Discuss is simply: improve the MIB module according to the MIB
>>doctor Looking at the long list of open issues, copied for the IESG
>>convenience below, I wrote "clear DISCUSS"
>>
>>
>>       General Comments
>>       ----------------
>>
>>
>>        1.  I did not re-compile the MIB as I am assuming Bert's
>>comments from compilation were sufficient.  These comments are IN
>>ADDITION to Bert's so please make fixes required from his comments too.
>>
>>       2. Please go through the objects in the module and look for uses
>>of DISPLAY-STRING and UNITS where possible. There are numerous cases
>>where it should have been used but wasn't. I did not point out every
>>one, just the first one.
>>
>>       3. In general, you have not explicitly described what happens to
>>rows in the tables where read-create objects exist. You must describe
>>these behaviors. I have noted the first instance of this, but please
>>check all tables.
>>
>>       4. The use of DisplayString in the MIB is quite prevalent.
>>RFC4181 is very clear in stating that:
>>
>>          Note 2.  DisplayString does not support internationalized text.
>It
>>                   MUST NOT be used for objects that are required to hold
>>                   internationalized text (which is always the case if
>>the
>>                   object is intended for use by humans [RFC2277]).
>Designers
>>                   SHOULD consider using SnmpAdminString, Utf8String, or
>>                   LongUtf8String for such objects.
>>
>>
>>
>>       5. You need a DEFVAL for *every* read-create object. I have
>>noted the first case, but there are LOTS of these in the module that
>>need to be fixed.
>>
>>       6. There is some confusion about your ifTable interaction. You
>>seem to want an EXTENDS relationship, but your modeling is one of
>>AUGMENTS. That is, the index text describes two types of interfaces
>>(without a proper ifType BTW), where you allow for the modeling of
>>non-manet interfaces. What I think you want to do is have this
>>relationship:
>>
>>       ifEntry NhdpInterfaceEntry
>>       1, ifType=mols
>>       2, ifType=mpls
>>       3, ifType=manet    ---------> 3
>>       4, ifType = manet  --------->       4
>>       5, ifType = mpls
>>
>>       That is, you do not have entries in the NhdpInterfaceEntry table
>>for ifIndex-es 1, 2 and 5.
>>
>>
>>       7. I think it is customary to include the full reference
>>description in the REFERENCE clause. For example:
>>
>>                  "RFC 2863 - The Interfaces Group MIB, McCloghrie, K.,
>>                    and F. Kastenholtz, June 2000"
>>
>>
>>       There are a number of these in the document, but I have only
>>noted the first one. Please go through the document and make these
>>corrections, and please do it consistently.
>>
>>       8. When you use InetAddress, you are constraining it to 4 or 16.
>>This is unusual. It is typical to just use the TC as-is.
>>
>>       9.  I have found a number of tables that match this guidance.
>>The easiest thing to do is create a StorageType object in each table
>>and define its semantics.  I have only noted one case of this, but
>>there are a number of them.
>>
>>       There either MUST be one columnar object with a SYNTAX value of
>>              StorageType [RFC2579] and a MAX-ACCESS value of
>>read-create,
>or
>>              else the row object (table entry) DESCRIPTION clause MUST
>specify
>>              what happens to dynamically-created rows after an agent
>restart.
>>
>>
>>
>>
>>
>>       10. In the notifications section, there is ambiguous terminology
>like
>>"significant number"; you need to define what you expect this means.   In
>>fact, there is a lot of examples for defining explicit MIB variables
>>like nhdpNbrStateChangeThreshold that explicitly define this. This will
>>help aid interoperability.  All of the notifications suffer from this
>>deficiency.
>>
>>
>>       11. The notifications emitted here seem to be potentially of a
>>high volume given that manet applications can include massive numbers
>>of "mobile"
>>devices.
>>You really should include some limiting/throttling parameters as
>>explicit MIB configuration values.  I know that you have defined this
>>in some of the description clauses, but this is not easily
>>interoperable, especially if implementations really need to use smaller
>>values.  Also, the way things are written, it is possible for
>>implementations to experience DoS attack on the device because it is
>>forced to emit so many notifications that it overwhelms the CPU. The
>>"bad packets" notification is a great example.
>>
>>       12. The  nhdpIfState notification is potentially dangerous given
>>how the IfTable relationship is currently defined above to be
>>essentially a 1:1 match with the IfEntry.  Imagine having to issue
>>notifications constantly for IF state changes for every interface in
>>the normal IF-MIB and then here?
>>Also,
>>what value does this notification add above/beyond the normal IfUp/Down
>>notification if you define an ifType=manet as I suggested above?
>>
>>       13. The  nhdpPacketSrcAddr  notification has no limits or
>throttling.
>>What if
>>%100 of the packets sent to the device match this criteria? Do you
>>issue a notification for every one?
>>
>>
>>
>>
>>
>>       Could you please capture your Discuss in the data tracker so
>>that it can be resolved in discussion with you.
>>
>>Ok.
>>
>>
>>
>>
>>
>>               - While reading through the document, I've been really
>waiting for an
>>               applicability statement section.
>>
>>
>>       So, I think you are asking "Why would any application that is
>>not using telnet and a CLI or directly attached to the node want to
>>know any details about the topology learnt by the node?"
>>
>>Not really, basically, I'm asking a very simple question: how do you
>>plan on managing an ad-hoc network?
>>
>>
>>
>>
>>       I might ask you what is the point of the IF-MIB? Why would any
>>management application ever want to learn about the behavior of a
>>network node using a standardised protocol?
>>
>>I don't understand this.
>>
>>
>>
>>
>>
>>               A sentence [RFC6130] such as "if router A is able to
>exchange packets
>>               with router B, and router B is able to exchange packets
>>with
>router C,
>>               this does not guarantee that router A and router C can
>exchange packets
>>               directly" got me thinking about the management and
>operational aspects.
>>               How do you plan on using this MIB module, taking into
>>account that you're
>>               dealing with an ad-hoc network?
>>
>>
>>       I am not sure whether you asking
>>       - How will a TCP-based application work in a MANET?
>>
>>Yes.
>>
>>
>>
>>       or
>>       - What information might you learn from a MANET node
>>          that implements NHDP?
>>
>>       NHDP discovers neighbors. Neighbor relationships are not
>>necessarily symmetric. They are hard to predict because they depend on
>>physical placement of the nodes (and other conditions that affect
>>wireless transmissions).
>>Reading the information gathered using NHDP allows an external
>>application to generate  map of the topology. Reading statistics about
>>the performance of the protocol allows an application to assess whether
>>there is a misbehaving implementation and also whether the reported
>>topology is likely to be accurate.
>>
>>       This all seems rather "obvious". I guess a statement like this
>>could be added to the document. I hope that this would mean that
>>*every* MIB module that goes for publication from now on will be
>>required to add similar explanation of why a MIB module is relevant.
>>
>>
>>               Note that the write-up mentions: "This document shepherd
>>is
>not aware of
>>               existing implementations of this MIB although several
>implementers have
>>               indicated interest in the work."
>>               So the potential implementers should have some views on
>>the
>following
>>               questions.
>>
>>               I'm really after 3 different parts in the applicability
>statement (or
>>               call it use cases if you want to): configuration
>>management,
>monitoring,
>>               and notification. And I have questions such as:
>>               * one static NMS or each MANET router configures/monitors
>his (newly
>>               attached) neighbor(s)?
>>
>>
>>       I think the question you are asking is about write-access. I
>>think it is obvious from the module that the node can update the
>>information that is reported by an application reading the module. So
>>the question is why is so much write-access needed to so many objects
>>in the module? That is something the authors/WG need to answer.
>>
>>Coming back to my basic question: how do you plan on managing an ad-hoc
>>network?
>>Do you want to have one static NMS monitoring the entire network, or do
>>you want to have every router only monitoring his neighbors (*).
>>
>>
>>
>>
>>
>>               * where are the notifications sent to?
>>
>>
>>       Hmmm? Why is this question any different for this module
>>compared with any other module? Who consumes Notifications from other
>>modules?
>>
>>In the case of (*)
>>
>>
>>
>>
>>
>>               * Do you expect all MANET routers to always have
>>connectivity to a static
>>               NMS?
>>
>>
>>       Why ever not? It is a routed IP network. If there is a
>>management station present, it can connect. If the network becomes
>>partitioned, well, this is the same problem as in any other network.
>>
>>You know, I started to find a couple of my points addressed in
>>http://www.herberg.name/downloads/pubs/CNSM_10.pdf
>><blockedhttp://www.herberg.name/downloads/pubs/CNSM_10.pdf>
>>Interestingly, in that paper (and you will recognize the author), there
>>is the notion of proxy with the REPORT-MIB Sorry proxy or "Do you
>>expect all MANET routers to always have connectivity to a static NMS?"
>>
>>
>>
>>
>>               * etc...
>>
>>
>>       Can't address that one :-)
>>
>>
>>               Obviously, monitoring, for example, is important in ad-hoc
>networks, but
>>               please let us know how you envision doing this. For
>>example, right now, I
>>               see the term "appropriate SNMP management stations", and I
>have no clue
>>               what's "appropriate" in the management of an ad-hoc
>>network.
>>
>>
>>       Frankly, I don't think we have a good answer to what
>>"appropriate" means in any network. Again, I am not sure why a MANET is
>>any different.
>>
>>       But I agree that "appropriate" is a bad word and I should have
>>let it through my review. Perhaps this is a Comment?
>>
>>Whether this is Comment or a Discuss is not relevant.
>>Let's not try to see every single line in this DISCUSS as a small thing
>>to fix... it seems to me that there is an elephant in the room.
>>
>>
>>At this point in time, I believe that a conf. with the authors would be
>>more beneficial
>>
>>Regards, Benoit.
>>
>>
>>
>>
>>
>>
>>               I see some other MANET MIB modules...
>>               * draft-ietf-manet-olsrv2-mib-04        Definition of
>Managed Objects for the
>>               Optimized Link State Routing Protocol
>>               * draft-ietf-manet-report-mib-02        Definition of
>Managed Objects for
>>               Performance Reporting
>>               * draft-ietf-manet-smf-mib-04   Definition of Managed
>Objects for the
>>               Manet Simplified Multicast Framework Relay Set
>>               However, this document is the first MANET MIB module to
>reach the IESG,
>>               so those operational questions are important.
>>
>>
>>       Agreed. The authors of those other documents are waiting on the
>>review of this document to help them with their work. The MIB Doctor
>>review was much anticipated. I agree that the answers to the questions
>>you have raised are equally applicable to the other documents. I think
>>the lessons learned about write access will be quickly applied to the
>>other document. But I have some trouble understanding the value of the
>>other questions - I just can't understand why a MANET is so
>>dramatically different in your eyes.
>>
>>
>>               If this is expressed in a different document, let me know,
>and I can
>>               review it.
>>
>>
>>       There is no other document on the applicability of managing
>>MANET devices.
>>
>>
>>               Along the same lines,
>>               1. see Al Morton's review, part of the OPS-DIR
>>
>>                       General question: Is a lossy, mobile ad-hoc
>>network
>compatible with
>>                       SNMPv3? In other words, will the link performance
>information needed
>>                       for troubleshooting really be available when it is
>needed most, and
>>                       critical nodes may be unreachable?
>>
>>
>>       Sorry, I have not seen Al's review.
>>       It looks like his question is "is it possible to run an IP-based
>>application over a MANET?"
>>       Answer: yes.
>>
>>
>>               2. Read Ron's Bonica's Abstain
>>
>>
>>       Read and discussed with Ron in person. Presuming you agree this
>>part of your Discuss is not actionable (or maybe the action is to read
>>Ron's comment
>>:o)
>>
>>
>>               COMMENT:
>>
>> ----------------------------------------------------------------------
>>
>>               - Abstract
>>
>>                  This document defines a portion of the Management
>Information Base
>>                  (MIB) for use with network management protocols in the
>Internet
>>                  community.  In particular, it describes objects for
>configuring
>>                  parameters of the Neighborhood Discovery Protocol
>>(NHDP)
>process on a
>>                  router.
>>
>>               Should this be "MANET router"?
>>               "MANET router" is used in RFC6130
>>               Alternatively, I see in this document:
>>                       "NHDP router"
>>                       "router in a Mobile Ad Hoc Network (MANET)"
>>               Same remark for the introduction, which uses the same
>>text.
>>
>>
>>       This can be cleaned up.
>>
>>
>>               - First occurence of NHDP must be expanded.
>>
>>
>>       It already is.
>>
>>
>>
>>
>>
>>
>>Classification: UNCLASSIFIED
>>Caveats: NONE
>>
>>
>>
>>Classification: UNCLASSIFIED
>>Caveats: NONE
>>
>>
>
>
>Classification: UNCLASSIFIED
>Caveats: NONE
>
>