Subject: Re: [MIB-DOCTORS] Thanks for your guidance and quick response

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

OK, some advuise:

W: f(capwap-base.mi2), (851,17) Item "capwapBaseWtpStateWtpBaseMacAddress" should have SIZE specified

I then look at:
     capwapBaseWtpStateWtpBaseMacAddress  OBJECT-TYPE
          SYNTAX      PhysAddress
          MAX-ACCESS  read-only 
          STATUS      current
          DESCRIPTION
            "Represents the WTP's Base MAC Address, which MAY be
             assigned to the primary Ethernet interface."
          REFERENCE
            "Section 4.6.40. of CAPWAP Protocol Specification, RFC 5415."
          ::= { capwapBaseWtpStateEntry 4 }

Then I first get confused by the term "WtpBaseMacAddress, because I 
think of a 48 byte Etehrnet Mac addres. If I then read rfc5415, sect 4.6.30,
I then read there is a VendorID of 32 bits, and then a Board Data Subelement 
(of size 32 plus max 1024), then the min size seems to be 64, buit probably somewhat
more. The max length seems to be 64+1024 is 1088. But there is also talk about
the fact that there can be multiple subelements. It does not say how many.
So I am left very confused as to what the SIZE of the MIB object can be.

So.... I think it is very good that SMICng complained and warned that a SIZE
must be specified. It is up to the CAPWAP WG to define that SIZE, as I cannot
determin it from the cited paragraph in RFC5415.

W: f(capwap-base.mi2), (974,17) Item "capwapBaseWtpBaseMacAddress" should have SIZE specified

Same story/comment/questions/confusion

W: f(capwap-base.mi2), (2038,17) Item "capwapBaseNtfStationIdList" should have SIZE specified

Again, I cannot find what a reasonable SIZE would be. CAPWAP WG, pls think about
this and decide. The MAX length is 64K, but that will not be very sueful with SNMP.
You may want to make it (much) smaller.

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

The INDEX is as follows:

    INDEX {
      capwapBaseWtpCurrId,
      capwapBaseWirelessBindingRadioId,
      capwapBaseStationId
    }

The first one is the first index in another table
The second one is the 2nd index in yet another table
The 3rd one is an index (the 3rd one) in this table capwapBaseStaionTable.

That is indeed some sort of weird indexing. So that is why SMICng gives a warning.
It does not mean it is absolutely a fatal error. But it would be good that the CAPWAP
WG checks if this is indeed the indexing they intended and wanted. 

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

Here the index objects are:

    INDEX { capwapBaseWtpCurrId, capwapBaseWirelessBindingRadioId }

That loks better, but again the the 2nd index is a 2nd index object in another
table that gets added as the 2nd index here. Pls make sure this is what the
WG intends and wants and that the indexing makes sense.

For these "does not have a consistent indexing scheme" warnings, it would be good to add
some comment lines to the MIB module that explain why this indexing is OK/INTENDED.
Something like:

    -- The following indexing is intended because we want to show a table that
    -- ... here you text ...
    INDEX { capwapBaseWtpCurrId, capwapBaseWirelessBindingRadioId }

That way, when the SYNTAX check is done, and the MIB doctor checks the MIB module,
then he can see the explanation and see that the indexing is indeed intended and nit
inconsistent by accident.

More later

Bert

  ----- Original Message ----- 
  From: Bert (IETF) Wijnen 
  To: young 
  Sent: Monday, December 07, 2009 9:46 AM
  Subject: Re: Thanks for your guidance and quick response

  OK Richard,

  I will try to compose some advise tonight or Tuesday evening (European
  time).

  Bert

  young wrote:
  > Hi, Bert:
  >
  > Thanks for your guidance and quick response. 
  > David Perkins disappeared from the CAPWAP mailing list, and has not put
  > effort in the MIB drafts for some time. I guessed he is very busy with other
  > things.
  > I wonder when would he get back to IETF community? 
  > I have to ask your guidance and help.
  >
  > 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
  > *************************************
  >
  >
  >
  >
  >   

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

  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 23:18:14 +0100

>> So... what is the reason?

You point to RFC5415 sect 4..6.25, where I read:

   The ECN Support message element is sent by both the WTP and the AC to
   indicate their support for the Explicit Congestion Notification (ECN)
   bits, as defined in [RFC3168].

      0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |  ECN Support  |
     +-+-+-+-+-+-+-+-+

   Type:   53 for ECN Support

   Length:   1

   ECN Support:   An 8-bit value representing the sender's support for
      ECN, as defined in [RFC3168].  All CAPWAP Implementations MUST
      support the Limited ECN Support mode.  Full ECN Support is used if
      both the WTP and AC advertise the capability for "Full and Limited
      ECN" Support; otherwise, Limited ECN Support is used.

      0 -  Limited ECN Support

      1 -  Full and Limited ECN Support

So from that, I do not see why you could not change your enumeration at 1. 
Bit zero is not a zero value, and bit 1 is not a 1 value. They represent the
values 8 and 4, and so you have to convert them anyways to go into the 
MIB OBJECT. So I would RECOMMEND to do 

                   limited(1),
                   fullAndLimited(2)
                 }
     MAX-ACCESS  read-create
     STATUS      current

>         "Section 4.6.25. of CAPWAP Protocol Specification, RFC 5415."

See above!!!

Bert

---

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

more details/advise about my commet:

  > 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?
Section 7.2 of draft-ietf-capwap-base-mib-06.txt states that 
       The IF-MIB module is required to be supported on the AC.

So when I see a MODULE-COMPLIANCE, I would have expected something like:

capwapBaseCompliance MODULE-COMPLIANCE
   STATUS current
   DESCRIPTION
       "Describes the requirements for conformance to the
        CAPWAP-BASE-MIB module."

   MODULE  IF-MIB 
       MANDATORY-GROUPS {
            some mandatory groups from the IF-MIB, possibly all?
       }
   ... potentially some optional groups from IF-MIB as well?

   ... and then follow the MANDATORY GROUPS of THIS MODULE (the CAPWAP-BASE-MIB module)
  
   MODULE -- this module
     MANDATORY-GROUPS {
       capwapBaseAcNodeGroup,
       capwapBaseWtpProfileGroup,
       capwapBaseWtpStateGroup,
       capwapBaseWtpGroup,
       capwapBaseRadioGroup,
       capwapBaseStationGroup
     }

For an example, see RFC3811, but also RFC3289

But then, maybe if indeed the WHOLE IF-MIB MUST be supported, then just stating that
may be OK.

Bert

---

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

The explanation you give below )on the MAC address topic) is not the one
I can
see from the DESCRIPTION clause and the reference to the specific section
in the RFC5415. So You may need to update that a
little bit? And then add a size.

For all sizes, pls make sure that the WG agrees with it.
In fact that is true for all changes you make because of my comments.
I am just reviewing the MIB with a MIB-doctors eye. I am not someone
who can decide/overrule the CAPWAP WG decisions. So always make sure
that the WG agress with whatever changes you make.

Bert

young wrote:
>
> Hi, Bert:
>
> Please check my comments in line (under //////).
>
> Regards
>
> Richard
>
> -----邮件原件-----
> *发件人:* Bert Wijnen (IETF) [mailto:[email-masked]]
> *发送时间:* 2009年12月8日 6:12
> *收件人:* young
> *抄送:* MIB Doctors (E-mail); [email-masked]
> *主题:* Re: Thanks for your guidance and quick response
>
> OK, some advuise:
>
> [Bert]
>
> W: f(capwap-base.mi2), (851,17) Item
> "capwapBaseWtpStateWtpBaseMacAddress" should have SIZE specified
>
> I then look at:
>
> ////////////
> Yes, the size could be specified.
>
> I guest you misunderstood it. In fact, the
> capwapBaseWtpStateWtpBaseMacAddress
>
> is only corresponding to the " 4 - Base MAC Address" in the Board data
> （RFC5415）.
>
> According to the following text in the RFC5415，The MAC Address is
> EUI-48 [EUI-48] or EUI-64.
>
> CAPWAP implementations MUST support certificates where the common
>     name (CN) for both the WTP and AC is the MAC address of that device.
>     The MAC address MUST be encoded in the PrintableString format, using
>     the well-recognized MAC address format of 01:23:45:67:89:ab.  The CN
>     field MAY contain either of the EUI-48 [EUI-48] or EUI-64 [EUI-64]
>
> MAC Address formats.
>
> ////////////
> [Richard] same as above.
> ////////////
> [Richard] I discussed it with Yong, and suggest SIZE is 1024.
>
> //////
>
> I would check the following comments later.
>
>
>     *From:* Bert (IETF) Wijnen <mailto:[email-masked]>
>
>     *To:* young <mailto:[email-masked]>
>
>     *Sent:* Monday, December 07, 2009 9:46 AM
>
>     *Subject:* Re: Thanks for your guidance and quick response
>
>     OK Richard,
>
>     > 发件人: [email-masked]
>     <mailto:[email-masked]>
>     [mailto:[email-masked]]
>     > 发送时间: 2009年12月7日 6:33
>     > 收件人: [email-masked] <mailto:[email-masked]>
>     > [email-masked] <mailto:[email-masked]>
>     >
>     > [email-masked] <mailto:[email-masked]>
>     >
>     > [email-masked] <mailto:[email-masked]>
>     >
>     > From: Richard <[email-masked] <mailto:[email-masked]>>
>     > To: [email-masked] <mailto:[email-masked]>
>     > Cc: [email-masked] <mailto:[email-masked]>,
>     [email-masked] <mailto:[email-masked]>
>     > Message-ID:
>     > <[email-masked]
>     <mailto:[email-masked]>>
>     > From: "Bert Wijnen \(IETF\)" <[email-masked]
>     <mailto:[email-masked]>>
>     > To: "Richard" <[email-masked] <mailto:[email-masked]>>
>     > Cc: [email-masked] <mailto:[email-masked]>,
>     [email-masked] <mailto:[email-masked]>
>     > Message-ID: <3DDEC596F7704BD0A9F1E2EBB3F4CAC7@BertLaptop
>     <mailto:3DDEC596F7704BD0A9F1E2EBB3F4CAC7@BertLaptop>>
>     > To: [email-masked] <mailto:[email-masked]>
>     > Cc: [email-masked] <mailto:[email-masked]> ;
>     [email-masked] <mailto:[email-masked]>
>     ------------------------------------------------------------------------
>
>
>     Gecontroleerd door AVG - www.avg.com <http://www.avg.com>

---

From: young <[email-masked]>
Date: Tue, 08 Dec 2009 16:01:44 +0800

Hi, Bert:

       Regards

       Richard

-----邮件原件-----
发件人: Bert Wijnen (IETF) [mailto:[email-masked]] 
发送时间: 2009年12月8日 6:12
收件人: young
抄送: MIB Doctors (E-mail); [email-masked]
主题: Re: Thanks for your guidance and quick response

OK, some advuise:

[Bert]

W: f(capwap-base.mi2), (851,17) Item "capwapBaseWtpStateWtpBaseMacAddress"
should have SIZE specified

I then look at:

          MAX-ACCESS  read-only 
          STATUS      current
          DESCRIPTION

(of size 32 plus max 1024), then the min size seems to be 64, buit probably
somewhat

more. The max length seems to be 64+1024 is 1088. But there is also talk
about

must be specified. It is up to the CAPWAP WG to define that SIZE, as I
cannot

 ////////////

[Richard]

According to the following text in the RFC5415，The MAC Address is  EUI-48
[EUI-48] or EUI-64.

MAC Address formats.

W: f(capwap-base.mi2), (974,17) Item "capwapBaseWtpBaseMacAddress" should
have SIZE specified

////////////

 [Richard] same as above.

W: f(capwap-base.mi2), (2038,17) Item "capwapBaseNtfStationIdList" should
have SIZE specified

Again, I cannot find what a reasonable SIZE would be. CAPWAP WG, pls think
about

this and decide. The MAX length is 64K, but that will not be very sueful
with SNMP.

////////////

 

//////

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

The INDEX is as follows:

    INDEX {
      capwapBaseWtpCurrId,

That is indeed some sort of weird indexing. So that is why SMICng gives a
warning.

It does not mean it is absolutely a fatal error. But it would be good that
the CAPWAP

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

That loks better, but again the the 2nd index is a 2nd index object in
another

 

For these "does not have a consistent indexing scheme" warnings, it would be
good to add

some comment lines to the MIB module that explain why this indexing is
OK/INTENDED.

Something like:

    -- The following indexing is intended because we want to show a table
that

    -- ... here you text ...

That way, when the SYNTAX check is done, and the MIB doctor checks the MIB
module,

then he can see the explanation and see that the indexing is indeed intended
and nit

 

More later

Bert

----- Original Message ----- 

From: Bert (IETF) <mailto:[email-masked]>  Wijnen 

To: young <mailto:[email-masked]>  

OK Richard,

Bert

> achment.htm 

  _____  

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: young <[email-masked]>
Date: Tue, 08 Dec 2009 17:10:28 +0800

Hi, Bert:

I would do update the DESCRIPTION to make it clear.
Yes, in the end, I would post and list all the changes to be made,
Then WG could easily go through and make decision to the changes.
I would ask WG.

Regards
Richard

-----邮件原件-----
发件人: Bert (IETF) Wijnen [mailto:[email-masked]] 
发送时间: 2009年12月8日 16:47
收件人: young
抄送: 'Yong Zhang'; [email-masked]; [email-masked]
主题: Re: My(Richard) comments to the object size issues

Bert