Subject: [Capwap] Please check my (Richard) comments, thanks

From: Richard <[email-masked]>
Date: Sun, 6 Dec 2009 21:19:05 +0800

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
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Sun, 6 Dec 2009 23:32:17 +0100

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]

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!!!!!

  row"

  [Richard]
   Same as the above one.

same as above

  unless
  > 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."  

  "
  the
  > to have a specific meaning !!!!! This is impossible given the

NOPE, not acceptable. A Counter cannot have special values!!!!
See the descritpion of Counter32 in RFC2578!

  [Richard]
  It follows the RFC5415.

Nope, you CANNOT use a Counter32 for that, see RFC2578

  [Richard]

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

---

From: "David Harrington" <[email-masked]>
Date: Sun, 6 Dec 2009 19:03:46 -0500

Hi Richard,

"
the

dbh: a MIB Counter32 cannot have special values like this.
if the WTP doesn't have the information, then the implementation
should simply not support the MIB object.
(and I suppose, not be compliant to the MIB)
The SNMP application can convert the SNMP error code that the object
is not supported into the 65535 value for the protocol counter.

[Richard]

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! 
 
dbh: I recommend you move Dave Perkins' name to the acknowledgement
section since you have totally rewritten this MIB since David worked
on it.
dbh: I recommend you ask Dan Romascanu for a MIB Technical Advisor 
 
Bert

Regards
Richard