Re: [IPFIX] NAT IPFIX logging draft

Brian Trammell <[email protected]> Mon, 2 Jun 2014 11:42:08 +0200
Newsgroups	gmane.ietf.ipfix
Message-ID	<[email protected]>
Hi, Senthil,

First, please read RFC 7013 if you have not done so already, and ensure that all IE definitions in this draft comply to the requirements therein.

Specifically, the descriptions in Section 5.2 are unimplementably brief. You don't need to give full definitions for IEs you're reusing, but you do need to fully define new IEs you want to create.

More points inline.

On 28 May 2014, at 16:11, Senthil Sivakumar (ssenthil) <[email protected]> wrote:

> 
> 
> During review of this draft http://tools.ietf.org/html/draft-ietf-behave-ipfix-nat-logging-03, the following question was raised by Spencer
>> SD: I noticed that some IEs below have a name that matches http://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-information-elements for the same IPFIX ID number, but others do not ("timeStamp" here doesn't match "observationTimeMilliseconds", but both are IPFIX ID 323, aren't they?) Is there a reason to use names that don't match the IANA registry?

Not only is there no reason to use names that don't match the IANA registry, we do not consider giving different names to codepoints in the IANA registry to be valid at all in any context.

>> [Senthil] Good question, in case of timeStamp, I was looking for something that already existed in the IPFIX registry rather than asking for a new one. However, the terminology of "observationTimeMilliseconds" is not the terminology that we use in the NAT drafts/rfc's. So I am open to suggestions here. I can clarify in the description that is called observationTimeMilliSeconds".

Note that an "observation" is "when the MP noticed an event", which for MPs colocated with packet-treatment devices is synonomous with "event time". So "observationTimeMilliseconds" is what you want if you want to limit implementors to millisecond-level precision.

I would strongly suggest creating a Terminology section that maps Behave terminology to IPFIX terminology.

>> The other field is internalAddressRealm and externalAddresRealm, this is the terminology that we used in NAT MIB, syslog and other documents. However, when we defined the IPFIX IE, we didn’t stick to the same terminology, so I don’t know if I can go and ask the IPFIX IANA to change the name.

You can certainly ask, though I suspect that a request to change IE 229's name to "internalAddressRealm" would be denied by the IE-DOCTORS as it is not clearly specific to NAT applications. It's also not at all clear to me that 229 refers to something that could be called "internalAddressRealm" -- natOriginatingAddressRealm per its definition refers to the side of the address realm boundary from which the first packet came.

From a data modeling standpoint, it is not at all clear to me why you want to (1) report "internalAddressRealm" and "externalAddressRealm" separately and (2) why you want to report this as opposed to natOriginatingAddressRealm as defined.

This is not a full review of the document; one will hopefully follow but I'm somewhat overcommitted at the moment.

Regards,

Brian

>> Again I am open to suggestions, the dillema is whether I should stick to the existing IPFIX IANA terminology or the behave documents terminology.
> I was asked to take this discussion here on how best to resolve this, any suggestions are greatly appreciated! 
> 
> Thanks
> Senthil
> _______________________________________________
> IPFIX mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix
signature.asc (application/pgp-signature, 496 B)