[I2nsf] Murray Kucherawy's Discuss on draft-ietf-i2nsf-registration-interface-dm-24: (with DISCUSS and COMMENT)

Murray Kucherawy via Datatracker <noreply@ietf.org> Thu, 13 April 2023 05:16 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: i2nsf@ietf.org
Delivered-To: i2nsf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA62C1522B9; Wed, 12 Apr 2023 22:16:31 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Murray Kucherawy via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-i2nsf-registration-interface-dm@ietf.org, i2nsf-chairs@ietf.org, i2nsf@ietf.org, ldunbar@huawei.com
X-Test-IDTracker: no
X-IETF-IDTracker: 10.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Murray Kucherawy <superuser@gmail.com>
Message-ID: <168136299183.46945.16075268953835859122@ietfa.amsl.com>
Date: Wed, 12 Apr 2023 22:16:31 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/OH9uEtLgGCyKwDNrdWwaDwNk7Vg>
Subject: [I2nsf] Murray Kucherawy's Discuss on draft-ietf-i2nsf-registration-interface-dm-24: (with DISCUSS and COMMENT)
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.39
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Apr 2023 05:16:31 -0000

Murray Kucherawy has entered the following ballot position for
draft-ietf-i2nsf-registration-interface-dm-24: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-registration-interface-dm/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'd like to talk about the two SHOULDs in Section 1, the Introduction. 
Normative guidance is normally in the meat of the document where the protocol
material is being presented.  Here, the Introduction says:

* "the security controller SHOULD be able to request the DMS for NSFs that have
the required security capabilities"

* "describes the operations that SHOULD be performed by the Security Controller
and the DMS via the Registration Interface using the defined model"

I think you need a (probably small) section after Section 2 that lays out these
normative requirements for controller behavior if that's what the intent is
here.

If the intent was just a plain old "should" and not a BCP 14-style SHOULD, then
this is a pretty easy fix.  But the language you're using here appears to be
asserting that controllers are expected to behave a particular way.

It also makes me wonder if this shouldn't be updating some other document if
you're extending required behavior of an I2NSF component that was defined
someplace else.  I looked around for a document defining "security controller"
and couldn't find an obvious one, so I'm at a loss for what to suggest.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The shepherd writeup seems to have skipped answering part of the first
question: Why is this the right document status?

I'm also confused by the answer to question 18.