Comments on latest i-drafts

[[e-mail]]

Here's my review of the latest i-drafts.

I do not consider *any* of these to be show-stoppers.
Although there is at least one real "defect" listed
(#2 w.r.t. draft-ietf-snmpv2-coex-ds-03.txt).

bok


draft-ietf-snmpv2-intro-ds-04.txt
---------------------------------

1. Section 2.7 (pg 5): does it make reasonable sense to introduce
   the term and acronymn "Community-based SNMPv2 (SNMPv2C)" as a
   common term that implementors and consumers can use to refer to
   this profile of SNMPv2 support?   

   Suggested edits:  Add the following sentence after the second
   sentence of paragraph 2:

	Use of this administrative framework with SNMP Version 2
	is commonly known as "Community-based SNMPv2 (SNMPv2C)."


draft-ietf-snmpv2-coex-ds-03.txt
--------------------------------

1. Section 2.1 (pg 3), step #3 specifies that hyphen characters be removed
   from object descriptors.  Does this ALSO apply to intermediate object 
   identifier descriptors (i.e., "mib-2")?

   If so, shouldn't "mib-2" (defined in draft-ietf-snmpv2-smi-ds) be 
   renamed to "mib2"?  Likewise for all references to "mib-2" in V2-SMI
   style mibs.


2. Section 3.1.2 (pg 9), step #2: specifies procedures for a SNMPv2-Proxy
   to translate a received SNMPv1-Trap into an equivelant SNMPv2-Trap.

   What should the proxy do with the agent_address field from the received
   SNMPv1-Trap?  Especially if it is different than the value of the 
   udp-from-address in the udp header of the received packet?

   NOTE: as currently specified, there is a loss of functionality going
         to SNMPv2-Traps from SNMPv1-Traps.  This is because in SNMPv1, 
	 a trap could be sent on the behalf of some other originator 
         (i.e., agent_addr != udpHdr.from_addr).

   In SNMPv2-Classic and snmpv2*, this was not an issue because the 
   CONTEXT in the SNMPv2-Trap was a globally unique identifier of the 
   originating snmp entity.  In the Community-based SNMPv2 (SNMPv2C), 
   the community string is *not* globally unique; so therefore, cannot 
   be used to identify the originator of the SNMPv2-Trap.

   SOLUTION:

   The easiest way out is to simply blow it off and accept this reduction
   in functionality over SNMPv1-Traps.

   One alternate solution is to define a new MIB Object (or a pair of
   new mib objects - preferred) as follows:
   
      Option 1:  snmpTrapOriginator     SYNTAX IpAddress

      Option 2:  snmpTrapOriginTDomain  SYNTAX TDomain
		 snmpTrapOriginTAddress SYNTAX TAddress

   which are optionally appended to the Trap variable-binding list
   if the originating address is different from the transport 
   from_addr.  The advantage of using Option 2 is that it solves
   the general problem of sending SNMPv2 Traps & Informs on behalf
   of others; and not just solve it for SNMPv1-to-SNMPv2 Trap Proxy.

   The elements of procedure for Notification processing would need 
   to be modified such that, not only might the last varbind be an 
   instance of snmpTrapEnterprise.0, the snmpTrapOrigin* varbinds
   may optionally appear as well.  Before or after snmpTrapEnterprise?

   In the interest of moving the documents along, I'll accept just
   blowing off this issue and accepting the reduction in functionality
   over SNMPv1-Traps.  This, despite the fact that our existing product
   relies on this SNMPv1-Trap capability and my only alternative will be
   to build an enterprise-specific work-around to this SNMPv2C deficiency.  


draft-ietf-snmpv2-ip-ds-03.txt
------------------------------

1. What is the status of the ipRouteTable in RFC1213 (MIB-II) given
   the newly defined ipForwardTable in RFC1354 (a proposed-std)?  
   Is it the intention of RFC1354 to deprecate the ipRoutTable? 
   Or just provide alternate means for viewing and configuring routes?

2. What is the status of the egp group in RFC1213?  
   These objects do not have an equivelant SNMPv2 SMI-based definition 
   in any of the current internet-drafts.

=> I guess these questions raise the more general question also being
   discussed in the thread "obsolete objects in latest drafts". That is:  
    
	"What is the recommended method for deprecating objects 
	in IETF standards-track MIBs?  Especially once they are
	internet-standard such as MIB-II?"

    Keith?  Dave Perkins?  Your thoughts on this topic?
    You've been the most vocal/interested in evolution of mibs.

-- end