Last Call: draft-ietf-isms-tmsm and
draft-ietf-isms-transport-security-model
Transport Subsystem for the Simple Network Management Protocol (SNMP)
1) Juergen commented MIB module names
RFC4181 recommenda a naming convention where the module name, module
identity, and prefixes are consistent:
- The module name should be of the form XXX-MIB (or XXX-TC-MIB for a
module with TCs only), where XXX is a unique prefix (usually all
caps with hyphens for separators) that is not used by any
existing
module. For example, the module for managing optical interfaces
[RFC3591] uses the prefix OPT-IF and has module name OPT-IF-MIB.
- The descriptor associated with the MODULE-IDENTITY invocation
should be of the form xxxMIB, xxxMib, or xxxMibModule, where xxx
is
a mixed-case version of XXX starting with a lowercase letter and
without any hyphens. For example, the OPT-IF-MIB uses the prefix
optIf, and the descriptor associated with its MODULE-IDENTITY
invocation is optIfMibModule.
- Other descriptors within the MIB module should start with the
same
prefix xxx. OPT-IF-MIB uses the prefix optIf for all
descriptors.
I don't think we should change SNMP-TSM-MIB to SNMP-TRANSPORT-SM-MIB.
I don't see significant benefit in this change.
I do not object to changing SSHTM-MIB to SNMP-SSHTM-MIB or
SNMPSSH-MIB.
> 3) Vijay Gurbani's Gen-ART review for tmsm:
> http://www.ietf.org/mail-archive/web/gen-art/current/msg03973.html
>
> One nit about white space/indentation -- will get fixed by
> the RFC editor when they assign the RFC numbers.
I believe this is related to the version of xml2rfc in use. It seems
to vary after xml2rfc upgrades. When the RFC Editor does their final
pass, it should be fine.
>
>
> 4) Ben Campbell's Gen-ART review for tsm:
> http://www.ietf.org/mail-archive/web/gen-art/current/msg03952.html
>
> Couple of editorial comments, all extremely minor. I'd suggest
> handling these during RFC Editor stage.
The "*" is part of the official name of the SNMPv2 variation.
reference to USM provided.
section 4.2 first two paragraphs ARE an ordered sequence - note that
3) follows a ways down in the procedures.
pointer to smi-registry provided for mib-2
removed open issues and change log sections
added pointer to secshell document for port assignment
>
>
> 5) Allison Mankin's transport directorate review for tmsm:
> http://www.ietf.org/mail-archive/web/isms/current/msg03490.html
> A top-level comment/question has to do with the draft's use of the
TDomain/TAddress textual convention from RFC 2579, instead of RFC
3419.
NEW:
This document uses TDomain textual conventions for the SNMP-internal
MIB modules defined here for compatibility with the RFC3413 MIB
modules and the RFC3411 Abstract Service Interfaces.
OLD:
with no significant effort...other than identifying requirements and
verifying the quality of service being provided.
NEW:
The individual therefore achieves the desired security, with
significantly less effort on his part except identifying
requirements and verifying the quality of service being provided.
reference for transport mappings added
OLD:
Transport Models MAY support sending multiple SNMP messages through
the same tunnel.
NEW:
While the Community Security Models and the User-based
Security Model establish a security association for each SNMP message,
newer Transport Models MAY support sending multiple SNMP messages
through the same tunnel to amortize the costs of establishing a
security association.
> This paragraph describes a heuristic to get around the fact that
"the transport subsystem does not have access to the pduType."
What do pduTypes include? What's a useful example of this hint
that makes this reversal worth including?
NEW:
... the transport subsystem does not have access to the pduType (i.e.,
the SNMP operation type) ...
NEW:
For example, the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB are used to
configure notification originators with the destination port to
which
SNMPv2-Trap PDUs or Inform PDUs should be sent, but the transport
subsystem never looks inside the PDU.
OLD:
The SNMPv3 WG decided that this should be a SHOULD architecturally,
and it is a security-model-specific decision whether to REQUIRE this.
NEW:
The SNMPv3 WG decided that this should be a SHOULD architecturally,
and it is a security-model-specific decision whether to REQUIRE this.
The architecture does not mandate this requirement to allow for future
security models where this might make sense, but not requiring this
could lead to added complexity and security vulnerabilities, so most
security models SHOULD require this.
Network stress discussion
NEW:
However, in times of network stress, a secure transport model may not
work
properly if its underlying security mechanisms (e.g., Network Time
Protocol (NTP) or Authentication, Authorization, and Accounting
(AAA) protocols or certificate authorities) are not reachable. The
User-based Security
Model was explicitly designed to not depend upon external network
services, and provides its own security services. It is RECOMMENDED
that operators provision authPriv USM as a fallback mechanism to
supplement
any security model or transport model that has external dependencies,
so that secure SNMP
communications can continue when the external network service is not
available.
snmpTCPDomain: I think such a domain should be registered when a model
is defined to use it.
>
> At least a reply reply is needed, and possibly some small
> clarifications. It's possible these could be handled by RFC Editor
> notes.
>
> David, can you reply and propose text?
>
>
> I hope we can get the RFC Editor notes to address Allison's comments
> soon, so I've placed these on the agenda of next Thursday's IESG
> telechat (April 23). If we don't have text by Monday,
> I'll move them to the next telechat (May 7th).
>
> Best regards,
> Pasi
>
>
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
