[idxp-java-discuss] Re: idxp-03

[Greg M. <gma...@od...>]

I really like the idea of a registration template for the "Option" element, and
in terms of initial options I'd go with "priority" and "stream_type". I don't
think that we should remove the "Option" element, because it provides a
mechanism by which QoS and organization of ID data transfers can be obtained.

With IAP we were limited to one logical channel over which alerts could be sent,
but with IDXP we have N number of channels, and providing the option to label
these (with the "stream_type") gives the receiver a chance to prioritize how it
handles incoming alerts. 

The "priority" option is a more direct approach that lends itself to other
scenarios...for instance we could have an IDS entity that is collecting alerts
from several sources, and it could open N different channels to transport the
alerts it collects from each on a seperate channel to the receiver. The sender
_could_ label each channel with some identifier of the source that generated the
alert, but if it's undesirable to do so the sender could simply indicate, with
priority numbers, which channel(s) should be attended to first (and second, and
third, etc).

I don't think we need the "mustUnderstand" attribute, because I don't want
"Option" elements to be considered an integral part of the protocol. Regardless
of the ordering in which alerts are processed, IDXP is still doing its job of
transporting alerts in a secure fashion. As the draft currently states, peers
may ignore any "Option" elements they see, and I think we should stick by that
with the understanding that "Option" elements do not affect the basic
functionality that IDXP provides, they merely facilitate the use of BEEP
channels for QoS.

On a different note, I've updated my 'author info' in the draft, and have
attached just the text version to this email.

-Greg Matthews

On Wed, 18 Jul 2001, Ben Feinstein wrote:

> Hey ya'll,
> 
> Here is a newly revised copy of IDXP.  I've changed the profile
> registration stuff and added a registration for a TCP port number.
> 
> I want to gauge support for how the group feels about the "Option" element
> in the "IDXP-Greeting".  As it stands, it can be anything.  I think we
> should create a registration template and IANA listing for IDXP Options.  
> Also, I feel we should add a "mustUnderstand" attribute to the "Option"
> element which specifies whether the option, if unrecognized, must cause an
> error in processing to occur.  This is a subset of how options are handled
> in APEX.  See section 5 and 7.1 and appendix B of
> http://www.ietf.org/internet-drafts/draft-ietf-apex-core-04.txt
> 
> Also, any ideas for one or two initial options to register?  Perhaps a
> "statusRequest" Option indicating that the greeting is querying the IDXP
> peer for status?  Or a "severity" or "priority" option on the
> greeting?  What do ya'll think?
> 
> Also, I'd like to annouce that I've been hired by Guardent
> (http://www.guardent.com/) to be a Software Development Engineer in their
> new Atlanta R&D lab!
> 
> Cheers,
> Ben
>