Subject: RE: [midcom] Protocol decision reminder

From: "Harrington, David" <[email-masked]>
Date: Tue, 10 Dec 2002 13:00:53 -0500

Hi,

I have read the complete semantics document through, thinking about each requirement, and I believe SNMPv3 can achieve all the semantic requirements. I am now considering the requirements of the needed mibs, and existing mibs, such as the NAT MIB, that are already under development. 

I will observe that the semantics document approaches the problem in a particular way, with some implicit design decisions. If I were designing from scratch with the assumption of SNMPv3 as the protocol, I would make some different design decisions to improve the alignment with best current practices of SNMP MIB design. Some of the mibs would be rather inefficient if designed to match the identified semantics. I expect all the protocols reviewers will find that they might have made slightly different design decisions to optimize their protocol to create more efficient/effective designs that achieve the same ends.

So my question is, after selecting a protocol, does the group intend to review the semantic model to align it with best current practices of the protocol chosen (without throwing out the original semantics document, or ignoring the purpose of the original semantic requirements)?

dbh

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, December 10, 2002 11:43 AM
> To: Melinda Shore
> Cc: [email-masked]
> Subject: Re: [midcom] Protocol decision reminder
> 
> 
> Well, I have a question.
> 
> Has anyone gone through the semantics document in detail and analyzed 
> whether or not the abstract protocol can be mapped into SNMP, and 
> specifically, whether SMI is a sufficient data model for what 
> we need to 
> do? I am not saying it isn't, I am merely saying that we 
> better be sure 
> it is OK before selecting SNMP. To be honest, the requirements and 
> framework, which form the basis of the evaluation, are really high 
> level. The devil with midcom is in the details, which have received 
> scant attention. I fear that we might make a choice and then 
> find that 
> some detailed operation we want to do cannot be accomplished.
> 
> Thanks,
> Jonathan R.
> 
> Melinda Shore wrote:
> > I'd like to remind everyone that we're now in the process of
> > going through the protocols, as ranked in the protocol
> > evaluation document, and determining one-by-one their
> > suitability for use as the midcom protocol.  
> > 
> > If someone cannot come up with a technical argument for why
> > SNMPv3 does not meet the midcom requirements and framework
> > it will become the midcom protocol.  If there are no such
> > comments by the end of the week, SNMPv3 will become the
> > midcom protocol.
> > 
> > Thanks,
> > 
> > Melinda
> > _______________________________________________
> > midcom mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/midcom
> > 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> 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: Eliot Lear <[email-masked]>
Date: Tue, 10 Dec 2002 10:20:43 -0800

SNMP version 3's security model, while novel, does not provide for 
distributed *integrated* key/certificate management.  There is no 
equivalent of Kerberos for SNMP users.  Scalable authorization of 
requests is required.

Eliot

---

From: Melinda Shore <[email-masked]>
Date: Tue, 10 Dec 2002 14:42:46 -0500

> equivalent of Kerberos for SNMP users.  Scalable authorization of 

Could you go into more detail about what the issue is here?
Although there's an appendix describing how to convert
passwords into keys, RFC 2264 doesn't describe where the
keys come from and certainly doesn't preclude the use of an
external key management system.  The limitation is that it
doesn't provide a mechanism for the engines to tell each
other what keying system they're using.  But as the document
is currently written I believe that I could use Kerberos
without changing anything.

Melinda