Subject: RE: draft-ietf-idr-bgp4-18.txt

From: Bill Fenner <[email-masked]>
Date: Fri, 1 Nov 2002 15:52:43 -0800

>	My understanding has been that the ID administrator 
>would not normally remove expired working group drafts
>(such as this one) without explicit agreement from a WG
>chair.

I've never head of that.  -17 was submitted in January (at least, the
timestamp on my copy is January 8) and its footers say that it expired
in July 2002.  It also said, in the boilerplate that we all ignore,

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time

So, it's been more than 6 months, -17 was expired.  In my 7 years as a
WG chair I don't think that the secretariat has ever checked with me
before removing a WG draft that had expired.

  Bill

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 4 Nov 2002 10:32:52 -0500

>    and may be updated, replaced, or obsoleted by other documents at any

And in the lines of "mea culpa" (they expired), I just re-submitted
the latest versions of the BGP MIBs last night, so they should
appear in the next several days.  The major changes are:

o Atomic aggregate is clarified. (about time)

v2mib:
Some bug fixes were put in:
o In the nlri tables, prefixlen and prefix were swapped.
o Clarify some text in the descriptions of the peer tables to address
  some points Venu brought up.
o Change to using SnmpAdminString instead of DisplayString to permit
  internationalization.  MIB implementors - please comment on this.
o Fix the textual convention for extended communities.
o Changed the enumerations of bgpM2PathAttrAtomicAggregate to stop
  mentioning less and more specific.
o Added a table for rfc 2545 link local nexthops.

Not addressed in these mibs:
o Some of Ran Atkinson's comments for the security section, specifically
  text requiring a MUST of using snmpv3 for implementors of these
  MIBs.  I think the language was a bit strong, but there is still
  an issue and we'll deal with it.  My suggestion is to insist on
  strong security in cases where snmp writes are allowed, but to
  allow for lesser security for most objects.
o I had some notes on table structure that I no longer understood
  since its been a while.  I'll be querying some people on these
  notes.  Sorry they didn't make this round.

The changes are light enough on the v2mib that this shouldn't 
throw a huge monkey-wrench into implementations.  Speaking of
which:
Who is implementing the v2mib?

-- 
Jeff Haas 
NextHop Technologies