Subject: RE: [midcom] Comments on SNMP evaluation in draft-ietf-midcom-pro tocol-eval-00 .txt

From: "Mary Barnes" <[email-masked]>
Date: Sat, 15 Jun 2002 00:33:51 -0500

Hi all,

Just a few notes (as indicated by [MB] on how the issues raised here are
handled in the updated -01 draft):

Mary.

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]]
Sent: Thursday, May 30, 2002 1:44 PM
To: Davies, Elwyn [HAL02:0S00:EXCH]; [email-masked]'
Subject: Re: [midcom] Comments on SNMP evaluation in
draft-ietf-midcom-protocol-eval-00 .txt

Hi Elwyn,

Thank you for your comments. Please see my answers below.

--On 30 May 2002 14:48 +0100 Elwyn Davies wrote:

>
> Hi.
>
> Some thoughts on the SNMP evaluation part:
> - There are more areas than just security where only SNMPv3
>   can meet the requirements.

Which areas? Do you mean the two you mention below (INFORMS,
not extensively tested)?

[MB] Per the comment wrt 2.1.7, I did update the conclusion to reflect that
SNMPv3 is required for more than the security requirements. 

> - The very simple and unextendable semantics of the SNMP
>   protocol (just GET/SET/INFORM verbs) may be found to be
>   restrictive for the mechanisms needed for Midcom.

I don't think so. Can you give an example?

I agree that this restriction might become a bit
inconvenient, but I do not see any requirement that
is not met because of it.

> - SNMP message transport uses UDP when IP protocols are used
>   (ie essentially always).  This means that message delivery
>   is unreliable which has some knock on effects:
>   - The Midcom protocol would have to achieve reliability for
>     itself above the SNMP layer

Typically an SNMP stack includes some reliability mechanisms
"above" SNMP for exactly solving this problem.

Is it intentional, that there is no reliability requirement
for the midcom protocol?

>   - The Midcom protocol would have to be constructed to be
>     be idempotent with respect to the MIB Module which
>     implements the Midcom communication, because
>     acknowledgements are just as unreliable as original
>     messages. This means that any of the commands could be
>     executed more than once as a result of retransmissions
>     before an acknowledgement gets through.

Yes, this is a typical problem with SNMP. However, typically
it is solved case by case. Most cases can be solved by a good
MIB module design that considers this fact. The remaining cases
have to be covered by the SNMP agent implementation at the
midcom server.

>   - TRAP messages cannot be realistically used to for the
>     midbox -> agent direction as they are unacknowledged
>     - Instead need to use acknowledged INFORMs available
>     only in v3.

I disagree. I think that unacknowledged v2 notifications
are sufficient (and meet the requirements). Of course INFORMs
are more desirable.

[MB] I have updated requirement 2.1.7 to indicated that INFORMs are more
desirable. Let me know if there is an implicit need for TRAP for other
requirements, thus I would need to update those, as well.

> Versions 1 and 2 of SNMP have not been used for
> configuration purposes (only GET/TRAP verbs used) because
> of obvious concerns about security:  Network managers may
> have qualms about SNMPv3 until it has been extensively tested,
> which might slow up the deployment of Midcom if it uses SNMPv3.

Just compare deployment and testing of SNMPv3 to the other
protocols that have been suggested. It might turn out to be the
one with the most practical experience.

[MB] I have updated the conclusion with regards to SNMPv3. 

    Juergen
-- 
Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

> Regards,
> Elwyn Davies
----------------------------------------------------------------------------
------
>
> Elwyn B Davies
>
>         Routing and Addressing Strategy Prime
>         Portfolio Integration                   Solutions Ready
>
>         Nortel Networks plc                     Email:
[email-masked]
>         Harlow Laboratories                             ESN
6-742-5498
>         London Road, Harlow,                    Direct Line
+44-1279-405498
>         Essex, CM17 9NA, UK                     Fax
+44-1279-402047
>         Registered Office:                      Maidenhead Office Park,
Westacott Way,
>         Company No. 3937799                     Maidenhead, Berkshire,
SSL6 3QH
----------------------------------------------------------------------------
> This message may contain information proprietary to Nortel Networks plc so
any
> unauthorised disclosure, copying or distribution of its contents is
strictly prohibited.
----------------------------------------------------------------------------
> "The Folly is mostly mine"
> and the opinions are mine and not those of my employer.
>
============================================================================
======

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom