[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Thoughts on the various EOS proposals
DTS> It struck me that a number of the proposals seemed to be
DTS> covering similar ground, but that very little attempt had
DTS> been made to try and draw together the various alternatives
DTS> for any particular requirement.
LH> I agree this is a problem. Hopefully, the next draft iterations
LH> will be able to sync up a bit.
Yes - but only if things are actually discussed!
As you state later:
LH> The RowOps draft was indeed intended to help provide grist
LH> for this debate, and was never intended to be a final solution.
LH> Due to lack of list feedback, we had assumed providing
LH> something tangible would inspire debate.
<low, sweeping bow>
Your wish is my command, m'lady.
Note that encouraging a Shield to debate is often regarded as
a rash move, and not recommended for the faint-hearted :-)
(Ain't that so, Wes?)
Actually, having now gone back and skimmed through the mailing
list archives yet again (in the light of a greater familiarity
with the issues being discussed) - I can see that there _has_
been more discussion than I remembered. But time and again,
just as things were getting interesting, it fizzles out :-(
How much is it sensible for me to pick up on debates from
2-3 months ago (or more!) - or should I just let things lie?
DTS> Particularly with the RowOps document, what came over was
DTS> very much a tightly-linked, all-or-nothing offering - which
DTS> felt contrary to the aims and structure of the working group
DTS> charter and requirements.
LH> The RowOps draft directly attempts to provide a tangible
LH> solution to some of the charter items, and the requirements
LH> have not yet been defined. However, which specific charter
LH> "aims" do you think the RowOps draft violate?
Sorry - I may have given the wrong impression by that comment.
I didn't intend to imply that the RowOps draft was working
contrary to the letter of the charter - certainly "violate"
isn't a word that I'd wish to use.
It's just that, as I tried to indicate, I see the EOS charter
as talking about half-a-dozen logically independant ideas, and
these seem to be repeated in the EOS Requirements document.
(Note, I was referring to this - draft-ietf-eos-requirements-00.txt
rather than the mail messages containing the list of rowOps
requirements and compliance matrix).
As such, it seems good practise to try and consider them as
modularly as possible - particularly for ease of understanding,
but also to aid implementation and testing. Certainly that's
how I try to encourage our students to work - tackle a problem
one step at a time. I didn't feel that this was something that
was particularly straightforward with the current rowOps draft.
I'll pick up on some of your specific comments later, once
I've had a chance to properly re-consider some of the earlier
discussions. But I'd like to make a couple of general points now.
Firstly, one of the fundamental problems to be addressed
(as I see it) is how to determine whether a particular chunk of
incoming octet stream should be regarded as a traditional SNMP
request (or part thereof), or a new EOS request (or part).
IMO, there are three basic alternatives:
- to define new PDU(s)
- to define new Types
- to use distinctive values
(which can, of course, be used individually or in combination).
The rowOps approach seems to use the first and third options
and (unnecessarily) avoid the second. Maybe I'm biased by the
Net-SNMP architecture, but it would actually be fairly easy
for us to handle new types within the existing basic SNMP
framework. Although the rowOps approach is slightly easier to
parse (since the mechanisms are already there), there's then
the need to re-interpret the values "higher up" which adds to
the overall complexity, and potential for problems.
Handling aggregations at the lower level feels to be a much
cleaner approach, and I can't help thinking that this is a case
of a short-term saving that we'd come to regret later. The
on-going support costs (e.g. of maintaining the code for this
additional level of encoding) are probably likely to prove
greater than doing it "right" in the first place.
Secondly, the on-the-wire and internal representations of a
particular contruct do not necessarily have to match precisely.
For example, a row aggregation (whether it came in as a single
varbind, or a sequence of RowIdentifiers) could be stored
as a single structure, or a list of traditional varbinds
(either seperate, or clustered) depending on circumstance,
and possibly converted to another format if need be (e.g.
splitting an aggregation when talking to a sub-module that
didn't understand them, or aggregating a traditional request
when talking to one that did).
Similarly, I'd expect that if we implemented the OPC algorithm,
an internal OID structure would probably be the same whether
the corresponding incoming octet stream was a traditional OID,
an uncompressed delta, or a compressed delta. The only
difference would probably be a flag somewhere (probably in
the PDU or session structure, rather than the OID itself) to
indicate whether an outgoing PDU should be compressed or not.
Clearly, to get the full benefit of the changes, knowledge
of the EOS stuff would need to be as widespread as possible.
And there are some cases where more than one feature might
be needed to get the necessary behaviour.
But by decoupling (say) OID compression from row aggregation,
or row aggregation from new operations - it makes it a lot
easier to implement and test each bit in isolation. And if
the XProto MIB was sufficiently fine-grained enough to be able
to report which options had been implemented in various cases,
then this incremental approach could be extended to deployment
I'll probably make some more specific comments next week.