[netmod] Regarding IPR on draft-entitydt-netmod-entity

[This regards the new pre-adoption process described by http://www.ietf.org/mail-archive/web/netmod/current/msg15520.html] Authors, Contributors, WG, As part of the preparation for WG Last Call, are you aware of any IPR that applies to draft identified above? Please state either: "No,

Re: [netmod] yang-next

I was just thinking about how we always talk about yang-1.1, yang-1.2, yang-2.0, so I figured yang-next ;) From: "Alexander Clemm (alex)" <a...@cisco.com<mailto:a...@cisco.com>> Date: Thursday, March 10, 2016 at 9:29 PM To: Kent Watsen <kwat...@juniper.net&l

[netmod] Regarding IPR on draft-wilton-netmod-intf-vlan-yang

[This regards the new pre-adoption process described by http://www.ietf.org/mail-archive/web/netmod/current/msg15520.html] Authors, Contributors, WG, As part of the preparation for WG Last Call, are you aware of any IPR that applies to draft identified above? Please state either: "No,

Re: [netmod] Differentiating the types of Mount

Thank you Eric and Juergen, this is really helpful, especially the diagram. Is there an implementation distinction between alias-mount and peer-mount? I’m hoping that there is one solution for both. Is there a difference with edits? E.g., a remote data mount is read-only, whereas a local

Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT)

the zerotouch draft uses object signing. XMLSIG was used in earlier draft, but was replaced with a binary type leaf called 'signature' having the following description: description "A PKCS #7 SignedData structure as specified by RFC

Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT)

All, I believe that this thread's issue is resolved if the following text is added to the Security Considerations section: "This document defines a JSON encoding for YANG-defined data. It does not defined any mechanisms for signing or encrypting said data. Use of an external mechanism,

Re: [netmod] 'Namespace Qualified' in draft-ietf-netmod-yang-json-08

> In this case, we never use the actual namespace (i.e., http://a.tld and > http://b.tld) so calling it ‘namespace qualified’ appears ambiguous. Should > it be simply referred to as ‘module-qualified’? It is a bit of a misnomer, and perhaps could be improved, but Section 4 defines

Re: [netmod] Fwd: Re: [Rtg-dt-yang-arch] I-D Action: draft-rtgyangdt-rtgwg-device-model-03.txt

We're already on it. This draft was discussed on the NETMOD virtual interim meeting last week. It is what is spurring the schema mount drafts and discussions of late. Thanks, Kent > On Mar 4, 2016, at 5:33 AM, Juergen Schoenwaelder > wrote: > > Is

Re: [netmod] YANG Advice/Editing Session at IETF95 ?

No, there will not be a YANG advice and editing session at IETF95. A number of YANG Doctors will be at the Hackathon both Saturday and Sunday, so some help can be had there. Kent From: netmod > on behalf of Eliot Lear

[netmod] kw review of draft-liu-netmod-yang-schedule

[As a contributor] While it's clear what this document is trying to achieve at a high level, it is unclear why the solution is needed. A "motivation" section explaining why this should be standardized would be nice. When reading this draft, I was reminded of my long expired draft

Re: [netmod] 答复: Regarding IPR on draft-entitydt-netmod-entity

-chairs) From: "Dongjie (Jimmy)" <jie.d...@huawei.com<mailto:jie.d...@huawei.com>> Date: Thursday, March 17, 2016 at 5:40 PM To: Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>>, "a...@yumaworks.com<mailto:a...@yumaworks.com>" <a...@y

Re: [netmod] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12

>> I think it would be better to use a more generic term for rpc + >> actions. Maybe operations: >> >>YANG is a data modeling language used to model configuration data, >>state data, operations, and notifications for network management >>protocols. > >I like 'operations' and the

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

There are a number of issues here. The first is that you are now depending on the separate applied state data store being implemented on every network device if you are going to eliminate the duplication of actual values in the OpState. The second is that OpsState is MUCH more than just

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

So my thinking is that if we can't merge "foo-state" into "foo" then instead we should have consistent rules that explicitly state that for all IETF models "foo" and "foo-state" are separate trees with a consistent naming convention and structure. That should hopefully allow tooling to

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

>> Firstly, I’m trying to get a sense of how big a problem this >> foo/foo-state thing is. [Note: by foo-state, I’m only referring >> to counters, not opstate]. RW: By counters, I think that we also mean any config false nodes that don't directly represent "applied configuration", right? E.g.

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

>> Juergen writes: >> Bottom line: I think we should continue to follow the model used by >> the ietf-interfaces model and the ietf-ip model until we have a better >> solution in place (and subsequently we can deprecate objects that >> became redundant). > > Rob writes: > This is pretty much what

[netmod] opstate breakout report

All, We just wanted to update the WG on the break out meeting on updated conceptual YANG datastores that took place last Wednesday. It was a very productive meeting attended by 20+ people. Progress was made on formalizing a revised conceptual datastore model. Based on this meeting, we will be

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

I think the issue is at the end of the sentence, my proposal: - the Internet-Draft is re-posted. + the work is published (e.g., it becomes an RFC). That said, for IETF drafts (not other SDOs), my understanding is that the revision statement’s date value SHOULD be the date that the I-D

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

> RW: > Are you thinking of a single global notification of convergence? > No > > I think the client would request a notification for its edit. > There would be a long-form and short-form notification. > > The interaction model is simple: > A) at the time of the request the client opt-in for

Re: [netmod] contact statement content

M, Andy Bierman wrote: On Tue, Jul 5, 2016 at 6:16 PM, Dale R. Worley <wor...@ariadne.com<mailto:wor...@ariadne.com>> wrote: Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>> writes: > 1) Remove the text "In addition, the Area Director and other conta

Re: [netmod] OpsState and Schema-Mount

Acee writes: >Then I see no YANG language barriers in collapsing config and state trees >- the model root just needs to be “config true”. Great, I think we’re all agreed. Can we now discuss the text I proposed for 6087bis? - here’s the link to my proposal:

Re: [netmod] OpsState and Schema-Mount

indirectly related, in that a holistic solution can address both. Kent From: Andy Bierman <a...@yumaworks.com> Date: Monday, August 8, 2016 at 5:51 PM To: Kent Watsen <kwat...@juniper.net> Cc: "Acee Lindem (acee)" <a...@cisco.com>, "Robert Wilton -X (rwilton -

Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Following Lou’s recommendation, my proposed changes for rfc6087bis Section 5.23 follow: 5.23. Operational Data In YANG, any data that has a "config" statement value of "false" could be considered operational data. The relationship between configuration (i.e., "config" statement

Re: [netmod] OpsState and Schema-Mount

>, Andy Bierman <a...@yumaworks.com>, Kent Watsen <kwat...@juniper.net>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] OpsState and Schema-Mount On Tue, Aug 9, 2016 at 6:38 AM, Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de<mailto:j

Re: [netmod] OpsState and Schema-Mount

Before the "rule" I can choose to place monitoring in its own module without any reliance on other modules. If the monitoring does not share indexing, what value is there in putting it in the config tree? I see none except a poor attempt at model classification. [KENT] from opstate-reqs:

Re: [netmod] contact statement content

<mailto:your-em...@example.com> In the above, I also added an “Author” example and added “[Optional]” to more clearly indicate that those fields are not required. Makes sense? Kent // as a contributor From: Robert Wilton <rwil...@cisco.com> Date: Thursday, June 30, 2016 at 5:58

Re: [netmod] [netmod-wg/schema-mount] bdebfd: use anyxml only for the mountpoints, updated refer...

I believe that this is a misconfiguration. Per https://www.ietf.org/mail-archive/web/netmod/current/msg15764.html, the idea was to replicate just the github *issue* comments to the list (not repo-level changes). Also, I think that this was supposed to be done for all drafts, but I’m unsure

Re: [netmod] grouping if-feature

> > Either way, to my understanding, there is one > > "ssh-x509-certs" feature definition redundant, either in > > ietf-netconf-server or in ietf-ssh-server. Thanks for clarification. > > Hmm, I think the one in ietf-netconf-server should be removed. But > this should really go to the netconf

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

Nits: 1. First it says “unpublished” then it says “posted”, I think it better to replace the latter with “published” so the terms are consistent. 2. “unpublished” is unclear. At least I consider submitting an I-D to datatracker as a form of publishing. I think it might be better here to

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

) in a published standard. This is why I would like the clarification to cover IDs (at least WG-adopted ones)! Thanks, William > On 15 Aug 2016, at 20:40, Kent Watsen <kwat...@juniper.net> wrote: > > Nits: > > 1. First it says “unpublished” the

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

>Perhaps we should make it clear that 'publish' is meant in the >traditional RFC 2026 sense. We could add a reference to RFC 2026, but I think that it’s easy enough to make the text understandable to any reader, regardless their familiarity with IETF process. I like that we’ve moved

Re: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-10.txt

Thank you Andy for addressing all the items listed here: https://www.ietf.org/mail-archive/web/netmod/current/msg17520.html. Benoit, I believe this draft addresses the comments raised during the AD review. Kent // as shepherd A New Internet-Draft is available from the on-line Internet-Drafts

Re: [netmod] example modules in 6087bis

Hi Martin, > I would like to see urn:example:, that's what > I usually use here. You mean the NID from RFC 6963? Sure, that can be mentioned as well but, unlike the other two examples, it's *only* useful for examples...it does not represent a template that could be used in production. Kent //

Re: [netmod] notifications...and yang-next

The NETCONF and NETMOD chairs are actively discussing how we might move content around between drafts maintained by the two groups. Resolving this notification statement issue is part of that. Here are some of my thoughts about this: 1) I think that YANG is primarily used to define the

Re: [netmod] netmod-revised-datastores: templates, interactions with RFC6243 'report-all'

Hi Lada, >> Yes, the YANG would have to define schema for both the template and >> expanded forms. > >Are you saying that running and intended (may) have different schemas? >The draft indicates that only intended is subject to validation. Either >way, it significantly changes the rules of the

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

> > True, this is keystore territory, and I don’t think this should venture in > that direction – the [sic] > can be considered clearly out of scope. Why would it be out of scope? Seems like this is actually what you might want given what you wrote below... > However, what would actually

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

nticate the other (non-sign) messages. Section 7 in RFC 5848 describes all this in detail. --- Alex From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen Sent: Wednesday, February 22, 2017 7:46 PM To: draft-ietf-netmod-syslog-mo...@ietf.org Cc: netmod@ietf.org Subject: Re: [netmod] W

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

>> - should the leafs not starting with "cert-" start with "sig-", to better >> match section 6.1? > > No, that would actually match less and be misleading. The parameters > mentioned in 6.1.1 > refer to configuration parameters for certificate blocks, and are accordingly > prefixed “cert”.

[netmod] draft netmod charter update proposal

<lber...@labn.net> Kent Watsen <kwat...@juniper.net> Operations and Management Area Directors: Benoit Claise <bcla...@cisco.com> Joel Jaeggli <joe...@bogus.com> Operations and Management Area Advisor: Benoit Claise <bcla...@cisco.com> Secretary:

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

be usable on a device without syslog? * "log-severity" defines a severity filter, not a severity, so its name is misleading. * Perhaps the "severity" type and the facility identities should have "reference" statements referring to RFC 5424, rather than referring to it

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

24 states that the severity and protocol values are not normative. * It's not clear to me why this needs to be split into two modules. Is it so that other modules can define logging parameters but still be usable on a device without syslog? * "log-severity" defines a severity filter,

Re: [netmod] Conflicting usage scenario for "invalid-value" error-tag between RFC 6241 & RFC 6020

Hi Rohit, On one hand, this seems like a protocol issue, so opting for NETCONF's definitions makes sense. On the other hand, RFC 6241 is just defining the error-tag without mandating when it's used, whereas RFC 7950 is specifying when it's to be used, so opting for YANG's normative language

Re: [netmod] Module tags

As for a concrete use-case, would something like this be helpful for a server to indicate which datastores a module is supported in? I'm thinking specifically about the revised-datastores draft where we've discussed that a module might exist in just oper-state, oper-state + ephemeral, oper-state

Re: [netmod] netmod-revised-datastores: templates, interactions with RFC6243 'report-all'

Hi Jason, > draft-nmdsdt-netmod-revised-datastores-00 mentions that “Templates > are expanded when copied into ”. > > That means the non-expanded template (i.e. the single copy of template data > itself) > is in the running. Yes. > Is that original non-expanded template data (which is

Re: [netmod] draft netmod charter update proposal

Chairs: Lou Berger <lber...@labn.net> Kent Watsen <kwat...@juniper.net> Operations and Management Area Directors: Benoit Claise <bcla...@cisco.com> Joel Jaeggli <joe...@bogus.com> Operations and Management Area Advisor: Benoit Claise <bcla...@cisco.com>

Re: [netmod] draft netmod charter update proposal

Hi Lada, I understand your intention here, but I'm inclined to agree with others that it's better to stick with the term we're using in the documents. I'm open to the idea of changing the term used in our RFCs, and I believe that such a change would likely have to begin with the YANG spec, from

Re: [netmod] draft netmod charter update proposal

Hi Rob, > Hi Kent, Lou, > > I think that it might possibly be a good idea to please align the > timelines for: > > draft-ietf-netmod-intf-ext-yang > draft-ietf-netmod-sub-intf-vlan-yang > > because I think that it will be somewhat helpful to review both > documents together. Can you

Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

Amendment: previous message as a contributor. K. On 9/2/16, 3:30 PM, "netmod on behalf of Kent Watsen" <netmod-boun...@ietf.org on behalf of kwat...@juniper.net> wrote: It holds. Some have FUD. I do not. K. On 9/2/16, 4:35 AM, "Ladislav L

Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

etmod-boun...@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Wednesday, August 31, 2016 20:41 > To: Kent Watsen > Cc: netmod@ietf.org > Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016) > > On Wed, Aug 31, 2016

Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

, but that thread seemed to have petered out, but now here we are and my opinion remains the same. Thanks, Kent From: netmod <netmod-boun...@ietf.org> on behalf of Kent Watsen <kwat...@juniper.net> Date: Friday, August 26, 2016 at 1:54 PM To: "netmod@ietf.org" <netmod@ietf.org> Su

Re: [netmod] RFC 6087bis guidance re use of revision statements indrafts

I like Jonathan’s proposed text as well. Kent // as a contributor On 8/31/16, 8:14 AM, "netmod on behalf of Acee Lindem (acee)" wrote: On 8/31/16, 8:00 AM, "netmod on behalf of Ladislav Lhotka"

Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

>Then you probably already know what the solution is going to be. I don't. It’s not that I know the exact solution. It’s that I see this approach offering good options for graceful migration to an opstate compliant solution (for which I’m on the design team alias), without incurring any

Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

to the ‘WG Consensus: Waiting for Write-Up’ working group state shortly; the shepherd will take it from there. Thanks, Kent (and Lou) From: netmod <netmod-boun...@ietf.org> on behalf of Kent Watsen <kwat...@juniper.net> Date: Friday, August 26, 2016 at 1:54 PM To: "netmod@

Re: [netmod] WG Last Call for draft-ietf-netmod-rfc6087bis-08 (until Oct 5, 2016)

to move forward with publishing the document as it is. If anyone disagrees with this, please speak up now. Thanks, Kent (as shepherd) From: netmod <netmod-boun...@ietf.org> on behalf of Kent Watsen <kwat...@juniper.net> Date: Tuesday, September 20, 2016 at 4:21 PM To: "netmod@

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-08 (until Oct 5, 2016)

, Kent (and Lou) From: Adrian Pan <adrian@ericsson.com> Date: Wednesday, September 21, 2016 at 4:55 AM To: Kent Watsen <kwat...@juniper.net>, "netmod@ietf.org" <netmod@ietf.org> Subject: RE: [netmod] WG Last Call for draft-ietf-netmod-acl-model-08 (until Oct 5, 2016)

Re: [netmod] Regarding IPR on draft-ietf-netmod-rfc6087bis-08

Authors, Contributors, WG, As part of the WG Last Call, are you aware of any IPR that applies to draft identified above? Please state either: * "No, I'm not aware of any IPR that applies to this draft" * "Yes, I'm aware of IPR that applies to this draft" If “yes”, has this IPR been

[netmod] WG Last Call for draft-ietf-netmod-acl-model-08 (until Oct 5, 2016)

This is a notice to start a two-week NETMOD WG last call for the document: Network Access Control List (ACL) YANG Data Model https://tools.ietf.org/html/draft-ietf-netmod-acl-model-08 Please indicate your support or concerns by Wednesday, October 5, 2016. We are

[netmod] Regarding IPR on draft-ietf-netmod-acl-model-08

Authors, Contributors, WG, As part of the WG Last Call, are you aware of any IPR that applies to draft identified above? Please state either: * "No, I'm not aware of any IPR that applies to this draft" * "Yes, I'm aware of IPR that applies to this draft" If “yes”, has this IPR been

[netmod] WG Last Call for draft-ietf-netmod-rfc6087bis-08 (until Oct 5, 2016)

This is a notice to start a two-week NETMOD WG last call for the document: Guidelines for Authors and Reviewers of YANG Data Model Documents https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-08 Please indicate your support or concerns by Wednesday, October

[netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

This is a notice to start a two-week NETMOD WG last call for the document: A YANG Data Model for Routing Management https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-23 Please indicate your support or concerns by Thursday September 9, 2016. We are not

[netmod] draft minutes from the netmod 96 sessions

ture, go ahead an use it. Also ok to stay and 1.0. Kent Watsen: Also Andy's point as well. Lou Berger: see a nod of "yes" from AD Vladimir Vassilev: 1.1 to 1.2, will be same question? Lou Berger: We have that issue whenever we rev techs. Kent Watsen: If there's a feature in

[netmod] presentation requests for IETF 97

Hi All, The draft working group agenda for 97 is due this Monday. If you are interested in presenting at IETF 97, please send a request to mailto:netmod-cha...@ietf.org. Please include the following information in your request: - name of presentation [optional, only needed if

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

oun...@ietf.org> on behalf of Kent Watsen <kwat...@juniper.net> Date: Friday, October 28, 2016 at 3:01 PM To: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016) The last call period for this draft h

[netmod] Regarding IPR on draft-wilton-netmod-intf-vlan-yang

Authors, Contributors, WG, This IPR disclosure requests is being made as part of the preparation for WG adoption of this draft. Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm

[netmod] Call for consensus to adopt draft-wilton-netmod-intf-vlan-yang

Dear working group, Should we move to adopt draft-wilton-netmod-intf-ext-yang as a WG item and correspondingly add this to the WG charter as a milestone? Please comment by Friday, November 4, 2016 so that the WG Chairs can gauge whether or not there is consensus to move forward with the

[netmod] 6087bis shepherd writeup issues

Andy, all, In reviewing the draft for Shepherd writeup, I found the following issues that I think need to be addressed before the document can be sent to Benoit for AD review: 1. Idnits found the following: == Missing Reference: 'RFC6242' is mentioned on line 2233, but not defined ==

[netmod] agenda updated

Updates: - Andy Bierman is now presenting the entity draft - Dean Bogdanovic is presenting the Routing Area DT Update - Clyde Wildes is now presenting -11 (not -09) - the presentation of the alarm draft has been removed - the time-slot for session 2 has been corrected

[netmod] opstate breakout meeting tomorrow (wednesday)

NETCONF and NETMOD WGs, As mentioned in today’s NETMOD session, there will be a breakout meeting tomorrow to continue the discussion of proposal in https://tools.ietf.org/html/draft-nmdsdt-netmod-revised-datastores-00. If interested in this topic, please join us in Park Ballroom 3 starting

Re: [netmod] Regarding IPR on draft-nmdsdt-netmod-revised-datastores

No, I'm not aware of any IPR that applies to this draft. What is the -01 comment about? AFAIK, we’d post draft-ietf-netmod-revised-datastores-00 (based on draft-nmdsdt-netmod-revised-datastores-00) following adoption... Kent // as an author On 11/28/16, 5:50 PM, "Lou Berger"

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

PM To: Kent Watsen <kwat...@juniper.net> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016) On Oct 29, 2016, at 4:01 AM, Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>&g

[netmod] preliminary 97 agenda posted

The preliminary agenda for the two NETMOD sessions has been posted here: https://www.ietf.org/proceedings/97/agenda/agenda-97-netmod-00.txt Cheers, Kent ___ netmod mailing list netmod@ietf.org

Re: [netmod] 6087bis shepherd writeup issues

updates needed per the AD’s review. Thanks, Kent From: Andy Bierman <a...@yumaworks.com> Date: Saturday, October 22, 2016 at 2:56 PM To: Kent Watsen <kwat...@juniper.net> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] 6087bis shepherd writeup issues H

Re: [netmod] New Version Notification for draft-nmdsdt-netmod-revised-datastores-00.txt

All, The datastore design team has posted the draft below. Please note that the chairs are prioritizing this draft for the upcoming 97 meeting. In particular, we plan to devote enough time for a thorough presentation on Tuesday, a breakout session on Wednesday, and a summary of the breakout

[netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

This is a notice to start a two-week NETMOD WG last call for the document: A YANG Data Model for Syslog Configuration https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-11 Please indicate your support or concerns by Tuesday, December 27, 2016. We are particularly interested

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

the Last Call period, and ultimately post an updated draft capturing the WG consensus. Thanks, Kent // as shepherd From: netmod <netmod-boun...@ietf.org> on behalf of Kent Watsen <kwat...@juniper.net> Date: Wednesday, November 23, 2016 at 10:54 AM To: Eliot Lear <l...@cisco.com>,

Re: [netmod] Modelling different "levels" of data in YANG

; diagnostics true;<-- new flag here ... } Is all this leading up to a draft? ;) Kent // contributor From: Robert Wilton <rwil...@cisco.com> Date: Monday, December 12, 2016 at 6:10 AM To: Kent Watsen <kwat...@juniper.net>, Andy Bierman <a...

Re: [netmod] Modelling different "levels" of data in YANG

> Why can't you use a when-stmt? > > > system > > ... > >// config false >// when "/top/diag-mode = 'system'" > > > Can we have a solution that is session-oriented, like with-defaults? Maybe the ‘when’ expression’s context

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

> I think it is better to have a human decide what is in the module > instead of relying on a pyang plugin to generate some additional module > that follows some simplistic pattern. It may be simple, but I’m thinking that’s only because it’s not tricky ;) > Of course this solution only works

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

I think that there may be a better way here: The data modelers design the model on the assumption that an operational state datastore will be present. We can then use a pyang plugin to generate an extra YANG model that contains the missing state leaves that would be required for the split

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

Hi Clyde, The LC period has ended. While we only received two reviews, I think both were quite good and thorough and, as far as I can tell, entail needing a non-trivial update to the draft. My thoughts are that you should continue working with Alex and Andy to ensure their issues are

Re: [netmod] Key Strings in ietf-key-chain operational state

datastore proposal. K. On 12/2/16, 7:45 PM, "Acee Lindem (acee)" <a...@cisco.com> wrote: Hi Kent, So are you suggesting the nacm:default-deny-all for key strings rather than omitting it from the operational state? Thanks, Acee On 12/2/16, 3:15 PM, "Kent Watsen" <kwa

Re: [netmod] Key Strings in ietf-key-chain operational state

Hi Acee, Sorry for being late to this thread. As Mehesh mentioned, this aspect of the keystore mode is currently open, and being tracked by github issue #2. It is my understanding that the working group would like to pursue a strategy that supports backup/restore operations to the greatest

Re: [netmod] A suggestion for yang namespaces

>Bill Fenner wrote: >> https://tools.ietf.org/html/rfc4151 defines the "tag:" URI scheme, which >> allows the creation of URIs with nearly arbitrary syntax by anyone with an >> email address or domain name. E.g., >> "tag:example.com,2016:yang:interface-extension". >> The

Re: [netmod] file "ietf-...@2016-03-20.yang" or file "ietf-foo.yang"

Hi Benoit, Section 4.2 of rfc6187bis says: The "" tag SHOULD be followed by a string identifying the file name specified in Section 5.2 of [RFC7950]. While Section 5.2 of RFC7950 says: The name of the file SHOULD be of the form: module-or-submodule-name ['@' revision-date]

Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-acl-model-10.txt

you add to this in the future and rev up the RFC? Sure. However, I am not sure what value that brings to the community. In its current form I would not ask any of my vendors to implement this draft. Instead I would push them towards the OpenConfig ACL model. On Tue, Mar 14, 2017 at 9:12 PM,

Re: [netmod] some comments on revised-datastores-01

> Currently there is no explicit mechanism for a server to > advertise which datastores is supports, other that the advertisment of > features in "ietf-datastore". Maybe we should add an explicit list of > supported datastores (but this will be protocol-dependent, since some > protocols might

Re: [netmod] some comments on revised-datastores-01

>> The new dynamic datastores are (per this draft) advertised by being >> listed in YANG Library. Only the "built in" datastores wouldn't have >> a module-backing. > > Actually, in the current draft, each module has a leaf-list of all > datastores (not only dynamic) where the module is

Re: [netmod] some comments on revised-datastores-01

> Obviously, relying on module names does not work if a module defines > multiple datastores. So either the set of datastores is identified > from reading the whole yang-library list or we provide a separate list > (and I think we should provide a separate list). It seems okay for more than one

Re: [netmod] security considerations boilerplate updates to cover RESTCONF

the first paragraph I have issue with. The more I think about it, the more I think the first paragraph should, for the most part, disappear. K. // contributor -ORIGINAL MESSAGE- Kent Watsen <kwat...@juniper.net> writes: > A couple comments: > > 1) drilling down o

Re: [netmod] draft netmod charter update proposal

7/03/2017 13:22, Mehmet Ersue wrote: >>>> I think YANG identities should be standardized with 7950bis. >>>> >>>> Mehmet >>>> >>>>> -Original Message- >>>>> From: Lou Berger [mailto:lber...@labn.net] >>>>>

Re: [netmod] security considerations boilerplate updates to cover RESTCONF

A couple comments: 1) drilling down on the mandatory-to-implement NC/RC protocols is somewhat missing the point. The important bit is that *all* protocols transporting YANG-modeled data *only* have secure transport layers. More specifically, YANG-modeled data may be transported

Re: [netmod] some comments on revised-datastores-01

>> It seems okay for more than one datastore to be represented by a single >> module. Presumably the set of them come together as a package (all or >> none), right? This could be a datastore-designer decision to make. >> >> For instance, I2RS talks about priority-ordered planes of glass, so

Re: [netmod] some comments on revised-datastores-01

> But this logic is already broken for the datastores defined in the > revised datastores document. It defines an identity for startup but > not all systems implement startup. End of proof. Ha ha, yes professor. But recall this started as a discussion regarding what to do for the new dynamic

Re: [netmod] some comments on revised-datastores-01

> I believe this is the wrong direction, even if we rewrite the module > in the revised datastores document and split it into multiple modules. > A simple list of implemented datastores is cheap. It is flexible. It > does not require explanations and rules how definitions must be split > into

Re: [netmod] security considerations boilerplate updates to cover RESTCONF

>> 1) drilling down on the mandatory-to-implement NC/RC protocols >>is somewhat missing the point. The important bit is that >>*all* protocols transporting YANG-modeled data *only* have >>secure transport layers. More specifically, YANG-modeled >>data may be transported over

Re: [netmod] security considerations boilerplate updates to cover RESTCONF

typo: new: one of the protocols *may* have an insecure protocol K. -ORIGINAL MESSAGE- A couple comments: 1) drilling down on the mandatory-to-implement NC/RC protocols is somewhat missing the point. The important bit is that *all* protocols transporting YANG-modeled data

Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-acl-model-10.txt

Hi David, Can you please confirm that the additional examples address your concern? And, if not, please explain if there is any reason why what you're looking for couldn't be added or augmented in in the future. Thanks, Kent // shepherd On 3/13/17, 5:57 AM, "netmod on behalf of Dean

Re: [netmod] security considerations boilerplate updates to cover RESTCONF

Benoit, I fixed this text in my drafts already. Actually, I found the old text difficult to read, so I fixed it like this: The YANG module defined in this document is designed to be accessed via YANG based management protocols, such as NETCONF

Re: [netmod] Query on Announcing Conformance Information in the Message

Is there a typo in your capability line? s/netocnf/netconf/ Is your server also advertising jnx-ietf-netocnf-monitoring-dev in its hello message? BTW, be aware that servers supporting RFC7950 no longer have "deviations=" in the capability string, as the server is now expected to use YANG

Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00

All, We're a couple days away from the 2-week window. As of now, the majority does not support adopting this draft. Any remaining opinions? Lada, The objections seem to be concern for net readability, and for the importance of the problem relative to other activities. For the former case,

<    1   2   3   4   5   6   7   8   9   10   >