|
Adding that extra explanation wuill be good
indeed.
Bert
----- Original Message -----
Sent: Monday, December 07, 2009 1:49
PM
Subject: RE: [Capwap] Could we close the
counter32 issue by this 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
>
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
|
bwijnen.net)