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

Great, then it's a go :-)

Bob

-----Original Message-----
From: Thomas Nadeau [mailto:[e-mail]] 
Sent: Wednesday, June 27, 2012 2:55 PM
To: Ulrich Herberg; Cole, Robert G CIV USARMY CERDEC (US)
Cc: 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)



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

Bob,

okay, that convinced me.

Only slight disadvantage is that ifType=manet would not correspond to "MANET
interface" according to RFC6130, but to all MANET protocols. The question
would then be, how (and where) is the terminology defined for the "MANET
interface that is not limited to NHDP"? Adrian, any advice on that?

Thomas, would that solution be good for you?

TOM: Yes. This is along the lines of what I suggested earlier.

--Tom



Best
Ulrich

On Wed, Jun 27, 2012 at 11:47 AM, Cole, Robert G CIV USARMY CERDEC (US)
<[e-mail]<mailto:[e-mail]>> wrote:
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]<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]<mailto:[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]<mailto:[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]<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]<mailto:[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]<mailto:[e-mail]>>
wrote:




              On 6/13/12 4:02 PM, "Cole, Robert G CIV USARMY CERDEC (US)"

 
<[e-mail]<mailto:[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]<mailto:[e-mail]>]
              >>Sent: Thursday, June 07, 2012 11:05 AM
              >>To: [e-mail]<mailto:[e-mail]>
              >>Cc: 'The IESG';
[e-mail]<mailto:[e-mail]>;
 
>>[e-mail]<mailto:draft-ietf-manet-nhdp-mib@
tools.ietf.org>
              >>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<http://www.herb
erg.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




Classification: UNCLASSIFIED
Caveats: NONE