[I2nsf] Yangdoctors last call review of draft-ietf-i2nsf-registration-interface-dm-04

Reshad Rahman via Datatracker <noreply@ietf.org> Fri, 28 June 2019 21:17 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 BAB1A12093A; Fri, 28 Jun 2019 14:17:22 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Reshad Rahman via Datatracker <noreply@ietf.org>
To: <yang-doctors@ietf.org>
Cc: i2nsf@ietf.org, draft-ietf-i2nsf-registration-interface-dm.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.98.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Reshad Rahman <rrahman@cisco.com>
Message-ID: <156175664267.21931.10329030969352120108@ietfa.amsl.com>
Date: Fri, 28 Jun 2019 14:17:22 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/g96krn6NzCJNcEalmb5dIEabx8w>
Subject: [I2nsf] Yangdoctors last call review of draft-ietf-i2nsf-registration-interface-dm-04
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 28 Jun 2019 21:17:29 -0000

Reviewer: Reshad Rahman
Review result: On the Right Track

YANG Doctor review of draft-ietf-i2nsf-registration-interface-dm-04 (by Reshad

Major comments:
- Look at appendix B of RFC8407 for an example of how a YANG module should be
structured. This document does not abide to that. - Poor descriptions e.g.
"nsf-name" for leaf "nsf-name" etc - prefix "iiregi" doesn't seem right. What
about "nsfreg"? Probably needs coordination with the other I2NSF YANG modules
to have consistency between the prefixes. I see that YD Acee suggested
"nsfintf" for draft-ietf-i2nsf-nsf-facing-interface-dm-06 - No unit specified
for bandwidth, processing (performance) - nsf-address is IPv4 specific -
Security considerations should list the nodes as per section 3.7 of RFC8407. -
Should this document be informational since 8329 is informational? - Section 2
should use RFC8174 also - Refer to RFC8407 instead of 6807 (YANG Guidelines) -
Examples should use IPv6 as examples (use the range from RFC3849). Kudos for
all the examples.

Minor comments and questions:
- The YANG trees such as Figure 6, 7 etc don't show the contents of the
groupings. So they don't help much. - nsf-port-address should be nsf-port? -
Section 4, last bullet. I am not an expert on I2NSF so not clear to me why this
query is needed, is it because NSF may not re-register after their capabilities
have been updated? Might be worth adding some explanation. - Have the examples
been validated?