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

From: Dave Thaler <[email-masked]>
Date: Sat, 27 Jul 2013 17:45:53 +0000

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.

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?

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

4.       The type registry is not sufficiently motivated.  Why are standard values

needed here?  And if they are, then why is FCFS not sufficient?

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

---

From: Tom Taylor <[email-masked]>
Date: Sun, 28 Jul 2013 04:12:51 -0400

Thanks for taking the time for this. Responses below.

> recommend low/high watermarks but probably should, as I think it's currently

[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?
> 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.
> scenario where sessions are initiated from the Internet, which side is

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

> 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.
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>