Re: [pim] draft-ietf-pim-bsr-mib-05.txt [was: RE: [MIB-DOCTORS] FW: PRELIMINARY Agenda and Package for May 8, 2008 Telechat]

Bharat -

Pls post a new draft by Tues of next week (May 6, 2008) so that we  
can refer to the latest draft that contains fixes for all comments to  
date in the IESG telechat.

Thanks

-DWard

On May 2, 2008, at 11:00 AM, Bharat Joshi wrote:

>
> Hi Bert,
>
>     In this case, I would like to say that I can add "Zone index  
> zero is not valid in this table" similar to what is mentioned in IP  
> MCAST MIB. I can also add the range '(1..4294967295)' for these two  
> objects.
>
>     I shall wait for some more time if I get any more comments on  
> this draft and will publish another version after fixing this.
>
> Thanks,
> Bharat
>
>> -----Original Message-----
>> From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net]
>> Sent: Friday, May 02, 2008 4:45 PM
>> To: Romascanu, Dan (Dan); David Ward; Bharat Joshi; rainab@gmail.com
>> Cc: MIB Doctors; pim@ietf.org
>> Subject: RE: draft-ietf-pim-bsr-mib-05.txt [was: RE: [MIB-DOCTORS]  
>> FW:
>> PRELIMINARY Agenda and Package for May 8,2008 Telechat]
>>
>> The errors are shwon indeed when I use STRICT checking with SMICng.
>> As I stated, I can live with it.
>> But (as per the rfc4181 quoted text below), it would be good to
>> make it clear in the DESCRIPTION clause that zero is indeed
>> a valid value for the index. That was/is not clear to me from
>> the text in the DESCRIPTION clauses. For example
>>
>>    pimBsrElectedBSRZoneIndex OBJECT-TYPE
>>        SYNTAX     InetZoneIndex
>>        MAX-ACCESS not-accessible
>>        STATUS     current
>>        DESCRIPTION
>>                "The zone index uniquely identifies the zone on a
>>                device to which this Elected BSR is attached. There
>>                is one entry for each zone in ipMcastZoneTable.
>>                Scope-level information for this zone can be extracted
>>                from ipMcastZoneTable in IP MCAST MIB."
>>
>> It speaks about the "index uniquely identifies".
>> It referes to the IP MCAST MIB module.
>> In there I see a lot of places where it states:
>>             listener address applies only within the given zone.   
>> Zone
>>             index zero is not valid in this table."
>>
>> And also, when used as an index there, it DOES exclude zero:
>>
>>    ipMcastZoneIndex OBJECT-TYPE
>>        SYNTAX     InetZoneIndex (1..4294967295)
>>
>> So... If zero is value in the BSR MIB, then fine, but I would like  
>> to see
>> that made explicit, so that everyone is sure that it did not  
>> happen by
>> accident.
>>
>> The DESCRIPTION clause of InetZoneIndex states:
>>
>>          The zone index may contain the special value 0, which refers
>>          to the default zone.  The default zone may be used in cases
>>          where the valid zone index is not known (e.g., when a
>>          management application has to write a link-local IPv6
>>          address without knowing the interface index value).  The
>>          default zone SHOULD NOT be used as an easy way out in
>>          cases where the zone index for a non-global IPv6 address
>>          is known."
>>
>> So a zero valeu can mean "default zone" meaning that it is not known.
>> So is it a valid value?
>>
>> THe
>>
>>
>>
>> Bert Wijnen
>>
>>> -----Oorspronkelijk bericht-----
>>> Van: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
>>> Verzonden: vrijdag 2 mei 2008 13:00
>>> Aan: Bert Wijnen - IETF; David Ward; bharat_joshi@infosys.com;
>>> rainab@gmail.com
>>> CC: MIB Doctors; pim@ietf.org
>>> Onderwerp: RE: draft-ietf-pim-bsr-mib-05.txt [was: RE: [MIB- 
>>> DOCTORS] FW:
>>> PRELIMINARY Agenda and Package for May 8,2008 Telechat]
>>>
>>>
>>> Bert,
>>>
>>> Using libsmi the MIB module compiles cleanly.
>>>
>>> Is this again a case where smicng is more strict?  This may be  
>>> rather a
>>> warning case at worst and not an error case.
>>>
>>> As per RFC4181:
>>>
>>>    -   Unsigned32 with a range that excludes zero is RECOMMENDED for
>>>        most index objects.  It is acceptable to include zero in the
>>>        range when it is semantically significant or when it is  
>>> used as
>>>        the index value for a unique row with special properties.   
>>> Such
>>>        usage SHOULD be clearly documented in the DESCRIPTION clause.
>>>
>>> Assuming zero is a valid error and that a better explanation is  
>>> provided
>>> about the 'special case' in the DESCRIPTION I do not see a problem.
>>>
>>> Dan
>>>
>>>
>>>> -----Original Message-----
>>>> From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net]
>>>> Sent: Friday, May 02, 2008 12:56 PM
>>>> To: Romascanu, Dan (Dan); David Ward;
>>>> bharat_joshi@infosys.com; rainab@gmail.com
>>>> Cc: MIB Doctors; pim@ietf.org
>>>> Subject: draft-ietf-pim-bsr-mib-05.txt [was: RE:
>>>> [MIB-DOCTORS] FW: PRELIMINARY Agenda and Package for May
>>>> 8,2008 Telechat]
>>>>
>>>> W.r.t.
>>>>
>>>>>   o draft-ietf-pim-bsr-mib-05.txt
>>>>>     PIM Bootstrap Router MIB (Proposed Standard) - 3 of 11
>>>>>     Token: David Ward
>>>>
>>>> I get:
>>>>
>>>>   C:\bw\smicng\work>smicng bsr.inc
>>>>   E: f(bsr.mi2), (402,21) Index item "pimBsrCandidateBSRZoneIndex"
>>>>      must be defined with syntax that includes a range
>>>>   E: f(bsr.mi2), (541,21) Index item "pimBsrElectedBSRZoneIndex"
>>>>      must be defined with syntax that includes a range
>>>>
>>>>   *** 2 errors and 0 warnings in parsing
>>>>
>>>> The InetZoneIndex ::= TEXTUAL-CONVENTION from RFC4001 is the
>>>> SYNTAX for those 2 objects. And that TC does not include a range.
>>>>
>>>> The DESCRIPTION clause of the TC explains that value zero is
>>>> a special value. It iss unclear to me if that special value
>>>> of zero is a valid/acceptable value for the INDEX objects. If
>>>> not, then it might be good to use
>>>>
>>>>        SYNTAX     InetZoneIndex (1..4294967295)
>>>>
>>>> If it is a valid value, then I can live with the Error msg.
>>>> The error msg could still be suppressed by doing:
>>>>
>>>>        SYNTAX     InetZoneIndex (0..4294967295)
>>>>
>>>> And if you do so, then you explicitly indicate that zero is
>>>> indeed a valid value for the INDEX object.
>>>>
>>>> A NIT on the securitry Considerations:
>>>>
>>>>    Even if the network itself is secure (for example by using  
>>>> IPSec),
>>>>
>>>> s/IPSec/IPsec/
>>>>
>>>> I would not be urprised if Russ makes that comment too.
>>>>
>>>> Bert
>>>>
>>>>
>>>
>
> **************** CAUTION - Disclaimer *****************
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION  
> intended solely for the use of the addressee(s). If you are not the  
> intended recipient, please notify the sender by e-mail and delete  
> the original message. Further, you are not to copy, disclose, or  
> distribute this e-mail or its contents to any other person and any  
> such actions are unlawful. This e-mail may contain viruses. Infosys  
> has taken every reasonable precaution to minimize this risk, but is  
> not liable for any damage you may sustain as a result of any virus  
> in this e-mail. You should carry out your own virus checks before  
> opening the e-mail or attachment. Infosys reserves the right to  
> monitor and review the content of all messages sent to or from this  
> e-mail address. Messages sent to or from this e-mail address may be  
> stored on the Infosys e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***

_______________________________________________
pim mailing list
pim@ietf.org
https://www.ietf.org/mailman/listinfo/pim