Re: [Isms] Status of IESG-review changes for draft-ietf-isms-dtls-tm

["David Harrington" <[e-mail]>]

 

> -----Original Message-----
> From: Wes Hardaker [mailto:[e-mail]] 
> Sent: Wednesday, May 05, 2010 7:21 PM
> To: David Harrington
> Cc: 'Wes Hardaker'; [e-mail]; [e-mail]
> Subject: Re: Status of IESG-review changes for
draft-ietf-isms-dtls-tm
> 
> >           The output is deterministic so there is no issue with
> >           interoperability unless the APIs can't handle it.
> > 
> 
> DH> I still have concerns about interoperability. I think we'll talk
> DH> about this during the telechat tomorrow.
> 
> I'd love to see a case that points out where something isn't
> deterministic given the existing specifications.  Please provide!

My concerns are not about deterministic; they are about
interoperability.

>  
> > 3.2.1 CLOSED In Section 3.1.2, the last sentence of the last 
> > paragraph: 
> > --------------------------------------------------------------
> > ----------
> > 
> >            Implementations SHOULD offer configuration settings for
> >            mapping algorithms to SNMPv3 security levels.
> > 
> 
> DH> If we say it SHOULD, then shouldn't we provide the appropriate
> DH> tables in the MIB module?  I am not certain what such a mapping
> DH> would look like.
> 
> We even agreed in the WG at one point that such infrastructure
tables
> would be nice to have but would need to be defined in PKIX, 
> not in ISMS.

PKIX would not be the right place to define how to ***map them to
SNMPv3*** security levels. Or do I not understand what mappings you
think should be provided? Maybe I am confused because this spec talks
a lot about "mapping algorithms"; maybe you are thinking of something
else here than I am. As I said, I am not certain what such a mapping
would look like. Can you tell us what you think it would look like?

> 
> > 4.2.3 CLOSED Forgive my ignorance regarding SNMP/SMI, but I 
> > can't seem 
> > --------------------------------------------------------------
> > ---------
> >         to find a definition of "transport domain"; is it a 
> DNS domain
> >         name, a trust domain, or something else? (It seems 
> to be more
> >         like an address type.) It might help to make this clearer
in
> >         the definitions of the snmpTLSTCPDomain and 
> snmpDTLSUDPDomain
> >         transport domains.
> > 
> >           document you had read.  I'll put in a reference to
RFC2579
> 
> DH> Actually, 3417 is probably the preferred reference.
> 
> 3417 defines the current transport mechanisms (e.g. UDP).  RFC2579,
on
> the other-hand, defines the TDomain and TAddress TC which is the
base
> for them all.

OK.

> -- 
> Wes Hardaker
> Cobham Analytic Solutions
>