Re: [BEHAVE] Comments on draft-ietf-behave-syslog-nat-logging-02

[Tom Taylor <[e-mail]>]

Thanks for taking the time for this. Responses below.

On 27/07/2013 1:45 PM, Dave Thaler wrote:
> Of the 10 documents I read while traveling to Berlin, this one was the longest, but
> also probably the easiest to read and most well written in my opinion, so thanks for
> all the work put into this recently!
>
> A summary of my technical comments follows.
>
>
> 1.       The syslog doc and the NAT MIB are not currently aligned.
>
> The NAT MIB has low/high watermark objects for one type of notification
>
> (which I think is a good approach), but it appears to only affect SNMP notifications
>
> not Syslog notifications.   The syslog doc requires rate limiting various things,
>
> with required knobs that are not in the NAT MIB.  And the syslog doesn't
>
> recommend low/high watermarks but probably should, as I think it's currently
>
> underspecified.

[PTT] I wonder if, in the interest of orderly procedure, we first draw 
up the configuration requirements by adding a Management Considerations 
section to the logging draft. Then we can figure out how to propagate 
that to the MIB or other configuration  models.

[PTT] The watermark system I'm familiar with from my telephony days 
would be based on observations over a fixed time interval (e.g., 5 
minutes, 30 minutes, possibly an hour). Is this what you would have in 
mind, with a log being generated at the end of each observation interval?
>
> 2.       The use of UTF-8 strings for identifiers needs clarification.  Is non-ASCII really
>
> required?   If so, what normalization form?  Any constraints on set of legal
>
> characters?  What are the uniqueness requirements?  E.g., is it ok to have
>
> two values that differ only in normalization form?  What about differing in
>
> case?  What about being visually identical/confusable?

[PTT] I agree this needs a closer look. We ended up having to add stuff 
to ANCP to support the use of UTF-8. I'm getting the picture of an 
occasional (hourly and whenever configuration changes) ADMIN event type 
which would have miscellaneous stuff like the byte masks used to 
truncate IPv4 and IPv6 addresses (suggested by Dan in his review), and 
could also have the additional information needed to make UTF-8 work. Of 
course, as you say, we should first determine whether anything more than 
US-ASCII is needed.
>
> 3.       The document assumes a single "internal" and a single "external" realm. This
>
> Is not a safe assumption in general, and especially not in scenarios like
>
> "An IPv4 Network to An IPv6 Network" and vice versa, where there could
>
> be (for instance) 2 internal realms and 0 external realms.  Furthermore, the
>
> terms are ambiguous. For example in the "IPv6 Internet to An IPv4 Network"
>
> scenario where sessions are initiated from the Internet, which side is
>
> "external"?

[PTT] Ironic -- I changed the terminology because the terminology 
implicit in the IPFIX draft always takes the point of view of outgoing 
packets without saying so and I thought that was ambiguous. Looks like 
we need to fall back to that position and state the convention in the 
terminology section.

>
> 4.       The type registry is not sufficiently motivated.  Why are standard values
>
> needed here?  And if they are, then why is FCFS not sufficient?

[PTT] Because, to be blunt, I sense that if anyone wanted to add NAT66 
to the list it would trigger a fairly strong reaction.
>
> 5.       The mechanism should not be limited to cases where the external address
>
> is IPv4.   Since it's passed as a string, there's no reason for such a limitation.
>
> A marked up copy that also includes my
> editorial comments can be found at
> http://research.microsoft.com/~dthaler/draft-ietf-behave-syslog-nat-logging-02.pdf
> (or a .docx version if you replace .pdf with .docx).
>
> -Dave
>
>
>
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave
>