Subject: IDMEF Last Call

From: Mike Erlinger <[email-masked]>
Date: Mon, 3 Dec 2001 07:52:53 -0800

The IDMEF Last Call is over, and we have only one set of comments to
resolve - namely those from Glenn Mansfield.  Dave Curry has generated
a reply. It would be nice if others would join the discussion with the
goal of reaching consensus as quickly as possible on each of Glenn's
concerns.

thanks
mike

-- 
Mike Erlinger, Professor and Chair Computer Science
www:      http://www.cs.hmc.edu/~mike
email:    [email-masked]
smail:    Computer Science Dept., Harvey Mudd College,
          301 E. 12th Street, Claremont, CA, 91711 
          909-621-8912,   FAX: 909-621-8465

---

From: "Eric D. Williams" <[email-masked]>
Date: Mon, 3 Dec 2001 17:11:29 -0500

Hello all;

I feel we may indeed be approaching consensus just wanted to throw in
my $.02 on the subjects below:

On Monday, December 03, 2001 9:24 AM, David A. Curry
[SMTP:[email-masked]] wrote:
> 
> >>>>> On Mon, 3 Dec 2001, Glenn Mansfield Keeni, identified as
> >>>>> "Glenn" below, wrote:
> 
>   Glenn> 11. Sec 5.2.6 The Assessment Classes
>   Glenn> Is it OK to have "textual descriptions of  impact" ? This
> raises the 
>   Glenn> basic issue -
> ...

While I feel there may become a tendency early on to overuse the
"free-form" nature of the "textual descriptions of impact" that
tendency will most likely be short lived.  Based on some of the other
discussion on this issue re: "verbosity" it seems likely more compact
forms will prevail and thus deprecate the textual description as
things move forward.  Textual is OK, a good short term compensatory
measure.

On Monday, December 03, 2001 9:24 AM, David A. Curry
[SMTP:[email-masked]] wrote:
>   Glenn> Do we require the domain name representation of an address
> ? That is 
>   Glenn> not present ?
> 
> Do you mean PTR records?  Or something else?

I think Glenn means PTR's here Dave.  My opinion is that since PTR
may be unreliable unless all caches along the resolution path, and
the authoritative records, are trusted (not likely) you don't need
that is or mapped to the Address class.

On Monday, December 03, 2001 2:23 PM, Cynthia McLain
[SMTP:[email-masked]] wrote:
> > 14. Sec. 5.2.7.4.2 The SNMPService Class
> >       The significance and purpose of this class is not clear.
> > This is better dropped.
> > 
> 	Is there a reason that there are extensions to Service for
> 	WebService and SNMPService but not other types of services?
> 	Having argued for the re-instatement of action and confidence,
> 	I'm tending towards the cautious when it comes to dropping
> 	elements.
> 

I think this was meant to address issues of frequency of traffic use
and to segregate the additional information associated with the
service.  I don't think it goes any farther than that, and I feel it
is appropriate for the Service context, particularly since it would
dis-aggregate the traffic of interest from 'nominal' traffic for
these services in the format itself, where underdevelopment (or
deprecation) of this 'sub/additional' class of service does not get
us as close to the "suspicious or of interest." requirement as the
current specification.  I am for keeping this in the spec.

Others are all handled well I think.

Cheers, 

- -Eric
mailto:[email-masked]
PGP Public Key: http://new.infobro.com/KeyServ/EricDWilliams.asc
Finger Print: 1055 8AED 9783 2378 73EF  7B19 0544 A590 FF65 B789