Capwap Mailing List: Re: The Status of the CAPWAP WG MIB issues

[Bert Wijnen \(IETF\) (bertietf]

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: capwap [at] frascone.com ; Black_David [at] emc.com ; 'Bert Wijnen (IETF)' ; elwynd [at] dial.pipex.com

Cc: yzhang [at] fortinet.com

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