[Teas] Yangdoctors early review of draft-ietf-teas-actn-vn-yang-10
Andy Bierman via Datatracker <noreply@ietf.org> Sun, 20 December 2020 15:46 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: teas@ietf.org
Delivered-To: teas@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB5A63A106E; Sun, 20 Dec 2020 07:46:29 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Andy Bierman via Datatracker <noreply@ietf.org>
To: yang-doctors@ietf.org
Cc: draft-ietf-teas-actn-vn-yang.all@ietf.org, teas@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <160847918971.3738.423965928103853275@ietfa.amsl.com>
Reply-To: Andy Bierman <andy@yumaworks.com>
Date: Sun, 20 Dec 2020 07:46:29 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/D9vgIfwsTztWWwfRPd7zBy_Pqu4>
Subject: [Teas] Yangdoctors early review of draft-ietf-teas-actn-vn-yang-10
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Dec 2020 15:46:30 -0000
Reviewer: Andy Bierman
Review result: Ready with Issues
Major Issues:
None
Moderate Issues:
1)
leaf /ap/access-point-list/access-point-id
leaf /vn/vn-list/vn-id
leaf /vn/vn-list/vn-member-list/vn-member-id
These list keys use type inet:uri.
You should consider the implementation complexity here.
Will servers all correctly convert any arbitrary URI to its canonical
representation? The draft should address this issue.
2)
leaf /vn/vn-list/oper-status
leaf /vn/vn-list/admin-status
These objects use vn-status-type, vn-admin-state-type
The use of identities for even simple "up/down" status types
seems extreme. The conformance for an enumeration is clear
(mandatory), but not for an identityref type.
- E.g., Is is mandatory for a vendor to support vn-state-up,down?
A vendor could write their own identities and ignore the standard
identities.
3)
rpc /vn-compute
The procedure for this operation is not explained here.
A full description or reference to normative test is needed.
- what does the server do with the input?
- what output is expected? Any variants based on the inputs
should be explained.
- any interoperability considerations wrt/ use of these
common groupings in this RPC context?
- what errors can occur? Specify any error-tags, etc. that
the server MUST/SHOULD include in the response
Minor Issues:
4)
- naming inconsistent within /ap and /vn
access-point is spelled out and vn is not
Suggest: shorten access-point to ap
5)
- naming a list entry with the the suffix -list is redundant.
YANG lists do not have any conceptual container or way to
reference all the entries (if that what this naming intends)
Suggest:
s/access-point-list/ap/
s/vn-list/vn/
s/vn-member-list/vn-member/
6)
- leaf /vn/vn-list/vn-member-list/src/multi-src
- leaf /vn/vn-list/vn-member-list/dest/multi-dest
Looks like these leafs should each have a default-stmt.
What does it mean if the multi-src-dest feature is supported
but these leafs are missing from the config?
- [Teas] Yangdoctors early review of draft-ietf-tea… Andy Bierman via Datatracker
- Re: [Teas] Yangdoctors early review of draft-ietf… Dhruv Dhody
- Re: [Teas] Yangdoctors early review of draft-ietf… tom petch
- Re: [Teas] Yangdoctors early review of draft-ietf… Andy Bierman
- Re: [Teas] Yangdoctors early review of draft-ietf… tom petch