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]>]

Classification: UNCLASSIFIED
Caveats: NONE

Ulrich,

One observation. I had proposed ifType=manet  instead of type 'nhdp' to
designate an interface which would carry any MANET protocol (e.g., NHDP,
AODV, OLSR, etc).  As you point out, I believe the ifStackTable could be
used to indicate that we wish to run 'manet' over ifType=802.3 or Ethernet
or 802.11 or whatever.  And that seems to me to be a reasonable approach. 

Then in the NHDP-MIB our nhdpIfTable would only contain rows for the
interfaces that we are running manet protocols over, as indicated  in the
ifTable and ifStackTable.

Bob

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

Thomas,

I understand now better how the ifType works, as defined in RFC2863.
Essentially, we would request from IANA to allocate a new "MANET" IANAifType
in http://www.iana.org/assignments/ianaiftype-mib

I just want to make sure that this is the correct thing to do. A MANET
interface is specified in RFC6130 as an interface that runs NHDP (i.e., a
protocol above IP in the stack). I have the impression that most of the
other ifType are below the IP layer. It would also imply that we have to add
plenty of entries in the ifStackTable (MANET above 802.11, MANET above
802.15.4 etc), right? And it means that, e.g., DYMO/AODV (even though
specified in the MANET WG) would not use the MANET ifType, because the
reactive MANET protocol does not use NHDP. If all that is as intended, then
we can go ahead and change it in the MIB-module.

Thanks
Ulrich




On Wed, Jun 13, 2012 at 1:15 PM, Thomas Nadeau <[e-mail]> wrote:




	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
	>
	>
	
	



Classification: UNCLASSIFIED
Caveats: NONE