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

[Andy Bierman <[e-mail]>]

On Thu, Mar 8, 2018 at 3:55 PM, Adam Roach <[e-mail]> 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