Subject: [BEHAVE] Consensus call regarding nat-mib

From: Dave Thaler <[email-masked]>
Date: Wed, 24 Jul 2013 19:54:02 +0000

> Simon wrote:

>> Our position, and we feel we have the consensus of the WG with us, is

>> that the existing NAT-MIB is fatally flawed and we need a complete

>> replacement. The reasons are explained in section 3.1.

>> https://tools.ietf.org/html/draft-ietf-behave-nat-mib-06#section-3.1

>> That's why we initially started with a brand new MIB, called the

>> NEW-NAT-MIB. We changed into the current structure based on feedback

>> from the working group in general and Juergen in particular.

> Juergen responded:

>> As far as I recall, it was initially not clear whether there is

>> consensus that the NAT-MIB is fatally flawed. (And the text that is

>> now in section

>> 3.1 did not exist at that time in the current level of detail as far

>> as I recall.)

>> I suggest a consensus call is made by the chairs on this fundamental

>> question. If there is consensus that the NAT-MIB is fatally flawed

>> (and note that opinions of implementors in particular matter here),

>> then declaring the MIB module in RFC 4008 historic (e.g. marking RFC

>> 4008 historic) and creating a new MIB module may indeed be the right

>> thing to do.

I believe we've heard from many folks that RFC 4008 is not appropriate

for carrier-grade NATs.  The authors of draft-ietf-behave-nat-mib have

put the reasons into section 3.1 as noted above.

However, the chairs discussed Juergen's request and are fine asking for

confirmation of this point.   This email asks for confirmation of the position

that "RFC 4008 should be historic and a new MIB module is needed" for all

NATs (to cover both CGNs and non-CGNs).

If you have an opinion on this matter, please respond with "Agree"

(and state reason if it doesn't already appear in section 3.1) or

"Object: <state reason>".

Please respond before the WG meeting in Berlin.

-Dave and Dan

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Wed, 24 Jul 2013 21:20:48 +0000

I am starting a couple of threads to track the inconsistencies between the syslog and IPFIX logging drafts that requires input from the WG. This is the first issue that we need input on.

Logging of destination information has been discouraged in general for various reasons, log record size, privacy reasons etc. However, both the drafts had provided the facility to log destination information if the operator chooses to do so. IPFIX draft has had information elements for destination information for a long time and syslog had the provision too until last version. However, syslog draft has removed this provision to log destination information in the latest draft.

We are seeking WG guidance on if we should we have provisions for destination logging or not.

Personally, I would like to see the ability to log destination information if one desires, but have text in the drafts to recommend that the destination logging be turned off by default.

Thanks
Senthil

---

From: "Zhouqian (Cathy)" <[email-masked]>
Date: Thu, 25 Jul 2013 03:20:18 +0000

I agree with Senthil that the logging of destination information should be optional. And we will put it in the next version of syslog logging draft.

Best Regards,
Cathy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Senthil Sivakumar (ssenthil)
Sent: Thursday, July 25, 2013 5:21 AM
To: [email-masked]
Subject: [BEHAVE] Issue #1 : Logging drafts and destination information logging

Thanks
Senthil

---

From: Simon Perreault <[email-masked]>
Date: Thu, 25 Jul 2013 09:56:16 +0200

Le 2013-07-24 23:20, Senthil Sivakumar (ssenthil) a écrit :
> Personally, I would like to see the ability to log destination
> information if one desires, but have text in the drafts to recommend
> that the destination logging be turned off by default.

+1

Simon

---

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

<personal opinion, no hats>
I read through the entire document with this question in mind.  In short I believe that
much, but not all, of RFC 4008 is flawed.   The difference comes down to the definition of "flawed".
It's applicable to certain types of NATs but not all NATs.  As such it's not flawed if there's a separate
compliance statement for such types of NATs.   I think the current approach of including all objects
from RFC 4008 in an update to the RFC is the approach I prefer.

In doing this read through, I have a number of other technical issues, which I will put into a separate thread.

-Dave

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Thaler
Sent: Wednesday, July 24, 2013 9:54 PM
To: [email-masked]
Cc: Juergen Schoenwaelder
Subject: [BEHAVE] Consensus call regarding nat-mib

-Dave and Dan