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

[Juergen Schoenwaelder]

On Thu, Mar 08, 2018 at 04:08:32PM -0800, Andy Bierman wrote:
> 
> 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,
> 

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

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Juergen Schoenwaelder]

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

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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-syslog-model-23: (with COMMENT)

[Adam Roach]

On 3/8/18 12:18 PM, Clyde Wildes (cwildes) wrote:

Adam,

An earlier version of the model (draft-ietf-netmod-syslog-model-08 and prior) 
included “terminal” as a syslog destination which addresses your requirement 
below:

 +--rw terminal {terminal-action}?
 |  +--rw all-terminals!
 |  |  +--rw log-selector
 |  | +--rw (selector-facility)
 |  | |  +--:(no-log-facility)
 |  | |  |  +--rw no-facilities?   empty
 |  | |  +--:(log-facility)
 |  | | +--rw log-facility* [facility]
 |  | |+--rw facility union
 |  | |+--rw severity union
 |  | |+--rw severity-operator?   enumeration 
{selector-sevop-config}?
 |  | +--rw pattern-match?   string {selector-match-config}?
 |  +--rw terminal* [name] {terminal-facility-user-logging-config}?
 | +--rw namestring
 | +--rw log-selector
 |+--rw (selector-facility)
 ||  +--:(no-log-facility)
 ||  |  +--rw no-facilities?   empty
 ||  +--:(log-facility)
 || +--rw log-facility* [facility]
 ||+--rw facility union
 ||+--rw severity union
 ||+--rw severity-operator?   enumeration 
{selector-sevop-config}?
 |+--rw pattern-match?   string {selector-match-config}?

A consensus of the group was that it was best to remove this destination in the 
model as a simplification, and that vendors that supported same could add it 
back through an augmentation.


Thanks for the history -- that's useful to know. I don't have any desire 
to re-open a settled issue, so please don't read my response as a 
request to go back to the older, more complex model.


My concern now is that the unstated assumption above isn't indicated in 
the document; and absent such a treatment, I fear that some vendors may 
do what you expect (extend the model), while some may do what I 
mentioned (expect terminal syslog output to be provisioned via a special 
filesystem node using the "file" subtree). This ambiguity doesn't seem 
ideal.


I would suggest that the document have text specifically indicating that 
terminal output with requirements more complex than the console subtree 
currently provides are expected to be supported via vendor extensions 
rather than handled via the file subtree.


/a

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-17.txt

[Mahesh Jethanandani]

Kent,

> On Mar 7, 2018, at 1:55 PM, Kent Watsen  wrote:
> 
> [To all those that said this draft was ready, really?]
> 
> 
> Hi Mahesh,
> 
> Thanks for the update.  I found some more issues.  Some must be fixed, 
> others are nits, and might be caught by the RFC Editor.  But I think
> that it's embarrassing to receive comments for such things from the 
> IESG, as is recently the case for the syslog draft, so please see 
> what you can do.
> 
> Thanks,
> Kent
> 
> 
> From Idnits:
> 
>  ** There are 6 instances of too long lines in the document, the longest one
> being 7 characters in excess of 72.

Hmm. The idnits at submission time did not complain. Will apply the new script 
that you provided to make sure I wrap them around.

> 
>  You wrote before that it was "Fixed", but it's still here?  Note: "**" is
>  an error (idnits label)
> 
>  -- The document has examples using IPv4 documentation addresses according
> to RFC6890, but does not use any IPv6 documentation addresses.  Maybe
> there should be IPv6 examples, too?
> 
>  I don't feel strongly about this, but if it's easy enough to do...
> 
> In the Abstract:
>  - I think the word "an" is missing (e.g., an ACL)

Added.

> 
> In the Introduction:
>  - should "ordered-by-user" be "ordered-by user" to avoid confusion, or 
> perhaps say it another way?

How about this in both the Abstract and the Introduction.

OLD:
ACL is a ordered-by-user set of rules

NEW:
An ACL is a set of rules, in an order set by the user

>  - what does "a tuple of" mean?  Can this be restated?

How about this?

OLD:
The match criteria consist of a tuple of packet header match criteria and can 
have metadata match criteria as well.

NEW:
The match criteria consist of packet header matches, and or or metadata as 
described below:

>  - s/In case vendor supports it/In case a vendor supports it/ ?

Ok.

>  - "The list of X is endless depending on...".  Is "endless" the right word, 
> perhaps restate?
OLD:
The list of potential actions is endless

NEW:
The list of potential actions is limitless

>  - same sentence as above, should "networked devices" be "network" or 
> "networking" devices?

Will change “networked devices” to “networking devices”.

> 
> In Section 3:
>  - "A network system usually have a list of ACLs"  (s/system/systems/ or 
> s/have/has/?)

s/have/has/.

>  - "The match criteria consist of packet header matching" - is consist the 
> right word?

How would you restate it? (After I have s/consist/consists/)

>  - "It as also possible for ACE to match on metadata"  s/as/is/ and s/ACE/an 
> ACE/

Ok

>  - "When applied to interfaces of a networked device, the ACL is applied in a 
> direction
> which indicates if it should be applied to packet entering (input) or 
> leaving the
> device (output)."  - restate to talk about "ingress" and "egress”?

How about:

When applied to interfaces of a networked device, the ACL is applied in a 
direction which indicates if it should be applied to ingress interface (input) 
or egress interface (output).

>  - "An example in the appendix shows how to express it in YANG model." - 
> either this
>is not true, or the sentence should not be at the end of this paragraph

Removed.

> 
> In Section 3.1:
>  - s/and must statements/and 'must' statements/

Done and s/if-feature/‘if-feature’/

>  - s/define new "matches" choice/define a new "matches" choice/ ?

Done.

> 
> In Section 4.1:
>  - "ietf-access-control-list" is the standard top level module for access 
> lists
>  - what does this mean?

OLD:
"ietf-access-control-list" is the standard top level module for access lists

NEW:
"ietf-access-control-list" is the top level module for access lists

>  - The "access-lists" container stores a list of "acl". - s/stores/has or 
> contains?/ 

s/stores/has/

>  - "...that can be used to determine which rule was matched upon" - not sure 
> if this
>part is needed, or maybe better restated ", which can later be used to 
> determine…"?

Ok.

>  - s/ability for ACL's to be/ability for ACLs to be/

Ok.

> 
> In Section 4.1 (in the YANG module):
>  - A number of identities read "ACL that primarily matches...".  Is 
> "primarily"
>an accurate word? - if so, then do we need to say anything about when it's
>not the case?

As one of the text says. It primarily matches IPv4, and does not match either 
ethernet or IPv6 headers. Such ACL types are different from the mixed ACL types 
that might match on a combination of ethernet and IPv4 headers etc.

>  Separately, s/ACL/an ACL/?

Ok.

>  - A number of features read "Device can support..." - s/Device/The device/?

Ok.

>  - "It can have one or more Access Control Lists" - lists should be singular.

Really? English grammar says that if a sentence has both a singular and a 
plural, the one nearest to the subject is the one you select.

>  - "An Access Control List(ACL)" - put a space before (ACL)

Ok.

>  - " Indicates the primary intended" - here's that word "primary" again..

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

[Andy Bierman]

On Thu, Mar 8, 2018 at 3:55 PM, Adam Roach  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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Adam Roach]

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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] I-D Action: draft-ietf-netmod-syslog-model-24.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

Title   : A YANG Data Model for Syslog Configuration
Authors : Clyde Wildes
  Kiran Koushik
Filename: draft-ietf-netmod-syslog-model-24.txt
Pages   : 31
Date: 2018-03-08

Abstract:
   This document defines a YANG data model for the configuration of a
   syslog process.  It is intended this model be used by vendors who
   implement syslog in their systems.

   The YANG model in this document conforms to the Network Management
   Datastore Architecture defined in [draft-ietf-netmod-revised-
   datastores].


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-24
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-syslog-model-24

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-24


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Alexey Melnikov's No Objection on draft-ietf-netmod-syslog-model-23: (with COMMENT)

[Clyde Wildes (cwildes)]

Alexey,

Your minor comments are addressed below…

On 3/6/18, 12:06 PM, "Alexey Melnikov"  wrote:

Alexey Melnikov has entered the following ballot position for
draft-ietf-netmod-syslog-model-23: 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-syslog-model/



--
COMMENT:
--

Thank you for this document.

I also prefer for TCP to be documented, if used in real world.

Some minor comments:

1) Please add a Normative Reference for the file: URI RFC (RFC 8089) when 
you
mention it for the first time.

[clw] Accepted

2) On page 19:

Example: compare->equals and action->no-match means
messages that have a severity that is not equal to the
specified severity will be logged.";

Do you mean "action->block" instead of "action->no-match"?

[clw] An equals compare with action no-match means log the message, not block 
it.

3) When logging to file: how is the file name constructed from the name 
file:
URI if multiple files are preserved by the system? E.g. if the log file is
rotated daily and 5 last files are preserved, how does each individual 
filename
look? If I understood how this is used, this needs more clarification.

[clw] We decided to leave this for the implementer as file systems may be 
different for different implementations.

4) Nit: on page 18, typo in "spectify"

[clw] Accepted  

Thanks,

Clyde  


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Andy Bierman]

On Thu, Mar 8, 2018 at 1:33 AM, Adam Roach  wrote:

> 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.
>
>
I added text that says consistent indentation and formatting SHOULD be used.



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



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



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



> 
> ---
>
> §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
> ). This section
> would do
> authors and reviewers a great favor by reiterating or pointing to this
> guidance.
>
>
OK



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

Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-syslog-model-23: (with COMMENT)

[Clyde Wildes (cwildes)]

Adam,

An earlier version of the model (draft-ietf-netmod-syslog-model-08 and prior) 
included “terminal” as a syslog destination which addresses your requirement 
below:

+--rw terminal {terminal-action}?
|  +--rw all-terminals!
|  |  +--rw log-selector
|  | +--rw (selector-facility)
|  | |  +--:(no-log-facility)
|  | |  |  +--rw no-facilities?   empty
|  | |  +--:(log-facility)
|  | | +--rw log-facility* [facility]
|  | |+--rw facility union
|  | |+--rw severity union
|  | |+--rw severity-operator?   enumeration 
{selector-sevop-config}?
|  | +--rw pattern-match?   string {selector-match-config}?
|  +--rw terminal* [name] {terminal-facility-user-logging-config}?
| +--rw namestring
| +--rw log-selector
|+--rw (selector-facility)
||  +--:(no-log-facility)
||  |  +--rw no-facilities?   empty
||  +--:(log-facility)
|| +--rw log-facility* [facility]
||+--rw facility union
||+--rw severity union
||+--rw severity-operator?   enumeration 
{selector-sevop-config}?
|+--rw pattern-match?   string {selector-match-config}?

A consensus of the group was that it was best to remove this destination in the 
model as a simplification, and that vendors that supported same could add it 
back through an augmentation.

Thanks,

Clyde

On 3/8/18, 12:19 AM, "Adam Roach"  wrote:

Adam Roach has entered the following ballot position for
draft-ietf-netmod-syslog-model-23: 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-syslog-model/



--
COMMENT:
--

One quick comment on the model for the console:

+--rw console! {console-action}?
|  +--rw facility-filter
|  |  +--rw facility-list* [facility severity]
|  | +--rw facilityunion
|  | +--rw severityunion
|  | +--rw advanced-compare {select-adv-compare}?
|  |+--rw compare?   enumeration
|  |+--rw action?enumeration
|  +--rw pattern-match? string {select-match}?

Syslog can be (and frequently is) configured to log to "console" on a
non-default tty. It's not clear from this model how this would be 
configured or
indicated. Is the assumption here that all non-default-console tty logging
would be handled by the "file" portion of the tree? If so, it would be worth
indicating so explicitly, and noting that such an approach is limited to 
those
systems that present ttys as a part of the filesystem. Alternately, it might
make sense to add a tty field to the "console" subtree to report/configure 
this
value.




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Adam Roach]

On 3/8/18 09:17, Benoit Claise wrote:

On 3/8/2018 3:31 PM, Martin Bjorklund wrote:

Benoit Claise  wrote:

On 3/8/2018 3:15 PM, Juergen Schoenwaelder wrote:

On Thu, Mar 08, 2018 at 02:21:01PM +0100, Benoit Claise wrote:

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.

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.

RFC 6087 mentions "pyang --ietf"  and
draft-ietf-netmod-yang-tree-diagrams mentions "pyang -f tree
--tree-line-length 50"

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


I'm happy with this as well.

/a

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Benoit Claise]

On 3/8/2018 3:31 PM, Martin Bjorklund wrote:

Benoit Claise  wrote:

On 3/8/2018 3:15 PM, Juergen Schoenwaelder wrote:

On Thu, Mar 08, 2018 at 02:21:01PM +0100, Benoit Claise wrote:

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.

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.

RFC 6087 mentions "pyang --ietf"  and
draft-ietf-netmod-yang-tree-diagrams mentions "pyang -f tree
--tree-line-length 50"

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

This is a good compromise I would say.

Regards, Benoit



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?

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
.



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Martin Bjorklund]

Benoit Claise  wrote:
> On 3/8/2018 3:15 PM, Juergen Schoenwaelder wrote:
> > On Thu, Mar 08, 2018 at 02:21:01PM +0100, Benoit Claise wrote:
> >> 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.
> > 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.
> RFC 6087 mentions "pyang --ietf"  and
> draft-ietf-netmod-yang-tree-diagrams mentions "pyang -f tree
> --tree-line-length 50"

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

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

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Benoit Claise]

On 3/8/2018 3:15 PM, Juergen Schoenwaelder wrote:

On Thu, Mar 08, 2018 at 02:21:01PM +0100, Benoit Claise wrote:

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.

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


/js



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Juergen Schoenwaelder]

On Thu, Mar 08, 2018 at 02:21:01PM +0100, Benoit Claise wrote:
> 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.

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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Eric Rescorla's No Objection on draft-ietf-netmod-syslog-model-23: (with COMMENT)

[Benoit Claise]

On 3/8/2018 2:15 PM, Eric Rescorla wrote:



On Thu, Mar 8, 2018 at 12:41 AM, Benoit Claise > wrote:


Eric,

Eric Rescorla has entered the following ballot position for
draft-ietf-netmod-syslog-model-23: 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 tohttps://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-syslog-model/




--
COMMENT:
--

https://mozphab-ietf.devsvcdev.mozaws.net/D4614


It's not a problem with this document, but I took a quick look at
draft-ietf-netconf-tls-client-server and I've got some concerns. Here are a 
few
examples:

- You can set the cipher suite but not key sizes and groups You can
- say sort of incoherent things in TLS like "I support TLS 1.0 and TLS
  1.2 but not TLS 1.1" (there is no way to negotiate this in TLS 1.2)

I'll try to get a chance to give this a real review, but I wanted to 
mention it
before I forgot.

We are using definitions of syslog protocol from [RFC5424] in this
RFC.
Not a big deal, but this introduction feels like it ought to say what the
document is about, not just about syslog.

The severity is one of type syslog-severity, all severities, or none.
None is a special case that can be used to disable a filter.  When
filtering severity, the default comparison is that messages of the
This seems to be the first use of the term filter to mean this entity

I'm not sure I understand the call for action here.
In the YANG module, we called this facility-filter:


The introductory text here says:

"

   Within each action, a selector is used to filter syslog messages.  A
   selector consists of a list of one or more facility-severity matches,
   and, if supported via the select-match feature, an optional regular
   expression pattern match that is performed on the [RFC5424] field."

Perhaps"

"A selector consists of a list of one or more filters specified by
facility-severity pairs and, if supported..."

Got it. That makes sense.




       container facility-filter {

  description
"This container describes the syslog filter parameters.";
  list facility-list {
...


  subtree, implementations MUST NOT specify a private key that is
  used for any other purpose.
It seems like the data that syslog writes is sensitive, so the ability to 
write
a destination reflects a high degree of risk.

Again, what is the call for action here?


That the text say that writing those fields is dangerous. This is 
related to the secdir review comment that Kathleenamplifies in her 
comment.

Ack.


Regards, Benoit


-Ekr


Regards, B.

.






___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Benoit Claise]

Hi Adam,

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Eric Rescorla's No Objection on draft-ietf-netmod-syslog-model-23: (with COMMENT)

[Eric Rescorla]

On Thu, Mar 8, 2018 at 12:41 AM, Benoit Claise  wrote:

> Eric,
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-netmod-syslog-model-23: 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-syslog-model/
>
>
>
> --
> COMMENT:
> --
> https://mozphab-ietf.devsvcdev.mozaws.net/D4614
>
> It's not a problem with this document, but I took a quick look at
> draft-ietf-netconf-tls-client-server and I've got some concerns. Here are a 
> few
> examples:
>
> - You can set the cipher suite but not key sizes and groups You can
> - say sort of incoherent things in TLS like "I support TLS 1.0 and TLS
>  1.2 but not TLS 1.1" (there is no way to negotiate this in TLS 1.2)
>
> I'll try to get a chance to give this a real review, but I wanted to mention 
> it
> before I forgot.
>
>We are using definitions of syslog protocol from [RFC5424] in this
>RFC.
> Not a big deal, but this introduction feels like it ought to say what the
> document is about, not just about syslog.
>
>The severity is one of type syslog-severity, all severities, or none.
>None is a special case that can be used to disable a filter.  When
>filtering severity, the default comparison is that messages of the
> This seems to be the first use of the term filter to mean this entity
>
> I'm not sure I understand the call for action here.
> In the YANG module, we called this facility-filter:
>

The introductory text here says:

"

   Within each action, a selector is used to filter syslog messages.  A
   selector consists of a list of one or more facility-severity matches,
   and, if supported via the select-match feature, an optional regular
   expression pattern match that is performed on the [RFC5424] field."

Perhaps"

"A selector consists of a list of one or more filters specified by
facility-severity pairs and, if supported..."


   container facility-filter {
>
>  description
>"This container describes the syslog filter parameters.";
>  list facility-list {
>...
>
>  subtree, implementations MUST NOT specify a private key that is
>  used for any other purpose.
> It seems like the data that syslog writes is sensitive, so the ability to 
> write
> a destination reflects a high degree of risk.
>
> Again, what is the call for action here?
>

That the text say that writing those fields is dangerous. This is related
to the secdir review comment that Kathleenamplifies in her comment.

-Ekr


> Regards, B.
>
> .
>
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Juergen Schoenwaelder]

On Thu, Mar 08, 2018 at 01:33:00AM -0800, Adam Roach wrote:
> 
> --
> COMMENT:
> --
> 
> 
> §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.
>

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 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Adam Roach]

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

This URL returns a 404.


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Notifications with state data reference

[Juergen Schoenwaelder]

On Thu, Mar 08, 2018 at 09:08:42AM +0100, Michal Vaško wrote:
> Hi Juergen,
> thanks for an answer. I realized that validation of such notifications could 
> be difficult because of the reasons you mentioned so I was rather questioning 
> the fact that it is allowed to have references to state data in notifications 
> in the first place. Also, I am not sure it is as harmless as it seems.
> 
> What if there is a union in the notification that includes 
> instance-identifier, for example. The client receives the notification from a 
> replay and is unable to validate (resolve) this union leaf. In effect, I dare 
> say the leaf (and likely the whole notification) becomes useless for the 
> client as it simply cannot learn what value is actually stored there. Is all 
> this really okay?
>

Yes, it is possible to design notifications that are mostly useless
when being replayed - and sometimes even when they are sent live. The
same is true for log messages, if they do not include enough context,
they are useless. Operational state must be understood as being under
constant change. Hence, any references to operational state data that
has a high churn rate is likely of limited value.

We have to trust that authors of YANG models understand the dynamics
of the technology they are modeling. Implementation experience with
the technology usually helps a lot.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Eric Rescorla's No Objection on draft-ietf-netmod-syslog-model-23: (with COMMENT)

[Benoit Claise]

Eric,

Eric Rescorla has entered the following ballot position for
draft-ietf-netmod-syslog-model-23: 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-syslog-model/



--
COMMENT:
--

https://mozphab-ietf.devsvcdev.mozaws.net/D4614

It's not a problem with this document, but I took a quick look at
draft-ietf-netconf-tls-client-server and I've got some concerns. Here are a few
examples:

- You can set the cipher suite but not key sizes and groups You can
- say sort of incoherent things in TLS like "I support TLS 1.0 and TLS
  1.2 but not TLS 1.1" (there is no way to negotiate this in TLS 1.2)

I'll try to get a chance to give this a real review, but I wanted to mention it
before I forgot.

We are using definitions of syslog protocol from [RFC5424] in this
RFC.
Not a big deal, but this introduction feels like it ought to say what the
document is about, not just about syslog.

The severity is one of type syslog-severity, all severities, or none.
None is a special case that can be used to disable a filter.  When
filtering severity, the default comparison is that messages of the
This seems to be the first use of the term filter to mean this entity

I'm not sure I understand the call for action here.
In the YANG module, we called this facility-filter:

   container facility-filter {
 description
   "This container describes the syslog filter parameters.";
 list facility-list {
   ...



  subtree, implementations MUST NOT specify a private key that is
  used for any other purpose.
It seems like the data that syslog writes is sensitive, so the ability to write
a destination reflects a high degree of risk.

Again, what is the call for action here?

Regards, B.



.



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Adam Roach's No Objection on draft-ietf-netmod-syslog-model-23: (with COMMENT)

[Adam Roach]

Adam Roach has entered the following ballot position for
draft-ietf-netmod-syslog-model-23: 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-syslog-model/



--
COMMENT:
--

One quick comment on the model for the console:

+--rw console! {console-action}?
|  +--rw facility-filter
|  |  +--rw facility-list* [facility severity]
|  | +--rw facilityunion
|  | +--rw severityunion
|  | +--rw advanced-compare {select-adv-compare}?
|  |+--rw compare?   enumeration
|  |+--rw action?enumeration
|  +--rw pattern-match? string {select-match}?

Syslog can be (and frequently is) configured to log to "console" on a
non-default tty. It's not clear from this model how this would be configured or
indicated. Is the assumption here that all non-default-console tty logging
would be handled by the "file" portion of the tree? If so, it would be worth
indicating so explicitly, and noting that such an approach is limited to those
systems that present ttys as a part of the filesystem. Alternately, it might
make sense to add a tty field to the "console" subtree to report/configure this
value.


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] ?==?utf-8?q? Notifications with state data reference

[Michal Vaško]

Hi Juergen,
thanks for an answer. I realized that validation of such notifications could be 
difficult because of the reasons you mentioned so I was rather questioning the 
fact that it is allowed to have references to state data in notifications in 
the first place. Also, I am not sure it is as harmless as it seems.

What if there is a union in the notification that includes instance-identifier, 
for example. The client receives the notification from a replay and is unable 
to validate (resolve) this union leaf. In effect, I dare say the leaf (and 
likely the whole notification) becomes useless for the client as it simply 
cannot learn what value is actually stored there. Is all this really okay?

Kind regards,
Michal

On Wednesday, March 7, 2018 15:21 CET, Juergen Schoenwaelder 
 wrote: 
 
> Dear Michal,
> 
> I think the short answer is that the server replays notifications as
> they were was recorded.
> 
> Operational state is about "in use" values and on many systems it is
> impossible to take a consistent snapshot of operational state and
> hence clients will have little chances to obtain consistent snapshots
> and to do meaningful validation of received notifications. (Clients
> would not only need a consistent snapshot to validate a received
> notification but they would also need a snapshot taken at the time the
> notification was generated.)
> 
> /js
> 
> On Wed, Mar 07, 2018 at 02:58:58PM +0100, Michal Vaško wrote:
> > Hi,
> > in ietf-hardware [1] there are notifications defined that include leafrefs 
> > pointing to state data leaves. When the notification is generated, it is 
> > validated with regard to the current state data and if successful, the 
> > notification is then stored for possible future replay. Now, what happens 
> > when a client actually asks for notification replay including this 
> > notification? A server is no longer capable of validating it before sending 
> > because the state data changed. The same goes for the client, it is unable 
> > to validate notifications received from replay. Was this intentional, 
> > should the validation be simply skipped in this case?
> > 
> > Thanks,
> > Michal
> > 
> > [1] https://tools.ietf.org/html/draft-ietf-netmod-entity-08#page-29
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
 
 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod