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

From: Adam Roach <[email-masked]>
Date: Thu, 08 Mar 2018 01:33:00 -0800

Adam Roach has entered the following ballot position for
draft-ietf-netmod-rfc6087bis-18: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this document. It is well-written and I believe it will be helpful.
Comments follow.

---------------------------------------------------------------------------

General:

I've reviewed a couple of YANG modules where the indentation and/or wrapping was
awkward and inconsistent. I would love to see guidance in this document that
authors be careful to run their modules through pyang (or a similar tool) to
ensure consistent formatting. It may be worthwhile to give an example of the
exact commandline invocation of pyang to achieve a formatting that is consistent
with existing published modules.

---------------------------------------------------------------------------

§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.

---------------------------------------------------------------------------

§3.6:

>  Example YANG modules and example YANG fragments MUST NOT contain any
>  normative text, including any reserved words from [RFC2119]

Please clarify that this means only all-uppercase reserved words.

---------------------------------------------------------------------------

§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.

---------------------------------------------------------------------------

§3.12:

>  Each specification that defines one or more modules SHOULD contain
>  usage examples, either throughout the document or in an appendix.

Many of the YANG documents I've reviewed over the past year have contained
examples that show only IPv4 addresses. The IAB has issued guidance that
examples in standards track documents use either a mix of IPv4 and IPv6
addresses or IPv6 addresses exclusively (see
<https://www.iab.org/2016/11/07/iab-statement-on-ipv6/>). This section would do
authors and reviewers a great favor by reiterating or pointing to this guidance.

---------------------------------------------------------------------------

§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.

---------------------------------------------------------------------------

§10.2:

>   [RFC-STYLE]
>              Braden, R., Ginoza, S., and A. Hagens, "RFC Document
>              Style", September 2009,
>              <http://www.rfc-editor.org/rfc-style-guide/rfc-style>.

This URL returns a 404.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Mar 2018 12:32:24 +0100

RFC 6021 does not define ipv4-address-no-zone, you seem to compare
apples vs. oranges here. The pattern used in the definition of
ipv4-address is pretty much the same in both versions. The reason why
the ipv4-address-no-zone typedef has a rather short pattern is that
the long pattern of inet:ipv4-address still applies (since
ipv4-address-no-zone is derived from ipv4-address).

How detailed should a pattern be? There is as, far as I can tell, no
simply answer or guideline or even consensus on this. It is usually
good if pattern are strict but then complex pattern can get difficult
to read and understand and so there is an engineering trade-off to be
made.

The only thing I could imagine to say in section 4.11.2. is that it is
a good idea to write test cases for longer pattern to ensure they do
what was intended. (This is what I did for the pattern in RFC 6991.) I
do not think it makes sense to publish test cases but it may be useful
to share them during the development of the specification and during
the YANG doctor review.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Benoit Claise <[email-masked]>
Date: Thu, 8 Mar 2018 14:21:01 +0100

Hi Adam,
> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/
We've been in discussion with the RFC editor lately (Sandy, cc'ed) on 
this important topic.
And also with IANA, which should be keep the source of truth for IETF 
YANG modules (but this is not that easy. More on this later).

 From a YANG language point of view, as long as the module validates, 
we're good.
But OTOH, we do require some common style from the published modules, 
for example we want all lines to be properly indented and we require 
space characters between some tokens etc. Consistency is easier for readers

With the RFC editors, we agreed on this high level process:
     - extract the YANG file
     - run pyang -f yang --yang-canonical --keep-comments FILE
     - ask the authors if they are okay with the output file (before 
replacing it in the RFC (to be) for review)
     - assuming they agree, update the RFC
     - then transmit the module to IANA for publication.

During the discussion, Martin Bjorklund (THE pyang main developer), 
expressed:

      Such a tool will of course blindly produce consistent output, but
      sometimes a human needs to polish the result anyway.

      ...

    Unfortunately, I don't think the tool is quite ready to be used in an
    automated fashion.  It does produce consistent output wrt indentation
    and quotes etc, but it doesn't do a good job when it comes to handling
    long lines.  As an example, if the original module has:

           pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-'
                 + '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}';

    the tool will print:

           pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}';

    I have just released a new version of pyang, 1.7.4, which fixes one
    issue with "-f yang" that has been discussed on the mailing list.

I see two solutions from here.
1. we mention "pyang -f yang --yang-canonical --keep-comments FILE" in 
RFC6087bis, with a warning such as: "As the tool matures, a human might 
need to polish the results"
2. we don't mention "pyang -f yang --yang-canonical --keep-comments 
FILE" in RFC6087bis, but we ask the YANG doctors to run the tests.

Considering that not many people know those specific pyang parameters, I 
would favor solution 1.

Feedback?

Regards, Benoit

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Mar 2018 15:15:08 +0100

On Thu, Mar 08, 2018 at 02:21:01PM +0100, Benoit Claise wrote:
> RFC6087bis, with a warning such as: "As the tool matures, a human might need
> to polish the results"
> 2. we don't mention "pyang -f yang --yang-canonical --keep-comments FILE" in
> RFC6087bis, but we ask the YANG doctors to run the tests.

I am not sure it is a good idea to hard code command line options of
specific tools in a BCP document. We should require that things are
consistently indented and stay away from the advice of the day how
to achieve that.

/js

---

From: Benoit Claise <[email-masked]>
Date: Thu, 8 Mar 2018 15:24:52 +0100

> consistently indented and stay away from the advice of the day how
RFC 6087 mentions "pyang --ietf"  and 
draft-ietf-netmod-yang-tree-diagrams mentions "pyang -f tree 
--tree-line-length 50"

If not in RFC6087bis, where would we document this?
As a rhetorical question: How many of the YANG doctors were aware of and 
are enforcing this command?

Background Info.
Typical question I've been receiving lately (in this case from IANA):
When requesting the final files from the RFC-Editor, the file they 
extracted using their tool and the yang modules appear to have a lot of 
blank space in them. Is this OK?

Regards, Benoit

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 08 Mar 2018 15:31:40 +0100 (CET)

Benoit Claise <[email-masked]> wrote:
> >> FILE" in

Maybe we can say that "for example, a tool like pyang can be used ..."

> As a rhetorical question: How many of the YANG doctors were aware of
> and are enforcing this command?
> 
> Background Info.
> extracted using their tool and the yang modules appear to have a lot
> of blank space in them. Is this OK?

The extraction tools often produce additional blank lines b/c it is
tricky to know how many blank lines were in the original module when
all you have is the RFC in ascii.

/martin

---

From: Benoit Claise <[email-masked]>
Date: Thu, 8 Mar 2018 16:17:45 +0100

> Maybe we can say that "for example, a tool like pyang can be used ..."
This is a good compromise I would say.

Regards, Benoit
> .

---

From: Adam Roach <[email-masked]>
Date: Thu, 8 Mar 2018 09:29:38 -0600

> This is a good compromise I would say. 

I'm happy with this as well.

/a

---

From: Andy Bierman <[email-masked]>
Date: Thu, 8 Mar 2018 12:00:27 -0800

> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/
I added text that says consistent indentation and formatting SHOULD be used.

This does not appear to be a WG document, so it seems premature to include
it

OK

This was just changed to "might be removed"

Is that good enough?

OK

Not changing any text since the pattern complexity depends on the structure
of the text that is being modeled.

changed top http://www.rfc-editor.org/styleguide/

Andy

---

From: Adam Roach <[email-masked]>
Date: Thu, 8 Mar 2018 17:55:17 -0600

Thanks for your quick response! I have some additional comments inline.

On 3/8/18 2:00 PM, Andy Bierman wrote:
> 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.

Yes, that seems fine.

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.

/a

---

From: Andy Bierman <[email-masked]>
Date: Thu, 8 Mar 2018 16:08:32 -0800

On Thu, Mar 8, 2018 at 3:55 PM, Adam Roach <[email-masked]> wrote:

> 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.
>

OK, I will add it to the Informative References section

> 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,

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 9 Mar 2018 07:28:03 +0100

On Thu, Mar 08, 2018 at 05:55:17PM -0600, Adam Roach wrote:
> 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

This is a misunderstanding how YANG works. ipv4-address-no-zone is
derived from ipv4-address and hence all the ipv4-address rules apply
as well. Your examples will all be rejected.
 
> 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.

In some cases, patterns are kept simpler but more specific text is in
the description statement. A pattern is one of several mechanisms to
constrain the value space.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 9 Mar 2018 07:29:33 +0100

> and keep the pattern as simple as possible,

I object to a statement that "pattern should be as simple as
possible".

/js

---

From: Benoit Claise <[email-masked]>
Date: Fri, 9 Mar 2018 15:22:26 +0100

Hi,
> I object to a statement that "pattern should be as simple as
The only guideline that makes sense is: "the pattern must be correct" or 
"the pattern must be meaningful". Not even worth mentioning, as this is 
so obvious!
Whether it's a simple or a complex regex is orthogonal here: the pattern 
must fulfill its job.

Adam, if you still believe something is missing, can you suggest some text.

Regards, Benoit

---

From: Robert Wilton <[email-masked]>
Date: Fri, 9 Mar 2018 14:58:31 +0000

Hi Adam,

> Thanks for your quick response! I have some additional comments inline.
<snip>
> for simple regexes, or for more rigorous ones.
I agree with your general sentiment.  In fact I had a long protracted 
discussion on this point on the Netmod WG alias.

Sometimes pattern statements can be both correct and also concise and 
readable.  This is the easy case.

But for other regular expressions (e.g. route-target in rfc8294) there 
is a clear choice whether to make the regex as precise as possible 
(minimizing false values), or to make it concise and hopefully 
readable/verifiable but allowing for more false values.

My personal preference is for a simpler, but less precise regex over a 
more precise, but hard to visually verify, regex.  E.g. I'm not a fan of 
using regular expressions to limit the range of numerical values.  I 
know that validating regular expression matches is computationally 
expensive, so I wonder if implementations will end up replacing these 
larger regular expressions with custom written verification code that is 
more performant.  But, as I recall, I was in the rough on this issue.

If the consensus is that they should be as accurate as is feasible then 
I think that it would be helpful if the guidelines state this as a 
goal.  This would seem to ensure consistency in the YANG models that are 
being standardized.

Thanks,
Rob

>
> /a
>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 9 Mar 2018 15:35:40 +0000

From: netmod <[email-masked]> on behalf of "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked]>
Date: Friday, March 9, 2018 at 9:59 AM
To: Adam Roach <[email-masked]>, Andy Bierman <[email-masked]>
Cc: NetMod WG Chairs <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG <[email-masked]>, NetMod WG <[email-masked]>
Subject: Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-rfc6087bis-18: (with COMMENT)

Hi Adam,

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 agree with your general sentiment.  In fact I had a long protracted discussion on this point on the Netmod WG alias.

Sometimes pattern statements can be both correct and also concise and readable.  This is the easy case.

But for other regular expressions (e.g. route-target in rfc8294) there is a clear choice whether to make the regex as precise as possible (minimizing false values), or to make it concise and hopefully readable/verifiable but allowing for more false values.

My personal preference is for a simpler, but less precise regex over a more precise, but hard to visually verify, regex.  E.g. I'm not a fan of using regular expressions to limit the range of numerical values.  I know that validating regular expression matches is computationally expensive, so I wonder if implementations will end up replacing these larger regular expressions with custom written verification code that is more performant.  But, as I recall, I was in the rough on this issue.

If the consensus is that they should be as accurate as is feasible then I think that it would be helpful if the guidelines state this as a goal.  This would seem to ensure consistency in the YANG models that are being standardized.

As the editor of RFC 8294, I can confirm that we did not reach consensus on whether to use easily understandable regular expressions versus regular expressions that precisely validate the input string. During the protracted Working Group last call for this document, there were strong proponents of both lines of thinking. Given that we had started with the more complex precise regular expressions, that is what was retained (e.g., for BGP route-targets).

     typedef route-target {
       type string {
         pattern
           '(0:(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
         +     '6[0-4][0-9]{3}|'
         +     '[1-5][0-9]{4}|[1-9][0-9]{0,3}|0):(429496729[0-5]|'
         +     '42949672[0-8][0-9]|'
         +     '4294967[01][0-9]{2}|429496[0-6][0-9]{3}|'
         +     '42949[0-5][0-9]{4}|'
         +     '4294[0-8][0-9]{5}|429[0-3][0-9]{6}|'
         +     '42[0-8][0-9]{7}|4[01][0-9]{8}|'
         +     '[1-3][0-9]{9}|[1-9][0-9]{0,8}|0))|'
         + '(1:((([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|'
         +     '25[0-5])\.){3}([0-9]|[1-9][0-9]|'
         +     '1[0-9]{2}|2[0-4][0-9]|25[0-5])):(6553[0-5]|'
         +     '655[0-2][0-9]|'
         +     '65[0-4][0-9]{2}|6[0-4][0-9]{3}|'
         +     '[1-5][0-9]{4}|[1-9][0-9]{0,3}|0))|'
         + '(2:(429496729[0-5]|42949672[0-8][0-9]|'
         +     '4294967[01][0-9]{2}|'
         +     '429496[0-6][0-9]{3}|42949[0-5][0-9]{4}|'
         +     '4294[0-8][0-9]{5}|'
         +     '429[0-3][0-9]{6}|42[0-8][0-9]{7}|4[01][0-9]{8}|'
         +     '[1-3][0-9]{9}|[1-9][0-9]{0,8}|0):'
         +     '(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
         +     '6[0-4][0-9]{3}|'
         +     '[1-5][0-9]{4}|[1-9][0-9]{0,3}|0))|'
         + '(6(:[a-fA-F0-9]{2}){6})|'
         + '(([3-57-9a-fA-F]|[1-9a-fA-F][0-9a-fA-F]{1,3}):'
         +     '[0-9a-fA-F]{1,12})';
       }

       description
         "A Route Target is an 8-octet BGP extended community
          initially identifying a set of sites in a BGP VPN
          (RFC 4364).  However, it has since taken on a more general
          role in BGP route filtering.  A Route Target consists of two
          or three fields: a 2-octet Type field, an administrator
          field, and, optionally, an assigned number field.

          According to the data formats for types 0, 1, 2, and 6 as
          defined in RFC 4360, RFC 5668, and RFC 7432, the encoding
          pattern is defined as:

          0:2-octet-asn:4-octet-number
          1:4-octet-ipv4addr:2-octet-number
          2:4-octet-asn:2-octet-number
          6:6-octet-mac-address

          Additionally, a generic pattern is defined for future
          Route Target types:

          2-octet-other-hex-number:6-octet-hex-number

          Some valid examples are 0:100:100, 1:1.1.1.1:100,
          2:1234567890:203, and 6:26:00:08:92:78:00.";
       reference
         "RFC 4360: BGP Extended Communities Attribute.
          RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs).
          RFC 5668: 4-Octet AS Specific BGP Extended Community.
          RFC 7432: BGP MPLS-Based Ethernet VPN.";
     }

I don’t know that we want to debate this again during the IESG comments for RFC6087BIS. .

Thanks,
Acee

Thanks,
Rob

/a

netmod mailing list

[email-masked]<mailto:[email-masked]>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 9 Mar 2018 16:54:34 +0100

On Fri, Mar 09, 2018 at 03:22:26PM +0100, Benoit Claise wrote:
> "the pattern must be meaningful". Not even worth mentioning, as this is so
> obvious!

Properties such as 'correct' or 'meaningful' are not easy to define
for pattern. Pattern can have different levels of strictness and often
greater strictness comes at the price of increased complexity of a
pattern.  There is no general advice that can be given how to trade
strictness of a pattern against pattern complexity.

That said, pattern can be incorrect (rejecting input that they are
supposed to accept). If pattern become increasingly complex to
increase their strictness, then it is important that they are
sufficiently tested not to be incorrect.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 9 Mar 2018 08:06:19 -0800

On Fri, Mar 9, 2018 at 7:54 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> so

I came up with 2 sentences to add to 6087bis:

#1)

If the patterns used in a type definition have known limitations
such as false positive matches, then these limitations
SHOULD be documented within the typedef or data definition.

#2)

Simpler patterns SHOULD be used instead of more complex variants,
if possible, because they are easier to read.

IMO #1 should be added, especially if YANG documents have patterns
that are known to be incorrect.  But I want to leave out #2.

YANG modules (including patterns) are source code for automation tools.
>From that perspective, the only thing that matters is the correctness of
the automation tool.  False positives and false negatives are both bad.
The readability of the source code is not that relevant here.

I would prefer to have the description-statement define the acceptable
values
than a pattern that is wrong.

/js
Andy

---

From: Adam Roach <[email-masked]>
Date: Fri, 9 Mar 2018 14:17:11 -0600

On 3/9/18 9:35 AM, Acee Lindem (acee) wrote:
>
> As the editor of RFC 8294, I can confirm that we did not reach 
> consensus on whether to use easily understandable regular expressions 
> versus regular expressions that precisely validate the input string. 
> During the protracted Working Group last call for this document, there 
> were strong proponents of both lines of thinking. Given that we had 
> started with the more complex precise regular expressions, that is 
> what was retained (e.g., for BGP route-targets).
>

Okay, this is helpful input.

I raised the issue because rfc6087bis appears to be designed as a style 
guide. Having reviewed several YANG modules and seeing somewhat varied 
philosophies in this regard, it seemed like a prime candidate for 
including in such a guide, and I brought it up only because it was 
conspicuous by its absence. I wasn't intending to express a preference 
for one end of the spectrum or the other; I simply thought it was 
something that belonged in the document.

I can't determine from the conversation so far whether the discussions 
on rfc6087bis explicitly included this topic and decided not to cover 
it, or whether it was simply not brought up. However, the quoted text 
above tells me that reaching a quick consensus by the community of 
interest on the topic is pretty unlikely. Consequently, including such 
guidance probably means that the working group will need to have 
additional conversations about what such guidance would say. I'll leave 
it to the responsible AD to determine whether the document should go 
back to the working group for explicit consideration of this topic, or 
whether it should move forward without any guidance on the topic of 
regex completelness-versus-simplicity trade-offs.

/a

---

From: Kent Watsen <[email-masked]>
Date: Fri, 9 Mar 2018 20:22:47 +0000

> SHOULD be documented within the typedef or data definition.

I like this, but it would be better to also mention false-negative
matches, as it gets people to think about the other side too.

> if possible, because they are easier to read.

I think we should stay silent on this point.   Maybe we could that there is
a known tradeoff between pattern complexity and verifiability, which is
left to the module designer as a consideration.

> Andy

Kent