Re: [IPFIX] NAT IPFIX logging draft

Hi Brian,
Please see inline.

On 6/2/14 5:42 AM, "Brian Trammell" <[email protected]> wrote:

>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.

Ok, as you could see in that table 5.2 most of the IE's are already
defined in IPFIX registry, but for the ones that are not, I will make them
verbose, in the IANA considerations section.

>
>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-elem
>>>ents 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.

Yep, agree, that would be the most practical way to address the
terminology differences.

>
>>> 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.

Thanks, looking forward to your review comments.

Senthil

>
>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