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

[Adam Roach <[e-mail]>]

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.

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

/a