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

[Dave Thaler <[e-mail]>]

1) The abstract says:
> The lack of a consistent way makes it difficult to write
> the collector applications that would receive this data and process
> it to present useful information.  

However the document only discusses data objects not a specific
mechanism to retrieve them.   As such, the statement above is still
true because there's no consistent way to receive such data.
So what problem is this trying to solve?   And is it useful without 
specifying what protocol to use?

2) Section 1 says:
> The usage of the term "NAT device" in this document refer to any
> NAT44, Firewall and NAT64  devices.  

The term NAT64 by itself includes both stateful NAT64 and stateless NAT64.
Why would logging be required for stateless devices?
Furthermore, the abstract talks about CGNs (where logging makes sense).
Why would the requirements in this document apply to "any" device (as
opposed to only CGNs) including CPE home gateways?   I didn't see any
text discussing or justifying this statement.
If this really is just about logging requirements for CGNs then this should
be discussed in the context of the CGN requirements document.

3) The document uses several terms without defining them:
"template", "address realm", "VRF", "NAT session", etc.   

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.

5) Section 4.1-4.3:
Some of these seem underspecified by comparison to what I'm used to
in MIBs.   (e.g., what's the format of "timestamp"?  what are the units?
since when?  Local time or UTC?)  This would be cleaner if done in some
formal way like SMIv2 or whatever, which can reference well-defined
data types.   And then no new "NAT Event Logging" registry would be 
needed from IANA either.

6) Section 4.1:
This defines "MAC address" as 48 bits which is too link-type specific.
A generic document that claims to apply to "any NAT device"
should be link-type agnostic.  (Same comment goes for "VLAN ID".)

7) Section 4.3.11:
The text confuses "user" with "source address".  They're not the same thing.
There can be many users per source address, as well as multiple source
addresses per user.

-Dave