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

[Wes Hardaker <[e-mail]>]

>           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!
 
> 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.

> 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.
-- 
Wes Hardaker
Cobham Analytic Solutions