RE: Protocol operations proposal deadline

At 05:56 PM 9/4/2002 +0200, Wijnen, Bert (Bert) wrote:
>Mmm... I thought Sharon also recently published a new rev (03) of her
>
>SNMP Extended Protocol MIB. 
>
>Thanks,
>Bert 
>>-----Original Message-----
>>From: Glenn Waters [mailto:[email protected]]
>>Sent: woensdag 4 september 2002 17:14
>>To: [email protected]
>>Subject: Protocol operations proposal deadline
>>
>>As was discussed in Yokohama and published in the minutes, the cutoff date for new protocol operations drafts is September 15, 2002.
>>
>>The drafts that I have seen so far are: 
>>
>><http://www.ietf.org/internet-drafts/draft-shield-eos-capabilities-00.txt>http://www.ietf.org/internet-drafts/draft-shield-eos-capabilities-00.txt 
>>http://www.ietf.org/internet-drafts/draft-hardaker-eos-oops-00.txt 
>>
>>There has been a reasonable amount of comment and support of the Hardaker draft. The Shield draft is reasonably new -- please read and supply comments.

I have read the SNMP Extended Capability Negotiation draft, and I have some
comments.

1) new protocol version vs. retrofitted features
   I think this draft provides a good framework for retrofitting
   existing versions of SNMP with new protocol features, but I don't
   think we should attempt to do this. If one decides to retrofit,
   then the only choice is to overload the varbind list somehow.
   That's what this draft (and other retrofit proposals I've seen)
   does.  I don't think this approach simplifies code design. On
   the contrary, it creates new coupling between the message processing
   module and the command responder application that doesn't exist
   in current implementations.  It does this in a kludgey way,
   that may cause implementations more work than simply adding
   a new message wrapper that supports new features efficiently
   (i.e. not by overloading the varbind list).  

2) Complexity of feature negotiation
   I think this draft goes overboard in complexity. 
   The ability to specify which features are requested for which
   varbinds is very complicated and could get even worse when you
   consider all the possible permutations and corner cases an agent
   needs to check.  The capabilities should apply to the entire PDU,
   not individual varbinds.  (If we had session-based SNMP-over-TCP,
   then the capabilities should apply to the entire session.)

3) Specification of extended capabilities:
   The draft list some extended features in a TC:

   ExtendedCapabilities ::= TEXTUAL-CONVENTION
      STATUS current
      DESCRIPTION
        "Provisional list of extended SNMP capabilities."
      SYNTAX BITS
        {
        oidDeltaCompression (0),
        oidPrefixCompression(1),
        fillHolesInTables   (2),
        dontColumnWrap      (3),
        errorString         (4)
        }

  These features are not defined or even described anywhere in the
  draft.  I think it's a feature of the proposal that the feature
  negotiation is independent of the actual feature extensions, but
  they illustrate an important point -- it's very likely that these
  features cannot be cleanly retrofitted to existing SNMP versions
  because they will require that rules for the contents of the
  Response PDU will be violated for some protocol operations.

In summary, I think we should leave existing versions of the SNMP
PDU alone, and add new features to a new message structure in the
cleanest manner possible. 


>>Thanks, /gww 

Andy