[netmod] Regarding IPR on draft-bjorklund-netmod-yang-tree-diagrams

Authors, Contributors, WG, As part of preparation for WG Adoption of: draft-bjorklund-netmod-yang-tree-diagrams 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 aware of IPR

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,

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

or v4 and v6 into this it would work for me but I think the IETF may have missed the boat on this one. On Sun, Mar 26, 2017 at 1:17 PM, Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>> wrote: HI David, I believe an analogy to the ietf-routing module can and shou

[netmod] WG adoption poll draft-bjorklund-netmod-yang-tree-diagrams

All, This is start of a two-week poll on making the following draft a NETMOD working group document: draft-bjorklund-netmod-yang-tree-diagrams Please send email to the list indicating "yes/support" or "no/do not support". If indicating no, please state your reservations with the document.

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] 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] some comments on revised-datastores-01

understand. Sue -Original Message- From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen Sent: Monday, March 20, 2017 1:09 PM To: Juergen Schoenwaelder Cc: netmod@ietf.org Subject: Re: [netmod] some comments on revised-datastores-01 > I believe this is the wrong di

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

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

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

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

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] 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] 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] 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] 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] stable reference for tree diagram notation

>> This way, reader can focus more quickly on the diffs, but also this >> likely mimics what happened in reality (start with `pyang -f tree` >> and then manually edit from there). What do you think? >> > > Manually edited tree diagrams? I hope not. Perhaps we should have text > saying that

Re: [netmod] stable reference for tree diagram notation

> I think we can allow both and leave it to the document author. Either > the author uses a well known tree format and refers to its definition > or the author uses a not yet well known tree format and then it has > to be defined inline: Nice compromise, but even then it would be helpful if a

Re: [netmod] draft netmod charter update proposal

k Modeling (NETMOD) - Charter Current Status: Active 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> Oper

Re: [netmod] rfc 6087bis - stress importance of instance examples

>> I think we should encourage authors to write examples. > > +1 And also encourage authors to validate the examples > using their favorite YANG instance validation tool. Please note this from the latest 6087bis update: 4.12. Module Usage Examples Each specification that defines one

Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt

>> If we pick the former, it will not be possible to configure a component with >> a system controlled parent (unless you also add the system controlled parent >> to the configuration). >> [Bart Bogaert] Is there a reason to only have this parent in the state tree >> and not in the config tree?

Re: [netmod] draft netmod charter update proposal

session on Tue or Wed in Chicago. Cheers, Mehmet > -Original Message- > From: Susan Hares [mailto:sha...@ndzh.com] > Sent: Tuesday, March 7, 2017 7:27 PM > To: 'Mehmet Ersue' <mer...@gmail.com>; 'Kent Watsen' > <kwat...@juniper.net>; netmod@ietf.org > Cc: netmod-cha..

Re: [netmod] Toolchain upgraded to yangdump-pro 16.10-5 => 16.10-5.1

Hi Benoit, You seem to know the ins and outs of many tools these days, maybe you can point me in the right direction...which tool is able to validate instance documents against YANG 1.1 modules? I've always used `yang2dsdl`, but currently it outputs "DSDL plugin supports only YANG version

Re: [netmod] 6087bis update

Thanks Andy! - update YANG tree syntax section I wasn't expecting for the pyang --tree-help output to be used verbatim, but am okay with it also. It's just different then the long-form we've been using to date... - add new sub-section on usage examples Nice addition, but should it say

Re: [netmod] yang canonical integer format

Hi Juergen, > Hi, > > the canonical format for integer types is the decimal representation. > We do not seem to have a mechanism (other than a description statement) > to declare that the canonical representation is lets say hexadecimal. > For example, EtherType

[netmod] stable reference for tree diagram notation

All, Lou and I were discussing how it seems unnecessary that every draft has the same boilerplate text regarding how to interpret tree diagram notations. It would be nice if drafts could instead just reference another draft that contains this information. Does this make sense? Assuming we're

[netmod] 6087bis update

Hi Andy, Lou and I just noticed that Section 3 (YANG Tree Diagrams) is out of date, as it is missing notation described by `pyang --tree-help` (see below). Since this draft is still in AD Review, can you please be sure to update this section, either now or along with the next update? Thanks,

Re: [netmod] draft netmod charter update proposal

Current Status: Active 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 <bc

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

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

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

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

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,

[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] 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] 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] 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] 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] 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] 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] 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] [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] 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] [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] 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] 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>,

[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] 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] 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] 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"

[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

[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

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

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

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

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

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

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)

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

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

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

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"

[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

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

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

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

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

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

<    3   4   5   6   7   8   9   10   >