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

From: "Jerome Moisand" <[email-masked]>
Date: Thu, 27 Mar 2003 10:11:24 -0500

Quite true.

It is a fact that the great majority of Service Providers (ILECs, PTTs,
ISPs, MSOs, whatever) tend to refuse to use SNMP for anything else than
monitoring (hence GETs). 

From my experience, this appears to be true for all market segments, and
all geographical theaters.

Could this trend be reversed by educating more & more people about
SNMPv3 is a matter of endless debates... But this new IETF policy about
'writable MIBs' will definitely not help to address this 'deployability'
issue.

This is quite different from the enterprise environment where SNMP SETs
are more commonly accepted.

Jerome

-----Original Message-----
From: Tom Taylor [mailto:[email-masked]]
Sent: Tuesday, March 25, 2003 3:30 PM
To: Melinda Shore; [email-masked]
Subject: Re: [midcom] On SNMPv3, clarification, invitation for
discussion

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.

[...]

Melinda Shore wrote:
> 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
> 

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

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 28 Mar 2003 12:38:30 -0600

I've snipped the thread to just respond to David's final point suggesting
that the WG can get started now on XMLConf schema for MIDCOM.  The reason
this WG is currently considering SNMPv3 for MIDCOM is because it proved to
be the "best fit" based upon the protocol evaluation, in which XMLconf was
not considered (as no new protocol was put under consideration unless the
ones put forth were all deemed unsuitable).

If SNMP is no longer deemed suitable (i.e. IF the WG has found a compelling
reason not to use it) and I'm assuming that this same reason being put forth
would also apply to COPS-PR, then we need to be looking at extensions to
Diameter to support MIDCOM (based upon the decision that has us working on a
MIDCOM mib right now), per the WG direction set back in December:
http://www1.ietf.org/mail-archive/working-groups/midcom/current/msg03037.htm
l 

That all said, it was my understanding that there are tools that can convert
mibs to XML, so is it really a waste to go ahead and define a mib?  Without
existing XMLConf schema being available, it would seem that there's no
reusuability, whereas with mibs, the potential for re-usability seems fairly
high.  Or are you suggesting we convert all these exisiting mibs that might
be applicable to MIDCOM to XML and work from there?  Personally, that seems
to be far more work at this juncture than the current approach.

Regards,
Mary H. Barnes
[email-masked]
 
-----Original Message-----
From: Durham, David [mailto:[email-masked]]
Sent: Friday, March 28, 2003 12:11 PM
To: Jonathan Rosenberg; [email-masked]
Cc: Eliot Lear; [email-masked]
Subject: RE: [midcom] On SNMPv3, clarification, invitation for
discussion

I agree. There is nothing technically preventing XMLConf from doing
small dynamic transactions. In fact, I argue that XMLConf would be
superior over SNMP for such transactions. Do the math: 

----stuff deleted by Mary Barnes ---------------

I can go on an on the con's of snmp here. One con on XMLConf is that
it's just starting. However, XML is not new. This wg can get started
immediately writing XMLSchema models for middle boxes.

-Dave

----rest of thread deleted by Mary Barnes
_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: "Durham, David" <[email-masked]>
Date: Fri, 28 Mar 2003 12:01:59 -0800

I think MIB --> XML is less than ideal. Most of the problems of the snmp
protocol percolate through the MIB data model, specifically the midcom
MIB. XMLSchema would provide a foundation free of all the snmp-isms
rampant in the MIB data model (full of crappy little rules one must
adhere to). If everything midcom wants to do can be flattened out into
rows in a table, fit into a MTU, and doesn't need anything other than
the most basic SMI data types, and the wg is willing to implement all
the transactional semantics into the midcom MIB, then fine (but seems
like a lot of extra work to me). 

-Dave

> From: Mary Barnes [mailto:[email-masked]]
> Sent: Friday, March 28, 2003 10:38 AM
> To: Durham, David; Jonathan Rosenberg; [email-masked]
discussion
> Diameter to support MIDCOM (based upon the decision that has us
working on
> a

---

From: "Harrington, David" <[email-masked]>
Date: Sun, 30 Mar 2003 03:02:52 -0500

Hi Dave,
 
My primary response is contained in a previous message. I just thought I'd respond to some specifics here. Inline.

-----Original Message-----
From: Durham, David [mailto:[email-masked]]
Sent: Friday, March 28, 2003 3:02 PM
To: Mary Barnes; Jonathan Rosenberg; [email-masked]
Cc: Eliot Lear; [email-masked]
Subject: RE: [midcom] On SNMPv3, clarification, invitation for discussion

MIB.  

I'm on the design team for the MIDCOM MIB. From that rather unique perspective, I can assure you we haven't yet published a document or even written the first line, the BEGIN statement, of a midcom mib. So I have some difficulty understanding how you know that "the problems of snmp percolate through the MIB data model, specifically the midcom mib." 

Can you point out the document you've used for your analysis? Can you point out specifically which lines in the document or managed objects in the mibcom mib reflect the problems that concern you?

 XMLSchema would provide a foundation free of all the snmp-isms

-Dave

> From: Mary Barnes [  <mailto:[email-masked]> mailto:[email-masked]]
discussion
working on
>  <http://www1.ietf.org/mail-archive/working-> http://www1.ietf.org/mail-archive/working-
> groups/midcom/current/msg03037.htm
> l
>
> From: Durham, David [  <mailto:[email-masked]> mailto:[email-masked]]
_______________________________________________
midcom mailing list
[email-masked]
 <https://www1.ietf.org/mailman/listinfo/midcom> https://www1.ietf.org/mailman/listinfo/midcom

---

From: "Harrington, David" <[email-masked]>
Date: Mon, 31 Mar 2003 00:03:02 -0500

Hi Eliot,
 
Thanks for the correction.
 
I concur that this belongs on the xmlconf list, not the midcom list.
 
dbh

-----Original Message-----
From: Eliot Lear [mailto:[email-masked]]
Sent: Sunday, March 30, 2003 12:12 PM
To: Harrington, David
Cc: [email-masked]
Subject: Re: [midcom] On SNMPv3, clarification, invitation for discussion

I recognize that this is not the place to debate XMLCONF, but I do want 
to disagree with one statement Dave made. 

> XMLConf doesn't actually address security at all. I see nothing the 
> proposal about ow to identify the authenticated user, or how to apply 
> access control to the data, since there isn't even a data addressing 
 > capability defined for XMLConf yet. 

Wrong, wrong, right, and right.  We do address certain components of 
security.  One identifies an authenticated user through a choice of 
either SASL or TLS in BEEP, and appropriate analogs should one use 
multi-channel HTTP. 

We do not specify an authorization model  in the draft as it stands.  As 
we see it, one would need to address the meta-data model in order to 
address authorization in the protocol.  This is not to say that an 
implementor shouldn't provide an authorization model.  We just don't 
standardize it in the current document. 

Let me suggest that the debate between SNMP and XMLCONF is sort of wrong 
in the first place, as it wasn't really meant to replace SNMP, and that 
if one really feels the need to debate the matter, it is better done on 
the xmlconf mailing list, which hangs off ops.ietf.org. 

Eliot