Subject: [Capwap] Last Call: draft-ietf-capwap-base-mib (CAPWAP Protocol Base MIB) to Informational RFC

From: The IESG <[email-masked]>
Date: Mon, 23 Nov 2009 07:45:47 -0800 (PST)

The IESG has received a request from the Control And Provisioning of 
Wireless Access Points WG (capwap) to consider the following document:

- 'CAPWAP Protocol Base MIB '
   <draft-ietf-capwap-base-mib-06.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2009-12-07. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-capwap-base-mib-06.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17304&rfc_flag=0

_________________________________________________________________
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: Mon, 23 Nov 2009 22:37:40 +0100

SMICng (strict checking) tells me:

W: f(capwap-base.mi2), (851,17) Item "capwapBaseWtpStateWtpBaseMacAddress" should have SIZE specified
W: f(capwap-base.mi2), (974,17) Item "capwapBaseWtpBaseMacAddress" should have SIZE specified
W: f(capwap-base.mi2), (2038,17) Item "capwapBaseNtfStationIdList" should have SIZE specified
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
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

I am somewhat surprised to see the above warnings while David Perkins is listed on the front-page.

Further I see:

capwapBaseAcNameListRowStatus OBJECT-TYPE
    SYNTAX      RowStatus
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "This variable is used to create, modify, and/or delete a row
         in this table."
    ::= { capwapBaseAcNameListEntry 4 }

I thought that a RowStatus object MUST describe if and under which conditions
any writable (including read-create) objects can be modified if the row is Active?

The same holds true for some (all?) other RowStatus objects

Then I see:

capwapBaseWtpProfileWtpStaticIp OBJECT-TYPE
    SYNTAX      InetAddress
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "When capwapBaseWtpProfileWtpStaticIpEnable is true,
         it represents the static IP address to be assigned to the WTP."
    REFERENCE
        "Section 4.6.48. of CAPWAP Protocol Specification, RFC 5415."
    ::= { capwapBaseWtpProfileEntry 9 }

I thought that nay object of SYNTAX InetAddress MUST state in its DESCRIPTION
clause which object of SYNTAX InetAddressType specifies the format?
Further, it seems that "dns" is a valid InetAddressType. So in that case, the
DESCRIPTION clauses MUST explain when the dns name is resolved.
See RFC4001 for details.

Same question for various other objects of SYNATX InetAddress.

I see:

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 see:

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.

I wonder if there is a risk of sending too many notifications in a very short time?
IS there a way to control the rate of notifications?
If the risk does not exists, then maybe some words about that would be good.

In the MODULE-COMPLIANCE, I would have expected at least that some (or all) of
the IF-MIB module would also be mandatory???!!!

Bert WIjnen

  ----- Original Message ----- 
  From: The IESG 
  To: IETF-Announce 
  Cc: [email-masked] 
  Sent: Monday, November 23, 2009 4:45 PM
  Subject: Last Call: draft-ietf-capwap-base-mib (CAPWAP Protocol Base MIB) toInformational RFC

  _______________________________________________
  IETF-Announce mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/ietf-announce

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

  Geen virus gevonden in het binnenkomende-bericht.
  Gecontroleerd door AVG - www.avg.com 
  Versie: 9.0.709 / Virusdatabase: 270.14.78/2521 - datum van uitgifte: 11/23/09 08:52:00
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap