Re: [Isms] draft-hardaker-isms-dtls-tm-05 submitted - tlstmNotifications

["David Harrington" <ietfdbh at comcast.net>]

If one were to implement the DTLS-TM using a DTLS toolkit, would the
SNMP side of the API likely know why that the client certificate was
invalid, or would that likely be internal to the toolkit?

dbh 

> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:jhutz at cmu.edu] 
> Sent: Monday, September 14, 2009 4:53 PM
> To: David Harrington; 'Wes Hardaker'
> Cc: isms at ietf.org; jhutz at cmu.edu
> Subject: RE: [Isms] draft-hardaker-isms-dtls-tm-05 submitted 
> - tlstmNotifications
> 
> --On Monday, September 14, 2009 04:28:26 PM -0400 David Harrington 
> <ietfdbh at comcast.net> wrote:
> 
> > If you want insight into what is happening at the (D)TLS 
> "layer", then
> > you should write a (D)TLS MIB to capture that information. That
does
> > not belong in the transport model though, just as the specific SSH
> > failures do not get documented in the SSHTM MIB.
> >
> > Think of it this way. If you write a generic (D)TLS MIB 
> that recorded
> > InvalidClientCertificates and InvalidServercertificates, would
these
> > only be incremented when SNMP was the protocol utilizing the
(D)TLS
> > service, or might they also be incremented when using, say, IPFIX
or
> > Netconf or HTTP? I think these are (D)TLS-specific errors, not
> > SNMP-TM-specific errors.
> 
> There really isn't such a thing as "_the_ (D)TLS service".  A 
> given host 
> might have any number of services utilizing TLS or DTLS on 
> different ports 
> with different configuration.  It's not multiplexed the way 
> SSH might be, 
> and you wouldn't want to combine management information for 
> them.  Ideally, 
> there'd be some kind of "MIB fragment" describing (D)TLS 
> which could be 
> incorporated into MIB's for various services using those 
> protocols, of 
> which the SNMP DTLS TM is just one.
>