[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Pls review Agenda and Package for July 22, 2004 IESG Telechat
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)
> > >
> > > But of course checking any other documents will be
> > > appreciated as well.
> > > Comments asap, but certainly before Thursday July 22nd at 4pm
> > > European time.
> > >
> > > Thanks, Bert
> > > ------------
> > > 2.1 WG Submissions
> > > 2.1.1 New Item
> > > o Eight-document ballot: - 1 of 4
> > > - draft-ietf-idr-bgp-implementation-01.txt
> > > BGP 4 Implementation Report (Informational)
> > > - draft-ietf-idr-bgp4-24.txt
> > > A Border Gateway Protocol 4 (BGP-4) (Draft Standard)
> > > - 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-vuln-00.txt
> > > BGP Security Vulnerabilities Analysis (Informational)
> > > - draft-ietf-idr-bgp-analysis-05.txt
> > > BGP-4 Protocol Analysis (Informational)
> > > - draft-ietf-idr-bgp4-experience-protocol-04.txt
> > > Experience with the BGP-4 Protocol (Informational)
> > > - draft-ietf-idr-bgp-mibagent-survey-01.txt
> > > BGP MIB V1 implementation survey (Informational)
> > > - draft-iesg-tcpmd5app-00.txt
> > > Standards Maturity Variance Regarding the TCP MD5
> > > Signature Option (RFC
> > > 2385) and the BGP-4 Specification (Informational)
> > > Token: Alex Zinin
> > > o draft-ietf-opes-http-02.txt
> > > HTTP adaptation with OPES (Proposed Standard) - 2 of 4
> > > Token: Ted Hardie
> > > o draft-ietf-mmusic-anat-01.txt
> > > The Alternative Network Address Types Semantics for the
> > > Session Description
> > > Protocol Grouping Framework (Proposed Standard) - 3 of 4
> > > Token: Jon Peterson
> > > o draft-ietf-sip-anat-usage-00.txt
> > > Usage of the Session Description Protocol (SDP)
> > > Alternative Network Address
> > > Types (ANAT) Semantics in the Session Initiation Protocol
> > > (SIP) (Proposed
> > > Standard) - 4 of 4
> > > Note: RFC Editor Note: ANAT to be expanded in Abstract
> > and Intro
> > > Token: Allison Mankin
> > >
> > > 2.1.2 Returning Item
> > > o draft-ietf-pkix-pi-10.txt
> > > Internet X.509 Public Key Infrastructure Permanent
> > > Identifier (Proposed
> > > Standard) - 1 of 3
> > > Note: The draft includes significant revisions. On
> > > the agenda to see
> > > if the revisions resolve the discuss positions.
> > > Also, given the
> > > significant changes, all of the ADs may want to take a
> > > fresh look.
> > > Token: Russ Housley
> > > o Two-document ballot: - 2 of 3
> > > - draft-ietf-sipping-early-media-02.txt
> > > Early Media and Ringing Tone Generation in the Session
> > > Initiation
> > > Protocol (SIP) (Informational)
> > > - draft-ietf-sipping-early-disposition-03.txt
> > > The Early Session Disposition Type for the Session
> > > Initiation Protocol
> > > (SIP) (Proposed Standard)
> > > Note: For re-review by Discussants please.
> > > Token: Allison Mankin
> > > o Three-document ballot: - 3 of 3
> > > - draft-ietf-crisp-iris-core-07.txt
> > > IRIS - The Internet Registry Information Service
> > > (IRIS) Core Protocol
> > > (Proposed Standard)
> > > Note: Returning to resolve outstanding DISCUSS; please
> > > be sure to review
> > > the -07 versions.
> > > - draft-ietf-crisp-iris-dreg-07.txt
> > > IRIS - A Domain Registry (dreg) Type for the
> > Internet Registry
> > > Information Service (Proposed Standard)
> > > - draft-ietf-crisp-iris-beep-07.txt
> > > IRIS - Using the Internet Registry Information Service
> > > (IRIS) over the
> > > Blocks Extensible Exchange Protocol (BEEP) (Proposed
> > Standard)
> > > Note: Needs to add a normative reference to
> > > draft-daigle-snaptr-00.txt,
> > > which sets up the registry populated here.
> > > Token: Ted Hardie
> > >
> > >
> > > 2.2 Individual Submissions
> > > 2.2.1 New Item
> > > o draft-wasserman-rfc2418-ml-update-01.txt
> > > Update to RFC 2418 Regarding the Management of IETF
> > > Mailing Lists (BCP) - 1
> > > of 2
> > > Token: Harald Alvestrand
> > > o draft-hansen-lemonade-msgctxt-videomsg-01.txt
> > > Video Message Message Context (Proposed Standard) - 2 of 2
> > > Token: Ted Hardie
> > >
> > > 2.2.2 Returning Item
> > > NONE
> > >
> > > 3. Document Actions
> > >
> > > 3.1 WG Submissions
> > > Reviews should focus on these questions: "Is this
> > > document a reasonable
> > > contribution to the area of Internet engineering which
> > > it covers? If
> > > not, what changes would make it so?"
> > >
> > > 3.1.1 New Item
> > > o draft-ietf-msec-gkmarch-08.txt
> > > MSEC Group Key Management Architecture
> (Informational) - 1 of 2
> > > Note: Blue Team.
> > > Token: Russ Housley
> > > o draft-ietf-v6ops-renumbering-procedure-01.txt
> > > Procedures for Renumbering an IPv6 Network without a Flag Day
> > > (Informational) - 2 of 2
> > > Note: Note: red team
> > > Token: David Kessens
> > >
> > > 3.1.2 Returning Item
> > > NONE
> > >
> > > 3.2 Individual Submissions Via AD
> > > Reviews should focus on these questions: "Is this
> > > document a reasonable
> > > contribution to the area of Internet engineering which
> > > it covers? If
> > > not, what changes would make it so?"
> > >
> > > 3.2.1 New Item
> > > o draft-torvinen-http-digest-aka-v2-01.txt
> > > Hypertext Transfer Protocol (HTTP) Digest
> Authentication Using
> > > Authentication and Key Agreement (AKA) Version-2
> > > (Informational) - 1 of 1
> > > Token: Allison Mankin
> > >
> > > 3.2.2 Returning Item
> > > NONE
> > > 3.3 Individual Submissions Via RFC Editor
> > > Reviews should focus on these questions: "Does this document
> > > represent an end run around the IETF's working groups
> > > or its procedures? Does this document present an incompatible
> > > change to IETF technologies as if it were compatible?" Other
> > > matters may be sent to the RFC Editor in private review.
> > >
> > > 3.3.1 New Item
> > > o draft-richardson-ipsec-opportunistic-15.txt
> > > Opportunistic Encryption using The Internet Key
> Exchange (IKE)
> > > (Informational) - 1 of 1
> > > Token: Steve Bellovin
> > >
> > > 3.3.2 Returning Item
> > > NONE
> > >
> > >
> > >
> >
>