Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib

[Simon Perreault <[e-mail]>]

Le 2013-05-30 21:38, Dave Thaler a écrit :
>>> 4) The MIB compiler I used complained about this:
>>>> natMappingPool OBJECT-TYPE
>>>>       SYNTAX NatPoolId (0|1..4294967295)
>>> Because of
>>>> NatPoolId ::= TEXTUAL-CONVENTION
>>>>       SYNTAX Unsigned32 (1..4294967295)
>>>
>>> That is, NatPoolId does not allow 0, and so natMappingPool cannot add
>>> it and still use the NatPoolId syntax.
>>
>> Hmmmm... Would it be OK if I changed natMappingPool to an Unsigned32?
>>
>> natMappingPool OBJECT-TYPE
>>       SYNTAX Unsigned32 (0|1..4294967295)
>
> Yes, but you should remove the range restriction since that's the full range.
> So just
>          SYNTAX Unsigned32

Right. Removed.

> I see you added in the security considerations section:
>>       Note: This section only applies to objects with current status.
>>       For deprecated objects, please refer to the Security
>>       Considerations section from [RFC4008].
>
> However that doesn't make sense in my opinion unless we make RFC4008 a
> Normative (not informative) reference.   But I would prefer keeping it as
> an informative reference so it can be obsoleted.   So I disagree with the
> quoted limitation.

Hmmm... So what should we do instead? Keeping in mind that the security 
considerations in 4008 aren't up to today's standards.

a) Copy the security section verbatim from 4008. Add a preamble saying 
something like "These considerations apply to the deprecated elements. 
Others may apply, use at your own risk."

b) Create brand new security considerations for deprecated elements.

c) ???

Simon