[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comments on draft-shield-eos-capabilities-00.txt
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
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
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