Subject: [Capwap] The Status of the CAPWAP WG MIB issues

From: young <[email-masked]>
Date: Mon, 21 Dec 2009 14:30:59 +0800

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

_________________________________________________________________
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, 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:

  not.

  2)

  3)

  4) 

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

---

From: young <[email-masked]>
Date: Mon, 21 Dec 2009 19:47:35 +0800

Hi, Bert:

     Ok, there are two issues keep open 

1)      Index

2)      RowStatus

Check my comments inline.

-----邮件原件-----
发件人: Bert Wijnen (IETF) [mailto:[email-masked]] 
发送时间: 2009年12月21日 17:23
收件人: young; [email-masked]; [email-masked];
[email-masked]
抄送: [email-masked]
主题: Re: The Status of the CAPWAP WG MIB issues

I noticed:

It seems weird to me (now taht I see this) that the size should be exact 512
octets ????

And if it is UTF-8 , then it would be much better to use a proper UTF-8
syntax.

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

[Richard]

Oh, a mistake. It should be OCTET STRING (SIZE(1..512))  for
capwapBaseAcNameListName.

The capwapBaseWtpProfileWtpName and capwapBaseWtpProfileWtpLocation need
changes.

    capwapBaseWtpProfileWtpName  OBJECT-TYPE

       SYNTAX      OCTET STRING (SIZE(1..512))

capwapBaseWtpProfileWtpLocation  OBJECT-TYPE

       SYNTAX      OCTET STRING (SIZE(1..1024))

For this one

writable object.

 [Richard] Yes

This one

Should be

  [Richard]  Yes

And for this one:

  as much as in a the case of a writable object. It is not incorrect
however.

   [Richard]  

   Ok, no subtyping list required here. I am clear this time.

But this:

In any case, it is often much longer than 20. I would not specify a size
here.

   [Richard]  

   Ok, no subtyping list required 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

[Richard]

Yes, Before I sent out the new draft, I was hesitating here whether should
give more flexibility to NMS..

 OK, I would give an answer tomorrow.

Bert

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

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

To: [email-masked] ; [email-masked] ; 'Bert Wijnen
<mailto:[email-masked]>  (IETF)' ; [email-masked] 

Cc: [email-masked] 

Hi, All:

not.

2)

3)

4) 

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

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Mon, 21 Dec 2009 13:31:13 +0100

Richard, thanks for your responses.

Still one comment:

young wrote:
> The capwapBaseWtpProfileWtpName and capwapBaseWtpProfileWtpLocation
> need changes.
>

OK, that is good for the SIZE (although 1 seems very short. But that is
what the RFC5415
specifies, so fine). But RFC5415 slaso states that it is a UTF-8 string,
ans so does your
DESCRITPION clause. So I would STRONGLY recommend to use longUtf8String
as the
SYNTAX. You have to import it from the SYSAPPL-MIB [RFC2287]: Or, if you
do not
want to epend on that RFC, then define a UTF-8 based TC yourself. That
is to say,
I would prefer a UTF-8 based TC as SYNTAX over a OCTET-STRING.
OCTET STRING is not strictly an error though, so if the WG really wants
to keep
that, then pls check with yoru AD if he is OK with that.

Bert

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 21 Dec 2009 14:08:41 +0100

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

> OK, that is good for the SIZE (although 1 seems very short. 
> But that is what the RFC5415 specifies, so fine). But RFC5415 
> slaso states that it is a UTF-8 string, ans so does your 
> DESCRITPION clause. So I would STRONGLY recommend to use 
> longUtf8String as the SYNTAX. You have to import it from the 
> SYSAPPL-MIB [RFC2287]: Or, if you do not want to epend on 
> that RFC, then define a UTF-8 based TC yourself. That is to 
> say, I would prefer a UTF-8 based TC as SYNTAX over a OCTET-STRING.
> OCTET STRING is not strictly an error though, so if the WG 
> really wants to keep that, then pls check with yoru AD if he 
> is OK with that.
> 
> Bert

I actually favor the reuse of existing TC's - so better in my opinion IMPORT from RFC 2287 rather than define a new TC. 

Dan

---

From: <[email-masked]>
Date: Mon, 21 Dec 2009 13:21:05 -0500

Richard,

Items 1) and 3) are the same issue, and cannot be resolved at this stage
of the process - they will be handled by the IESG.  The details are that
my Gen-ART review is advisory; your responsible AD (Dan Romascanu) has
expressed a view that the document should not be split, and he and I
have
"agreed to disagree" on this.  The General AD (Russ Housley) will decide
what, if anything, he wants to see done about this.

The RFC Editor will deal with some of item 2), but I'm disappointed
that your draft co-authors are not stepping up to do something about
this.

Thanks,
--David

> From: young [mailto:[email-masked]]
> Sent: Monday, December 21, 2009 1:31 AM
> To: [email-masked]; Black, David; 'Bert Wijnen (IETF)';
[email-masked]

---

From: young <[email-masked]>
Date: Tue, 22 Dec 2009 08:54:39 +0800

Hi, David:

Thanks. OK.
For 1) and 3), I will note that Russ Housley would handle it.
For 2), the RFC Editor would handle it.

Regards
Richard

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2009年12月22日 2:21
收件人: [email-masked]; [email-masked]; [email-masked];
[email-masked]
抄送: [email-masked]; [email-masked]
主题: RE: The Status of the CAPWAP WG MIB issues

Richard,

Thanks,
--David

[email-masked]

---

From: young <[email-masked]>
Date: Tue, 22 Dec 2009 13:27:01 +0800

Hi, All:

OK. I think so: the reuse of existing TC's

Regards
Richard

-----邮件原件-----
发件人: Romascanu, Dan (Dan) [mailto:[email-masked]] 
发送时间: 2009年12月21日 21:09
收件人: Bert (IETF) Wijnen; young
抄送: [email-masked]; [email-masked]; [email-masked];
[email-masked]
主题: RE: [Capwap] 答复: The Status of the CAPWAP WG MIB issues

> really wants to keep that, then pls check with yoru AD if he 

I actually favor the reuse of existing TC's - so better in my opinion IMPORT
from RFC 2287 rather than define a new TC. 

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 22 Dec 2009 13:51:43 +0100

Just to make clear what David Black meant (I think) with his comment that  ' The General AD (Russ Housley) will decide what, if anything, he wants to see done about this.' David performed the Gen-ART tem review and his comment about the need to split the document in order to define the optional CAPWAP protocol extensions in a separate document than the MIB module definition will remain unsolved unless the WG decides to follow David's recommendation. Russ as General Area Director can decide to turn this comment into a blocking DISCUSS, which will need to be solved. It also can happen that Russ will not find the issue important enough to press for changing the documents at this stage - basically this would mean sending the MIB document back to the WG. 

I do not know yet Russ's position about this. I can ask his position in advance if you want me to. 

Dan

> Sent: Tuesday, December 22, 2009 2:55 AM
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [Capwap] 答复: The Status of the CAPWAP WG MIB issues
> 
> Hi, David:
> 
> Thanks. OK.
> 收件人: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Items 1) and 3) are the same issue, and cannot be resolved at 
> this stage of the process - they will be handled by the IESG. 
>  The details are that my Gen-ART review is advisory; your 
> responsible AD (Dan Romascanu) has expressed a view that the 
> document should not be split, and he and I have "agreed to 
> disagree" on this.  The General AD (Russ Housley) will decide 
> The RFC Editor will deal with some of item 2), but I'm 
> disappointed that your draft co-authors are not stepping up 
> to do something about this.
> 
> Thanks,
> --David
> 
> 
> > The drafts text was updated according to the discussion in 
> the mailing
> list.
> > W: f(capwap-base.mi2), (1343,7) Row 
> "capwapBaseStationEntry" does not
> have a
> > consistent indexing sche
> > capwapBaseWtpEntry, since can have only one "base row" which is 
> > capwapBaseWirelessBindingEntry
> > W: f(capwap-base.mi2), (1568,13) Row 
> "capwapBaseRadioEventsStatsEntry"
> does