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

From: "Cole, Robert G CIV USARMY CERDEC (US)" <[email-masked]>
Date: Wed, 13 Jun 2012 18:35:05 +0000

Classification: UNCLASSIFIED
Caveats: NONE

Tom, MIB-Doctor's.

We are looking for some guidance on one of the comments on the NHDP-MIB below, 
specifically issue #6.  Please see below.

Thanks, Bob

-----Original Message-----
From: Cole, Robert G CIV USARMY CERDEC (US)
Sent: Wednesday, June 13, 2012 12:53 PM
To: 'Benoit Claise'; [email-masked]
Cc: 'The IESG'; [email-masked]; 
[email-masked]; 'Ulrich Herberg'
Subject: RE: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with 
DISCUSS and COMMENT) (UNCLASSIFIED)

Classification: UNCLASSIFIED
Caveats: NONE

Benoit,

I am struggling with your comments on the nhdpInterfaceTable (item #6 below).
I give two alternatives (please read way below).

a) I understand that this could be constructed as an AUGMENTS to the IF-MIB
ifTable.  E.g., (although the use of the nhdpIfRowStatus here does not seem
right)

"  nhdpInterfaceEntry OBJECT-TYPE
      SYNTAX      NhdpInterfaceEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
         "nhdpInterfaceEntry describes one NHDP
          local interface configuration.  It is
          constructed as an AUGMENTS to the
          Standard MIB II Interface Table (RFC2863)."
      AUGMENTS { ifIndex }
   ::= { nhdpInterfaceTable 1 }

   NhdpInterfaceEntry ::=
      SEQUENCE {
         nhdpIfStatus
            TruthValue,
         nhdpHelloInterval
            Unsigned32,
         nhdpHelloMinInterval
            Unsigned32,
         nhdpRefreshInterval
            Unsigned32,
         nhdpLHoldTime
            Unsigned32,
         nhdpHHoldTime
            Unsigned32,
         nhdpHystAcceptQuality
            Float32TC,
         nhdpHystRejectQuality
            Float32TC,
         nhdpInitialQuality
            Float32TC,
         nhdpInitialPending
            TruthValue,
         nhdpHpMaxJitter
            Unsigned32,
         nhdpHtMaxJitter
            Unsigned32,
         nhdpIfRowStatus
            RowStatus
         }
"

b) Instead we chose to extend the ifTable through a common indexing.  A
precedence does exists to our approach, e.g.,

"ipv4InterfaceEntry OBJECT-TYPE
    SYNTAX     Ipv4InterfaceEntry
    MAX-ACCESS not-accessible
    STATUS     current
    DESCRIPTION
           "An entry containing IPv4-specific information for a specific
            interface."
    INDEX { ipv4InterfaceIfIndex }
    ::= { ipv4InterfaceTable 1 }nhdpIfRowStatus

Ipv4InterfaceEntry ::= SEQUENCE {
        ipv4InterfaceIfIndex         InterfaceIndex,
        ipv4InterfaceReasmMaxSize    Integer32,
        ipv4InterfaceEnableStatus    INTEGER,
        ipv4InterfaceRetransmitTime  Unsigned32
    }

ipv4InterfaceIfIndex OBJECT-TYPE
    SYNTAX     InterfaceIndex
    MAX-ACCESS not-accessible
    STATUS     current
    DESCRIPTION
           "The index value that uniquely identifies the interface to
            which this entry is applicable.  The interface identified by
            a particular value of this index is the same interface as
            identified by the same value of the IF-MIB's ifIndex."
    ::= { ipv4InterfaceEntry 1 }
"

What is your recommendation?

Thanks,
Bob Cole

-----Original Message-----
From: Benoit Claise [mailto:[email-masked]]
Sent: Thursday, June 07, 2012 11:05 AM
To: [email-masked]
Cc: 'The IESG'; [email-masked];
[email-masked]
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

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 13 Jun 2012 14:58:55 -0400

>What is your recommendation?

        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.

        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.

        --Tom

---

From: "Cole, Robert G CIV USARMY CERDEC (US)" <[email-masked]>
Date: Wed, 13 Jun 2012 20:02:12 +0000

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.

        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?

Thanks, Bob

        --Tom

>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:
>
>       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:
>
>       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:
>
>       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.
>
>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,
>       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.
>
>
>
>
>
>       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.
>
>
>
>
>
>       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.
>
>
>       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.
>
>Do you want to have one static NMS monitoring the entire network, or do 
>you want to have every router only monitoring his neighbors (*).
>
>
>
>
>
>       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 (*)
>
>
>
>
>
>       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.
>
>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...
>
>
>       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?
>
>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.
>
>
>
>
>
>
>       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.
>
>
>       It looks like his question is "is it possible to run an IP-based 
>application over a MANET?"
>       Answer: yes.
>
>
>       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:
>

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 13 Jun 2012 16:15:53 -0400

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

>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

>>              StorageType [RFC2579] and a MAX-ACCESS value of
>>read-create,
>or
>>               with router B, and router B is able to exchange packets
>>with
>router C,
>>               Note that the write-up mentions: "This document shepherd
>>is
>not aware of
>>               So the potential implementers should have some views on
>>the
>following
>>               questions.
>>
>>               call it use cases if you want to): configuration
>>management,
>monitoring,
>>                       General question: Is a lossy, mobile ad-hoc
>>network
>compatible with
>>                  parameters of the Neighborhood Discovery Protocol
>>(NHDP)
>process on a
>>                  router.
>>

---

From: "Cole, Robert G CIV USARMY CERDEC (US)" <[email-masked]>
Date: Wed, 13 Jun 2012 21:20:13 +0000

Tom,  thx.  Will do. Bob

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

        --Tom

---

From: "Cole, Robert G CIV USARMY CERDEC (US)" <[email-masked]>
Date: Wed, 27 Jun 2012 18:04:08 +0000

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:[email-masked]] 
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; [email-masked]
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 <[email-masked]> wrote:

	<[email-masked]> wrote:
	
	>In the reference, I believe operationally you avoid entries that do
not
	>have
	>behavior is identified.  I agree with you that this is desirable.
I just
	>do

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

	>that you should use AUGMENTS, but that doesn't seem like what you
want.
	>The

	       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

	>>Subject: Re: Benoit Claise's Discuss on
draft-ietf-manet-nhdp-mib-14:
	>>(with
	>>               - There is a clear DISCUSS coming from the
MIB-doctor
	>review. Please
	>>          Note 2.  DisplayString does not support
internationalized text.
	>It
	>>                   internationalized text (which is always the
case if
	>>the
	>>                   object is intended for use by humans
[RFC2277]).
	>Designers
	>>              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
	>>               - While reading through the document, I've been
really
	>waiting for an
	>>               A sentence [RFC6130] such as "if router A is able
to
	>exchange packets
	>>               this does not guarantee that router A and router C
can
	>exchange packets
	>>               How do you plan on using this MIB module, taking
into
	>>account that you're
	>>               existing implementations of this MIB although
several
	>implementers have
	>>               I'm really after 3 different parts in the
applicability
	>statement (or
	>>               * one static NMS or each MANET router
configures/monitors
	>his (newly
	>>               Obviously, monitoring, for example, is important in
ad-hoc
	>networks, but
	>>               see the term "appropriate SNMP management
stations", and I
	>have no clue
	>>               * draft-ietf-manet-olsrv2-mib-04        Definition
of
	>Managed Objects for the
	>>               * 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
	>>               However, this document is the first MANET MIB
module to
	>reach the IESG,
	>>               If this is expressed in a different document, let
me know,
	>and I can
	>>                       SNMPv3? In other words, will the link
performance
	>information needed
	>>                       for troubleshooting really be available
when it is
	>needed most, and
	>>
	>>               - 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
	>>               Same remark for the introduction, which uses the
same
	>>text.

---

From: "Cole, Robert G CIV USARMY CERDEC (US)" <[email-masked]>
Date: Wed, 27 Jun 2012 18:47:42 +0000

Ulrich,

I guess I lean towards your former option, i.e.,

"- introduce an ifType=manet that applies for all MANET protocols. In the
NHDP-MIB, the interface table would only list ifType=manet. However, in case
another MANET protocol (not NHDP) is used on an interface, that interface
would still be listed in the NHDP-MIB interface table. I don't think that is
what we want."

Then the nhdpIfStatus object would be defined to indicate whether or not
NHDP is configured to run over that interface.  And type 'manet' would
restrict the total list of interfaces.

Then looking forward to the SMF-MIB, where SMF does not require NHDP to
operate, the smfInterfaceTable's smfIfAdminStatus would have a comparable
semantic, i.e.,

"smfIfAdminStatus OBJECT-TYPE
      SYNTAX      SmfStatus
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "The SMF interface's administrative status.
          The value 'enabled' denotes that the interface
          is running the SMF forwarding process.
          The value 'disabled' denotes that the interface is
          external to the SMF forwarding process.
          "
      ::= { smfInterfaceEntry 3 }
"

This would generally hold true for other manet control protocols, e.g., DSR,
AODV, etc

Bob

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

Bob,

we have to be careful how to name the ifType, since RFC6130 defines a "MANET
interface" as: "An interface participating in a MANET and using this
neighborhood discovery protocol", i.e. it is specific to the usage of NHDP.
Therefore, if we choose ifType=manet, but actually mean every MANET routing
protocol (incl. DYMO), that may be confusing. 
I wonder if it was a good idea to linking "MANET interface" specifically for
usage of NHDP in RFC6130... but it's too late to change it.

I see several options:
- introduce an ifType=manet that applies for all MANET protocols. In the
NHDP-MIB, the interface table would only list ifType=manet. However, in case
another MANET protocol (not NHDP) is used on an interface, that interface
would still be listed in the NHDP-MIB interface table. I don't think that is
what we want.
- introduce an ifType=nhdp that applies only for NHDP. In that case, only
these interfaces would be listed in the NHDP-MIB interface table, which is
correct. The question is, do we still need a ifType=manet, and ifType=nhdp
would be above the stack of ifType=manet?

Best regards
Ulrich

On Wed, Jun 27, 2012 at 11:04 AM, Cole, Robert G CIV USARMY CERDEC (US)
<[email-masked]> wrote:

	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-----
	
	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; [email-masked]
	Subject: Re: Benoit Claise's Discuss on
draft-ietf-manet-nhdp-mib-14: (with

	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 <[email-masked]>
wrote:

	
	
	       <[email-masked]> wrote:
	
	       >        I appreciate the reference but my points from
earlier still
	apply.
	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
	       >RGC> I do not see in reading through the reference RFC 4293,
how
	this
	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
	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.
	       >RGC> You are right; it is this later case and behavior we
want to
	achieve.
	       >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

	
	MIB-doctor
	       >>doctor Looking at the long list of open issues, copied for
the
	IESG
	       >>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
	internationalized text.
	       >It
	       >>                   MUST NOT be used for objects that are
required
	to hold
	case if
	[RFC2277]).
	       >>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
	       >>       That is, you do not have entries in the
NhdpInterfaceEntry
	table
	       >>       There are a number of these in the document, but I
have
	only
	       >>       8. When you use InetAddress, you are constraining it
to 4
	or 16.
	       >>The easiest thing to do is create a StorageType object in
each
	table
	       >>       There either MUST be one columnar object with a
SYNTAX
	value of
	MUST
	agent
	terminology
	       >like
	       >>"significant number"; you need to define what you expect
this
	means.   In
	       >>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
	       >>explicit MIB configuration values.  I know that you have
defined
	this
	       >>interoperable, especially if implementations really need to
use
	smaller
	       >>implementations to experience DoS attack on the device
because it
	is
	       >>forced to emit so many notifications that it overwhelms the
CPU.
	The
	       >>       12. The  nhdpIfState notification is potentially
dangerous
	given
	       >>notifications constantly for IF state changes for every
interface
	in
	       >>what value does this notification add above/beyond the
normal
	IfUp/Down
	       >>       Could you please capture your Discuss in the data
tracker
	so
	really
	       >>       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
	       >>Not really, basically, I'm asking a very simple question:
how do
	you
	       >>       I might ask you what is the point of the IF-MIB? Why
would
	any
	to
	       >exchange packets
	       >>               with router B, and router B is able to
exchange
	packets
	can
	       >exchange packets
	       >>               directly" got me thinking about the
management and
	       >operational aspects.
	into
	       >>necessarily symmetric. They are hard to predict because
they
	depend on
	       >>application to generate  map of the topology. Reading
statistics
	about
	       >>the performance of the protocol allows an application to
assess
	whether
	       >>       This all seems rather "obvious". I guess a statement
like
	this
	       >>               Note that the write-up mentions: "This
document
	shepherd
	several
	       >>               So the potential implementers should have
some
	views on
	applicability
	configures/monitors
	       >his (newly
	       >>               attached) neighbor(s)?
	       >>
	       >>
	       >>       I think the question you are asking is about
write-access.
	I
	       >>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
	       >>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
	       >>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
	       >>Interestingly, in that paper (and you will recognize the
author),
	there
	       >>expect all MANET routers to always have connectivity to a
static
	NMS?"
	ad-hoc
	       >networks, but
	       >>               please let us know how you envision doing
this. For
	       >>example, right now, I
	stations", and I
	       >have no clue
	       >>               what's "appropriate" in the management of an
ad-hoc
	       >>network.
	       >>"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's not try to see every single line in this DISCUSS as a
small
	thing
	       >>At this point in time, I believe that a conf. with the
authors
	would be
	of
	of
	Managed
	module to
	       >>       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
	me know,
	       >and I can
	       >>               review it.
	       >>
	       >>
	       >>       There is no other document on the applicability of
managing
	       >>MANET devices.
	performance
	when it is
	       >>       It looks like his question is "is it possible to run
an
	IP-based
	       >>       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
	
	Management
	in the
	for
	same