Re: [yang-doctors] Yangdoctors early review of draft-ietf-teas-yang-sr-te-topo-04

Xufeng Liu <xufeng.liu.ietf@gmail.com> Tue, 09 July 2019 15:56 UTC

Return-Path: <xufeng.liu.ietf@gmail.com>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BADE61206EA; Tue, 9 Jul 2019 08:56:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level:
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CvMaMOmvNWK; Tue, 9 Jul 2019 08:56:53 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD4901206E2; Tue, 9 Jul 2019 08:56:45 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id u19so44206267ior.9; Tue, 09 Jul 2019 08:56:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hRk3HR+DxwMinlRSf+O/c6Iy3lk/yZ/10VkFUoqn5WI=; b=eEI9v7BAslEsBEfrBO+TlFbWQKCji+v00nTihZbyCGp0xvV3Y+cVHHfO+ogwRZb3MT qosmddmdHkOl0gWvFxFl6CK6Fz/ibehFz6cFFa34tMgIWl1SkZ8ZQK8m4JcFaVAZaB/o VcIWQdlxhDhAjBJVCJVKsDKBOQ/WcGygW8vq5n2aBV1HdzWLBCm7F03ApasUalvasD5r 95RTvA5FxgOvRa7P6KhAbppNJbGodpVdqiMEvFAdyYYNeU/seKg6Ih885SoM37/g4RIo 5ZLfOfz8yNKFL42miUOjhsP9eWH+xPZnhcw0jmYnkQK1NhB7S0fv4m1/p0DN9NZou/vM JnkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hRk3HR+DxwMinlRSf+O/c6Iy3lk/yZ/10VkFUoqn5WI=; b=qyIC8JVL5ILBGp5dj8mQ5F6dfEohadFK29+STy/w9TFF46t7+XoD7puUu4qEnGpRwI ftfGxXEprzVnvkiKYPDkwFfxJcAqEqMV7RfHQqR3sE6l+oN7n7UnoIUqHQ6mB5zsvTJ+ Fme7J/aI17IUIc/fJoGyMDuez8NdKxcU8GlBe7neJlHvRKVMXf1kPGqGByRsiMPwnw8A UYb0WluIEdIQh95b0dBy2DcMOVCLImg4PO2L+MkwP+S6ofMfGNBEFAL30J+lPvMUShOo 2Hnm5ZlgOr9yt0bKduDtBpHJdqKhB7Xz8oh4ne5YHIJlRbT2VJat43csoOeOcfkDoqUp L4VQ==
X-Gm-Message-State: APjAAAXD7K4cgAIksg28NWl2xy0bvXXoneE9Oec88zmwiAVvZcKLA6EE LO0AjxiAVQmydL1RDox6yPtyC0mDWcIWfJKO611hp0Fy
X-Google-Smtp-Source: APXvYqzS+qHVP8beSRT3rEclbQDiLPKifPJhwdPKht3YbrRn7hK2bu+31ccKppeDCXrCIWGJBH7P545LSm6pY7bcdKk=
X-Received: by 2002:a5d:96d8:: with SMTP id r24mr25354743iol.269.1562687803878; Tue, 09 Jul 2019 08:56:43 -0700 (PDT)
MIME-Version: 1.0
References: <156017177005.10755.7672289550345761824@ietfa.amsl.com>
In-Reply-To: <156017177005.10755.7672289550345761824@ietfa.amsl.com>
From: Xufeng Liu <xufeng.liu.ietf@gmail.com>
Date: Tue, 9 Jul 2019 11:56:33 -0400
Message-ID: <CAEz6PPQ9J88e-DmVYnHa2TiRtLKQrhnhiS+bt1NPUNdV9dwORw@mail.gmail.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Cc: yang-doctors@ietf.org, draft-ietf-teas-yang-sr-te-topo.all@ietf.org, ietf <ietf@ietf.org>, TEAS WG <teas@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000071f498058d419b2d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/GXKKOK7Z_Zer0wohITNcJA-3VTY>
Subject: Re: [yang-doctors] Yangdoctors early review of draft-ietf-teas-yang-sr-te-topo-04
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jul 2019 15:56:56 -0000

Hi Lada,

Thanks for the review. We are addressing some of the issues by
https://tools.ietf.org/html/draft-ietf-teas-yang-sr-te-topo-05. Some of the
discussions are in-line below.

Best regards,
- Xufeng

On Mon, Jun 10, 2019 at 9:02 AM Ladislav Lhotka via Datatracker <
noreply@ietf.org>; wrote:

> Reviewer: Ladislav Lhotka
> Review result: Ready with Issues
>
> This document and YANG module "ietf-sr-topology" contained therein
> contribute two new types to the family of network topology data
> models: segment routing and segment routing traffic engineering
> topologies. The document also provides a companion module
> "ietf-sr-topology-state" intended for non-NMDA implementations.
>
> >From the YANG point of view, both modules are in a relatively good
> shape. Also, as far as I can tell, they satisfy the requirements
> specified in RFC 8345.
>
> The example instance data contained in Appendix B successfully passes
> formal validation against the date model, which is far from
> commonplace for early versions of documents. See however comment #1
> below.
>
> **** Comments
>
> 1. I have argued several times that using URIs as identifiers of all
>    network topology objects in RFC 8345 is an overkill.

Xufeng]: Agree with you on this, but since the type has been published we
need to figure out the way to fit into it. It is clear for what we need to
do here in this case, so it is appreciated if you can provide a suggestion.

> Now, the
>    present draft demonstrates the consequences: id values used in
>    many places of the example data (Appendix B) are not valid URIs!
>    For example, "link-id" leaves have values like
>    "D1,1-2-1,D2,2-1-1", which is not a URI.
>
>    This type violation isn't caught by validating tools because the
>    "ietf-inet-types:uri" type doesn't specify a regular expession
>    pattern. However, its description states clearly that the type
>    represents URI as defined by STD 66.
>
[Xufeng]: We know that this is not a typical URI, but many of the syntax
components are not relevant here. In term of this particular example, how
does it violate STD66? Specifically Sec 4.2 Relative Reference?
Syntactically can this string be a “path segment” of a “relative-path” (or
“path-noscheme”)?

>
> 2. The module uses (indirectly) the grouping "srlr" from the
>    "ietf-segment-routing-common" module. This grouping defines two
>    leaves, "lower-bound" and "upper-bound". I assume it is expected
>    that the former must not be greater than the latter. This is
>    however not enforced by the data model. My suggestion is to add a
>    "must" statement to the "srlr" grouping corresponding to this
>    constraint.
>
[Xufeng]: We have added a few “must” statements to the module
ietf-sr-topology, and we will work with the authors of
ietf-segment-routing-common to see if the constraint can be added to
ietf-segment-routing-common.

>
> 3. Typos in the module text:
>
>    - description of grouping "sr-topology-type":
>      s/toplogies/topologies/
>
[Xufeng]: Fixed.

>
>    - description of container "sr-mpls":
>      s/Indiates/Indicates/
>
[Xufeng]: Fixed.