Subject: [Isms] TLSTM draft -05 published

From: Wes Hardaker <[email-masked]>
Date: Fri, 08 Jan 2010 10:59:58 -0800

I've published a -05 copy of the draft that has the following changes in
it:

1) Miscellaneous small wording items pointed out mostly by Tom.

2) Other wording suggestions and clarifications discussed and agreed to
   on the list since -04 was published (most of the suggestions were by
   David H).
   - client/server wording
   - identity/principal consistency
   - sessionID/port-uniqueness consistency
   - certificate verification terminology consistency
   - Agreed-upon text surrounding the 4366 reference to make it more
     generic and reference it as an example.
   - removal of the text describing fate-sharing between the target mib
     and the tlstm mib.  No fate sharing exists now, per WG consensus.

3) Implementation hint markings.  Both David and Tom wanted to see them
   explicitly spelled out, so I went back through my mail archives and
   found the two places in addition to 5.1.1 that were talked about as
   being hints.  I've added prefixes to the text in these places so they're
   now explicitly marked as advice.  I didn't mark 5.1.1 that way since the
   text already describes that the section is discussing one possible
   approach and thus is already marked as a hint.

A eventual link that should work for comparing the documents should be:

  http://tools.ietf.org/wg/isms/draft-ietf-isms-dtls-tm/draft-ietf-isms-dtls-tm-05-from-04.diff.html

But it's not yet active.

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 8 Jan 2010 20:31:32 +0100

On Fri, Jan 08, 2010 at 07:59:58PM +0100, Wes Hardaker wrote:

> I've published a -05 copy of the draft that has the following
> changes in it:

[...]

Thanks for the update. I think we are getting pretty close to
delivery. WG last call reviewers, please check the changes.

/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: Dave Shield <[email-masked]>
Date: Wed, 13 Jan 2010 11:12:23 +0000

2010/1/8 Wes Hardaker <[email-masked]>:
> I've published a -05 copy of the draft

I still need to catch up with the most recent discussions,
but the following comments from earlier versions still seem
to be relevant to the 05 draft.  Mostly wordsmithing for
clarity, or typos.  Feel free to adopt/ignore as you wish.

Dave

3.1.1  Step 3, para 2
   s/sequencing ability/sequencing ability,/
   s/sequence number for/sequence number used for/

3.1.2  para 2
   s/through the cache, the application/it also/

3.3 para 3
   The bulk of this paragraph seems to be discussing how
   to populate the target-related MIB tables, when used
   with a DTLS transport destination.  All except the last
   sentence, which is more concerned with access control.

   Suggestion:  Insert a new paragraph break before
     "The securityName defined ...."

4.1.1  para 1
   s/through a trusted out of band mechanism into the server/
     into the server through a trusted out of band mechanism,/

   s/its authenticity/their authenticity/

4.1.1  para 2, bullets

   s/type and value/value/

   Given that the name-based mapping is the preferred approach,
   (as indicated immediately following), might it be worth
   switching the order of these two bullet items?

4.1.1  para 6
   s/by the security model.  A security model, like the
        TSM security model [RFC5591], may perform/
     by a security model, such as the TSM security model [RFC5591].
        This security model may perform/

4.1.1  diagram
   Most of the elements in this diagram are modules from the
   (transport-extended) SNMPv3 architecture.   However
   'tmSecurityName' and 'securityName' are values passed
   (via the cache) from one module to another.

   Might it be useful to distinguish these different cases within
   the diagram.  E.g. by omitting the boxes:

      +-------+    tmSecurityName    +-----+
      | TLSTM | -------------------> | TSM |
      +-------+                      +-----+

4.3.1
  statusInformation
     s/passing of the message/sending of the message/
  destTransportDomain
     s/snmpDTLSSCTPDomain"/s/snmpDTLSSCTPDomain/
  outgoingMessage
     s/send to (D)TLS for encapsulation/
       pass to (D)TLS for encapsulation and transmission/

4.3.2
  transportDomain
     s/snmpDTLSSCTPDomain"/s/snmpDTLSSCTPDomain/
  incomingMessage
     s/removed of/removal of/

5  para 2
  s/first prior/prior/

5.1
  Suggested text:
     This section describes the procedures followed by the (D)TLS
  Transport Model when it receives a (D)TLS protected packet.  The
  required functionality is broken into two different sections.
  Section 5.1.1 described the processing required for de-multiplexing
  multiple DTLS sessions, which is specifically needed for DTLS over
  UDP sessions.  It is assumed that TLS and DTLS/SCP protocol
  implementations already provide appropriate message demultiplexing.

  Section 5.1.2 describes the transport processing required once
  the (D)TLS processing has been completed.  This will be needed
  for all (D)TLS-based sessions.

5.1.1  para 1
  s/always critical/critical/
  s/implementations be able/implementations are always able/

5.1.1  para 2
  s/wholeMessage/incomingMessage/
  s/wholeMessageLength/incomingMessageLength/
     [as per RFC 5590]

5.1.1  step 2, para 1
  s/ and its tlsSnmpSessionID//
     [The session ID is retrieved in step 3]

5.1.1  step 2, para 3
  s/both above and in Section 5.3/in Section 5.3/

5.1.1  step 5
  s/in the Section 5.1.2/in Section 5.1.2/

5.1.2
  Is it worth numbering these processing steps?
  E.g.
     1)  Create a tmStateReference ....
     2)  The wholeMessage and the wholeMessageLength ....
     3)  The TLS Transport Model ....

5.1.2  step 2
  The incomingMessage and incomingMessageLength are assigned
  values from the (D)TLS processing.

5.1.2  step 3
  s/wholeMessage/incomingMessage/
  s/wholeMessageLength/incomingMessageLength/
     [as per RFC 5590]

6.2  bullet 1
  s/New TransportDomain and TransportAddress formats/
    A new TransportAddress format/
       [The TransportDomains are objects, not TCs]

7  tlstmCertSpecified
  a/the mapping will be considered a failure/
    , and an alternative mapping looked for/

7  tlstmCertSANRFC822Name
  s/exmaple/example/
  Should this description mention the 32-character limit
  for security names, and describe what should happen if
  the RFC822 name is longer than this?
    [The required behaviour is covered in the descriptions
  of tlstmCertToTSNTable and tlstmCertToSNMapType, but
  it might be worth mentioning it here too.]

7  tlstmCertSANDNSName
7  tlstmCertCommonName
  Again, should these descriptions touch on the 32-character limit?
    [e.g. using similar wording to tlstmCertSpecified)

7  tlstmCertToTSNTable,    para 4, step 2
  s/CA certificated/CA certificate/

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 13 Jan 2010 06:58:19 -0800

>>>>> On Wed, 13 Jan 2010 11:12:23 +0000, Dave Shield <[email-masked]> said:

DS> I still need to catch up with the most recent discussions,
DS> but the following comments from earlier versions still seem
DS> to be relevant to the 05 draft.  Mostly wordsmithing for
DS> clarity, or typos.  Feel free to adopt/ignore as you wish.

Given that these new comments are months beyond the last call, I'll wait
for the WG chairs to decide whether I should address them now or wait
until IETF last call to look at them.

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 25 Jan 2010 14:00:44 -0800

Thanks for the suggestions Dave, they've certainly helped the document's
readability.  Below are my responses/actions to your comments.

My responses are prefixed below with "WH:" if you want to search for
them.  The status of each item is as follows:

  DONE:     Suggestion was acted on
  WONTDO:   Nothing was done; refer to the WH: response for reasons why
  DISCUSS:  There is an outstanding question back to you
  ANSWERED: A question was answered but had no action resulting from it

* DONE 3.1.1  Step 3, para 2 
  s/sequencing ability/sequencing ability,/
  s/sequence number for/sequence number used for/
  
* DONE 3.1.2  para 2 
  
* DONE 3.3 para 3 

* DONE 4.1.1  para 1 

* DONE 4.1.1  para 2, bullets 
  
  s/type and value/value/

* WONTDO 4.1.1  para 6 
  s/by the security model.  A security model, like the
       TSM security model [RFC5591], may perform/
    by a security model, such as the TSM security model [RFC5591].
       This security model may perform/
  + WH: The TSM security model is the only current one that
    does a mapping of some kind, but your text uses "This"
    which I don't think is appropriate since it gives the
    impression that the TSM will be the only one (which may
    or may not be true).
* DONE 4.1.1  diagram 
  Most of the elements in this diagram are modules from the
  (transport-extended) SNMPv3 architecture.   However
  'tmSecurityName' and 'securityName' are values passed
  (via the cache) from one module to another.

     +-------+    tmSecurityName    +-----+
     | TLSTM | -------------------> | TSM |
     +-------+                      +-----+
  + WH: Ok, see what you think of the new picture.
  
* DONE 4.3.1 
  statusInformation
  
* DONE 4.3.2 
  transportDomain
     
* DONE 5  para 2 
  s/first prior/prior/
  
* DONE 5.1 
  Suggested text:
  
  Section 5.1.2 describes the transport processing required once
  the (D)TLS processing has been completed.  This will be needed
  for all (D)TLS-based sessions.
  + WH: text changed to the above-ish:
    + s/5.1.1 described/5.1.1 describes/
    + 3 paragraphs were used instead of 2 (the first broken
      into two).
* DONE 5.1.1  para 1 
  s/always critical/critical/
  s/implementations be able/implementations are always able/
  
* DONE 5.1.1  para 2 
  
* DONE 5.1.1  step 2, para 1 
  s/ and its tlsSnmpSessionID//
     [The session ID is retrieved in step 3]
  
* WONTDO 5.1.1  step 2, para 3 
  s/both above and in Section 5.3/in Section 5.3/
  + WH: No, it's described directly above.  We could change it
    to be more explicitly stated like "in the last paragraph
    and in Section 5.3".  Would that be better?
* DONE 5.1.1  step 5 
  s/in the Section 5.1.2/in Section 5.1.2/
  
* DONE 5.1.2 
  + WH: Sure. makes sense.
  
* DONE 5.1.2  step 2 
  
* DONE 5.1.2  step 3 
  
* DONE 6.2  bullet 1 
  
* DONE 7  tlstmCertSpecified 
  a/the mapping will be considered a failure/
    , and an alternative mapping looked for/
    + WH: actually it was far more broken than even that would
      fix.  I changed the text to:
         The tlstmCertToTSNData column must contain
         a non-zero length SnmpAdminString compliant value or
         the mapping described in this row must be considered
         a failure.
  
* DONE 7  tlstmCertSANRFC822Name 
  s/exmaple/example/
  
* WONTDO 7  tlstmCertSANRFC822Name 
  Should this description mention the 32-character limit
  for security names, and describe what should happen if
  the RFC822 name is longer than this?
    [The required behaviour is covered in the descriptions
  of tlstmCertToTSNTable and tlstmCertToSNMapType, but
  it might be worth mentioning it here too.]
  + WH: I think mentioning it in every object-identity mapping is
    more text than is needed and is over kill.
  
* WONTDO 7  tlstmCertSANDNSName 
  + WH: I think mentioning it in every object-identity mapping is
    more text than is needed and is over kill.
* WONTDO 7  tlstmCertCommonName 
  Again, should these descriptions touch on the 32-character limit?
    [e.g. using similar wording to tlstmCertSpecified)
  + WH: I think mentioning it in every object-identity mapping is
    more text than is needed and is over kill.
    tlstmCertSpecified doesn't contain text describing the 32
    character issue.  It contains text describing special
    ramifications of the values populated into the
    tlstmCertToSNData column.
  
* DONE 7  tlstmCertToTSNTable,    para 4, step 2 
  s/CA certificated/CA certificate/