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

[Eric Rescorla]

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

 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.


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

[netmod] Ben Campbell's Yes on draft-ietf-netmod-rfc6087bis-18: (with COMMENT)

[Ben Campbell]

Ben Campbell has entered the following ballot position for
draft-ietf-netmod-rfc6087bis-18: Yes

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 very readable and informative document. I am balloting YES, but
I do have a few minor comments:

Substantive Comments:

§3, first paragraph:

Can there be a citation for internet-draft guidelines? Also, it seems odd to
have a normative MUST for I-D guidelines, but the RFC guidelines are not
normative?

§3.5: Is the referenced draft in the example likely to become an RFC prior to
publication? As it is, the way it is referenced looks a lot like a citation,
which are not recommended in an abstract.

§3.7:  The URL in the second paragraph is very dependent on the structure of
the tools pages. Any reorganization of those pages is likely to break the link.
I wonder if there is a way to alias that to something less brittle.

§4.8, 2nd paragraph: I’m surprised to see the WG mail list a MUST level
requirement here. WGs (and their mailing lists) come and go. I think, in many
cases, it would make more sense to list the IESG as the contact, at least for
standards track models. (I’ve seen us do that more often lately for IANA
registrations, and this seems in the same spirit.)

I can see that it might still make sense to reference the WG list in some
circumstances, but MUST seems excessive. . Editorial Comments and Nits:

§3.9, last paragraph:

There are two clauses starting with “, which”, which I think are intended as
restrictive clauses. Consider s/“, which”/“that”


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

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

[Eric Rescorla]

OK. I think it would be helpful to the reader to say that explicitly.

-ekr


On Wed, Mar 7, 2018 at 2:31 PM, Andy Bierman  wrote:

>
>
> On Wed, Mar 7, 2018 at 2:25 PM, Eric Rescorla  wrote:
>
>> Hi Andy,
>>
>> I don't want to overrotate on period, as I was just using it as an
>> example.
>>
>> As I said, there are a pile of other characters that are not in either
>> set. Are
>> they allowed or not?
>>
>>
> That is the only other character allowed in YANG not mentioned in this
> section.
>
> https://tools.ietf.org/html/rfc7950#section-6.2
>
>
> -Ekr
>>
>>
> Andy
>
>
>>
>> On Wed, Mar 7, 2018 at 2:22 PM, Andy Bierman  wrote:
>>
>>>
>>>
>>> On Wed, Mar 7, 2018 at 1:56 PM, Eric Rescorla  wrote:
>>>


 On Wed, Mar 7, 2018 at 1:44 PM, Andy Bierman 
 wrote:

>
>
> On Wed, Mar 7, 2018 at 11:49 AM, Eric Rescorla  wrote:
>
>> Eric Rescorla 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/stat
>> ement/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:
>> 
>> --
>>
>> draft-ietf-netmod-rfc6087bis.txt:500
>>normative, if the module itself is considered normative, and not an
>>example module or example YANG fragment.  The use of keywords
>> defined
>>in [RFC2119] apply to YANG description statements in normative
>> I think you probably want to rewrite this as:
>>
>> "Note that if the module itself is considered normative and not an
>> example
>> module or example YANG fragment, then all YANG statements..."
>>
>>
> OK
>
>
>
>>o  Prefixes are never allowed for built in data types and YANG
>>   keywords.
>> I'm not sure I understand what this means. Is the idea that I can't
>> use
>> "example-import" somewhere?
>>
>>
>
> The external keyword "example:import" is not the same as the YANG
> keyword "import"
> YANG keywords are not allowed to have prefixes.
>

>
>
>
>>character MAY be used if the identifier represents a well-known
>> value
>>that uses these characters.
>> Is this text saying that only characters in these two subsets are
>> allowed and
>> therefore, for instance "." is forbidden
>>
>
>
> This text is suggesting the characters that SHOULD be used.
> The dot and dash chars are not included. The text specifies which
> characters are included.
>

 I'm sorry, I am still confused. Here's the original text:

Identifiers SHOULD follow a consistent naming pattern throughout the
module.  Only lower-case letters, numbers, and dashes SHOULD be used
in identifier names.  Upper-case characters and the underscore
character MAY be used if the identifier represents a well-known value
that uses these characters.

 There are other characters that are not in either of these sets. Are
 you saying
 that they can't be used under any conditions?


>>> I will add the period charater to the list
>>>
>>>
>>>
 -Ekr


>>>
>>> Andy
>>>
>>>

>
>
>>
>>It is RECOMMENDED that only valid YANG modules be included in
>>documents, whether or not they are published yet.  This allows:
>> For clarify, I assume you mean "the modules are published yet"
>>
>>
> OK
>
>
>>The NETCONF Access Control Model (NACM)
>> [I-D.ietf-netconf-rfc6536bis]
>>does not support parameter access control for RPC operations.  The
>>user is given permission (or not) to invoke the RPC operation with
>> This might be slightly clearer if you said "parameter-based access
>> control"
>>
>>
>>
> OK
>
> Andy
>
>
>

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

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

[Andy Bierman]

On Wed, Mar 7, 2018 at 2:25 PM, Eric Rescorla  wrote:

> Hi Andy,
>
> I don't want to overrotate on period, as I was just using it as an example.
>
> As I said, there are a pile of other characters that are not in either
> set. Are
> they allowed or not?
>
>
That is the only other character allowed in YANG not mentioned in this
section.

https://tools.ietf.org/html/rfc7950#section-6.2


-Ekr
>
>
Andy


>
> On Wed, Mar 7, 2018 at 2:22 PM, Andy Bierman  wrote:
>
>>
>>
>> On Wed, Mar 7, 2018 at 1:56 PM, Eric Rescorla  wrote:
>>
>>>
>>>
>>> On Wed, Mar 7, 2018 at 1:44 PM, Andy Bierman  wrote:
>>>


 On Wed, Mar 7, 2018 at 11:49 AM, Eric Rescorla  wrote:

> Eric Rescorla 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/stat
> ement/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:
> --
>
> draft-ietf-netmod-rfc6087bis.txt:500
>normative, if the module itself is considered normative, and not an
>example module or example YANG fragment.  The use of keywords
> defined
>in [RFC2119] apply to YANG description statements in normative
> I think you probably want to rewrite this as:
>
> "Note that if the module itself is considered normative and not an
> example
> module or example YANG fragment, then all YANG statements..."
>
>
 OK



>o  Prefixes are never allowed for built in data types and YANG
>   keywords.
> I'm not sure I understand what this means. Is the idea that I can't use
> "example-import" somewhere?
>
>

 The external keyword "example:import" is not the same as the YANG
 keyword "import"
 YANG keywords are not allowed to have prefixes.

>>>



>character MAY be used if the identifier represents a well-known
> value
>that uses these characters.
> Is this text saying that only characters in these two subsets are
> allowed and
> therefore, for instance "." is forbidden
>


 This text is suggesting the characters that SHOULD be used.
 The dot and dash chars are not included. The text specifies which
 characters are included.

>>>
>>> I'm sorry, I am still confused. Here's the original text:
>>>
>>>Identifiers SHOULD follow a consistent naming pattern throughout the
>>>module.  Only lower-case letters, numbers, and dashes SHOULD be used
>>>in identifier names.  Upper-case characters and the underscore
>>>character MAY be used if the identifier represents a well-known value
>>>that uses these characters.
>>>
>>> There are other characters that are not in either of these sets. Are you
>>> saying
>>> that they can't be used under any conditions?
>>>
>>>
>> I will add the period charater to the list
>>
>>
>>
>>> -Ekr
>>>
>>>
>>
>> Andy
>>
>>
>>>


>
>It is RECOMMENDED that only valid YANG modules be included in
>documents, whether or not they are published yet.  This allows:
> For clarify, I assume you mean "the modules are published yet"
>
>
 OK


>The NETCONF Access Control Model (NACM)
> [I-D.ietf-netconf-rfc6536bis]
>does not support parameter access control for RPC operations.  The
>user is given permission (or not) to invoke the RPC operation with
> This might be slightly clearer if you said "parameter-based access
> control"
>
>
>
 OK

 Andy



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

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

[Eric Rescorla]

Hi Andy,

I don't want to overrotate on period, as I was just using it as an example.

As I said, there are a pile of other characters that are not in either set.
Are
they allowed or not?

-Ekr


On Wed, Mar 7, 2018 at 2:22 PM, Andy Bierman  wrote:

>
>
> On Wed, Mar 7, 2018 at 1:56 PM, Eric Rescorla  wrote:
>
>>
>>
>> On Wed, Mar 7, 2018 at 1:44 PM, Andy Bierman  wrote:
>>
>>>
>>>
>>> On Wed, Mar 7, 2018 at 11:49 AM, Eric Rescorla  wrote:
>>>
 Eric Rescorla 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/stat
 ement/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:
 --

 draft-ietf-netmod-rfc6087bis.txt:500
normative, if the module itself is considered normative, and not an
example module or example YANG fragment.  The use of keywords defined
in [RFC2119] apply to YANG description statements in normative
 I think you probably want to rewrite this as:

 "Note that if the module itself is considered normative and not an
 example
 module or example YANG fragment, then all YANG statements..."


>>> OK
>>>
>>>
>>>
o  Prefixes are never allowed for built in data types and YANG
   keywords.
 I'm not sure I understand what this means. Is the idea that I can't use
 "example-import" somewhere?


>>>
>>> The external keyword "example:import" is not the same as the YANG
>>> keyword "import"
>>> YANG keywords are not allowed to have prefixes.
>>>
>>
>>>
>>>
>>>
character MAY be used if the identifier represents a well-known value
that uses these characters.
 Is this text saying that only characters in these two subsets are
 allowed and
 therefore, for instance "." is forbidden

>>>
>>>
>>> This text is suggesting the characters that SHOULD be used.
>>> The dot and dash chars are not included. The text specifies which
>>> characters are included.
>>>
>>
>> I'm sorry, I am still confused. Here's the original text:
>>
>>Identifiers SHOULD follow a consistent naming pattern throughout the
>>module.  Only lower-case letters, numbers, and dashes SHOULD be used
>>in identifier names.  Upper-case characters and the underscore
>>character MAY be used if the identifier represents a well-known value
>>that uses these characters.
>>
>> There are other characters that are not in either of these sets. Are you
>> saying
>> that they can't be used under any conditions?
>>
>>
> I will add the period charater to the list
>
>
>
>> -Ekr
>>
>>
>
> Andy
>
>
>>
>>>
>>>

It is RECOMMENDED that only valid YANG modules be included in
documents, whether or not they are published yet.  This allows:
 For clarify, I assume you mean "the modules are published yet"


>>> OK
>>>
>>>
The NETCONF Access Control Model (NACM) [I-D.ietf-netconf-rfc6536bis]
does not support parameter access control for RPC operations.  The
user is given permission (or not) to invoke the RPC operation with
 This might be slightly clearer if you said "parameter-based access
 control"



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

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

[Andy Bierman]

On Wed, Mar 7, 2018 at 1:56 PM, Eric Rescorla  wrote:

>
>
> On Wed, Mar 7, 2018 at 1:44 PM, Andy Bierman  wrote:
>
>>
>>
>> On Wed, Mar 7, 2018 at 11:49 AM, Eric Rescorla  wrote:
>>
>>> Eric Rescorla 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/stat
>>> ement/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:
>>> --
>>>
>>> draft-ietf-netmod-rfc6087bis.txt:500
>>>normative, if the module itself is considered normative, and not an
>>>example module or example YANG fragment.  The use of keywords defined
>>>in [RFC2119] apply to YANG description statements in normative
>>> I think you probably want to rewrite this as:
>>>
>>> "Note that if the module itself is considered normative and not an
>>> example
>>> module or example YANG fragment, then all YANG statements..."
>>>
>>>
>> OK
>>
>>
>>
>>>o  Prefixes are never allowed for built in data types and YANG
>>>   keywords.
>>> I'm not sure I understand what this means. Is the idea that I can't use
>>> "example-import" somewhere?
>>>
>>>
>>
>> The external keyword "example:import" is not the same as the YANG keyword
>> "import"
>> YANG keywords are not allowed to have prefixes.
>>
>
>>
>>
>>
>>>character MAY be used if the identifier represents a well-known value
>>>that uses these characters.
>>> Is this text saying that only characters in these two subsets are
>>> allowed and
>>> therefore, for instance "." is forbidden
>>>
>>
>>
>> This text is suggesting the characters that SHOULD be used.
>> The dot and dash chars are not included. The text specifies which
>> characters are included.
>>
>
> I'm sorry, I am still confused. Here's the original text:
>
>Identifiers SHOULD follow a consistent naming pattern throughout the
>module.  Only lower-case letters, numbers, and dashes SHOULD be used
>in identifier names.  Upper-case characters and the underscore
>character MAY be used if the identifier represents a well-known value
>that uses these characters.
>
> There are other characters that are not in either of these sets. Are you
> saying
> that they can't be used under any conditions?
>
>
I will add the period charater to the list



> -Ekr
>
>

Andy


>
>>
>>
>>>
>>>It is RECOMMENDED that only valid YANG modules be included in
>>>documents, whether or not they are published yet.  This allows:
>>> For clarify, I assume you mean "the modules are published yet"
>>>
>>>
>> OK
>>
>>
>>>The NETCONF Access Control Model (NACM) [I-D.ietf-netconf-rfc6536bis]
>>>does not support parameter access control for RPC operations.  The
>>>user is given permission (or not) to invoke the RPC operation with
>>> This might be slightly clearer if you said "parameter-based access
>>> control"
>>>
>>>
>>>
>> OK
>>
>> Andy
>>
>>
>>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Eric Rescorla]

On Wed, Mar 7, 2018 at 1:44 PM, Andy Bierman  wrote:

>
>
> On Wed, Mar 7, 2018 at 11:49 AM, Eric Rescorla  wrote:
>
>> Eric Rescorla 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:
>> --
>>
>> draft-ietf-netmod-rfc6087bis.txt:500
>>normative, if the module itself is considered normative, and not an
>>example module or example YANG fragment.  The use of keywords defined
>>in [RFC2119] apply to YANG description statements in normative
>> I think you probably want to rewrite this as:
>>
>> "Note that if the module itself is considered normative and not an example
>> module or example YANG fragment, then all YANG statements..."
>>
>>
> OK
>
>
>
>>o  Prefixes are never allowed for built in data types and YANG
>>   keywords.
>> I'm not sure I understand what this means. Is the idea that I can't use
>> "example-import" somewhere?
>>
>>
>
> The external keyword "example:import" is not the same as the YANG keyword
> "import"
> YANG keywords are not allowed to have prefixes.
>

>
>
>
>>character MAY be used if the identifier represents a well-known value
>>that uses these characters.
>> Is this text saying that only characters in these two subsets are allowed
>> and
>> therefore, for instance "." is forbidden
>>
>
>
> This text is suggesting the characters that SHOULD be used.
> The dot and dash chars are not included. The text specifies which
> characters are included.
>

I'm sorry, I am still confused. Here's the original text:

   Identifiers SHOULD follow a consistent naming pattern throughout the
   module.  Only lower-case letters, numbers, and dashes SHOULD be used
   in identifier names.  Upper-case characters and the underscore
   character MAY be used if the identifier represents a well-known value
   that uses these characters.

There are other characters that are not in either of these sets. Are you
saying
that they can't be used under any conditions?

-Ekr


>
>
>>
>>It is RECOMMENDED that only valid YANG modules be included in
>>documents, whether or not they are published yet.  This allows:
>> For clarify, I assume you mean "the modules are published yet"
>>
>>
> OK
>
>
>>The NETCONF Access Control Model (NACM) [I-D.ietf-netconf-rfc6536bis]
>>does not support parameter access control for RPC operations.  The
>>user is given permission (or not) to invoke the RPC operation with
>> This might be slightly clearer if you said "parameter-based access
>> control"
>>
>>
>>
> OK
>
> Andy
>
>
>
___
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

[Kent Watsen]

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

  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)

In the Introduction:
  - should "ordered-by-user" be "ordered-by user" to avoid confusion, or 
perhaps say it another way?
  - what does "a tuple of" mean?  Can this be restated?
  - s/In case vendor supports it/In case a vendor supports it/ ?
  - "The list of X is endless depending on...".  Is "endless" the right word, 
perhaps restate?
  - same sentence as above, should "networked devices" be "network" or 
"networking" devices?

In Section 3:
  - "A network system usually have a list of ACLs"  (s/system/systems/ or 
s/have/has/?)
  - "The match criteria consist of packet header matching" - is consist the 
right word?
  - "It as also possible for ACE to match on metadata"  s/as/is/ and s/ACE/an 
ACE/
  - "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"?
  - "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

In Section 3.1:
  - s/and must statements/and 'must' statements/
  - s/define new "matches" choice/define a new "matches" choice/ ?

In Section 4.1:
  - "ietf-access-control-list" is the standard top level module for access lists
  - what does this mean?
  - The "access-lists" container stores a list of "acl". - s/stores/has or 
contains?/ 
  - "...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..."?
  - s/ability for ACL's to be/ability for ACLs to be/

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?  Separately, s/ACL/an ACL/?
  - A number of features read "Device can support..." - s/Device/The device/?
  - "It can have one or more Access Control Lists" - lists should be singular.
  - "An Access Control List(ACL)" - put a space before (ACL)
  - " Indicates the primary intended" - here's that word "primary" again...
  - s/a list of access-list-entries(ACE)/ a list of access-list-entry nodes 
(ACE)/?
  - s/List of access list entries(ACE)/List of access list entry nodes (ACE)/?
  - there is more than one instance of this in the model
  - "../../../../type" - still some long relative XPaths
  - " or referring to a group of source ports" - this isn't there yet.  I think 
you
want to say something like "this is a choice so as to support future 'case'
statements, such as one enabling a group of source ports to be referenced"
  - ditto for "or referring to a group of destination ports."
  - ditto on both of the above for the "udp" container
  - is it possible for both "egress-interface" and "ingress-interface" leafs to 
be specified at the same time?  - if not, should there a 'must' statement to
prevent that possibility? - or an explanation for what happens if it occurs?
  - s/The ACL's applied/The ACLs applied/   (this happens more than once in 
model)

In Section 4.2:
  - references them by "uses" --> references them by 'uses' statements  ???
  - not all your 'reference' statements have the title of the referenced 
document.
  - "then the datagram must be destroyed" - s/destroyed/dropped/?
  - "or referring to a group of ..."  - same comments as for previous module
  - "ece" is missing a 'reference' statement?  - 
  - "Indicates that the Urgent pointer field is significant" - urgent is
capitalized, but there's no context as for why.  Perhaps missing a
reference statement too?
  - in "window-size" leaf description, remove parentheses

In Section 4.3:
  - the text says that it drops traffic from X to Y, but the example seems to do
the reverse.

In Section 4.4:
  - The "With the follow XML example:"  "This represents..." is 
difficult to read.  How about just 

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

[Andy Bierman]

On Wed, Mar 7, 2018 at 11:49 AM, Eric Rescorla  wrote:

> Eric Rescorla 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:
> --
>
> draft-ietf-netmod-rfc6087bis.txt:500
>normative, if the module itself is considered normative, and not an
>example module or example YANG fragment.  The use of keywords defined
>in [RFC2119] apply to YANG description statements in normative
> I think you probably want to rewrite this as:
>
> "Note that if the module itself is considered normative and not an example
> module or example YANG fragment, then all YANG statements..."
>
>
OK



>o  Prefixes are never allowed for built in data types and YANG
>   keywords.
> I'm not sure I understand what this means. Is the idea that I can't use
> "example-import" somewhere?
>
>

The external keyword "example:import" is not the same as the YANG keyword
"import"
YANG keywords are not allowed to have prefixes.




>character MAY be used if the identifier represents a well-known value
>that uses these characters.
> Is this text saying that only characters in these two subsets are allowed
> and
> therefore, for instance "." is forbidden
>


This text is suggesting the characters that SHOULD be used.
The dot and dash chars are not included. The text specifies which
characters are included.





>
>It is RECOMMENDED that only valid YANG modules be included in
>documents, whether or not they are published yet.  This allows:
> For clarify, I assume you mean "the modules are published yet"
>
>
OK


>The NETCONF Access Control Model (NACM) [I-D.ietf-netconf-rfc6536bis]
>does not support parameter access control for RPC operations.  The
>user is given permission (or not) to invoke the RPC operation with
> This might be slightly clearer if you said "parameter-based access control"
>
>
>
OK

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

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

[Eric Rescorla]

Eric Rescorla 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:
--

draft-ietf-netmod-rfc6087bis.txt:500
   normative, if the module itself is considered normative, and not an
   example module or example YANG fragment.  The use of keywords defined
   in [RFC2119] apply to YANG description statements in normative
I think you probably want to rewrite this as:

"Note that if the module itself is considered normative and not an example
module or example YANG fragment, then all YANG statements..."

   o  Prefixes are never allowed for built in data types and YANG
  keywords.
I'm not sure I understand what this means. Is the idea that I can't use
"example-import" somewhere?

   character MAY be used if the identifier represents a well-known value
   that uses these characters.
Is this text saying that only characters in these two subsets are allowed and
therefore, for instance "." is forbidden

   It is RECOMMENDED that only valid YANG modules be included in
   documents, whether or not they are published yet.  This allows:
For clarify, I assume you mean "the modules are published yet"

   The NETCONF Access Control Model (NACM) [I-D.ietf-netconf-rfc6536bis]
   does not support parameter access control for RPC operations.  The
   user is given permission (or not) to invoke the RPC operation with
This might be slightly clearer if you said "parameter-based access control"


___
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)

[Warren Kumari]

On Wed, Mar 7, 2018 at 9:17 AM, Benoit Claise  wrote:
> Hi Alexey, Warren,
>>
>> 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.
>
> I've seen this comment in Warren's comment at
> https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/ballot/#warren-kumari.
> However, I can't find his ballot in email.

That's because of my cunning plan of not clicking the Send Mail button.

I'd viewed my comments as just informational / preferences and not
worth cluttering up people's mail.

> So let me reply to both of you here.
>
> This was discussed on the NETMOD mailing list. See subject "I-D Action:
> draft-ietf-netmod-syslog-model-19.txt"
> The fact is that RFC 6587 is now historic, implying a historic downref.
>
> I'm in favor to publish the document as it is right now, whose 00 WG doc.
> version dates from Nov 2014.

SGTM!
W

> Augmenting a YANG module, if TCP is required, is not that hard.
>
> Regards, Benoit
>>
>>
>> Some minor comments:
>>
>> 1) Please add a Normative Reference for the file: URI RFC (RFC 8089) when
>> you
>> mention it for the first time.
>>
>> 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"?
>>
>> 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.
>>
>> 4) Nit: on page 18, typo in "spectify"
>>
>>
>> .
>>
>



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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

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

[Benoit Claise]

Hi Alvaro,

Alvaro Retana 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:
--

(1) This sentence in the Introduction caught my attention: "This document
defines a set of usage guidelines for Standards Track documents containing
YANG...data models."The Abstract extends to say that "Applicable portions
may be used as a basis for reviews of other YANG data model documents."

I don't remember a non-Standards Track document off the top of my head [*], but
I'm sure the guidelines apply to any IETF document containing a module.  Is
that true?

In my mind, yes. I don't see why we would make a distinction.
I believe the text should be improved.

As history, this sentence is a cut/paste from RFC6087.


I see, for example, that in 4.1 (Module Naming Conventions) it is clear how
modules published by the IETF should be named...and a note is included about
what other SDOs might do.  Are there cases where the guidelines are only
applicable to Standards Track documents, but would not apply to other IETF
documents?

I don't think so.

Regards, B.


This may be a nit, but I think it is good to close this door before the
justification for non-compliance starts being the Status of a document.

[*] I do remember the IESG talking about whether a document with a module for
an Experimental protocol should be in the Standards Track or not.  IMHO, what
matters is for the module to be used (i.e. correct, implementable, implemented,
etc.) and not the status of the document it is in.

(2) The second paragraph in 2.1. (Requirements Notation) is not needed: "RFC
2119 language...as if it were describing best current practices."  This
document is now a BCP.


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



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

Re: [netmod] Notifications with state data reference

[Juergen Schoenwaelder]

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

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

[Benoit Claise]

Hi Alexey, Warren,

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.
I've seen this comment in Warren's comment at 
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/ballot/#warren-kumari. 
However, I can't find his ballot in email.

So let me reply to both of you here.

This was discussed on the NETMOD mailing list. See subject "I-D Action: 
draft-ietf-netmod-syslog-model-19.txt"

The fact is that RFC 6587 is now historic, implying a historic downref.

I'm in favor to publish the document as it is right now, whose 00 WG 
doc. version dates from Nov 2014.

Augmenting a YANG module, if TCP is required, is not that hard.

Regards, Benoit


Some minor comments:

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

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

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.

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


.



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

Re: [netmod] Suresh Krishnan's Discuss on draft-ietf-netmod-rfc6087bis-18: (with DISCUSS and COMMENT)

[Suresh Krishnan]

Hi Andy/Benoit,
  Your suggested changes look good to me. I will clear as soon as the new 
version hits.

Regards
Suresh

On Mar 7, 2018, at 5:24 AM, Benoit Claise 
mailto:bcla...@cisco.com>> wrote:

Suresh,


On Tue, Mar 6, 2018 at 8:44 PM, Suresh Krishnan 
mailto:sur...@kaloom.com>> wrote:
Suresh Krishnan has entered the following ballot position for
draft-ietf-netmod-rfc6087bis-18: Discuss

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/



--
DISCUSS:
--

* Section 4.25

I think this might be a simple misunderstanding but I have no idea what
compliance with this statement implies.

"A YANG module MUST NOT be designed such that the set of modules found on a
server implementation can be predetermined in advance."

Can you please clarify?



OK to remove this sentence.
Not sure where it came from



--
COMMENT:
--

Section 3.2:
  The date looks to be contradictory between the explanatory text

"The following example is for the '2010-01-18' revision of the  'ietf-foo'
module:"

and the actual code component defined right after

file 
"ietf-...@2016-03-20.yang"
...
 revision 2016-03-20 {
...


OK will update revision date



* Section 4.8

I went over this text several times to figure out what it means. Can you
simplify this, or provide examples as to when revision dates are/are not to be
updated.

   It is not required to keep the full revision history of draft
   versions (e.g., modules contained within Internet-Drafts).  That is,
   within a sequence of draft versions, only the most recent revision
   need be recorded in the module.  However, whenever a new (i.e.
   changed) version is made available (e.g., via a new version of an
   Internet-Draft), the revision date of that new version MUST be
   updated to a date later than that of the previous version.


OK -- will clarify that the same revision-stmt can be reused in an Internet 
Draft.
The revision date is updated if the module is changed.
What we mean here is that the published RFC should contain something such as:

 revision 2018-01-09 {
   description
 "Updated to support NMDA.";
   reference
 "RFC : A YANG Data Model for Interface Management";
 }

As opposed to the full draft history and change log

 revision 2018-01-09 {
   description
 "Updated to support NMDA.";
   reference
 "RFC : A YANG Data Model for Interface Management";
 }

 revision 2017-11-01 {
   description
 "Updated to address AD review.";
   reference
 "draft-ietf-netmod-rfc7223bis-03";
 }

 revision 2017-09-01 {
   description
 "Updated to address issue X, Y, Z";
   reference
 "draft-ietf-netmod-rfc7223bis-02";
 }




* Section 4.20

What does "cannot" imply here? MUST NOT? SHOULD NOT?


MUST NOT -- per RFC 7950, 7.20.3



"The YANG "deviation" statement cannot appear in IETF YANG modules"



Will change "cannot" to is not allowed to"
There is not point to repeat the RFC7950 specifications, but we want to add to 
it.
Therefore, let me propose:

OLD:

   The YANG "deviation" statement cannot appear in IETF YANG modules,
   but it can be useful for documenting server capabilities.  Deviation
   statements are not reusable and typically not shared across all
   platforms.


NEW:


   Per RFC 7950, 7.20.3, the YANG "deviation" statement is not allowed to 
appear in IETF YANG modules,
   but it can be useful for documenting server capabilities.  Deviation
   statements are not reusable and typically not shared across all
   platforms.

Regards, Benoit


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

[netmod] Notifications with state data reference

[Michal Vaško]

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

Re: [netmod] default namespace in XPath

[Ladislav Lhotka]

On Wed, 2018-03-07 at 14:06 +0100, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > Hi,
> > 
> > sec. 6.4.1 in RFC 7950 says in the second bullet item:
> > 
> > Names without a namespace prefix belong to the same namespace as
> > the identifier of the current node.
> > 
> > It is unclear what "current node" means:
> > 
> > 1. Is it the context node of the XPath expression, or
> > 
> > 2. is it the schema node corresponding to the parent statement of the
> must/when
> > statement?
> > 
> > For example:
> > 
> > module example-4-a {
> >   ...
> >   container bag {
> > ...
> >   }
> > }
> > 
> > module example-4-b {
> >   ...
> >   import example-4-a {
> > prefix "ex4a";
> >   }
> > 
> >   augment "/ex4a:bag" {
> > when "/quux = 0";
> > ...
> > }
> >   }
> >   ...
> > }
> > 
> > What is the namespace of "quux" in the when expression? Is it "example-4-a"
> > (option 1 above) or "example-4-b" (option 2)?
> 
> Just like with all other unprefixed items (except in a
> grouping/typedef), it is supposed to default to the prefix of the
> module where it is defined (lexical scope).  So it is supposed to be
> "example-4-b".  I agree that the term "current node" is misleading.

But then you cannot refer to XPath 2.0 as being the model for this default
namespace concept because in-scope namespaces defined in XPath 2.0 are bound to
element (XPath) nodes.

Lada 

> 
> 
> 
> 
> /martin
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] default namespace in XPath

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Hi,
> 
> sec. 6.4.1 in RFC 7950 says in the second bullet item:
> 
> Names without a namespace prefix belong to the same namespace as
> the identifier of the current node.
> 
> It is unclear what "current node" means:
> 
> 1. Is it the context node of the XPath expression, or
> 
> 2. is it the schema node corresponding to the parent statement of the 
> must/when
> statement?
> 
> For example:
> 
> module example-4-a {
>   ...
>   container bag {
> ...
>   }
> }
> 
> module example-4-b {
>   ...
>   import example-4-a {
> prefix "ex4a";
>   }
> 
>   augment "/ex4a:bag" {
> when "/quux = 0";
> ...
> }
>   }
>   ...
> }
> 
> What is the namespace of "quux" in the when expression? Is it "example-4-a"
> (option 1 above) or "example-4-b" (option 2)?

Just like with all other unprefixed items (except in a
grouping/typedef), it is supposed to default to the prefix of the
module where it is defined (lexical scope).  So it is supposed to be
"example-4-b".  I agree that the term "current node" is misleading.




/martin

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

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

[Alvaro Retana]

Alvaro Retana 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:
--

(1) This sentence in the Introduction caught my attention: "This document
defines a set of usage guidelines for Standards Track documents containing
YANG...data models."The Abstract extends to say that "Applicable portions
may be used as a basis for reviews of other YANG data model documents."

I don't remember a non-Standards Track document off the top of my head [*], but
I'm sure the guidelines apply to any IETF document containing a module.  Is
that true?

I see, for example, that in 4.1 (Module Naming Conventions) it is clear how
modules published by the IETF should be named...and a note is included about
what other SDOs might do.  Are there cases where the guidelines are only
applicable to Standards Track documents, but would not apply to other IETF
documents?

This may be a nit, but I think it is good to close this door before the
justification for non-compliance starts being the Status of a document.

[*] I do remember the IESG talking about whether a document with a module for
an Experimental protocol should be in the Standards Track or not.  IMHO, what
matters is for the module to be used (i.e. correct, implementable, implemented,
etc.) and not the status of the document it is in.

(2) The second paragraph in 2.1. (Requirements Notation) is not needed: "RFC
2119 language...as if it were describing best current practices."  This
document is now a BCP.


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

Re: [netmod] Proposal for minimalist full NMDA support in schema mount

[Ladislav Lhotka]

Robert Varga  writes:

> On 27/02/18 08:02, Ladislav Lhotka wrote:
>> The initial virtual interim decided to use Martin's combined proposal
>> and most of my subsequent objections were rejected on the basis of that
>> decision. That's why I hate discussing complicated things in virtual
>> interims - it it a safe and fast way to reach wrong decisions.
>
> Well said, I could not agree more. The standardization is taking *way*
> too long because the WG is ignoring the KISS principle and does not
> define simple (yet powerful) composable constructs.

In fact, it is just the good old Occam's Razor: Entities should not be
multiplied unnecessarily. Simplicity of concepts is especially important
here because the majority of YANG modules will be written (hopefully) by
people having only a casual experience with YANG.

Anyway, it doesn't help us in the current state of affairs. It looks
like we are stuck and no compromise is in sight.

Lada

>
> Regards,
> Robert
>

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] default namespace in XPath

[Ladislav Lhotka]

Hi Michal,

On Wed, 2018-03-07 at 10:18 +0100, Michal Vaško wrote:
> Hello,
> we have implemented it as option 1 based on the "current()" function 

Right, I have the same in my implementation. It is however counter-intuitive in
cases like my example because unprefixed names normally receive the namespace of
the module where they appear (I made a mistake myself:-).

> definition (RFC 7950 sec. 10.1.1):
> 
> The current() function takes no input parameters and returns a node
>set with the initial context node as its only member.
> 
> If this was not intended and actually option 2 is correct, the "current()"
> function should probably be renamed or return a different node to be
> consistent and not misleading.

IMO the current() function should stay, but the text in sec. 6.4.1 has to be
changed:

OLD
  Names without a namespace prefix belong to the same namespace as
  the identifier of the current node.

NEW
  Names without a namespace prefix belong to the same namespace as
  the identifier of the context node.

If there are no objections, I will file an erratum.

Lada

> 
> Regards,
> Michal
> 
> On Wednesday, March 7, 2018 10:11 CET, Ladislav Lhotka  wrote: 
>  
> > Hi,
> > 
> > sec. 6.4.1 in RFC 7950 says in the second bullet item:
> > 
> > Names without a namespace prefix belong to the same namespace as
> > the identifier of the current node.
> > 
> > It is unclear what "current node" means:
> > 
> > 1. Is it the context node of the XPath expression, or
> > 
> > 2. is it the schema node corresponding to the parent statement of the
> > must/when
> > statement?
> > 
> > For example:
> > 
> > module example-4-a {
> >   ...
> >   container bag {
> > ...
> >   }
> > }
> > 
> > module example-4-b {
> >   ...
> >   import example-4-a {
> > prefix "ex4a";
> >   }
> > 
> >   augment "/ex4a:bag" {
> > when "/quux = 0";
> > ...
> > }
> >   }
> >   ...
> > }
> > 
> > What is the namespace of "quux" in the when expression? Is it "example-4-a"
> > (option 1 above) or "example-4-b" (option 2)?
> > 
> > Thanks, Lada
> > 
> > -- 
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
>  
>  
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] Alexey Melnikov's Yes on draft-ietf-netmod-rfc6087bis-18: (with COMMENT)

[Benoit Claise]

Alexey,

Alexey Melnikov has entered the following ballot position for
draft-ietf-netmod-rfc6087bis-18: Yes

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

Thank you for a great document. Some minor comments:

3.8.  IANA Considerations Section

In order to comply with IESG policy as set forth in
http://www.ietf.org/id-info/checklist.html, every Internet-Draft that
is submitted to the IESG for publication MUST contain an IANA
Considerations section.  The requirements for this section vary
depending on what actions are required of the IANA.  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.

IANA's and RFC Editor opinion about empty IANA Considerations section has
changed over time (and might change again), so I would not make this statement.
I don't think this is necessarily the current policy. RFC Editor asks, but
doesn't enforce this. So I suggest changing "is removed" to "might be removed".

That makes sense.


[I-D.ietf-netmod-revised-datastores] - I am pretty sure that some uses of this
document are normative, so you should move it to Normative References.

Well spot. This is required by the terminology section 2.4


Regards, Benoit



.



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

Re: [netmod] Suresh Krishnan's Discuss on draft-ietf-netmod-rfc6087bis-18: (with DISCUSS and COMMENT)

[Benoit Claise]

Suresh,



On Tue, Mar 6, 2018 at 8:44 PM, Suresh Krishnan > wrote:


Suresh Krishnan has entered the following ballot position for
draft-ietf-netmod-rfc6087bis-18: Discuss

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/




--
DISCUSS:
--

* Section 4.25

I think this might be a simple misunderstanding but I have no idea
what
compliance with this statement implies.

"A YANG module MUST NOT be designed such that the set of modules
found on a
server implementation can be predetermined in advance."

Can you please clarify?



OK to remove this sentence.
Not sure where it came from


--
COMMENT:
--

Section 3.2:
  The date looks to be contradictory between the explanatory text

"The following example is for the '2010-01-18' revision of the 
'ietf-foo'
module:"

and the actual code component defined right after

                    file "ietf-...@2016-03-20.yang"
...
                                 revision 2016-03-20 {
...



OK will update revision date


* Section 4.8

I went over this text several times to figure out what it means.
Can you
simplify this, or provide examples as to when revision dates
are/are not to be
updated.

   It is not required to keep the full revision history of draft
   versions (e.g., modules contained within Internet-Drafts). 
That is,
   within a sequence of draft versions, only the most recent revision
   need be recorded in the module.  However, whenever a new (i.e.
   changed) version is made available (e.g., via a new version of an
   Internet-Draft), the revision date of that new version MUST be
   updated to a date later than that of the previous version.


OK -- will clarify that the same revision-stmt can be reused in an 
Internet Draft.

The revision date is updated if the module is changed.
What we mean here is that the published RFC should contain something 
such as:


 revision 2018-01-09 {
   description
 "Updated to support NMDA.";
   reference
 "RFC : A YANG Data Model for Interface Management";
 }


As opposed to the full draft history and change log

 revision 2018-01-09 {
   description
 "Updated to support NMDA.";
   reference
 "RFC : A YANG Data Model for Interface Management";
 }

 revision 2017-11-01 {
   description
 "Updated to address AD review.";
   reference
 "draft-ietf-netmod-rfc7223bis-03";
 }

 revision 2017-09-01 {
   description
 "Updated to address issue X, Y, Z";
   reference
 "draft-ietf-netmod-rfc7223bis-02";
 }




* Section 4.20

What does "cannot" imply here? MUST NOT? SHOULD NOT?



MUST NOT -- per RFC 7950, 7.20.3


"The YANG "deviation" statement cannot appear in IETF YANG modules"



Will change "cannot" to is not allowed to"
There is not point to repeat the RFC7950 specifications, but we want to 
add to it.

Therefore, let me propose:

OLD:

   The YANG "deviation" statement cannot appear in IETF YANG modules,
   but it can be useful for documenting server capabilities.  Deviation
   statements are not reusable and typically not shared across all
   platforms.



NEW:

   Per RFC 7950, 7.20.3, the YANG "deviation" statement is not allowed to 
appear in IETF YANG modules,
   but it can be useful for documenting server capabilities.  Deviation
   statements are not reusable and typically not shared across all
   platforms.

Regards, Benoit

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

Re: [netmod] ?==?utf-8?q? default namespace in XPath

[Michal Vaško]

Hello,
we have implemented it as option 1 based on the "current()" function definition 
(RFC 7950 sec. 10.1.1):

The current() function takes no input parameters and returns a node
   set with the initial context node as its only member.

If this was not intended and actually option 2 is correct, the "current()" 
function should probably be renamed or return a different node to be consistent 
and not misleading.

Regards,
Michal

On Wednesday, March 7, 2018 10:11 CET, Ladislav Lhotka  wrote: 
 
> Hi,
> 
> sec. 6.4.1 in RFC 7950 says in the second bullet item:
> 
> Names without a namespace prefix belong to the same namespace as
> the identifier of the current node.
> 
> It is unclear what "current node" means:
> 
> 1. Is it the context node of the XPath expression, or
> 
> 2. is it the schema node corresponding to the parent statement of the 
> must/when
> statement?
> 
> For example:
> 
> module example-4-a {
>   ...
>   container bag {
> ...
>   }
> }
> 
> module example-4-b {
>   ...
>   import example-4-a {
> prefix "ex4a";
>   }
> 
>   augment "/ex4a:bag" {
> when "/quux = 0";
> ...
> }
>   }
>   ...
> }
> 
> What is the namespace of "quux" in the when expression? Is it "example-4-a"
> (option 1 above) or "example-4-b" (option 2)?
> 
> Thanks, Lada
> 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
 
 

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

[netmod] default namespace in XPath

[Ladislav Lhotka]

Hi,

sec. 6.4.1 in RFC 7950 says in the second bullet item:

Names without a namespace prefix belong to the same namespace as
the identifier of the current node.

It is unclear what "current node" means:

1. Is it the context node of the XPath expression, or

2. is it the schema node corresponding to the parent statement of the must/when
statement?

For example:

module example-4-a {
  ...
  container bag {
...
  }
}

module example-4-b {
  ...
  import example-4-a {
prefix "ex4a";
  }

  augment "/ex4a:bag" {
when "/quux = 0";
...
}
  }
  ...
}

What is the namespace of "quux" in the when expression? Is it "example-4-a"
(option 1 above) or "example-4-b" (option 2)?

Thanks, Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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