Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Martin Bjorklund píše v Po 25. 09. 2017 v 11:57 +0200:
> > Ladislav Lhotka  wrote:
> > > Robert Wilton píše v Čt 21. 09. 2017 v 10:38 +0100:
> > 
> > 
> > [...]
> > 
> > > > Yes, I agree that this scenario is very likely, but I think that the 
> > 
> > > > solution here is just to not mark the leaf as mandatory.
> > 
> > > 
> > 
> > > But this makes the schema weaker, and implementors may think it needn't be
> > 
> > > implemented.
> > 
> > 
> > Whether the "mandatory" statement is present or not on a node has
> > nothing to do with what a device must implement.  "mandatory" does not
> > affect conformance.
> > 
> > As long as we don't have a more elaborate conformance mechanism, all
> > nodes in a module (modulo if-feature) must be implemented in order to
> > claim conformance to the module.  This said, there can be cases where
> 
> Section 5.6 in RFC 7950 describes conformance but I think it neither states 
> nor
> implies what you are saying. Specifically (in 5.6.5):
> 
>A server implements a module if it implements the module's data
>nodes, RPCs, actions, notifications, and deviations.
> 
> But what does "implements the module's data nodes" exactly mean?

It means that the device must implement whatever the defintion of that
node says, either with formal statements or in the description
statement.

> My
> interpretation is that if a node is optional, then it may or may not be
> implemented.

Which text supports this interpretation?  7950 doesn't use the term
"optional node", so I don't know what that is.  The text about the
"mandatory" statement in 7.6.5 says:

   The "mandatory" statement [...] puts a constraint on valid data.

It does not say "... means that a server MUST implement this node".


> > "implement" in reality translates to "never return", b/c the
> > conditions that would make the device instantiate the node are never
> > fulfilled.
> 
> Right, if a node is optional (with no default) then it may not exist in the 
> data
> tree (hence is never returned), and the client isn't able to tell whether it 
> is
> internally implemented or not.

Correct.


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

Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

[Ladislav Lhotka]

Martin Bjorklund píše v Po 25. 09. 2017 v 11:57 +0200:
> Ladislav Lhotka  wrote:
> > Robert Wilton píše v Čt 21. 09. 2017 v 10:38 +0100:
> 
> 
> [...]
> 
> > > Yes, I agree that this scenario is very likely, but I think that the 
> 
> > > solution here is just to not mark the leaf as mandatory.
> 
> > 
> 
> > But this makes the schema weaker, and implementors may think it needn't be
> 
> > implemented.
> 
> 
> Whether the "mandatory" statement is present or not on a node has
> nothing to do with what a device must implement.  "mandatory" does not
> affect conformance.
> 
> As long as we don't have a more elaborate conformance mechanism, all
> nodes in a module (modulo if-feature) must be implemented in order to
> claim conformance to the module.  This said, there can be cases where

Section 5.6 in RFC 7950 describes conformance but I think it neither states nor
implies what you are saying. Specifically (in 5.6.5):

   A server implements a module if it implements the module's data
   nodes, RPCs, actions, notifications, and deviations.

But what does "implements the module's data nodes" exactly mean? My
interpretation is that if a node is optional, then it may or may not be
implemented.

> "implement" in reality translates to "never return", b/c the
> conditions that would make the device instantiate the node are never
> fulfilled.

Right, if a node is optional (with no default) then it may not exist in the data
tree (hence is never returned), and the client isn't able to tell whether it is
internally implemented or not.

Lada

> 
> 
> 
> /martin
> 
> 
> 
> > 
> 
> > > 
> 
> > > It is interesting to consider what "mandatory" exactly means in the 
> 
> > >  datastore.  Given that the mandatory constraint may be
> 
> > 
> 
> > Yes, the semantics in the context of NM protocols is different from that of
> 
> > configuration datastores. But in the context of document (data tree)
> validation
> 
> > it is the same: the instance has to be present for a data tree to be valid. 
> 
> > 
> 
> > > violated in , then my interpretation is that it means that 
> 
> > > a correct implementation SHOULD always return a mandatory node (if it is 
> 
> > > in scope).  But a client has no way to force a device return this data 
> 
> > > (except perhaps shouting at the vendor :-), and so it seems that a 
> 
> > > robust client would need to be able to cope with the fact that the 
> 
> > > device is not behaving nicely and isn't returning the data regardless of 
> 
> > > any mandatory keyword specified in the schema.
> 
> > 
> 
> > I don't really share this view, it is IMO not much different from the
> situation
> 
> > when a vendor fails to implement a config node. Either way, the
> implementation
> 
> > doesn't conform to the data model.
> 
> > 
> 
> > One of the benefits of a data model is that an application can offload
> 
> > validation to an external tool, such as a generic YANG library, and then can
> 
> > rely on data being valid so that the application's code needn't be cluttered
> 
> > with all kinds of sanity checks.
> 
> > 
> 
> > I can imagine a tool collecting data from a number of devices that fails if
> a
> 
> > mandatory state data are absent.  
> 
> > 
> 
> > > 
> 
> > > To further expand on this, a device is required to ensure that 
> 
> > > configuration datastores are valid, and hence all mandatory constraints 
> 
> > > are enforced, or a config change would be rejected, but I don't think 
> 
> > > that many devices are going to validate operational. They will just
> 
> > > return the current state of the system back to the client, and let the 
> 
> > > client deal with any unexpected inconsistencies.
> 
> > 
> 
> > I could likewise expect the server to be prepared to deal with unexpected
> 
> > inconsistencies in config data. The data model is a contract, so it should
> be
> 
> > binding for both parties.
> 
> > 
> 
> > > 
> 
> > > Also, what about all the regular config false nodes in the schema that 
> 
> > > are not marked as mandatory?  Is a device always required to return 
> 
> > > those leaves (if they are in scope)?  If a device is never going to 
> 
> > 
> 
> > In terms of YANG, no.
> 
> > 
> 
> > > return those leaves then it should use a deviation to remove them, but 
> 
> > > is that actually required?
> 
> > > 
> 
> > > Is seems that possibly the most useful use of mandatory in the context 
> 
> > > of operational is for something like an IP address/prefix length 
> 
> > > pairing, i.e. to indicate that the data really doesn't make any sense 
> 
> > > unless both address and prefix are provided.
> 
> > > 
> 
> > > When the next version of YANG is specified, perhaps we should consider 
> 
> > > allowing an extra options to mandatory to that it only applies to the 
> 
> > > state datastores?  if so, we could add this to the YANG.Next issue
> tracker?
> 
> > 
> 
> > I believe the fundamental problem is that YANG was designed basically as a
> 
> > document-oriented schema language, 

Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

[Ladislav Lhotka]

Robert Wilton  writes:

> On 21/09/2017 16:10, Ladislav Lhotka wrote:
>> Robert Wilton píše v Čt 21. 09. 2017 v 10:38 +0100:
>>> On 20/09/2017 15:33, Ladislav Lhotka wrote:
 Robert Wilton  writes:

> On 19/09/2017 15:07, Ladislav Lhotka wrote:
>> Robert Wilton píše v Út 19. 09. 2017 v 14:49 +0100:
>>> Hi Lada,
>>>
>>>
>>> On 19/09/2017 14:37, Ladislav Lhotka wrote:
 Martin Bjorklund  writes:

> Ladislav Lhotka  wrote:
>> Hi,
>>
>> I support the adoption but I propose two conceptual changes:
>>
>> 1. Introduce a new module name and namespace so that it is not
>> necessary to carry along the deprecated baggage. If readability
>> is
>> the primary concern, this is IMO the way to go. Instead of
>> "ietf-ip-2", I'd suggest something like "ietf- ip-nmda".
>>
>> 2. Avoid obsoleting RFC 7277. I believe the old modules may
>> continue
>> to be used
>> in areas where NMDA is an overkill, such as open source home
>> routers.
> Why wouldn't NMDA be appropriate in an open source home
> router?  Note
> that the new model really just have a single tree instead of two
> trees, so the data that needs to be instrumented is more or less
> the
> same.
 It is quite likely that some parts of the data models will be
 implemented only as configuration but not state data. In the "old
 style"
 modules it is easy to add a deviation for the node(s) under -state
 but
 in NMDA style this is not possible because we only have one node.
>>> The new YANG library allows different sets of modules to be available
>>> for  datastores vs .   The operational
>>> datastore can also have different features supported and different
>>> deviations vs the conventional datastores.
>> OK, I missed the 7895bis draft, sorry. Then there could be differences
>> in
>> mandatory/optional (e.g. a node is optional in configuration but
>> mandatory in
>> state data) or the data type of a leaf can differ. How can these be
>> handled?
> If the data type of the leaf can differ, then normally this should be
> modeled as two separate leaves.  Do you have a concrete example of
> this?
 So, for example, duplex and duplex-state? And  will
 have both as siblings?
>>> Here I presume you are thinking that the configurable value for duplex
>>> is "full/half/auto", but the operational value is "full/half"?
>>>
>>> The solution here is really to model auto-negotiation on/off as a
>>> separate leaf (which also more closely reflects the actual behaviour of
>>> the auto-negotiation protocol).  Then for duplex both the space for both
>>> the configured and operational leaves are the same, i.e. both taking
>>> "full/half", and hence only a single leaf is required to model both the
>>> optional configured value and the operational value.
>> Yes, this sounds reasonable. Here also the config value should then be 
>> optional
>> while the state value mandatory.

> I think that this would mean that lots of "config false" leaves should 
> be marked mandatory.  But looking at the YANG models going through IETF 
> standardization that doesn't seem to be the case.

Many of them have defaults that effectively mean that the leaves have to
be implemented. Otherwise the guarantees provided by the data model are
really weaker - there is no way to tell whether a given server will send
a parameter or not.

>
> Perhaps a very simple device doesn't have the capability to report 
> duplexity because it is always full duplex, hence mandatory seems less

Then we have features and/or deviations to account for this.

> useful.  Or a device might be able to report duplexicty but not at that 
> instant in time (e.g. perhaps the optics module is missing)?  It seems 
> more natural for operational to say that if you don't know something 
> then don't return it.

Of course, transient effects need to be considered, and perhaps
statistics are also a bit special. But, for example, if an NM
application isn't able to learn actual router-id, it may be stuck.

>
> So, I wouldn't support marking this field as being mandatory in 
>  regardless of model structure.
>
>>> A concrete example of the Ethernet interface YANG structured this way is @
>>> https://github.com/8023YangDesignTeam/EthernetYang/blob/nmda/standard/ieee/802
>>> .3/draft/ieee802-ethernet-interface.yang
>>>
>>>
>>>
> If some data is mandatory in config, but not necessarily mandatory in
>  then normally it can be marked as mandatory true, since
> optional is allowed to violate this constraint if necessary, but
> implementations would generally be expected to conform to the constraint
> if possible.
>
> For the reverse case, we 

Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

[Juergen Schoenwaelder]

On Thu, Sep 21, 2017 at 05:10:52PM +0200, Ladislav Lhotka wrote:
> 
> I can imagine a tool collecting data from a number of devices that fails if a
> mandatory state data are absent.  
>

This is not a very robust tool. There are other reasons why a leaf may
be absert, e.g., an access control rule. In general, there is no
requirement that state data is reported as consistent snapshots, so
robust tools will have to be somewhat tolerant anyway.

> I could likewise expect the server to be prepared to deal with unexpected
> inconsistencies in config data. The data model is a contract, so it should be
> binding for both parties.

The server is prepared; it fails the commit if configuration data is
unexpectedly inconsistent.

/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] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

[Ladislav Lhotka]

Robert Wilton  writes:

> On 19/09/2017 15:07, Ladislav Lhotka wrote:
>> Robert Wilton píše v Út 19. 09. 2017 v 14:49 +0100:
>>> Hi Lada,
>>>
>>>
>>> On 19/09/2017 14:37, Ladislav Lhotka wrote:
 Martin Bjorklund  writes:

> Ladislav Lhotka  wrote:
>> Hi,
>>
>> I support the adoption but I propose two conceptual changes:
>>
>> 1. Introduce a new module name and namespace so that it is not
>> necessary to carry along the deprecated baggage. If readability is
>> the primary concern, this is IMO the way to go. Instead of
>> "ietf-ip-2", I'd suggest something like "ietf- ip-nmda".
>>
>> 2. Avoid obsoleting RFC 7277. I believe the old modules may continue
>> to be used
>> in areas where NMDA is an overkill, such as open source home
>> routers.
> Why wouldn't NMDA be appropriate in an open source home router?  Note
> that the new model really just have a single tree instead of two
> trees, so the data that needs to be instrumented is more or less the
> same.
 It is quite likely that some parts of the data models will be
 implemented only as configuration but not state data. In the "old style"
 modules it is easy to add a deviation for the node(s) under -state but
 in NMDA style this is not possible because we only have one node.
>>> The new YANG library allows different sets of modules to be available
>>> for  datastores vs .   The operational
>>> datastore can also have different features supported and different
>>> deviations vs the conventional datastores.
>> OK, I missed the 7895bis draft, sorry. Then there could be differences in
>> mandatory/optional (e.g. a node is optional in configuration but mandatory in
>> state data) or the data type of a leaf can differ. How can these be handled?
> If the data type of the leaf can differ, then normally this should be 
> modeled as two separate leaves.  Do you have a concrete example of
> this?

So, for example, duplex and duplex-state? And  will
have both as siblings?

>
> If some data is mandatory in config, but not necessarily mandatory in 
>  then normally it can be marked as mandatory true, since 
> optional is allowed to violate this constraint if necessary, but 
> implementations would generally be expected to conform to the constraint 
> if possible.
>
> For the reverse case, we can't express that.  I think that you would 
> have to leave out the "mandatory: true" constraint.  Again, can you 
> provide a concrete example of this please?  That makes it a bit easier 
> to reason about.

This should be quite typical: a config leaf is optional and if it is not
configured, the system sets it to some value (as in the case of
router-id). But in state data it is mandatory so that the client can see
what the system chose.

Lada

>
> Thanks,
> Rob
>
>
>>
>> Lada
>>
>>> So, the device can make the same deviations to remove the state leaves
>>> from .  Or if they don't want to support the module in
>>> operational at all then a device could just list it as being supported
>>> in the conventional datastores and not .
>>>
 There are subtle differences in the schemas for configuration and state
 data that the NMDA concept doesn't address. If you want another example,
 ietf-routing-2 has the "router-id" leaf that is conditional via the
 "router-id" feature. If this feature is not supported, router-id cannot
 be explicitly configured (it is assigned by the system) but in state data
 "router-id" needs IMO be present in any case. But the if-feature
 isn't able to differentiate between configuration and state data if
 there is only one node for both.
>>> The new YANG library also supports this:
>>>
>>> The "router-id" feature would be disabled for the conventional
>>> datastores, but enabled for .
>>>
> In fact, if we claim that the new architecture is not appropriate for
> some devices I think we have failed, especially if the conclusion is
> that we need to maintain two versions of all modules going forward.
 I am not asking for this but, on the other hand, if NMDA versions used a 
 new
 module name and namespace (my item #1, which is what ietf-routing-2
 does), then I don't see any pressing need for obsoleting the old style
 modules.
>>> I think that creating a "-2" versions of these models at this time might
>>> be a mistake.  I actually think that the "deprecate state leaves" ->
>>> "obsolete state leaves" -> "delete state leaves" path is a better choice.
>>>
>>> Thanks,
>>> Rob
>>>
>>>
 Lada

> /martin
>
>
>
>
>
>
>> NMDA
>> implementors should be aware of the new modules but there is no need to
>> eradicate the old data models.
>>
>> #2 applies also to other modules for which the NMDA version is underway.
>>
>> Lada
>>
>> PS. The subject is wrong, it shoud be -rfc7277bis-
>>
>> Lou 

Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

[t.petch]

- Original Message -
From: "Robert Wilton" 
Sent: Wednesday, September 20, 2017 12:04 PM

> On 20/09/2017 11:18, t.petch wrote:
> > - Original Message -
> > From: "Ladislav Lhotka" 
> > Sent: Tuesday, September 19, 2017 2:37 PM
> >
> >> Martin Bjorklund  writes:
> >>
> >>> Ladislav Lhotka  wrote:
> 
>  I support the adoption but I propose two conceptual changes:
> 
>  1. Introduce a new module name and namespace so that it is not
>  necessary to carry along the deprecated baggage. If readability
is
>  the primary concern, this is IMO the way to go. Instead of
>  "ietf-ip-2", I'd suggest something like "ietf- ip-nmda".
> 
>  2. Avoid obsoleting RFC 7277. I believe the old modules may
> > continue
>  to be used
>  in areas where NMDA is an overkill, such as open source home
>  routers.
> >>> Why wouldn't NMDA be appropriate in an open source home router?
> > Note
> >>> that the new model really just have a single tree instead of two
> >>> trees, so the data that needs to be instrumented is more or less
the
> >>> same.
> >> It is quite likely that some parts of the data models will be
> >> implemented only as configuration but not state data. In the "old
> > style"
> >> modules it is easy to add a deviation for the node(s) under -state
but
> >> in NMDA style this is not possible because we only have one node.
> >>
> >> There are subtle differences in the schemas for configuration and
> > state
> >> data that the NMDA concept doesn't address. If you want another
> > example,
> >> ietf-routing-2 has the "router-id" leaf that is conditional via the
> >> "router-id" feature. If this feature is not supported, router-id
> > cannot
> >> be explicitly configured (it is assigned by the system) but in
state
> > data
> >> "router-id" needs IMO be present in any case. But the if-feature
> >> isn't able to differentiate between configuration and state data if
> >> there is only one node for both.
> > So add a second node!  I think that the idea that NMDA eliminates
all
> > duplication of config and state is a myth; there will still be
> > duplication where the life cycle of the data diverges, ie it is not
> > really duplication! I think too that the twin trees approach, while
> > clumsy, was easy to create;
> Easy to create, but just as easy to get wrong. Alas, with the twin
> trees approach, the config and state trees can (and do) diverge.
> Different WGs within IETF were already starting to model the state
> information with different tree structures. Some WG models includes
the
> applied config value, others didn't. We seemed to be loosing
> consistency between the model. My opinion is that the end outcome of
> this would effectively require all clients to write custom code to
> correlate equivalent information between the config and its related
> state, which doesn't seem great.
>
> >   the NMDA approach is more subtle, more
> > complex, easier to get wrong.
> Yes, I agree the NMDA approach is a bit more subtle. And there are
> definitely some concepts that probably should be modeled slightly
> differently:
>
> A case in point might be "interface MTU" that can be automatically
> assigned (the default behaviour) or statically configured.
>
> (1) A pre-NMDA split config/state model might have:
> - a config true interfaces/mtu leaf that is either "auto" or a
specific
> value,
> - a config false interfaces-state/mtu leaf holding the actual
> operational value,
> - [potentially also a config false interfaces-state/cfgd-mtu leaf
> indicating the applied config value.]
>
> (2) One way of modelling this in NMDA would be to split whether mtu
was
> auto vs manually configured separately from the mtu value. So this
> could be modeled as:
> - one config true leaf that represents with MTU is automatic or
manually
> configured.
> --one config true leaf that represents the manually configured and
> operational MTU value. Allow with an appropriate constraint so that
> both leaves are not configured.
>
> (3) Alternatively, in both pre NMDA or post NMDA, the model could
assume
> "automatic" as the implicit default MTU behaviour. In this case you
> only need to have a single leaf in the NMDA model (or 2 leaves in the
> split model).
>   - one config true leaf that represents the operational MTU of the
> interface, which may be configured if a specific value is to be
enforced.
>
> For MTU, it is the third approach that I prefer.
>
> Another similar example is Ethernet auto-negotiation, where (2) looks
> like the best approach post NMDA with an explicit leaf to control
> whether the auto-negotiation protocol is enabled (rather than
attempting
> to merge it with the speed, duplex, and flow-control leaves). But in
> the end, (2) also has the added benefit that it actually more closely
> marries up to how the auto-negotiation protocol is defined, and what
> functionality is actually allowed.
>
> I think that 

Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

[Robert Wilton]

On 20/09/2017 11:18, t.petch wrote:

- Original Message -
From: "Ladislav Lhotka" 
Sent: Tuesday, September 19, 2017 2:37 PM


Martin Bjorklund  writes:


Ladislav Lhotka  wrote:

Hi,

I support the adoption but I propose two conceptual changes:

1. Introduce a new module name and namespace so that it is not
necessary to carry along the deprecated baggage. If readability is
the primary concern, this is IMO the way to go. Instead of
"ietf-ip-2", I'd suggest something like "ietf- ip-nmda".

2. Avoid obsoleting RFC 7277. I believe the old modules may

continue

to be used
in areas where NMDA is an overkill, such as open source home
routers.

Why wouldn't NMDA be appropriate in an open source home router?

Note

that the new model really just have a single tree instead of two
trees, so the data that needs to be instrumented is more or less the
same.

It is quite likely that some parts of the data models will be
implemented only as configuration but not state data. In the "old

style"

modules it is easy to add a deviation for the node(s) under -state but
in NMDA style this is not possible because we only have one node.

There are subtle differences in the schemas for configuration and

state

data that the NMDA concept doesn't address. If you want another

example,

ietf-routing-2 has the "router-id" leaf that is conditional via the
"router-id" feature. If this feature is not supported, router-id

cannot

be explicitly configured (it is assigned by the system) but in state

data

"router-id" needs IMO be present in any case. But the if-feature
isn't able to differentiate between configuration and state data if
there is only one node for both.

So add a second node!  I think that the idea that NMDA eliminates all
duplication of config and state is a myth; there will still be
duplication where the life cycle of the data diverges, ie it is not
really duplication! I think too that the twin trees approach, while
clumsy, was easy to create;
Easy to create, but just as easy to get wrong.  Alas, with the twin 
trees approach, the config and state trees can (and do) diverge. 
Different WGs within IETF were already starting to model the state 
information with different tree structures.  Some WG models includes the 
applied config value, others didn't.  We seemed to be loosing 
consistency between the model.  My opinion is that the end outcome of 
this would effectively require all clients to write custom code to 
correlate equivalent information between the config and its related 
state, which doesn't seem great.



  the NMDA approach is more subtle, more
complex, easier to get wrong.
Yes, I agree the NMDA approach is a bit more subtle. And there are 
definitely some concepts that probably should be modeled slightly 
differently:


A case in point might be "interface MTU" that can be automatically 
assigned (the default behaviour) or statically configured.


(1) A pre-NMDA split config/state model might have:
- a config true interfaces/mtu leaf that is either "auto" or a specific 
value,
- a config false interfaces-state/mtu leaf holding the actual 
operational value,
- [potentially also a config false interfaces-state/cfgd-mtu leaf 
indicating the applied config value.]


(2) One way of modelling this in NMDA would be to split whether mtu was 
auto vs manually configured separately from the mtu value.  So this 
could be modeled as:
- one config true leaf that represents with MTU is automatic or manually 
configured.
--one config true leaf that represents the manually configured and 
operational MTU value.  Allow with an appropriate constraint so that 
both leaves are not configured.


(3) Alternatively, in both pre NMDA or post NMDA, the model could assume 
"automatic" as the implicit default MTU behaviour.  In this case you 
only need to have a single leaf in the NMDA model (or 2 leaves in the 
split model).
 - one config true leaf that represents the operational MTU of the 
interface, which may be configured if a specific value is to be enforced.


For MTU, it is the third approach that I prefer.

Another similar example is Ethernet auto-negotiation, where (2) looks 
like the best approach post NMDA with an explicit leaf to control 
whether the auto-negotiation protocol is enabled (rather than attempting 
to merge it with the speed, duplex, and flow-control leaves).  But in 
the end, (2) also has the added benefit that it actually more closely 
marries up to how the auto-negotiation protocol is defined, and what 
functionality is actually allowed.


I think that building up a set of these examples (probably on an FAQ), 
of how particular abstract concepts can be effectively modeled may make 
it a bit easier when folks are trying to figure out the best way of 
modeling something in the post NMDA world.




I recall that in the initial stages of discussion of this issue there
was a proposal for an object to have potentially eight different
characteristics so 

Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

[t.petch]

- Original Message -
From: "Ladislav Lhotka" 
Sent: Tuesday, September 19, 2017 2:37 PM

> Martin Bjorklund  writes:
>
> > Ladislav Lhotka  wrote:
> >> Hi,
> >>
> >> I support the adoption but I propose two conceptual changes:
> >>
> >> 1. Introduce a new module name and namespace so that it is not
> >> necessary to carry along the deprecated baggage. If readability is
> >> the primary concern, this is IMO the way to go. Instead of
> >> "ietf-ip-2", I'd suggest something like "ietf- ip-nmda".
> >>
> >> 2. Avoid obsoleting RFC 7277. I believe the old modules may
continue
> >> to be used
> >> in areas where NMDA is an overkill, such as open source home
> >> routers.
> >
> > Why wouldn't NMDA be appropriate in an open source home router?
Note
> > that the new model really just have a single tree instead of two
> > trees, so the data that needs to be instrumented is more or less the
> > same.
>
> It is quite likely that some parts of the data models will be
> implemented only as configuration but not state data. In the "old
style"
> modules it is easy to add a deviation for the node(s) under -state but
> in NMDA style this is not possible because we only have one node.
>
> There are subtle differences in the schemas for configuration and
state
> data that the NMDA concept doesn't address. If you want another
example,
> ietf-routing-2 has the "router-id" leaf that is conditional via the
> "router-id" feature. If this feature is not supported, router-id
cannot
> be explicitly configured (it is assigned by the system) but in state
data
> "router-id" needs IMO be present in any case. But the if-feature
> isn't able to differentiate between configuration and state data if
> there is only one node for both.

So add a second node!  I think that the idea that NMDA eliminates all
duplication of config and state is a myth; there will still be
duplication where the life cycle of the data diverges, ie it is not
really duplication! I think too that the twin trees approach, while
clumsy, was easy to create; the NMDA approach is more subtle, more
complex, easier to get wrong.

I recall that in the initial stages of discussion of this issue there
was a proposal for an object to have potentially eight different
characteristics so what NMDA gives us at present is limited and will not
solve all the issues of needing more than one node.

Tom Petch








>
> >
> > In fact, if we claim that the new architecture is not appropriate
for
> > some devices I think we have failed, especially if the conclusion is
> > that we need to maintain two versions of all modules going forward.
>
> I am not asking for this but, on the other hand, if NMDA versions used
a new
> module name and namespace (my item #1, which is what ietf-routing-2
> does), then I don't see any pressing need for obsoleting the old style
> modules.
>
> Lada
>
> >
> >
> > /martin
> >
> >
> >
> >
> >
> >
> >> NMDA
> >> implementors should be aware of the new modules but there is no
need to
> >> eradicate the old data models.
> >>
> >> #2 applies also to other modules for which the NMDA version is
underway.
> >>
> >> Lada
> >>
> >> PS. The subject is wrong, it shoud be -rfc7277bis-
> >>
> >> Lou Berger píše v Po 18. 09. 2017 v 10:33 -0400:
> >> > All,
> >> >
> >> > This is start of a two week poll on making
> >> > draft-bjorklund-netmod-rfc7227bis-00 a working group document.
Please
> >> > send email to the list indicating "yes/support" or "no/do not
support".
> >> > If indicating no, please state your reservations with the
document.  If
> >> > yes, please also feel free to provide comments you'd like to see
> >> > addressed once the document is a WG document.
> >> >
> >> > The poll ends Oct 2.
> >> >
> >> > Thanks,
> >> >
> >> > Lou (and Kent)
> >> >
> >> > ___
> >> > netmod mailing list
> >> > netmod@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/netmod
> >> --
> >> Ladislav Lhotka
> >> Head, CZ.NIC Labs
> >> PGP Key ID: 0xB8F92B08A9F76C67
> >>
> >> ___
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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

Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

[Robert Wilton]

On 19/09/2017 15:07, Ladislav Lhotka wrote:

Robert Wilton píše v Út 19. 09. 2017 v 14:49 +0100:

Hi Lada,


On 19/09/2017 14:37, Ladislav Lhotka wrote:

Martin Bjorklund  writes:


Ladislav Lhotka  wrote:

Hi,

I support the adoption but I propose two conceptual changes:

1. Introduce a new module name and namespace so that it is not
necessary to carry along the deprecated baggage. If readability is
the primary concern, this is IMO the way to go. Instead of
"ietf-ip-2", I'd suggest something like "ietf- ip-nmda".

2. Avoid obsoleting RFC 7277. I believe the old modules may continue
to be used
in areas where NMDA is an overkill, such as open source home
routers.

Why wouldn't NMDA be appropriate in an open source home router?  Note
that the new model really just have a single tree instead of two
trees, so the data that needs to be instrumented is more or less the
same.

It is quite likely that some parts of the data models will be
implemented only as configuration but not state data. In the "old style"
modules it is easy to add a deviation for the node(s) under -state but
in NMDA style this is not possible because we only have one node.

The new YANG library allows different sets of modules to be available
for  datastores vs .   The operational
datastore can also have different features supported and different
deviations vs the conventional datastores.

OK, I missed the 7895bis draft, sorry. Then there could be differences in
mandatory/optional (e.g. a node is optional in configuration but mandatory in
state data) or the data type of a leaf can differ. How can these be handled?
If the data type of the leaf can differ, then normally this should be 
modeled as two separate leaves.  Do you have a concrete example of this?


If some data is mandatory in config, but not necessarily mandatory in 
 then normally it can be marked as mandatory true, since 
optional is allowed to violate this constraint if necessary, but 
implementations would generally be expected to conform to the constraint 
if possible.


For the reverse case, we can't express that.  I think that you would 
have to leave out the "mandatory: true" constraint.  Again, can you 
provide a concrete example of this please?  That makes it a bit easier 
to reason about.


Thanks,
Rob




Lada


So, the device can make the same deviations to remove the state leaves
from .  Or if they don't want to support the module in
operational at all then a device could just list it as being supported
in the conventional datastores and not .


There are subtle differences in the schemas for configuration and state
data that the NMDA concept doesn't address. If you want another example,
ietf-routing-2 has the "router-id" leaf that is conditional via the
"router-id" feature. If this feature is not supported, router-id cannot
be explicitly configured (it is assigned by the system) but in state data
"router-id" needs IMO be present in any case. But the if-feature
isn't able to differentiate between configuration and state data if
there is only one node for both.

The new YANG library also supports this:

The "router-id" feature would be disabled for the conventional
datastores, but enabled for .


In fact, if we claim that the new architecture is not appropriate for
some devices I think we have failed, especially if the conclusion is
that we need to maintain two versions of all modules going forward.

I am not asking for this but, on the other hand, if NMDA versions used a new
module name and namespace (my item #1, which is what ietf-routing-2
does), then I don't see any pressing need for obsoleting the old style
modules.

I think that creating a "-2" versions of these models at this time might
be a mistake.  I actually think that the "deprecate state leaves" ->
"obsolete state leaves" -> "delete state leaves" path is a better choice.

Thanks,
Rob



Lada


/martin







NMDA
implementors should be aware of the new modules but there is no need to
eradicate the old data models.

#2 applies also to other modules for which the NMDA version is underway.

Lada

PS. The subject is wrong, it shoud be -rfc7277bis-
   
Lou Berger píše v Po 18. 09. 2017 v 10:33 -0400:

All,

This is start of a two week poll on making
draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
send email to the list indicating "yes/support" or "no/do not
support".
If indicating no, please state your reservations with the
document.  If
yes, please also feel free to provide comments you'd like to see
addressed once the document is a WG document.

The poll ends Oct 2.

Thanks,

Lou (and Kent)

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

--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

[Ladislav Lhotka]

Robert Wilton píše v Út 19. 09. 2017 v 14:49 +0100:
> Hi Lada,
> 
> 
> On 19/09/2017 14:37, Ladislav Lhotka wrote:
> > Martin Bjorklund  writes:
> > 
> > > Ladislav Lhotka  wrote:
> > > > Hi,
> > > > 
> > > > I support the adoption but I propose two conceptual changes:
> > > > 
> > > > 1. Introduce a new module name and namespace so that it is not
> > > > necessary to carry along the deprecated baggage. If readability is
> > > > the primary concern, this is IMO the way to go. Instead of
> > > > "ietf-ip-2", I'd suggest something like "ietf- ip-nmda".
> > > > 
> > > > 2. Avoid obsoleting RFC 7277. I believe the old modules may continue
> > > > to be used
> > > > in areas where NMDA is an overkill, such as open source home
> > > > routers.
> > > 
> > > Why wouldn't NMDA be appropriate in an open source home router?  Note
> > > that the new model really just have a single tree instead of two
> > > trees, so the data that needs to be instrumented is more or less the
> > > same.
> > 
> > It is quite likely that some parts of the data models will be
> > implemented only as configuration but not state data. In the "old style"
> > modules it is easy to add a deviation for the node(s) under -state but
> > in NMDA style this is not possible because we only have one node.
> 
> The new YANG library allows different sets of modules to be available 
> for  datastores vs .   The operational 
> datastore can also have different features supported and different 
> deviations vs the conventional datastores.

OK, I missed the 7895bis draft, sorry. Then there could be differences in
mandatory/optional (e.g. a node is optional in configuration but mandatory in
state data) or the data type of a leaf can differ. How can these be handled?

Lada 

> 
> So, the device can make the same deviations to remove the state leaves 
> from .  Or if they don't want to support the module in 
> operational at all then a device could just list it as being supported 
> in the conventional datastores and not .
> 
> > 
> > There are subtle differences in the schemas for configuration and state
> > data that the NMDA concept doesn't address. If you want another example,
> > ietf-routing-2 has the "router-id" leaf that is conditional via the
> > "router-id" feature. If this feature is not supported, router-id cannot
> > be explicitly configured (it is assigned by the system) but in state data
> > "router-id" needs IMO be present in any case. But the if-feature
> > isn't able to differentiate between configuration and state data if
> > there is only one node for both.
> 
> The new YANG library also supports this:
> 
> The "router-id" feature would be disabled for the conventional 
> datastores, but enabled for .
> 
> > 
> > > In fact, if we claim that the new architecture is not appropriate for
> > > some devices I think we have failed, especially if the conclusion is
> > > that we need to maintain two versions of all modules going forward.
> > 
> > I am not asking for this but, on the other hand, if NMDA versions used a new
> > module name and namespace (my item #1, which is what ietf-routing-2
> > does), then I don't see any pressing need for obsoleting the old style
> > modules.
> 
> I think that creating a "-2" versions of these models at this time might 
> be a mistake.  I actually think that the "deprecate state leaves" -> 
> "obsolete state leaves" -> "delete state leaves" path is a better choice.
> 
> Thanks,
> Rob
> 
> 
> > 
> > Lada
> > 
> > > 
> > > /martin
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > > NMDA
> > > > implementors should be aware of the new modules but there is no need to
> > > > eradicate the old data models.
> > > > 
> > > > #2 applies also to other modules for which the NMDA version is underway.
> > > > 
> > > > Lada
> > > > 
> > > > PS. The subject is wrong, it shoud be -rfc7277bis-
> > > >   
> > > > Lou Berger píše v Po 18. 09. 2017 v 10:33 -0400:
> > > > > All,
> > > > > 
> > > > > This is start of a two week poll on making
> > > > > draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
> > > > > send email to the list indicating "yes/support" or "no/do not
> > > > > support".
> > > > > If indicating no, please state your reservations with the
> > > > > document.  If
> > > > > yes, please also feel free to provide comments you'd like to see
> > > > > addressed once the document is a WG document.
> > > > > 
> > > > > The poll ends Oct 2.
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > Lou (and Kent)
> > > > > 
> > > > > ___
> > > > > netmod mailing list
> > > > > netmod@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > 
> > > > -- 
> > > > Ladislav Lhotka
> > > > Head, CZ.NIC Labs
> > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > 
> > > > ___
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> 
> 

Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

[Robert Wilton]

Hi Lada,


On 19/09/2017 14:37, Ladislav Lhotka wrote:

Martin Bjorklund  writes:


Ladislav Lhotka  wrote:

Hi,

I support the adoption but I propose two conceptual changes:

1. Introduce a new module name and namespace so that it is not
necessary to carry along the deprecated baggage. If readability is
the primary concern, this is IMO the way to go. Instead of
"ietf-ip-2", I'd suggest something like "ietf- ip-nmda".

2. Avoid obsoleting RFC 7277. I believe the old modules may continue
to be used
in areas where NMDA is an overkill, such as open source home
routers.

Why wouldn't NMDA be appropriate in an open source home router?  Note
that the new model really just have a single tree instead of two
trees, so the data that needs to be instrumented is more or less the
same.

It is quite likely that some parts of the data models will be
implemented only as configuration but not state data. In the "old style"
modules it is easy to add a deviation for the node(s) under -state but
in NMDA style this is not possible because we only have one node.
The new YANG library allows different sets of modules to be available 
for  datastores vs .   The operational 
datastore can also have different features supported and different 
deviations vs the conventional datastores.


So, the device can make the same deviations to remove the state leaves 
from .  Or if they don't want to support the module in 
operational at all then a device could just list it as being supported 
in the conventional datastores and not .




There are subtle differences in the schemas for configuration and state
data that the NMDA concept doesn't address. If you want another example,
ietf-routing-2 has the "router-id" leaf that is conditional via the
"router-id" feature. If this feature is not supported, router-id cannot
be explicitly configured (it is assigned by the system) but in state data
"router-id" needs IMO be present in any case. But the if-feature
isn't able to differentiate between configuration and state data if
there is only one node for both.

The new YANG library also supports this:

The "router-id" feature would be disabled for the conventional 
datastores, but enabled for .





In fact, if we claim that the new architecture is not appropriate for
some devices I think we have failed, especially if the conclusion is
that we need to maintain two versions of all modules going forward.

I am not asking for this but, on the other hand, if NMDA versions used a new
module name and namespace (my item #1, which is what ietf-routing-2
does), then I don't see any pressing need for obsoleting the old style
modules.
I think that creating a "-2" versions of these models at this time might 
be a mistake.  I actually think that the "deprecate state leaves" -> 
"obsolete state leaves" -> "delete state leaves" path is a better choice.


Thanks,
Rob




Lada



/martin







NMDA
implementors should be aware of the new modules but there is no need to
eradicate the old data models.

#2 applies also to other modules for which the NMDA version is underway.

Lada

PS. The subject is wrong, it shoud be -rfc7277bis-
  
Lou Berger píše v Po 18. 09. 2017 v 10:33 -0400:

All,

This is start of a two week poll on making
draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
send email to the list indicating "yes/support" or "no/do not support".
If indicating no, please state your reservations with the document.  If
yes, please also feel free to provide comments you'd like to see
addressed once the document is a WG document.

The poll ends Oct 2.

Thanks,

Lou (and Kent)

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

--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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


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

Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

[Ladislav Lhotka]

Martin Bjorklund  writes:

> Ladislav Lhotka  wrote:
>> Hi,
>> 
>> I support the adoption but I propose two conceptual changes:
>> 
>> 1. Introduce a new module name and namespace so that it is not
>> necessary to carry along the deprecated baggage. If readability is
>> the primary concern, this is IMO the way to go. Instead of
>> "ietf-ip-2", I'd suggest something like "ietf- ip-nmda".
>> 
>> 2. Avoid obsoleting RFC 7277. I believe the old modules may continue
>> to be used 
>> in areas where NMDA is an overkill, such as open source home
>> routers.
>
> Why wouldn't NMDA be appropriate in an open source home router?  Note
> that the new model really just have a single tree instead of two
> trees, so the data that needs to be instrumented is more or less the
> same.

It is quite likely that some parts of the data models will be
implemented only as configuration but not state data. In the "old style"
modules it is easy to add a deviation for the node(s) under -state but
in NMDA style this is not possible because we only have one node.

There are subtle differences in the schemas for configuration and state
data that the NMDA concept doesn't address. If you want another example,
ietf-routing-2 has the "router-id" leaf that is conditional via the
"router-id" feature. If this feature is not supported, router-id cannot
be explicitly configured (it is assigned by the system) but in state data
"router-id" needs IMO be present in any case. But the if-feature
isn't able to differentiate between configuration and state data if
there is only one node for both.

>
> In fact, if we claim that the new architecture is not appropriate for
> some devices I think we have failed, especially if the conclusion is
> that we need to maintain two versions of all modules going forward.

I am not asking for this but, on the other hand, if NMDA versions used a new
module name and namespace (my item #1, which is what ietf-routing-2
does), then I don't see any pressing need for obsoleting the old style
modules.

Lada

>
>
> /martin
>
>
>
>
>
>
>> NMDA
>> implementors should be aware of the new modules but there is no need to
>> eradicate the old data models.
>> 
>> #2 applies also to other modules for which the NMDA version is underway.
>> 
>> Lada
>> 
>> PS. The subject is wrong, it shoud be -rfc7277bis-
>>  
>> Lou Berger píše v Po 18. 09. 2017 v 10:33 -0400:
>> > All,
>> > 
>> > This is start of a two week poll on making
>> > draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
>> > send email to the list indicating "yes/support" or "no/do not support".
>> > If indicating no, please state your reservations with the document.  If
>> > yes, please also feel free to provide comments you'd like to see
>> > addressed once the document is a WG document.
>> > 
>> > The poll ends Oct 2.
>> > 
>> > Thanks,
>> > 
>> > Lou (and Kent)
>> > 
>> > ___
>> > netmod mailing list
>> > netmod@ietf.org
>> > https://www.ietf.org/mailman/listinfo/netmod
>> -- 
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

[Juergen Schoenwaelder]

I believe that starting a new model would cause a real pain since any
model augmentations now need to augment two differnet versions of the
IP model. (Actually any model references may cause extra work.)

I also believe that view that NMDA is for big gear but not for small
gear is not quite right. Differences between operational state and
config state exists in almost all systems I have seen. The /foo and
/foo-state approach came out of long discussions about how to model
interfaces (Lada should recall this) and it was kind of clear even
back then that /foo and /foo-state was just a 'hack', given the
specifications we had to work with. NMDA simplifies models and we
would be failing badly if we now start maintaining multiple versions
of models.

/js

On Tue, Sep 19, 2017 at 11:46:57AM +0200, Ladislav Lhotka wrote:
> Hi,
> 
> I support the adoption but I propose two conceptual changes:
> 
> 1. Introduce a new module name and namespace so that it is not necessary to
> carry along the deprecated baggage. If readability is the primary concern, 
> this
> is IMO the way to go. Instead of "ietf-ip-2", I'd suggest something like 
> "ietf-
> ip-nmda".
> 
> 2. Avoid obsoleting RFC 7277. I believe the old modules may continue to be 
> used
> in areas where NMDA is an overkill, such as open source home routers. NMDA
> implementors should be aware of the new modules but there is no need to
> eradicate the old data models.
> 
> #2 applies also to other modules for which the NMDA version is underway.
> 
> Lada
> 
> PS. The subject is wrong, it shoud be -rfc7277bis-
>  
> Lou Berger píše v Po 18. 09. 2017 v 10:33 -0400:
> > All,
> > 
> > This is start of a two week poll on making
> > draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
> > send email to the list indicating "yes/support" or "no/do not support".
> > If indicating no, please state your reservations with the document.  If
> > yes, please also feel free to provide comments you'd like to see
> > addressed once the document is a WG document.
> > 
> > The poll ends Oct 2.
> > 
> > Thanks,
> > 
> > Lou (and Kent)
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

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

Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Hi,
> 
> I support the adoption but I propose two conceptual changes:
> 
> 1. Introduce a new module name and namespace so that it is not
> necessary to carry along the deprecated baggage. If readability is
> the primary concern, this is IMO the way to go. Instead of
> "ietf-ip-2", I'd suggest something like "ietf- ip-nmda".
> 
> 2. Avoid obsoleting RFC 7277. I believe the old modules may continue
> to be used 
> in areas where NMDA is an overkill, such as open source home
> routers.

Why wouldn't NMDA be appropriate in an open source home router?  Note
that the new model really just have a single tree instead of two
trees, so the data that needs to be instrumented is more or less the
same.

In fact, if we claim that the new architecture is not appropriate for
some devices I think we have failed, especially if the conclusion is
that we need to maintain two versions of all modules going forward.


/martin






> NMDA
> implementors should be aware of the new modules but there is no need to
> eradicate the old data models.
> 
> #2 applies also to other modules for which the NMDA version is underway.
> 
> Lada
> 
> PS. The subject is wrong, it shoud be -rfc7277bis-
>  
> Lou Berger píše v Po 18. 09. 2017 v 10:33 -0400:
> > All,
> > 
> > This is start of a two week poll on making
> > draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
> > send email to the list indicating "yes/support" or "no/do not support".
> > If indicating no, please state your reservations with the document.  If
> > yes, please also feel free to provide comments you'd like to see
> > addressed once the document is a WG document.
> > 
> > The poll ends Oct 2.
> > 
> > Thanks,
> > 
> > Lou (and Kent)
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

[Ladislav Lhotka]

Hi,

I support the adoption but I propose two conceptual changes:

1. Introduce a new module name and namespace so that it is not necessary to
carry along the deprecated baggage. If readability is the primary concern, this
is IMO the way to go. Instead of "ietf-ip-2", I'd suggest something like "ietf-
ip-nmda".

2. Avoid obsoleting RFC 7277. I believe the old modules may continue to be used
in areas where NMDA is an overkill, such as open source home routers. NMDA
implementors should be aware of the new modules but there is no need to
eradicate the old data models.

#2 applies also to other modules for which the NMDA version is underway.

Lada

PS. The subject is wrong, it shoud be -rfc7277bis-
 
Lou Berger píše v Po 18. 09. 2017 v 10:33 -0400:
> All,
> 
> This is start of a two week poll on making
> draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
> send email to the list indicating "yes/support" or "no/do not support".
> If indicating no, please state your reservations with the document.  If
> yes, please also feel free to provide comments you'd like to see
> addressed once the document is a WG document.
> 
> The poll ends Oct 2.
> 
> Thanks,
> 
> Lou (and Kent)
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

[netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

[Lou Berger]

All,

This is start of a two week poll on making
draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
send email to the list indicating "yes/support" or "no/do not support".
If indicating no, please state your reservations with the document.  If
yes, please also feel free to provide comments you'd like to see
addressed once the document is a WG document.

The poll ends Oct 2.

Thanks,

Lou (and Kent)

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

[netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00 (resend)

[Lou Berger]

All,

This is start of a two week poll on making
draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
send email to the list indicating "yes/support" or "no/do not support".
If indicating no, please state your reservations with the document.  If
yes, please also feel free to provide comments you'd like to see
addressed once the document is a WG document.

The poll ends Oct 2.

Thanks,

Lou (and Kent)

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