Re: The Status of the CAPWAP WG MIB issues
From: Black_David (Black_Davidemc.com)
Date: Mon, 21 Dec 2009 10:21:23 -0800 (PST)
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


> -----Original Message-----
> From: young [mailto:young [at] h3c.com]
> Sent: Monday, December 21, 2009 1:31 AM
> To: capwap [at] frascone.com; Black, David; 'Bert Wijnen (IETF)';
elwynd [at] dial.pipex.com
> Cc: yzhang [at] fortinet.com
> 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
> 
> 
> 

Results generated by Tiger Technologies using MHonArc.