Re: [secdir] Secdir last call review of draft-ietf-opsawg-nat-yang-14

<> Mon, 18 June 2018 07:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E945127598; Mon, 18 Jun 2018 00:10:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.395
X-Spam-Status: No, score=-3.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.795, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Lm8z6HDo7LiV; Mon, 18 Jun 2018 00:10:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8AE63130DEB; Mon, 18 Jun 2018 00:10:21 -0700 (PDT)
Received: from (unknown [xx.xx.xx.70]) by (ESMTP service) with ESMTP id C690DC07D9; Mon, 18 Jun 2018 09:10:19 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by (ESMTP service) with ESMTP id 98C971A0065; Mon, 18 Jun 2018 09:10:19 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0399.000; Mon, 18 Jun 2018 09:10:19 +0200
From: <>
To: Stephen Farrell <>, "" <>
CC: "" <>, "" <>, "" <>
Thread-Topic: Secdir last call review of draft-ietf-opsawg-nat-yang-14
Thread-Index: AQHUBnaxNi2Gt51rukm5BMZI7aoJ46RllBdw
Date: Mon, 18 Jun 2018 07:10:18 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302DF4678E@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [secdir] Secdir last call review of draft-ietf-opsawg-nat-yang-14
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 18 Jun 2018 07:10:24 -0000

Hi Stephen, 

Thank you for the review. 

Please see inline. 


> -----Message d'origine-----
> De : Stephen Farrell []
> Envoyé : dimanche 17 juin 2018 22:07
> À :
> Cc :;;
> Objet : Secdir last call review of draft-ietf-opsawg-nat-yang-14
> Reviewer: Stephen Farrell
> Review result: Has Issues
> I see one major issue:
> 2.1: Logging in NATs and esp. CGNs is clearly sensitive in various ways. I
> think it'd be ok if logging was really out of scope, however, there is a
> logging-enable feature, I think under-specified,  (on page 63) so the
> statement
> in 2.1 seems contradictory to me - if logging is out of scope why is
> logging-enable a flag?.  Presumably if logging-enable transitions from F->T
> then you turn on (some undefined kind of) logging. 

[Med] The intent is not to define the exact set of logging information (e.g., Section 4 of RFC6888), the protocol to use (e.g., RFC8158 or draft-ietf-behave-syslog-nat-logging), etc... but to allow for disabling/enabling such feature (when supported by an implementation). 

If this transitions from
> T->F then what is the implementer supposed to do?

[Med] This transition will have an effect to disable ANY logging feature supported by an implementation. The transition for F to T is more problematic as it requires additional information to be available (e.g., logging server IP address and port, credentials, ...). The document assumes that data is provisioned using other specific modules (syslog, ipfix, etc.).

 I think that illustrates
> the
> under-specification here. The simplest thing might be to really make logging
> out of scope here by deleting the logging-enable thing entirely. (I can
> imagine
> that reaching consensus on a logging control interface would be non-trivial,

[Med] There is already RFC 8158.

> hence the suggestion to really put it out of scope rather than try specify it
> fully.)

[Med] If, with the above clarification, you maintain your comment, then I don't have any objection to remove that optional feature from the module. Please advise. 

> Just one nit:
> The abstract could do with a bit of re-wording as it reads awkwardly.  I'd
> say
> maybe just delete the 1st sentence.

[Med] OK.