Subject: [Isms] review of draft-ietf-isms-tmsm-04.txt

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 5 Nov 2006 01:12:46 +0100

I have reviewed <draft-ietf-isms-tmsm-04.txt> and here are my comments
(as a technical contributor). Even though I have written down quite
some comments, I believe this document is in a rather good shape and I
would encourage especially SNMP people to look at it.

/js

01: Should the document status not be standards track? Note that RFC
    3411 is also standards track.

02: On page 5, should we mention SHA instead of MD5 or more generally
    talk about hash and encryption functions?

03: Page 6, last paragraph states that every proposed transport model
    "includes a discussion of the applicability statement of the
    protocols to be used". Do you really mean a discussion of the
    applicability statement? Or do we mean that every proposed
    transport model "includes an applicability statement which
    discusses the security protocols to be used."

    Note that the current ISMS charter kind of suggests a separate
    document for the applicability statement. I personally would
    prefer to inline these applicability statements into the various
    secure transports as page 6 seems to suggest.

04: Page 8 says that the ASIs utilize TransportType and
    TransportAddress. I believe we have to stick to TDomain and
    TAddress in the SNMP MIB space and transportDomain and
    transportAddress in the ASI space. (Requires edits in all three
    documents in various places).

05: Page 10: In the box representing the Dispatcher, I would add
    "Transport Dispatcher" at the top (similar to Message Dispatcher
    and PDU Dispatcher).

06: Page 12: Add vertical bars to the SNMP messaging box and fix the
    alignment of the arrow between the transport layer and the SNMP
    engine box.

07: Page 12: The following sentence is a bit confusing (and ends with
    a comma):

     If a message is secured using non-SNMP-specific message security and
     parameters, then the transport model should provide the translation
     from e.g., an SSH user name to the securityName in step 3,

    Step 3 is marked as (messaging model). Perhaps a better phrasing is:

     If a message is secured using non-SNMP-specific message security
     and parameters, then the transport model should provide the
     translation from e.g., an SSH user name to the securityName
     messaging model in step 3.

08: Page 12 and page 13: I find the two figures pretty different; on
    page 13 you indicate a security model while on page 12 you indicate
    only a box with "decryption + translation". Is it needed to have
    these figures at all or is it possible to explain the difference
    between message based security and transport model security not
    be refering to the boxes in the figure on page 10?

09: Page 14 has a duplicate dot in 2.2.2.1.

10: Page 17: I do not understand the [todo:]

11: Page 17: Rewording of the old text:

     Throughout this document, the term session is used.  Some underlying
     secure transports will have a notion of session.  Some underlying
     secure transports might enable the use of channels or other session-
     like thing. 

    New text:

     Some secure transports may have a notion of sessions while other
     secure transports might provide channels or other session-like
     things. Throughout this document, the term session is used in a
     broad sense to cover sessions, channels, and session-like things.

12: Page 18: My answer to the [discuss] is no. The transport model
    should not have insight into the security model.

13: Page 19: I suggest that we leave it to the transport to define
    what happens if the session disappears while a response is being
    prepared and close the discuss.

14: Page 20: ransport -> transport

15: Page 20: End of 5th paragraph: Should we not state explicitely
    that the actual security level can be upgraded by a secure
    transport, i.e. that noAuth/noPriv and auth/noPriv can be sent
    over an authenticated and encrypted session?

16: Page 21: Regarding the [discuss]: I would be in favor of dropping
    any discussions about speculative features of transports yet to be
    invented.

17: Page 25: "contrain" -> "constrain"

18: Page 25: Concerning the [todo]: I think it OK to keep the ASIs
    since they were actually changed.

19: Page 26: Add a comment to tmStateReference in the ASI and mark it
    as (NEW) so that it becomes obvious what has changed.

20: Page 26: "for the application" -> "from the application"

21: Page 27: Add a comment for the tmStateReference in the ASIs.

22: Page 27: The openSession() and closeSession() ASIs are actually
    never invoked by the dispatcher and hence they do not need to be
    visible in the architecture; they could be purely local to the
    transport models. On the other hand, I agree that several
    transports will have similar internal openSession() and
    closeSession() interfaces. Perhaps the text should make it clear
    that these ASIs are really "helper" ASIs for session based
    transports and not needed as interfaces between subsystems (which
    normally ASIs are used for). Or we might want to simply remove
    them and introduce them in the transport models that need them.

23: Page 28: Add a comment for the tmStateReference in the ASIs.

24: Page 29: Align the tmStateReference comment and mark it as (NEW).

25: Page 29: Remove duplicate colon.

26: Page 30:  Align the tmStateReference comment and mark it as (NEW).

27: Page 30: "5)The" -> "5) The"

28: Page 31: There is no use of tmsmStats so the definition should be
    removed and section 6.1.1 can be discarded.

29: Page 31: The name of the MIB module should be changed; all SNMP
    core module names start with SNMP- and so I suggest to call it
    SNMP-TRANSPORT-MIB.

30: Page 32: The imports need to be cleaned up and unsued stuff removed.

31: Page 33: The comment of the REVISION is wrong. I sugges to simply
    remove the comment.

32: Page 33: All core SNMP MIBs have traditionally been registered
    under snmpModules and I am not sure we want to break that
    tradition (if we do, we should make a deliberate choice). Note
    that the revised SNMP over Ethernet module went with the
    tradition...

33: Page 33: The SnmpTransportModel TC might become handy at some
    point in time but I note that so far this is not used by any
    definition.

34: Page 35: Do we need a counter for situations where the dispatcher
    has to call a transport model which does not exist?

35: Page 36: The text boilerplate text needs to be revised to match
    the actual MIB definitions. Should we also add text stating that
    the data referred to by tmStateReference must be kept in protected
    storage or is this obvious?

36: Page 37: Updated the MIB module name and the registration point
    to match points 29 and 32 above.

37: Page 38: Why are references [RFC4366] and [RFC2865] normative?

38: Page 39: Why are references [RFC3419] and [RFC4251] normative?

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms