[Isms] tlstm last call comments from js

[Juergen Schoenwaelder <j.schoenwaelder at jacobs-university.de>]

Hi,

I have reviewed the tlstm document and even though I have compiled a
relatively long list of issues and editorial nits, I believe the
document is in good shape and none of the issues I identified seem
to be difficult to address.

Technical comments:

a) In Appendix C, you use the RowStatus value createAndGo, which
   however is a transient value for creating rows. I suggest to use
   active instead, like in Appendix A of RFC 3414.

b) I found section 4.1 somewhat difficult to follow. It is not very
   clear what maps what to what. Perhaps a picture helps showing the
   mapping from the certification via tlstmCertToSNTable to a
   tmSecurityName and then via TSM to a securityName?

c) Is 4.5.1 needed as a subsection? It is just one sentence (well if
   the final missing to would be there ;-)

d) Is tlsRead() and tlsWrite() really needed? Implementation wise I
   understand tlsRead(), architecturally it may look odd. I know, you
   read something from a socket, you pass it through (D)TLS and then
   you deal with the content. But architecturally, you just get an SNMP
   message out of (D)TLS, no? tlsWrite is also not referenced in any
   other place. Is all this just there because DTLS/UDP lacks proper
   multiplexing support? See also below...

e) What does "consistently deterministic" in 5.1.1 mean?

f) In section 5.1.1 step (1), how can I know if a UDP message is a
   DTLS message or not? And how do I establish new session state if I
   throw away all messages that are not (D)TLS (should this be DTLS?)
   Application Data messages? It seems that the multiplexing generally
   needs to happen for all received UDP datagrams and all this happens
   below the TLSTM layer:

	... -> | UDP | -> | DEMUX | -> | DTLS | -> | TLSTM | -> ...

   If I am right, then I think we should factor this multiplexing out
   of the TLSTM elements of procedure and discuss it in some separate
   section. (How does DTLS for SYSLOG deal with this? Is this not a
   rather general issue to be fixed in a generic way?)

g) The last paragraph in 5.3 says that there is no way to indicate
   server certificate selection. Is there work underway to eventually
   fix this in (D)TLS?

h) 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.

i) The first sentence in 6.2 can probably be removed.

j) Why "public" in "Public certificate fingerprint"? The TC likely
   does not control what is public or non-public.

k) Condense the text in 6.5 (do not repeat twice that the MIB is for
   TLSTM - this has already been said). I also find "is likely
   ... will implement" a bit too vague of a language since some of the
   MIB objects really depend on the other modules to be implemented.

l) The LAST-UPDATED and REVISION timestamps are likely wrong. Also
   note that there is again a shorter copyright notice that can be
   used.

m) The message size requirement in snmpDTLSUDPDomain may be difficult
   to meet on generic platforms. (How shall I prepare for an unknown
   interface on a Linux box?)

n) 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.)

o) The phrases "UDP connection address" and "TCP connection address"
   and "SCTP connection address" sound strange, especially since UDP
   does not have a notion of a connection. I suggest to talk about
   endpoints instead.

p) I do not understand the REFERENCEs for Fingerprint. Looks like
   another cut'n'paste error.

q) Exclude 0 from the tlstmCertToSNID? This is usually useful so that
   a special value exists for reference purposes.

r) The last sentence in the DESCRIPTION of tlstmParamsEntry should be
   rewritten to make it clear that it only applies to targets that use
   certificates (as written now, this is not clear cut).

s) 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.

t) It would be nice to have the elements of procedure spell out when
   the two notifications are generated.

u) I am confused by section 9.2. I think both SNMPv1 and SNMPv2c MPs
   actually use the community-based security model. Is there really a
   "SNMPv2c(2) Security Model"?

Editorial nits:

s/Jurgen Schonwalder/Juergen Schoenwaelder/

s/value is a value that needs derive/value is a value derived/

s/tmSecurityNome/tmSecurityName/

s/Appendix C/Appendix C./

s/establishing a new sessions/establishing new sessions/

s/statical counters/counters/

s/is are/are/

s/US-US-ASCII/US-ASCII/

s/tlstmCertToSNecurityName/tlstmCertToSNSecurityName/

s/points to an usable/points to an unusable/

s/TRAPS and INFORMS/notifications/

s/RFC3484/RFC3584/

/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/>