Re: [IPFIX] NAT IPFIX logging draft

On 06/02/2014 10:46 AM, Senthil Sivakumar (ssenthil) wrote:
> Hi Brian,
> Please see inline.

Thank you, Brian, for your help. And thanks for being over-committed 
because you're doing OTHER TSV stuff, too :-)

Spencer

> 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