Re: [Isms] DISCUSS and COMMENT: draft-ietf-isms-transport-security-model

["David Harrington" <[e-mail]>]

Hi,

I am changing the sources with the requested changes.
comments inline

David Harrington
[e-mail]
[e-mail]
[e-mail]
 

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]] 
> Sent: Monday, May 04, 2009 9:44 AM
> To: [e-mail]
> Cc: [e-mail]; 
> [e-mail]
> Subject: DISCUSS and COMMENT: 
> draft-ietf-isms-transport-security-model 
> 
> 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.

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. 

> 
> Comment:
> Section 1.2
> Helpful if s/STD62/STD62 [RFC3411]/

I deliberately did not provide a reference to a specific RFC.
STD62 refers to 8 RFCs.
The terminology under discussion in section 1.2 is not limited to
RFC3411.
I think it is correct to just reference STD62 in this case without a
citation.

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

I will search out instances of lowercase may/should/must and either
make them RFC2119 compliant or change the word.

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

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

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

Yes, but a complete list would be distracting, and a moving target.

> 
> 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. 

done.
> 
> 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

done
> 
>