[Isms] review of changes to -13

[Wes Hardaker <wjhns1 at hardakers.net>]

I just did a quick review of the -13 update and thanks for working so
diligently on it!  In particular, I love the new wording surrounding
unique session identification (3.3.1) and how implementations may use
particular combinations of parameters or utilize internal session
pointers.  I think this much more closely aligns with real-word code
bases.  Thanks for tackling that sticky issue.

I have the following minor things to point out that are new nits as a
result of the edits done.  I didn't do a complete reread, but I did
read all the changed sentences based on the diff (which, as you said
would be the case, was rather extensive).  I have one long issue, and
a bunch of short ones.  I'll send the long one in a different message.


==== Minor edits.

* Section 3.2.1
*** "Any Transport Model SHOULD define one minimum-compliance security
    mechanism, but should also be able to support additional
    existing and new mechanisms."
*** I think this is somewhat hard to understand why it's being stated
    without an example.  EG, for SSH what is the minimum-compliance
    statement?  There was a reference to certificates, which was at
    least an example, but it's been removed now.  If you want to leave
    it generic, how about:
***** "Any Transport Model SHOULD define minimally required security
      features of the transport protocol.  The Transport Model SHOULD
      also be able to support additional existing and new mechanisms."
*** It A) uses "feature" instead of "mechanism" which I think makes it
    clearer that an author should discuss minimal setup of the
    protocol features and B) Creates two SHOULDs instead of one for
    each of the separate concepts
* Section 3.2.1.2
*** I don't think the *s around '*before*' are really needed.
*** "those security functions" is a reference to something nebulous.
    I'm not sure what it's referencing, so I'm guessing RFC3411
    "functions"?  How about:

      A secure transport performs any needed security functions on the
      message, before the message is decoded.  Note that some of these
      or similar functions might then be repeated by the selected
      Security Model.
* Section 3.2.1.3
*** Nit suggestion: use "stream" (eg "message stream") instead of
    "tunnel".  (Tunnels are more frequently reserved for IP-level
    packet transporting where the higher layer doesn't even know of
    it's existence, which is not the case here).
* Section 3.2.4
*** nit: "so cannot" => "so it cannot"
*** "If two different Transport Model" => "If two different Transport Model*s*"
***** Same sentence: I'm not sure the first comma is needed.
* Section 3.3
*** "session-like mechanism." => "session-like mechanism*s*."
* Section 3.3.2, 3rd paragraph
*** should => SHOULDs (like the previous paragraph)?
* Section 5.2.3
*** "to security level" => "to security levels"
* Section 6.3
*** "The contents of this cache are" => "The contents of this cache is"
* Section 6.4
*** "the USM Security Model has no need of values" =>
    "the USM Security Model has no need of *the* values"
* Section 6.2, re "DISCUSS"
*** FYI, I don't see any issues with the rewritten section that caused
    technical changes that should not have happened.


-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms