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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sun, 17 June 2018 20:06 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 976D6130E51; Sun, 17 Jun 2018 13:06:32 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: secdir@ietf.org
Cc: draft-ietf-opsawg-nat-yang.all@ietf.org, ietf@ietf.org, opsawg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.81.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152926599250.2311.15532810595098738604@ietfa.amsl.com>
Date: Sun, 17 Jun 2018 13:06:32 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/b1hOVzy9Uk8rR1zK5DyKtVoSEDo>
Subject: [secdir] Secdir last call review of draft-ietf-opsawg-nat-yang-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.26
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Jun 2018 20:06:33 -0000

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. If this transitions from
T->F then what is the implementer supposed to do? 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,
hence the suggestion to really put it out of scope rather than try specify it 
fully.)

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.