Subject: Re: [MIB-DOCTORS] Discuss the counter32 issue in the MIBs

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Mon, 07 Dec 2009 09:52:05 +0100

inline

young wrote:
> Hi, Bert:
>
> Thanks for you comments.
> I still have doubts  with the counter32 issue. 
> My latest comment is under "-------- [Richard]".
> Thanks for your comments.
>
>   > capwapBaseWtpEventsStatsInitCount OBJECT-TYPE
>   >     SYNTAX      Counter32
>   >     MAX-ACCESS  read-only
>   >     STATUS      current
>   >     DESCRIPTION
>   >         "Represents the number of reboots that have occurred at the
>   >          request of a CAPWAP protocol message, such as a change in
>   >          configuration that requires a reboot or an explicit CAPWAP
>   >          protocol reset request.  A value of 65535 implies that this
>   >          information is not available on the WTP."
>   >     REFERENCE
>   >         "Section 4.6.47. of CAPWAP Protocol Specification, RFC 5415.
>   "
>   >     ::= { capwapBaseWtpEventsStatsEntry 2 }
>   >
>   > I do not believe that a SYNTAX of Counter32 allows any value (like
>   the
>   > 65535)
>   > to have a specific meaning !!!!! This is impossible given the
>   > semantics for
>   > the
>   > Counter32 SYNTAX.
>   >
>   [Richard]
>   It follows the RFC5415.
>   How about update the text with:
>   According to the RFC 5415, a value of 65535 implies that this
>   information is not available on the WTP.
>
> [Bert]
> NOPE, not acceptable. A Counter cannot have special values!!!!
> See the descripion of Counter32 in RFC2578!
> ---------------------------
> [Richard]
> I checked the RFC2578, it says  "Counters have no defined "initial" value,
> and thus, a single value of a Counter has (in general) no information
> content. "
> RFC4181 talks about NOT OK  with "reset to zero or to any other specific
> value".
> Since, it is " in general " with RFC2578, could 
> We say " According to the RFC 5415, a value of 65535 implies that this
> information is not available on the WTP "?
> If it is not ok,
> Maybe the optional method is to:
> Add another two flag objects in the CapwapBaseWtpEventsStatsEntry to
> indicate
> whether the information for capwapBaseWtpEventsStatsRebootCount or 
> capwapBaseWtpEventsStatsInitCount is available or not on the WTP.
> The description of capwapBaseWtpEventsStatsRebootCount and
> capwapBaseWtpEventsStatsInitCount would not talk about " a value of 65535
> implies that this information is not available on the WTP " any more.
> Kindly let me know your opionion.
>
>   

Richard, The semantics of a Counter32 do NOT allow what you want to do.
I think if a WTP does not have the data, then it should just not
instantiate the
object. The problem then may be that the implementation cannot claim
compliance.
So be it.

If it is common that a certain class of WTPs cannot support this
counter, then
you could make it an object of an optional group. That way an implementation
can still claim compliance if it does not support this optional object
(or set of
optional objects).

Does this help?

Bert

> Regards
> Richard
>
> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 
> 发送时间: 2009年12月7日 6:33
> 收件人: [email-masked]
> 主题: Capwap Digest, Vol 49, Issue 3
>
> Send Capwap mailing list submissions to
> 	[email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.frascone.com/mailman/listinfo/capwap
> or, via email, send a message with subject or body 'help' to
> 	[email-masked]
>
> You can reach the person managing the list at
> 	[email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Capwap digest..."
>
>
> Today's Topics:
>
>    1. Please check my (Richard) comments, thanks (Richard)
>    2. Re: Please check my (Richard) comments, thanks
>       (Bert Wijnen (IETF))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 6 Dec 2009 21:19:05 +0800
> From: Richard <[email-masked]>
> Subject: [Capwap] Please check my (Richard) comments, thanks
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> Message-ID:
> 	<[email-masked]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi, Bert:
>
> Thanks for your comments.  Most comments are clear to me,
> while some of them need your guidance.
> Once I am clear, I would send out all the modification in details.
> Please check my comments identified by [Richard].
>
>   
>> W: f(capwap-base.mi2), (1293,7) Row "capwapBaseStationEntry"
>> does not have a
>> consistent indexing sche
>> me - cannot specify an index item from additional "base row"
>> capwapBaseWtpEntry, since can have only
>> one "base row" which is capwapBaseWirelessBindingEntry
>>     
>
> [Richard]
> I don't understand the problem. Kindly explain more and let me know
> how to fix it (if possiable).
>
>   
>> W: f(capwap-base.mi2), (1509,13) Row
>> "capwapBaseRadioEventsStatsEntry" does
>> not have a consistent ind
>> exing scheme - cannot specify an index item from additional "base
>>     
> row"
>   
>> capwapBaseWtpEntry, since can
>> have only one "base row" which is capwapBaseWirelessBindingEntry
>>     
> [Richard]
>  Same as the above one.
>
>
>   
>> capwapBaseWtpProfileWtpEcnSupport OBJECT-TYPE
>>     SYNTAX      INTEGER {
>>                   limited(0),
>>                   fullAndLimited(1)
>>                 }
>>     MAX-ACCESS  read-create
>>     STATUS      current
>>
>> Normally we recommend that ENUMERATIONS do NOT start with zero,
>>     
> unless
>   
>> there is a good reason (which we then like to see in the DESCRIPTION
>> clause).
>> So... what is the reason?
>>
>> Same question for: capwapBaseWtpDiscoveryType
>> And for: capwapBaseWtpEventsStatsLastFailureType
>> And possibly others!! pls check.
>>     
> [Richard]
> The enumeration in RFC5415 starts with zero.
> So how about the description updated in the following way?
> capwapBaseWtpProfileWtpEcnSupport OBJECT-TYPE
>     SYNTAX      INTEGER {
>                   limited(0),
>                   fullAndLimited(1)
>                 }
>     MAX-ACCESS  read-create
>     STATUS      current
>     DESCRIPTION
>         "Represents the support for the Explicit Congestion
> Notification
>          (ECN) bits, as defined in
> [RFC3168].
>          The following enumerated values are
> supported:
>            limited(0)        - Limited ECN
> support
>            fullAndLimited(1) - Full and limited ECN support
>          Since the enumeration in RFC5415 starts with zero, the MIB
>          object follow the same rule."
>     REFERENCE
>         "Section 4.6.25. of CAPWAP Protocol Specification, RFC 5415."
>
>
>   
>> capwapBaseWtpEventsStatsInitCount OBJECT-TYPE
>>     SYNTAX      Counter32
>>     MAX-ACCESS  read-only
>>     STATUS      current
>>     DESCRIPTION
>>         "Represents the number of reboots that have occurred at the
>>          request of a CAPWAP protocol message, such as a change in
>>          configuration that requires a reboot or an explicit CAPWAP
>>          protocol reset request.  A value of 65535 implies that this
>>          information is not available on the WTP."
>>     REFERENCE
>>         "Section 4.6.47. of CAPWAP Protocol Specification, RFC 5415.
>>     
> "
>   
>>     ::= { capwapBaseWtpEventsStatsEntry 2 }
>>
>> I do not believe that a SYNTAX of Counter32 allows any value (like
>>     
> the
>   
>> 65535)
>> to have a specific meaning !!!!! This is impossible given the
>> semantics for
>> the
>> Counter32 SYNTAX.
>>
>> Same for: capwapBaseWtpEventsStatsRebootCount
>> and possibly others, pls check and make sure.
>>     
>
> [Richard]
> It follows the RFC5415.
> How about update the text with:
> According to the RFC 5415, a value of 65535 implies that this
> information is not available on the WTP.
>
>   
>> In the MODULE-COMPLIANCE, I would have expected at least that
>> some (or all)
>> of
>> the IF-MIB module would also be mandatory???!!!
>>     
>
> [Richard]
> In fact, I don't understand why it is required?
> The ifGeneralInformationGroup in the IF-MIB module is mandatory, and
> The CAPWAP-BASE-MIB relies on the IF-MIB. There are no
> special requirement to the IF-MIB.
> Please let me know what should be done here?
>
> Regards
> Richard
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.frascone.com/pipermail/capwap/attachments/20091206/2d99dd44/att
> achment.htm 
>
> ------------------------------
>
> Message: 2
> Date: Sun, 6 Dec 2009 23:32:17 +0100
> From: "Bert Wijnen \(IETF\)" <[email-masked]>
> Subject: Re: [Capwap] Please check my (Richard) comments, thanks
> To: "Richard" <[email-masked]>
> Cc: [email-masked], [email-masked]
> Message-ID: <3DDEC596F7704BD0A9F1E2EBB3F4CAC7@BertLaptop>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Inline
>   ----- Original Message ----- 
>   From: Richard 
>   To: [email-masked] 
>   Cc: [email-masked] ; [email-masked] 
>   Sent: Sunday, December 06, 2009 2:19 PM
>   Subject: Please check my (Richard) comments, thanks
>
>
>   Hi, Bert:
>
>   Thanks for your comments.  Most comments are clear to me,
>   while some of them need your guidance.
>   Once I am clear, I would send out all the modification in details.
>   Please check my comments identified by [Richard].
>   > W: f(capwap-base.mi2), (1293,7) Row "capwapBaseStationEntry"
>   > does not have a
>   > consistent indexing sche
>   > me - cannot specify an index item from additional "base row"
>   > capwapBaseWtpEntry, since can have only
>   > one "base row" which is capwapBaseWirelessBindingEntry
>
>   [Richard]
>   I don't understand the problem. Kindly explain more and let me know 
>   how to fix it (if possiable). 
>
>
>
> The SMICng syntax checker is VERY strict on these things.
> If you are 100% sure you want to index as you do, then it may be OK.
> I advise to check with your co-editor/author David Perkins, who is
> also the author of SMICng!!!!!
>
>   > W: f(capwap-base.mi2), (1509,13) Row
>   > "capwapBaseRadioEventsStatsEntry" does
>   > not have a consistent ind
>   > exing scheme - cannot specify an index item from additional "base
>   row"
>   > capwapBaseWtpEntry, since can
>   > have only one "base row" which is capwapBaseWirelessBindingEntry
>
>   [Richard]
>    Same as the above one.
>
>
> same as above
>
>   > capwapBaseWtpProfileWtpEcnSupport OBJECT-TYPE
>   >     SYNTAX      INTEGER {
>   >                   limited(0),
>   >                   fullAndLimited(1)
>   >                 }
>   >     MAX-ACCESS  read-create
>   >     STATUS      current
>   >
>   > Normally we recommend that ENUMERATIONS do NOT start with zero,
>   unless
>   > there is a good reason (which we then like to see in the DESCRIPTION
>   > clause).
>   > So... what is the reason?
>   >
>   > Same question for: capwapBaseWtpDiscoveryType
>   > And for: capwapBaseWtpEventsStatsLastFailureType
>   > And possibly others!! pls check.
>
> I do no tfind the arguments strong, but I can live with it
>
>
>   [Richard]
>   The enumeration in RFC5415 starts with zero.
>   So how about the description updated in the following way?
>   capwapBaseWtpProfileWtpEcnSupport OBJECT-TYPE
>       SYNTAX      INTEGER {                                         
>                     limited(0),                                         
>                     fullAndLimited(1)
>
>                   }                                         
>       MAX-ACCESS  read-create                                         
>       STATUS      current                                         
>       DESCRIPTION                                          
>           "Represents the support for the Explicit Congestion Notification
>
>            (ECN) bits, as defined in [RFC3168].
>
>            The following enumerated values are supported:
>
>              limited(0)        - Limited ECN support
>
>              fullAndLimited(1) - Full and limited ECN support
>            Since the enumeration in RFC5415 starts with zero, the MIB 
>            object follow the same rule."                        
>       REFERENCE                                         
>           "Section 4.6.25. of CAPWAP Protocol Specification, RFC 5415."  
>           
>
>   > capwapBaseWtpEventsStatsInitCount OBJECT-TYPE
>   >     SYNTAX      Counter32
>   >     MAX-ACCESS  read-only
>   >     STATUS      current
>   >     DESCRIPTION
>   >         "Represents the number of reboots that have occurred at the
>   >          request of a CAPWAP protocol message, such as a change in
>   >          configuration that requires a reboot or an explicit CAPWAP
>   >          protocol reset request.  A value of 65535 implies that this
>   >          information is not available on the WTP."
>   >     REFERENCE
>   >         "Section 4.6.47. of CAPWAP Protocol Specification, RFC 5415.
>   "
>   >     ::= { capwapBaseWtpEventsStatsEntry 2 }
>   >
>   > I do not believe that a SYNTAX of Counter32 allows any value (like
>   the
>   > 65535)
>   > to have a specific meaning !!!!! This is impossible given the
>   > semantics for
>   > the
>   > Counter32 SYNTAX.
>   >
>
> NOPE, not acceptable. A Counter cannot have special values!!!!
> See the descritpion of Counter32 in RFC2578!
>
>   > Same for: capwapBaseWtpEventsStatsRebootCount
>   > and possibly others, pls check and make sure.
>
>   [Richard]
>   It follows the RFC5415.
>   How about update the text with:
>   According to the RFC 5415, a value of 65535 implies that this
>   information is not available on the WTP.
>
> Nope, you CANNOT use a Counter32 for that, see RFC2578
>
>   > In the MODULE-COMPLIANCE, I would have expected at least that
>   > some (or all)
>   > of
>   > the IF-MIB module would also be mandatory???!!!
>
>   [Richard]
>   In fact, I don't understand why it is required?
>   The ifGeneralInformationGroup in the IF-MIB module is mandatory, and
>   The CAPWAP-BASE-MIB relies on the IF-MIB. There are no
>   special requirement to the IF-MIB.
>   Please let me know what should be done here?
>
>
>
> I could try to work it out for you... 
> However, I am sure that you co-author, co-editor David Perkins knows what
> needs
> to be done!
>
> Bert
>
>   Regards
>   Richard
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.frascone.com/pipermail/capwap/attachments/20091206/986444a9/att
> achment.htm 
>
> ------------------------------
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap
>
> End of Capwap Digest, Vol 49, Issue 3
> *************************************
>
>
>
>
>

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Mon, 07 Dec 2009 13:30:52 +0100

Yep, if you remove that text, then I am happy with it in this case.

Bert

young wrote:
> Hi, Bert:
>
> Thanks. 
> Since the capwapBaseWtpEventsStatsRebootCount and 
> capwapBaseWtpEventsStatsInitCount already in a optional group
> (capwapBaseWtpEventsStatsGroup), what changes should be done is just to
> remove the text " A value of 65535 implies that this information is not
> available on the WTP" in the either object's description. 
>
> I think no other changes are required.
> Wish this way is correct.
>
> Regards
> Richard
>
> -----邮件原件-----
> 发件人: Bert (IETF) Wijnen [mailto:[email-masked]] 
> 发送时间: 2009年12月7日 16:52
> 收件人: young
> 抄送: [email-masked]; [email-masked]; [email-masked]
> 主题: Re: Discuss the counter32 issue in the MIBs
>
> inline
>
>
> young wrote:
>   
>> Hi, Bert:
>>
>> Thanks for you comments.
Yep

---

From: "David Harrington" <[email-masked]>
Date: Mon, 7 Dec 2009 07:49:28 -0500

Hi,

Since Richard decided that the approrpriate way to handle this 65535
value called for by RFC5415 was to put it into the MIB counter, I
suspect other implementers could reach a similar conclusion and
implement it with the special value.

I recommend removing the text from the objectthat says to use 65535 as
a special value, but to add text that says it is inappropriate to
implement this special value semantics, and if the WTP does not have
this information, it should not instantiate the object. Since MIB
modules are frequently distributed without the surrounding RFC text, I
think this advisory should be in the MIB module itself, not in a
separate implementer guidelines section.

As an alternative, a new datatype could be defined (in a TC) that
supported counter behavior, but also allowed for special value
semantics like this. If the WG chooses this approach, they should
definitely have a MIB Doctor involved to design this. I don't really
recommend this approach because existing SNMP tools will not know how
to work with this new datatype, and the goal of the SMI, SNMP, and
standard MIB modules is to standardize the handling of monitoring
data.

dbh

> -----Original Message-----
> From: Bert (IETF) Wijnen [mailto:[email-masked]] 
> Sent: Monday, December 07, 2009 7:31 AM
> To: young
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Capwap] Could we close the counter32 issue by this
way?

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 7 Dec 2009 14:33:20 +0100

I agree - this was actually my reading of taking out the 'special 65535 use'  and making the counters part of an optional group. 

A new TC is not a good idea. 

Dan

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David Harrington
> Sent: Monday, December 07, 2009 2:49 PM
> To: 'Bert (IETF) Wijnen'; 'young'
> Subject: Re: [MIB-DOCTORS] [Capwap] Could we close the 
> counter32 issue bythis way?
> 
> Hi,
> 
> Since Richard decided that the approrpriate way to handle 
> this 65535 value called for by RFC5415 was to put it into the 
> MIB counter, I suspect other implementers could reach a 
> similar conclusion and implement it with the special value.
> 
> I recommend removing the text from the objectthat says to use 
> 65535 as a special value, but to add text that says it is 
> inappropriate to implement this special value semantics, and 
> if the WTP does not have this information, it should not 
> instantiate the object. Since MIB modules are frequently 
> distributed without the surrounding RFC text, I think this 
> advisory should be in the MIB module itself, not in a 
> As an alternative, a new datatype could be defined (in a TC) 
> that supported counter behavior, but also allowed for special 
> value semantics like this. If the WG chooses this approach, 
> they should definitely have a MIB Doctor involved to design 
> this. I don't really recommend this approach because existing 
> SNMP tools will not know how to work with this new datatype, 
> and the goal of the SMI, SNMP, and standard MIB modules is to 
> standardize the handling of monitoring data.
> 
> dbh
> 
> > >> Since, it is " in general " with RFC2578, could We say " 
> According 
> > >> to the RFC 5415, a value of 65535
> > implies that this
> > > instantiate the object. The problem then may be that the 
> > > implementation cannot
> claim
> > > compliance.
> > > So be it.
> > >
> > > counter, then you could make it an object of an optional 
> group. That 
> > > way
> > an implementation
> > >> Thanks for your comments.  Most comments are clear to me, while 
> > >> some of them need your guidance.
> > >>> capwapBaseWtpEntry, since can have only one "base row" which is 
> > >>> capwapBaseWirelessBindingEntry
> > >>>     
> > >>>       
> > >> [Richard]
> > >>> "capwapBaseRadioEventsStatsEntry" does not have a 
> consistent ind 
> > >>> Same question for: capwapBaseWtpDiscoveryType And for: 
> > >>> capwapBaseWtpEventsStatsLastFailureType
> > >>> semantics for the
> > >>> In the MODULE-COMPLIANCE, I would have expected at 
> least that some 
> > >>> (or all) of the IF-MIB module would also be mandatory???!!!
> > >>>     
> > >>>       
> > >> [Richard]
> > >> The CAPWAP-BASE-MIB relies on the IF-MIB. There are no special 
> > >> requirement to the IF-MIB.
> > >> -------------- next part -------------- An HTML attachment was 
> > >> scrubbed...
> > >> URL:
> > >>
> > >>     
> > > 
> > >> -------------- next part -------------- An HTML attachment was 
> > >> scrubbed...
> > >> URL:
> > >>
> > >>     
> > > 
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors
>

---

From: "David Harrington" <[email-masked]>
Date: Mon, 7 Dec 2009 08:50:05 -0500

Hi,

I think that reading would be incomplete.
You really need to look at RFC5415, where there is a counter defined
in the **protocol** which uses the 65535 value as a special value
indicating the information is not available. The CAPWAP protocol does
nto say "if you dont have the information available then do not
instantiate the protocol counter." Instead it uses a different
approach - always instantiate the protocol counter, but return a
special value value that in effect says "the WTP doesn't instantiate
the corresponding counter functionality."

A MIB object representing that protocol counter cannot be implemented
with the same semantics as the protocol counter because a counter32
does not support special value semantics.
Unless you really understand counter32 semantics, it could be easy to
assume the capwap mib object representing that protocol counter would
have comparable semantics.
I think an explicit warning is needed to implementers that such an
assumption would be wrong, and that the instantiation semantics and
content semantics of the protocol counter and the MIB counter differ.

dbh

> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Monday, December 07, 2009 8:33 AM
> To: David Harrington; Bert (IETF) Wijnen; young
> Subject: RE: [MIB-DOCTORS] [Capwap] Could we close the 
> I agree - this was actually my reading of taking out the 
> 'special 65535 use'  and making the counters part of an 
> optional group. 
> 
> > > >> whether the information for
capwapBaseWtpEventsStatsRebootCount
> > or 
> > > >> I don't understand the problem. Kindly explain more and let
me
> > know
> > > >>          Since the enumeration in RFC5415 starts with zero,
the
> > MIB
> > > >>>          request of a CAPWAP protocol message, such 
> as a change
> > in

> > > >> The CAPWAP-BASE-MIB relies on the IF-MIB. There are no
special 
> > > >> I advise to check with your co-editor/author David Perkins,
who
> > is
> least that

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 7 Dec 2009 15:03:41 +0100

I know what 5415 says, it's a different protocol and I would actually think that the behavior in an agent that implements a MIB module is consistent with SMIv2 semantics and practice. I understand however the concern, and I agree that explicit warning text can help.  For example we can add in the DESCRIPTION clause of the counters the following: 'Note that the CAPWAP field modeled by this counter takes the value 65535 as a 
To indicate that the information is not available. This MIB object does not follow this behavior which would not be standard in SMIv2. If the WTP does not have the information, the agent will instantiate the object.'

Dan

> From: David Harrington [mailto:[email-masked]] 
> Sent: Monday, December 07, 2009 3:50 PM
> To: Romascanu, Dan (Dan); 'Bert (IETF) Wijnen'; 'young'
> You really need to look at RFC5415, where there is a counter 
> defined in the **protocol** which uses the 65535 value as a 
> special value indicating the information is not available. 
> The CAPWAP protocol does nto say "if you dont have the 
> information available then do not instantiate the protocol 
> counter." Instead it uses a different approach - always 
> instantiate the protocol counter, but return a special value 
> value that in effect says "the WTP doesn't instantiate the 
> corresponding counter functionality."
> 
> A MIB object representing that protocol counter cannot be 
> implemented with the same semantics as the protocol counter 
> because a counter32 does not support special value semantics.
> Unless you really understand counter32 semantics, it could be 
> easy to assume the capwap mib object representing that 
> protocol counter would have comparable semantics.
> I think an explicit warning is needed to implementers that 
> such an assumption would be wrong, and that the instantiation 
> semantics and content semantics of the protocol counter and 
> the MIB counter differ.
> 
> dbh
> 
> > I agree - this was actually my reading of taking out the 'special 
> > 65535 use'  and making the counters part of an optional group.
> > 
> this 65535 
> > > inappropriate to implement this special value semantics, 
> and if the 
> > > WTP does not have this information, it should not instantiate the 
> > > object. Since MIB modules are frequently distributed without the 
> > > surrounding RFC text, I think this advisory should be in the MIB 
> > > module itself, not in a separate implementer guidelines section.
> > > 
> > > recommend this approach because existing SNMP tools will not know 
> > > how to work with this new datatype, and the goal of the 
> SMI, SNMP, 
> > > and standard MIB modules is to standardize the handling of 
> > > monitoring data.
> > > 
> > > dbh
> > >

---

From: "David Harrington" <[email-masked]>
Date: Mon, 7 Dec 2009 09:12:48 -0500

Hi,

I assume the following was a typo:
s/the agent will instantiate the object/the agent will not instantiate
the object/

Such a statement in the description clause would satisfy my concerns.

dbh

> Sent: Monday, December 07, 2009 9:04 AM
> I know what 5415 says, it's a different protocol and I would 
> actually think that the behavior in an agent that implements 
> a MIB module is consistent with SMIv2 semantics and practice. 
> I understand however the concern, and I agree that explicit 
> warning text can help.  For example we can add in the 
> DESCRIPTION clause of the counters the following: 'Note that 
> the CAPWAP field modeled by this counter takes the value 65535 as a 
> To indicate that the information is not available. This MIB 
> object does not follow this behavior which would not be 
> standard in SMIv2. If the WTP does not have the information, 
> the agent will instantiate the object.'
> 
> Dan
> 
> 
'special 

> > > > > >>   >          request of a CAPWAP protocol message, such
as 
> > > > > a change in
> > > > > >>   > I do not believe that a SYNTAX of Counter32 allows
any
> > > > > value (like
> > > > > >>   According to the RFC 5415, a value of 65535 implies
that
> > this
> > > > > >> capwapBaseWtpEventsStatsInitCount would not talk about "
a
> > > > > value of 65535
> > > > > > Richard, The semantics of a Counter32 do NOT allow what
you
> > > > > want to do.
> > > > > >> When replying, please edit your Subject line so it is
more
> > > > specific
> > > > > >>> exing scheme - cannot specify an index item from 
> additional
> > > > "base
> > > > > >>>     
> > > > > >>>       
> > > > > >> row"
> > > > > >>   
> > > > > >>     
> > > > > >>         "Section 4.6.25. of CAPWAP Protocol
Specification,
> > > > > RFC 5415."
> > > > > >>> I do not believe that a SYNTAX of Counter32 
> allows any value
> > > > (like
> > > > > >>>     
> > > > > >>>       
> > > > > >> the
> > > > > >>   
> > > > > >>     
> > > > > >>> 65535)
> > > > > >>> to have a specific meaning !!!!! This is impossible
given
> > > > > >> -------------- next part -------------- An HTML
attachment
> > was 
http://lists.frascone.com/pipermail/capwap/attachments/2009120
> > > > > 6/2d99dd44/att
> > > > > >>   > Normally we recommend that ENUMERATIONS do NOT 
> start with
> > > > zero,
> > > > > >>   unless

> > > > > >>   >          request of a CAPWAP protocol message, such
as 
> > > > > a change in
> > > > > >>   > I do not believe that a SYNTAX of Counter32 allows
any
> > > > > value (like
> > > > > >>   According to the RFC 5415, a value of 65535 implies
that
> > this
> > > > > >> -------------- next part -------------- An HTML
attachment
> > was 
http://lists.frascone.com/pipermail/capwap/attachments/2009120
> > > > > 6/986444a9/att

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 7 Dec 2009 15:13:46 +0100

Of course 

> s/the agent will instantiate the object/the agent will not 
> instantiate the object/

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 7 Dec 2009 15:15:43 +0100

Also 

s/as a To indicate/ to indicate/ 

> From: Romascanu, Dan (Dan) 
> Sent: Monday, December 07, 2009 4:14 PM
> To: 'David Harrington'; 'Bert (IETF) Wijnen'; 'young'
> instantiate

---

From: young <[email-masked]>
Date: Mon, 07 Dec 2009 15:51:22 +0800

Hi, Bert:

Thanks for you comments.

  "
  the
  [Richard]
  It follows the RFC5415.

[Bert]

Regards
Richard

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2009年12月7日 6:33
收件人: [email-masked]
主题: Capwap Digest, Vol 49, Issue 3

Today's Topics:

Message: 1

Hi, Bert:

[Richard]

row"
[Richard]
 Same as the above one.

unless
[Richard]

"
the

[Richard]
It follows the RFC5415.

[Richard]

Regards
Richard
-------------- next part --------------

Message: 2

Inline
  ----- Original Message ----- 
  From: Richard 
  To: [email-masked] 
  Cc: [email-masked] ; [email-masked] 
  Sent: Sunday, December 06, 2009 2:19 PM
  Subject: Please check my (Richard) comments, thanks

  Hi, Bert:

  [Richard]

  row"

  [Richard]
   Same as the above one.

same as above

  unless

  [Richard]

                  }                                         
      MAX-ACCESS  read-create                                         
      STATUS      current                                         
      DESCRIPTION                                          

  "
  the

  [Richard]
  It follows the RFC5415.

  [Richard]

Bert

  Regards
  Richard

---

From: young <[email-masked]>
Date: Mon, 07 Dec 2009 17:26:38 +0800

Hi, Bert:

Thanks. 

Regards
Richard

-----邮件原件-----
发件人: Bert (IETF) Wijnen [mailto:[email-masked]] 
发送时间: 2009年12月7日 16:52
收件人: young
抄送: [email-masked]; [email-masked]; [email-masked]
主题: Re: Discuss the counter32 issue in the MIBs

inline

Does this help?

Bert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 7 Dec 2009 19:16:16 +0100

On Mon, Dec 07, 2009 at 08:51:22AM +0100, young wrote:

> -----????????-----
> ??????: [email-masked] [mailto:[email-masked]]
> ????????: 2009??12??7?? 6:33
> ??????: [email-masked]
> ????: Capwap Digest, Vol 49, Issue 3
> 

If a Counter has the special value then it is ambiguous whether the
number is a special value or a normal counter value. Generic SNMP
tools will treat a Counter32 as a Counter32 and not pay any attention
to special values. If the Counter32 does not exist, then the best
thing is to nor report that objects - every decent SNMP tool should be
able to deal with this nicely.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 7 Dec 2009 11:53:02 -0800

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "young" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Monday, December 07, 2009 10:16 AM
> Subject: Re: [MIB-DOCTORS] Discuss the counter32 issue in the MIBs
...
> able to deal with this nicely.
...

Agreed, but...

For the manager, this situation is indistinguishable from that Counter
having been made inaccessible due to access control.  If they really
really really need to unambiguously represent this special case, I'd
suggest adding an object with a syntax of TruthValue to explicitly
represent the condition.

If there are a whole bunch of them, one might use a single BITS object,
with one bit for each piece of data for which the condition can occur.

Randy

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Mon, 7 Dec 2009 22:18:34 +0100

Inline
  ----- Original Message ----- 
  From: Randy Presuhn 
  To: young 
  Cc: [email-masked] ; [email-masked] 
  Sent: Monday, December 07, 2009 8:53 PM
  Subject: Re: [MIB-DOCTORS] Discuss the counter32 issue in the MIBs

  Hi -

  ...
  ...

  Agreed, but...

And of that truthValue object were also inaccessible?

Can't win on that one I think.

Bert

  Randy

------------------------------------------------------------------------------

  Geen virus gevonden in het binnenkomende-bericht.
  Gecontroleerd door AVG - www.avg.com 
  Versie: 9.0.709 / Virusdatabase: 270.14.97/2550 - datum van uitgifte: 12/07/09 08:33:00

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Mon, 7 Dec 2009 22:15:38 +0100

Adding that extra explanation wuill be good indeed.

Bert
  ----- Original Message ----- 
  From: David Harrington 
  To: 'Bert (IETF) Wijnen' ; 'young' 
  Cc: [email-masked] ; [email-masked] 
  Sent: Monday, December 07, 2009 1:49 PM
  Subject: RE: [Capwap] Could we close the counter32 issue by this way?

  Hi,

  dbh

  way?
  > additional "base

  > Specification, RFC 5415."  
  > >>           
  > >>

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 7 Dec 2009 14:11:02 -0800

Hi -

> From: "Bert Wijnen (IETF)" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; "young" <[email-masked]>
> Sent: Monday, December 07, 2009 1:18 PM
...
...

It's a little better than a total loss.  :-)

If you retrieved the Counters, and the TruthValue wasn't
there, you would *know* that you didn't know whether the
Counter values are legitimate, and that the probable cause
would almost certainly have been a quirky access control
policy.

With a "don't instantiate" policy, it's always ambiguous.

Randy

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Tue, 08 Dec 2009 09:34:58 +0100

works for me.

Bert

young wrote:
> Hi, All:
>
> If it is ok, I would follow the Dan's suggestion. 
> The new text would be:
> capwapBaseWtpEventsStatsRebootCount OBJECT-TYPE
>     SYNTAX      Counter32
>     MAX-ACCESS  read-only
>     STATUS      current
>     DESCRIPTION
>         "Represents the number of reboots that have occurred due to a
>          WTP crash. 
>          Note that the CAPWAP field [RFC 5415] modelled by this counter 
>          takes the value 65535 to indicate that the information is not
> available
>          on the WTP. This MIB object does not follow this behaviour which 
>          would not be standard in SMIv2. If the WTP does not have the
> information, 
>         the agent will not instantiate the object."
>     REFERENCE
>         "Section 4.6.47. of CAPWAP Protocol Specification, RFC 5415."
>     ::= { capwapBaseWtpEventsStatsEntry 1 }
>
> Same change would be done to the capwapBaseWtpEventsStatsInitCount.
>
> Regards
> Richard
>
>

---

From: young <[email-masked]>
Date: Tue, 08 Dec 2009 11:34:58 +0800

Hi, All:

Regards
Richard

-----邮件原件-----
发件人: Romascanu, Dan (Dan) [mailto:[email-masked]] 
发送时间: 2009年12月7日 22:04
收件人: David Harrington; Bert (IETF) Wijnen; young
抄送: [email-masked]; [email-masked]
主题: RE: [MIB-DOCTORS] [Capwap] Could we close the counter32 issue bythis
way?

I know what 5415 says, it's a different protocol and I would actually think
that the behavior in an agent that implements a MIB module is consistent
with SMIv2 semantics and practice. I understand however the concern, and I
agree that explicit warning text can help.  For example we can add in the
DESCRIPTION clause of the counters the following: 'Note that the CAPWAP
field modeled by this counter takes the value 65535 as a 
To indicate that the information is not available. This MIB object does not
follow this behavior which would not be standard in SMIv2. If the WTP does
not have the information, the agent will instantiate the object.'

Dan