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] Opstate solutions discussions: update and request for WGinput

[as a contributor] So, I see a strong preference for Option B which is all very logical, as Acee points out. But Option B I see as being a fundamental change to RFC6241, so if the netmod WG takes that decision, then it is stamping on the netconf WG. Perhaps the WG should be merged, now that

Re: [netmod] Opstate solutions discussions: update and request for WGinput

ha...@ietf.org" <netmod-cha...@ietf.org>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Opstate solutions discussions: update and request for WGinput Resent-From: <alias-boun...@ietf.org> Resent-To: <j.schoenwael...@jacobs-university.de>, &

Re: [netmod] The Restconf root

Yes, please re-post to the netconf ML. Also, though not your primary point, you misquoted the example. The 2nd example in Section 3.1 returns “/top/restconf” (not “/restconf”), which is consistent with it subsequent use-example quoted below. Kent On 6/13/16, 2:34 AM, "netmod on behalf of

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] 答复: 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

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

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

[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] Regarding IPR on draft-entitydt-netmod-entity

klund" <m...@tail-f.com> wrote: >I am not aware of any IPR related to this draft. > >[BTW, you should change the text from "preparation for WG Last Call" >to "preparation for WG adoption" or something.] > > >/martin > > >Kent Watsen

Re: [netmod] yang-next

>I think it is a good idea to capture ideas like this, but I also think >that such ideas should be discussed on the ML. But maybe that's what >you meant. My thought is to defer any discussion on the ML until we actually want to start working on yang-next. That said, it would be good to

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

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

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] '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] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft

willingness to review the draft as it progresses (thanks Dan and Martin). Can others that support this draft and willing to review this draft say so? Thanks, Netmod Chairs From: netmod <netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>> on behalf of Kent Watsen <kwat

[netmod] working group secretary position

All, We are considering whether to fill the open working group secretary position. Working Group secretaries help with Working Group administrative tasks, and are typically responsible for: * producing draft meeting notes based on attending the actual meeting, or listening to recordings (or

Re: [netmod] NETMOD WG Virtual Interim Meeting: 22 February 2016

On 2/22/16, 8:23 AM, "netmod on behalf of Kent Watsen" <netmod-boun...@ietf.org on behalf of kwat...@juniper.net> wrote: > >Friendly reminder, this meeting starts in about 90 minutes. > >Cheers, >Kent > > > > >On 2/10/16, 10:46 AM, "

Re: [netmod] NETMOD WG Virtual Interim Meeting: 22 February 2016

Friendly reminder, this meeting starts in about 90 minutes. Cheers, Kent On 2/10/16, 10:46 AM, "netmod on behalf of IESG Secretary" wrote: >The NETCONF Data Modeling Language (NETMOD) WG will have a virtual >interim meeting on

Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt

[As a contributor] If not, does it become a configuration error if a line card is inserted to which the configuration can not be applied? >>> As above, this question doesn't directly apply. >>> >>> But a similar question might be: what would happen if the configuration >>> had

Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt

>If there was a way that YANG patch (or equivalent) were able to return >both old and new values (in the same tree) then I think that would be >better. I don't think that such as solution would be specific to the >opstate requirements and may be useful more generally. Already the RPC

Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

[chair hat on] >But I wonder whether the OpenConfig operators might also ask the WG the >same question of whether a datastore solution is orders of magnitude >better than the OpenConfig solution? > >My best guess is that at the moment they would regard a datastore >solution as being

Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

>Can you please suggest an approach of how to return a single tree that >contains the data from two separate datastores (where the leaf paths may >overlap)? I think that the approach would need to work both for get >requests and also notification data. I know that this is a difference

Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

Hi Lou, >>>I know that this is a difference between the solutions, but I don’t see it >>>listed as a requirement. There is a requirement to return the diff, but >>>that’s all. Is there actually a need to return both sets of data? - or is >>>this just a desire for the diff to be able

Re: [netmod] OpState Solution Options

[As co-chair] Andy et al., Please keep in mind this message from Benoit: https://www.ietf.org/mail-archive/web/netmod/current/msg14585.html And note that Lou is trying to perform the analysis now. Thanks, Kent From: Andy Bierman > Date: Monday,

Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt

between intended and applied state is important as changes >have only partially be applied. Hence the error-option should apply to >applied-config. > >- Gert > > > > >On 2016-02-02 18:54, "netmod on behalf of Kent Watsen" ><netmod-boun...@ietf.org on beh

Re: [netmod] Yang mount / ysdl example use case

gt; On 03 Feb 2016, at 03:24, Kent Watsen <kwat...@juniper.net> wrote: >> >> >> [Chair hat on] >> >> Given the number of competing/complementing drafts involved, and the general >> lack of discussion on any of them, a virtual interim meeting might be an

Re: [netmod] Yang mount / ysdl example use case

(acee)" <a...@cisco.com> wrote: > > >On 2/3/16, 1:18 AM, "Ladislav Lhotka" <lho...@nic.cz> wrote: > >> >>> On 03 Feb 2016, at 03:24, Kent Watsen <kwat...@juniper.net> wrote: >>> >>> >>> [Chair hat on] &

Re: [netmod] 'uses' as a sub-statement to 'choice' statement?

>This has already been discussed, see > >https://mailarchive.ietf.org/arch/search/?email_list=netmod=1=uF7kbBPMxIBAMUm03D3AqxaJvK4 Okay, good answer. Never mind. Thanks, Kent ___ netmod mailing list netmod@ietf.org

[netmod] 'uses' as a sub-statement to 'choice' statement?

In a model where the choice shorthand notation is being used, it is necessary to use longhand notation if wanting a case statement to be defined by the ‘uses’ statement. That is, 6020bis allows ‘uses’ as a sub-statement to the ‘case’ statement, but not to the ‘choice’ statement. As an

Re: [netmod] Yang mount / ysdl example use case

[Chair hat on] Given the number of competing/complementing drafts involved, and the general lack of discussion on any of them, a virtual interim meeting might be an expedient way to proceed. In fairness, we know that there has been some discussion, but it hasn’t been picked up yet in a big

Re: [netmod] Question on the output of rpc-reply for operational model?

Hi Yong, The formatting on your message makes it difficult to read - please consider sending to the list using plain text. Otherwise, see below for comments - look for [KENT]... Thanks, Kent From: netmod > on behalf of Yong Zhu

Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-03.txt

[As a contributor] And just when I thought we were done with this draft ;) >>I think that the text for 2A would be more clear using MUST rather than >>may (in the sense that a compliant server must choose one of the three >>options listed). >> >>Before: >> >>A. A server may

Re: [netmod] Summary of "applied configuration and system-controlled entries" discussions

Please see inline below. Kent // as a contributor On 1/15/16, 3:36 PM, "netmod on behalf of Gert Grammel" wrote: >Rob, > >Thank you for the effort, it¹s really useful. > >Gert > >On 2016-15-01 19:21, "netmod on behalf of

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

>>to: >> >>4. Ability to relate configuration with its corresponding >>operational state >> >>A. Ability to relate intended config nodes with corresponding >>applied >>config nodes >> >>B. Ability to relate applied config nodes with

Re: [netmod] AD review: draft-ietf-netmod-opstate-reqs

[As a contributor] Hi Benoit, Thank you for your proactive AD review. Below are my responses to your comments. >- Editorial: I see many instances of (see term) or (see terms). >This doesn't add any value IMO. >If there are some chance for misinterpretation of those terms, >capitalize the

Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-03.txt

[As a contributor] From Benoit: Yes, I've seen those RFCs. The IETF is not really consistent regarding RFC 2119 and requirement documents. So I wanted to put the issue on the table. No strong view on way or the other. [Kent] thanks. Changing the MAY keywords the way you proposed is one

Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-03.txt

Hi Benoit, >You use MUST, SHOULD, MAY, and you refer to RFC 2119. Fine. >However, it might be beneficial to say something such as in RFC 7698 > >The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >

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

uergen Schoenwaelder <j.schoenwael...@jacobs-university.de> writes: >>> >>>> On Thu, Jan 07, 2016 at 05:24:45PM +, Robert Wilton wrote: >>>>> Hi Juergen, >>>>> >>>>> On 07/01/2016 16:05, Juergen Schoenwaelder wrote: >&g

Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-03.txt

net-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the NETCONF Data Modeling Language Working Group > of the IETF. > >Title : Terminology and Requirements for Enhanced Handling > of Operational State &

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

On 1/7/16, 12:24 PM, "Robert Wilton" wrote: >I don't have a particular problem with the current title, but if you >don't like visibility/control, then perhaps "Terminology and >Requirements for Enhanced Handling of Operational State"? This looks good to me. If no

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

draft. >> >> Acee >> >> On 1/5/16, 3:02 PM, "netmod on behalf of Juergen Schoenwaelder" >> <netmod-boun...@ietf.org on behalf of >> j.schoenwael...@jacobs-university.de> wrote: >> >> >On Mon, Jan 04, 2016 at 10:29:5

Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)

[As a contributor] Gert> If a client is has the intention to update/change a config, its decision is based on the present state of the configuration when the decision is taken. Ideally the present configuration is in a state where intended == applied config, so there is stable ground upon

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

: Terminology and Requirements for Enhanced > Operational State Visibility and Control >Authors : Kent Watsen > Thomas Nadeau > Filename: draft-ietf-netmod-opstate-reqs-02.txt > Pages : 6 > Date

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka" wrote: > >> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder >> wrote: >> >> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise

Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)

[As a contributor] Hi Robert, I want to go back to Jason’s original questions. I think we’re aligned on this, but please check my answers below. Quoting Jason’s original text now: >Is there some intention in the opstate requirements to add some sort >of all-or-nothing behavior to

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

Hi Robert, I agree that -01 doesn’t add much on top of -00. This is expected as we’re in the fit and finish phase. If you want to help finish the draft, then please consider responding to one of these threads: http://www.ietf.org/mail-archive/web/netmod/current/msg14587.html (re:

Re: [netmod] review of draft-ietf-netmod-opstate-reqs-01

about others? Thanks, Kent On 12/18/15, 2:59 AM, "Juergen Schoenwaelder" <j.schoenwael...@jacobs-university.de> wrote: >On Thu, Dec 17, 2015 at 09:27:12PM +, Kent Watsen wrote: >> [As a contributor] >> >> Thank you for the review Juergen. >>

Re: [netmod] IPR Check: draft-ietf-netmod-opstate-reqs-01

I have no nor know of any IPR Claims against this document. On 12/16/15, 8:53 AM, "netmod on behalf of Robert Wilton" wrote: >I have no nor know of any IPR Claims against this document. > >Thanks, >Rob > > >On 16/12/2015 13:13, Nadeau

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

>>>I’m struggling a bit to understand what is motivating you to ask this >>>question.That is, as a tool vendor, I wouldn’t think that any decision >>>made here would affect you immediately. My expectations are that any >>>impact to YANG/NETCONF/RESTCONF would be backwards compatible,

Re: [netmod] review of draft-ietf-netmod-opstate-reqs-01

[As a contributor] Thank you for the review Juergen. Great suggestions. If no one objects, I’ll incorporate them into the next revision of the document after last call. My one comment is that I don’t believe the document is limited to the introduction of applied configuration. For instance,

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[as a contributor] Hi Andy, I’m struggling a bit to understand what is motivating you to ask this question. That is, as a tool vendor, I wouldn’t think that any decision made here would affect you immediately. My expectations are that any impact to YANG/NETCONF/RESTCONF would be

Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-01.txt

work item of the NETCONF Data Modeling Language Working Group > of the IETF. > >Title : NETMOD Operational State Requirements >Authors : Kent Watsen > Thomas Nadeau > Filename: draft-ietf-netmod-opstate-reqs

Re: [netmod] draft netmod 94 minutes posted

del should be happening > there. > [RS] this is related to overlapping of the bridging model implementation? > [DR] do you have any mail exchanges for this? Maybe this could be raised in > IEEE plenary. Please forward me any emails on this discussion From: Robert Wilton <rwil...

Re: [netmod] draft netmod 94 minutes posted

On 11/24/15, 9:36 AM, "Martin Bjorklund" wrote: >Robert Wilton wrote: >> Hi Kent, Andrew >> >> Do you have a pointer to the recordings please? I tried the audio >> streams on the link below, but I can't seem to get them to work. >> >>

[netmod] draft netmod 94 minutes posted

All, The minutes for the two NETMOD sessions have been posted: https://www.ietf.org/proceedings/94/minutes/minutes-94-netmod Please provide comments/corrections on these draft minutes by Wed, Nov 25th. PS: huge thanks to Ignas and Andrew for putting these together! Thanks, Kent

Re: [netmod] IETF 94 - Remote Participation information and request for jabber scribes

Yes, time is tight for the morning session, the more we can dispatch beforehand the better. Not just Jabber scribe, but also minute-takers - please, if you’re willing to take minutes for the morning session, let us know now. Lastly, I forgot to bring my thunderbolt-to-hdmi/dvi cable thingy.

Re: [netmod] preliminary agenda for yokohama posted

Final agenda posted: https://www.ietf.org/proceedings/94/agenda/agenda-94-netmod - don’t forget to refresh your cache ;) Thanks, Kent From: netmod <netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>> on behalf of Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.ne

Re: [netmod] preliminary agenda for yokohama posted

-netmod - don’t forget to refresh your cache ;) Thanks, Kent and Tom From: netmod <netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>> on behalf of Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>> Date: Monday, October 19, 2015 at 8:39 PM To: "netmod@ie

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

I meant 3.D, and so did you I think when you wrote on the 16th "E.g. change the 1.D text to..." Sorry for the confusion. Kent On 10/19/15, 9:14 AM, "Kent Watsen" <kwat...@juniper.net> wrote: >Hi Rob, > >I know there is an on-going discussion about the

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

of this configuration operation. > > >Gert has provided some definitions that are closer to Kent's original >text, how do we resolve? > >Thanks, >Rob > > >On 19/10/2015 14:22, Kent Watsen wrote: >> I meant 3.D, and so did you I think when you wrote on

Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-00.txt

ta Modeling Language Working >Group of the IETF. > >Title : NETMOD Operational State Requirements >Authors : Kent Watsen > Thomas Nadeau > Filename: draft-ietf-netmod-opstate-reqs-00.txt > Pages

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

>Will there ever be a server that operates in synchronous mode, given >that applied will not match intended if hardware is missing? > >Will a client ever use "block" mode if it means that it might hang >forever (or at least until some hw is plugged in)? I think the key is in the phrase "The

[netmod] IPR Poll for draft-ietf-netmod-yang-json-06

This mail starts the IPR poll on draft-ietf-netmod-yang-json-06. Are you aware of any IPR that applies to draft-ietf-netmod-yang-json-06? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If you are listed as a document

Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)

>>> These terms were edited on today's call, resulting in the following >>>text: >>> >>> Synchronous configuration operation - A configuration request to >>>update >>> the running configuration of a server that is applied >>>synchronously with >>> respect to the client request.

Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)

rom: Gert Grammel <ggram...@juniper.net<mailto:ggram...@juniper.net>> Date: Friday, October 16, 2015 at 10:16 AM To: Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>> Cc: Robert Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>>, "netmod@ietf.or

Re: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied

cross several subsystems. >³²" > > My issue is that the requirement seems to ignore the situations and my >suggestion is to relax the requirement. > > I don¹t believe 1.C addresses the actual concern with the requirement. > >> On Oct 14, 2015, at 8:14 PM, Kent Watsen <k

Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)

Thanks Gert. I've incorporated these suggestions into my notes for today's interim meeting. From: Gert Grammel <ggram...@juniper.net<mailto:ggram...@juniper.net>> Date: Thursday, October 15, 2015 at 7:17 AM To: Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net

[netmod] webex accidentally cancelled meeting - looking to restart webex now...

webex accidentally cancelled meeting - looking to restart webex now... Kent ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] opstate-reqs #4: Provide a tighter definition of"applied configuration"

config. That may not always be the case. Jonathan From: Robert Wilton Sent: 14 October 2015 22:28 To: Kent Watsen;Andy Bierman Cc: netmod@ietf.org<mailto:netmod@ietf.org> Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of"applied configuration" On 14

Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)

>Anyway, as long as a regular NC/RC server does not have to pay a price >for this applied config idea, I have no real problem with this since I >am sure the market will sort this out. This goes to the solution - that it should allow servers to opt-in to support applied config. I have also been

Re: [netmod] opstate-reqs #4: Provide a tighter definition of "applied configuration"

Thank you Robert for bringing the discussion back to the github issues. Robert writes: > In particular: >- does it include support for templating (as per > openconfig-netmod-opstate-01 section 7.3.)? >- is it allowed to represent system created objects that have no > corresponding

Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D"

e of the corresponding applied >configuration node must match the intended configuration >node. > > >Thanks, >Rob > > >On 06/10/2015 21:54, Juergen Schoenwaelder wrote: >> On Tue, Oct 06, 2015 at 09:00:30PM +0100, Robert Wilton wrote: >&g

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

On 9/28/15, 1:40 AM, "Juergen Schoenwaelder" <j.schoenwael...@jacobs-university.de> wrote: >On Wed, Sep 23, 2015 at 03:03:57PM +, Kent Watsen wrote: >> >> Popping the stack on this issue, the issue remains as to what to do >>with requirement 3: >>

Re: [netmod] opstate-reqs #4 (was #6: clarify impact of synchronous vs asynchronous)

Robert writes: intended configuration - this data represents the configuration state that the network operator intends the system to be in, and that has been accepted by the system as valid configuration. This data is colloquially referred to as the 'configuration' of the

[netmod] WG Last Call for draft-ietf-netmod-yang-metadata-02 (until 2015-10-22)

This is a notice to start a NETMOD WG last call for the document: Defining and Using Metadata with YANG http://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-02 Please indicate your support by Thursday October 22, 2015 at 9PM EDT. We are not only interested in receiving defect reports, we

Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully synchronized" in "Requirement 1.D"

This issue appears to have become more like issue #5 – should we mark this one a duplicate of the other? As for this, what does it mean? > > - templates: the intended data model and applied data model are disjoint > > This came up towards the end of the interim, and my understanding is that

Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)

What text do we agree to put into draft-chairs-netmod-opstate-reqs? I maintain that we need definitions for the terms "synchronous" and "asynchronous". Robert took a stab at defining these terms on the 24th (thanks Robert!), but so far no one has commented on them. So I don't think we're

Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs asynchronous (esp. wrt intended and applied)

[As a contributor] I find that the term "system" is a bit ambiguous in this context. It is talking about the NMS, the server, or both together? [KENT] I believe that we're talking about the NETCONF/RESTCONF/ server, specifically in how it processes update requests. Anyway, I've tried to

[netmod] opstate-reqs #4: Provide a tighter definition of "applied configuration"

Again, let's tackle a hard issue before tomorrow's interim meeting - this time the definition of "applied configuration": https://github.com/netmod-wg/opstate-reqs/issues/4 Currently, draft-chairs-netmod-opstate-reqs has this definition: o applied configuration - this data represents the

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

> This doesn't seem to be consistent with the rfc6241 section 5.1 that states: > "The running configuration datastore holds the complete configuration > currently active on the network device." Good catch! RFC 6241 appears to be inaccurate, unless we assume "currently active" means active

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

> Big confusion here. NETCONF/RESTCONF is synchronous not asynchronous. > Did you messes up the terms throughout this paragraph? If I swap all > of them, the text starts to make sense to me. Nope, but I grant you there are terminology issues here. What I mean, and have said before, is that

[netmod] WG Last Call for draft-ietf-netmod-yang-json-05 (until 2015-10-05)

This is a notice to start a NETMOD WG last call for the document "JSON Encoding of Data Modeled with YANG": https://tools.ietf.org/html/draft-ietf-netmod-yang-json-05 Please indicate your support by Monday October 5, 2015 at 9PM EDT. We are not only interested in receiving defect

[netmod] closing issues on opstate-reqs

Seven issues were filed against draft-chairs-netmod-opstate-reqs-00: https://github.com/netmod-wg/opstate-reqs/issues These issues are all currently in the NEW state. FYI, all the issue tracking states are described here:

[netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules

Regarding https://github.com/netmod-wg/opstate-reqs/issues/7 Jonathan> Why does 7(A) limit the scope to IETF-defined modules of others are now defining YANG modules? Benoit> Good point. We need to provide guidance for the other SDOs. Current text says: 7. Ability for

Re: [netmod] Consensus Call Note for Requirements

These GitHub issues were opened per this thread: - https://github.com/netmod-wg/opstate-reqs/issues/1 - https://github.com/netmod-wg/opstate-reqs/issues/2 - https://github.com/netmod-wg/opstate-reqs/issues/3 Thank you Rob! Kent On 9/11/15, 9:28 AM, "Lou Berger"

Re: [netmod] FW: New Version Notification for draft-chairs-netmod-opstate-reqs-00.txt

, Section 4.2 4. draft-openconfig-netmod-opstate-01, Section 4.3 5. draft-openconfig-netmod-opstate-01, Section 4.4 6. draft-openconfig-netmod-opstate-01, Section 4.5 7. draft-openconfig-netmod-model-structure-00 (no section) Kent On 9/11/15, 6:16 PM, "Kent Watsen&q

Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01

GitHub issue #4 has been raised to track the predominant concern raised in this thread: https://github.com/netmod-wg/opstate-reqs/issues/4 Thanks again Rob! Kent From: Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>> Date: Monday, September 14, 2015 at 3:12 PM To:

Re: [netmod] FW: New Version Notification for draft-chairs-netmod-opstate-reqs-00.txt - REQ 6 clarification

Rob, thanks for clarifying the need for 6B. No new GitHub issues filed for this thread. Kent On 9/14/15, 10:16 AM, "Rob Shakir" wrote: > >On 14 September 2015 at 08:43:53, Benoit Claise (bcla...@cisco.com) wrote: > >> Re-reading this section 4.5, I understand 6A and 6C, but is

Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01

[As a contributor] > This raises the issue "how does the client know that a missing applied > value means there is no applied value vs. the server does not know > and does not support reporting the applied value for a particular leaf?" > > None of the solutions allow a client to know that.

[netmod] FW: New Version Notification for draft-chairs-netmod-opstate-reqs-00.txt

tate-reqs-00.txt >has been successfully submitted by Kent Watsen and posted to the >IETF repository. > >Name: draft-chairs-netmod-opstate-reqs >Revision: 00 >Title: NETMOD Operational State Requirements >Document date: 2015-09-11 >Group:

Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig: tomorrow meeting

On 9/10/15, 5:19 AM, "Martin Bjorklund" wrote: >If the goal of this meeting is to agree on requirements, wouldn't it >help if we had them summarized in one place? Yes, we must have a list of requirements that everyone agrees to. We will subsequently put it into an email to

Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig: tomorrow meeting

Typo: - this is a duplicate of # 3-a + this is a duplicate of # 4-a Kent On 9/10/15, 10:46 AM, "Kent Watsen" <kwat...@juniper.net> wrote: >[As co-chair] > >To facilitate the meeting, following is a straw man list of requirements >based on what I've read. Let's

Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig: tomorrow meeting

Hi Anees, I was hoping this was going to come up on the call, but since it didn't... > hi -- some additional comments inline. I think that the revisit on some of > the operator requirements is primarily due to some proposed solution's > inability to address them. Can you elaborate on this?

Re: [netmod] minutes of the NETMOD 2015-08-31 virtual interim meeting

On 9/7/15, 3:31 AM, "Martin Bjorklund" wrote: >Juergen Schoenwaelder wrote: >> On Fri, Sep 04, 2015 at 09:29:53AM -0700, Andy Bierman wrote: >> > Hi, >> > >> > Is there a WEB page that lists all the upcoming virtual meetings? >> > This

<    4   5   6   7   8   9   10   >