Subject: [Isms] tlstm last call comments from js

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 29 Oct 2009 12:19:02 +0100

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

---

From: "Donati Andrew-MGIA0477" <[email-masked]>
Date: Thu, 29 Oct 2009 09:41:08 -0400

>    active instead, like in Appendix A of RFC 3414.

Appendix C appears to show how to configure or, using the software term,
how to "instantiate" the entries.   
If 'active' is used for RowStatus in these examples, the following
sentence will also need to change; <An example vacmSecurityToGroupTable
row might be filled out as follows (using a single SNMP SET request):>
Below shows an illustration of how it may change if 'active' is used: 
<An example vacmSecurityToGroupTable is instantiated as follows:>

Otherwise, if 'createAndGo' is used, all of the examples in Appendix C
may have to explicitly indicate that they are showing how to configure
the entries by pointing out that the illustrations are showing a SET
request, as indicated in the first of the three examples.

- Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Juergen Schoenwaelder
Sent: Thursday, October 29, 2009 7:19 AM
To: [email-masked]
Subject: [Isms] tlstm last call comments from js

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:

Editorial nits:

s/is are/are/

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

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/>
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 29 Oct 2009 15:34:53 -0700

>>>>> On Thu, 29 Oct 2009 12:19:02 +0100, Juergen Schoenwaelder <[email-masked]> said:

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

Thanks for the review and the list of nits.  I'll look over those in the
next few weeks, but glancing through them quickly I agree they look easy
to address.

One immediate comment:

JS> s/Jurgen Schonwalder/Juergen Schoenwaelder/

Way back when, before my Emacs installation was UTF-8 compliant you
ended up in my address book with that misspelling when the accented
characters got dropped during some conversion process (and I just now
realized this).  I'm in shock that I've just now noticed that your
record in my address book was incorrect (which is where I did a copy
from).  Thanks for pointing this out to me and accept my apologies for
taking so long to notice (especially since I've been spelling it
correctly by hand correctly for a long time).

-- 
Wes Hardaker
Cobham Analytic Solutions