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] module update rules

[Ladislav Lhotka]

> On 22 Dec 2015, at 16:53, Juergen Schoenwaelder 
>  wrote:
> 
> On Tue, Dec 22, 2015 at 04:23:44PM +0100, Ladislav Lhotka wrote:
>> 
>>> On 22 Dec 2015, at 16:06, Juergen Schoenwaelder 
>>>  wrote:
>>> 
>>> On Tue, Dec 22, 2015 at 11:34:41AM +0100, Ladislav Lhotka wrote:
 
> On 22 Dec 2015, at 11:06, Juergen Schoenwaelder 
>  wrote:
> 
> On Mon, Dec 21, 2015 at 08:09:13PM +0100, Ladislav Lhotka wrote:
>> 
>>> 
>>> That's why the definition what 'published' means in the IETF is in the
>>> guidelines document. On the other hand, since this is an IETF
>>> document, I also do not find it problematic to define IETF rules
>>> here. Others should be able to skip over this. There are really more
>>> important problems to solve.
>> 
>> It is not clear at all from sec. 10 that data modellers outside IETF may 
>> skip over this. I am not even sure that everybody in this WG agrees with 
>> your interpretation.
>> 
> 
> You are wrong.
> 
> - Section 10 in RFC 6020 applies to all published modules.
 
 The bullets specifying the rules are introduced with this sentence:
 
 'A definition may be revised in any of the following ways:'
 
 so IMO it is intended to apply to *all* modules. Are you saying that it 
 actually means
 
 'A definition in a module published by IETF may be revised in any of the 
 following ways:'?
 
>>> 
>>> A definition in a published module may be revised [...]
>>> 
> - The definition of what turns a module into a published module is
> specific to the different organizations publishing modules.
 
 So it means that such an organization may also decide to ignore the rules 
 entirely or replace them with its own rules.
 
>>> 
>>> No.
>>> 
 If the WG can agree on this and make the corresponding changes in sec. 11 
 of 6020bis, then I have no more objections.
>>> 
>>> The rules are there to ensure interoperability. Interoperability is an
>>> issue for published modules (but not for modules under development).
>> 
>> This doesn't make much sense unless you give an objective definition of 
>> "published". For example, are proprietary modules (developed by vendors) 
>> ever published?
>> 
> 
> This has to be late binding - an organization publishing modules will
> have to define what 'publishing' means for them and they will have to
> decide whether they publish anything at all.

Right. Should there ever be any malcontents who are not happy with those rules, 
here is a recipe: they can provide the modules to their customers instead of 
publishing them. And W3C could just recommend their modules.

Lada

> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

[Robert Wilton]

HI Andy,

On 22/12/2015 20:37, Andy Bierman wrote:



On Tue, Dec 22, 2015 at 12:31 PM, Robert Wilton 
mailto:robert.pub...@wilton.org.uk>> wrote:


Hi Gert,

On 21/12/2015 20:17, Gert Grammel wrote:

Hi Rob,

Seems we are pretty close with our understanding, so snipping the
only discussion point left, with further comments:

Gert




The real problem is what you called in another
email  'hybrid' or cheating-synchronous implementations. This
leads to a situation where the client is made to believe the
intended config is applied, but the server still didn't apply
it yet. Take the case where the server runs into trouble
after the synchronous-commit (which lets the client believe
that the intended config is applied) and decides to
roll-back. From a client perspective this would look like a
node randomly losing its committed configuration. There is
tons of code required on the client side to cope with that
situation. So what was the purpose of implementing it that
way in the first place - instead of just applying an
asynchronous implementation?

Yes, I agree that handling rollback could be a problem in this
scenario,
and hence I would propose that the behaviour in such a scenario is
explicitly documented as being undefined in whatever solution is
agreed
upon :-)
Gert> sadly, we can’t roll time back. So the best option is
indeed to document the issue and move on to improve things

Otherwise assuming that all requests are strictly synchronous or
asynchronous then I think that we should be OK with the following
two
rules on the server:

 1. All edit-config requests must strictly be processed in order.

Gert> yes, although there are corner cases we need to hash out. 
I.e. a client may set  a leaf to  followed by setting it to

. Then a server may skip setting it to , because it is
anyhow overwritten by .


Yes, it might, but from a correctness point of view it will need
to able to fail the subsequent request to set the value to  and
hence set it to  instead.




What does "processed in order" mean?
NETCONF has a requirement that  requests on a specific session
are processed in the order received.  There is no such requirement
across multiple sessions doing edits at once.


Thanks for the clarification.  I hope that whatever NETCONF does here 
should be a sufficient solution.  I.e. as long as the error handling 
semantics can be well defined with the request ordering just defined 
relative to particular sessions then that is fine with me.  I think that 
it would only be necessary to refine/modify the NETCONF behaviour if it 
is shown to be insufficiently specified to be robustly implementable, 
and I'm not aware of that being the case.


Otherwise, I think that this discussion can probably be deferred until 
we are discussing the specific solution draft.


As an aside - I also see this as another example where it would be 
useful to define the common semantics and expectations of a YANG 
manageability protocol outside of NETCONF and RESTCONF.


Thanks,
Rob





Andy





2) You cannot tell a client that a request has been full applied
unless
all previous requests specifying rollback-on-error semantics with
any
overlapping nodes with the current request have either be applied or
aborted (i.e. rolled back)

Gert> with “have bee full applied” you meant a state that I
tentatively named ‘validated’  in my earlier email?  I am a bit
sensitive to naming here because of those ‘cheating synchronous
nodes’ would return ‘applied’ without actually doing so in full.
It would be great if we could quickly converge on some naming
convention to remove ambiguity.


Yes, it means the same state as your 'validated'.  I basically
just mean that the synchronous operation has completed (as per the
definition of 'Synchronous Configuration Operation' defined in
draft-ietf-netmod-opstate-reqs-01).





The rule holds true but I don’t see a dependency on
“rollback-on-error” semantics. In my view it is applicable also
in cases of "continue-on-error” and “stop-on-error” in the sense
that unless any error has been reported, the client still needs
to wait for the ‘validated’ state before it can reliably assume
the config was applied.

I would see that a "continue-on-error" configuration operation is
processed best effort.  I.e. even if applying one of more config
nodes failed to be applied, the rest of the configuration
contained in a best effort operation would always be applied.  As
such subsequent operations would not need to wait for a best
effort request to complete first before they can complete.

Thanks,
Rob






From: Robert Wilton mailto:rwil...@cisco.com>>
Date: Monday 21 December 2015 19:55

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

[Andy Bierman]

On Tue, Dec 22, 2015 at 12:31 PM, Robert Wilton  wrote:

> Hi Gert,
>
> On 21/12/2015 20:17, Gert Grammel wrote:
>
> Hi Rob,
>
> Seems we are pretty close with our understanding, so snipping the only
> discussion point left, with further comments:
>
> Gert
>
>
> 
>
> The real problem is what you called in another email  'hybrid' or
> cheating-synchronous implementations. This leads to a situation where the
> client is made to believe the intended config is applied, but the server
> still didn't apply it yet. Take the case where the server runs into trouble
> after the synchronous-commit (which lets the client believe that the
> intended config is applied) and decides to roll-back. From a client
> perspective this would look like a node randomly losing its committed
> configuration. There is tons of code required on the client side to cope
> with that situation. So what was the purpose of implementing it that way in
> the first place - instead of just applying an asynchronous implementation?
>
> Yes, I agree that handling rollback could be a problem in this scenario,
> and hence I would propose that the behaviour in such a scenario is
> explicitly documented as being undefined in whatever solution is agreed
> upon :-)
> Gert> sadly, we can’t roll time back. So the best option is indeed to
> document the issue and move on to improve things
>
> Otherwise assuming that all requests are strictly synchronous or
> asynchronous then I think that we should be OK with the following two
> rules on the server:
>
>1. All edit-config requests must strictly be processed in order.
>
> Gert> yes, although there are corner cases we need to hash out.  I.e. a
> client may set  a leaf to  followed by setting it to . Then a server
> may skip setting it to , because it is anyhow overwritten by .
>
>
> Yes, it might, but from a correctness point of view it will need to able
> to fail the subsequent request to set the value to  and hence set it to
>  instead.
>
>


What does "processed in order" mean?
NETCONF has a requirement that  requests on a specific session
are processed in the order received.  There is no such requirement
across multiple sessions doing edits at once.


Andy




>
>
> 2) You cannot tell a client that a request has been full applied unless
> all previous requests specifying rollback-on-error semantics with any
> overlapping nodes with the current request have either be applied or
> aborted (i.e. rolled back)
>
> Gert> with “have bee full applied” you meant a state that I tentatively
> named ‘validated’  in my earlier email?  I am a bit sensitive to naming
> here because of those ‘cheating synchronous nodes’ would return ‘applied’
> without actually doing so in full. It would be great if we could quickly
> converge on some naming convention to remove ambiguity.
>
>
> Yes, it means the same state as your 'validated'.  I basically just mean
> that the synchronous operation has completed (as per the definition of
> 'Synchronous Configuration Operation' defined in
> draft-ietf-netmod-opstate-reqs-01).
>
>
>
>
> The rule holds true but I don’t see a dependency on “rollback-on-error”
> semantics. In my view it is applicable also in cases of "continue-on-error”
> and “stop-on-error” in the sense that unless any error has been reported,
> the client still needs to wait for the ‘validated’ state before it can
> reliably assume the config was applied.
>
> I would see that a "continue-on-error" configuration operation is
> processed best effort.  I.e. even if applying one of more config nodes
> failed to be applied, the rest of the configuration contained in a best
> effort operation would always be applied.  As such subsequent operations
> would not need to wait for a best effort request to complete first before
> they can complete.
>
> Thanks,
> Rob
>
>
>
> 
>
> From: Robert Wilton 
> Date: Monday 21 December 2015 19:55
> To: Gert Grammel < ggram...@juniper.net>, Jason
> Sterne , "netmod@ietf.org" <
> netmod@ietf.org>
> Subject: Re: [netmod] netmod-opstate-reqs and error option terms
> (rollback on error)
>
> Hi Gert,
>
> Please see inline ...
>
> On 05/11/2015 03:53, Gert Grammel wrote:
>
> Jason,
>
> A synchronous config basically contains two pieces of information in the
> commit:
> 1) the intended configuration is valid (i.e. is syntactically correct) and
> 2) the intended config has been applied
> Any error that would affect the config before the commit could be rolled
> back to the old config and a suitable notification sent to the client.
> After the commit, there is no roll-back.
>
> I agree.
>
> Similarly for asynchronous, however here the information needs to be split
> into two messages:
> 1) a commit that the intended config is valid
> 2) another message when the intended config is fully applied (let's call
> this 'validated').
> A rollback can happen before the intended config is fully applied i.e.
> before the 'validated' state is reached.
>
> I agree.
>
>
> The real problem is what you called in anot

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

[Robert Wilton]

Hi Gert,

On 21/12/2015 20:17, Gert Grammel wrote:

Hi Rob,

Seems we are pretty close with our understanding, so snipping the only 
discussion point left, with further comments:


Gert




The real problem is what you called in another email  'hybrid' or
cheating-synchronous implementations. This leads to a situation
where the client is made to believe the intended config is
applied, but the server still didn't apply it yet. Take the case
where the server runs into trouble after the synchronous-commit
(which lets the client believe that the intended config is
applied) and decides to roll-back. From a client perspective this
would look like a node randomly losing its committed
configuration. There is tons of code required on the client side
to cope with that situation. So what was the purpose of
implementing it that way in the first place - instead of just
applying an asynchronous implementation?

Yes, I agree that handling rollback could be a problem in this scenario,
and hence I would propose that the behaviour in such a scenario is
explicitly documented as being undefined in whatever solution is agreed
upon :-)
Gert> sadly, we can’t roll time back. So the best option is indeed to 
document the issue and move on to improve things


Otherwise assuming that all requests are strictly synchronous or
asynchronous then I think that we should be OK with the following two
rules on the server:

 1. All edit-config requests must strictly be processed in order.

Gert> yes, although there are corner cases we need to hash out.  I.e. 
a client may set  a leaf to  followed by setting it to . Then a 
server may skip setting it to , because it is anyhow overwritten by 
.


Yes, it might, but from a correctness point of view it will need to able 
to fail the subsequent request to set the value to  and hence set it 
to  instead.





2) You cannot tell a client that a request has been full applied unless
all previous requests specifying rollback-on-error semantics with any
overlapping nodes with the current request have either be applied or
aborted (i.e. rolled back)

Gert> with “have bee full applied” you meant a state that I 
tentatively named ‘validated’  in my earlier email?  I am a bit 
sensitive to naming here because of those ‘cheating synchronous nodes’ 
would return ‘applied’ without actually doing so in full. It would be 
great if we could quickly converge on some naming convention to remove 
ambiguity.


Yes, it means the same state as your 'validated'.  I basically just mean 
that the synchronous operation has completed (as per the definition of 
'Synchronous Configuration Operation' defined in 
draft-ietf-netmod-opstate-reqs-01).





The rule holds true but I don’t see a dependency on 
“rollback-on-error” semantics. In my view it is applicable also in 
cases of "continue-on-error” and “stop-on-error” in the sense that 
unless any error has been reported, the client still needs to wait for 
the ‘validated’ state before it can reliably assume the config was 
applied.
I would see that a "continue-on-error" configuration operation is 
processed best effort.  I.e. even if applying one of more config nodes 
failed to be applied, the rest of the configuration contained in a best 
effort operation would always be applied.  As such subsequent operations 
would not need to wait for a best effort request to complete first 
before they can complete.


Thanks,
Rob






From: Robert Wilton mailto:rwil...@cisco.com>>
Date: Monday 21 December 2015 19:55
To: Gert Grammel mailto:ggram...@juniper.net>>, 
Jason Sterne >, "netmod@ietf.org 
" mailto:netmod@ietf.org>>
Subject: Re: [netmod] netmod-opstate-reqs and error option terms 
(rollback on error)


Hi Gert,

Please see inline ...

On 05/11/2015 03:53, Gert Grammel wrote:

Jason,

A synchronous config basically contains two pieces of information
in the commit:
1) the intended configuration is valid (i.e. is syntactically
correct) and
2) the intended config has been applied
Any error that would affect the config before the commit could be
rolled back to the old config and a suitable notification sent to
the client. After the commit, there is no roll-back.

I agree.

Similarly for asynchronous, however here the information needs to
be split into two messages:
1) a commit that the intended config is valid
2) another message when the intended config is fully applied
(let's call this 'validated').
A rollback can happen before the intended config is fully applied
i.e. before the 'validated' state is reached.

I agree.


The real problem is what you called in another email  'hybrid' or
cheating-synchronous implementations. This leads to a situation
where the client is made to believe the intended config is
applied, but the server still didn't apply it yet. Take the case
where the server ru

[netmod] I-D Action: draft-ietf-netmod-syslog-model-06.txt

[internet-drafts]

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   : SYSLOG YANG model
Author  : Clyde Wildes
Filename: draft-ietf-netmod-syslog-model-06.txt
Pages   : 21
Date: 2015-12-22

Abstract:
   This document describes a data model for Syslog
   protocol which is used to convey event notification messages.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-06


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

Re: [netmod] syslog-model-05: terminal logging vs session logging

[Clyde Wildes (cwildes)]

Jason,

We are about to publish draft-ietf-netmod-syslog-06 which separates terminal 
logging from session logging. We appreciate your feedback.

Thanks,

Clyde

From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of "Sterne, Jason (Jason)" 
mailto:jason.ste...@alcatel-lucent.com>>
Date: Wednesday, October 28, 2015 at 11:50 AM
To: "netmod@ietf.org" 
mailto:netmod@ietf.org>>
Subject: [netmod] syslog-model-05: terminal logging vs session logging

Hi all,

One of the syslog destinations in the model is the “terminal” (for all users or 
specific users).

Isn’t logging to a terminal more typically enabled on a CLI *session* basis 
rather than configured against a particular user ?

I believe it is also typical for session logging to stop/disappear when that 
session is ended (i.e. it is not persistent config).

I’m not sure it is typical to have configuration in a device that basically 
instructs the device to enable logging to the terminal for “user x” whenever 
that user later logs in (and if they had multiple login sessions then 
presumably log events would be delivered to each session).

I think session logging is something that is really purely CLI (i.e. 
interactive sessions with human users) and maybe not even applicable to 
configuration via NETCONF (since we’d never want to send a stream of syslog 
events as text to the NETCONF client/session like we do to the terminal for a 
CLI user).

In section 5 of the draft it mentions that syslog:log-actions/terminal maps to 
Cisco NXOS “logging monitor 2”.  I believe that is intended to enable logs to a 
particular *session* (not user).   IOS-XR behavior is similar.  The ALU SR OS 
logging config has the concept of sending (enabling) log events to a particular 
session (but not configured against a user).

Jason



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

Re: [netmod] syslog-model-05: minor editorial comments

[Clyde Wildes (cwildes)]

Jason,

We are about to publish draft-ietf-netmod-syslog-model-06 which incorporates 
your feedback below.

Thanks,

Clyde

From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of "Sterne, Jason (Jason)" 
mailto:jason.ste...@alcatel-lucent.com>>
Date: Wednesday, October 28, 2015 at 11:50 AM
To: "netmod@ietf.org" 
mailto:netmod@ietf.org>>
Subject: [netmod] syslog-model-05: minor editorial comments

A few minor editorial comments on syslog-model-05:

- The introduction says "We are using definitions of Syslog protocol from 
[RFC3164] in this draft." but the YANG model mostly references 5424.
- In section 3 maybe use the term "Remote Collector(s)" instead of Server(s) ? 
Collector seems more in line with RFC5424 (or "Remote Receiver" if others 
prefer that).
- In the Section 3 figure make all the Distributors have a common syntax for 
plural vs singular "Log Buffer(s)", "Log File(s)", "Remote Collector(s)", “User 
Terminal(s)”
- Document is missing the standard legend for the PYANG tree

Jason

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

Re: [netmod] module update rules

[Nadeau Thomas]

thx!

> On Dec 22, 2015:11:55 AM, at 11:55 AM, Andy Bierman  
> wrote:
> 
> 
> 
> On Tue, Dec 22, 2015 at 8:35 AM, Nadeau Thomas  > wrote:
> 
> > On Dec 22, 2015:10:53 AM, at 10:53 AM, Juergen Schoenwaelder 
> >  > > wrote:
> >
> > On Tue, Dec 22, 2015 at 04:23:44PM +0100, Ladislav Lhotka wrote:
> >>
> >>> On 22 Dec 2015, at 16:06, Juergen Schoenwaelder 
> >>>  >>> > wrote:
> >>>
> >>> On Tue, Dec 22, 2015 at 11:34:41AM +0100, Ladislav Lhotka wrote:
> 
> > On 22 Dec 2015, at 11:06, Juergen Schoenwaelder 
> >  > > wrote:
> >
> > On Mon, Dec 21, 2015 at 08:09:13PM +0100, Ladislav Lhotka wrote:
> >>
> >>>
> >>> That's why the definition what 'published' means in the IETF is in the
> >>> guidelines document. On the other hand, since this is an IETF
> >>> document, I also do not find it problematic to define IETF rules
> >>> here. Others should be able to skip over this. There are really more
> >>> important problems to solve.
> >>
> >> It is not clear at all from sec. 10 that data modellers outside IETF 
> >> may skip over this. I am not even sure that everybody in this WG 
> >> agrees with your interpretation.
> >>
> >
> > You are wrong.
> >
> > - Section 10 in RFC 6020 applies to all published modules.
> 
>  The bullets specifying the rules are introduced with this sentence:
> 
>  'A definition may be revised in any of the following ways:'
> 
>  so IMO it is intended to apply to *all* modules. Are you saying that it 
>  actually means
> 
>  'A definition in a module published by IETF may be revised in any of the 
>  following ways:'?
> 
> >>>
> >>> A definition in a published module may be revised [...]
> >>>
> > - The definition of what turns a module into a published module is
> > specific to the different organizations publishing modules.
> 
>  So it means that such an organization may also decide to ignore the 
>  rules entirely or replace them with its own rules.
> 
> >>>
> >>> No.
> >>>
>  If the WG can agree on this and make the corresponding changes in sec. 
>  11 of 6020bis, then I have no more objections.
> >>>
> >>> The rules are there to ensure interoperability. Interoperability is an
> >>> issue for published modules (but not for modules under development).
> >>
> >> This doesn't make much sense unless you give an objective definition of 
> >> "published". For example, are proprietary modules (developed by vendors) 
> >> ever published?
> >>
> >
> > This has to be late binding - an organization publishing modules will
> > have to define what 'publishing' means for them and they will have to
> > decide whether they publish anything at all.
> 
> So that is exactly what I was suggesting the document’s text
> be changed to.  At the present time it refers to the IETF’s process
> only.
> 
> I know -- I added issue #25 4 days ago:
> https://github.com/netmod-wg/rfc6087bis/issues/25 
> 
> 
>  
> 
> —Tom
> 
> 
> 
> 
> Andy
> 
>  
> >
> > /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 
> > 
> 
> ___
> 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] New Thread: IESG Review Process for Yang Models at the IETF

[Ladislav Lhotka]

> On 22 Dec 2015, at 16:43, Nadeau Thomas  wrote:
> 
>> 
>> On Dec 22, 2015:10:36 AM, at 10:36 AM, Ladislav Lhotka  wrote:
>> 
>> 
>>> On 22 Dec 2015, at 16:22, Nadeau Thomas  wrote:
>>> 
>>> 
>>> The action I am trying to tease out of this thread is how do we take 
>>> action
>>> going forward? There are many who are saying (and doing) what you say 
>>> below; however,
>> 
>> This should IMO be OK. One thing that might help avoid unnecessary 
>> duplication of work is to keep and up-to-date directory, where everybody 
>> could register their modules. Everything else could be a bottom-up process.
>> 
>> Lada
> 
>   That has been discussed on a separate thread.  I think the best idea 
> right now is to
> do something in IANA for a module namespace/ID registry but Benoit has asked 
> us to write
> up a draft with some ideas.

I think I don't even need IANA registration.

Lada

> 
>   —Tom
> 
> 
>> 
>>> there are related discussions on the RFC6020 update to the module update 
>>> rules
>>> claiming that we should only focus on IETF-realted modules. Do you see the 
>>> catch-22
>>> I am trying to make clear here?   The other issue is the simple process for 
>>> those modules
>>> that are developed here. Should we move them all to an external model, 
>>> should we 
>>> amend the IETF’s processes to accommodate rapid model development and 
>>> iteration?
>>> 
>>> —Tom
>>> 
>>> 
 On Dec 22, 2015:8:39 AM, at 8:39 AM, Ladislav Lhotka  wrote:
 
 
> On 22 Dec 2015, at 14:06, Nadeau Thomas  wrote:
> 
> 
> [moving the thread to its own discussion.]
> 
>>  This is a blocking factor that people are not considering: The RFC 
>> process the
>> IETF has in place is not suitable for rapid/modern/canonical model 
>> development.  It will
>> be difficult for the IESG review process to scale to even a couple 
>> models during any given
>> telechat period given the state of the document review/approval process. 
>> How do we
>> envision the IESG reviewing 250+ models (and growing)?  Besides the 
>> initial RFC version,
>> rapid refresh/update of models has the same issues.
> 
> I don't disagree, but I propose that we stick to the oper state 
> discussion in this email thread.
 
 I agree with Tom. I personally decided not to work on any new module in 
 the IETF any time soon. I am currently working on a number of modules 
 related to DNS, they will be freely available for review and use by 
 everybody, but I don't want to go through a similar process as with 
 ietf-routing, and then be stymied by the update rules.
 
 Lada
 
> 
> Regards, Benoit
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
 
 --
 Ladislav Lhotka, CZ.NIC Labs
 PGP Key ID: E74E8C0C
 
 
 
 
>>> 
>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

Re: [netmod] New Thread: IESG Review Process for Yang Models at the IETF

[Andy Bierman]

On Tue, Dec 22, 2015 at 5:06 AM, Nadeau Thomas 
wrote:

>
> [moving the thread to its own discussion.]
>
> >   This is a blocking factor that people are not considering: The RFC
> process the
> > IETF has in place is not suitable for rapid/modern/canonical model
> development.  It will
> > be difficult for the IESG review process to scale to even a couple
> models during any given
> > telechat period given the state of the document review/approval process.
> How do we
> > envision the IESG reviewing 250+ models (and growing)?  Besides the
> initial RFC version,
> > rapid refresh/update of models has the same issues.
>
> I don't disagree, but I propose that we stick to the oper state discussion
> in this email thread.
>
>
Since this is a new thread, I am confused by the topic.
This suggests that the IESG final review of drafts is the bottleneck for
YANG.
I see no evidence of that.

The "RFC process" is a consensus and review based process.
The way to circumvent that consensus-based process is to publish
AD-sponsored Informational RFCs.

Getting people to agree on the details has always been the hard part
of standards development.  YANG modules are no different from any
other standard in this respect.





> Regards, Benoit
>


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] module update rules

[Andy Bierman]

On Tue, Dec 22, 2015 at 8:35 AM, Nadeau Thomas 
wrote:

>
> > On Dec 22, 2015:10:53 AM, at 10:53 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> >
> > On Tue, Dec 22, 2015 at 04:23:44PM +0100, Ladislav Lhotka wrote:
> >>
> >>> On 22 Dec 2015, at 16:06, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> >>>
> >>> On Tue, Dec 22, 2015 at 11:34:41AM +0100, Ladislav Lhotka wrote:
> 
> > On 22 Dec 2015, at 11:06, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> >
> > On Mon, Dec 21, 2015 at 08:09:13PM +0100, Ladislav Lhotka wrote:
> >>
> >>>
> >>> That's why the definition what 'published' means in the IETF is in
> the
> >>> guidelines document. On the other hand, since this is an IETF
> >>> document, I also do not find it problematic to define IETF rules
> >>> here. Others should be able to skip over this. There are really
> more
> >>> important problems to solve.
> >>
> >> It is not clear at all from sec. 10 that data modellers outside
> IETF may skip over this. I am not even sure that everybody in this WG
> agrees with your interpretation.
> >>
> >
> > You are wrong.
> >
> > - Section 10 in RFC 6020 applies to all published modules.
> 
>  The bullets specifying the rules are introduced with this sentence:
> 
>  'A definition may be revised in any of the following ways:'
> 
>  so IMO it is intended to apply to *all* modules. Are you saying that
> it actually means
> 
>  'A definition in a module published by IETF may be revised in any of
> the following ways:'?
> 
> >>>
> >>> A definition in a published module may be revised [...]
> >>>
> > - The definition of what turns a module into a published module is
> > specific to the different organizations publishing modules.
> 
>  So it means that such an organization may also decide to ignore the
> rules entirely or replace them with its own rules.
> 
> >>>
> >>> No.
> >>>
>  If the WG can agree on this and make the corresponding changes in
> sec. 11 of 6020bis, then I have no more objections.
> >>>
> >>> The rules are there to ensure interoperability. Interoperability is an
> >>> issue for published modules (but not for modules under development).
> >>
> >> This doesn't make much sense unless you give an objective definition of
> "published". For example, are proprietary modules (developed by vendors)
> ever published?
> >>
> >
> > This has to be late binding - an organization publishing modules will
> > have to define what 'publishing' means for them and they will have to
> > decide whether they publish anything at all.
>
> So that is exactly what I was suggesting the document’s text
> be changed to.  At the present time it refers to the IETF’s process
> only.
>

I know -- I added issue #25 4 days ago:
https://github.com/netmod-wg/rfc6087bis/issues/25



>
> —Tom
>
>
>

Andy



> >
> > /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
>
> ___
> 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] module update rules

[Nadeau Thomas]

> On Dec 22, 2015:10:53 AM, at 10:53 AM, Juergen Schoenwaelder 
>  wrote:
> 
> On Tue, Dec 22, 2015 at 04:23:44PM +0100, Ladislav Lhotka wrote:
>> 
>>> On 22 Dec 2015, at 16:06, Juergen Schoenwaelder 
>>>  wrote:
>>> 
>>> On Tue, Dec 22, 2015 at 11:34:41AM +0100, Ladislav Lhotka wrote:
 
> On 22 Dec 2015, at 11:06, Juergen Schoenwaelder 
>  wrote:
> 
> On Mon, Dec 21, 2015 at 08:09:13PM +0100, Ladislav Lhotka wrote:
>> 
>>> 
>>> That's why the definition what 'published' means in the IETF is in the
>>> guidelines document. On the other hand, since this is an IETF
>>> document, I also do not find it problematic to define IETF rules
>>> here. Others should be able to skip over this. There are really more
>>> important problems to solve.
>> 
>> It is not clear at all from sec. 10 that data modellers outside IETF may 
>> skip over this. I am not even sure that everybody in this WG agrees with 
>> your interpretation.
>> 
> 
> You are wrong.
> 
> - Section 10 in RFC 6020 applies to all published modules.
 
 The bullets specifying the rules are introduced with this sentence:
 
 'A definition may be revised in any of the following ways:'
 
 so IMO it is intended to apply to *all* modules. Are you saying that it 
 actually means
 
 'A definition in a module published by IETF may be revised in any of the 
 following ways:'?
 
>>> 
>>> A definition in a published module may be revised [...]
>>> 
> - The definition of what turns a module into a published module is
> specific to the different organizations publishing modules.
 
 So it means that such an organization may also decide to ignore the rules 
 entirely or replace them with its own rules.
 
>>> 
>>> No.
>>> 
 If the WG can agree on this and make the corresponding changes in sec. 11 
 of 6020bis, then I have no more objections.
>>> 
>>> The rules are there to ensure interoperability. Interoperability is an
>>> issue for published modules (but not for modules under development).
>> 
>> This doesn't make much sense unless you give an objective definition of 
>> "published". For example, are proprietary modules (developed by vendors) 
>> ever published?
>> 
> 
> This has to be late binding - an organization publishing modules will
> have to define what 'publishing' means for them and they will have to
> decide whether they publish anything at all.

So that is exactly what I was suggesting the document’s text
be changed to.  At the present time it refers to the IETF’s process
only.

—Tom


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

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

Re: [netmod] module update rules

[Juergen Schoenwaelder]

On Tue, Dec 22, 2015 at 04:23:44PM +0100, Ladislav Lhotka wrote:
> 
> > On 22 Dec 2015, at 16:06, Juergen Schoenwaelder 
> >  wrote:
> > 
> > On Tue, Dec 22, 2015 at 11:34:41AM +0100, Ladislav Lhotka wrote:
> >> 
> >>> On 22 Dec 2015, at 11:06, Juergen Schoenwaelder 
> >>>  wrote:
> >>> 
> >>> On Mon, Dec 21, 2015 at 08:09:13PM +0100, Ladislav Lhotka wrote:
>  
> > 
> > That's why the definition what 'published' means in the IETF is in the
> > guidelines document. On the other hand, since this is an IETF
> > document, I also do not find it problematic to define IETF rules
> > here. Others should be able to skip over this. There are really more
> > important problems to solve.
>  
>  It is not clear at all from sec. 10 that data modellers outside IETF may 
>  skip over this. I am not even sure that everybody in this WG agrees with 
>  your interpretation.
>  
> >>> 
> >>> You are wrong.
> >>> 
> >>> - Section 10 in RFC 6020 applies to all published modules.
> >> 
> >> The bullets specifying the rules are introduced with this sentence:
> >> 
> >> 'A definition may be revised in any of the following ways:'
> >> 
> >> so IMO it is intended to apply to *all* modules. Are you saying that it 
> >> actually means
> >> 
> >> 'A definition in a module published by IETF may be revised in any of the 
> >> following ways:'?
> >> 
> > 
> > A definition in a published module may be revised [...]
> > 
> >>> - The definition of what turns a module into a published module is
> >>> specific to the different organizations publishing modules.
> >> 
> >> So it means that such an organization may also decide to ignore the rules 
> >> entirely or replace them with its own rules.
> >> 
> > 
> > No.
> > 
> >> If the WG can agree on this and make the corresponding changes in sec. 11 
> >> of 6020bis, then I have no more objections.
> > 
> > The rules are there to ensure interoperability. Interoperability is an
> > issue for published modules (but not for modules under development).
> 
> This doesn't make much sense unless you give an objective definition of 
> "published". For example, are proprietary modules (developed by vendors) ever 
> published?
>

This has to be late binding - an organization publishing modules will
have to define what 'publishing' means for them and they will have to
decide whether they publish anything at all.

/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

Re: [netmod] module update rules

[Andy Bierman]

On Tue, Dec 22, 2015 at 7:24 AM, Nadeau Thomas 
wrote:

>
> > On Dec 22, 2015:10:23 AM, at 10:23 AM, Ladislav Lhotka 
> wrote:
> >
> >
> >> On 22 Dec 2015, at 16:06, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> >>
> >> On Tue, Dec 22, 2015 at 11:34:41AM +0100, Ladislav Lhotka wrote:
> >>>
>  On 22 Dec 2015, at 11:06, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> 
>  On Mon, Dec 21, 2015 at 08:09:13PM +0100, Ladislav Lhotka wrote:
> >
> >>
> >> That's why the definition what 'published' means in the IETF is in
> the
> >> guidelines document. On the other hand, since this is an IETF
> >> document, I also do not find it problematic to define IETF rules
> >> here. Others should be able to skip over this. There are really more
> >> important problems to solve.
> >
> > It is not clear at all from sec. 10 that data modellers outside IETF
> may skip over this. I am not even sure that everybody in this WG agrees
> with your interpretation.
> >
> 
>  You are wrong.
> 
>  - Section 10 in RFC 6020 applies to all published modules.
> >>>
> >>> The bullets specifying the rules are introduced with this sentence:
> >>>
> >>> 'A definition may be revised in any of the following ways:'
> >>>
> >>> so IMO it is intended to apply to *all* modules. Are you saying that
> it actually means
> >>>
> >>> 'A definition in a module published by IETF may be revised in any of
> the following ways:'?
> >>>
> >>
> >> A definition in a published module may be revised [...]
> >>
>  - The definition of what turns a module into a published module is
>  specific to the different organizations publishing modules.
> >>>
> >>> So it means that such an organization may also decide to ignore the
> rules entirely or replace them with its own rules.
> >>>
> >>
> >> No.
> >>
> >>> If the WG can agree on this and make the corresponding changes in sec.
> 11 of 6020bis, then I have no more objections.
> >>
> >> The rules are there to ensure interoperability. Interoperability is an
> >> issue for published modules (but not for modules under development).
> >
> > This doesn't make much sense unless you give an objective definition of
> "published". For example, are proprietary modules (developed by vendors)
> ever published?
>
> And that is the point I made the other day. Simply saying that
> definition is The IETF’s
> definition forms a rather circular argument.
>
>

Each SDO may have its own definition of work-in-progress vs
published-for-use.
It doesn't seem that hard to figure out without help from the IETF.




> —Tom
>


Andy


>
>
> >
> >> The IETF certainly has a history to care about interoperability. I
> >> expect that other organizations care about interoperability as well.
> >
> > That's their business.
> >
> > Lada
> >
> >>
> >> /js
> >>
> >> --
> >> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> >> Fax:   +49 421 200 3103 
> >
> > --
> > 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
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Andy Bierman]

On Tue, Dec 22, 2015 at 5:07 AM, Acee Lindem (acee)  wrote:

> Hi Lada,
>
> On 12/22/15, 7:25 AM, "Ladislav Lhotka"  wrote:
>
> >Hi Acee,
> >
> >> On 22 Dec 2015, at 13:03, Acee Lindem (acee)  wrote:
> >>
> >> Jurgen, Lada,
> >>
> >> On 12/22/15, 6:45 AM, "netmod on behalf of Ladislav Lhotka"
> >>  wrote:
> >>
> >>>
>  On 22 Dec 2015, at 12:38, Benoit Claise  wrote:
> 
>  Jürgen,
> > 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.
>  Interestingly, I received that feedback again recently, this time from
>  the OSPF and ISIS YANG model authors.
> >>>
> >>> Did they mention any reason *why* it is a blocking factor for their
> >>> modules?
> >>
> >> This should be obvious - the OSPF and IS-IS WG are not going to publish
> >> YANG models that don’t meet the ops-state requirements. Why would we
> >
> >Can you please explain what specific ops-state requirements aren't met in
> >those modules? I am interested because the same problem may possibly be
> >present in our ietf-routing module.
>
> That’s easy - the requirements as stated in
> https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/
>
> We could go back and reorganize the IGP models and add separate leaves for
> intended and applied config and meet these requirements. However, if we
> conclude on a more elegant solution, it would be great to avail ourselves
> to that solution.
>
>

At the last IETF, the consensus in the room was to use an RPC-based
solution.
Has that changed? What aspect of the RPC-based solution is blocking data
model development?



> Thanks,
> Acee
>


Andy


>
>
>
> >
> >Thanks, Lada
> >
> >> publish standards that don’t meet the requirements and are,
> >>consequently,
> >> irrelevant? Failure to recognize this is a real blocking issue.
> >>
> >> Acee
> >>
> >>
> >>
> >>
> >>>
> >>> Thanks, Lada
> >>>
> > There seem to be
> > ways to address the requirements without having to block all work or
> > to redo what that we have published.
>  That's my hope too.
> > But sure, if you make it a
> > blocking factor, it will be one.
>  I'll chose to ignore this last sentence.
> 
>  Regards, Benoit
> >
> >> 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
> >
> 
>  ___
>  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
> >
> >--
> >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] New Thread: IESG Review Process for Yang Models at the IETF

[Nadeau Thomas]

> On Dec 22, 2015:10:36 AM, at 10:36 AM, Ladislav Lhotka  wrote:
> 
> 
>> On 22 Dec 2015, at 16:22, Nadeau Thomas  wrote:
>> 
>> 
>>  The action I am trying to tease out of this thread is how do we take 
>> action
>> going forward? There are many who are saying (and doing) what you say below; 
>> however,
> 
> This should IMO be OK. One thing that might help avoid unnecessary 
> duplication of work is to keep and up-to-date directory, where everybody 
> could register their modules. Everything else could be a bottom-up process.
> 
> Lada

That has been discussed on a separate thread.  I think the best idea 
right now is to
do something in IANA for a module namespace/ID registry but Benoit has asked us 
to write
up a draft with some ideas.

—Tom


> 
>> there are related discussions on the RFC6020 update to the module update 
>> rules
>> claiming that we should only focus on IETF-realted modules. Do you see the 
>> catch-22
>> I am trying to make clear here?   The other issue is the simple process for 
>> those modules
>> that are developed here. Should we move them all to an external model, 
>> should we 
>> amend the IETF’s processes to accommodate rapid model development and 
>> iteration?
>> 
>>  —Tom
>> 
>> 
>>> On Dec 22, 2015:8:39 AM, at 8:39 AM, Ladislav Lhotka  wrote:
>>> 
>>> 
 On 22 Dec 2015, at 14:06, Nadeau Thomas  wrote:
 
 
 [moving the thread to its own discussion.]
 
>   This is a blocking factor that people are not considering: The RFC 
> process the
> IETF has in place is not suitable for rapid/modern/canonical model 
> development.  It will
> be difficult for the IESG review process to scale to even a couple models 
> during any given
> telechat period given the state of the document review/approval process. 
> How do we
> envision the IESG reviewing 250+ models (and growing)?  Besides the 
> initial RFC version,
> rapid refresh/update of models has the same issues.
 
 I don't disagree, but I propose that we stick to the oper state discussion 
 in this email thread.
>>> 
>>> I agree with Tom. I personally decided not to work on any new module in the 
>>> IETF any time soon. I am currently working on a number of modules related 
>>> to DNS, they will be freely available for review and use by everybody, but 
>>> I don't want to go through a similar process as with ietf-routing, and then 
>>> be stymied by the update rules.
>>> 
>>> Lada
>>> 
 
 Regards, Benoit
 
 
 ___
 netmod mailing list
 netmod@ietf.org
 https://www.ietf.org/mailman/listinfo/netmod
>>> 
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>> 
>>> 
>>> 
>>> 
>> 
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 

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

Re: [netmod] New Thread: IESG Review Process for Yang Models at the IETF

[Ladislav Lhotka]

> On 22 Dec 2015, at 16:22, Nadeau Thomas  wrote:
> 
> 
>   The action I am trying to tease out of this thread is how do we take 
> action
> going forward? There are many who are saying (and doing) what you say below; 
> however,

This should IMO be OK. One thing that might help avoid unnecessary duplication 
of work is to keep and up-to-date directory, where everybody could register 
their modules. Everything else could be a bottom-up process.

Lada

> there are related discussions on the RFC6020 update to the module update rules
> claiming that we should only focus on IETF-realted modules. Do you see the 
> catch-22
> I am trying to make clear here?   The other issue is the simple process for 
> those modules
> that are developed here. Should we move them all to an external model, should 
> we 
> amend the IETF’s processes to accommodate rapid model development and 
> iteration?
> 
>   —Tom
> 
> 
>> On Dec 22, 2015:8:39 AM, at 8:39 AM, Ladislav Lhotka  wrote:
>> 
>> 
>>> On 22 Dec 2015, at 14:06, Nadeau Thomas  wrote:
>>> 
>>> 
>>> [moving the thread to its own discussion.]
>>> 
This is a blocking factor that people are not considering: The RFC 
 process the
 IETF has in place is not suitable for rapid/modern/canonical model 
 development.  It will
 be difficult for the IESG review process to scale to even a couple models 
 during any given
 telechat period given the state of the document review/approval process. 
 How do we
 envision the IESG reviewing 250+ models (and growing)?  Besides the 
 initial RFC version,
 rapid refresh/update of models has the same issues.
>>> 
>>> I don't disagree, but I propose that we stick to the oper state discussion 
>>> in this email thread.
>> 
>> I agree with Tom. I personally decided not to work on any new module in the 
>> IETF any time soon. I am currently working on a number of modules related to 
>> DNS, they will be freely available for review and use by everybody, but I 
>> don't want to go through a similar process as with ietf-routing, and then be 
>> stymied by the update rules.
>> 
>> Lada
>> 
>>> 
>>> Regards, Benoit
>>> 
>>> 
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>> 
>> 
>> 
>> 
> 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

Re: [netmod] module update rules

[Nadeau Thomas]

> On Dec 22, 2015:10:23 AM, at 10:23 AM, Ladislav Lhotka  wrote:
> 
> 
>> On 22 Dec 2015, at 16:06, Juergen Schoenwaelder 
>>  wrote:
>> 
>> On Tue, Dec 22, 2015 at 11:34:41AM +0100, Ladislav Lhotka wrote:
>>> 
 On 22 Dec 2015, at 11:06, Juergen Schoenwaelder 
  wrote:
 
 On Mon, Dec 21, 2015 at 08:09:13PM +0100, Ladislav Lhotka wrote:
> 
>> 
>> That's why the definition what 'published' means in the IETF is in the
>> guidelines document. On the other hand, since this is an IETF
>> document, I also do not find it problematic to define IETF rules
>> here. Others should be able to skip over this. There are really more
>> important problems to solve.
> 
> It is not clear at all from sec. 10 that data modellers outside IETF may 
> skip over this. I am not even sure that everybody in this WG agrees with 
> your interpretation.
> 
 
 You are wrong.
 
 - Section 10 in RFC 6020 applies to all published modules.
>>> 
>>> The bullets specifying the rules are introduced with this sentence:
>>> 
>>> 'A definition may be revised in any of the following ways:'
>>> 
>>> so IMO it is intended to apply to *all* modules. Are you saying that it 
>>> actually means
>>> 
>>> 'A definition in a module published by IETF may be revised in any of the 
>>> following ways:'?
>>> 
>> 
>> A definition in a published module may be revised [...]
>> 
 - The definition of what turns a module into a published module is
 specific to the different organizations publishing modules.
>>> 
>>> So it means that such an organization may also decide to ignore the rules 
>>> entirely or replace them with its own rules.
>>> 
>> 
>> No.
>> 
>>> If the WG can agree on this and make the corresponding changes in sec. 11 
>>> of 6020bis, then I have no more objections.
>> 
>> The rules are there to ensure interoperability. Interoperability is an
>> issue for published modules (but not for modules under development).
> 
> This doesn't make much sense unless you give an objective definition of 
> "published". For example, are proprietary modules (developed by vendors) ever 
> published?

And that is the point I made the other day. Simply saying that 
definition is The IETF’s
definition forms a rather circular argument.

—Tom


> 
>> The IETF certainly has a history to care about interoperability. I
>> expect that other organizations care about interoperability as well.
> 
> That's their business.
> 
> Lada
> 
>> 
>> /js
>> 
>> -- 
>> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103 
> 
> --
> 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] module update rules

[Ladislav Lhotka]

> On 22 Dec 2015, at 16:06, Juergen Schoenwaelder 
>  wrote:
> 
> On Tue, Dec 22, 2015 at 11:34:41AM +0100, Ladislav Lhotka wrote:
>> 
>>> On 22 Dec 2015, at 11:06, Juergen Schoenwaelder 
>>>  wrote:
>>> 
>>> On Mon, Dec 21, 2015 at 08:09:13PM +0100, Ladislav Lhotka wrote:
 
> 
> That's why the definition what 'published' means in the IETF is in the
> guidelines document. On the other hand, since this is an IETF
> document, I also do not find it problematic to define IETF rules
> here. Others should be able to skip over this. There are really more
> important problems to solve.
 
 It is not clear at all from sec. 10 that data modellers outside IETF may 
 skip over this. I am not even sure that everybody in this WG agrees with 
 your interpretation.
 
>>> 
>>> You are wrong.
>>> 
>>> - Section 10 in RFC 6020 applies to all published modules.
>> 
>> The bullets specifying the rules are introduced with this sentence:
>> 
>> 'A definition may be revised in any of the following ways:'
>> 
>> so IMO it is intended to apply to *all* modules. Are you saying that it 
>> actually means
>> 
>> 'A definition in a module published by IETF may be revised in any of the 
>> following ways:'?
>> 
> 
> A definition in a published module may be revised [...]
> 
>>> - The definition of what turns a module into a published module is
>>> specific to the different organizations publishing modules.
>> 
>> So it means that such an organization may also decide to ignore the rules 
>> entirely or replace them with its own rules.
>> 
> 
> No.
> 
>> If the WG can agree on this and make the corresponding changes in sec. 11 of 
>> 6020bis, then I have no more objections.
> 
> The rules are there to ensure interoperability. Interoperability is an
> issue for published modules (but not for modules under development).

This doesn't make much sense unless you give an objective definition of 
"published". For example, are proprietary modules (developed by vendors) ever 
published?

> The IETF certainly has a history to care about interoperability. I
> expect that other organizations care about interoperability as well.

That's their business.

Lada

> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

Re: [netmod] New Thread: IESG Review Process for Yang Models at the IETF

[Nadeau Thomas]

The action I am trying to tease out of this thread is how do we take 
action
going forward? There are many who are saying (and doing) what you say below; 
however,
there are related discussions on the RFC6020 update to the module update rules
claiming that we should only focus on IETF-realted modules. Do you see the 
catch-22
I am trying to make clear here?   The other issue is the simple process for 
those modules
that are developed here. Should we move them all to an external model, should 
we 
amend the IETF’s processes to accommodate rapid model development and iteration?

—Tom


> On Dec 22, 2015:8:39 AM, at 8:39 AM, Ladislav Lhotka  wrote:
> 
> 
>> On 22 Dec 2015, at 14:06, Nadeau Thomas  wrote:
>> 
>> 
>> [moving the thread to its own discussion.]
>> 
>>> This is a blocking factor that people are not considering: The RFC 
>>> process the
>>> IETF has in place is not suitable for rapid/modern/canonical model 
>>> development.  It will
>>> be difficult for the IESG review process to scale to even a couple models 
>>> during any given
>>> telechat period given the state of the document review/approval process. 
>>> How do we
>>> envision the IESG reviewing 250+ models (and growing)?  Besides the initial 
>>> RFC version,
>>> rapid refresh/update of models has the same issues.
>> 
>> I don't disagree, but I propose that we stick to the oper state discussion 
>> in this email thread.
> 
> I agree with Tom. I personally decided not to work on any new module in the 
> IETF any time soon. I am currently working on a number of modules related to 
> DNS, they will be freely available for review and use by everybody, but I 
> don't want to go through a similar process as with ietf-routing, and then be 
> stymied by the update rules.
> 
> Lada
> 
>> 
>> Regards, Benoit
>> 
>> 
>> ___
>> 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] module update rules

[Juergen Schoenwaelder]

On Tue, Dec 22, 2015 at 11:34:41AM +0100, Ladislav Lhotka wrote:
> 
> > On 22 Dec 2015, at 11:06, Juergen Schoenwaelder 
> >  wrote:
> > 
> > On Mon, Dec 21, 2015 at 08:09:13PM +0100, Ladislav Lhotka wrote:
> >> 
> >>> 
> >>> That's why the definition what 'published' means in the IETF is in the
> >>> guidelines document. On the other hand, since this is an IETF
> >>> document, I also do not find it problematic to define IETF rules
> >>> here. Others should be able to skip over this. There are really more
> >>> important problems to solve.
> >> 
> >> It is not clear at all from sec. 10 that data modellers outside IETF may 
> >> skip over this. I am not even sure that everybody in this WG agrees with 
> >> your interpretation.
> >> 
> > 
> > You are wrong.
> > 
> > - Section 10 in RFC 6020 applies to all published modules.
> 
> The bullets specifying the rules are introduced with this sentence:
> 
> 'A definition may be revised in any of the following ways:'
> 
> so IMO it is intended to apply to *all* modules. Are you saying that it 
> actually means
> 
> 'A definition in a module published by IETF may be revised in any of the 
> following ways:'?
>

A definition in a published module may be revised [...]

> > - The definition of what turns a module into a published module is
> >  specific to the different organizations publishing modules.
> 
> So it means that such an organization may also decide to ignore the rules 
> entirely or replace them with its own rules.
>

No.

> If the WG can agree on this and make the corresponding changes in sec. 11 of 
> 6020bis, then I have no more objections.

The rules are there to ensure interoperability. Interoperability is an
issue for published modules (but not for modules under development).
The IETF certainly has a history to care about interoperability. I
expect that other organizations care about interoperability as well.

/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

Re: [netmod] New Thread: IESG Review Process for Yang Models at the IETF

[Ladislav Lhotka]

> On 22 Dec 2015, at 14:06, Nadeau Thomas  wrote:
> 
> 
> [moving the thread to its own discussion.]
> 
>>  This is a blocking factor that people are not considering: The RFC 
>> process the
>> IETF has in place is not suitable for rapid/modern/canonical model 
>> development.  It will
>> be difficult for the IESG review process to scale to even a couple models 
>> during any given
>> telechat period given the state of the document review/approval process. How 
>> do we
>> envision the IESG reviewing 250+ models (and growing)?  Besides the initial 
>> RFC version,
>> rapid refresh/update of models has the same issues.
> 
> I don't disagree, but I propose that we stick to the oper state discussion in 
> this email thread.

I agree with Tom. I personally decided not to work on any new module in the 
IETF any time soon. I am currently working on a number of modules related to 
DNS, they will be freely available for review and use by everybody, but I don't 
want to go through a similar process as with ietf-routing, and then be stymied 
by the update rules.

Lada

> 
> Regards, Benoit
> 
> 
> ___
> 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] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Ladislav Lhotka]

> On 22 Dec 2015, at 14:07, Acee Lindem (acee)  wrote:
> 
> Hi Lada,
> 
> On 12/22/15, 7:25 AM, "Ladislav Lhotka"  wrote:
> 
>> Hi Acee,
>> 
>>> On 22 Dec 2015, at 13:03, Acee Lindem (acee)  wrote:
>>> 
>>> Jurgen, Lada, 
>>> 
>>> On 12/22/15, 6:45 AM, "netmod on behalf of Ladislav Lhotka"
>>>  wrote:
>>> 
 
> On 22 Dec 2015, at 12:38, Benoit Claise  wrote:
> 
> Jürgen,
>> 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.
> Interestingly, I received that feedback again recently, this time from
> the OSPF and ISIS YANG model authors.
 
 Did they mention any reason *why* it is a blocking factor for their
 modules?
>>> 
>>> This should be obvious - the OSPF and IS-IS WG are not going to publish
>>> YANG models that don’t meet the ops-state requirements. Why would we
>> 
>> Can you please explain what specific ops-state requirements aren't met in
>> those modules? I am interested because the same problem may possibly be
>> present in our ietf-routing module.
> 
> That’s easy - the requirements as stated in
> https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/
> 
> We could go back and reorganize the IGP models and add separate leaves for
> intended and applied config and meet these requirements. However, if we

OK, so you probably already have a solution for implementing intended and 
applied configuration. In my view, since intended and applied configuration 
have identical schemas (Requirement 1C), there is no reason for repeating any 
leaves in the data model.

> conclude on a more elegant solution, it would be great to avail ourselves
> to that solution.

I don't know whether it is more elegant but certainly a possible solution is to 
have a separate datastore for applied configuration and use the same data model 
(config true part) for both intended and applied configuration.

Lada

> 
> Thanks,
> Acee 
> 
> 
> 
>> 
>> Thanks, Lada
>> 
>>> publish standards that don’t meet the requirements and are,
>>> consequently,
>>> irrelevant? Failure to recognize this is a real blocking issue.
>>> 
>>> Acee
>>> 
>>> 
>>> 
>>> 
 
 Thanks, Lada
 
>> There seem to be
>> ways to address the requirements without having to block all work or
>> to redo what that we have published.
> That's my hope too.
>> But sure, if you make it a
>> blocking factor, it will be one.
> I'll chose to ignore this last sentence.
> 
> Regards, Benoit
>> 
>>> 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
>> 
> 
> ___
> 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
>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

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

[Acee Lindem (acee)]

Hi Lada,

On 12/22/15, 7:25 AM, "Ladislav Lhotka"  wrote:

>Hi Acee,
>
>> On 22 Dec 2015, at 13:03, Acee Lindem (acee)  wrote:
>> 
>> Jurgen, Lada, 
>> 
>> On 12/22/15, 6:45 AM, "netmod on behalf of Ladislav Lhotka"
>>  wrote:
>> 
>>> 
 On 22 Dec 2015, at 12:38, Benoit Claise  wrote:
 
 Jürgen,
> 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.
 Interestingly, I received that feedback again recently, this time from
 the OSPF and ISIS YANG model authors.
>>> 
>>> Did they mention any reason *why* it is a blocking factor for their
>>> modules?
>> 
>> This should be obvious - the OSPF and IS-IS WG are not going to publish
>> YANG models that don’t meet the ops-state requirements. Why would we
>
>Can you please explain what specific ops-state requirements aren't met in
>those modules? I am interested because the same problem may possibly be
>present in our ietf-routing module.

That’s easy - the requirements as stated in
https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/

We could go back and reorganize the IGP models and add separate leaves for
intended and applied config and meet these requirements. However, if we
conclude on a more elegant solution, it would be great to avail ourselves
to that solution. 

Thanks,
Acee 



>
>Thanks, Lada
>
>> publish standards that don’t meet the requirements and are,
>>consequently,
>> irrelevant? Failure to recognize this is a real blocking issue.
>> 
>> Acee
>> 
>> 
>> 
>> 
>>> 
>>> Thanks, Lada
>>> 
> There seem to be
> ways to address the requirements without having to block all work or
> to redo what that we have published.
 That's my hope too.
> But sure, if you make it a
> blocking factor, it will be one.
 I'll chose to ignore this last sentence.
 
 Regards, Benoit
> 
>> 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
> 
 
 ___
 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
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>

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

[netmod] New Thread: IESG Review Process for Yang Models at the IETF

[Nadeau Thomas]

[moving the thread to its own discussion.]

>   This is a blocking factor that people are not considering: The RFC 
> process the
> IETF has in place is not suitable for rapid/modern/canonical model 
> development.  It will
> be difficult for the IESG review process to scale to even a couple models 
> during any given
> telechat period given the state of the document review/approval process. How 
> do we
> envision the IESG reviewing 250+ models (and growing)?  Besides the initial 
> RFC version,
> rapid refresh/update of models has the same issues.

I don't disagree, but I propose that we stick to the oper state discussion in 
this email thread.

Regards, Benoit


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

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

[Benoit Claise]

On 12/22/2015 1:55 PM, Nadeau Thomas wrote:

On Dec 22, 2015:6:38 AM, at 6:38 AM, Benoit Claise  wrote:

Jürgen,

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.

Interestingly, I received that feedback again recently, this time from the OSPF 
and ISIS YANG model authors.

This is a blocking factor that people are not considering: The RFC 
process the
IETF has in place is not suitable for rapid/modern/canonical model development. 
 It will
be difficult for the IESG review process to scale to even a couple models 
during any given
telechat period given the state of the document review/approval process. How do 
we
envision the IESG reviewing 250+ models (and growing)?  Besides the initial RFC 
version,
rapid refresh/update of models has the same issues.
I don't disagree, but I propose that we stick to the oper state 
discussion in this email thread.


Regards, Benoit

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

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

[Nadeau Thomas]

> On Dec 22, 2015:6:38 AM, at 6:38 AM, Benoit Claise  wrote:
> 
> Jürgen,
>> 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.
> Interestingly, I received that feedback again recently, this time from the 
> OSPF and ISIS YANG model authors.

This is a blocking factor that people are not considering: The RFC 
process the 
IETF has in place is not suitable for rapid/modern/canonical model development. 
 It will 
be difficult for the IESG review process to scale to even a couple models 
during any given 
telechat period given the state of the document review/approval process. How do 
we 
envision the IESG reviewing 250+ models (and growing)?  Besides the initial RFC 
version, 
rapid refresh/update of models has the same issues. 

—Tom

>> There seem to be
>> ways to address the requirements without having to block all work or
>> to redo what that we have published.
> That's my hope too.
>> But sure, if you make it a
>> blocking factor, it will be one.
> I'll chose to ignore this last sentence.
> 
> Regards, Benoit
>> 
>>> 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
>> 
> 
> ___
> 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

[Ladislav Lhotka]

Hi Acee,

> On 22 Dec 2015, at 13:03, Acee Lindem (acee)  wrote:
> 
> Jurgen, Lada, 
> 
> On 12/22/15, 6:45 AM, "netmod on behalf of Ladislav Lhotka"
>  wrote:
> 
>> 
>>> On 22 Dec 2015, at 12:38, Benoit Claise  wrote:
>>> 
>>> Jürgen,
 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.
>>> Interestingly, I received that feedback again recently, this time from
>>> the OSPF and ISIS YANG model authors.
>> 
>> Did they mention any reason *why* it is a blocking factor for their
>> modules?
> 
> This should be obvious - the OSPF and IS-IS WG are not going to publish
> YANG models that don’t meet the ops-state requirements. Why would we

Can you please explain what specific ops-state requirements aren't met in those 
modules? I am interested because the same problem may possibly be present in 
our ietf-routing module.

Thanks, Lada

> publish standards that don’t meet the requirements and are, consequently,
> irrelevant? Failure to recognize this is a real blocking issue.
> 
> Acee
> 
> 
> 
> 
>> 
>> Thanks, Lada
>> 
 There seem to be
 ways to address the requirements without having to block all work or
 to redo what that we have published.
>>> That's my hope too.
 But sure, if you make it a
 blocking factor, it will be one.
>>> I'll chose to ignore this last sentence.
>>> 
>>> Regards, Benoit
 
> 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
 
>>> 
>>> ___
>>> 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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

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

[Acee Lindem (acee)]

Jurgen, Lada, 

On 12/22/15, 6:45 AM, "netmod on behalf of Ladislav Lhotka"
 wrote:

>
>> On 22 Dec 2015, at 12:38, Benoit Claise  wrote:
>> 
>> Jürgen,
>>> 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.
>> Interestingly, I received that feedback again recently, this time from
>>the OSPF and ISIS YANG model authors.
>
>Did they mention any reason *why* it is a blocking factor for their
>modules?

This should be obvious - the OSPF and IS-IS WG are not going to publish
YANG models that don’t meet the ops-state requirements. Why would we
publish standards that don’t meet the requirements and are, consequently,
irrelevant? Failure to recognize this is a real blocking issue.

Acee




>
>Thanks, Lada
>
>>> There seem to be
>>> ways to address the requirements without having to block all work or
>>> to redo what that we have published.
>> That's my hope too.
>>> But sure, if you make it a
>>> blocking factor, it will be one.
>> I'll chose to ignore this last sentence.
>> 
>> Regards, Benoit
>>> 
 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
>>> 
>> 
>> ___
>> 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 WG LC: draft-ietf-netmod-opstate-reqs-01

[Ladislav Lhotka]

> On 22 Dec 2015, at 12:38, Benoit Claise  wrote:
> 
> Jürgen,
>> 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.
> Interestingly, I received that feedback again recently, this time from the 
> OSPF and ISIS YANG model authors.

Did they mention any reason *why* it is a blocking factor for their modules?

Thanks, Lada

>> There seem to be
>> ways to address the requirements without having to block all work or
>> to redo what that we have published.
> That's my hope too.
>> But sure, if you make it a
>> blocking factor, it will be one.
> I'll chose to ignore this last sentence.
> 
> Regards, Benoit
>> 
>>> 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
>> 
> 
> ___
> 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] Draft clemm netmod mount draft

[rohitrranade]

In the controller-network data model , is the interfaces module imported for a 
specific reason ?




Sent from Outlook Mobile


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

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

[Benoit Claise]

Jürgen,

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.
Interestingly, I received that feedback again recently, this time from 
the OSPF and ISIS YANG model authors.

There seem to be
ways to address the requirements without having to block all work or
to redo what that we have published.

That's my hope too.

But sure, if you make it a
blocking factor, it will be one.

I'll chose to ignore this last sentence.

Regards, Benoit



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



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

Re: [netmod] module update rules

[Ladislav Lhotka]

> On 22 Dec 2015, at 11:06, Juergen Schoenwaelder 
>  wrote:
> 
> On Mon, Dec 21, 2015 at 08:09:13PM +0100, Ladislav Lhotka wrote:
>> 
>>> 
>>> That's why the definition what 'published' means in the IETF is in the
>>> guidelines document. On the other hand, since this is an IETF
>>> document, I also do not find it problematic to define IETF rules
>>> here. Others should be able to skip over this. There are really more
>>> important problems to solve.
>> 
>> It is not clear at all from sec. 10 that data modellers outside IETF may 
>> skip over this. I am not even sure that everybody in this WG agrees with 
>> your interpretation.
>> 
> 
> You are wrong.
> 
> - Section 10 in RFC 6020 applies to all published modules.

The bullets specifying the rules are introduced with this sentence:

'A definition may be revised in any of the following ways:'

so IMO it is intended to apply to *all* modules. Are you saying that it 
actually means

'A definition in a module published by IETF may be revised in any of the 
following ways:'?

> 
> - The definition of what turns a module into a published module is
> specific to the different organizations publishing modules.

So it means that such an organization may also decide to ignore the rules 
entirely or replace them with its own rules.

If the WG can agree on this and make the corresponding changes in sec. 11 of 
6020bis, then I have no more objections.  

Lada

> 
> - For the IETF, the definition is publication as an RFC. I do not care
> whether this definition is in RFC 6020bis or RFC 6087bis.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

Re: [netmod] module update rules

[Juergen Schoenwaelder]

On Mon, Dec 21, 2015 at 11:28:41AM -0800, Andy Bierman wrote:

> However, we do seem to aggressively extract YANG modules from documents and
> then ignore the source document completely.
> There is absolutely no way for a YANG compiler to tell the difference
> between a module extracted from an Internet Draft from a module
> extracted from an RFC.

This is a tool problem that is easy to solve (e.g., by storing
published modules separately from other modules).

/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

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

[Ladislav Lhotka]

> On 21 Dec 2015, at 22:34, Andy Bierman  wrote:
> 
> 
> 
> On Mon, Dec 21, 2015 at 12:17 PM, Ladislav Lhotka  wrote:
> 
> > On 21 Dec 2015, at 17:42, Robert Wilton  wrote:
> >
> > Hi Lada,
> >
> > On 21/12/2015 16:05, Ladislav Lhotka wrote:
> >>> On 21 Dec 2015, at 16:05, Robert Wilton  wrote:
> >>>
> >>> Hi Lada,
> >>>
> >>> On 21/12/2015 13:55, Ladislav Lhotka wrote:
>  Juergen Schoenwaelder  writes:
> 
> > On Thu, Dec 17, 2015 at 10:52:13AM -0500, Nadeau Thomas wrote:
> >>> On Dec 17, 2015:9:36 AM, at 9:36 AM, Kent Watsen 
> >>>  wrote:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >> 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
> >>  [As Co-chair]
> >>
> >>  Given the tall hill we climbed to get to this point on the 
> >> requirements, I
> >> want to be clear that there needs to be very significant support to 
> >> change the requirements
> >> in any significant way. We went round and round the drain on settling 
> >> on these requirements, and
> >> people had a whole host of reasonable opportunities to add this during 
> >> those times. I want to point out that while this statement may seem 
> >> subtle, slipping this in at the last minute could have a profound 
> >> impact on solutions built from these requirements, so I want to be 
> >> sure everyone involved has through through this kind of change.
> >>
> >>  —Tom
> > Tom,
> >
> > I think Andy is talking about applicability - to which kind of servers
> > do these requirements apply. For example, if it takes more time on a
> > certain class of devices to retrieve the difference between applied
> > and intended config than it takes to turn intended config into applied
> > config, then these requirements may not be applicable (since by the
> > time you have finished retrieving the difference it has vanished).
>  I think it is not only matter of synchronisation delays between intended
>  and applied configuration. I have serious troubles understanding how
>  these concepts map to the class of devices I am mainly interested in.
> 
>  Let me give you an example: An OpenWRT router runs a NETCONF/RESTCONF
>  server that supports intended and applied config. Assume the server
>  implements modules of the acl-model family so that firewall rules can be
>  configured through NETCONF/RESTCONF. Great.
> 
>  Now an admin runs "iptables" to manipulate netfilter rules in the
>  kernel. How does it affect the applied and intended configurations?
> 
>  A. The change isn't reflected in applied configuration. Then applied
> configuration is no more "…, the configuration state which is
> currently being used by server components (e.g., control plane
> daemons, operating system kernels, line cards)."
> 
>  B. The change is reflected in applied but not in intended
> configuration. This violates requirement 1 sub D, and also it may be
> impossible to map the kernel changes back to the configuration.
> 
>  For sure, these problems exist also with the good old "running", but I
>  think the migration to intended-applied would just make things worse.
> >>> If I understand your example correctly, then the complexity in your 
> >>>