[netmod] Re: Yangdoctors last call review of draft-ietf-netmod-rfc6991-bis-16

Jürgen Schönwälder <jschoenwaelder@constructor.university> Mon, 21 October 2024 11:30 UTC

Return-Path: <jschoenwaelder@constructor.university>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B74BC09E1A0; Mon, 21 Oct 2024 04:30:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.243
X-Spam-Level:
X-Spam-Status: No, score=-1.243 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGe_xlqf1K3k; Mon, 21 Oct 2024 04:30:47 -0700 (PDT)
Received: from beadg.de (beadg.de [178.254.54.206]) by ietfa.amsl.com (Postfix) with ESMTP id 89776C169406; Mon, 21 Oct 2024 04:30:44 -0700 (PDT)
Received: from localhost (firewallix.jacobs-university.de [212.201.44.246]) by beadg.de (Postfix) with ESMTPSA id E8FC316A048; Mon, 21 Oct 2024 13:30:43 +0200 (CEST)
Date: Mon, 21 Oct 2024 13:30:42 +0200
From: Jürgen Schönwälder <jschoenwaelder@constructor.university>
To: Martin Björklund <mbj+ietf@4668.se>
Message-ID: <ZxY7Ynth8IZNFALF@alice.eecs.jacobs-university.de>
Mail-Followup-To: Martin Björklund <mbj+ietf@4668.se>, yang-doctors@ietf.org, draft-ietf-netmod-rfc6991-bis.all@ietf.org, last-call@ietf.org, netmod@ietf.org
References: <172537401912.1444563.10355942395544427055@dt-datatracker-68b7b78cf9-q8rsp>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <172537401912.1444563.10355942395544427055@dt-datatracker-68b7b78cf9-q8rsp>
Message-ID-Hash: WOQ2YQK3AMTYNLTBIVSL3UYBDRB6SL5X
X-Message-ID-Hash: WOQ2YQK3AMTYNLTBIVSL3UYBDRB6SL5X
X-MailFrom: jschoenwaelder@constructor.university
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-netmod.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: yang-doctors@ietf.org, draft-ietf-netmod-rfc6991-bis.all@ietf.org, last-call@ietf.org, netmod@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Reply-To: Jürgen Schönwälder <jschoenwaelder@constructor.university>
Subject: [netmod] Re: Yangdoctors last call review of draft-ietf-netmod-rfc6991-bis-16
List-Id: NETMOD WG list <netmod.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/O6fAh3SUQNWmPWDDIkZs3BKeC94>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Owner: <mailto:netmod-owner@ietf.org>
List-Post: <mailto:netmod@ietf.org>
List-Subscribe: <mailto:netmod-join@ietf.org>
List-Unsubscribe: <mailto:netmod-leave@ietf.org>

Thanks for the review Martin. See my responses inline...

On Tue, Sep 03, 2024 at 07:33:39AM -0700, Martin Björklund via Datatracker wrote:
> Reviewer: Martin Björklund
> Review result: Ready with Nits
> 
> Here is my YANG doctor's review of draft-ietf-netmod-rfc6991-bis-16.  
> 
> o  typedef email-address
> 
>   The domain part of "email-address" is different from the type
>   "domain-name".  This looks a bit odd.  If special characters can
>   occur in the domain part of an email address, one would assume that
>   they can occur in a domain name as well.

Email addresses are more complex than just <label@domain-name>. We
meanwhile also received a review suggesting that we support
internationalized email addresses and this likely means u-labels in
the domain name part instead of a-labels we use in the domain-name
type. As a consequence, I believe that capturing all details of valid
email addresses precisely in a regular expression is a flawed idea as
this leads to super complex regular expressions that are hard to get
right (for the interested readers, check our "How can I validate an
email address using a regular expression?" on stack overflow. So I
will revert to a rather course grained regular expression. I will
share more details in my response to the Artart review.
 
> o  typedef protocol-number
> 
>      "The protocol-number type represents an 8-bit Internet
>       protocol number, carried in the 'protocol' field of the
>       IPv4 header or in the 'next header' field of the IPv6
>       header. If IPv6 extension headers are present, then the
>       protocol number type represents the upper layer protocol
>       number, i.e., the number of the last next header' field
>                                          ^^^ ' missing
>       of the IPv6 extension headers.

Fixed in my sources.
 
> o  typedef ipv6-address-and-prefix
> 
>      "The ipv6-address-and-prefix type represents an IPv6
>       address and an associated ipv4 prefix.
> 
>    s/ipv4 prefix/IPv6 prefix/

Fixed in my sources.
 
> o  typedef ipv4-address-and-prefix
> 
>      "The ipv4-address-and-prefix type represents an IPv4
>       address and an associated ipv4 prefix.
> 
>    s/ipv4 prefix/IPv4 prefix/

Fixed in my sources.
 
> o  "schema node instance"
> 
>   This term is used in a few places in ietf-yang-types, for example:
> 
>       A schema node instance of this type will be set to zero (0)
>       on creation
> 
>   This isn't correct, since a schema node is a node in the schema
>   tree, and doesn't have a value.  With RFC 7950 terminology, it would
>   be "a node in the data tree".  It is unfortunate that there is no
>   specific term for this in RFC 7950.
> 
>   Perhaps it would be easier to just write "An instance of this
>   type...".
> 
>   (I know that this was not correct RFC 6991 either)

I suggest we use 'A data tree node using this type' as a replacement
of "A schema node instance of this type'. Since a data tree is defined
in RFC 7950 to be an instantiated tree of any data modeled with YANG,
this should be fix the problem.

/js

-- 
Jürgen Schönwälder              Constructor University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany