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,

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:[e-mail]] 
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; [e-mail]
Subject: Re: Benoit Claise's Discuss on draft-ietf-manet-nhdp-mib-14: (with
DISCUSS and COMMENT) (UNCLASSIFIED)

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)
<[e-mail]> wrote:


	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
	
	
	



Classification: UNCLASSIFIED
Caveats: NONE