Re: comments on draft-shield-eos-capabilities-00.txt

Wes>  I don't think putting a beginning/end range varbind at the top of
Wes>  the OID to say you're going to compress the rest is a efficient way
Wes>  to do compression (ie, to do compression you must insert 2 varbinds
Wes>  which will total in something like 44 bytes

Two comments:

Firstly, it's not actually as bad as that:

  a)  One varbind would be sufficient if you're compressing the
whole varbind list (start.1 and no end indicates the whole list).

  b)  The OID of the compression indicator varbind could then be
used to compress the OID of the first 'data' varbind, thus reducing
the overhead.

But yes - there would be an overhead to signalling in this way.

So (secondly) I probably wouldn't expect the management application
to use varbind signalling in this case.  Both compression proposals
used the ASN.1 tag to indicate a compressed OID, and that seems the
most obvious approach to follow.
  The OID-compression bit in the list of capabilities would primarily
be used for *advertising* this support, rather than requesting it.

  Similarly, if there's a new PDU type defined for a particular
operation, there'd be no point in signalling this within the varbind
list as well - again the capability bit would be primarily for
advertising this support.

  The list of signalling varbinds would be more appropriate for
more widely-applicable features.  I wasn't intending to propose
this as a "one-size-fits-all" mechanism - just as one weapon in
the armoury.


Wes>  I'd also suggest that if the work on this draft does continue, you
Wes>  should include error handling details which section 5 says you're
Wes>  not going to include (see the last paragraph if nothing else).
Wes>
Wes>  section 8 says:

Draft>   "It is implementation dependent as to whether
Draft>    the agent attempts to process the request anyway, ignoring
Draft>    the unsupported capability."

OK - perhaps "implementation dependent" was the wrong phrase there.
I was trying to suggest is that it's not up to the capability negotiation
document to define the behaviour on receipt of an unrecognised capability.
I'd agree that it's probably sensible to have an agreed behaviour in
this case - but it'd be the responsibility of each capability definition
document to specify the appropriate behaviour for that capability.


Wes>  section 8 also says:

Draft>   "(Though such an agent would presumably drop
Draft>    the request with unknownVersion or unknownProcessingModel anyway)"

Wes>  Which seems odd, because I thought you were trying to make the
Wes>  varbinds compatible with older versions of the protocol.

Not really - I didn't think that it would be held generally acceptable to
redefine the behaviour of existing protocol versions retrospectively.
(And the general reaction has seemed to bear this out!)
  I've been more trying to lay the groundwork so that we wouldn't need
to keep changing versions (or processing models) in the future.

What I was trying to do, was stick within the overall structure of
the existing basic  PDU format as much as possible - rather than
introducing differences unnecessarily.
   With something like your Object-Request proposal, extending the PDU
structure is fair enough - it'd probably be difficult to provide that
level of functionality within the existing framework without a lot of
awkward fudges.
   But the additions I've been advocating wouldn't require such drastic
changes - they'd be quite happily accomodated within the existing PDU,
so there seemed no point in fiddling with this if I didn't need to.

Wes>                                                       If you're
Wes>  not and are still requiring modification of the packet version
Wes>  number or something, I see *far* less use in this approach.


So every time we have a new idea of something we'd like to add to SNMP,
we'll end up bumping either the version or the processing model.  Yes?
   If people are happy with that - fine.   I'm simply suggesting an
alternative approach.

Dave