Re: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-03

[Dave Thaler <[e-mail]>]

> > This draft does not currently allow you to write apps that collect and
> > process them without having to deal with vendor specific
> > implementations.  To get that, you'd have to specify what protocol to
> > use.  Otherwise you have to deal with vendor specific protocol code
> > anyway so you haven't met your stated goal.
> 
> There are many choices of the protocol that can be used to transport the
> data. But we wanted to stay away from getting into exact recommendation
> of the protocol to use.

Then you should change your goal.   Personally I would be in favor of either
of two approaches:
a) be completely abstract, focus on requirements, and not protocol.
   This is what lsn-requirements draft does already.
b) be concrete, specifying a solution for a particular protocol.

Currently this draft does neither.  It's halfway in between, which is
the problem I have with it.

> >>> 4) Section 4 says:
> >>>> Prior to logging any events, the NAT device MUST send the template
> >>>> of the record to the collector to declare the format of the data
> >>>> record that it is using to send the events.
> >>>
> >>> The above MUST might make sense for a specific protocol, but since
> >>> this document currently doesn't require any specific protocol the
> >>> MUST
> >> doesn't
> >>> make sense.   For example, if the protocol is SNMP Traps or
> >> InformRequests,
> >>> then the format is specified in a MIB and there's no
> >>> need for the NAT device to send it a MIB.   Similarly for any other
> protocol
> >>> the collector might have some other way of getting the template from
> >>> somewhere other than the NAT device.
> >>
> >> I am not sure I see the connection between the protocol specification
> >> and the ability to send templates. The reason for sending the
> >> template is that the same device could be sending multiple templates
> >> (one for nat44 create event and the other for NAT64 delete event and
> >> another for a NAT44 quota exceeded event. All of them carry different
> >> data sets and hence the template is necessary.
> >
> > I understand you didn't follow what I said, so I'll try to rephrase.
> > A NAT device can send all of this information to a collector without
> sending any
> > "template" before sending the information.   Of course since you never
> defined
> > the term template, I'm assuming it means schema.   The collector might
> already
> > have the templates, and there's many examples of this today.
> >
> I will define what a template is in the next rev. Yes, schema and template are
> the same. The problem with the fixed templates is that it makes it difficult to
> change and adopt to different implementations. Let me give you an
> example.
> If the schema/template changes the data to be exported for example an
> previously optional field now becomes a part of the new template, then the
> collector device need to change its template too. Having the templates sent
> over dynamically provides a much greater benefit and ability to change the
> schema.

Defining a "template" and sending it to the server is specifying part of a
protocol (and would certainly not apply to some protocols) and is one of 
the reasons this draft is not currently in category (a) as I defined it above.  
Another reason where it is not abstract (i.e. not in category a) is that it
defines bit lengths of data items.   That implies that IP addresses and ports
are sent in binary format, not in (say) string format, and hence is specifying
part of a protocol.

My recommendation would be to pick (a) or (b) and not try to be somewhere
in between, which I find confusing.

-Dave