| Re: [MIB-DOCTORS] Could we close the counter32 issue bythis way? | <– Date –> <– Thread –> |
From: David Harrington (ietfdbh comcast.net)
|
|
| Date: Mon, 7 Dec 2009 06:12:51 -0800 (PST) | |
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 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca [at] avaya.com] > Sent: Monday, December 07, 2009 9:04 AM > To: David Harrington; Bert (IETF) Wijnen; young > Cc: mib-doctors [at] ietf.org; capwap [at] frascone.com > Subject: 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 > > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh [at] comcast.net] > > Sent: Monday, December 07, 2009 3:50 PM > > To: Romascanu, Dan (Dan); 'Bert (IETF) Wijnen'; 'young' > > Cc: mib-doctors [at] ietf.org; capwap [at] frascone.com > > Subject: RE: [MIB-DOCTORS] [Capwap] Could we close the > > counter32 issue bythis way? > > > > 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 > > > > > -----Original Message----- > > > From: Romascanu, Dan (Dan) [mailto:dromasca [at] avaya.com] > > > Sent: Monday, December 07, 2009 8:33 AM > > > To: David Harrington; Bert (IETF) Wijnen; young > > > Cc: mib-doctors [at] ietf.org; capwap [at] frascone.com > > > Subject: RE: [MIB-DOCTORS] [Capwap] Could we close the > > > counter32 issue bythis way? > > > > > > 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 > > > > > > > > > > -----Original Message----- > > > > From: mib-doctors-bounces [at] ietf.org > > > > [mailto:mib-doctors-bounces [at] ietf.org] On Behalf Of David > > Harrington > > > > Sent: Monday, December 07, 2009 2:49 PM > > > > To: 'Bert (IETF) Wijnen'; 'young' > > > > Cc: mib-doctors [at] ietf.org; capwap [at] frascone.com > > > > 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 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:bertietf [at] bwijnen.net] > > > > > Sent: Monday, December 07, 2009 7:31 AM > > > > > To: young > > > > > Cc: mib-doctors [at] ietf.org; capwap [at] frascone.com > > > > > Subject: Re: [Capwap] Could we close the counter32 > issue by this > > > > way? > > > > > > > > > > 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:bertietf [at] bwijnen.net] > > > > > > 发送时间: 2009年12月7日 16:52 > > > > > > 收件人: young > > > > > > 抄送: mib-doctors [at] ietf.org; dromasca [at] avaya.com; > > > > capwap [at] frascone.com > > > > > > 主题: Re: Discuss the counter32 issue in the MIBs > > > > > > > > > > > > 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 > > > > > >> > > > > > >> -----邮件原件----- > > > > > >> 发件人: capwap-request [at] frascone.com > > > > > [mailto:capwap-request [at] frascone.com] > > > > > >> 发送时间: 2009年12月7日 6:33 > > > > > >> 收件人: capwap [at] frascone.com > > > > > >> 主题: Capwap Digest, Vol 49, Issue 3 > > > > > >> > > > > > >> Send Capwap mailing list submissions to > > > > > >> capwap [at] frascone.com > > > > > >> > > > > > >> 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 > > > > > >> capwap-request [at] frascone.com > > > > > >> > > > > > >> You can reach the person managing the list at > > > > > >> capwap-owner [at] frascone.com > > > > > >> > > > > > >> 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 <rishyang [at] gmail.com> > > > > > >> Subject: [Capwap] Please check my (Richard) > comments, thanks > > > > > >> To: bertietf [at] bwijnen.net > > > > > >> Cc: mib-doctors [at] ietf.org, capwap [at] frascone.com > > > > > >> Message-ID: > > > > > >> > > > <8556013e0912060519h345209d0r8790188d1c33a40a [at] mail.gmail.com> > > > > > >> 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/2009120 > > > > > 6/2d99dd44/att > > > > > > > > > > > >> achment.htm > > > > > >> > > > > > >> ------------------------------ > > > > > >> > > > > > >> Message: 2 > > > > > >> Date: Sun, 6 Dec 2009 23:32:17 +0100 > > > > > >> From: "Bert Wijnen \(IETF\)" <bertietf [at] bwijnen.net> > > > > > >> Subject: Re: [Capwap] Please check my (Richard) > > > comments, thanks > > > > > >> To: "Richard" <rishyang [at] gmail.com> > > > > > >> Cc: mib-doctors [at] ietf.org, capwap [at] frascone.com > > > > > >> Message-ID: <3DDEC596F7704BD0A9F1E2EBB3F4CAC7 [at] BertLaptop> > > > > > >> Content-Type: text/plain; charset="iso-8859-1" > > > > > >> > > > > > >> Inline > > > > > >> ----- Original Message ----- > > > > > >> From: Richard > > > > > >> To: bertietf [at] bwijnen.net > > > > > >> Cc: mib-doctors [at] ietf.org ; capwap [at] frascone.com > > > > > >> 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/2009120 > > > > > 6/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 > > > > > >> ************************************* > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yep > > > > > > > _________________________________________________________________ > > > > > To unsubscribe or modify your subscription options, please > > visit: > > > > > http://lists.frascone.com/mailman/listinfo/capwap > > > > > > > > > > Archives: http://lists.frascone.com/pipermail/capwap > > > > > > > > > > > > > _______________________________________________ > > > > MIB-DOCTORS mailing list > > > > MIB-DOCTORS [at] ietf.org > > > > https://www.ietf.org/mailman/listinfo/mib-doctors > > > > > > > > > > > >
- Re: Could we close the counter32 issue by this way?, (continued)
- Re: Could we close the counter32 issue by this way? David Harrington, December 7 2009
- Re: [MIB-DOCTORS] Could we close the counter32 issue bythis way? Romascanu, Dan (Dan), December 7 2009
- Re: [MIB-DOCTORS] Could we close the counter32 issue bythis way? David Harrington, December 7 2009
- Re: [MIB-DOCTORS] Could we close the counter32 issue bythis way? Romascanu, Dan (Dan), December 7 2009
- Re: [MIB-DOCTORS] Could we close the counter32 issue bythis way? David Harrington, December 7 2009
- Re: [MIB-DOCTORS] Could we close the counter32 issue bythis way? Romascanu, Dan (Dan), December 7 2009
- Re: [MIB-DOCTORS] Could we close the counter32 issue bythis way? Romascanu, Dan (Dan), December 7 2009
- [Couter32 issue] If it is ok, I would follow the Dan's suggestion young, December 7 2009
- Re: [Couter32 issue] If it is ok, I would follow the Dan's suggestion Bert (IETF) Wijnen, December 8 2009
Results generated by Tiger Technologies using MHonArc.