draft-hardaker-eos-oops-02pre.txt available

Ok, I've published my missed-the-deadline draft at:

  http://eos.hardakers.net/draft-hardaker-eos-oops-02pre.txt

Assuming that after the WG meeting is over and the thought is that the
work will go forward, I'll publish it as a -00 working group document
(assuming the Chairs and ADs have no objections, of course).

There is significant change since the -01 draft published in
September.  It's still in fairly rough shape, but is progressing into
a standards document from my previous personal draft.

High level changes that I can remember:

- warning: write PDUs still subject to significant change.
- warning: smiv3 got some attention in this draft, but due to last
  minute changes in thinking it's far from complete.  I'll make a
  summary slide about the issues for the WG meeting.


- there are now ASN.1 definitions of all the PDUs.

- There is a new "PDU processing" section.  There is a lot more text
  in it to help explain the PDU operations.  It's not perfect or
  complete, but it's a good start.

- There is now support for logical operations (and, or, not) by
  popular demand.

- You still can't say ifInOctets > ifOutOctets (ie, a variable on both
  sides of the operator) and I don't think you should be able to.
  I'll have a slide on this as well at the Wed. AM EOS meeting.  As
  is, the right hand side of the search function must be a value.

- The error reporting fields are now done via a SEQUENCE OF SEQUENCE.
  This provides two important benefits:
  a) if no error, its 2 on-the-wire bytes to say so.
  b) if errors, it's now possible to list multiple errors at once.

- There is a fair amount of room for extensibility, as also requested
  by numerous people.  Specifically, the more major pieces of the PDUs
  contain a option-field sequence, which will be simply empty until
  new documents fill it.  It hasn't been well defined in ASN.1 at this
  time (to implement it properly, a unique definition must be created
  at every invocation, unlike the common-throughout-definition used
  now).  Also, the flags field is present for future use as well, and
  it's documented what to do if you encounter an unknown flag, and
  restrictions are laid down for how new flags must be defined to
  ensure backward compatibility.

- probably more.

-- 
Wes Hardaker
Network Associates Laboratories