Subject: Re: [Isms] Ismstlstm last call comments from js

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 10 Dec 2009 09:26:40 +0100

On Wed, Dec 09, 2009 at 01:06:19AM +0100, Wes Hardaker wrote:

[...]

Thanks for your work. The following comments are written in my role as
a technical contributor.

>   + DISCUSS There is no explicit text talking about clearing (and 
>     setting up) multiplexing state. But I guess this needs to be
>     discussed where multiplexing is discussed and this likely
>     requires some timer to do something equivalent as TCP's
>     TIME_WAIT.
>      + WH: To be honest, I'm not sure I understand this comment at
>        all?  Which aspect of multiplexing are you referring to
>        and with what portion of the solution?  I could
>        extrapolate a number of ideas from this comment but I'm
>        not sure which you're concerned with.

Let me try be way of an example: Suppose I run 'snmpwalk', I press C-C
in the middle of the walk and I immediately restart it - will the
multiplexing to do the right thing or is the server going to consider
the packets for the new session "garbage" entering the old session?
And even if this is handled properly by DTLS (I do not know), what
happens if packets are reordered in the network and a late packet from
the first DTLS sessions spills over into the new session?

>   + DISCUSS The LAST-UPDATED and REVISION timestamps are likely wrong. Also 
>     note that there is again a shorter copyright notice that can be
>     used.
>     + WH: changed the date to be current when-built
>     + WH: copyright is what's in the SSH document.  Are you
>       suggesting we use only what is found on
>       [http://www.ietf.org/iesg/statement/mib-copyright.html] instead?

This web page has a note directing you to a page that directs you to
the Trust Legal Provisions (TLP) and then you have lots of stuff to
read. My understanding is that with the TLP in place, we can use this
short text:

     Copyright (c) 2009 IETF Trust and the persons identified as
     the document authors.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject
     to the license terms contained in, the Simplified BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (http://trustee.ietf.org/license-info).

At least this is what we now have in the YANG modules. Note that I am
not tracking the TLP in detail - perhaps Dan can confirm what the
latest boilerplate is and update the web page you pointed at above.

>   + WONTDO There is text in the DESCRIPTION of SnmpTLSAddress talking about 
>     TransportAddress, TransportAddressType, TransportDomain and this
>     seems to be a cut'n'paste error. (This text is in all *Address TC
>     definitions and need to be fixed in all instances.)
>     + WH: I think if you re-read the text you'll see it makes sense.
>       Note that it's identical text to what's in the SSH RFC.
>       It's functionally saying that you shouldn't use objects of
>       that specific type and should be using the more generic
>       ones instead but read the description clauses of the
>       generic ones for any resolving issues.

My comment was related to the fact that the SNMPv3 MIB modules (and
this is where these TCs matter for us) use TDomain/TAddress and _not_
TransportAddressType, TransportAddressDomain and TransportAddress.
There is also no reference to RFC 3419 and I think this is fine.  I
note that similar text is in RFC 5592 - I am now wondering why the
text is there as well. Since the TC is called SnmpTLSAddress, I assume
this TC is SNMP specific and thus belongs to the generic TAddress
family of TCs and not to the TransportAddress family of TCs.

>   + WONTDO Lifecycle of tlstmParamsEntry: It seems I can create an 
>     entry while there is no target entry yet. But then, when I
>     delete a target, the tlstmParamsEntry goes away. I find this
>     inconsistent.
>     + WH: fate sharing as is was the result of a previous WG
>       discussion (in stockholm I think).  The only option would
>       be to disallow making the target mib row active when a TLS
>       based domain was used until the row in the tlstmParamsTable
>       had been configured.  This would be a significantly more
>       complex management operation than repopulating the
>       tlstmParamsTable ahead of the target mib table.  I think
>       leaving the row so that it be pre-created is the only
>       sensible solution.
>     
>       In the WG meeting (I think) the participants were heavily
>       in favor of having the row deleted if the corresponding
>       TARGET row was deleted.  I think this makes sense from a
>       management issue, though I understand your view that it
>       looks inconsistent.  It's likely what the manager will want
>       most (if not all) of the time though.

I am not sure this is "likely what the manager will want most (if not
all) of the time though" but if the WG believes this I won't object.
I just do not recall that any of the other SNMPv3 tables do this kind
of automatic deletion and hence this automatic delete comes as a
surprise. I can very well imagine that I may want to change a target
during a renumbering exercise where I do not want to loose the TLS
parameters or that I want to disable a target for some time without
loosing the TLS parameters. But again, if the WG believes this
automatic delete is a feature, I will shutup.
     
/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>