Re: [netmod] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

[Robert Wilton]

On 21/06/2017 18:20, Andy Bierman wrote:



On Wed, Jun 21, 2017 at 5:32 AM, Juergen Schoenwaelder 
> wrote:


On Wed, Jun 21, 2017 at 10:03:21AM +0100, Robert Wilton wrote:
>
> We found that trying to define what "configuration is, or
isn't", is hard,
> but still regard having a definition is important.
>
> In the end, I see that the real core of the definition is
actually the
> config true sentence.  I.e. the intention of the draft is to define
> configuration as the nodes in the YANG schema that are labelled
as config
> true, and hence it is the marking of the node as config true
that actually
> makes it configuration (at least in the context of this draft and
> NETCONF/YANG).
>
> So, do you think that it would help if the definition text was
reordered to
> make the binding to YANG config true first and foremost?
>
> E.g.
>
> Old:
>o  configuration: Data that determines how a device behaves. This
>   data is modeled in YANG using "config true" nodes.
Configuration
>   can originate from different sources.
>
> New:
>   configuration: All data that is modelled in YANG using "config
>   true" nodes.  Configuration is used to instruct how a device
behaves.
>   Configuration can originate from different sources.
>

I think this was true at some point of the internal discussions but I
think it is not true any longer. I believe the fix is this (moving the
config true statement to the definition of conventional
configuration):

NEW:

   o  configuration: Data that determines how a device behaves.
  Configuration can originate from different sources.

   o  conventional configuration: Configuration that is stored in
any of
  the conventional configuration datastores. This data is
modeled in
  YANG using "config true" nodes.



I agree with Joel that all protocol negotiated values should not be 
considered configuration.
There are values e.g. protocol timers that may be set either manually 
through configuration, or through a value negotiated by a peer.  In some 
protocols, it may be defined that a manually configured value would 
override a negotiated value.  In other cases, a negotiated value wins.


However, in both cases, there is only ever one actual operational value 
being used.  The idea of the classification of different types of 
configuration, and associated origin values, is so that a client can 
determine whether the actual operational value in use was taken from the 
configuration, or through protocol negotiation, or somewhere else.


Other examples are like IP addresses that may be set through 
configuration, or learned from DHCP, or other sources.




I2RS is somewhere in between configuration and protocol-negotiated values.
We don't have a good term for it yet.

There will be some protocol negotiation that is modeled in YANG and 
represented in
a configuration datastore (e.g. ephemeral datastore). This data can be 
modified with configured values.
The operational datastore reflects the actual values used. Maybe this 
is called

ephemeral configuration?
I think that draft refers to this as dynamic configuration, but the 
expectation is that this would only apply to config true nodes.  I don't 
think that we have a name if I2RS writes to config false nodes (which is 
in the I2RS requirements draft).




There will be some protocol negotiation that is not modeled in YANG 
and not represented in
a configuration datastore, but the operational datastore can still 
contain these values.

This should not be called configuration.
Agreed.  If these values are exposed they should be exposed as config 
false nodes in the operational datastore.


Thanks,
Rob




Andy

---8<--- snip ---8<---

In the current NMDA draft, configuration is a combination of
conventional configuration, dynamic configuration, learned
configuration, system configuration, and default configuration.
Perhaps we need to create more figures:

   configuration
|
+ conventional configuration (origin intended)
+ dynamic configuration  (origin dynamic)
+ learned configuration  (origin learned)
+ system configuration   (origin system)
+ default configuration  (origin default)

I am not sure whether dynamic configuration (e.g., coming from an I2RS
subsystem) or system configuration is necessarily restricted to config
true nodes. By moving the config true statement to the definition of
the term conventional configuration, we state something where we are
sure the statement is correct.

/js

--
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 

Re: [netmod] draft-vallin-netmod-alarm-module status and plans

[Kent Watsen]

Hi William,

Please be aware that this draft is moving to the CCAMP WG.  I don't think the 
ccamp-version of the draft has been posted yet, but it will be discussed in 
that WG (and not NETMOD) in Prague. 

Regards,
Kent


> On Jun 22, 2017, at 6:25 AM, William Lupton  
> wrote:
> 
> Dear all,
> 
> We at the Broadband Forum (BBF) would like to reiterate our interest in the 
> draft-vallin-netmod-alarm-module draft.
> 
> We will also have some technical comments / suggestions (internal discussion 
> is ongoing) that we will share with NETMOD as soon as possible.
> 
> Thanks,
> William
> 
>> On 31 May 2017, at 13:08, Benoit Claise  wrote:
>> 
>> William,
>> 
>> This was discussed with the authors, the NETMOD chairs, and the RTG AD 
>> Deborah.
>> The advice was for the authors to raise the draft in ccamp and try to 
>> progress it there.
>> 
>> The authors updated their draft to version 2 and pinged the CCAMP mailing 
>> list (https://www.ietf.org/mail-archive/web/ccamp/current/msg18124.html).
>> From that email thread, it seems there is interest in the work, but where to 
>> do the work is not clear.
>> 
>> My advice to the authors: continue progress this work and if CCAMP is not 
>> interested or consider this work too generic, bring it back to NETMOD and 
>> we'll follow normal WG process.
>> 
>> Regards, Benoit
>>> All,
>>> 
>>> I heard from Kent that 
>>> https://tools.ietf.org/html/draft-vallin-netmod-alarm-module was moving to 
>>> CCAMP but I don’t see any mention of it at 
>>> https://datatracker.ietf.org/wg/ccamp/documents (although it is shown as a 
>>> dependency at https://datatracker.ietf.org/wg/ccamp/deps/svg). Is any more 
>>> info available please?
>>> 
>>> Thanks,
>>> William
> 
> ___
> 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] Fwd: New Liaison Statement, "Liaison to IETF on IP Services Approved Draft 1"

[Benoit Claise]

FYI.

Regards, B.


 Forwarded Message 
Subject: 	New Liaison Statement, "Liaison to IETF on IP Services 
Approved Draft 1"

Date:   Wed, 3 May 2017 08:24:58 -0700
From:   Liaison Statement Management Tool 
To: 	Benoit Claise , Alvaro Retana 
, Alia Atlas , Deborah Brungard 
, Warren Kumari 
CC: 	Alvaro Retana , Deborah Brungard 
, n...@mef.net, Alia Atlas , Warren 
Kumari , The IETF Chair , 
sste...@pccwglobal.com, rra...@ciena.com, Benoit Claise 
, Raghu Ranganathan 




Title: Liaison to IETF on IP Services Approved Draft 1
Submission Date: 2017-05-03
URL of the IETF Web page: https://datatracker.ietf.org/liaison/1521/

From: Raghu Ranganathan 
To: Warren Kumari ,Benoit Claise ,Alia Atlas 
,Alvaro Retana ,Deborah Brungard 
Cc: Alvaro Retana ,Deborah Brungard ,Alia Atlas 
,Warren Kumari ,The IETF Chair ,Benoit Claise 
,Raghu Ranganathan 
Response Contacts: rra...@ciena.com, n...@mef.net, sste...@pccwglobal.com
Technical Contacts:
Purpose: For information

Body: Following our previous liaisons, we would like to update you on the 
progress of the MEF IP Service Attributes project. A new Approved Draft of our 
specification for IP Service Attributes for Subscriber Services is available, 
which can be accessed as described below. Note that a corresponding 
specification for IP Service Attributes for Operator Services is in progress 
but an Approved Draft is not yet available.

In the course of our work, we have reviewed some of the internet drafts from the L3SM 
working group that preceded publication of RFC 8049 ("Yang Data Model for L3VPN 
Service Delivery"), and we used this as input to our specification. Now that RFC 
8049 is published, we intend to review it again to ensure our work remains aligned. We 
would appreciate your review of our Approved Draft, and in particular any assistance you 
can give in identifying areas where it may conflict or be otherwise misaligned with RFC 
8049.

Note that the scope of the current IP Service Attributes project does not 
include definition of a yang module; however, we expect that a future project 
will include specification of a yang module based on the service attributes 
defined in this document. It is our hope that such a module can be defined as 
an augment of the module defined in RFC 8049.

MEF’s liaison partners may access all MEF approved drafts as follows:
https://mef.net/liaison-login
Username: mef
Password: M3F3030

The next MEF meetings are:
July 24 - 27, Toronto, Canada
October 23 - 26, Raleigh, USA
Attachments:

L00263_001_LiaisontoIETFonIPServicesApprovedDraft1_Ball_Ranganathan.pdf

https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2017-05-03-mef-ops-rtg-liaison-to-ietf-on-ip-services-approved-draft-1-attachment-1.pdf

.

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

Re: [netmod] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

[Mehmet Ersue]

> Having ' This data is modeled in YANG using "config true" nodes ' sort of
> suggests that the original definition holds sway and so contradicts the
> previous sentence.  And for this sentence to make sense, a reader would
> really have to understand the debates over configuration, state and how to
> model them that have been going on for so long which means that regardless
> of how true it is, it does not really belong in a definition.
> 
> There is no reference back to the previous definition, as to whether or
not
> the latest definition is meant to be the same or not.  I find this
confusing.
> 
> I think that the previous definition has to appear in this I-D, since it
has
> influenced so much work, and this I-D then needs to go on to say

It is indeed confusing to the reader if a document referring to a standard
track RFC defines and uses a term differently.
I agree that revising a term might become necessary though the revision
should be introduced properly.

> 
> 'We are revising it ..
> or
> 'We are not revising it ...
> 
> I have read the later posts but this one seemed to catch the crux of my
> discontent.
> 
> Tom Petch
> 
> > > Even worse, configuring protocol learned values is liable to break
> > > things.  To use one example, many
> protocols
> > > negotiate timers.  The value that a given systems starts with is the
> > > configured value.  The value that it learns from the protocol
> exchange is
> > > the operational value.  In fact, you better not try to configure
> that value
> > > or you are liable to break the protocol.
> >
> > Nobody proposed this, please take a look at the figure in the document
> > to understand the information flow and where the distinction is made.
> >
> > /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] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

[t.petch]

- Original Message -
From: "Juergen Schoenwaelder" 
Sent: Tuesday, June 20, 2017 8:40 PM

> On Tue, Jun 20, 2017 at 02:19:32PM -0400, Joel M. Halpern wrote:
> > I was going to just watch this, but I can't.
> >
> > To call protocol negotiated values "configuration" is to create a
usage
> > which will confuse MANY people.
>
> There are people who have a broad concept of configuration and there
> are people who have a narrow concept of configuration. There is not
> way to resolve this. All we can do is come up with a terminology that
> is consistent and can be used consistently.

Juergen, Robert,

This is what triggered my post (which I have been mulling ever since
ietf-netmod-revised-datastores appeared).

There has been a narrow (IMHO) definition in use for over a decade to
whit

'Configuration data is the set of writable data that is required to
   transform a system from its initial default state into its current
   state.  '

which I have accepted as the basis of this work (having previously used
a much wider definition) .

'Data that determines how a device behaves' seems to me a much wider
definition encompassing much of 'state' as has been defined for the past
decade.

I don't expect to have to read the rest of the I-D (about the kinds of
configuration) to find out that the definition does not mean what it
appears to say; I may have to read on to fully understand it but the
words as written seem to brook no misunderstanding!

Having ' This data is modeled in YANG using "config true" nodes ' sort
of suggests that the original definition holds sway and so contradicts
the previous sentence.  And for this sentence to make sense, a reader
would really have to understand the debates over configuration, state
and how to model them that have been going on for so long which means
that regardless of how true it is, it does not really belong in a
definition.

There is no reference back to the previous definition, as to whether or
not the latest definition is meant to be the same or not.  I find this
confusing.

I think that the previous definition has to appear in this I-D, since it
has influenced so much work, and this I-D then needs to go on to say

'We are revising it ..
or
'We are not revising it ...

I have read the later posts but this one seemed to catch the crux of my
discontent.

Tom Petch

> > Even worse, configuring protocol learned
> > values is liable to break things.  To use one example, many
protocols
> > negotiate timers.  The value that a given systems starts with is the
> > configured value.  The value that it learns from the protocol
exchange is
> > the operational value.  In fact, you better not try to configure
that value
> > or you are liable to break the protocol.
>
> Nobody proposed this, please take a look at the figure in the document
> to understand the information flow and where the distinction is made.
>
> /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] draft-vallin-netmod-alarm-module status and plans

[William Lupton]

Dear all,

We at the Broadband Forum (BBF) would like to reiterate our interest in the 
draft-vallin-netmod-alarm-module draft.

We will also have some technical comments / suggestions (internal discussion is 
ongoing) that we will share with NETMOD as soon as possible.

Thanks,
William

> On 31 May 2017, at 13:08, Benoit Claise  wrote:
> 
> William,
> 
> This was discussed with the authors, the NETMOD chairs, and the RTG AD 
> Deborah.
> The advice was for the authors to raise the draft in ccamp and try to 
> progress it there.
> 
> The authors updated their draft to version 2 and pinged the CCAMP mailing 
> list (https://www.ietf.org/mail-archive/web/ccamp/current/msg18124.html).
> From that email thread, it seems there is interest in the work, but where to 
> do the work is not clear.
> 
> My advice to the authors: continue progress this work and if CCAMP is not 
> interested or consider this work too generic, bring it back to NETMOD and 
> we'll follow normal WG process.
> 
> Regards, Benoit
>> All,
>> 
>> I heard from Kent that 
>> https://tools.ietf.org/html/draft-vallin-netmod-alarm-module was moving to 
>> CCAMP but I don’t see any mention of it at 
>> https://datatracker.ietf.org/wg/ccamp/documents (although it is shown as a 
>> dependency at https://datatracker.ietf.org/wg/ccamp/deps/svg). Is any more 
>> info available please?
>> 
>> Thanks,
>> William

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