Re: [netmod] Fwd: Re: Leafref and require-instance=false

[Kent Watsen]

I think the two leafs are coupled through the path statement and so the
values of both should conform to the same type. If I extend Balazs¹
example with uint8 and 1..10 range:

1. Would a leafref value of 256 be acceptable?

2. How about foo?


I agree it doesn't makes sense, but is the configuration invalid?

The leafref is marked require-instance=false, it just means a matching
condition will never succeed.

Would a configuration be invalid if a when expression could never
evaluate to true?


Kent

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

[netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)

[Kent Watsen]

This is a notice to start a NETMOD WG last call for the document Defining and 
Using Metadata with YANG:

https://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-01

Please indicate your support by Monday June 29, 2015 at 9PM EST.
We are not only interested in receiving defect reports, we are equally
interested in statements of the form:

  I have reviewed I-D XYZ and I found no issues
  I have implemented the data model in I-D XYZ
  I am implementing the data model in I-D XYZ
  I am considering to implement the data model in I-D XYZ

This is the first Last Call for this document.

Kent, as NETMOD co-chair

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

Re: [netmod] scheduling interim meetings

[Kent Watsen]

There has only been one response so far.  Please respond by tomorrow if
interested in having time during an interim meeting.

Thanks,
Kent


On 5/22/15, 5:39 PM, Kent Watsen kwat...@juniper.net wrote:


Following up on 
https://www.ietf.org/mail-archive/web/netmod/current/msg12549.html, and
also to help other drafts progress, we'd like to schedule 3-4 one-hour
virtual interim meetings before the meeting in Prague.

The first meeting is already set in terms of time and agenda (see below),
but the other slots remain open for signups.   To accommodate IETF's
2-week announcement requirement, please send your request for time before
next Thursday (5/28).

Tentative schedule:

Fri 6/12 11:30-12:30 EST: modeling operational state
(draft-openconfig-netmod-opstate)
Thu 6/18 10:00-11:00 EST: TBD

Thu 6/25 10:00-11:00 EST: TBD

Thu 7/02 10:00-11:00 EST: TBD


Please send your request for time to netmod-cha...@tools.ietf.org.

Thanks,
NETMOD co-chairs

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

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

Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)

[Kent Watsen]

1. In Section 3, it says:

snip/
   Does this mean that the annotation A can be used by *any* module
   the server advertises, or just the modules that define/import
   annotation A?

For all modules implemented by the server, no import is needed.


Good, but I think the text should say this explicitly.



   I assume that the intent is for the annotation to apply to
   the server as a whole, not any specific module.  It might

Yes. The description can also say that the annotation is ignored
elsewhere.

Maybe I don't understand your response, but if we agree that annotations
are a server-level thing (not module-specific), then I do not agree that a
module's description should be able to say that an annotation should be
ignored in other modules.



   help enforce this if annotations can only be defined in
   modules that don't define any data-nodes and it is required
   that the server advertises this module explicitly (not via
   an import)...

I expect this will be the normal way of defining annotations, and it
could appear in the document as a guideline. I don't think though it is
necessary to state it as a hard rule.

OK, a SHOULD or RECOMMENDED statement would help to clarify this.



3. In Section 4.2.2, adding metadata to the first entry in a list doesn't
 seem elegant.  Can we instead create a special list element like the
 following?

Maybe I don't understand but the idea is that a separate metadata objects
can be attached to any or all entries of a list. In the example it is
added only to the first entry but another metadata object could be added
to the second entry as well.

I see, but then this make the example misleading.  I thought it was trying
to show how to place an annotation on the list as a whole.  I see now it
says list instance, but this seems uninteresting example, as list
instances are just nodes for which how to apply annotations is already
known - there's nothing special about the node being a list element -
right?




It is not possible to add an annotation to the whole list, also because
this cannot be represented in XML encoding (via attributes).

An annotation cannot be attached to a list as a whole?  - that seems
fundamentally broken, though I understand why you say it cannot be easily
represented in XML (via attributes).  Should we consider alternative
representations?

That said, if unavoidable, the draft needs to call that out as a
limitation somewhere, because it wan't clear to me.  Are there other
limitations that are not also not being called out?




Thanks,
Kent (as a contributor)

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

Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)

[Kent Watsen]

All,

Today is the cutoff date for the Last Call for this draft, but the author 
indicated that comments received today or tomorrow can be incorporated into the 
draft-update being worked on.  So, if you have any lingering reviews, please 
send them before as soon as possible.

Thanks!
Kent



From: Kent Watsen kwat...@juniper.netmailto:kwat...@juniper.net
Date: Monday, June 15, 2015 at 6:49 PM
To: netmod@ietf.orgmailto:netmod@ietf.org 
netmod@ietf.orgmailto:netmod@ietf.org
Subject: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 
2015-06-29)


This is a notice to start a NETMOD WG last call for the document Defining and 
Using Metadata with YANG:

https://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-01

Please indicate your support by Monday June 29, 2015 at 9PM EST.
We are not only interested in receiving defect reports, we are equally
interested in statements of the form:

  I have reviewed I-D XYZ and I found no issues
  I have implemented the data model in I-D XYZ
  I am implementing the data model in I-D XYZ
  I am considering to implement the data model in I-D XYZ

This is the first Last Call for this document.

Kent, as NETMOD co-chair

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

Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)

[Kent Watsen]

Maybe I don't understand your response, but if we agree that annotations
 are a server-level thing (not module-specific), then I do not agree
that a
 module's description should be able to say that an annotation should be
 ignored in other modules.


It depends on the annotation's semantics, and it may be designed to do
something only for certain node instances (such as leafs with union
type), or for nodes in a given namespace etc. Do you think it may be a
problem?

Those kinds of uses are fine, as they are not module-specific.  I just
want to ensure we don't ever wind up with module-specific annotations



 I see, but then this make the example misleading.  I thought it was
trying
 to show how to place an annotation on the list as a whole.  I see now
 it says list instance, but this seems uninteresting example, as list

I will use list entry because the term instance in not defined in
YANG.

 instances are just nodes for which how to apply annotations is already
 known - there's nothing special about the node being a list element -
 right?

Do you suggest to remove the second example in that section? But you
also wanted to add an example on anydata that is arguable even more
alike to a container.

Yes, an example for each item discussed (including anydata) is desired.
What I'm questioning here is why we need to discuss annotating list
entries at all, since they seem to follow normal rules.   If true, I
recommend removing a special section for list entries/instances entirely.



An annotation cannot be attached to a list as a whole?  - that seems
 fundamentally broken, though I understand why you say it cannot be
easily
 represented in XML (via attributes).  Should we consider alternative
 representations?

I agree it might be useful, and I was thinking about it but I haven't
found any good way for encoding it in XML, also because in XML list
entries can be interspersed with other elements.

Interspersed with other elements?  - I don't understand.  For instance,
assuming:

  container foobars {
list foo {
  ...
}
list bar {
}
  }

The XML would be:

  foobars
foo.../foo

foo.../foo

foo.../foo

bar.../bar


bar.../bar

bar.../bar

  /foobars

Where is the interspersion?

As for how to place annotations on an XML list as a whole, I was thinking
we could use a fake first element.  For instance, the following shows an
annotation on the bar list:

  foobars
foo.../foo
foo.../foo
foo.../foo
bar color=red/   // colors entire list red  (notice empty
element)
bar.../bar
bar.../bar
bar.../bar
  /foobars


But this is most likely illegal since it's not a valid instance document.
So then maybe we could use an XML comment like this:

  foobars
foo.../foo
foo.../foo
foo.../foo
!-- annotation: bar color=red --
bar.../bar
bar.../bar
bar.../bar
  /foobars


Ugh, this isn't great either.  Anybody else have an idea?



That said, if unavoidable, the draft needs to call that out as a
 limitation somewhere, because it wan't clear to me.  Are there other
 limitations that are not also not being called out?

Well, one could e.g. think about structured annotations but this is
again not exactly easy with XML attributes. I don't think though we can
really call it limitations - after all, the motivation for this document
was to officialize the use of XML attributes, so it would be a bit
weird to to make it incompatible with them.

True, I'd rather we can find a solution for annotating XML lists.  Until
then, the draft SHOULD explicitly call it out as not supported.   Maybe
put in into an OPEN ISSUES section?


Thanks,
Kent (as a contributor)





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

[netmod] presentations for ietf 93

[Kent Watsen]

The NETMOD working group is meeting twice for IETF 93 in Prague:

Monday:  18:50-19:50  (1 hour)
Tuesday: 15:20-17:20  (2 hours)

If you would like to request a time-slot for a presentation at IETF 93, please 
reply by Friday, July 10th with the following information:

1) Draft title
2) Presenter name
3) Requested duration

Requests for slots with discussion on the mailing list are given priority.   
Please start a discussion on your draft now if needed.

Thanks,
Kent

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

Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)

[Kent Watsen]

[As an individual contributor]

Already many comments have been made, hopefully he below comments are new:


1. In Section 3, it says:

  By advertising a YANG module in which metadata annotation A is
   defined using the md:annotation statement, a server specifies
   support for the syntax of annotation A.  This means that
   configuration or state data, RPC messages and notifications will be
   considered syntactically valid if annotation A is attached to any
   data node instance, provided that all rules stated in this document
   are observed.


  Does this mean that the annotation A can be used by *any* module
  the server advertises, or just the modules that define/import
  annotation A?
 
  For example, could a YANG module be defined like this:

   module example-color-text {
 namespace http://example.org/example-color-text;;
 prefix rgb;
 import ietf-yang-metadata { prefix md; }
 description
   Text is black, unless colored otherwise;
 md:annotation color {
   type enumeration {
 enum red;
 enum green;
 enum blue;
   }
   description
 This annotation only makes sense within this module.
  Application of this annotation to any data node
  Recursively applies to all its descendent nodes.;
 }
 container document {
   list paragraph {
 list sentence {
   leaf-list word {
 type string;
   }
 }
   }
 }
   }



  I assume that the intent is for the annotation to apply to
  the server as a whole, not any specific module.  It might
  help enforce this if annotations can only be defined in
  modules that don't define any data-nodes and it is required
  that the server advertises this module explicitly (not via
  an import)...



2. Also in Section 3, s/conditional:/conditional;/




3. In Section 4.2.2, adding metadata to the first entry in a list doesn't
seem elegant.  Can we instead create a special list element like the
following?

   seq: [
 {
   @: {
   example-inactive:inactive: true

   }
 },
 {
   name: two,
   ...
 }
   ]

  I don't think that '@' is a valid identifier string, so it's
  syntactically OK, right?



4. Also in Section 4.2.2, an anydata example would complete this section...



5. In Section 4.2.3, an anyxml example would complete this section...


Thanks,
Kent



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

Re: [netmod] Agenda posted for IETF 93 meeting

[Kent Watsen]

All, the agenda for today's meeting has been updated.  The update is as follows:

  * 10 min: draft-bjorklund-netmod-openconfig-reply-00 (Juergen Schoenwaelder)

Thanks,
Kent

From: Kent Watsen kwat...@juniper.netmailto:kwat...@juniper.net
Date: Friday, July 17, 2015 at 10:47 AM
To: netmod@ietf.orgmailto:netmod@ietf.org 
netmod@ietf.orgmailto:netmod@ietf.org
Subject: Re: [netmod] Agenda posted for IETF 93 meeting


All, the agenda has been updated as follows:

  1. Pravin Gohite is now presenting draft-ietf-netmod-syslog-model-04
  2. Added 5 minutes for draft-bogdanovic-netmod-yang-model-classification-03
  3. Added 5 minutes for  draft-wilton-netmod-intf-vlan-yang-00
  4. Reordered Tuesday's presentations

Presenters:
  - please send your slides to the chairs no later than the night before your 
presentation
  - Monday's schedule has no wiggle room, please adhere to your time 
allocations!


Thanks,
Kent


From: Kent Watsen kwat...@juniper.netmailto:kwat...@juniper.net
Date: Wednesday, July 15, 2015 at 4:05 PM
To: netmod@ietf.orgmailto:netmod@ietf.org 
netmod@ietf.orgmailto:netmod@ietf.org
Subject: [netmod] Agenda posted for IETF 93 meeting


The preliminary agenda for the two NETMOD sessions has been posted here:

https://www.ietf.org/proceedings/93/agenda/agenda-93-netmod

Please note that a discussion regarding Open Config will not occur due to 
scheduling conflicts.  Otherwise, please let us know if any adjustments are 
needed.

Thanks,
Kent




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

Re: [netmod] Y34 - root node

[Kent Watsen]

I like the idea of relocatable modules.  It is almost to say everything defined 
by the IETF should be a grouping, allowing others to assemble the pieces as 
they see fit.  I do not think it makes sense for IETF to define an uber 
structure, especially using a language mandating forever backwards 
compatibility...

How to support logical/virtual systems is a bigger discussion.   Certainly 
there is a huge data model overlap between the host system and the logical 
systems, but some data may only exist in the host system and some data may only 
exist in a logical system.  Making things more interesting, some data in the 
host system (e.g., an interface) can be exported to a logical system as a 
read-only value.   The way I solved this in another life was using conditional 
enablement [1] on a shared data model to indicate the applicability of nodes in 
a context.

[1] https://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00

Kent, as a contributor



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

Re: [netmod] preliminary agenda for yokohama posted

[Kent Watsen]

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.net>>
Date: Saturday, October 24, 2015 at 2:33 AM
To: "netmod@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] preliminary agenda for yokohama posted

Here’s an update to the agenda for the two sessions at 94:

Updates:
  - syslog removed (because it’s ready for Last Call)
  - diffserv removed (nothing to report)
  - models moved to morning slot
  - times and presenters locked in (almost)

https://www.ietf.org/proceedings/94/agenda/agenda-94-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@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: [netmod] preliminary agenda for yokohama posted


The preliminary agenda for the two sessions at Yokohama has been posted here:

https://www.ietf.org/proceedings/94/agenda/agenda-94-netmod

Obviously a lot of unknowns, but that's what "preliminary" means right?  ;)

Kent   // chair hat on

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

Re: [netmod] preliminary agenda for yokohama posted

[Kent Watsen]

Here’s an update to the agenda for the two sessions at 94:

Updates:
  - syslog removed (because it’s ready for Last Call)
  - diffserv removed (nothing to report)
  - models moved to morning slot
  - times and presenters locked in (almost)

https://www.ietf.org/proceedings/94/agenda/agenda-94-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@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: [netmod] preliminary agenda for yokohama posted


The preliminary agenda for the two sessions at Yokohama has been posted here:

https://www.ietf.org/proceedings/94/agenda/agenda-94-netmod

Obviously a lot of unknowns, but that's what "preliminary" means right?  ;)

Kent   // chair hat on

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

[netmod] draft netmod 94 minutes posted

[Kent Watsen]

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

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

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

[Kent Watsen]

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.  If anyone 
has one I could borrow for the morning session, I would be most grateful!

K.

From: netmod > on 
behalf of "Andrew McLachlan (amclachl)" 
>
Date: Wednesday, November 4, 2015 at 12:33 AM
To: "netmod@ietf.org" 
>
Subject: [netmod] IETF 94 - Remote Participation information and request for 
jabber scribes

Dear All

Request for Jabber Scribes

We would be very grateful if there are a couple of folks who would be willing 
to volunteer as a scribe for either of the two sessions we have at this IETF.

Since I’m unable to attend this IETF, and the tz is against me for email later, 
please ping both Kent and I directly just to be sure one of us sees your email 
before the meetings.

kwat...@juniper.net
amcla...@cisco.com

Wednesday:
0900 - 1130 JST - Room 301 -
1300 - 1500 JST - Rooms 411/412 -

Room - xmpp:net...@jabber.ietf.org?join
Logs - http://jabber.ietf.org/logs/netmod


Remote Participation

Following on from IETF 92 & 93,  IETF 94 is going to be expanding the use of 
the Meetecho.

Details of how to use this system are available here - 
http://ietf.org/meeting/94/remote-participation.html#Meetecho

The two sessions are available via the following links

0900 - 1130 JST - Room 301 - http://www.meetecho.com/ietf94/netmod
1300 - 1500 JST - Rooms 411/412 - http://www.meetecho.com/ietf94/netmod_II


Thank you in advance.


Kent, Tom, Andrew
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

>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 thinking about market response.  It is a bit frustrating
to even think that solution might not be widely popular, but the reality
is that I don't see how it can be widely implemented - and so maybe it
will only be popular for datacenter operators?

Kent // as a contributor


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

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

[Kent Watsen]

>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 server MUST fully *attempt* to
apply..."

In my view, the server does not have to "fully apply", it merely has to
have attempted to do so.  Essentially, a request comes in resulting in a
flurry of activity, that ultimately stabilizes, at which point the
response can be sent.

If a line card is missing, then (as I understand it), the server would not
wait for the line-card to show up.  That said, if the client requested
transactional/atomic update, a missing line-card would cause an immediate
failure/rollback.

Makes sense?

Kent  // as a contributor

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

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

[Kent Watsen]

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 author or contributor please respond to this
email explicitly regardless of whether or not you are aware of any relevant IPR.
The response needs to be sent to the NETMOD WG mailing list.  The document
will not advance to the next stage until a response has been received from each
author and contributor.

If you are on the NETMOD WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any IPR 
that
has not yet been disclosed in conformance with IETF rules.

Thank you,

Kent and Tom, NETMOD WG Chairs

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

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

[Kent Watsen]

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 time-line of things, but
>the draft needs to be posted today...  Can you help finalize the text?
>
>Randy offers some good editorial suggestions below, and I believe you and
>Gert had some ideas in wordsmithing 1.D. and bringing in error modes.
>
>Thanks,
>Kent
>
>
>On 10/16/15, 11:29 PM, "Randy Presuhn" <randy_pres...@mindspring.com>
>wrote:
>
>>Hi -
>>
>>> From: Robert Wilton
>>> Sent: Oct 16, 2015 5:12 AM
>>> To: Kent Watsen , Nadeau Thomas
>>> Cc: "netmod@ietf.org"
>>> Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for
>>>asynchronous systems to provide a blocking config update?
>>...
>>>Here is my attempt at word smithing section 3:
>>...
>>> A. A server may choose to support only synchronous
>>>configuration
>>>operations, or only asynchronous configuration
>>>operations, or
>>>both synchronous and asynchronous configuration
>>>operations in
>>>a client specified per-operation basis.
>>
>>Editorial comments:
>>  - is the "may" intended as a RFC 2119 MAY?  If so, this seems
>>a semantically inappropriate use of the keyword.
>>  - please avoid unnecessary anthropomorphisms; the server doesn't
>>"choose" anything here.
>>  - s/ in/ on/
>>  - s/client specified/client-specified/
>>
>>...
>>>  failed.  A configuration protocol, or server, SHOULD provide
>>>  support for rollback-on-error behavior and MAY choose to
>>>  provide support for best effort semantics as well.
>>
>>Editorial comments:
>>
>>  - The implications of the RFC 2119 SHOULD and MAY are quite different
>>depending on which of the two subjects ("protocol" or "server") one
>>chooses to think about.  The server's observable behaviour is
>>presumably
>>circumscribed by the protocol, so I suggest removing ", or server,".
>>
>>  - Please suppress anthropomorphisms.
>>
>>  - s/best effort/best-effort/
>>
>>Randy
>>
>>___
>>netmod mailing list
>>netmod@ietf.org
>>https://www.ietf.org/mailman/listinfo/netmod
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

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

[Kent Watsen]

OK, it looks like we converged.  Thank you all.
I will use the text below for the draft.

Kent   // with editor hat on  ;)



On 10/19/15, 9:52 AM, "Robert Wilton" <rwil...@cisco.com> wrote:

>Hi Kent, Gert,
>
>For clarity, the text that I had reached for 3 (folding in the comments
>so far) is this:
>
>3.  Support for both synchronous and asynchronous configuration
>operations (see terms)
>
>A. A server may support only synchronous configuration
>   operations, or only asynchronous configuration operations, or
>   both synchronous and asynchronous configuration operations on
>   a client-specified per-operation basis.
>
>B. Servers that support asynchronous configuration operations MAY
>   also provide a verify operation that a client can request from
>   the server to return information regarding the difference
>   between the intended and applied configurations.
>
>C. The configuration protocol MUST specify how configuration
>   errors are handled.  Errors may be handled by "stop on error",
>   "continue on error" or "rollback on error" semantics (see
>   terms).  Support for "rollback on error" SHOULD be provided.
>
>
>  Extra terms to add the definitions section (based on the definitions
>for NETCONF RFC):
>
>   stop-on-error:  The configuration operation is aborted on the
>first
> error.
>
>  continue-on-error:  Continue to process configuration data on
> error; error is recorded, and negative response is generated
> if any errors occur.
>
>  rollback-on-error:  If an error condition occurs such that part
> of applying the configuration fails, the server will stop
> processing the configuration operation and restore the
> specified configuration to its complete state at the start
> 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 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 time-line of things,
>>>but
>>> the draft needs to be posted today...  Can you help finalize the text?
>>>
>>> Randy offers some good editorial suggestions below, and I believe you
>>>and
>>> Gert had some ideas in wordsmithing 1.D. and bringing in error modes.
>>>
>>> Thanks,
>>> Kent
>>>
>>>
>>> On 10/16/15, 11:29 PM, "Randy Presuhn" <randy_pres...@mindspring.com>
>>> wrote:
>>>
>>>> Hi -
>>>>
>>>>> From: Robert Wilton
>>>>> Sent: Oct 16, 2015 5:12 AM
>>>>> To: Kent Watsen , Nadeau Thomas
>>>>> Cc: "netmod@ietf.org"
>>>>> Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for
>>>>> asynchronous systems to provide a blocking config update?
>>>> ...
>>>>> Here is my attempt at word smithing section 3:
>>>> ...
>>>>>  A. A server may choose to support only synchronous
>>>>> configuration
>>>>> operations, or only asynchronous configuration
>>>>> operations, or
>>>>> both synchronous and asynchronous configuration
>>>>> operations in
>>>>> a client specified per-operation basis.
>>>> Editorial comments:
>>>>   - is the "may" intended as a RFC 2119 MAY?  If so, this seems
>>>> a semantically inappropriate use of the keyword.
>>>>   - please avoid unnecessary anthropomorphisms; the server doesn't
>>>> "choose" anything here.
>>>>   - s/ in/ on/
>>>>   - s/client specified/client-specified/
>>>>
>>>> ...
>>>>>   failed.  A configuration protocol, or server, SHOULD
>>>>>provide
>>>>>   support for rollback-on-error behavior and MAY choose to
>>>>>   provide support for best effort semantics as well.
>>>> Editorial comments:
>>>>
>>>>   - The implications of the RFC 2119 SHOULD and MAY are quite
>>>>different
>>>> depending on which of the two subjects ("protocol" or "server")
>>>>one
>>>> chooses to think about.  The server's observable behaviour is
>>>> presumably
>>>> circumscribed by the protocol, so I suggest removing ", or
>>>>server,".
>>>>
>>>>   - Please suppress anthropomorphisms.
>>>>
>>>>   - s/best effort/best-effort/
>>>>
>>>> Randy
>>>>
>>>> ___
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> .
>>
>

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

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

[Kent Watsen]

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 configuration?
>
> Requirement 1.D states

 D.  For asynchronous systems, when fully synchronized, the data
   in the applied configuration is the same as the data in the
   intended configuration.

>
> So, if this requirement statement stands as being valid (which I think it 
> should) then that would imply that the answer for both the two issues above 
> must be "no".  The only question would be whether these need to be explicitly 
> listed out?

[KENT] so I think I have to (begrudgingly) agree with your logic.I have 
heard the operators state that they want the intended/applied comparison to be 
drop-dead simple.  To that end, it would not be possible to flatten templates 
or apply defaults, or make any other change - it needs to be as close as 
possible to a carbon-copy of the original intended configuration (where 
deviations are allowed only for cases like a missing line-card).  To this end, 
yes, I think that we could tack on a statement like the following:

That is, the intended configuration is a subset of the applied
configuration where omissions are only due to when the
configuration cannot be applied (e.g., a missing line-card).

What do you think?



>>  - how does it relate to the state of the system after a equivalent 
>> synchronous config commit (if at all)?
>>
> Again, I think that definition of requirement 1.D, along with the proposed 
> definition of synchronous configuration operation vs asynchronous 
> configuration operation, will provide a sufficient answer to this question.  
> I.e. that the state of the system after an asynchronous config operation 
> must, when fully synchronized, be the same as the state of the system after 
> an equivalent synchronous configuration operation completes and replies back.

[KENT] I agree with this, but I think it impacts issue #6 more so than issue #4 
- right?


Thanks,
Kent


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

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

[Kent Watsen]

The new 1-D works for me.  It is similar in spirit to the proposal I just
sent in the issue #4 thread.

Thanks,
Kent


On 10/13/15, 9:14 AM, "Robert Wilton" <rwil...@cisco.com> wrote:

>In an attempt to try and close on some of the proposed requirement text
>before Thursday's interim meeting.
>
>Does anyone have any outstanding objections on using this proposed text
>for Requirement 1.D, or is it sufficiently clear to update the draft,
>and resolve issue 1?
>
>OLD text for Requirement 1:
>
>1.  Ability to interact with both intended and applied configuration
>
>A.  The ability to ask the operational components of a system
>(e.g., line cards) for the configuration that they are
>currently using.  This is the "applied configuration".
>
>B.  Applied configuration is read-only
>
>C.  The data model for the applied configuration is the same as
>the data model for the intended configuration (same leaves)
>
>D.  For asynchronous systems, when fully synchronized, the data
>in the applied configuration is the same as the data in the
>intended configuration.
>
>
>NEW text (as above, changing 1.D only):
>
>1.  Ability to interact with both intended and applied configuration
>
>A.  The ability to ask the operational components of a system
>(e.g., line cards) for the configuration that they are
>currently using.  This is the "applied configuration".
>
>B.  Applied configuration is read-only
>
>C.  The data model for the applied configuration is the same as
>the data model for the intended configuration (same leaves)
>
>D.  When the configuration change for any intended configuration
>node has been successfully applied to the system (e.g. not
>failed, nor deferred due to absent hardware) then the
>existence and value 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:
>>> Hi Juergen,
>>>
>>> On 06/10/2015 17:01, Juergen Schoenwaelder wrote:
>>>> On Tue, Oct 06, 2015 at 10:38:11AM +0100, Robert Wilton wrote:
>>>>> Hi Kent,
>>>>>
>>>>> On 06/10/2015 01:40, Kent Watsen wrote:
>>>>>> This issue appears to have become more like issue #5 ­ should we
>>>>>>mark
>>>>>> this one a duplicate of the other?
>>>>> I suggest that we can just finalize on the text being discussed to
>>>>> replace 1.D and then resolve issue #1.
>>>>>
>>>>> Jason had proposed this text:
>>>>>
>>>>> When the configuration change for any intended configuration node has
>>>>> been successfully applied to the system (e.g. not failed, nor
>>>>>deferred
>>>>> due to absent hardware) then the existence and value of the applied
>>>>> equivalent of the node (whether that be a corresponding node in the
>>>>>data
>>>>> model, an attribute associated with the intended config node, the
>>>>> configuration node read from a different datastore or context, etc)
>>>>>must
>>>>> match the intended configuration node.
>>>> I have no clue what "an attribute associated with the intended config
>>>> node" or "the configuration node read from a different datastore or
>>>> context" or "etc". means. What exactly is an "applied equivalent of
>>>> the node"?
>>>>
>>>>> Or perhaps this slightly briefer alternative is better?:
>>>>>
>>>>>  D.  When the configuration change for any intended
>>>>>  configuration node has been successfully applied to the
>>>>>  system (e.g. not failed, nor deferred due to absent
>>>>>hardware)
>>>>>  then the existence and value of the corresponding,
>>>>>possibly
>>>>>  notional, applied configuration node must match the
>>>>>intended
>>>>>  configuration node.
>>>> What is the purpose of the phrase "possibly notional"?
>>> There was a concern that my previous text, i.e. as above but without
>>> "possibly notional", imp

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

[Kent Watsen]

Hi Carl,

I understand your concern, but isn't it up to the server to decide the
response it provides in that case?  Already I think the server needs to
scatter/gather responses from the operational components in the system and
stitch together a result.  In this case, the stitching may fail and hence
it reports an error of some sort (e.g., not-completely-applied) - what do
you think?

Kent



On 10/15/15, 9:05 AM, "Carl Moberg (camoberg)" <camob...@cisco.com> wrote:

>
> Maybe we¹re coming down to a definition of ³requirement² here. But the
>issue I raised can be summarized as follows:
>
>³²²
>The assumption of a 1:1 mapping ignores situations where a change to an
>intended configuration leaf value may result in several instances of
>applied configuration leaf values (operational state) to be updated in
>the backend framework across 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 <kwat...@juniper.net> wrote:
>> 
>> 
>> I believe that you are correct, it seems that we've doubled-down on 1C
>>and so #5 should now be marked as DEAD.
>> 
>> This action will be taken if no objection is made before tomorrow's
>>interim.
>> 
>> Thanks,
>> Kent
>> 
>> 
>> From: Robert Wilton <rwil...@cisco.com>
>> Date: Tuesday, October 13, 2015 at 9:29 AM
>> To: Kent Watsen <kwat...@juniper.net>, "netmod@ietf.org"
>><netmod@ietf.org>
>> Subject: Re: [netmod] opstate-reqs #5: Support for situations when
>>structure of intended configuration is not the same as applied
>> 
>> From the interim meeting two weeks ago, it was clarified that the
>>schema of the intended configuration nodes are expected to be the same
>>as the schema of the applied configuration nodes so that clients can
>>easily relate between the two.
>> 
>> I think that the requirement text for 1.C and the proposed updated text
>>for 1.D makes this reasonable clear.
>> 
>> Hence, is issue 5 now at the state where is can be closed as not being
>>a requirement?  Or is there something further that needs to be discussed
>>first?
>> 
>> Thanks,
>> Rob
>> 
>> 
>> On 30/09/2015 16:44, Kent Watsen wrote:
>>> 
>>> It's time to tackle another issue, just before tomorrow's meeting, and
>>>this time I'm picking a hard one:
>>> 
>>> https://github.com/netmod-wg/opstate-reqs/issues/5
>>> 
>>> Already Carl, Mahesh, Einar, and Andy have posted 18 comments on the
>>>GitHub issue tracker.Please first read the comments posted there
>>>and then continue the discussion here on the mailing list (not on the
>>>GitHub issue tracker).
>>> 
>>> Note that this issue is closely tied to the definition of "applied
>>>configuration", which is exactly what issue #4 regards
>>>(https://github.com/netmod-wg/opstate-reqs/issues/4), for which Mahesh
>>>and Einar have posted comments on already.   As these two issues (#4
>>>and #5) are so highly related, I'm going to simultaneously open the
>>>other issue for discussion now as well.
>>> 
>>> Thanks,
>>> Kent
>>> 
>>> 
>>> 
>>> ___
>>> netmod mailing list
>>> 
>>> netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>

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

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

[Kent Watsen]

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>>, Robert 
Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs 
asynchronous (esp. wrt intended and applied)

Kent, Rob,

Comparing the cases, the definition of the asynchronous case doesn’t look 
complete. The way it stands for the synchronous operation, the client knows 
that it's intended config was good AND it has been effected to the server. In 
the Asynchronous case, the client only knows that the intended config was good 
– and that’s not enough.

So the proposal is to refine the asynchronous case definition as follows:

Asynchronous configuration operation - A configuration request to update the 
running configuration of a server that is applied asynchronously with respect 
to the client request.  The server MUST update its intended configuration (see 
term) before replying to the client indicating whether the request will be 
processed.  The reply to the client only indicates whether there are any errors 
in the  original request.
The server's applied configuration state (see term) is updated after the 
configuration change has been applied to all impacted components in the server. 
 Once applied, the client MUST be notified whether the intended config is now 
fully effective or there are any errors from applying the configuration change.

In addition I would suggest to require a verify operation which a client can 
request from the server to obtain above information on an on-demand basis. 
Would that somehow go in the opstate-reqs #3 then?

Best

Gert




From: netmod <netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>> on 
behalf of Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>>
Date: Thursday 15 October 2015 00:11
To: Robert Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs 
asynchronous (esp. wrt intended and applied)

Hi Robert,

One comment, it seems that the asynchronous configuration operation should
have one more sentence at its end saying that an asynchronous notification
must be used to report any errors produced from when applying the
configuration.

What do you think?

Kent  // as a contributor



On 10/14/15, 10:59 AM, "Robert Wilton" 
<rwil...@cisco.com<mailto:rwil...@cisco.com>> wrote:

Hi All,

Are there any more comments on the following proposed descriptions, or
are these descriptions sufficiently clear to update the requirements
draft and resolve issue #6?

Synchronous configuration operation - A configuration request to update
the running configuration of a server that is applied synchronously with
respect to the client request.  The server MUST fully effect the
configuration change to all impacted components in the server, updating
both the server's intended and applied configuration (see terms), before
replying to the client.  The reply to the client indicates whether there
are any errors in the request or errors from applying the configuration
change.

Asynchronous configuration operation - A configuration request to update
the running configuration of a server that is applied asynchronously
with respect to the client request.  The server MUST update its intended
configuration (see term) before replying to the client indicating
whether the request will be processed.  The server's applied
configuration state (see term) is updated after the configuration change
has been fully effected to all impacted components in the server.  The
reply to the client only indicates whether there are any errors in the
original request.

Synchronous configuration server - a configuration server that processes
all configuration operations as synchronous configuration operations.

Asynchronous configuration server - a configuration server that processes
all configuration operations as asynchronous configuration operations.

Thanks,
Rob


On 13/10/2015 09:48, Juergen Schoenwaelder wrote:
On Tue, Oct 06, 2015 at 09:42:37PM +0100, Robert Wilton wrote:
Hi Juergen,

On 06/10/2015 17:16, Juergen Schoenwaelder wrote:
On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote:
Hi Kent,

Feeding in the various input, I think that this is the best
refinement
that I've come up with:

Synchronous configuration operation - A configuration request to
update
the running configuration of a server that is applied synchronously
with
respect to the client

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

[Kent Watsen]

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"

[Kent Watsen]

These terms were edited on today's call, resulting in the following:

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

  * applied configuration - this data represents the configuration
state that the network element is actually in.  That is, the
configuration state which is currently being used by system
components (e.g., control plane daemons, operating system
kernels, line cards).

NOTE: The system's ability to report applied configuration accurately
may be limited in some cases, such as when the the configuration
goes through an intermediate layer without an ability to inspect the
lower layer.

If no objection is raise by tomorrow, this issue will be moved to the
EDIT state and I'll plan to make the change in the draft before Monday's
cutoff.

Kent


From: Robert Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>>
Date: Thursday, October 15, 2015 at 5:50 AM
To: Jonathan Hansford <jonat...@hansfords.net<mailto:jonat...@hansfords.net>>, 
Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>>, Andy Bierman 
<a...@yumaworks.com<mailto:a...@yumaworks.com>>
Cc: "netmod@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of"applied 
configuration"

Hi Jonathan,

Yes, of course, in the general case your statement is completely true.

I think that my premise would still hold if either:
 - there is coordination of the intended configuration between multiple NMS
 - responsibility for parts of the configuration is split between multiple NMS 
and they are each independently responsible for ensuring that their part of the 
configuration has been programmed correctly.

My point is really that I would more naturally expect the definitive 
configuration for a device to be known and held (perhaps in a distributed 
fashion) somewhere in the operators management network, not on the device 
itself.

Thanks,
Rob


On 15/10/2015 09:55, Jonathan Hansford wrote:

The NMS only knows the intended config if it is the only NMS capable of 
changing that device’s 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/10/2015 20:15, Kent Watsen wrote:
Andy writes:
> I am wondering why operators would want to compare 2 massive subtrees
> in the first place, where 1 is static and the other is changing constantly.
>
> Do they really want this complex task or do they just want to
> determine if the intended config has been applied yet?

I think that it is more the latter.   And there have been suggestions for 
solutions to provide something like a yang-patch to describe just the diffs.  
Makes sense to me!

The NMS already knows the intended config since it sent it to the device in the 
first place, so in normal circumstances I would expect the NMS to only query 
the applied config (and possibly derived state at the same time) and then 
compare it to the NMS's view of the intended cfg for that device.  If the NMS 
is smart then it might be able to restrict most of the queries to only the 
device's applied config sub-trees that could possibly be out of sync, perhaps 
with periodic full synchronization checks.

Otherwise, I think that a function that returns just the diff may also be 
useful (the draft that I put forward also proposes a diff-cfg-only option).  
However, it is also worth noting that the original requirements don't 
explicitly ask for this, so perhaps more of a nice to have than a formal 
requirement?

Thanks,
Rob




K.


From: Andy Bierman 
<<mailto:a...@yumaworks.com>a...@yumaworks.com<mailto:a...@yumaworks.com>>
Date: Wednesday, October 14, 2015 at 2:56 PM
To: Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>>
Cc: Robert Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] opstate-reqs #4: Provide a tighter definition of "applied 
configuration"



On Wed, Oct 14, 2015 at 11:00 AM, Kent Watsen 
<<mailto:kwat...@juniper.net>kwat...@juniper.net<mailto:kwat...@juniper.net>> 
wrote:

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 sys

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

[Kent Watsen]

>>> 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.  The server MUST fully attempt to
>>>apply
>>>  the configuration change to all impacted components in the server,
>>>  updating both the server's intended and applied configuration
>>>(see terms),
>>>  before replying to the client.  This may be transactional or non-
>>>  transactional (need terms!).  The transactionality of the
>>>operation
>>>  may be a server property or specified on as a property.
>> I do not understand the transactionality blurb. What is it and why is
>> it relevant? (The last sentence above also seems incomplete.)
>
>It was added in the meeting because some interpretations of the text
>assumed that the text implied that the server would always
>rollback-on-error, so the proposed text was intended to clarify that.
>
>However, I think that this clarification applies equally to both sync
>and async operations and hence I have proposed (on a separate thread)
>that it be documented as part of the requirement 3 "Support for both
>synchronous and asynchronous configuration operations" instead.


So the proposal is to remove the last two sentences? - I'm OK with that.

I think that the new word "attempt" in the previous sentence fixed it to
be (IMO) a very good definition for what is meant by a "synchronous
configuration operation" without it getting mired in details.

Kent

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

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

[Kent Watsen]

> Why is there a need to update the intended config?

Because that is what happens via requests like  and PATCH.  The 
intended (running) config gets updated first and then config is distributed to 
internal components, ultimately updated the applied config.

Kent  // as a contributor


From: 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.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs 
asynchronous (esp. wrt intended and applied)

Kent,

The new one looks much better. However the last sentence is confusing with 
respect to intended config. Why is there a need to update the intended config?

Proposal:
The server MUST fully attempt to apply
the configuration change to all impacted components in the server,
updating the server's applied configuration (see terms),
before replying to the client.

Sent from my Apple ][

On 16 Oct 2015, at 15:45, Kent Watsen 
<kwat...@juniper.net<mailto:kwat...@juniper.net>> wrote:


Gert writes:
> I don't see the need for defining synchronous/asynchronous config servers.

Thank you (and Juergen) for the confirmation.   Again, if no objections, these 
two terms will not be removed.


> The new definitions look good. Later in the discussion there was a common
> sentiment that the requirement for synchronous operations contained some
> crisp wording we could use here too.  I particularly liked the mentioning of
> blocking requests for some time,

[Note: the following removes the last two sentences on "transactions", as being 
discussed elsewhere on this thread]

OLD:

Synchronous configuration operation - A configuration request to update
the running configuration of a server that is applied synchronously with
respect to the client request.  The server MUST fully attempt to apply
the configuration change to all impacted components in the server,
updating both the server's intended and applied configuration (see terms),
before replying to the client.

NEW

Synchronous configuration operation - A configuration request to update
the running configuration of a server that is applied synchronously with
respect to the client request (i.e. a blocking call).  The server MUST 
fully attempt to apply
the configuration change to all impacted components in the server,
updating both the server's intended and applied configuration (see terms),
before replying to the client.


What do you think?

Kent

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

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

[Kent Watsen]

This draft has been posted as a WG draft (i.e. s/chairs/ietf/).

Thank you everyone for the time it's taken to bring it to this state.

Moving forwards, please don't wait to post comments.   That is, it's okay
to continue the discussion before the meeting in Yokohama.  We will open
new issues on the GitHub issue tracker as needed.

Thanks again,
Kent


On 10/19/15, 1:07 PM, "internet-dra...@ietf.org"
<internet-dra...@ietf.org> wrote:

>
>A New Internet-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   : NETMOD Operational State Requirements
>Authors : Kent Watsen
>  Thomas Nadeau
>   Filename: draft-ietf-netmod-opstate-reqs-00.txt
>   Pages   : 8
>   Date: 2015-10-19
>
>Abstract:
>   This document defines requirements for servers enabling better
>   visibility and control over the server's operational state.  To
>   achieve this end, this document also defines terminology describing a
>   conceptual model enabling the requirements to be expressed.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/
>
>There's also a htmlized version available at:
>https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-00
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

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

[Kent Watsen]

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:
>> 
>>3.  Support for both transactional, synchronous management systems
>> as well as distributed, asynchronous management systems
>>
>
>I fail to understand 'transactional' and 'distributed' here.

I hope that these terms will be clarified on tomorrow's call.   There is
also a chance that these terms will be removed from the text altogether,
as they may be viewed as unnecessarily qualify the
synchronous/asynchronous terms.


> And
>frankly, I am not sure why the management _systems_ are classified to
>be synchronous or asynchronous - I think we are talking about
>protocols between a management system and a device.


Aye, I didn't see that before.

First off, elsewhere in the draft the term "system" is used 7 times to
refer to the device (e.g., NC/RC server).  The term "system" is otherwise
not defined.

But to your main point, we have been discussing the terms a/synchronous to
have to do with internal server processing of an edit request, but in '3'
the terms are being used to qualify a management system, which can't be
right.  I think that '3' should be rewritten to be a statement about
devices, not a statement about management systems.



>Anyway, I am not sure 3. is properly worded until someone defines
>'transactional', 'distributed', 'synchronous management systems' and
>'asynchronous management systems'.

The agenda for tomorrow's interim!  :)


Kent

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

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

[Kent Watsen]

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

 applied configuration - this data represents the configuration
  state that the network element is actually in, i.e., the
  configuration state which is currently being being used by system
  components (e.g., control plane daemons, operating system
  kernels, line cards).

  So, is this text above acceptable, or does it need to be refined?


[hat on]

The discussion on these terms should happen on the opstate-reqs #4 thread.  
Renaming subject line to reflect that.

[hat off]

Jonathan Hansford made a suggestion to somehow clarify that the intended and 
applied configurations were limited to YANG-defined configuration data.  Maybe 
we could do this to both terms:

- this data represents the configuration...
+ YANG-defined data representing the configuration...


Also, Juergen wrote:

...we probably need to add text below the definition
of the term 'applied configuration' that acknowledges that this is
grey area and the definition of applied configuration is fuzzy here by
design.

So, perhaps something like this?

The system's ability to report applied configuration accurately may be
limited in some cases, such as when the the configuration goes through
an intermediate layer without an ability to inspect the lower layer.


Kent

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

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

[Kent Watsen]

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 are equally
interested in statements of the form:

  * I have reviewed draft-ietf-netmod-yang-metadata-02 and I found no issues
  * I have implemented the data model in draft-ietf-netmod-yang-metadata-02
  * I am implementing the data model in draft-ietf-netmod-yang-metadata-02
  * I am considering to implement the data model in 
draft-ietf-netmod-yang-metadata-02

Of course, these are merely suggestions, folks can provide comments in any
form that suits them.

This is the second Last Call for this document, the first call being last June.

Kent  // as co-chair

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

Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)

[Kent Watsen]

But don't get mw wrong, syntactically annotations would be allowed
everywhere although in some places they may be a no-op.

OK



This is also valid, see sec. 7.7.6 in RFC 6020:
snip/

I see, thanks.



True, I'd rather we can find a solution for annotating XML lists.  Until
 then, the draft SHOULD explicitly call it out as not supported.   Maybe
 put in into an OPEN ISSUES section?

But that means XML clients would be unable to receive some
information. Is it what we want?

I agree that is not what we want.  Do you have any ideas other than using
a processing instruction inside an XML comment?


Thanks,
Kent  (as a contributor)

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

Re: [netmod] Motivations for Structuring Models

[Kent Watsen]

Hi Martin,

BTW, are these interim meeting
minutes available somewhere?  This is not the first time I had to
search old emails in order to find interim minutes.

I just sent email to the WG chairs alias asking about this.  I'm proposing
that minutes for interim meetings be linked off the Minutes page too, as
they are already for conference meetings
(http://tools.ietf.org/wg/netmod/minutes)

Using the meeting manager tool I have access to, I can see a list of all
the interim meetings that were scheduled in 2014 and 2015.  And I can
drill down to find the link for the minutes that were uploaded for that
meeting.  Looking at the results (see below), I see that the minutes were
uploaded for about 1/2 of the meetings.  In some cases, this is an error
by the chairs forgetting to upload them or not knowing that they should
and, in other cases, this is because (I speculate) that the interim
meeting was cancelled and was left dangling.

For interim meetings that took place and yet missing minutes, Tom and I
will work to get them posted.  For the interim meetings that were
cancelled, I imagine we can uploaded some fake minutes that just say the
meeting was cancelled, though I'd much rather find a way to delete the
meeting entirely from the meeting manager tool's record - I'll ask around
to see if that's possible...


2015-10-12 : none linked
2015-10-05 : none linked
2015-09-28 : none linked
2015-09-21 : none linked
2015-09-14 : none linked
2015-09-07 : none linked
2015-08-31 : none linked
2015-08-24 : 
https://www.ietf.org/proceedings/interim/2015/08/24/netmod/minutes/minutes-
interim-2015-netmod-15
2015-06-25 : none linked
2015-06-18 : none linked
2015-03-12 : none linked
2015-03-05 : 
https://www.ietf.org/proceedings/interim/2015/03/04/netmod/minutes/minutes-
interim-2015-netmod-5
2015-03-04 : none linked
2015-02-22 : none linked
2015-02-18 : 
https://www.ietf.org/proceedings/interim/2015/02/18/netmod/minutes/minutes-
interim-2015-netmod-4
2015-02-04 : 
https://www.ietf.org/proceedings/interim/2015/02/04/netmod/minutes/minutes-
interim-2015-netmod-3
2015-01-21 : 
https://www.ietf.org/proceedings/interim/2015/01/21/netmod/minutes/minutes-
interim-2015-netmod-2
2015-01-15 : none linked
2015-01-08 : none linked
2015-01-07 : 
https://www.ietf.org/proceedings/interim/2015/01/07/netmod/minutes/minutes-
interim-2015-netmod-1
2014-12-17 : 
https://www.ietf.org/proceedings/interim/2014/12/17/netmod/minutes/minutes-
interim-2014-netmod-19
2014-12-11 : none linked
2014-12-04 : none linked
2014-12-03 : 
https://www.ietf.org/proceedings/interim/2014/12/03/netmod/minutes/minutes-
interim-2014-netmod-18
2014-11-19 : 
https://www.ietf.org/proceedings/interim/2014/11/19/netmod/minutes/minutes-
interim-2014-netmod-17
2014-10-22 : none linked
2014-10-15 : 
https://www.ietf.org/proceedings/interim/2014/10/15/netmod/minutes/minutes-
interim-2014-netmod-15
2014-10-08 : 
https://www.ietf.org/proceedings/interim/2014/10/08/netmod/minutes/minutes-
interim-2014-netmod-14
2014-10-01 : 
https://www.ietf.org/proceedings/interim/2014/10/01/netmod/minutes/minutes-
interim-2014-netmod-13
2014-09-24 : none linked
2014-09-17 : 
https://www.ietf.org/proceedings/interim/2014/09/17/netmod/minutes/minutes-
interim-2014-netmod-11
2014-09-10 : none linked
2014-09-03 : 
https://www.ietf.org/proceedings/interim/2014/09/03/netmod/minutes/minutes-
interim-2014-netmod-9
2014-08-27 : 
https://www.ietf.org/proceedings/interim/2014/08/27/netmod/minutes/minutes-
interim-2014-netmod-8
2014-07-16 : none linked
2014-07-09 : 
https://www.ietf.org/proceedings/interim/2014/07/09/netmod/minutes/minutes-
interim-2014-netmod-6
2014-07-02 : 
https://www.ietf.org/proceedings/interim/2014/07/02/netmod/minutes/minutes-
interim-2014-netmod-5
2014-06-25 : none linked
2014-06-18 : none linked
2014-06-11 : 
https://www.ietf.org/proceedings/interim/2014/06/11/netmod/minutes/minutes-
interim-2014-netmod-2
2014-06-04 : 
https://www.ietf.org/proceedings/interim/2014/06/04/netmod/minutes/minutes-
interim-2014-netmod-1



Kent


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

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

[Kent Watsen]

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 would really help people remember without scanning lots of
>> > ietf-announce email.
>> >
>> 
>> The official list of interim meetings is here:
>> 
>> https://www.ietf.org/meeting/interim.html
>> 
>> Yes, you have to search for NETMOD and no I am not aware of a nicer
>> list directly linked to say the NETMOD WG pages (or even a calendar
>> file).
>
>Hmm, I thought we're having a virtual interim on the opstate issue
>this thursday (2015-09-10), but it is not listed here.  Maybe I missed
>something.  Can the chairs clarify this?

There is an interim meeting planned for this Thursday the 10th on opstate.
 Tom sent a WebEx invite to the list, but didn't schedule it via the
meeting manager tool, which is why it doesn't show up in the URL above.
We hope to have this rectified shortly.

Kent


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

[netmod] posted: draft-kwatsen-netmod-opstate-00

[Kent Watsen]

For next week's interim meeting, but feel free to post comments before
then  ;)

Cheers,
Kent


On 9/2/15, 7:55 PM, "internet-dra...@ietf.org" <internet-dra...@ietf.org>
wrote:

>
>A new version of I-D, draft-kwatsen-netmod-opstate-00.txt
>has been successfully submitted by Kent Watsen and posted to the
>IETF repository.
>
>Name:  draft-kwatsen-netmod-opstate
>Revision:  00
>Title: Operational State Enhancements for YANG, NETCONF, and RESTCONF
>Document date: 2015-09-02
>Group: Individual Submission
>Pages: 12
>URL:
>https://www.ietf.org/internet-drafts/draft-kwatsen-netmod-opstate-00.txt
>Status: 
>https://datatracker.ietf.org/doc/draft-kwatsen-netmod-opstate/
>Htmlized:   
>https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-00
>
>
>Abstract:
>   This document presents enhancements to YANG, NETCONF, and RESTCONF to
>   better support the definition of and access to operational state
>   data.
>
>  
>
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>

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

[netmod] tracking new YANG language issues

[Kent Watsen]

[chair hat on, changed subject line]



On 9/1/15, 11:05 AM, "Lou Berger"  wrote:

>This is exactly the (sub) model reuse issue I was getting at in
>http://www.ietf.org/mail-archive/web/netmod/current/msg13357.html
>
>I think this new capability (i.e., the ability to define complex,
>augmentable and reusable structures that are "included" when defining
>more complex models) would be a good new issue to track.
>
>Lou


Yes, we need to start tracking new YANG language issues like this one.
How/where is the question...

First off, anything that can be implemented using a YANG language
extension should be submitted as a draft and released that way.
Everything else is essentially destined for a 6020bis-bis - agreed?

The big question, which may not even have to be answered immediately, is
if 6020bis-bis is YANG 1.2 or a 2.0.  That is, will we confine ourselves
to backwards compatibility or not.

Personally, since I don't have a sense for how much 2.0 there might be, I
think it would be interesting just to collect the YANG 2.0 ideas now.  It
would be good to see what all else is out there besides the I2RS and
OpenConfig stuff we already know about.

Thoughts? - how should we proceed?  - use GitHub issue tracker?

Kent



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

[netmod] FW: NomCom 2015: Call for nominations

[Kent Watsen]

All,

Please see below the Call for Nominations from NomCom 2015. Please help
NomCom and the IETF community by proposing the best candidates for the
open positions. This is important for the IETF and the industry.

Thanks!
Kent




On 9/8/15, 3:11 AM, "Benoit Claise"  wrote:

>Dear OPS chairs,
>
>Please make sure your WG/community is aware of (the importance of) this
>message.
>
>Regards, Benoit
>
> Forwarded Message 
>Subject:   NomCom 2015: Call for nominations
>Date:  Wed, 26 Aug 2015 03:13:13 -0700
>From:  NomCom Chair 2015 
>Reply-To:  i...@ietf.org, nomco...@ietf.org
>To:IETF Announcement List 
>CC:i...@ietf.org
>
>
>
>The 2015-16 Nominating Committee (Nomcom) is seeking nominations from
>now until October 8, 2015. The open positions being considered by this
>year's Nomcom can be found at the end of this email and also on this
>year's Nomcom website:
>
>https://datatracker.ietf.org/nomcom/2015/
>
>Nominations may be made by selecting the Nominate link at the top of
>the Nomcom 2015 home page, or by visiting the following URL:
>
>https://datatracker.ietf.org/nomcom/2015/nominate/
>
>   {Note that nominations made using the web tool require an ietf.org
>datatracker account. You can create a datatracker ietf.org account
>if you don't have one already by visiting the following URL:
>https://datatracker.ietf.org/accounts/create/  }
>
>If you are unable to use the web form, nominations may instead be made
>by email tonomco...@ietf.org. If using email, please include the word
>"Nominate" in the Subject and indicate in the email who is being
>nominated, their email address (to confirm acceptance of the
>nomination), and the position for which you are making the nomination.
>If you are nominating someone other than yourself, please tell us if
>we may tell the nominee that you were the one who made the nomination.
>If you wish to nominate someone via email for more than one position,
>please use separate emails to do so.
>
>Self-nomination is welcome!
>
>NomCom 2015-16 will follow the policy for "Open Disclosure of Willing
>Nominees" described in BCP 10/RFC 7437.  As stated in RFC 7437: "The
>list of nominees willing to be considered for positions under review
>in the current Nomcom cycle is not confidential". Willing nominees for
>each position will be listed in a publicly accessible way - anyone
>with a datatracker account may access the lists.  Additionally, the
>nomination form asks if we may share your own name with the
>nominee. In all other ways, the confidentiality requirements of BCP10
>remain in effect.  All feedback and all Nomcom deliberations will
>remain confidential and will not be disclosed.
>
>There is a field on the form you can mark in order to allow the Nomcom
>to tell the nominee that you were the one who made the
>nomination. This is a new thing this year, and it defaults to ³no² -
>we won¹t tell. After the nomination cycle, we will evaluate the result
>of this and recommend whether the next Nomcom should do something
>different.
>
>In order to ensure time to collect sufficient community feedback about
>each of the willing nominees, nominations must be received by the
>Nomcom on or before October 8, 2015.
>
>Please submit your nominations as early as possible for the sake of
>your nominees. Note that nominations should not wait for management
>permission, as it is easier to decline the nomination than put one in
>late.  We have set the questionnaire submission deadline for October
>15, 2015.
>
>The Nomcom appoints individuals to fill the open slots on the IAOC,
>the IAB, and the IESG. The list of people and posts whose terms end
>with the March 2016 IETF meeting, and thus the positions for which
>this Nomcom is responsible, follows:
>
>IAB:
>* Mary Barnes
>* Joe Hildebrand
>* Ted Hardie
>* Erik Nordmark
>* Brian Trammell
>* Mark Blanchet
>
>IESG:
>- Alissa Cooper, ART
>- Barry Leiba, ART
>- Brian Haberman, Internet (*)
>- Benoit Claise, O
>- Alia Atlas, Routing
>- Kathleen Moriarty, Security
>- Martin Stiemerling, Transport (*)
>
>*- have indicated that they do not intend to accept a
>renomination. This information is always up to date on
>https://datatracker.ietf.org/nomcom/2015/
>
>Please be resourceful in identifying possible candidates for these
>positions, as developing our talent is a very crucial requirement for
>the IETF, and also, please consider accepting a nomination.  You'll
>find extensive information about specific positions, developed by the
>IAB, IESG, and IAOC, under individual tabs at:
>
>   https://datatracker.ietf.org/nomcom/2015/requirements/
>
>In addition to nominations, the Nomcom seeks community input on the
>positions themselves.  We need and welcome the community's views and
>input on the jobs within each organization. If you have ideas on the
>positions' responsibilities (more, less, different), please let us
>know.
>
>Please send suggestions and 

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

[Kent Watsen]

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 the WG for final on-list
consensus.   


Kent

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

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

[Kent Watsen]

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 focus on refining this list during the
>meeting.
>
>
>1. Ability to interact with both intended and applied configuration
>
>   a. The ability to ask the operational components of a system
>   (e.g., line cards) for the configuration that they are currently
>   using. This is the "applied configuration".
>
>   b. applied configuration is read-only
>
>   c. The data model for the applied configuration is the same as
>   the data model for the intended configuration (same leaves)
>
>   d. For asynchronous systems, when fully synchronized, the data
>   in the applied configuration is the same as the data for the
>   intended configuration.
>
>
>2. Applied configuration as part of operational state
>
>a. the ability to retrieve the applied configuration and
>derived state nodes in a single protocol operation.
>
>
>3. Support for both transactional, synchronous management
>   systems as well as distributed, asynchronous management
>   systems
>
>a. For asynchronous systems, the ability to request a protocol
>operation to not return (i.e. block) until the intended
>configuration has been fully synchronized.
>
>b. The protocol operation's response would indicate the result
> of the operation (success, failure, partial, etc.)
>
>
>4. Separation of configuration and operational state data; ability
>   to retrieve them independently
>
>a. be able to retrieve only the derived aspects of operational state
>
>b. be able to retrieve only the non-derived aspects of operational
>state
>
>
>5. Ability to retrieve operational state corresponding only to
>   derived values, statistics, etc.
>
>// this is a duplicate of # 3-a
>
>
>6. Ability to relate configuration with its corresponding operational
>state
>
>a. ability to map intended config nodes to corresponding applied
>config nodes
>b. ability to map intended config nodes to associated derived state
>nodes
>c. The mappings needs to be programmatically consumable
>
>
>7. Ability for distinct modules to leverage a common model-structure
>
>  a. Scope is limited to IETF-defiend modules
>  b. multiple domain-specific trees are okay
>  c. multiple namespaces are okay
>
>
>
>
>Thanks,
>Kent
>
>
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

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

[Kent Watsen]

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?   Is it an "inability" to address them, or just that 
they don't address them currently?

Thanks,
Kent


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

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

[Kent Watsen]

The AD and chairs thought it best to formalize the consensus on the
requirements a bit more.  So we created the I-D listed below to track and
capture final consensus.

Additionally, we want to use this GitHub issue tracker to track issues:

https://github.com/netmod-wg/opstate-reqs/issues

Consistent with Tom's earlier email, we want to collect any issues with
these requirements before EOB Monday, September 14, 2015 at 5PM EST.  If
you have an issue, in addition to posting it to the list, please consider
adding it to the GitHub tracker, and let people know you did so.   Our
goal is to close the issues as quickly as possible, some will go to DEAD
while others may remain OPEN, based on WG consensus.

Thanks,
Kent & Tom


On 9/11/15, 5:36 PM, "internet-dra...@ietf.org" <internet-dra...@ietf.org>
wrote:

>
>A new version of I-D, draft-chairs-netmod-opstate-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: Individual Submission
>Pages: 5
>URL:
>https://www.ietf.org/internet-drafts/draft-chairs-netmod-opstate-reqs-00.t
>xt
>Status: 
>https://datatracker.ietf.org/doc/draft-chairs-netmod-opstate-reqs/
>Htmlized:   
>https://tools.ietf.org/html/draft-chairs-netmod-opstate-reqs-00
>
>
>Abstract:
>   This document captures consensus on operational state requirements by
>   the NETMOD working group.
>
>  
>
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>

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

Re: [netmod] Consensus Call Note for Requirements

[Kent Watsen]

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

>
>
>On 9/11/2015 8:09 AM, Nadeau Thomas wrote:
 3. Support for both transactional, synchronous management
 >>   systems as well as distributed, asynchronous management
 >>   systems
 >> 
 >>a. For asynchronous systems, the ability to request a protocol
 >>operation to not return (i.e. block) until the intended
 >>configuration has been fully synchronized.
>>> > I'm not sure why 3 (a) is a requirement, or its unclear to me where
>>>this is specified in the openconfig-netmod-opstate draft.
>>  Anees/Rob, can you guys please add some color to the above
>>descriptions to help clarify things for Robert?
>I see (3) but not (3.a) in
>http://tools.ietf.org/html/draft-openconfig-netmod-opstate-01#section-4.2
>so am unsure how 3.a made it on the list.
>
>also, I don't object to 3.a if *users* say they need it.
>
>Lou
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

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

[Kent Watsen]

In case folks missed it, Appendix A (pasted below for convenience) roughly
describes where each requirement came from.  As it says, some liberty was
taken to adjust the text based on what looked liked consensus from on list
discussions; this is why they're not 1-1.  Regardless if our
interpretation is accurate, we will iterate this draft to consensus
(closing GitHub issues).


   Appendix A.  Relation to Requirements in Other Drafts

   The requirements in this document roughly map onto the requirements
   listed in [draft-openconfig-netmod-opstate-01] and
   [draft-openconfig-netmod-model-structure-00] as list below.  Some
   liberty was taken to adjust the requirements based on what looked
   liked consensus from on list discussions:

   1.  draft-openconfig-netmod-opstate-01, Section 3
   2.  draft-openconfig-netmod-opstate-01, Section 4.1
   3.  draft-openconfig-netmod-opstate-01, 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" <kwat...@juniper.net> wrote:

>
>The AD and chairs thought it best to formalize the consensus on the
>requirements a bit more.  So we created the I-D listed below to track and
>capture final consensus.
>
>Additionally, we want to use this GitHub issue tracker to track issues:
>
>   https://github.com/netmod-wg/opstate-reqs/issues
>
>Consistent with Tom's earlier email, we want to collect any issues with
>these requirements before EOB Monday, September 14, 2015 at 5PM EST.  If
>you have an issue, in addition to posting it to the list, please consider
>adding it to the GitHub tracker, and let people know you did so.   Our
>goal is to close the issues as quickly as possible, some will go to DEAD
>while others may remain OPEN, based on WG consensus.
>
>Thanks,
>Kent & Tom
>
>
>On 9/11/15, 5:36 PM, "internet-dra...@ietf.org" <internet-dra...@ietf.org>
>wrote:
>
>>
>>A new version of I-D, draft-chairs-netmod-opstate-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:Individual Submission
>>Pages:5
>>URL:
>>https://www.ietf.org/internet-drafts/draft-chairs-netmod-opstate-reqs-00.
>>t
>>xt
>>Status: 
>>https://datatracker.ietf.org/doc/draft-chairs-netmod-opstate-reqs/
>>Htmlized:   
>>https://tools.ietf.org/html/draft-chairs-netmod-opstate-reqs-00
>>
>>
>>Abstract:
>>   This document captures consensus on operational state requirements by
>>   the NETMOD working group.
>>
>> 
>>
>>
>>
>>Please note that it may take a couple of minutes from the time of
>>submission
>>until the htmlized version and diff are available at tools.ietf.org.
>>
>>The IETF Secretariat
>>
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

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

[Kent Watsen]

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: Andy Bierman <a...@yumaworks.com<mailto:a...@yumaworks.com>>, Juergen 
Schoenwaelder 
<j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>>,
 Mahesh Jethanandani <mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: 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.

draft-kwatsen-netmod-opstate-reqs Sections 5.2 and 6.1. define an
Applied Configuration capability so the client to tell, doesn't this count?

> Andy

Kent



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

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

[Kent Watsen]

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 6B also
>> required?
>> Do we need to make the link between a config node and all the derived
>> counters/statistics it influences, which might be in different YANG
>> models btw?
>
>Yes - we need to deterministically retrieve, for a particular
>configuration object (e.g., interface, BGP peer) the set set of derived
>state nodes associated with it, such that we do not need to maintain
>complex mapping tables on the client side for this - and can efficiently
>query the server for them.
>
>For instance, knowing that we configured a BGP peer at
>$SOMEROOT/bgp/neighbors/neighbor[peer-address=Œ192.0.2.1¹]/config/{leaf-se
>t} then we would find the counters at
>$SOMEROOT/bgp/neighbors/neighbor[peer-address=Œ192.0.2.1¹]/state/ -
>allows us to (based on the fact that we just configured a peer) retrieve
>the state and counters that a client application will likely want to
>check without having to map to some other (set of locations).
>
>Note that in previous discussions, it was expressed that this implied
>that the model had knowledge of how the protocol operates such that it
>was known that leaf A corresponding to some other derived-state leaf B.
>However, this isn¹t true. As I expressed before, the intention is that it
>is possible for a NMS layer to easily retrieve the set of state objects
>that an interested client may require, without many disparate queries,
>based on the configuration path. The actual meaning may be completely
>unknown to this layer.
>
>The openconfig-opstate approach allows state and config to be defined in
>separate modules - since the Œstate¹ module in this case can simply
>augment the relevant Œstate¹ containers within the config model.
>
>Regards,
>r.

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

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

[Kent Watsen]

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

draft-kwatsen-netmod-opstate-reqs Sections 5.2 and 6.1. define an
Applied Configuration capability so the client to tell, doesn't this count?

> Andy

Kent



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

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

[Kent Watsen]

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 
ready to close this issue yet.

Thanks,
Kent


From: Thomas Nadeau >
Date: Tuesday, September 29, 2015 at 10:56 AM
To: Robert Wilton >
Cc: "netmod@ietf.org" 
>
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous vs 
asynchronous (esp. wrt intended and applied)


Robert,

It seems this discussion has run out of steam and we've come to a head on this 
issue.
It seems we have some actions we can take based on the list of three bullets 
below as part of
that conclusion (potentially).

Do folks think we are ready to close this issue down officially?

-Tom


On Sep 29, 2015:10:47 AM, at 10:47 AM, Robert Wilton 
> wrote:



On 28/09/2015 18:17, Andy Bierman wrote:


On Mon, Sep 28, 2015 at 10:10 AM, Robert Wilton 
> wrote:
Hi Andy,


On 24/09/2015 19:22, Andy Bierman wrote:
Hi,

I find this exercise to classify servers as synchronous or asynchronous mostly 
useless.
We have both types of instrumentation in our server. They can be different
on a per-node basis.  They can both take a long time or both be instant, 
depending
on the instrumentation code the vendor writes.

In any case, the server does not know if the instrumentation has finished making
the network behave according to the new edit.  That would be new functionality 
that
no vendor supports at this time.  Currently servers return "ok" if the edit is 
accepted
into the running datastore.  There are no other semantics wrt/ returning "ok".

I'm not sure whether we agree here, but as stated previously, Sec 5.1 of RFC 
6241, implies that if the configuration is in the running datastore then that 
configuration is expected to be active on the device.


I do not agree at all that the running datastore means anything other
than the intended confg.   A new operation is needed to retrieve
the active config vs. the intended config.

If the running datastore only ever means intended config, then I think that 
would imply:

 - existing NETCONF servers should reply immediately after the config has been 
semantically verified + written to the config subsystem before the 
configuration is applied.

 - existing NETCONF servers are logically classified (as per 
openconfig-netmod-opstate) as being asynchronous w.r.t to the config requests.

 - the existing NETCONF/RESTCONF protocols has no direct mechanism for 
indicating a failure to apply any configuration leaf, the only way such 
information could be deduced is through related operational state leaves or 
notifications.

Rob

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

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

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

[Kent Watsen]

[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 define them relative to the configuration operations 
being performed.

[KENT] Perhaps these could be collapsed if we use the terms "a/synchronous 
server" ?


Synchronous configuration operation - A configuration request that the server 
applies synchronously with respect to the client request.  Before the server 
replies back to the client indicating the success or failure of the operation 
it MUST semantically validate the contents of the request and update the 
intended configuration of the target datastore.  If the request is to the 
running datastore then the configuration change MUST also be applied in the 
system before the server replies back to the client.  The reply to the client 
indicates whether there are any semantic errors or system errors from applying 
the configuration change.


[KENT]  This generally matches my understanding, but here are some thoughts to 
improve it:

1. I think the language "semantically validate" would exclude an ephemeral 
datastore.  We could put a qualifier on it, but I think it can be removed 
entirely as each datastore already has its own semantics around how it 
processes update requests.

2. I like how you call out the running datastore, but it is somewhat 
NETCONF-specific.  How about something like "If the request impacts the 
intended configuration (see term), then..."

3. "applied in the system" seems too open ended, how about this:  "...MUST also 
be propagated to and processed by the operational components of the server 
before..." ???



Asynchronous configuration operation - A configuration request that the server 
applies asynchronously with respect to the client request.  Before the server 
replies back to the client indicating the success or failure of the operation 
it MUST semantically validate the contents of the request and update the 
intended configuration of the target datastore.  If the request is to the 
running datastore then the configuration change is applied to the system after 
the server has replied back to the client.  The reply to the client only 
indicates whether there are any semantic errors in the configuration change.

[KENT] For the most part, my comments on this are the mirror image of the 
comments made above.   One additional comment though, when reading in the first 
sentence "with respect to the client" I was thinking that these terms are 
actually independent of the protocol.  For instance, they could equally well be 
defined for a system that only had CLI access.  So, in that sense, the word 
"client" in the first sentence, and client/server elsewhere generally, may be 
ground for some confusion.


Synchronous system - NETCONF/RESTCONF client/server interactions that processes 
all configuration operations as synchronous configuration operations.

Asynchronous system - NETCONF/RESTCONF client/server interactions that 
processes all configuration operations as asynchronous configuration operations.

[KENT] again, maybe we can collapse the number of terms from 4 to 2 by calling 
these "a/synchronous server" - what do you think?


Thanks again,
Kent



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

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

[Kent Watsen]

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 state that the
  network element is actually in, i.e., that which is currently
  being run by particular software modules (e.g., the BGP daemon),
  or other systems within the device (e.g., a secondary control-
  plane, or line card).

But, as Robert states in the issue:

The definition of "applied configuration" is slightly vague, and there
seems to be multiple interpretations of it on the WG alias, and
hence a tighter specification of it would be useful.

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 configuration?
  - how does it relate to the state of the system after a equivalent 
synchronous config commit (if at all)?


Already Mahesh and Einar have posted comments on the GitHub issue tracker.   
Please first read the comments posted there and then continue the discussion 
here on the mailing list (not on the GitHub issue tracker).

PS: This issue is highly related to issue #5, which was also just opened for 
discussion on the mailing list.

Thanks,
Kent

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

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

[Kent Watsen]

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 it
> acceptable for any templating solution to have to adhere to that constraint 
> above.

Specifically, would this imply that the flattening of the template would have 
to now take place at each operational component in the system – as opposed to 
being flattened by a centralized component (e.g., in the control plane).   If 
so, then I think it might add significant costs to the servers, as then *all* 
downstream components would have to know how to flatten templates.

Related to this, how do we handle the case where the downstream component's 
native data model is different.  For instance, imagine a mixed IP/optical 
router that has subtended ROADM and optical amplifiers attached.  So, when the 
control plane sends the config to the ROADM, it first converts it to the 
ROADM's native data model.  For this case, in order to present the applied 
config with the same data model, would the control plane have to perform the 
reverse mapping?


Kent   // as a contributor




From: Andy Bierman >
Date: Saturday, October 3, 2015 at 11:38 AM
To: Robert Wilton >
Cc: Randy Presuhn 
>, 
"netmod@ietf.org" 
>
Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully 
synchronized" in "Requirement 1.D"

Hi,

So the applied leaf is being used as a complicated boolean?

IMO your draft (using attributes similar to with-defaults=report-all-tagged,
not containers) is the best compromise because:

   - the data models are not touched
   - no datastores are required
   - the same string is used to identify the data node no matter what
 state needs to be checked
   - client has to request the metadata somehow so no impact
 on clients that do not care about this issue
   - a single boolean attribute applied="true" is all that is really needed



Andy



On Fri, Oct 2, 2015 at 1:16 PM, Robert Wilton 
> wrote:
Hi Andy,

It was clarified by Rob Shakir in the meeting that the applied-cfg leaf is only 
used to indicate whether the configuration represented by the intended-cfg leaf 
has been applied.

But it appears that my proposed text for 1D may have caused some confusion.  
Please see inline ...

On 02/10/2015 19:11, Andy Bierman wrote:
Hi,

What about the data models that do not follow 1D?

  - 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 it 
acceptable for any templating solution to have to adhere to that constraint 
above.


  - 'auto-duplex' corner-case: the intended and applied leaf are the same, but 
they
will never have the same value
The intention is:
  - intended-cfg duplex leaf = "auto" (i.e. operator wants duplex to be 
determined by auto-negotiation)
  - applied-cfg duplex leaf = "auto" (i.e. device will determine duplex by 
auto-negotiation)
  - related derived-state duplex-state leaf = "full" or "half" or "unknown" 
(always represents the actual duplex setting of the interface)

  - 'use-dhcp' corner-case: intended config just enables specific derived state
 to be used; disjoint data models
Similarly:
  - intended-cfg use-dhcp leaf = "true" (i.e. operator wants DHCP assigned IP 
addresses)
  - applied-cfg use-dhcp leaf = "true" (i.e. system is using DHCP to assign IP 
addresses)
  - related derived-state IP address leaf = A.B.C.D (Primary IP address in use 
for the interface - if any).



Somebody asked an important question at the interim:
Is the intent of this group to limit all YANG data models such that
they conform to 1D? (IMO that is a non-starter)
It is not my intention that my proposed 1D text makes are constraint on the 
structure of YANG data models.


IMO requirement 1D presume that the solution involves separate
objects in the YANG data model for intended and applied states,
and therefore it is an invalid requirement.

That is not the intention of my phrasing, perhaps it needs further refinement?

The intention is that a config node has two notional states in the data store, 
intended and applied.  The aim is to tightly relate those two notional states 
as to when they are allowed to be the same or different.


Only the 2 protocol-based solutions address this issue by using
the same object identifier no matter which state is being queried.
I don't think that this requirement excludes any of the three solutions that 
have been proposed (or the use of attribute to return intended vs applied state 
metadata).

Thanks,
Rob

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

[Kent Watsen]

> 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 from the control plane's perspective, but not necessarily 
operationally active.  Does this require errata?


Popping the stack on this issue, the issue remains as to what to do with 
requirement 3:

   3.  Support for both transactional, synchronous management systems
as well as distributed, asynchronous management systems

   A.  For asynchronous systems, the ability to request a protocol
   operation to not return (i.e. block) until the intended
   configuration has been fully synchronized.

   B.  The protocol operation's response would indicate the result
   of the operation (success, failure, partial, etc.)


Again, my position is that sub-requirements A and B are not actual requirements 
in the sense that we're being asked to add to NETCONF/RESTCONF (the only 
protocols supported currently) an ability to block protocol operations until 
the intended configuration is fully propagated to the operational components of 
a system.  So I think that 3A and 3B should be removed.

But the top-level statement in 3 remains valid, and yet it now seems like a 
duplicate to the requirement #1.  That is, a synchronous system presumably has 
no "applied" configuration whereas an asynchronous does.  So it seems that 
satisfying this requirements is one and the same as satisfying the desire for a 
system to advertise (or not) support for an "applied" configuration.  Agreed?

If this is agreed, then we can close this issue by replacing A and B with a 
note indicating that requirement #3 is a duplicate of #1.

Thanks,
Kent





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

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

[Kent Watsen]

> 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 NETCONF/RESTCONF make no assertions with regard to the 
applied configuration when the RPC-reply or HTTP response is provided.   In my 
experience, only the control plane is updated and sometime later the changes 
are propagated to dataplane. 

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

[netmod] closing issues on opstate-reqs

[Kent Watsen]

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:

https://github.com/netmod-wg/opstate-reqs/blob/master/README.md#issue-tracking


Immediately I plan to start a thread to track some of these issues to closure.  
I will start with an easy issue so we can see how it goes.

Thanks,
Kent

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

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

[Kent Watsen]

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 distinct modules to leverage a common model-structure
   A.  Scope is limited to IETF-defined modules
   B.  Multiple domain-specific trees are okay
   C.  Multiple namespaces are okay



Background:

  I pulled 7A from Andy's message here:


https://mailarchive.ietf.org/arch/msg/netmod/I6clHE2665C40taRZHi0CKLD46U

  and put a stake in the ground so that, if nothing else, it could
  be discussed...and here we are!

  FWIW, I wrote 7A this way because I didn't see how it can be
  enforced outside of the IETF.  But maybe that doesn't matter?
  Of course, we can have 6087bis guidance for other SDOs, but
  I didn't put that in the text.


Thoughts on how the text should be updated?


PS: Please Reply-All to the list rather than post comments to the GitHub
issue tracker.


Thanks,
Kent

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

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

[Kent Watsen]

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 reports, we are equally
interested in statements of the form:

  "I have reviewed I-D XYZ and I found no issues"
  "I have implemented the data model in I-D XYZ"
  "I am implementing the data model in I-D XYZ"
  "I am considering to implement the data model in I-D XYZ"

This is the second Last Call for this document.

Thanks,
Kent


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

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

[Kent Watsen]

[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 backwards compatible, such that implementations 
would only opt-in when needed - a pay as you grow strategy.   But herein 
perhaps lies an unstated requirement, that the impact to YANG/NETCONF/RESTCONF 
needs to be backwards compatible with respect to existing deployments.  Did we 
miss it or is it too obvious?

I agree that supporting these requirements will be unnecessary for many 
platforms.  After all, we’ve gone decades without needing such visibility, and 
that’s not going to change for many platforms for some time, if ever.

You ask for objective metrics for determining solution applicability.  My 
thinking is to just let the market decide - is it not good enough?   If I tried 
to quantify it, I might say that its only useful for networking devices (as 
their operational state somehow matters more?) and that it’s only useful when 
there is no guarantee that the intended config will become operational (i.e. 
applied) in some bounded amount of time.   Just throwing out ideas here, but I 
like best letting the market decide.

Kent


From: netmod > on 
behalf of Andy Bierman >
Date: Wednesday, December 16, 2015 at 7:21 PM
To: Thomas Nadeau >
Cc: "netmod-cha...@tools.ietf.org" 
>, 
"netmod@ietf.org" 
>
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

Hi,

I have asked repeatedly for some indication of scope in these requirements.
There is an assumption all possible YANG-based platforms have intended
and applied state that can be different for a long enough interval such that 
retrieving
the differences is operationally useful.

For devices that converge in milli-seconds or even as long as 5 seconds,
I do not see the point of implementing solutions for these requirements.
I would prefer that this draft specify some sort of objective
metric for determining the solution applicability.


Andy


On Wed, Dec 16, 2015 at 4:10 PM, Nadeau Thomas 
> wrote:

This is a WG Last Call on draft-ietf-netmod-opstate-reqs-01.
Please post comments on this draft by Wednesday, December 30, 2015
at 9AM EST.

Tom/Kent


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

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

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

[Kent Watsen]

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 Thomas wrote:
>> This mail starts the IPR poll on draft-ietf-netmod-opstate-reqs-01.
>>
>> Are you aware of any IPR that applies to draft-ietf-netmod-opstate-reqs-01?
>> 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 author or contributor please respond to this
>> email explicitly regardless of whether or not you are aware of any relevant 
>> IPR.
>> The response needs to be sent to the NETMOD WG mailing list.  The document
>> will not advance to the next stage until a response has been received from 
>> each
>> author and contributor.
>>
>> If you are on the NETMOD WG email list but are not listed as an author or
>> contributor, then please explicitly respond only if you are aware of any IPR 
>> that
>> has not yet been disclosed in conformance with IETF rules.
>>
>> Thank you,
>>
>> Kent and Tom, NETMOD WG Chairs
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> .
>>
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

>>>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, such that 
>>>implementations would only opt-in when needed - a pay as you grow strategy.  
>>> But herein perhaps lies an unstated requirement, that the impact to 
>>>YANG/NETCONF/RESTCONF needs to be backwards compatible with respect to 
>>>existing deployments.  Did we miss it or is it too obvious?
>>> 
>> 
>> It may be obvious for many of us but for the sake of completeness I
>> prefer to have this backwards compatibility assumption explicitely
>> stated.
>
>+1


[as a chair]

As last call comment, there seems to be support for adding a requirement to the 
opstate-reqs draft to state that solutions supporting said requirements MUST be 
backwards compatible with respect to existing deployments.  Do we have WG 
consensus to add this as a requirement to this draft?  Are there any 
objections? Please voice your opinion before the last call cutoff date (Dec 30).


[as a contributor]


I’m unsure if it makes sense to call it out in this draft, in that it seems 
universally applicable, but I don’t see any harm in it either and thus do not 
object.


Kent

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

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

[Kent Watsen]

[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, the relating of config to 
derived state and also the model structure requirement are not related to 
applied config.  In all fairness, Requirement #5 (model structure) isn’t even 
about operational state.  So your title and abstract suggestions might define 
too narrow a scope.  So how about:

Title: Terminology and Requirements for Operational State and Model Structure
Abstract:
 This document defines requirements for enhancing the support
 of operational state through the introduction of a conceptual
 "applied configuration".  The document also defines requirements
 enabling distinct modules to leverage a common model structure.



…and add an Introduction section that expands on this theme further?

Thanks again,
Kent





On 12/17/15, 1:16 PM, "netmod on behalf of Juergen Schoenwaelder" 
 
wrote:

>Hi,
>
>reviewing as technical contributor
>
>a) Title:
>
> NETMOD Operational State Requirements
>
>   I do not think having a WG name in the title is useful in the
>   long-term. WGs come and go, technology stays. But likely more
>   important, is the document really about 'operational state
>   requirements'?  My understanding is that the document is primarily
>   about the separation of intended config and applied config and not
>   operational state requirements in general. Let me make a
>   constructive proposal you can throw darts at...
>
> Separation of Intended Configuration from Applied Configuration:
> Terminology and Requirements
>
>b) Abstract:
>
> This document defines requirements for servers enabling better
> visibility and control over the server's operational state.
>
>   Do the requirements apply to _all_ servers? You later define server
>   = device = system = network element but I think it is desirable if
>   the abstract stands on its own. And, as stated above already, I
>   think the document is not really about "enabling better visibility
>   and control over the server's operational state" - it is primarily
>   about the separation of Intended Configuration from Applied
>   Configuration. Let me again try to make a constructive proposal:
>
> This document discusses the difference between intended
> configuration and applied configuration of a device and how
> intended and applied configuration relate to the operational
> state of a device. The document defines the necessary terminology
> and identifies requirements enabling visibility into the
> difference of intended configuration and applied configuration.
>
>c) The document does not have an Introduction. I am personally OK with
>   that but most RFCs do have an Introduction section. Well, the
>   Gen-ART reviewers will tell us I guess.
>
>d) I note that there is no reference to RFC 6244. For me, it seems
>   Intended Configuration maps to the box 'config database' in the
>   figure on page 15 of RFC 6244 and Applied Configuration is part of
>   the box marked 'system software component' in RFC 6244. If this is
>   correct, perhaps it is useful to spell this out. If this is
>   incorrect, it is likely useful to spell this out as well. While RFC
>   6244 might have its limitations, it is the only architectural
>   document we have in the NETCONF and YANG space and we should
>   perhaps not ignore it.
>
>e) Title of Appendix A
>
>   This should probably be 'in Other Documents" instead of in Other
>   Drafts" since RFC 6241 is not really a "Draft".
>
>f) Editorial: It would be nice to write terms such as
>   continue-on-error always in the same way - makes searching in the
>   document easier (I think I have seen Continue On Error, continue on
>   error, and continue-on-error).  Same for stop-on-error and
>   rollback-on-error. Or be explicit that continue-on-error means
>   RFC6241 continue-on-error and Continue On Error means this
>   document's continue on error.
>
>g) Appendix A:
>
> The following terms were originally defined in [RFC6241], but since
> modified by the NETMOD WG:
>
> o  continue-on-error
> o  stop-on-error
> o  rollback-on-error
>
>  Instead of noting the fact that terms are different, it might be
>  more useful to _explain_ what the difference is between the terms
>  defined in RFC 6241 the terms defined in this document. Are the
>  terms defined here just a generalization to make the definition less
>  protocol specific or is there also a semantic change beyond that?
>  Perhaps also make it clear that the definitions provided here do not
>  change the semantics of the terms defined in RFC 6241 (otherwise
>  this document would have to formally update RFC 6241).
>

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

[Kent Watsen]

[As a contributor]


This update reflects the four on-list email threads since -00 was published as 
follows:


1. Regarding Balazs, Gert, and Robert’s thread here: 
https://www.ietf.org/mail-archive/web/netmod/current/msg14243.html

The term “non-derived” state in Req #4 has been removed and new term 
“Operational State” has been added.  The new requirement #3 is a little 
different than what’s in draft-openconfig-netmod-opstate, but I believe that it 
is what’s intended (no pun intended, doh!).  No change made clarifying long 
running operations like backup, as this requirements draft, when referring to 
“asynchronous", regards configuration operations.   Also no change made to add 
a new requirement for a YANG annotation for config nodes that are known to have 
potentially different intented-config value.

Git diffs: 
https://github.com/netmod-wg/opstate-reqs/commit/6bc82d24e35337cb2229fb6338f21af2bf106647
https://github.com/netmod-wg/opstate-reqs/commit/3dabc4fa905c4d3037f808dbc8f18584d3e613d5



2. Regarding Jason and Gert’s thread here: 
https://www.ietf.org/mail-archive/web/netmod/current/msg14342.html

I have not done anything about this yet, but it seems that something might need 
to be done.  Personally, I don’t see how Rollback on Error could be allowed to 
rollback the intended config set via an asynchronous commit (e.g., after  
has been sent).  My thinking is that the server should send  if the 
client requests that combination.  FWIW, I’m not troubled by 'hybrid' or 
cheating-synchronous implementations, as in my view, they don’t advertise 
support for applied configurations or for synchronous commits.



3. Regarding Jason and Randy’s thread here: 
https://www.ietf.org/mail-archive/web/netmod/current/msg14344.html

The old 2-A was removed since it’s a duplicate to 4-C, and then the old 2 was 
removed since it’s covered in the new Operational State term.  The old #5 was 
also removed to eliminate cruft from the draft.  Then I fixed Appendix B to 
point to new section numbers.

Git diffs: 
https://github.com/netmod-wg/opstate-reqs/commit/02ef5fedd4293024dab70514884e9661b9c86285
https://github.com/netmod-wg/opstate-reqs/commit/4a06744157dada4707a457ec06a17b048719ae0b
  



4. Regarding Jason and Gert’s thread here: 
https://www.ietf.org/mail-archive/web/netmod/current/msg14343.html

No changes made here because I don’t think this hybrid case needs to be 
defined.   In my view, a device either advertises support for synch or asynch 
or both or none (default).  For the first three cases, the behavior is 
explicitly defined.  For the last case, the behavior remains same as today 
(undefined), which is needed for backwards compatibility.



Thanks,
Kent








On 12/15/15, 4:47 PM, "netmod on behalf of internet-dra...@ietf.org" 
<netmod-boun...@ietf.org on behalf of internet-dra...@ietf.org> wrote:

>
>A New Internet-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   : NETMOD Operational State Requirements
>Authors : Kent Watsen
>  Thomas Nadeau
>   Filename: draft-ietf-netmod-opstate-reqs-01.txt
>   Pages   : 8
>   Date: 2015-12-15
>
>Abstract:
>   This document defines requirements for servers enabling better
>   visibility and control over the server's operational state.  To
>   achieve this end, this document also defines terminology describing a
>   conceptual model enabling the requirements to be expressed.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/
>
>There's also a htmlized version available at:
>https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-01
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-opstate-reqs-01
>
>
>Please note that it may take a couple of minutes from the time of submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

This update addresses comments received during the Last Call.

Warning!  - the Diff1 and Diff2 outputs somehow mangle the Applied 
Configuration term.  Please look at the draft itself for the correct text.

Kent



On 1/4/16, 5:17 PM, "netmod on behalf of internet-dra...@ietf.org" 
<netmod-boun...@ietf.org on behalf of internet-dra...@ietf.org> wrote:

>
>A New Internet-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 
> Operational State Visibility and Control
>Authors : Kent Watsen
>  Thomas Nadeau
>   Filename: draft-ietf-netmod-opstate-reqs-02.txt
>   Pages   : 6
>   Date: 2016-01-04
>
>Abstract:
>   This document discusses the difference between intended configuration
>   and applied configuration of a device and how intended and applied
>   configuration relate to the operational state of a device.  The
>   document defines the necessary terminology and identifies
>   requirements enabling visibility into the difference of intended
>   configuration and applied configuration.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/
>
>There's also a htmlized version available at:
>https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-02
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-opstate-reqs-02
>
>
>Please note that it may take a couple of minutes from the time of submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

It’s true that the draft is largely centered around the intended/applied config 
notion, but not exclusively.  Specifically, 4-B has "Ability to map intended 
config nodes to associated derived state nodes".  I think that this might be 
the only exclusion though and, if it weren’t for it I would’ve used your title 
suggestion from the LC review.   Should one requirement have such influence 
over the title is the question.  I was trying to be fair to it, but maybe it's 
going too far.

Regarding visibility and control, I was attempting to use common words (not 
normative terms) here.  My intent for them is something along the lines of:

visibility: read/understand
control: write/orchestrate

Thanks,


Kent


On 1/6/16, 1:30 AM, "Juergen Schoenwaelder" 
<j.schoenwael...@jacobs-university.de> wrote:

>Acee,
>
>for me the document is centered around the notion of intended /
>applied config:
>
>#1 is clearly about intended/applied cfg
>
>#2 is about intended/applied cfg (since sync config operations is
>   largely defined using intended/applied cfg)
>
>#3 is about the relationship of applied config and derived state
>
>#4 is about the relationship of intended / applied config and
>   operational state
>
>I find "Enhanced Operational State Visibility and Control" abstract
>and somewhat confusing (what is visibility? what is control?).
>
>/js
>
>On Tue, Jan 05, 2016 at 08:08:29PM +, Acee Lindem (acee) wrote:
>> Juergen, 
>> 
>> As another non-author, I disagree with this characterization of the draft.
>> The intended/applied configuration is an important requirement but
>> certainly not the only one precisely articulated in the 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:54PM +, Kent Watsen wrote:
>> >> 
>> >> This update addresses comments received during the Last Call.
>> >>
>> >
>> >I not entirely happy with the new title:
>> >
>> >   Terminology and Requirements for Enhanced
>> >Operational State Visibility and Control
>> >
>> >Since the key contribution is the concept of intended configuration
>> >and applied configuration, why not put these terms into the title
>> >instead of "Enhanced Operational State Visibility and Control", which
>> >is somewhat vague? What about this proposal:
>> >
>> >   Terminology and Requirements for Distinguishing
>> >  Intended and Applied Configuration
>> >
>> >/js
>> >
>> >-- 
>> >Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>> >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>> >Fax:   +49 421 200 3103 <http://www.jacobs-university.de/>
>> >
>> >___
>> >netmod mailing list
>> >netmod@ietf.org
>> >https://www.ietf.org/mailman/listinfo/netmod
>> 
>
>-- 
>Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>Fax:   +49 421 200 3103 <http://www.jacobs-university.de/>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

[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 which a change is applied. However there 
is also the case where intended != applied config and there are two reasons for 
that.

a)  a previous intended config is in the process of being applied

b)  a previous configuration failed due to an error

[KENT] or due to missing hardware, right?   Regardless, I don’t think this 
thread has bearing of the requirements draft.  Note that I removed the 
*-on-error terms from the Terminology section in -02 by instead rewording 
requirement 2-C, which was the only place they were being referenced before and 
the reference was merely suggestive (not normative).  Can we leave it to the 
solution drafts to sort out?


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

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

[Kent Watsen]

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 objections are raised by tomorrow, I’ll post -03 
using this title.

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

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

[Kent Watsen]

[As a contributor]

As I count it, there are four in favor and two not in favor of the title 
proposed by Robert, so I’m going to post -03 with that one.

Kent



On 1/8/16, 9:26 AM, "netmod on behalf of Ladislav Lhotka" 
<netmod-boun...@ietf.org on behalf of lho...@nic.cz> wrote:

>
>> On 08 Jan 2016, at 14:46, Acee Lindem (acee) <a...@cisco.com> wrote:
>> 
>> 
>> 
>> On 1/8/16, 7:47 AM, "netmod on behalf of Ladislav Lhotka"
>> <netmod-boun...@ietf.org on behalf of lho...@nic.cz> wrote:
>> 
>>> Juergen 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:
>>>>>> On Wed, Jan 06, 2016 at 06:18:46PM +, Kent Watsen wrote:
>>>>>>> It’s true that the draft is largely centered around the
>>>>>>> intended/applied config notion, but not exclusively.  Specifically,
>>>>> 4-B 
>>>>>>> has "Ability to map intended config nodes to associated derived
>>>>> state 
>>>>>>> nodes".  I think that this might be the only exclusion though and,
>>>>> if it 
>>>>>>> weren’t for it I would’ve used your title suggestion from the LC
>>>>>>> review.   Should one requirement have such influence over the title
>>>>> is 
>>>>>>> the question.  I was trying to be fair to it, but maybe it's going
>>>>> too 
>>>>>>> far.
>>>>>>> 
>>>>>>> Regarding visibility and control, I was attempting to use common
>>>>> words 
>>>>>>> (not normative terms) here.  My intent for them is something along
>>>>> the 
>>>>>>> lines of:
>>>>>>> 
>>>>>>> visibility: read/understand
>>>>>>> control: write/orchestrate
>>>>>>> 
>>>>>> We do not write operational state. I have no clue how 'orchestrate'
>>>>>> helps me either. What is wrong with using defined terminology in
>>>>>> a title?
>>>>> I don't think that using defined terminology is a problem.  But I also
>>>>> think that the title that you have suggested seems to suggest a
>>>>> narrower 
>>>>> scope that what the requirements articulate.
>>>>> 
>>>>> In particular, the draft places requirements relating the
>>>>> configuration 
>>>>> to the derived state (I.e. Req 4B).
>>>>> 
>>>>> It also places further requirements on how management protocols are
>>>>> expected to handle synchronous and asynchronous config edit requests.
>>>>> (E.g. Req 2 A, B, C and associated definitions).
>>>> 
>>>> Note that synchronous and asynchronous are defined in terms of
>>>> intended / applied configuration.
>>>> 
>>>>> 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"?
>>>> 
>>>> Better but I still think this proposal is too broad given the content
>>>> of the document. I still believe my proposal is right to the point.
>>> 
>>> +1
>>> 
>>> The draft talks about introducing applied configuration and its
>>> relationship to state data and intended configuration (which, I believe,
>>> is the good old "running"). I don't see any enhanced handling of
>>> operational state.
>> 
>> The draft is quite succinct and I’m not sure how you and Juergen do not
>> agree that there are requirements beyond intended/applied state. Perhaps
>> you do not agree with them? Refer to requirements 3.(B & C) and 4.(B & C).
>> For your convenience, I’ve excerpted them below:
>> 
>
>Well, opstate-reqs defines applied configuration and *proclaims* it to be a 
>part of operational state, whereas it is a new artefact that has to do with 
>how the server processes configuration.
>
>With two exceptions commented on below, the requirements really are directly 
>related to the introduction of applied configuration.
>
>In other words: for those who don't want to use applied configuration, there 
>is

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

[Kent Watsen]

In addition to the title update, I also updated the abstract/introduction and 
fixed a couple editorial items.

Kent




On 1/8/16, 7:58 PM, "netmod on behalf of internet-dra...@ietf.org" 
<netmod-boun...@ietf.org on behalf of internet-dra...@ietf.org> wrote:

>
>A New Internet-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
>Authors : Kent Watsen
>  Thomas Nadeau
>   Filename: draft-ietf-netmod-opstate-reqs-03.txt
>   Pages   : 7
>   Date: 2016-01-08
>
>Abstract:
>   This document primarily regards the difference between the intended
>   configuration and the applied configuration of a device and how
>   intended and applied configuration relate to the operational state of
>   a device.  This document defines requirements for the applied
>   configuration's data model and its values, as well as for enabling a
>   client to know when a configuration has been fully applied or not,
>   how to access operational state, and how to relate intended
>   configuration nodes to applied configuration and derived state nodes.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/
>
>There's also a htmlized version available at:
>https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-03
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-opstate-reqs-03
>
>
>Please note that it may take a couple of minutes from the time of submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

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 wrote:
>> 
>>> I hope that nobody disagrees that the operational state design and how 
>>> to structure the models are the two blocking factors to publish YANG 
>>> models. If you disagree or don't see this, let me know, I should 
>>> communicate better.
>> 
>> Even if it may spoil your day, I disagree that there is a blocking
>> factor that should stop us from publishing models. There seem to be
>> ways to address the requirements without having to block all work or
>> to redo what that we have published. But sure, if you make it a
>> blocking factor, it will be one.
>
>I agree with Juergen. It is not clear to me how the proposed split between 
>intended and applied configuration is supposed to affect the data models we 
>are working on.


As I understand it, solution #1 affects the models themselves, whereas 
solutions #2 and #3 are transparent to the models.

Kent



>Lada
>
>> 
>>> I hope that nobody really believes that because some people in IETF (or 
>>> in any other SDOs) thinks that what those operators want is a bad idea, 
>>> those operators will not get what they request/pay for from their suppliers.
>> 
>> To be fair, those operators also tell us that they use protocols that
>> are not IETF protocols and it remains somewhat unclear what those
>> protocols are we are expected to optimize data model solutions for.
>> 
>> /js
>> 
>> -- 
>> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103 
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

[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 transition (C)?

Yes


>i.e. if some part of
>an edit fails during the transition from intended->applied we should
>"rollback" the other parts that may have already been applied ?

Yes


>Would we then remove it all from intended as well ?

IMO, yes.  This is more easily understood when thinking about Synchronous 
Configuration Operations (defined in opstate-reqs), but I believe that it 
equally applies to Asynchronous Configuration Operations, so long as the client 
explicitly ops-in for the behavior.


>I'm not sure how that would work for an async/hybrid (read "real”)
>system.  We've already done an "ack" back to the client before 
>transition (C) so the client may have already sent some additional
>new config that depends on the previous edit.  That would mean that
>new config isn't valid.

I’m not a fan on the “hybrid” term, but in thinking about legacy or existing 
NETCONF servers, I think that this is a non-issue as the server wouldn’t 
advertise support for Rollback on Error in the first place.


Kent





On 12/21/15, 1:57 PM, "netmod on behalf of Robert Wilton" 
 wrote:

>Hi Jason,
>
>Picking up this slightly old thread.
>
>The "rollback on error" definition that I added I took directly from 
>RFC6241, so it's good that they look similar.  The intention is that the 
>NETCONF "rollback-on-error" capability is a valid implementation of this 
>requirement :-)
>
>I think that the  rollback-on-error capability defined in RFC6241 can 
>also be applied to the running datastore.  Certainly, the example quoted 
>is in the context of the edit-config request on the running-config 
>datastore, and the RFC description of this feature doesn't appear to 
>limit it to the candidate datastore in any way.
>
>Thanks,
>Rob
>
>
>On 03/11/2015 07:23, Sterne, Jason (Jason) wrote:
>> Hi all,
>>
>> The term "rollback on error" (and other error options) has been used during 
>> these discussions around the opstate requirements.
>>
>> That term already has some meaning in RFC6241 (or at least rollback-on-error 
>> does and that is pretty close) and IMO it (today) has nothing to do with 
>> "applied" config.  It is an error option that has the scope of the contents 
>> of a single edit-config request and how those contents get applied (all or 
>> nothing) to the candidate DS (which is neither intended nor applied config) 
>> or to the running DS (intended) if the  is .
>>
>> I think we need to clarify this "all or nothing" concept and how it is 
>> related to "applied" config.  We may also want to use slightly different 
>> terminology so we don't get confused with today's meaning of 
>> rollback-on-error.
>>
>> There are a few transitions to consider when editing a config and applying 
>> it to a device (I'll give the example of using the candidate DS):
>> (A) config changes   ---> candidate DS   ()
>> (B) candidate DS  > running (intended)  ()
>> (C) intended > applied  (internal processed in the device)
>>
>> Today rollback-on-error is only applicable to transition (A).
>>
>> Transition (B) does have all-or-nothing properties (as described in RFC6241) 
>> but that isn't related to "rollback-on-error".
>>
>> Is there some intention in the opstate requirements to add some sort of 
>> all-or-nothing behavior to transition (C) ?  i.e. if some part of an edit 
>> fails during the transition from intended->applied we should "rollback" the 
>> other parts that may have already been applied ?
>>
>> Would we then remove it all from intended as well ?
>>
>> I'm not sure how that would work for an async/hybrid (read "real") system.  
>> We've already done an "ack" back to the client before transition (C) so the 
>> client may have already sent some additional new config that depends on the 
>> previous edit.  That would mean that new config isn't valid.
>>
>> Jason
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> .
>>
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

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: 
rollback-on-error)
  http://www.ietf.org/mail-archive/web/netmod/current/msg14641.html  (re: 
model-structure)

As for this thread:

1. Regarding adding an explicit backwards-compatibility requirement, please 
note that what was written here is still in effect: 
http://www.ietf.org/mail-archive/web/netmod/current/msg14629.html.  Note that 
no objections have been raised yet, so this will likely happen.

2. Regarding adding an applicability statement, there is currently only one 
voice asking for it, which isn’t enough to warrant a change.

Thanks,
Kent



On 12/18/15, 6:33 AM, "netmod on behalf of Robert Wilton" 
 wrote:

>Hi,
>
>On 17/12/2015 23:45, Randy Presuhn wrote:
>> Hi -
>>
>>> From: Robert Wilton
>>> Sent: Dec 17, 2015 1:12 PM
>>> To: Andy Bierman
>>> Cc: "netmod@ietf.org"
>>> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
>> ...
>>>  Your requirement is a bit too strong for my liking.
>>>
>>>  To paraphrase your requirement text, it is forcing that all
>>>  compliant NETCONF/RESTCONF servers MUST support any clients that do
>>>  not want to differentiate between intended config and applied
>>>  config.
>> Do do otherwise sound to me like an interoperability disaster,
>> and would encourage the "siloization" of toolsets.
>>
>>>  However, this requires all opstate aware servers:
>>>
>>>   - To handle a mix of clients, some of which are opstate aware, and
>>>   some that are not.
>> This seems perfectly reasonable.  To do otherwise torpedoes the very
>> notion of interoperability.
>>
>>>   - To potentially handle a mix of requests, some of which are
>>>   opstate aware requests, and some are not.
>> Ditto.
>>
>>>  It also prevents:
>>>
>>>   - Having a server that is implemented to only support opstate aware
>>>   clients.
>> Avoiding the creation of such servers sounds like a *good* thing to me.
>>
>>>   - Having a server side configuration knob to control the behaviour
>>>   (since it would affect the semantics for all clients).
>> This also sounds like something which it would be desireable to prevent.
>>
>> I think I'm squarely with Andy on this one.
>
>Taking a step back ...
>
>I am probably way off the mark, but my perception is that some (perhaps 
>many) of the folks in the WG still perceive that the opstate 
>requirements are niche requirements for some unusual scenarios, and that 
>everyone else is happy with the status quo and don't want/need them.
>
>Alas, I don't share that view.  For me, the opstate requirements can be 
>summarized as saying that the operators just want to know what 
>configuration the device is actually running in a format that is 
>convenient for them to use.  This really doesn't appear to be 
>unreasonable request to me, and if I was writing to a network 
>manageability API then I would choose to use opstate because I perceive 
>that it is a more robust and easier to use API.  The counter arguments 
>appear to be that it is too hard for devices to provide this 
>information, and that the operators have historically managed without it.
>
>However, I think that several things have changed, and hence negate 
>these counter arguments: (i) the operators want to have much more 
>automation and management over their devices, (ii) they have found a way 
>to group together and have a more vocal voice about what they need and 
>want, (iii) the operators have realized that they don't need to wait for 
>the SDOs and can create defacto standard models on their own if they 
>have to.
>
>Personally, I would like us to stop spending time churning on the 
>requirements and actually get on to discussing the solutions.  To be 
>honest, there has been relatively little change in my understanding of 
>the requirements from reading draft-openconfig-netmod-opstate-01 back in 
>July, and I was expecting to discuss the solution drafts back in 
>September.  Here we are in December, and I'm not convinced that we have 
>truly made significant progress.
>
>The only reason that I submitted a solution draft to this problem was 
>because I thought it unlikely that OpenConfig would support a multiple 
>datastore solution, and I could see strong resistance amongst the IETF 
>engineers to the proposed OpenConfig solution.  I was hoping that my 
>proposed solution might be seen for the compromise that it is between 
>the two opposing positions.  But I care less on what the solution is, 
>and more whether we can agree on one and move forward.
>
>As someone that is quite new to SDO processes, my main concern is that 
>IETF (and other standards bodies) are moving too slowly here, 

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

[Kent Watsen]

[As a contributor]

Hi Juergen,

I agree with you that req #5 sticks out as the odd ball in the bunch.  I 
suggested once to remove it a long time back, but I guess it fell on deaf ears 
then.  Anyway, given where we are with this document, I’m unsure what to do, 
but here are our options:

1. Leave requirement #5 in the document, but spend time improving it to WG 
satisfaction.

2. Take requirement #5 out, declaring it an unwanted distraction from the 
primary opstate focus.  We’d have to be sure to get sign-off from the OC folks 
too...

So far it sounds like Juergen and I are with #2, how 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.
>> 
>> 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, the relating of config 
>> to derived state and also the model structure requirement are not related to 
>> applied config.  In all fairness, Requirement #5 (model structure) isn’t 
>> even about operational state.
>
>Reading #5 again I must admit that I do not really understand what
>this requirement tries to accomplish:
>
>   5.  Ability for distinct modules to leverage a common model-structure
>
>   A.  Focus on the IETF-defined modules, and ideally provides
>   guidance to other SDOs
>
>   B.  Multiple domain-specific model-structure trees are okay
>
>   C.  Model-structures may be defined in multiple modules with
>   distinct namespaces
>
>At this level of abstraction, #5 really does not mean anything or N
>people will have at least N different interpretations of it. I
>actually think this should be taken out and moved into a different
>document and then it requires to be developed into something much more
>concrete.
>
>/js
>
>> So your title and abstract suggestions might define too narrow a scope.  So 
>> how about:
>> 
>> Title: Terminology and Requirements for Operational State and Model Structure
>>
>> Abstract:
>>  This document defines requirements for enhancing the support
>>  of operational state through the introduction of a conceptual
>>  "applied configuration".  The document also defines requirements
>>  enabling distinct modules to leverage a common model structure.
>> 
>> …and add an Introduction section that expands on this theme further?
>
>I think this is getting into the wrong direction and as explained
>above #5 is by far underspecified to be of any value. I suggest to
>take it out so that we can publish the rest in a timely manner. The
>alternative is to hold off this document in an attempt to replace #5
>with something that is concrete and actionable.
>
>/js
>
>-- 
>Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>Fax:   +49 421 200 3103 <http://www.jacobs-university.de/>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft netmod 94 minutes posted

[Kent Watsen]

ting for IEEE 802.1Q WG chair - what is that?
> [MJ]  Glen thinks that the extension of VLAN YANG model 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...@cisco.com<mailto:rwil...@cisco.com>>
Date: Tuesday, November 24, 2015 at 11:59 AM
To: Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>>, 
"netmod@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] draft netmod 94 minutes posted

Hi Kent,

I've some minor modifications of some of the minutes, mainly just to clarify 
who was asking some of the questions/comments (mostly between Rob Shakir and 
myself), but also some other minor clarifications when I was listening back to 
the audio.

[Before]

10 min: draft-ietf-openconfig-netmod-opstate-01(Anees Shaikh or [RS] Shakir)
Rob Shakir presenting.
[LL] Would it be possible to have multiple management interfaces (NETCONF, 
RESTONF, other) - is the intended configuration supposed to be private per 
transport protocol?
[RS]  Would think no. There is one intended configuration per device.
[LL] this may have some locking implications.
[TC]  Why did you chose to use intended/applied approach?
[RS]  This allows us to use YANG today.
[KW] there were 3 solutions drafts.
[TC]we are doing the same thing in BBF, and would like to mimic the 
solution agreed here.
[AS] There is a section i a draft that addresses this.
[LB]  I am confused on the process for the requirements. You said you will make 
consensus call for requirements today?
[KW] we will do a consensus call on solutions. I believe there is consensus on 
requirements.
[LB]  on a list there was a discussion on planning to poll for consensus but 
that did not seem to happen.
[KW] confirming consensus on requirements now by humming - consensus achieved.


[After]
10 min: draft-ietf-openconfig-netmod-opstate-01(Anees Shaikh or [RS] Shakir)
Rob Shakir presenting.
[LL] Would it be possible to have multiple management interfaces (NETCONF, 
RESTONF, other) - is the intended configuration supposed to be private per 
transport protocol?
[RS]  Would think no. There is one intended configuration per device.
[LL] this may have some locking implications.
[TC]  Why did you chose to use intended/applied approach rather than using 
datastores?
[RS]  1. No such thing as an applied datastore today.  This solution allows us 
to use YANG today. 2. Our solution allows for a single path that is not 
dependent on the datastore.
[KW] there were 3 solutions drafts.
[TC]we are doing the same thing in BBF, and would like to mimic the 
solution agreed here.
[AS] There is a section in our draft that addresses some of these questions.
[LB]  I am confused on the process for the requirements. You said you will make 
consensus call for requirements today?
[KW] we will do a consensus call on solutions. I believe there is consensus on 
requirements.
[LB]  on a list there was a discussion on planning to poll for consensus but 
that did not seem to happen.
[KW] confirming consensus on requirements now by humming - consensus achieved.


[Before]

10 min: other solutions for the opstate-reqs (Robert Wilton)
Robert Wilton presenting.
[RW]  no changes to existing YANG models - that does not seem to be practical. 
There are vendor extensions anyway.
[RW] Wilton  if models are standardised in IETF, they should work in all cases.

[KW] we would like to know which of those solutions should progress forward.
[Rw]  would be nice to poil for who has read the solutions drafts?
[KW] who would favor solution 1. Humm. 2. Humm (most). 3. Humm
[KW] Does anyone object to solution 2? Please go to mike?
[Rw]  Didn't we do that already? We seem not to going anywhere forward with 
this discussion. We did clarify wording, but that is mostly it. It is noting 
for operator to help with configuring a network. Is it a perfection problem 
here? Can we produce something practically useful?
[CM] There are large installations based on existing YANG specifications.
[RW]I take that into account. I have none in my network though that use 
existing model. I am not saying that we should throw away the existing solution 
in favor of the future solution.
[CM] There is a technology shift.
[CH] We are not forcing to implement some particular data store technology. 
This is more of a way of thinking of it.


[After]
10 min: other solutions for the opstate-reqs (Robert Wilton)
Robert Wilton presenting.
[RS] No changes to existing YANG models - that does not seem to be practical. 
There are vendor extensions anyway.
[RW]   if models are standardised in IETF, they should work in all cases.

[KW] we would like to know which of those solutions should progress forward.
[RS] Wo

Re: [netmod] draft netmod 94 minutes posted

[Kent Watsen]

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.
>> 
>> https://tools.ietf.org/wg/netmod/minutes?item=minutes-94-netmod.html


When clicking on the “audio stream” link:

  - Safari says “ This webpage has content that requires an Internet plug-in.
This page contains content of “audio/x-mpegurl” type. You do not have the
plug-in required to view this content.  I clicked the “missing plugin”
link, but it didn’t do anything.

  - Firefox offers to save the file or load with iTunes.  Loading with iTunes
doesn’t work.  Saving to file and then examining its contents shows
"http://icecast-ietf.conf.meetecho.com:8000/room301.mp3”, which looks
like it’s more for the live stream as oppose for a recorded stream.




>Try this one:
>
>http://ietf94.conf.meetecho.com/index.php/Recordings
>
>
>/martin


This worked for me in Firefox, but not Safari (it spins forever trying to load 
the page)

Thanks,
Kent



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

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

[Kent Watsen]

[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 terms specified in the terminology section.

I removed “(see term[s])” from my local copy.  I view this as an editorial 
change.



>- Any reason why the "backwards compatibility" (section 3) is not 
>numbered as a requirement in section 4?  I.e. a new requirement 5. Or is 
>it because it's a special requirement?
>Numbering all the requirements might ease the comparison of the 3 
>different proposed solutions.

FWIW, the Backwards Compatibility section was not initially incorporated into 
the Requirements section because it seemed more like an implicit/generic 
requirement, not a solution-specific requirement.   That said, I have to agree 
that it would help reviews.  For instance, when trying to determine how a 
solution satisfies each requirement, it would be easier to have “Backwards 
Compatibility” folded into the Requirements “tree”, rather than having to call 
it out special.  So, if no one objects, I will make this change tomorrow.


>- There is a requirement in asynchronous configuration operations 
>definition:
>Once applied, there MUST be a mechanism for the client
>to determine when the request has completed processing and
>whether the intended config is now fully effective or there are
>any errors from applying the configuration change, which could be
>from an asynchronous notification or via a client operation.
>
>Why isn't it a numbered requirement in section 4?

Good point, it does read like a requirement more so than a term.   I note that 
requirement 2-B has overlap with the "or via a client operation" clause, so I 
think it makes sense to move this text into requirement 2-B.  Again, if no one 
objects, I will make this change tomorrow.



Thanks again,
Kent



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

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

[Kent Watsen]

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

[Kent] okay, I will do that.


but more importantly, you should tell us what is intent behind a MAY sentence 
is.
So it means that the specified solution MAY or MAY not have this functionality, 
right?

[Kent] yes, that is how I am interpreting it


So what is the requirement? Maybe it's not a requirement, but just something to 
think about.

[Kent] just something to think about I guess.  But I will change the two MAY 
instances in the draft, so we don’t need to worry about it anymore  ;)


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

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

[Kent Watsen]

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
>document are to be interpreted as described in [RFC2119].
>
>While [RFC2119] describes interpretations of these key words in terms
>of protocol specifications and implementations, they are used in this
>document to describe design requirements for protocol extensions.

Is this needed?  Looking at RFC2119, I don’t read it as being very particular 
about the context it’s terms are used in.

Additionally, other requirements docs use RFC2119 without any such a paragraph 
(e.g., RFC7698, RFC7497, RFC7449, etc.)...


>Btw, I never quite understood what a MAY means for a requirement.
>See requirement 2B and 2C

For 2B, would you rather is be a SHOULD?
For 2C, would you rather this be a “may”?

FWIW, the other requirements docs listed above also use "MAY" in some of their 
“requirements"


Kent


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

Re: [netmod] The Restconf root

[Kent Watsen]

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 Juergen Schoenwaelder" 
 
wrote:

>Hi,
>
>this comment seems to be long to NETCONF and not NETMOD.
>
>/js
>
>On Sun, Jun 12, 2016 at 10:14:17PM -0400, Dale R. Worley wrote:
>> Looking at draft-ietf-netconf-restconf-13, it looks like the RFC 7320
>> mechanism is used to find the root URL, from which all the Restconf URLs
>> are derived by appending path components as specified in the draft.
>> 
>> But looking at RFC 6570, which is referenced by both 7320 and the draft,
>> it seems like appending path components to a configured base URL is no
>> longer best practice, because it requires the HTTP server to be able to
>> connect all those URLs to the Restconf server despite their different
>> paths.  It seems like the new, improved method is for a URL template to
>> be advertised, and the Restconf client should use the template and the
>> Restconf specification to construct the URL to be used.
>> 
>> E.g., now, the example in section 3.1 shows how the Restconf root is
>> obtained:
>> 
>>   Request
>>   ---
>>   GET /.well-known/host-meta HTTP/1.1
>>   Host: example.com
>>   Accept: application/xrd+xml
>> 
>>   Response
>>   
>>   HTTP/1.1 200 OK
>>   Content-Type: application/xrd+xml
>>   Content-Length: nnn
>> 
>>   
>>   
>>   
>> 
>> and used, with the sub-URL "operations":
>> 
>>   Request
>>   ---
>>   GET /top/restconf/operations  HTTP/1.1
>>   Host: example.com
>>   Accept: application/yang.api+json
>> 
>> RFC 6570 seems to suggest that the first lookup should return a URL
>> template:
>> 
>>   Request
>>   ---
>>   GET /.well-known/host-meta HTTP/1.1
>>   Host: example.com
>>   Accept: application/xrd+xml
>> 
>>   Response
>>   
>>   HTTP/1.1 200 OK
>>   Content-Type: application/xrd+xml
>>   Content-Length: nnn
>> 
>>   
>>   
>>   
>> 
>> The value of this being that a different server might return the
>> template 'http://example.com{?resource}', causing the second request to
>> use the URL 'http://example.com?resource=operations'.
>> 
>> Although this probably requires a redefinition of the href attribute of
>> the Link element.
>> 
>> Dale
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>-- 
>Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>Fax:   +49 421 200 3103 
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

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

[Kent Watsen]

[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 support only synchronous configuration
>>operations, or only asynchronous configuration operations, or
>>both synchronous and asynchronous configuration operations on
>>a client-specified per-operation basis.
>>
>>
>>After:
>>
>>A.  A server MUST support only synchronous configuration
>>operations, or only asynchronous configuration operations, or
>>both synchronous and asynchronous configuration operations on
>>a client-specified per-operation basis.
>Gert> support

This does seem better, thanks for the suggestion.  I view this as an editorial 
fix.




>>For 2B, I agree changing MAY to SHOULD but we should broaden this to
>>apply to synchronous servers as well.  Even though a config edit
>>operation is synchronous it could still fail to be applied for some
>>leaves, and hence the intended and applied leaves could be out of step.
>>Hence I propose the following change:
>>
>>Before:
>>
>>B.  Servers that support asynchronous configuration operations
>>MAY also provide a verify operation that a client can request
>>from the server to return information regarding the
>>difference between the intended and applied configurations.
>Gert> as per definition of synchronous, the confirmation has to indicate
>that the intended config has been applied or has been failed. I therefore
>like to keep the current text suggesting to change the existing text
>slightly (SHOULD instead of MAY):
>
>B.  Servers that support asynchronous configuration operations
>SHOULD also provide a verify operation that a client can request
>from the server to return information regarding the
>difference between the intended and applied configurations.
>>
>>
>>After:
>>
>>B.  Servers SHOULD also provide a verify operation that a client
>>can request from the server to return information regarding
>>the
>>difference between the intended and applied configurations.


I agree with Gert on this one - and it is what I told Benoit I would do...

My observation that the “difference” could be as simple as a flag or as complex 
as an actual diff.   When considering the former, there is no need for an 
addition verify option when a synchronous call is made, whereas a verify option 
*would* be useful when an asynchronous call is made.   That said, when 
considering the latter, it seems that a verify option would always be useful.

Being conservative, I choose to believe that “difference" has the simplest 
meaning and hence conclude that the SHOULD only applies to servers that support 
asynchronous configuration operations.  This doesn’t mean that a solution can 
always provide a verify operation, of course, and if the result includes an 
actual diff, it’s value will be understood as being generally useful.  Makes 
sense?


>>For 2C, I think that the "may" should change to "SHOULD", otherwise the
>>requirement that "rollback on error" semantics SHOULD be provided
>>doesn't seem well grounded.
>>
>>So, before:
>>
>>C.  The configuration protocol MUST specify how configuration
>>errors are handled.  Errors MAY be handled by semantics
>>similar to NETCONF's error-options for the 
>>operation (stop-on-error, continue-on-error, rollback-on-
>>error), as described in Section 7.2 in [RFC6241], but
>>extended to incorporate both the intended and applied
>>configurations.  Support for "rollback on error" semantics
>>SHOULD be provided.
>>
>>After:
>>
>>C.  The configuration protocol MUST specify how configuration
>>errors are handled.  Errors SHOULD be handled by semantics
>>similar to NETCONF's error-options for the 
>>operation (stop-on-error, continue-on-error, rollback-on-
>>error), as described in Section 7.2 in [RFC6241], but
>>extended to incorporate both the intended and applied
>>configurations.  Support for "rollback on error" semantics
>>SHOULD be provided.
>Gert> support

This does seem better than the s/MAY/may/ I proposed to Benoit.  

The important thing to me is that there is still a lot of leeway in the 
"handled by semantics similar to” clause.  It’s just saying that the client 
SHOULD have some control over error handling, which I think is still in keeping 
with the original phrasing of the requirement.   So I view this as another 
editorial fix.

Thanks,

Kent

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

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

[Kent Watsen]

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 Robert Wilton"
> wrote:
>
>>Hi,
>>
>>Over the last week or so there has been quite a lot of discussion and
>>longs threads regarding applied configuration and system-controlled
>>entries.
>>
>>To try and bring that thread to an explicit conclusion I have tried to
>>summarize (at least from my POV) where I think these discussions have
>>reached, hopefully get feedback from others, and make any updates to the
>>requirement draft that may be required.
>>
>>I think that there were broadly three different threads to the
>>discussions:
>>
>>
>>1) Lada requested that the requirement text in requirement 1D be
>>loosened so that the applied configuration schema doesn't have to be a
>>subset of the intended configuration schema.  The aim of the loosening
>>of this text is to allow system-controlled entities (such as interfaces
>>that always exist) to be put in the applied configuration.
>>
>>Personally, I'm opposed to this change, since the relationship between
>>intended and applied was explicitly discussed and it was confirmed that
>>the schema for the two was expected to be the same so that they can be
>>easily compared.
>>
>>Is there any other support for loosening the requirement text as per
>>Lada's suggestion?
>Gert> (1) In my response to Lada, I expressed the view the text in 1D
>allowed the use case he had in mind. In his case there is no intended
>config pushed to the server, hence there is no "corresponding applied
>configuration². That said I don¹t see the need to change the wording but
>would argue that Lada¹s use case is covered by the current text (see also
>(2)).

Kent> Agreed, so let’s conclude this issue as DEAD.



>>However, there is still a related corner case that hasn't been raised
>>yet, but may be useful to consider, which is where a systems default
>>setting differs from the one defined in an associated YANG module.
>>
>>To take an example, a YANG module for LLDP might use a global
>>P-container to indicate whether the LLDP protocol is enabled on the
>>device.  However, for a particular vendors device, the default behaviour
>>for LLDP may be that is enabled globally.
>Gert> indeed a valid scenario

Kent> Seems like a bug either in the module or the vendor’s implementation of 
the module.


>>If a operator is configuring the device via YANG and pushes down their
>>initial config (using a config replace semantics to replace the entire
>>existing configuration of the device), and the config that is pushed
>>down doesn't include the P-container to explicitly enable LLDP then I
>>think the expectation is that the device should disable LLDP when
>>processing the config request (even though it the device's default).
>>Further, all the time that the device doesn't match the implicit
>>intended p-container node state (of non-existence), it should report an
>>applied p-container node to indicate that LLDP is actually enabled on
>>the device even though the intended behaviour is that it be disabled.
>>
>>In essence I'm saying that the intended configuration includes all
>>explicit data nodes, any default node values in scope, and also any
>>nodes in scope that have an implicit schema default value of
>>non-existence (i.e. the feature is not enabled).
>>
>>Do others agree with my interpretation of intended configuration for
>>this scenario?
>Gert> (2) Perhaps we should to distinguish the modelling aspect from the
>usage aspect:
>-modeling: Whatever the model contains as applied state should also
>modelled as intended state and should also include default values (guess
>this is in line with your understanding)
>-usage: A client may not make full use of intended configuration for a
>given server and could rely upon default values in the applied config. In
>that case the intended config (in use) covers a subset of the applied
>config (see (1)).

I’m not convince this needs to solved (see above)



>>2) Separately, there has been a suggestion from Lada (also supported by
>>Gert?) such that the applied configuration always explicitly reports
>>default values (e.g. like the report-all option in RFC 6243).
>>
>>I generally support this suggestion because I think it solves the
>>problem that a server can't indicate a difference between a leaf not
>>being configured at all and leaf that is configured with the default
>>value.  However, I would see it that the YANG schema for both intended
>>and applied configuration is still the same, and hence I don't see any
>>direct need to modify the requirements draft.  I think that all three
>>proposed solutions are able to support this, and hence this issue can
>>probably be deferred until a general solution approach has been 

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

[Kent Watsen]

>>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 associated derived
>>state nodes
>> 
>>C.  The relationships needs to be programmatically consumable
>> 
>> 
>> Are there any other views on whether this requirement text should be 
>> updated?
>>
>
>I think the new wording is an improvement.

I agree and view this as an editorial fix.


  
>> >>Personally, I think that the relationship should be expressed in the
>> >>reverse direction.  I.e. a particular node of derived state should be
>> >>allowed to refer back to the config (intended/applied) that is derived
>> >>from.  This is presumably an implementation detail rather than a
>> >>requirement.
>> >Yes, I wrote about this earlier - some several weeks ago. What is
>> >really helpful for a managing system is to know the source of derived
>> >state, be it applied config, be it a routing protocol daemon, be it a
>> >dhcp server, be it a piece of tunneling software, be it an I2RS
>> >agent. So yes, I agree with you that the reverse direction is
>> >desirable (e.g., have meta data for derived state that explains where
>> >the state if originating from). What I also explained back then is
>> >that a standard Linux kernel does not track this context for many
>> >resources, which makes this somewhat difficult (= expensive) to
>> >implement. But yes, from a management point perspective, knowing the
>> >source of derived state is truly helpful in my experience.
>> 
>> There seem to be two separate angles to this:
>> 
>> (1) Allowing the schema to express the relationship between derived 
>> state and config nodes.  This effectively allows the operator to know 
>> that if they change a particular config item, which derived state fields 
>> they may want to check to ensure that the config change has been enacted 
>> correctly.  My understanding is that this is what the requirements in 
>> section 4 of the requirements draft are addressing.
>
>This direction of the relationship might in some cases be a relatively
>trivial and predictable 1:1 relationship, in other cases it may be
>more complex and in the worst case dynamically changing.

It YANG module could support 1:N by having a list of associated derived state 
relationships.  I don’t get the dynamically changing part, are you saying the 
derived state can randomly appear anywhere?




>> (2) Optional meta-data annotations to the derived state that indicates 
>> for a specific node in the data tree what is/are the sources for that 
>> nodes existence/value.  I agree that this does seem useful, but my hunch 
>> is that very few systems would be able to track or provide this 
>> information today.  My naive impression is that this would be more 
>> difficult for system vendors to implement than the applied configuration 
>> nodes.
>
>If you can do 'applied config' -> 'associated derived state' then you
>should be able to do 'derived state' -> 'applied config' for 'derived
>state' associated with 'applied config'.

I made this point before as well.   Given the forward mapping, a system could 
calculate the reverse mapping...


>But yes, I agree that 'derived state' -> 'arbitrary source of derived
>state' is unfortunately unrealistic (in the general case).
>
>BTW, do we have a definition of 'associated derived state'? What is
>the scope of the _associated_ derived state? My interpretation is that
>it is any derived state that is a _direct_ consequence of some applied
>config being active but it does not include any state indirectly
>associated with some applied config. (For example, if I turn on a VPN
>service, then the associated derived state are VPN service counters
>etc. but not lets say interfaces dynamically created via the VPN
>service operation.)

I think your interpretation is acceptable, but do we need to define a term 
other than “derived state”?

   Derived State:  This data represents information which is generated
   as part of the server's own interactions.  For example, derived
   state may consist of the results of protocol interactions (the
   negotiated duplex state of an Ethernet link), statistics (such as
   message queue depth), or counters (such as packet input or output
   bytes).



Separately, the term “derived state” seems poorly named.  I know that it is 
what the OpenConfig draft called it, but it begs the question as to what the 
state is derived from.  Thoughts on a better name?


Thanks,
Kent

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

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

[Kent Watsen]

[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 6020bis is on
its way, but for the moment, I believe that changes to NETCONF need the
consensus of  the NETCONF WG.

I disagree.
I have implemented NETCONF and RESTCONF and I do not see any problems with
adding additional (optional) datastores.


KENT > Right, but mapping the solution to drafts is key.  For instance, would 
there be one draft to define the conceptual model and then two other drafts for 
mapping that model to NETCONF and RESTCONF?   And if so, to Tom’s point, should 
those drafts go through the NETCONF WG?



Tom Petch

Andy


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

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

[Kent Watsen]

[as a contributor]

I’m for ‘B’ as well, in case it wasn’t obvious from [2]  (Lou’s ref below).

Kent


From: "Kiran Koushik Agrahara Sreenivasa (kkoushik)" <kkous...@cisco.com>
Date: Friday, June 17, 2016 at 2:36 PM
To: Lou Berger <lber...@labn.net>
Cc: "netmod-cha...@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>, <lber...@labn.net>, Kent 
Watsen <kwat...@juniper.net>, <mishra.ash...@outlook.com>
Resent-Date: Friday, June 17, 2016 at 2:36 PM

Hi All
I’d like to support Option B below.
>> B) no explicit support is required for models to support
>>applied configuration -- and that the WG needs to
>>formalize an opstate solution based on the approach
>>discussed in [4] and [5].

Thanks
Kiran


>> All,
>>
>> We want to provide an update based on the off line discussions
>> related to OpState Solutions that we have been having and solicit
>> input from the WG.
>>
>> All authors of current solution drafts [1,2,3] together with those
>> who helped conduct the solutions analysis* were invited to the these
>> discussions -- with the objective of coming up with a single
>> consolidated proposal to bring to the WG. (I/Lou acted as facilitator
>> as Kent and Juergen were and are involved with the technical details.)
>>
>> The discussions have yielded some results but, unfortunately,
>> not a single consolidated proposal as hoped, but rather two
>> alternate directions -- and clearly we need to choose one:
>>
>> 1) Adopt the conventions for representing state/config
>>based on Section 6 of [1].
>>
>>From a model definition perspective, these conventions
>>impact every model and every model writer.
>>
>> 2) Model OpState using a revised logical datastore definition
>>as introduced in [4] and also covered in [5]. There is
>>also a variant of this that we believe doesn't significantly
>>impact this choice.
>>
>>With this approach, model definitions need no explicit
>>changes to support applied configuration.
>>
>> >From a technology/WG standpoint, we believe an approach
>> that doesn't impact every model written (i.e., #2) is superior.
>> The counterpoint to this is that the conventions based
>> approach (i.e., #1) is available today and being followed in
>> OpenConfig defined models.
>>
>> We would like to hear opinions on this from the WG before
>> declaring one of the following as the WG direction:
>>
>> A) models that wish to support applied configuration MUST
>>follow conventions based on [1] -- and the WG needs to
>>formalize these conventions.
>> or
>> B) no explicit support is required for models to support
>>applied configuration -- and that the WG needs to
>>formalize an opstate solution based on the approach
>>discussed in [4] and [5].
>>
>> We intend to close on this choice before Berlin.
>>
>> Thank you,
>> Lou (and co-chairs)
>>
>> [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01
>> [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02
>> [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02
>> [4]
> https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00
>> [5]
> https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00
>> * - Chris H. and Acee L.
>>
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org<mailto:netmod@ietf.org>
>> https://www.ietf.org/mailman/listinfo/netmod
>


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

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

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

[Kent Watsen]

>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 accepts an enumeration specifying the response 
format.  It seems that all that is needed is to define another enumeration for 
something like “yang-diff” that can do all you say.   We don’t have yang-diff 
today, but someone can write a draft to define it and then it can be added or 
used instead.  

Alternatively, the  RPC could be moved into a diff-draft that defines 
both the RPC and the format together.  Something like this might make sense as 
 is generally useful outside of this opstate application. 

Kent  // contributor 

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

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

[Kent Watsen]

[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 inferior to their current working solution (for which 
>they have models that are further ahead than IETF, running code, some 
>major vendors committed to implementing those models, and seeming more 
>interest from the large network operators in using those models).
>
>Will vendors actually implement a datastore based solution if the 
>OpenConfig operators (who are raising the requirement) don't actually 
>want/need to use it?
>
>Then I guess the final question I have is whether SDO produced models 
>will still be relevant if they lag 2 years behind the OpenConfig models, 
>and those models have become a defacto standard?

Let’s just focus on solving the engineering problem at hand.  The OC folks are 
more than welcomed to assist (seriously guys, where are you?), but let’s not 
speculate on their positions.



>>   If the only real technical argument is "I need to
>> be able to retrieve data from multiple datastores in a single RPC
>> operation"... 

I want to point out again (see [1]) that there is no requirement listed to 
return two configuration datastores in one RPC response - only the diff is 
specified as being required.  Yes, solution #1 has this ability, but that 
doesn’t translate to a requirement.   Unless we hear from operators that this 
was a missed requirement, we should not view it as such.


[1] https://mailarchive.ietf.org/arch/msg/netmod/ei_Xhnz22NoeMjlqY42DrUFGalI


Thanks,
Kent


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

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

[Kent Watsen]

>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 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 to return both (as oppose to the transform)?  
Just wondering if this is a must-have or a nice-to-have.

Kent  


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

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

[Kent Watsen]

On 2/5/16, 7:20 AM, "Gert Grammel" <ggram...@juniper.net> wrote:

>Hi Kent,
>
>On P.7 the current draft says: "Any rollback that may occur will restore
>both the intended and the applied configurations to their previous states."
>
>It is not clear to me to which phase of the configuration this statement
>refers to. In draft-ietf-netmod-opstate-reqs-04, Asynchronous operation is
>defined as 
>Asynchronous Configuration Operation:  A configuration request to
>  update the running configuration of a server that is applied
>  asynchronously with respect to the client request.  The server
>  MUST update its intended configuration before replying to the
>  client indicating whether the request will be processed.  This
>  reply to the client only indicates whether there are any errors
>  in the original request.  The server's applied configuration
>  state is updated after the configuration change has been fully
>  effected to all impacted components in the server.
>
>
>The statement "The server MUST update its intended configuration before
>replying to the client indicating whether the request will be processed²,


I think that this statement is/was a mistake.  It should’ve been left open to 
the server to return immediately, as even updating intended can take 3o+ 
seconds on some systems...



>doesn¹t define what to do after responding. I suggest to add the following
>clarification:
>1) in case of a negative response from the Server, the server shall roll
>back the intended config and the applied config shall not be affected.
>2) in case of a positive response from the server, the intended config
>shall remain. Upon failure in applying intended config, only applied
>config is affected according to the error-option (rollback-on-error,
>stop-on-error and continue-on-error)

This does not match my understanding of the desired behavior, nor would I know 
how to implement it without introducing additional API and metadata to 
support/control that approach.

Kent


>Rationale for 1: since the server didn¹t accept a new intended config
>(e.g. due to a syntax error), the original intended config should remain
>untouched.
>Rationale for 2: The intended state is logically owned by the client and a
>server is supposed to align with it. Once a server accepted the intended
>config with a positive response, a failure in the server execution doesn¹t
>affect the intention. It would be the client to modify the intended state
>if the intention changes. The difference between intended and applied
>state is an important source of information for a client. Removing the
>intended state after rollback would nullify the intention rather than
>documenting which applied state differs from its intended state. This is
>also in line with Œcontinue-on-error¹ and Œstop-on-error¹. In both cases
>the difference 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 behalf of kwat...@juniper.net> wrote:
>
>>
>>Hi All,
>>
>>I didn¹t receive the usual announcement CC-ed to the netmod list, so I¹m
>>replying to this one sent to the id-announce list instead.
>>
>>Anyway, this morning I posted -01 of this draft and then shortly after
>>-02 to fix some cleanup items I only noticed after -01 was posted  :ooops:
>>
>>Either way, this update is an overhaul to the original draft posted last
>>September.
>>
>>Kent
>>
>>
>>
>>
>>
>>On 2/2/16, 10:30 AM, "internet-dra...@ietf.org"
>><internet-dra...@ietf.org> wrote:
>>
>>>
>>>A New Internet-Draft is available from the on-line Internet-Drafts
>>>directories.
>>>
>>>
>>>Title   : Operational State Enhancements for YANG,
>>>NETCONF, and RESTCONF
>>>Authors : Kent Watsen
>>>  Andy Bierman
>>>  Martin Bjorklund
>>>  Juergen Schoenwaelder
>>> Filename: draft-kwatsen-netmod-opstate-02.txt
>>> Pages   : 27
>>> Date: 2016-02-02
>>>
>>>Abstract:
>>>   This document presents enhancements to YANG, NETCONF, and RESTCONF
>>>   satisfying the requirements set forth in Terminology and Requirements
>>>   for Enhanced Handling of Operational State.
>>>
>>>
>>>The IETF datatracker status page for this draft is:
>>>https://datat

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

[Kent Watsen]

[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 previously been accepted and then a linecard removed?  In this case
>>> the the affected interface configuration would stay in intended but be
>>> removed from applied by the system.
>> Looks like the semantics you describe are somewhat inconsistent.
>OK, they were not meant to be inconsistent at all:
>
>- The intended configuration is what the operator wants, and can only be 
>changed by the operator.
>- The applied configuration is what state the system is in, and should 
>be continuously kept up to date with the current system state.
>
>- If a config change completes without any errors that means that for 
>every node in the changeset, the applied config node matches the 
>intended config node.
>- This is why I would say that the cleanest semantics are that 
>attempting to configure an interface that doesn't exist should be 
>regarded as a config apply error.  (If the operator wants to push this 
>config in then I think that they should be using the continue-on-error 
>option - or perhaps something similar).

I disagree.  JUNOS specifically allows for preconfiguration for hardware that 
does not exists yet.  It’s a well-regarded feature.  It is not an error, but 
may be reported as a warning.  This is why we defined leaf "apply-warning” in 
this draft (see subject line).  That said, I do agree that the applied 
configuration would not have the config for the missing hardware, as would be 
evident in a diff between it and the intended configuration.  



>>   BTW,
>> I have been told that 'some operators' do provision configuration for
>> hardware not yet present. RFC 7223 has been designed to allow this to
>> happen. Anyway, this is an example. The point is that it is not clear
>Yes.  I'm not opposed to this on principal, but if a choice of semantics 
>are supported then it should be down the operators request to choose the 
>semantics.  Having rules that give flexibility in how a device is 
>allowed to behave just makes them more difficult for the operator to manage.

I think that this doesn’t scale.  By this token, servers should support 
everything the IETF defines.  But that’s not how it works, instead we have 
features and capabilities that enable devices to advertise what they support.  
This ability is important when a brown-field device is moving to support 
NETCONF/RESTCONF but can’t break compatibility with its legacy APIs.



Note that NETCONF together with YANG provides a rather clear
 definition what validation of a configuration datastore means. When we
 talk about applied config and the difference between intended and
 applied config, the notion of what is a configuration error is not
 clear cut anymore.
>>> Personally, I agree that having tighter semantics are a good thing here
>>> (and should be covered by the solution draft).
>> Then I note that the requirement is at least not well defined.
>Perhaps, but we had already spent a long time discussing the 
>requirements draft, hence personally I think that it is OK to 
>specify/agree the precise semantics/behaviour in a solution draft.

Not just that, but it was the decision we made as a WG, and why the 
requirements say "The configuration protocol MUST specify how configuration 
errors are handled.” - right?



 Second, in order to rollback, there needs to be a configuration that
 can be safely rolled back into. The only robust way I can imagine to
 implement this rollback requirement is to use locks until the whole
 new config has been applied, thereby turning an asynchronous system
 into a synchronous system. Otherwise, I fail to see how I can ensure
 that I have a configuration that can be safely rolled back into.
>>> Locks are the simplest way of implementing this, but I agree that they
>>> defeat the point of async configuration updates.
>>>
>>> I don't think that locking is the only way to solve this.  I would have
>>> thought that one of the optimistic transactional locking approaches
>>> could be used to process multiple requests concurrently.
>> As long as it is clear to which configuration to roll back to. Once
>> you process multiple requests concurrently, this is not at all clear,
>> at least not to me.
>Logically, the system must revert to a state where the failed 
>configuration request was never applied.  I think this is the only 
>guarantee that is being made to the client.
>
>One way to achieve this would be rollback the configuration (intended 
>and applied) back to exactly the point before that failed request (or 
>any other request) was processed.
>
>Any concurrent configuration requests that were previously in progress 
>would then need to be re-applied one by one (in the same order).  

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

[Kent Watsen]

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 to return both (as oppose to the 
>>>transform)?
>What I see is from draft-ietf-netmod-opstate-reqs
>
>   C.  Be able to retrieve both the applied configuration and
>   derived state aspects of operational state together

Maybe I’m turned around, but I thought this was about returning both intended 
and applied configurations together at the same time, which I didn’t know was a 
requirement.   Certainly returning applied config + derived state (e.g., all op 
state) is a requirement, as you cite above.


>I see the original OpenConfig doc/approach as supporting this (returning
>both sets) but not stating this as an explicit requirement.  I do think
>I've heard such usage in discussions too.

Yes, actually, they returned all three sets of data (intended config, applied 
config, and derived state)


>>  Just wondering if this is a must-have or a nice-to-have.
>I think this is one for Anees/Rob...

It would be good to get that clarification.   I wonder if it might be 
considered  errata  ;)


Kent



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

Re: [netmod] OpState Solution Options

[Kent Watsen]

[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, February 8, 2016 at 3:58 PM
To: Lou Berger >
Cc: Martin Bjorklund >, Juergen 
Schoenwaelder 
>,
 
"draft-openconfig-netmod-opst...@ietf.org"
 
>,
 
"draft-kwatsen-netmod-opst...@ietf.org"
 
>,
 "netmod@ietf.org" 
>
Subject: Re: [netmod] OpState Solution Options

Hi,

It should be up to the co-chairs to make consensus calls.
The IETF 94 minutes indicate that "solution 2" (RPC-based)
had consensus in the room.

https://tools.ietf.org/wg/netmod/minutes?item=minutes-94-netmod.html

I have not seen any evidence that room consensus has changed on the mailing 
list.


Andy



On Mon, Feb 8, 2016 at 12:48 PM, Lou Berger 
> wrote:
[retry]

Martin,


On 2/8/2016 3:42 PM, Martin Bjorklund wrote:
> Lou Berger > wrote:
>> Martin,
>> Thanks for the response.  See below.
>>
>> On 2/8/2016 1:57 PM, Martin Bjorklund wrote:
>>> Hi,
>>>
>>> Lou Berger > wrote:
> [...]
>
 But it's
 also clear that some in the WG would prefer Option 2 (and most/all of
 these are its coauthors.)
>>> This was the preferred solution of the room in Yokohama.  2 of the 4
>>> authors were present.
>> sure.  And we know that the IETF consensus is not judged by who is in
>> the room.  It is of course useful information to the WG and the chairs.
> You wrote "most/all of [those who prefer option 2] are its coauthors".
I was referring to the on-list discussion, but fair point.  But keep in
mind that an in-person meeting isn't an authoritative source of WG
consensus from the IETF process standpoint.

> My observation was that just 2 of the coauthors were in the room, and
> still this was the preferred solution; thus I think that your
> statement that I quoted is incorrect.
>
okay, let me modify my comment:
OLD
and most/all of these are its coauthors
NEW
at very least its coauthors

Lou

> /martin
>



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

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

[Kent Watsen]

>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
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

Okay, I set up a doodle poll to help us pick a time:

http://doodle.com/poll/dv68psxn33yt4ehf

Would the draft authors and other key participants please fill in their 
availability?

Thanks,
Kent




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]
>> 
>> 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 way, and now Lou has 
>> an updated draft.  
>> 
>> The chairs discussed maybe scheduling one for a couple weeks from now, 
>> perhaps Thursday Feb 18 starting at 10am EST?   I'm thinking
>
>Thursday at this time doesn't suit me very well, Monday till Wednesday of that 
>week are OK.
>
>Lada
>
>>  about this slot only since it worked for us for previously.  Is this a good 
>> time slot?  I assume to schedule for 2 hours, with a plan to end early if 
>> needed - makes sense? We also need to put together a proper agenda, 
>> perhaps the following?
>> 
>>  10 min: RTG DT YANG Arch team use-case summary
>>  20 min: draft-rtgyangdt-rtgwg-device-model
>>  20 min: draft-lhotka-netmod-ysdl
>>  20 min: draft-bjorklund-netmod-structural-mount
>>  50 min: general discussion or end early
>> 
>> 
>> We hope to schedule the meeting itself tomorrow or the next day, so please 
>> respond quickly to this email if possible.
>> 
>> Thanks,
>> Kent and Tom
>> 
>> 
>> 
>> 
>> On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger" 
>> <netmod-boun...@ietf.org on behalf of lber...@labn.net> wrote:
>> 
>>> 
>>> I thought it would be worth summarizing what we're looking for in our
>>> draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version in case
>>> you missed it) with respect to the draft-lhotka-netmod-ysdl and
>>> draft-bjorklund-netmod-structural-mount drafts. This is just my view, so
>>> my co-authors may wish to chime in and correct me.
>>> 
>>> I'd be interested in hearing from the authors of YSDL and
>>> structural-mount, or anyone else for that matter, on how they see to
>>> best meet these needs.
>>> 
>>> Here's what I think our draft needs:
>>> 
>>> 1. that there be a mechanism that allows the incorporation (or
>>>  'mounting') of the data model defined by one top-level module
>>>  within another module.
>>> 
>>>  The implication here is that when information is instantiated
>>>  for the parent model it is also instantiated for the
>>>  incorporated/mounted model. In our case we expect to do this on
>>>  list element creation. Both solutions drafts cover the path
>>>  implications, so these are not repeated here.
>>> 
>>> 2. that this mechanism allow identification of specific modules to
>>>  be incorporated/mounted at time of module definition, i.e. that
>>>  no additional module is needed to support 1. This doesn't
>>>  preclude definition of such a module.
>>> 
>>> 3. that this mechanism allow for a server to control (and
>>>  identify) which modules are incorporated/mounted. (see Section
>>>  3 LNE in our draft for an envisioned usage.)
>>> 
>>> 4. that all capabilities that exist with the mounted module are
>>>  available e.g. RPC operations and notifications.
>>> 
>>> 5. while our primary requirement is for 'mounting' of top level
>>>  modules, mounting of submodules may also be useful. (DT not draft
>>>  driven.)
>>> 
>>> We make use of the above in sections 3 and 4 of rtgwg-device-model.  We
>>> see having a solution as critical for the simplifications/flexibility
>>> represented in the -02 version of our draft vs the -03 rev.  We don't
>>> see wither solution draft as significantly different and just hope for a
>>> standard solution as soon as possible.  (a draft-ietf-netmod solutions
>>> draft on the topic by BA would be fantastic given the impact on routing
>>> area -- even if it had to document two variations / alternative solutions.)
>>> 
>>> Again, this is just my opinion and my coauthors or others on the rtg
>>> area yang DT may choose to chime in.
>>> 
>>> Lou
>>> 
>>> 
>>> 
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

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 example, this 
choice statement:

 choice interface-type {
   case ethernet {
 uses ethernet;
   }
   case optical {
 uses optical;
   }
 }

Cannot use shorthand notation:

 choice interface-type {
   uses ethernet;
   uses optical;
 }


This seems like a bug to me.   Is it too late to fix in 6020bis as an issue 
raised by WGLC?

Kent  // as a contributor


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

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

[Kent Watsen]

No problem, I just created another poll for the following week:

http://doodle.com/poll/byugp4umy2m4fwdz

The first poll is now deleted.  For the couple of folks that put values there, 
please fill in your values again on this new poll.

Kent





On 2/3/16, 6:59 AM, "Acee Lindem (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]
>>> 
>>> 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 way,
>>>and now Lou has an updated draft.
>>> 
>>> The chairs discussed maybe scheduling one for a couple weeks from now,
>>>perhaps Thursday Feb 18 starting at 10am EST?   I'm thinking
>>
>>Thursday at this time doesn't suit me very well, Monday till Wednesday of
>>that week are OK.
>
>I’m out the entire week of Feb 14th.
>
>Thanks,
>Acee 
>
>
>>
>>Lada
>>
>>>  about this slot only since it worked for us for previously.  Is this a
>>>good time slot?  I assume to schedule for 2 hours, with a plan to end
>>>early if needed - makes sense? We also need to put together a proper
>>>agenda, perhaps the following?
>>> 
>>>  10 min: RTG DT YANG Arch team use-case summary
>>>  20 min: draft-rtgyangdt-rtgwg-device-model
>>>  20 min: draft-lhotka-netmod-ysdl
>>>  20 min: draft-bjorklund-netmod-structural-mount
>>>  50 min: general discussion or end early
>>> 
>>> 
>>> We hope to schedule the meeting itself tomorrow or the next day, so
>>>please respond quickly to this email if possible.
>>> 
>>> Thanks,
>>> Kent and Tom
>>> 
>>> 
>>> 
>>> 
>>> On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger"
>>><netmod-boun...@ietf.org on behalf of lber...@labn.net> wrote:
>>> 
>>>> 
>>>> I thought it would be worth summarizing what we're looking for in our
>>>> draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version in case
>>>> you missed it) with respect to the draft-lhotka-netmod-ysdl and
>>>> draft-bjorklund-netmod-structural-mount drafts. This is just my view,
>>>>so
>>>> my co-authors may wish to chime in and correct me.
>>>> 
>>>> I'd be interested in hearing from the authors of YSDL and
>>>> structural-mount, or anyone else for that matter, on how they see to
>>>> best meet these needs.
>>>> 
>>>> Here's what I think our draft needs:
>>>> 
>>>> 1. that there be a mechanism that allows the incorporation (or
>>>>  'mounting') of the data model defined by one top-level module
>>>>  within another module.
>>>> 
>>>>  The implication here is that when information is instantiated
>>>>  for the parent model it is also instantiated for the
>>>>  incorporated/mounted model. In our case we expect to do this on
>>>>  list element creation. Both solutions drafts cover the path
>>>>  implications, so these are not repeated here.
>>>> 
>>>> 2. that this mechanism allow identification of specific modules to
>>>>  be incorporated/mounted at time of module definition, i.e. that
>>>>  no additional module is needed to support 1. This doesn't
>>>>  preclude definition of such a module.
>>>> 
>>>> 3. that this mechanism allow for a server to control (and
>>>>  identify) which modules are incorporated/mounted. (see Section
>>>>  3 LNE in our draft for an envisioned usage.)
>>>> 
>>>> 4. that all capabilities that exist with the mounted module are
>>>>  available e.g. RPC operations and notifications.
>>>> 
>>>> 5. while our primary requirement is for 'mounting' of top level
>>>>  modules, mounting of submodules may also be useful. (DT not draft
>>>>  driven.)
>>>> 
>>>> We make use of the above in sections 3 and 4 of rtgwg-device-model.  We
>>>> see having a solution as critical for the simplifications/flexibility
>>>> represented in the -02 version of our draft vs the -03 rev.  We don't
>>>> see wither solution draft as significantly different and just hope for
>>>>a
>>>> standard solution as soon as possible.  (a draft-ietf-netmod solutions
>>>> draft on the topic by BA would be fantastic given the impact on routing
>>>> area -- even if it had to document two variations / alternative
>>>>solutions.)
>>>> 
>>>> Again, this is just my opinion and my coauthors or others on the rtg
>>>> area yang DT may choose to chime in.
>>>> 
>>>> Lou
>>>> 
>>>> 
>>>> 
>>>> ___
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>--
>>Ladislav Lhotka, CZ.NIC Labs
>>PGP Key ID: E74E8C0C
>>
>>
>>
>>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

[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 way, and now Lou has an 
updated draft.  

The chairs discussed maybe scheduling one for a couple weeks from now, perhaps 
Thursday Feb 18 starting at 10am EST?   I'm thinking about this slot only since 
it worked for us for previously.  Is this a good time slot?  I assume to 
schedule for 2 hours, with a plan to end early if needed - makes sense? We 
also need to put together a proper agenda, perhaps the following?

  10 min: RTG DT YANG Arch team use-case summary
  20 min: draft-rtgyangdt-rtgwg-device-model
  20 min: draft-lhotka-netmod-ysdl
  20 min: draft-bjorklund-netmod-structural-mount
  50 min: general discussion or end early


We hope to schedule the meeting itself tomorrow or the next day, so please 
respond quickly to this email if possible.

Thanks,
Kent and Tom




On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger"  wrote:

>
>I thought it would be worth summarizing what we're looking for in our
>draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version in case
>you missed it) with respect to the draft-lhotka-netmod-ysdl and
>draft-bjorklund-netmod-structural-mount drafts. This is just my view, so
>my co-authors may wish to chime in and correct me.
>
>I'd be interested in hearing from the authors of YSDL and
>structural-mount, or anyone else for that matter, on how they see to
>best meet these needs.
>
>Here's what I think our draft needs:
>
>1. that there be a mechanism that allows the incorporation (or
>   'mounting') of the data model defined by one top-level module
>   within another module.
>
>   The implication here is that when information is instantiated
>   for the parent model it is also instantiated for the
>   incorporated/mounted model. In our case we expect to do this on
>   list element creation. Both solutions drafts cover the path
>   implications, so these are not repeated here.
>
>2. that this mechanism allow identification of specific modules to
>   be incorporated/mounted at time of module definition, i.e. that
>   no additional module is needed to support 1. This doesn't
>   preclude definition of such a module.
>
>3. that this mechanism allow for a server to control (and
>   identify) which modules are incorporated/mounted. (see Section
>   3 LNE in our draft for an envisioned usage.)
>
>4. that all capabilities that exist with the mounted module are
>   available e.g. RPC operations and notifications.
>
>5. while our primary requirement is for 'mounting' of top level
>   modules, mounting of submodules may also be useful. (DT not draft
>   driven.)
>
>We make use of the above in sections 3 and 4 of rtgwg-device-model.  We
>see having a solution as critical for the simplifications/flexibility
>represented in the -02 version of our draft vs the -03 rev.  We don't
>see wither solution draft as significantly different and just hope for a
>standard solution as soon as possible.  (a draft-ietf-netmod solutions
>draft on the topic by BA would be fantastic given the impact on routing
>area -- even if it had to document two variations / alternative solutions.)
>
>Again, this is just my opinion and my coauthors or others on the rtg
>area yang DT may choose to chime in.
>
>Lou
>
>
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

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 >
Date: Thursday, January 28, 2016 at 10:51 AM
To: "netmod@ietf.org" 
>, Yong Zhu 
>
Subject: [netmod] Question on the output of  rpc-reply for operational 
model?



Hi Work group,


We got some question regarding netconf operation’s rpc-reply output.

For example, we have draft operational model as follows (list AAA contains list 
BBB which contains list CCC):

list AAA {

key "aaa_name";

config false;

leaf aaa_name {

type 
string;

}

leaf aaa_leaf1 {

type 
int32;

}



list BBB {

key 
"bbb_name";

config 
false;

leaf 
bbb_name {


type string;

}

leaf 
bbb_leaf1 {


type uint32;

}



list 
CCC {


key "ccc_name";


config false;


leaf ccc_name {


type string;


}


leaf ccc_leaf1 {


type uint32;


}

} 
//list CCC

} //list BBB

} //list AAA

The netconf request is the following:


[KENT] the request seems to be missing here



























What is the expected ?

[KENT] this depends on what data is configured on the server


More specifically, will CCC’s key (leaf ) be included in rpc-reply? Will 
AAA/BBB’s key (leaf / ) be included in rpc-reply?

[KENT] generally, list keys are returned (e.g., "aaa_name”).  The usage example 
here shows how a list is encoded in XML: 
https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-09#section-7.8.3.1



The following is what I am thinking now. Please comment.







  my AAA name //???



my BBB name //???



  my CCC name //???

  my ccc leaf1 name



[KENT] I don’t understand this at all.









Thanks

/Yong

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

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

[Kent Watsen]

Thank you all who joined today’s virtual interim meeting.

Other than my starting the recording late and rearranging the presentation 
order, I thought that the meeting went really well in that there seems to be a 
lot of support for trying to solve this problem, and because we have a plan to 
try to move towards having a WG document in the BA timeframe.  The plan is for 
draft-bjorklund-netmod-structural-mount to be updated based on the meeting and 
for it to be discussed on list as the basis for the WG effort on the topic.

Attached are the very rough Ethernet minutes captured during the meeting.  
Please review carefully.  Corrections can be made on the etherpad here: 
http://etherpad.tools.ietf.org:9000/p/netmod-interim-20160222  (so we can track 
changes, the end of meeting snapshot is here: 
http://etherpad.tools.ietf.org:9000/p/netmod-interim-20160222/timeslider#3933)

To listen to the recording, please follow one of these two links:

  Streaming recording link:
https://ietf.webex.com/ietf/ldr.php?RCID=4dc88386f13a49fa8f2c934db953f4a2

  Download recording link:
https://ietf.webex.com/ietf/lsr.php?RCID=1b6490fe5cc6fc95d4e3c9b913dfdc1f


Thanks again,

Kent and Lou





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, "netmod on behalf of IESG Secretary" 
><netmod-boun...@ietf.org on behalf of iesg-secret...@ietf.org> wrote:
>
>>The NETCONF Data Modeling Language (NETMOD) WG will have a virtual 
>>interim meeting on 22 February 2016 at 10:00 EST (15:00 UTC) to discuss 
>>use-cases and solutions for combining YANG modules into the schema 
>>defined in other YANG modules, as this is a blocking item for some other 
>>working groups currently. The agenda for the meeting is:
>>
>>5 min: agenda bashing, scribes, note well, etherpad, etc.
>>20 min: use-case summary (draft-rtgyangdt-rtgwg-device-model-02)
>>20 min: proposal #1 (draft-lhotka-netmod-ysdl-00)
>>20 min: proposal #2 (draft-bjorklund-netmod-structural-mount-00)
>>55 min: general discussion or end early
>>
>>All participants should come prepared to discuss these drafts.
>>
>>Note: it is understood that draft-clemm-netmod-mount is related work, 
>>but the chairs wish to only focus on the schema composition issue at 
>>this time.
>>
>>Etherpad: http://etherpad.tools.ietf.org:9000/p/netmod-interim-20160222
>>
>>Regards,
>>
>>NETMOD Chairs
>>
>>--
>>NETMOD Virtual Interim Meeting
>>Monday, February 22, 2016
>>4:00 pm | Europe Time (Berlin, GMT+01:00) | 2 hrs
>>
>>Join WebEx meeting:
>>https://ietf.webex.com/ietf/j.php?MTID=me171803d3dfe83d3f0d003f8332b032f
>>Meeting number: 646 684 956
>>Meeting password: Qbds3nPZ
>>
>>Join by phone
>>1-877-668-4493 Call-in toll free number (US/Canada)
>>1-650-479-3208 Call-in toll number (US/Canada)
>>Access code: 646 684 956
>>Toll-free calling restrictions
>>
>>Add this meeting to your calendar. (Cannot add from mobile devices.)
>>https://ietf.webex.com/ietf/j.php?MTID=mf4e7a67f2b45f6542947fa3464d35e05
>>
>>Can't join the meeting? Contact support.
>>
>>IMPORTANT NOTICE: Please note that this WebEx service allows audio and 
>>other information sent during the session to be recorded, which may be 
>>discoverable in a legal matter. By joining this session, you 
>>automatically consent to such recordings. If you do not consent to being 
>>recorded, discuss your concerns with the host or do not join the 
>>session. 
>>
>>___
>>netmod mailing list
>>netmod@ietf.org
>>https://www.ietf.org/mailman/listinfo/netmod
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod
[Please add your name to the virtual blue sheet at the end, and notes inline in 
the appropriate Notes block.]

IETF NETMOD Virtual Interim Meeting
Feb 22, 2016

Online Agenda and Slides at: 
https://www.ietf.org/proceedings/interim/2016/02/22/netmod/proceedings.html
Data tracker: http://datatracker.ietf.org/wg/netmod/
Tools page: http://tools.ietf.org/wg/netmod

Agenda:

   5 min: agenda bashing, scribes, note well, etherpad, etc.
  20 min: use-case summary (draft-rtgyangdt-rtgwg-device-model-02)
  20 min: proposal #1  (draft-lhotka-netmod-ysdl-00)
  20 min: proposal #2  (draft-bjorklund-netmod-structural-mount-00)
  55 min: general discussion or end early

Attendees:

  - Kent Watsen
  Lou Berger
  Christian Hopps
  Einar Nilsen

[netmod] working group secretary position

[Kent Watsen]

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 ensuring that they identify someone to produce it 
for them)

* ensuring data tracker matches the discussion on the list , eg, adoption polls 
and IPR checks.

* consolidating meeting slot requests and meeting presentations

* ensuring  agendas, presentations, minutes, are posted  to Materials Manager

Being a working group secretary not only helps out the chairs and the working 
group, but it's also generally viewed as a good way to get experience for those 
interested in becoming a Working Group Chair at some point in the future.

If you are interested in serving this function for netmod, please let the 
chairs know within the next two weeks. (If you reply to this mail there is no 
need to CC the mailing list.)


Thank you,

Netmod Chairs


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

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

[Kent Watsen]

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 22 February 2016 at 10:00 EST (15:00 UTC) to discuss 
>use-cases and solutions for combining YANG modules into the schema 
>defined in other YANG modules, as this is a blocking item for some other 
>working groups currently. The agenda for the meeting is:
>
>5 min: agenda bashing, scribes, note well, etherpad, etc.
>20 min: use-case summary (draft-rtgyangdt-rtgwg-device-model-02)
>20 min: proposal #1 (draft-lhotka-netmod-ysdl-00)
>20 min: proposal #2 (draft-bjorklund-netmod-structural-mount-00)
>55 min: general discussion or end early
>
>All participants should come prepared to discuss these drafts.
>
>Note: it is understood that draft-clemm-netmod-mount is related work, 
>but the chairs wish to only focus on the schema composition issue at 
>this time.
>
>Etherpad: http://etherpad.tools.ietf.org:9000/p/netmod-interim-20160222
>
>Regards,
>
>NETMOD Chairs
>
>--
>NETMOD Virtual Interim Meeting
>Monday, February 22, 2016
>4:00 pm | Europe Time (Berlin, GMT+01:00) | 2 hrs
>
>Join WebEx meeting:
>https://ietf.webex.com/ietf/j.php?MTID=me171803d3dfe83d3f0d003f8332b032f
>Meeting number: 646 684 956
>Meeting password: Qbds3nPZ
>
>Join by phone
>1-877-668-4493 Call-in toll free number (US/Canada)
>1-650-479-3208 Call-in toll number (US/Canada)
>Access code: 646 684 956
>Toll-free calling restrictions
>
>Add this meeting to your calendar. (Cannot add from mobile devices.)
>https://ietf.webex.com/ietf/j.php?MTID=mf4e7a67f2b45f6542947fa3464d35e05
>
>Can't join the meeting? Contact support.
>
>IMPORTANT NOTICE: Please note that this WebEx service allows audio and 
>other information sent during the session to be recorded, which may be 
>discoverable in a legal matter. By joining this session, you 
>automatically consent to such recordings. If you do not consent to being 
>recorded, discuss your concerns with the host or do not join the 
>session. 
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft

[Kent Watsen]

The chairs were just reviewing notes and realized that this thread never closed 
properly.

Juergen has some concerns regarding realistic milestones, that were never 
addressed.  Robert, can you please try to address Juergen’s concerns now?

Also, there were only a two responses before indicating 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...@juniper.net<mailto:kwat...@juniper.net>>
Date: Tuesday, December 15, 2015 at 11:48 AM
To: "netmod@ietf.org<mailto:netmod@ietf.org>" 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang 
as NETMOD WG draft


The minutes for IETF 94 show that there was in-room support for adopting 
draft-wilton-netmod-intf-ext-yang as a WG draft.   The minutes also show that 
this decision would be confirmed on the mailing list, which I am doing now.

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 
Tuesday, December 22, 2015 at 9AM EST at which time the WG Chairs will gauge 
whether or not there is consensus to move forward with the document.

Thanks,
Kent


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

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

[Kent Watsen]

My mistake, I simply copied that text from the referenced email without 
thinking about changing that text.  It would’ve helped if the template I used 
replaced “WG Last Call” with “WG ”.  

Lou, have you posted the template anywhere yet?

Thanks,
Kent






On 3/16/16, 3:37 PM, "Martin Bjorklund" <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 <kwat...@juniper.net> wrote:
>> [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, I'm not aware of any IPR that applies to this draft"
>> or
>> "Yes, I'm aware of IPR that applies to this draft"
>> 
>> If so, has this IPR been disclosed in compliance with IETF IPR rules
>> (see RFCs 3979, 4879, 3669 and 5378 for more details)?  If yes to the above, 
>> please state either:
>> 
>> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
>> or
>> "No, the IPR has not been disclosed"
>> 
>> If you answer no, please provide any additional details you think
>> appropriate.
>> 
>> If you are listed as a document author or contributor please answer the 
>> above by responding to this email regardless of whether or not you are aware 
>> of any relevant IPR. This document will not advance to the next stage until 
>> a response has been received from each author and listed contributor. NOTE: 
>> THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE’S TO LINES.
>> 
>> If you are on the WG email list or attend WG meetings but are not listed as 
>> an author or contributor, we remind you of your obligations under the IETF 
>> IPR rules which encourages you to notify the IETF if you are aware of IPR of 
>> others on an IETF contribution, or to refrain from participating in any 
>> contribution or discussion related to your undisclosed IPR. For more 
>> information, please see the RFCs listed above and 
>> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
>> 
>> Thank you,
>> NETMOD WG Chairs
>> 
>> PS Please include all listed in the headers of this message in your response.
>> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] yang-next

[Kent Watsen]

>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 ensure that any issues 
posted in the interim are suitably captured; that what’s being asked for is 
clearly understood.   Of course, we could at a later point in time reach out to 
the github userid to ask for a clarification and, in the case of no response, 
either do our best or drop it.  To me, it is sufficient to just capture the 
ideas, with no discussion happening until later and then, of course, they would 
be on the ML.

Thanks,
Kent

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