Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-rfc6087bis-18: (with COMMENT)

Andy Bierman <andy@yumaworks.com> Fri, 09 March 2018 00:08 UTC

Return-Path: <andy@yumaworks.com>
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 A9E2B120727 for <netmod@ietfa.amsl.com>; Thu, 8 Mar 2018 16:08:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 5Klz6Xwb-5Qk for <netmod@ietfa.amsl.com>; Thu, 8 Mar 2018 16:08:35 -0800 (PST)
Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 C3C15124B18 for <netmod@ietf.org>; Thu, 8 Mar 2018 16:08:34 -0800 (PST)
Received: by mail-lf0-x22a.google.com with SMTP id m69-v6so10823075lfe.8 for <netmod@ietf.org>; Thu, 08 Mar 2018 16:08:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bgW8BP0zBPjWEE8iLOoSW5alMTfpGOOXhlMB+PMy4Ng=; b=w1yx3cZfD6u4/5QefOyHyg04bMKlLOpj3hcDo6AccNxtrvw2LI3LR4cx0cWHZSvQCi HNy/J3oTtGeTlPEtc9liRd5VDC+IzlcnrOncvjMp0qA/G2ZQYKRVernb9RRbB4fU5EW+ A3kCM5Iu5Efz+Dx0qGbmZnCPOvpqZOLiU+aAvi2tsjZ7l2fB750uopiPu/YyE1Z9NhaJ LXCMm3DMgKVafSi/xWTHXvlAVr7HHZAQi3tNh5EnCKblZnWWPXkKqLQJ3iOV+FfFJ4lq 8o64RZHcxOFP0ATJ62FQQFRcilGSBJ9Ph4V9+px/EGiPvWXRfxRmk+4ZyhrK7Ytz2gIm 2tkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bgW8BP0zBPjWEE8iLOoSW5alMTfpGOOXhlMB+PMy4Ng=; b=p1v+IDalN7jBWL+9rMpsPhuhlDtRhq9qnIWHqSZ0uUiFJN9bksh7UleICdycEq8C8q Qf6X+bRvkpwpcLFueUedEWlfAFM0wiDMJbF2AZJ1mFeUciBTfbpXTwHaZFzZAfvsEp7A tyHgmXhQG5sILuKPEgk+I8O2NndVWV9UuN4zY68vsqA4F0h8Vv+kUJmLSP7Wm0o6/GYk E4NZep51Hd68fyySicxtbT83frvmB6YOEfDb51xsBUn4nSGYfwUYROz79+3B1xXsuLFD fU0tedsDlqpbTP9Pjgk55FBiopnUky8mffHRfu25XxuDlUYICkAuD9aWj//jnv02c9fM 2X/A==
X-Gm-Message-State: AElRT7FUCRjWujXzWeHzyA3lREpfe+OPG1UlzXsXbBwtD3u6zJJmU8tU 3BPwx7TZh5Lp6aC+yPsw/OYt9ok/9/1u0m2JcAgP+A==
X-Google-Smtp-Source: AG47ELsSw4gXhKKniH5VDYX07g0cFmm9kS1jJwj/nFhtRaw6sBlWFOjzJPAuAVz9mMOKNjVBINmsJwvgOxvVWHrHqHA=
X-Received: by 10.25.207.145 with SMTP id f139mr20674968lfg.75.1520554112951; Thu, 08 Mar 2018 16:08:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.21.210 with HTTP; Thu, 8 Mar 2018 16:08:32 -0800 (PST)
In-Reply-To: <e627d122-a709-c41c-b58a-b5890b8d2103@nostrum.com>
References: <152050158005.21412.3389388204390015375.idtracker@ietfa.amsl.com> <CABCOCHSmCioJPNM5b9J-5WCsXe_J2jMzKKCD8fw02uh-D5nNdA@mail.gmail.com> <e627d122-a709-c41c-b58a-b5890b8d2103@nostrum.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 8 Mar 2018 16:08:32 -0800
Message-ID: <CABCOCHSLAKZCyACHgQvdqU6TLLdLBtY9izh7+2Pi4Qc3Z2-Sjw@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-netmod-rfc6087bis@ietf.org, NetMod WG Chairs <netmod-chairs@ietf.org>, Kent Watsen <kwatsen@juniper.net>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="001a11412078c3bcc10566ef9764"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/xAAw0vttEoCQZrhYqDr_Cygx1ik>
Subject: Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-rfc6087bis-18: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Mar 2018 00:08:38 -0000

On Thu, Mar 8, 2018 at 3:55 PM, Adam Roach <adam@nostrum.com>; wrote:

> Thanks for your quick response! I have some additional comments inline.
>
> On 3/8/18 2:00 PM, Andy Bierman wrote:
>
>
> ------------------------------------------------------------
>> ---------------
>>
>> §3:
>>
>> >  YANG data model modules under review are likely to be contained in
>> >  Internet-Drafts.  All guidelines for Internet-Draft authors MUST be
>> >  followed.  The RFC Editor provides guidelines for authors of RFCs,
>> >  which are first published as Internet-Drafts.  These guidelines
>> >  should be followed and are defined in [RFC7322] and updated in
>> >  [RFC7841] and "RFC Document Style" [RFC-STYLE].
>>
>> Maybe include a pointer to draft-flanagan-7322bis also, as this document
>> is in
>> the process of being revised.
>>
>
>
> This does not appear to be a WG document, so it seems premature to include
> it
>
>
> Like RFC 7322 before it, 7322bis will be published as part of the IAB
> stream, not part of the IESG stream, so it will never be a WG document. The
> "flanagan" in "draft-flanagan" is Heather Flanagan, the RFC editor. While
> the contents may continue to evolve, I don't think there's any doubt that a
> revision of the document is in the works, and it's all but guaranteed that
> such revision will be published at some point and obsolete RFC 7322.
>
> To be clear: I'm okay with you leaving the text as-is, but I think that
> the additional citation would be an improvement.
>
>

OK, I will add it to the Informative References section



> ------------------------------------------------------------
>> ---------------
>>
>> §3.8:
>>
>> >  If there are no
>> >  IANA considerations applicable to the document, then the IANA
>> >  Considerations section stating that there are no actions is removed
>> >  by the RFC Editor before publication.
>>
>> I believe that the current state of play is that removal is left to the
>> authors'
>> discretion, and that the IANA has a weak preference for leaving in
>> sections that
>> say "No actions are requested of IANA." This may change. Rather than try
>> to
>> capture the (potentially changing) state of play, my suggestion is to
>> remove the text I quote above.
>>
>>
> This was just changed to "might be removed"
>
> Is that good enough?
>
>
> Yes, that seems fine.
>
>
>
>
>> ------------------------------------------------------------
>> ---------------
>>
>> §4.11.2:
>>
>> >  The following typedef from [RFC6991] demonstrates the proper use of
>> >  the "pattern" statement:
>> >
>> >      typedef ipv4-address-no-zone {
>> >        type inet:ipv4-address {
>> >          pattern '[0-9\.]*';
>> >        }
>> >        ...
>> >      }
>>
>> By contrast, RFC 6021 has a somewhat more complex production:
>>
>>      pattern
>>          '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
>>        +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
>>        + '(%[\p{N}\p{L}]+)?';
>>
>> Is there any consensus on how complex the pattern validation should be?
>> I've
>> seen some YANG modules with patterns that occupied more than half a page.
>> Is
>> that encouraged, discouraged, or neither? It seems some guidance on this
>> specific issue would be useful, as the currently published modules appear
>> to be
>> all over the map on this topic.
>>
>>
> Not changing any text since the pattern complexity depends on the structure
> of the text that is being modeled.
>
>
> It's a little more than that; it comes down to the purpose of the regex,
> and how much validation is expected to be provided. For example, ignoring
> the interface designation, the validation of IP addresses between the two
> productions above is radically different. The second one is set up so that
> anything it matches will be a syntactically correct IP address. The first
> one, by contrast, would accept any of the following as valid:
>
>
>    - 999.999.999.999
>    - 1.3.6.1.2.1.2.2.1.3
>    - 17
>    - .......
>
>
> This seems a bit more than academic to me: given that modules are included
> into other modules, wild inconsistencies in validation philosophies can be
> surprising to users. For example, if an operator gets used to the syntax
> for IP addresses generating warnings or errors when they are out of range,
> then they may be frustrated to discover that IP addresses in other
> locations are not.
>
> Clearly, the items that have already been published can't be changed, but
> it seems like there is room for guidance about whether to optimize for
> simple regexes, or for more rigorous ones.
>


I don't really know what a guideline should say about patterns.
I will try to add something that says to document the pattern limitations
and keep the pattern as simple as possible,





>
> /a
>


Andy