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

[Adrian Farrel <[e-mail]>]

Cleared.

There, that didn't hurt, did it?

Adrian
----- Original Message ----- 
From: "David Harrington" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; 
<[e-mail]>; <[e-mail]>
Sent: Tuesday, May 05, 2009 6:25 PM
Subject: RE: DISCUSS and COMMENT: draft-ietf-isms-transport-security-model


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