[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Pls review Agenda and Package for July 22, 2004 IESG Telechat
Mike,
My understanding of Bert's intervention was that the document is targeting advancement on standards track. The IESG agenda mentions that it is being discussed as a candidate for 'Draft'. In the light of this recommendation, I agreed with Bert that no syntactical changes that would impact backwards compatibility are to be done. I also grudgingly agreed that other 'non-stopper' comments that would improve the level of documentation can be omitted, although I hold the belief that one of the goals of a Proposed to Draft RFC advancement phase is to improve the level of clarity and documentation of the standard, as result of implementation and further reviews feedback.
However, if the document recycles to Proposed, it becomes effectively a new module, and fixing the different shortcomes is required. It is not clear to me what purpose will be served by making the older version an Informational. After all 1657 is available for all to see, and if documenting the implementations is the goal, the respective implementation report I-D can be turned into an Informational RFC.
Regards,
Dan
> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: 22 July, 2004 9:06 AM
> To: Romascanu, Dan (Dan)
> Cc: Wijnen, Bert (Bert); Mreview (E-mail)
> Subject: RE: Pls review Agenda and Package for July 22, 2004
> IESG Telechat
>
>
> Dan,
>
> Allow me to echo Bert's point that a lot of the "cruft" in this MIB
> module is a result of history going back to RFC 1269. Assuming that
> the problem with the erroneous embedded double quote is fixed (which
> I think is a MUST), then all of the remaining smilint warnings are a
> result of the history. Specifically: the {index-element-accessible}
> warnings are a result of the original MIB module having been written
> as an SMIv1 module; the {row-name-table-name} are a result of
> previous failures to observe naming conventions, and cannot be fixed
> now; and the {notification-not-reversible} warnings are a result of
> bugs introduced by an improper translation to SMIv2 in RFC 1657. I
> will point that I made some comments to the authors on the -12
> version and (apart from the stray quote) all of the things I raised
> then have now been fixed. And as you can see from the attached
> smidiff report, the RFC 1657 version was quite a bit worse. I do
> agree that the suggestions that you have made would be improvements
> but none should be a showstopper. Certainly the implementation
> experience documented in the mibagent-survey draft indicate that
> even the previous versions were good enough to implement.
>
> Having said all that, I do tend to agree that it's not entirely
> right to recycle this module back to Proposed. Here is a comment
> that I made on the -12 version, and I think it is still valid today:
>
> On Mon, 8 Sep 2003, I wrote:
> | 2.) I also understand from reading the draft and from previous
> | e-mail messages that the main purpose of this document is to provide
> | a clean MIB module that documents the behaviour of deployed
> | implementations, and that a new MIB module to overcome numerous
> | shortcomings is under development and will in due course be
> | submitted for standards-track consideration. Under the
> | circumstances it may be appropriate to submit this document as an
> | Informational RFC rather than for the standards track, as indicated
> | in the WG last call: if a replacement is under development, there
> | is no reason to progress this document along the standards track,
> | and submitting it for Proposed Standard implies such an intent.
>
> Regards,
>
> Mike Heard
>
>
> On Wed, 21 Jul 2004, Romascanu, Dan (Dan) wrote:
> > Bert,
> >
> > Well, this raises the issue of how we address documents at
> > 'higher' standardization levels in our MIB reviews. Because of
> > the time filter, the documents aspiring to reach Draft or Full
> > could be susceptible to more problems relative to our MIB review
> > guidelines. I would agree with you that such documents should
> > get waivers, unless they contain really show-stopper issues.
> > However, documents aspiring to Proposed, or re-cycled to
> > Proposed, should be reviewed against the full set of guidelines.
> >
> > Regards,
> >
> > Dan
> >
> >
> >
> > > -----Original Message-----
> > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> > > Sent: 21 July, 2004 4:01 PM
> > > To: Romascanu, Dan (Dan); Mreview (E-mail)
> > > Subject: RE: Pls review Agenda and Package for July 22, 2004
> > > IESG Telechat
> > >
> > >
> > > Dan, I will consider these additional comments.
> > >
> > > However, we must realize that this new MIB module is basically to
> > > FIX some of the errors/bug created in RFC1657 (which is
> at DS level).
> > > This new doc fixes those problems and makes a few
> clarifications as
> > > to how current implementations in fact work. The new doc is
> > > going to start all over at PS.
> > >
> > > The IDR WG is also working on a much better version of a BGP MIB
> > > module as you can see in: draft-ietf-idr-bgp4-mibv2-04.txt
> > > My understanding is that that will be the goal for the
> final BGP MIB
> > > module, and so we can wonder how much more cycles we want
> to spend on
> > > this one.
> > >
> > > As you have seen, I have posted some (non-blocking) comments
> > > about this document as well. I wil add these, and maybe the
> > > authors are willing to do one more rev.
> > >
> > > My personal assessment however is that it seems not right
> to BLOCK if
> > > they are very reluctant to do so.
> > >
> > > Opinions are welcome.
> > >
> > > Thanks for the review Dan!
> > > Bert
> > >
> > > > -----Original Message-----
> > > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
> > > > Sent: woensdag 21 juli 2004 13:31
> > > > To: Wijnen, Bert (Bert); Mreview (E-mail)
> > > > Subject: RE: Pls review Agenda and Package for July 22,
> 2004 IESG
> > > > Telechat
> > > >
> > > >
> > > > I have a few more comments wrt. the bgp4-mib:
> > > >
> > > > 1. "Changes from RFC 1657:
> > > >
> > > > 1) Fixed the definitions of the traps to
> > > > make them equivalent to their initial
> > > > definition in RFC 1269.
> > > >
> > > > I guess that we are doing Notifications rather than
> Traps nowadays
> > > >
> > > > 2. This version of the MIB seems to support a BGP-4
> > > > specification that covers only the exchange of IP
> version 4 network
> > > > reach ability information. Accordingly, the usage of the
> > > > IpAddress TC is OK, but it would be nice for some text to
> > > > clarify this.
> > > >
> > > > 3. DESCRIPTION clauses of objects with enumerated indices
> > > > miss explaining each value - see for example bgpPeerState
> > > >
> > > > 4. Almost no REFERENCE clauses come to help the implementers
> > > > - see for example the same bgpPeerState
> > > >
> > > > 5. No UNITS clauses for Counter objects or Integer32 objects
> > > > expressing timers - e.g. bgpPeerHoldTimeConfigured
> > > >
> > > > 6. Is bgp 7 obsolete, or deprecated? The ASN.1 and the text
> > > > are not consistent.
> > > >
> > > > Although none of the above is a show stopper, my personal
> > > > feeling is that the level of accuracy and documentation of
> > > > the MIB module defined in this document is somehow below the
> > > > usual criteria for approval by the IESG, and I would suggest
> > > > that the authors are required to do an extra round and fix
> > > > these problems before publication.
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Dan
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: owner-mreview@ops.ietf.org
> > > > > [mailto:owner-mreview@ops.ietf.org]On Behalf Of
> Wijnen, Bert (Bert)
> > > > > Sent: 16 July, 2004 12:52 PM
> > > > > To: Mreview (E-mail)
> > > > > Subject: Pls review Agenda and Package for July 22,
> 2004 IESG Telechat
> > > > >
> > > > >
> > > > > MIB Doctors,
> > > > >
> > > > > I would appreciate if you can review from an NM and SNMP/MIB
> > > > > perspective. Specific documents I like you to focus on are:
> > > > >
> > > > > - draft-ietf-idr-bgp4-mib-14.txt
> > > > > Definitions of Managed Objects for the Fourth Version
> > > > > of Border Gateway Protocol (BGP-4) (Proposed Standard)
> > > > >
> > > > > - draft-ietf-idr-bgp-mibagent-survey-01.txt
> > > > > BGP MIB V1 implementation survey (Informational)
> ...
>