[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: firstname.lastname@example.org
- Subject: draft-hardaker-eos-oops-02pre.txt available
- From: Wes Hardaker <email@example.com>
- Date: Mon, 04 Nov 2002 15:37:19 -0800
- Organization: Network Associates Laboratories
- Sender: firstname.lastname@example.org
- User-Agent: Gnus/5.090008 (Oort Gnus v0.08) XEmacs/21.5 (brussels sprouts,i686-pc-linux)
Ok, I've published my missed-the-deadline draft at:
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
- 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.
Network Associates Laboratories