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

[Wes Hardaker <hardaker@tislabs.com>]

As promised in the note I just sent, here's some more technical
feedback on my reading of the shield-eos-capabilities draft:

  Over all, I think it's a neat hack that should work clear back to v1
  PDUs, which does have benefits.  The list of capabilities to work
  out, however, is long and the starting list there (which enumerates
  many of the current drafts) sounds nice, but we obviously would need
  to undertake a lot more work in the group to ensure some of the
  other problems are solved as well (see the list in the top of my
  draft, for example).

  I'm not sure I like the notion of the varbind index counter to be
  separate from the main errindex field.  I understand the advantages
  you're trying to achieve, but I think it'll cause a bit of confusion
  and problems in some cases (sniffers, proxies, etc being the most
  heavily affected).  But, on the other hand I understand why you want
  to strip out those varbinds and not have to adjust the counter...  I
  think you loose something in either choice so care must be taken.

  I don't think putting a beginning/end range varbind at the top of
  the OID to say you're going to compress the rest is a efficient way
  to do compression (ie, to do compression you must insert 2 varbinds
  which will total in something like 44 bytes (if rough count is
  right, although the oids would likely be slightly shorter in the
  non-enterprise version)).  This doesn't seem terribly efficient.
  Granted if you were sending *really* big requests/responses it might
  be below the noise level, but it still seems odd.

  I would say, by the way, that ordering of the varbinds should be a
  MUST (last paragraph of section 4.2).

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

  section 8 says:

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

  The problem with error handling like this is that if you decide to
  proceed and then it gets dropped due to an unsupported asn encoding, for
  example (eg, oid compression), then the request gets dropped and
  only the counter is incremented with no error being fed back to the
  application (which then must wait for a timeout condition, check the
  counter, maybe retry, ...), which is not a good way to do error
  handling IMHO.

  section 8 also says:

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

  Which seems odd, because I thought you were trying to make the
  varbinds compatible with older versions of the protocol.  If you're
  not and are still requiring modification of the packet version
  number or something, I see *far* less use in this approach.


-- 
"The trouble with having an open mind, of course, is that people will
 insist on coming along and trying to put things in it."   -- Terry Pratchett