Transport Security Model for the Simple Network Management Protocol (SNMP)
draft-ietf-isms-transport-security-model-14

[Ballot discuss]
Discuss was:

I am not a MIB expert, but when I see counters I wonder about wraps
and discontinuities. These seem not to be covered in this document
and I would like to hear from a MIB expert that this is OK.

I cleared when Dave Harrington said...

> I discussed this with some of the MIB Doctors.
> These counters should behave in the normal manner, as defined in
> rfc2578:
> 7.1.6.  Counter32
>
> The Counter32 type represents a non-negative integer which
> monotonically increases until it reaches a maximum value of 2^32-1
> (4294967295 decimal), when it wraps around and starts increasing
> again from zero.
>
> Counters have no defined "initial" value, and thus, a single value of
> a Counter has (in general) no information content.  Discontinuities
> in the monotonically increasing value normally occur at re-
> initialization of the management system, and at other times as
> specified in the description of an object-type using this ASN.1
> type.
>
> There are no anticipated discontinuities other than re-initialization
> of the management system.
>
> This behavior is consistent with other SNMP-system counters, such as
> those in the User-based Security Model.

[Ballot discuss]
I am not a MIB expert, but when I see counters I wonder about wraps
and discontinuities. These seem not to be covered in this document
and I would like to hear from a MIB expert that this is OK.

[Ballot comment]
Section 1.2
Helpful if s/STD62/STD62 [RFC3411]/

Section 1.5
You seem to fluctuate in your usage of RFC 2119 language.
In bullet 3, I suggest s/may not/might not/

Section 2.3.1
Notwithstanding the requirement to read the reference material, please
expand ASI on first use.

Section 3.1.2
"REQUIRES" is not in the RFC 2119 lexicon.

Section 3.1.3
"and other MIB modules" is a bit vague.

Section 3.1.3
  IANA maintains a registry for transport domains and the corresponding
  prefix.
Would be helpful to include a pointer (perhaps by registry name, or by
defining RFC) to this registry.

Section 7
Useful if FROM clauses can give a comment that shows the RFC that
defines the module from which the import is taken.
For example
FROM SNMPv2-SMI  -- RFC 2578

IANA comments:

Action 1:

Upon approval of this document, IANA will make the following
assignment in the "iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1)"
registry at
http://www.iana.org/assignments/smi-numbers

Decimal Name Description References
------- ---- ----------- ----------
[tbd] snmpTsmMIB The Transport Security Model MIB
[RFC-isms-transport-security-model-12]


Action 2:

Upon approval of this document, IANA will make the following
assignment in the "Security Models" registry at
http://www.iana.org/assignments/snmp-number-spaces

Value Description References
------ --------------------------------- ----------
[tbd(4)] Transport Security Model (TSM) [RFC-isms-transport-security-model-12]

We understand the above to be the only IANA Actions for this document.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Juergen Schoenwaelder is the document shepherd.

I have reviewed the document several times including the latest
version and I believe it is ready for forwarding to the IESG for
publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has gone through multiple WG last calls and has had over
time significant review by subject matter experts. I do not have any
concerns regarding the level of review for this document.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

I do not believe any extra special review (other than normal IETF Last
Call) is needed. The document, however, still needs a MIB doctor
review. Since the document is edited by MIB doctors, I do not expect
major problems here.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

I do not have any specific concerns.
No IPR disclosure been filed as far as we know.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The document has WG consensus and the WG wants the document to be
published as a Proposed Standard.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No-one has threatened with an appeal or expressed extreme discontent.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

The document passes ID-nits 2.10.03. The trust text in the MIB module
needs to be updated, pending the general resolution of this issue.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

References are split in Normative and Informative. All normative
references have been published or are submitted together with this
document to the IESG.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA section exists and seems to be complete.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

The MIB module contained in the document compiles cleanly with smilint
0.4.5.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

The document defines a Transport Security Model for the Simple
Network Management Protocol (SNMP) for use with secure
Transport Models in the Transport Subsystem. The document also
defines a portion of the Management Information Base (MIB) for
monitoring and managing the Transport Security Model for SNMP.

Working Group Summary

The document did stabilize several revisions ago and has
mainly been updated recently to track clarifications. There
has been WG consensus on revision 12 of this document and
there were no controversies on the technical solution since
the IETF meeting in Dublin.

Document Quality

There are two known implementations in progress of the
Transport Security Model. A concrete SSH subsystem has been
worked out by the ISMS working group and a DTLS subsystem is
in progress as an individual draft and it seems the Transport
Security Model defined in this document is capable to support
both secure transports.