[netmod] Eric Rescorla's No Objection on draft-ietf-netmod-schema-mount-12: (with COMMENT)

[Eric Rescorla]

Eric Rescorla has entered the following ballot position for
draft-ietf-netmod-schema-mount-12: 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-schema-mount/



--
COMMENT:
--

Thank you for addressing my DISCUSS


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

Re: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS)

[Eric Rescorla]

OK, after reading your explanation and the example, I think I am clearer on
the use case and the text you propose seems appropriate. Why don't you
provide a new ID and I'll clear my DISCUSS

-Ekr


On Tue, Oct 16, 2018 at 9:05 AM joel jaeggli  wrote:

> On 10/16/18 06:00, Eric Rescorla wrote:
> > I'm sorry, but I still don't think I understand the security impacts of
> > this well enough to know if this text is OK.
> >
> > Can you provide a more detailed explanation of what XPath expressions
> > can and cannot do here? Happy to discuss live either on the phone or in
> BKK
> I'm probably grossly simplifying the goal here, but.
>
> xpath statement allow for referencing another path or applying
> constraints e.g. when / must (rfc 6020)
>
> the canonical example in 6020 being something like
>
>   container interface {
>   leaf ifType {
>   type enumeration {
>   enum ethernet;
>   enum atm;
>   }
>   }
>   leaf ifMTU {
>   type uint32;
>   }
>   must "ifType != 'ethernet' or " +
>"(ifType = 'ethernet' and ifMTU = 1500)" {
>   error-message "An ethernet MTU must be 1500";
>   }
>   must "ifType != 'atm' or " +
>"(ifType = 'atm' and ifMTU <= 17966 and ifMTU >= 64)" {
>   error-message "An atm MTU must be  64 .. 17966";
>   }
>
> http://www.yang-central.org/twiki/pub/Main/YangDocuments/rfc6020.html#xpath
>
> Imposing constraints using nodes in mounted modules is kind of a key
> application of schema-mount.
>
> > -Ekr
> >
> >
> > On Tue, Oct 16, 2018 at 5:45 AM Martin Bjorklund  > <mailto:m...@tail-f.com>> wrote:
> >
> > Hi,
> >
> > Eric Rescorla mailto:e...@rtfm.com>> wrote:
> > > That seems like it's going to have some pretty surprising
> > consequences and
> > > at minimum needs more information in the Security Considerations.
> >
> > Ok.  Howabout we add a paragraph to the end of the Security
> > Considerations section:
> >
> >   Care must be taken when the "parent-reference" XPath expressions
> are
> >   constructed, since the result of the evaluation of these
> expressions
> >   is added to the accessible tree for any XPath expression found in
> >   the mounted schema.
> >
> >
> > /martin
> >
> > > On Thu, Oct 11, 2018 at 12:18 AM Martin Bjorklund  > <mailto:m...@tail-f.com>> wrote:
> > >
> > > > Eric Rescorla mailto:e...@rtfm.com>> wrote:
> > > > > I'm sorry but I don't understand this.
> > > > >
> > > > > Does the externally visible behavior of any mounted module
> > depend in any
> > > > > way on these XPATH references
> > > >
> > > > Yes, but note that these XPath expressions ("parent-reference")
> are
> >     > > read-only (config false in the YANG model).  Thus they are set
> > by the
> > > > implementation, and used to inform the operator about the
> > environment
> > > > in which other XPath expressions are evaluated.
> > > >
> >     > >
> > > > /martin
> > > >
> > > >
> > > > >
> > > > > -Ekr
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Oct 10, 2018 at 6:38 AM Martin Bjorklund
> > mailto:m...@tail-f.com>> wrote:
> > > > >
> > > > > > Eric Rescorla mailto:e...@rtfm.com>> wrote:
> > > > > > > On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund
> > mailto:m...@tail-f.com>>
> > > > wrote:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > Eric Rescorla mailto:e...@rtfm.com>>
> wrote:
> > > > > > > > > Eric Rescorla has entered the following ballot
> > position for
> > > > > > > > > draft-ietf-netmod-schema-mount-11: Discuss
> > > > > > > > >
> > > > > > > > > When responding, please keep the subject line intact
> > and reply
> > > > to all
> > > > > > > > > email 

Re: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS)

[Eric Rescorla]

I'm sorry, but I still don't think I understand the security impacts of
this well enough to know if this text is OK.

Can you provide a more detailed explanation of what XPath expressions can
and cannot do here? Happy to discuss live either on the phone or in BKK

-Ekr


On Tue, Oct 16, 2018 at 5:45 AM Martin Bjorklund  wrote:

> Hi,
>
> Eric Rescorla  wrote:
> > That seems like it's going to have some pretty surprising consequences
> and
> > at minimum needs more information in the Security Considerations.
>
> Ok.  Howabout we add a paragraph to the end of the Security
> Considerations section:
>
>   Care must be taken when the "parent-reference" XPath expressions are
>   constructed, since the result of the evaluation of these expressions
>   is added to the accessible tree for any XPath expression found in
>   the mounted schema.
>
>
> /martin
>
> > On Thu, Oct 11, 2018 at 12:18 AM Martin Bjorklund 
> wrote:
> >
> > > Eric Rescorla  wrote:
> > > > I'm sorry but I don't understand this.
> > > >
> > > > Does the externally visible behavior of any mounted module depend in
> any
> > > > way on these XPATH references
> > >
> > > Yes, but note that these XPath expressions ("parent-reference") are
> > > read-only (config false in the YANG model).  Thus they are set by the
> > > implementation, and used to inform the operator about the environment
> > > in which other XPath expressions are evaluated.
> > >
> > >
> > > /martin
> > >
> > >
> > > >
> > > > -Ekr
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Oct 10, 2018 at 6:38 AM Martin Bjorklund 
> wrote:
> > > >
> > > > > Eric Rescorla  wrote:
> > > > > > On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund  >
> > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > Eric Rescorla  wrote:
> > > > > > > > Eric Rescorla has entered the following ballot position for
> > > > > > > > draft-ietf-netmod-schema-mount-11: 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-schema-mount/
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > >
> --
> > > > > > > > DISCUSS:
> > > > > > > >
> > > > >
> --
> > > > > > > >
> > > > > > > > Rich version of this review at:
> > > > > > > > https://mozphab-ietf.devsvcdev.mozaws.net/D3506
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > DETAIL
> > > > > > > > S 4.
> > > > > > > > >
> > > > > > > > >  It is worth emphasizing that the nodes specified in
> > > > > > > > >  "parent-reference" leaf-list are available in the
> mounted
> > > > > schema
> > > > > > > only
> > > > > > > > >  for XPath evaluations.  In particular, they cannot be
> > > accessed
> > > > > > > there
> > > > > > > > >  via network management protocols such as NETCON

Re: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS)

[Eric Rescorla]

That seems like it's going to have some pretty surprising consequences and
at minimum needs more information in the Security Considerations.

On Thu, Oct 11, 2018 at 12:18 AM Martin Bjorklund  wrote:

> Eric Rescorla  wrote:
> > I'm sorry but I don't understand this.
> >
> > Does the externally visible behavior of any mounted module depend in any
> > way on these XPATH references
>
> Yes, but note that these XPath expressions ("parent-reference") are
> read-only (config false in the YANG model).  Thus they are set by the
> implementation, and used to inform the operator about the environment
> in which other XPath expressions are evaluated.
>
>
> /martin
>
>
> >
> > -Ekr
> >
> >
> >
> >
> > On Wed, Oct 10, 2018 at 6:38 AM Martin Bjorklund  wrote:
> >
> > > Eric Rescorla  wrote:
> > > > On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund 
> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Eric Rescorla  wrote:
> > > > > > Eric Rescorla has entered the following ballot position for
> > > > > > draft-ietf-netmod-schema-mount-11: 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-schema-mount/
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > --
> > > > > > DISCUSS:
> > > > > >
> > > --
> > > > > >
> > > > > > Rich version of this review at:
> > > > > > https://mozphab-ietf.devsvcdev.mozaws.net/D3506
> > > > > >
> > > > > >
> > > > > >
> > > > > > DETAIL
> > > > > > S 4.
> > > > > > >
> > > > > > >  It is worth emphasizing that the nodes specified in
> > > > > > >  "parent-reference" leaf-list are available in the mounted
> > > schema
> > > > > only
> > > > > > >  for XPath evaluations.  In particular, they cannot be
> accessed
> > > > > there
> > > > > > >  via network management protocols such as NETCONF
> [RFC6241] or
> > > > > > >  RESTCONF [RFC8040].
> > > > > >
> > > > > > What are the security implications of this XPath reference
> outside
> > > the
> > > > > > mount jail? Specifically, how does it interact with the access
> > > control
> > > > > > for the enclosing module.
> > > > >
> > > > > There is no such interaction, since access control comes into play
> > > > > when some external entity accesses the data through some management
> > > > > protocol, and the nodes from the "parent-reference" expressions
> cannot
> > > > > be accessed via management protocols.
> > > > >
> > > > > The last sentence of the quoted paragraph was supposed to make this
> > > > > clear, but it seems we might need some additional explanation?
> > > > >
> > > >
> > > > Yes, I think so. I guess I'm not clear on what the XPath expressions
> are
> > > > for if they
> > > > can't be accessed via the management protocols. How can they be used?
> > >
> > > These are XPath expressions defined in the YANG models themselves,
> > > such as "must" expressions or "leafrefs".   The description of
> > > "parent-reference" refer to them as:
> > >
> > >[...] XPath
> > >expressions whose context nodes are defined in the
> > >mounted schema
> > >
> > >
> > >
> > > /martin
> > >
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS)

[Eric Rescorla]

I'm sorry but I don't understand this.

Does the externally visible behavior of any mounted module depend in any
way on these XPATH references

-Ekr




On Wed, Oct 10, 2018 at 6:38 AM Martin Bjorklund  wrote:

> Eric Rescorla  wrote:
> > On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund  wrote:
> >
> > > Hi,
> > >
> > > Eric Rescorla  wrote:
> > > > Eric Rescorla has entered the following ballot position for
> > > > draft-ietf-netmod-schema-mount-11: 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-schema-mount/
> > > >
> > > >
> > > >
> > > >
> --
> > > > DISCUSS:
> > > >
> --
> > > >
> > > > Rich version of this review at:
> > > > https://mozphab-ietf.devsvcdev.mozaws.net/D3506
> > > >
> > > >
> > > >
> > > > DETAIL
> > > > S 4.
> > > > >
> > > > >  It is worth emphasizing that the nodes specified in
> > > > >  "parent-reference" leaf-list are available in the mounted
> schema
> > > only
> > > > >  for XPath evaluations.  In particular, they cannot be accessed
> > > there
> > > > >  via network management protocols such as NETCONF [RFC6241] or
> > > > >  RESTCONF [RFC8040].
> > > >
> > > > What are the security implications of this XPath reference outside
> the
> > > > mount jail? Specifically, how does it interact with the access
> control
> > > > for the enclosing module.
> > >
> > > There is no such interaction, since access control comes into play
> > > when some external entity accesses the data through some management
> > > protocol, and the nodes from the "parent-reference" expressions cannot
> > > be accessed via management protocols.
> > >
> > > The last sentence of the quoted paragraph was supposed to make this
> > > clear, but it seems we might need some additional explanation?
> > >
> >
> > Yes, I think so. I guess I'm not clear on what the XPath expressions are
> > for if they
> > can't be accessed via the management protocols. How can they be used?
>
> These are XPath expressions defined in the YANG models themselves,
> such as "must" expressions or "leafrefs".   The description of
> "parent-reference" refer to them as:
>
>[...] XPath
>expressions whose context nodes are defined in the
>mounted schema
>
>
>
> /martin
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS)

[Eric Rescorla]

On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund  wrote:

> Hi,
>
> Eric Rescorla  wrote:
> > Eric Rescorla has entered the following ballot position for
> > draft-ietf-netmod-schema-mount-11: 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-schema-mount/
> >
> >
> >
> > --
> > DISCUSS:
> > --
> >
> > Rich version of this review at:
> > https://mozphab-ietf.devsvcdev.mozaws.net/D3506
> >
> >
> >
> > DETAIL
> > S 4.
> > >
> > >  It is worth emphasizing that the nodes specified in
> > >  "parent-reference" leaf-list are available in the mounted schema
> only
> > >  for XPath evaluations.  In particular, they cannot be accessed
> there
> > >  via network management protocols such as NETCONF [RFC6241] or
> > >  RESTCONF [RFC8040].
> >
> > What are the security implications of this XPath reference outside the
> > mount jail? Specifically, how does it interact with the access control
> > for the enclosing module.
>
> There is no such interaction, since access control comes into play
> when some external entity accesses the data through some management
> protocol, and the nodes from the "parent-reference" expressions cannot
> be accessed via management protocols.
>
> The last sentence of the quoted paragraph was supposed to make this
> clear, but it seems we might need some additional explanation?
>

Yes, I think so. I guess I'm not clear on what the XPath expressions are
for if they
can't be accessed via the management protocols. How can they be used?

-Ekr


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

[netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS)

[Eric Rescorla]

Eric Rescorla has entered the following ballot position for
draft-ietf-netmod-schema-mount-11: 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-schema-mount/



--
DISCUSS:
--

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3506



DETAIL
S 4.
>   
>  It is worth emphasizing that the nodes specified in
>  "parent-reference" leaf-list are available in the mounted schema only
>  for XPath evaluations.  In particular, they cannot be accessed there
>  via network management protocols such as NETCONF [RFC6241] or
>  RESTCONF [RFC8040].

What are the security implications of this XPath reference outside the
mount jail? Specifically, how does it interact with the access control
for the enclosing module.




___
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 <bcla...@cisco.com> 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

[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

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 <a...@yumaworks.com> wrote:

>
>
> On Wed, Mar 7, 2018 at 2:25 PM, Eric Rescorla <e...@rtfm.com> 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 <a...@yumaworks.com> wrote:
>>
>>>
>>>
>>> On Wed, Mar 7, 2018 at 1:56 PM, Eric Rescorla <e...@rtfm.com> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Mar 7, 2018 at 1:44 PM, Andy Bierman <a...@yumaworks.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Mar 7, 2018 at 11:49 AM, Eric Rescorla <e...@rtfm.com> 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 <a...@yumaworks.com> wrote:

>
>
> On Wed, Mar 7, 2018 at 1:56 PM, Eric Rescorla <e...@rtfm.com> wrote:
>
>>
>>
>> On Wed, Mar 7, 2018 at 1:44 PM, Andy Bierman <a...@yumaworks.com> wrote:
>>
>>>
>>>
>>> On Wed, Mar 7, 2018 at 11:49 AM, Eric Rescorla <e...@rtfm.com> 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 <a...@yumaworks.com> wrote:

>
>
> On Wed, Mar 7, 2018 at 11:49 AM, Eric Rescorla <e...@rtfm.com> 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

[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

[netmod] Eric Rescorla's No Objection on draft-ietf-netmod-yang-tree-diagrams-05

[Eric Rescorla]

Eric Rescorla has entered the following ballot position for
draft-ietf-netmod-yang-tree-diagrams-05: 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-yang-tree-diagrams/


There are no remarks associated with this position.




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

Re: [netmod] Eric Rescorla's No Objection on draft-ietf-netmod-revised-datastores-09: (with COMMENT)

[Eric Rescorla]

On Wed, Jan 10, 2018 at 5:15 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Mon, Jan 08, 2018 at 05:05:09AM -0800, Eric Rescorla wrote:
> >
> > --
> > COMMENT:
> > --
> >
> >
> >   protocol interactions with other systems and that is neither
> >   conventional nor dynamic configuration.
> > Could you provide an example of this?
>
> Many DHCP implementations do not go through a dynamic datastore and
> deliver configuration state straight into the operational state. An IP
> address learned via DHCP on such a system will be tagged with
> or:learned.
>

I don't think it's imperative, but it would be nice to have this example in
the
text.


>datastore that holds the complete current configuration on the
> >device.  It MAY include configuration that requires further
> >transformation before it can be applied, e.g., inactive
> >
> > If I am reading the text, this doesn't seem to be true because "system
> > configuration" is not included.
>
> Yes, it might make sense to remove 'complete' here to align the
> sentence in 5.1.3 with the definition of 'running configuration
> datastore'.
>

Thanks,

-Ekr


>
> /js
>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 <http://www.jacobs-university.de/>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Eric Rescorla's No Objection on draft-ietf-netmod-revised-datastores-09: (with COMMENT)

[Eric Rescorla]

Eric Rescorla has entered the following ballot position for
draft-ietf-netmod-revised-datastores-09: 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-revised-datastores/



--
COMMENT:
--


  protocol interactions with other systems and that is neither
  conventional nor dynamic configuration.
Could you provide an example of this?


   datastore that holds the complete current configuration on the
   device.  It MAY include configuration that requires further
   transformation before it can be applied, e.g., inactive

If I am reading the text, this doesn't seem to be true because "system
configuration" is not included.


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

Re: [netmod] Alia Atlas' Yes on draft-ietf-netmod-yang-model-classification-07: (with COMMENT)

[Eric Rescorla]

Module pedigree seems good. Other alternatives might be "module ownership"
or "module origin"


On Tue, Jun 6, 2017 at 9:30 PM, Alia Atlas  wrote:

> Alia Atlas has entered the following ballot position for
> draft-ietf-netmod-yang-model-classification-07: 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-yang-
> model-classification/
>
>
>
> --
> COMMENT:
> --
>
> If there is a desire to change from "module types", which I agree is
> likely to
> be overused,  an alternate term might be "module pedigree". Thank you for
> an
> excellent, clear, and useful document; I remember the confusion that
> generated
> this.
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Eric Rescorla's No Objection on charter-ietf-netmod-08-05: (with COMMENT)

[Eric Rescorla]

Eric Rescorla has entered the following ballot position for
charter-ietf-netmod-08-05: 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.)



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



--
COMMENT:
--

As before.


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

[netmod] Eric Rescorla's No Objection on charter-ietf-netmod-08-02

[Eric Rescorla]

Eric Rescorla has entered the following ballot position for
charter-ietf-netmod-08-02: 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.)



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


There are no remarks associated with this position.




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