Re: [netmod] Regarding IPR on draft-openconfig-netmod-model-catalog

[Anees Shaikh]

Thanks Lou.

Regarding draft-openconfig-netmod-model-catalog:  No, I'm not aware of any
IPR that applies to this draft .

-- Anees

On Fri, Apr 14, 2017 at 2:23 PM, Lou Berger  wrote:

>
> Authors, Contributors, WG,
>
> As part of preparation for WG Adoption
>
> Are you aware of any IPR that applies to drafts 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 1.0 behavior for leafref

[Anees Shaikh]

Isn't there already a verified errata for this same issue with the same
recommendation (Errata ID: 2949) ?

-- Anees

On Tue, Sep 15, 2015 at 3:15 PM, Andy Bierman  wrote:

> Hi,
>
> The leafref text was changed to allow the require-instance-stmt in YANG 1.1
>
> RFC 6020, sec. 9.9. is quite clear that this sub-statement is not allowed.
>
> 9.9.1.  Restrictions
>
>A leafref cannot be restricted.
>
> 9.13.1.  Restrictions
>
>An instance-identifier can be restricted with the "require-instance"
>statement (Section 9.13.2).
>
>
> However, the ABNF on page 149 clearly contradicts the text in 9.9.1:
>
>   leafref-specification =
>  ;; these stmts can appear in any order
>  path-stmt stmtsep
>  [require-instance-stmt stmtsep]
>
>path-stmt   = path-keyword sep path-arg-str stmtend
>
>require-instance-stmt = require-instance-keyword sep
> require-instance-arg-str stmtend
>
>
>
> So which normative text is correct?
> Is instance-required-stmt allowing in YANG 1.0?
>
>
> Andy
>
>
> ___
> 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

[Anees Shaikh]

Benoit, I think Rob and others have already addressed the first issue
raised in the comments from your group.  For the second point, your mail
says that the OpenConfig opstate draft says:

 *   "The proposal does not allow items that are not configured, configured
but not present, or system configured."*

*Please note that this is a general note that would apply to the language
itself. Meaning that YANG will no longer be able to describe situations
like the above for any type of application in any context.*

While the draft does say this, you've unfortunately misunderstood the point
being made in that section (I'll have to accept some responsibility for
writing it this way).  The preface to Section 7 says, "A number of issues
have been raised with the proposed solution ..." and point #3 is just
stating the issue that was raised with regard to our proposal -- if you
read the rest of the explanation in #3, it describes an example of how the
solution can address these situations, using a specific example of
configuring 'all' interfaces , some of which may not be present.
Similarly, if an implementation supports pre-configuration of interfaces,
for example, the intended configuration reflects that preconfiguration,
while the corresponding state would show that it is applied but also that
oper-status = 'NOT PRESENT'

So I would say that your point about the solution limiting expressivity
that is otherwise allowed by the language is based on a misreading of the
section.  Other points in Section 7 also first relate the issue raised,
followed by our response regarding how it can be addressed.

thanks.
-- Anees


On Thu, Sep 10, 2015 at 1:40 AM, Benoit Claise  wrote:

> Dear all,
>
> The YANG coordination team
> 
> has spent some time reading and gathering input on the requirements and
> proposed solutions in draft-openconfig-netmod-opstate. This note is to
> collect some observations that will hopefully contribute to progress in the
> working group.
>
> We believe it is useful to consider that YANG was initially designed to be
> a data modeling language for the NETCONF protocol. IETF is also working on
> RESTCONF which is an HTTP-based protocol to access data defined in YANG,
> using the datastores defined in NETCONF.
>
> YANG is fulfilling its intended role with NETCONF and RESTCONF and has
> gained some significant traction in this capacity. There are some changes
> worked on in YANG 1.1, but they are mostly incremental.
>
> There is interest in using other protocols outside of NETCONF and RESTCONF
> to manipulate data described by YANG. The proposals in the draft is based
> on the assertion that YANG models should be usable for protocols beyond
> RESTCONF and NETCONF. So these are new requirements on YANG from, or in
> preparation for, new protocol bindings.
>
> We have focused on two main aspects of the draft.
>
> FIRSTLY: The proposed split between intended and applied configuration as
> described in sections 4.1 (requirements) and 5.1 (implications)
>
> There are two observations here:
> 1. The implication is that all configurable data nodes ("intended
> configuration") shall be repeated in an operational version ("applied
> configuration") in all models for all applications going forward. This
> would apply independent of if the system is synchronous or asynchronous in
> nature. Synchronous systems would simply hard-wire the applied
> configuration to be the same as intended configuration at all times.
> 2. An informal round of conversations with some vendors as well as some
> tooling vendors show that there are currently no widely known platforms
> that allow for observing the intended and applied state separately. A
> common architecture includes a central configuration data store that is
> being updated by the manageability framework and updates read by the
> subsystems affected by the change (e.g. the BGP service or the interface
> manager). In this case, there is no other source of configuration except
> for the content of the data store.
>
> Please note that this was not an exhaustive collection of data, but should
> give some directional information.
>
> The *implication* we would like to make here is that by making this
> feature mandatory part of the YANG language itself (as opposed to an
> optional capability) we risk introducing a fake perception that the current
> NETCONF server supports a capability it can't support. Indeed, polling the
> applied configuration would always return the intended configuration.
>
> A *question* would be if it would be useful to consider a direction where
> we make an attempt to separate out requirements that are tied to specific
> protocols and solve them in the protocol semantics rather than in the
> language to the extent we can. Without knowing more about the intended
> protocol in the case of this draft, it is hard to make more progress.
>
> A *suggestion* is to ask the 

Re: [netmod] Open Config Options

[Anees Shaikh]

We've posted a new version of our draft:
https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01

It includes a section on the issues that were raised and our
observation/comment.  It also adds a detailed section on terminology based
on the interim calls, and updates the operational requirements with further
details.

thanks.
-- Anees


On Mon, Jul 6, 2015 at 12:59 PM, Martin Bjorklund m...@tail-f.com wrote:

 Hi,

 Nadeau Thomas tnad...@lucidvision.com wrote:
 
One of the actions from the last Interim meeting was to have both
sides of the issues around the open config approach to create at
 least
slides/textual bullet points for use during our discussion in
 Praha so
we can come to a conclusion around the final issues.  We need these
slides/bullet points to be listed on the list here and continue the
discussion here BEFORE the Praha meeting.  I’d like to ask Anees
 and
Rob to write up their side of the story.  As I recall Juergen,
 Kent,
Martin and Andy were the most vocal around the other side of
 things,
so I would like to ask them to write up their side of things.  Can
 you
all please confirm your acceptance of this action and a target for
when you will post the issues?

 We have posted our thoughts in this draft:
 https://tools.ietf.org/html/draft-bjorklund-netmod-openconfig-reply-00


 /martin

 ___
 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