Subject: [midcom] On SNMPv3, clarification, invitation for discussion

From: Melinda Shore <[email-masked]>
Date: Mon, 24 Mar 2003 17:47:42 -0500

At the midcom meeting last week David Harrington raised the
issue of a recent policy change in the OPS area, which is
that because the use of SNMP for configuration hasn't
accelerated as expected, the OPS area seems to be moving
towards XML for configuration (no protocol specified).
There's a new policy that writable MIBs are no longer
required.  

This raised the question of whether or not we want to continue
with SNMPv3 as the midcom protocol, and we had a lengthy
discussion about what the actual issues are.  One thing to
consider is that the environment in which we expect midcom
to be deployed is substantially different from the
environment in which people might be using SNMP for static
device configuration.  

After the meeting I spent some time talking with Mary and
David, and they seem willing to continue the work (although
they'd appreciate more feedback from the working group).
The first draft of their work should be out very soon and we
expect that it won't take more than a few months to wrap it
up and deliver it to the IESG.  While the future may indeed
turn out to be XMLCONF, 1) that working group isn't even
chartered yet, and 2) the group that's developing it is
using the same data model as SMIng, and there are compilers
that take a MIB and turn it into an XML document.  That is
to say, MIB work now will be reusable with XMLCONF later.

I attended the OPS area meeting where this information was
confirmed.  It's not that SNMP is being deprecated or even
that the use of SNMP for configuration is being deprecated.
It's that writable MIBs are no longer mandatory.

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

---

From: Eliot Lear <[email-masked]>
Date: Mon, 24 Mar 2003 15:56:59 -0800

Melinda,

Two more additions to your valid comments.

XMLCONF has an intended audience: configuration and retrieval of static 
information within devices.  This may be slightly imprecise, but let me 
tell you what we *don't* think XMLCONF is good for: exchange of protocol 
state information.  We wouldn't want to replace BGP with XMLCONF, for 
example.

I believe midcom comes a lot closer to a state exchange protocol, such 
as BGP, then it does to the screen scraping that we are attempting to 
address with NET-CONF.  Certainly this holds true for STUN, and that's a 
good hint, IMHO.

ALSO.  To repeat what Bert, Andy, and others have said, while the 
requirement has been relaxed, there is nothing stopping anyone from 
writing a MIB or specification with writable objects.  You simply aren't 
REQUIRED to do so.

If this group believes that SNMP with writable objects is the right way 
to go, I say go for it.

Eliot

---

From: Tom Taylor <[email-masked]>
Date: Tue, 25 Mar 2003 15:30:19 -0500

The real issue is deployability of a MIDCOM protocol.  We heard that the operators 
we are targetting for MIDCOM are not enabling SNMP SET operations.  Jonathan was 
saying this was on grounds of cost.  Other interpretations are certainly possible. 
The point is that operators will enable a MIDCOM protocol only if they are convinced 
that they have adequate control over its operation, whether it be SNMPv3 or SIMCO. 
We need to hear from operators on what would convince them that the risks are 
acceptable, and that may well call for an extended risk analysis on our part.

In the meantime, I think the additional configuration constraints Juergen and Martin 
proposed in their semantics document open issues list are a move in the right 
direction.  Quoting from Melinda's E-mail: "Semantics Document" sent to the list on 
2003-03-10:

      - Shall the agent be able to specify parameters for protection
        against denial of service attacks? Examples are
           - maximum total number of TCP connection setups allowed
           - maximum number of TCP connection setups per minute
           - maximum number of UDP packets per minute
           - maximum bit rate
           - ...

I think we should be thinking along these lines.

---

From: Melinda Shore <[email-masked]>
Date: Tue, 25 Mar 2003 15:44:37 -0500

> The real issue is deployability of a MIDCOM protocol.  We
> heard that the operators we are targetting for MIDCOM are
> not enabling SNMP SET operations.

To be clear, what we heard is that the operators who were in
the room at the time that a show of hands was requested are
not enabling SNMP SET operations.  This doesn't include
enterprises and it's a highly biased sample.  It also
doesn't address the question of whether or not they'd enable
them in order to support new applications.

However, I do agree that we need to close the questions
Martin has raised, and we'll try to do that over the next
several weeks in preparation for a final draft to put into
WG last call.

Melinda

---

From: "Pyda Srisuresh" <[email-masked]>
Date: Fri, 28 Mar 2003 08:45:02 -0800

I agree. I believe, XMLCONF is useful for one-time configuration/retrieval.
SNMP is still desirable for
dynamic transactions.

cheers,
suresh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Eliot Lear
> Sent: Monday, March 24, 2003 3:57 PM
> To: Melinda Shore
> Cc: [email-masked]
> Subject: Re: [midcom] On SNMPv3, clarification, invitation for
> discussion
>
>
> Melinda,
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 28 Mar 2003 12:01:34 -0500

Pyda,

This is a pretty substantial claim. Can you provide details on why this 
is true?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com