Subject: Re: [MIB-DOCTORS] The Status of the CAPWAP WG MIB issues

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

SMICng Syntax check is clea now except for the 21 awarnings about index.
AS we stated, that is OK... as long as explanation gets added.

I noticed:
capwapBaseAcNameListName OBJECT-TYPE
    SYNTAX      OCTET STRING(SIZE(512))
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "Represents the name of an AC, and it is expected to be
         an UTF-8 encoded string."
    REFERENCE
        "Section 4.6.5. of CAPWAP Protocol Specification, RFC 5415."
    ::= { capwapBaseAcNameListEntry 2 }

It seems weird to me (now taht I see this) that the size should be exact 512 octets ????
Did you mean max size 512 octets? There is probably a minimum size too?

And if it is UTF-8 , then it would be much better to use a proper UTF-8 syntax.
If you look here: http://ops.ietf.org/mib-common-tcs.html
you can find pointers/suggestions.

If the size needs to be 512, then LongUtf8String seems the one to choose (with a SIZE of course).

For this one
capwapBaseWtpProfileWtpStaticIpType OBJECT-TYPE
    SYNTAX      InetAddressType {ipv4(1), ipv4z(3)}
    MAX-ACCESS  read-create
    STATUS      current

I recommended to subtype, because ith is ONLY IPv4, AND because it is a
writable object.

This one
capwapBaseWtpProfileWtpStaticIp OBJECT-TYPE
    SYNTAX      InetAddress (SIZE(6|8))

Should be
capwapBaseWtpProfileWtpStaticIp OBJECT-TYPE
    SYNTAX      InetAddress (SIZE(4|8))

And for this one:
capwapBaseWtpStateWtpIpAddressType OBJECT-TYPE
    SYNTAX      InetAddressType {
                  ipv4(1),
                  ipv6(2),
                  ipv4z(3),
                  ipv6z(4),
                  dns(16)
                }
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Represents the IP address type of a WTP.
         Only ipv4(1), ipv6(2), ipv4z(3), ipv6z(4) and dns(16)
         are supported by the object."
    ::= { capwapBaseWtpStateEntry 2 }

I had not recommended to use the subtyping. There are 2 reasons:
- it basically supports everything (OK, except the unknown).
- it is read-only, so having all subtypes listed out is not needed
  as much as in a the case of a writable object. It is not incorrect however.

But this:
capwapBaseWtpStateWtpIpAddress OBJECT-TYPE
    SYNTAX      InetAddress (SIZE(4|8|16|20))
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Represents the IP address of a WTP.
         The format of this IP address is determined by
         the corresponding instance of object
         capwapBaseWtpStateWtpIpAddressType."
    ::= { capwapBaseWtpStateEntry 3 }

Seems wrong to me. a DNS name can be up to 255 characters I think.
In any case, it is often much longer than 20. I would not specify a size here.

I can live with your approach that rows must be made notInService, then changed, then set 
back to active. But it is somewhat of a burdon to a Network Management Station (application).
So I would think hard if it is really needed. Would it be allowed to just change some rows,
or some objects in a row while it is active? If such changes on an active row do not
jeopardize the service, then you might want to consider allowing that.

Bert

  ----- Original Message ----- 
  From: young 
  To: [email-masked] ; [email-masked] ; 'Bert Wijnen (IETF)' ; [email-masked] 
  Cc: [email-masked] 
  Sent: Monday, December 21, 2009 7:30 AM
  Subject: The Status of the CAPWAP WG MIB issues

  Hi, All:

  Till now, I got the review comments from David, Bert and Elwyn.
  The drafts text was updated according to the discussion in the mailing list.
  I already sent the updated drafts to the reviewer and ask them to confirm
  whether the changes are ok or not.

  There are few open issues left. Please remind me if I missed any one.
  1) 
  > Section 9 refers to a usage of
  > Message Element Extensions which a vendor can chose to implement or
  not.
  > It is not normative text and multi-vendor interoperability is not 
  > required.
  [Reviewer] The issue was raised by David.
  [Status] open

  2)
  > [*] I see lots of editorial problems in the text prior to the MIB 
  > definitions, most of which are not called out in this review. I 
  > strongly suggest an editorial pass by a native speaker of English 
  > prior to IESG Review.
  [Reviewer] The issue was raised by David.
  [Status] open

  3)
  > [*] Why is Section 9 (CAPWAP Message Element Extension) in a MIB 
  > draft?  MIB drafts generally do not make changes to the protocol that 
  > they provide management for.  This section, and the changes in Section 
  > 5.7 ought to be in a separate draft that could be standards track. 
  [Reviewer] The issue was raised by David.
  [Status] open

  4) 
  W: f(capwap-base.mi2), (1343,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), (1568,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
  [Reviewer] The issue was raised by Bert.
  [Editors] It needs more explain in the object's description 
  [Status] Richard and Yong are preparing text

  I believe the new drafts could be post soon once we have conclusion for all
  the
  Open issues.

  Regards
  Richard

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

  Geen virus gevonden in het binnenkomende-bericht.
  Gecontroleerd door AVG - www.avg.com 
  Versie: 9.0.717 / Virusdatabase: 270.14.116/2578 - datum van uitgifte: 12/20/09 20:35:00