Subject: [Entmib] Issues with RFC 2737?

From: Margaret Wasserman <[email-masked]>
Date: Sat, 21 Jul 2001 09:32:47 -0400

To reiterate a previous request:

Do you know of any issues that should prevent RFC 2737 from going
to Draft Standard in its current form?  

If so, please send your issues to the list BY FRIDAY, JULY 27TH, so 
that there will be a few days to discuss them before the 
London IETF meeting.

It is important that we get any unresolved issues on the table, so
that we can begin work to resolve them!

Please also let me know if you would like time in the agenda to 
discuss your issue(s) -- this is recommended for complex or 
controversial issues.  I will prepare a summary of all other 
unresolved issues for discussion at the meeting.

Andy and/or Keith, were there any outstanding issues regarding
RFC 2737 before the WG hiatus?  If so, could you please summarize
those issues for the list?

Thanks,
Margaret

_______________________________________________
Entmib mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/entmib

---

From: Andy Bierman <[email-masked]>
Date: Mon, 23 Jul 2001 11:22:00 -0700

> that there will be a few days to discuss them before the

There are 2 distinct tasks at hand:
   1) WG chair must document interoperability for at least 2 complete 
      and independent implementations, as per instructions in RFC 2026, 
      sec. 4.1.2 
   2) Determine if RFC 2737 constitutes the necessary and sufficient
      technology required the satisfy the original charter statement.
      (http://www.ietf.org/html.charters/entmib-charter.html)
      If so, the WG is done for awhile, otherwise the WG may decide
      the technology is not sufficient, and consider adding extensions.

Given that half the meeting agenda is devoted to new features, and
the fact that major vendors have already deployed several Entity MIB
extensions, it's quite likely the WG consensus will be the charter
has not yet been fulfilled.  This is to be expected, since the
first 2 versions were designed with a 'minimalist approach', as the 
last sentence of the charter text recommends.

One issue that I can think of now -- the entLogicalTable includes the
following objects to associate an SNMP engine with a logical entity:
      entLogicalTAddress         TAddress,
      entLogicalTDomain          TDomain,
      entLogicalContextEngineID  SnmpEngineIdOrNone,
      entLogicalContextName      SnmpAdminString

There seems to be an overlap between these objects and the functionality
provided by the snmpCommunityTable, from the SNMP-COMMUNITY-MIB in RFC 2576,
and that RFC 2576 is better and more complete. Perhaps the entLogicalCommunity
object should simply identify an snmpCommunityEntry with the same 
snmpCommunityIndex value, and these objects should be deprecated.

Andy