date:20170109

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

2017-01-09 Thread Juergen Schoenwaelder

On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote:
> 
> I think itt is not realistic to say that datastores are optional.
> 
> e.g.  leaf:  If there is a standard way to enable/disable config
> then individual "enabled" leafs are redundant. However XPath (must/when)
> has no way to describe if the subtree is enabled (which is a show-stopper)

I may not understand what you are saying. From what I know, there are
implementations that allow to 'comment out' nodes and subtrees and
that work with clients in a backwards compatible way.
 
>  vs .  If the applied or operational datastore is
> assumed,
> then there is no need to model the redundant config-as-operstate.
> If this is left out of the model, then the datastore becomes mandatory.
> If it is left in the model, the datasore becomes redundant.
> 
> The basic premise that these datastores are optional is flawed.
> One cannot design a YANG module assuming the datastores are present
> if they are in fact optional.

The claim that all datastores are mandatory is equally flawed.

/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] "when" statement deviation

2017-01-09 Thread Robert Varga

On 01/09/2017 11:32 PM, Andy Bierman wrote:
> 
> 
> On Mon, Jan 9, 2017 at 2:26 PM, Alex Campbell
> > wrote:
> 
> I don't see how a "when" statement modified by a deviation is any
> more complicated to implement than a "when" statement outside of a
> deviation - presuming that augments and deviations are processed
> before "when" statements.
> 
> 
> 
> augments and deviations are processed once when the module is loaded.
> A when-stmt is processed anytime the value of the XPath boolean result
> changes. 

Right, but that also means that processing a 'deviate add { when ... }'
would occur only once, after which the cost would be the same as if that
when statement was present in the original definition.

In any case, the same effect can be achieved by deviate-adding an
appropriate must statement -- which seems appropriate, as presumably you
want to restrict the leaf from becoming 'true' rather than enforce it
not being available at all.

Regards,
Robert

signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] "when" statement deviation

2017-01-09 Thread Andy Bierman

On Mon, Jan 9, 2017 at 2:26 PM, Alex Campbell 
wrote:

> I don't see how a "when" statement modified by a deviation is any more
> complicated to implement than a "when" statement outside of a deviation -
> presuming that augments and deviations are processed before "when"
> statements.
>
>
>
augments and deviations are processed once when the module is loaded.
A when-stmt is processed anytime the value of the XPath boolean result
changes.


Alex
>
>
>
Andy


> --
> *From:* Andy Bierman 
> *Sent:* Tuesday, 10 January 2017 11:20 a.m.
> *To:* Alex Campbell
> *Cc:* netmod@ietf.org
> *Subject:* Re: [netmod] "when" statement deviation
>
> Hi,
>
> This is not allowed because it is too complicated to implement.
> Changing the schema tree based on values of instances within the schema
> tree
> is full of complications.
>
> Note that when-stmt used where allowed enables or disables the schema tree
> without changing it. This is hard enough to support.
>
>
> Andy
>
>
> On Mon, Jan 9, 2017 at 1:56 PM, Alex Campbell 
> wrote:
>
>> Hi,
>>
>>
>> I have a module that adds some configuration to interfaces (the specific
>> feature being configured isn't important here, so I'll just call it
>> "feature").
>>
>> I want to implement this module, but the device I'm working on only
>> supports the feature on some kinds of interfaces.
>>
>> So I want to add a "when" constraint in a deviation module that says the
>> feature configuration is only available for these kinds of interfaces.
>>
>>
>> However, I found that "when" statements are not allowed to be affected by
>> deviations (according to the RFC and according to confdc).
>>
>> Is there a reason for this? It seems like an oversight.
>>
>>
>> Example:
>>
>>
>> module feature-module {
>>
>> // ... prefix, imports, etc ...
>>
>> import ietf-interfaces {prefix if;}
>>
>>
>> augment /if:interfaces/if:interface {
>>
>> container feature {
>>
>> leaf enabled {
>>
>> type boolean;
>>
>> description "Enables the feature";
>>
>> }
>>
>> }
>>
>> }
>>
>> }
>>
>>
>> module feature-module-deviations {
>>
>> // ... prefix, imports, etc ...
>>
>> import feature-module {prefix fm;}
>>
>> import iana-if-types {prefix ianaift;}
>>
>>
>> deviation /if:interfaces/if:interface/fm:feature {
>>
>> deviate add {
>>
>> // parsing fails here; "when" is not allowed as a child
>> of "deviate"
>>
>> when "../if:type = 'ianaift:ethernetCsmacd' or ../if:type
>> = 'ianaift:ieee8023adLag'";
>>
>> }
>>
>> }
>>
>> }
>>
>>
>> Alex
>>
>>
>>
>> ___
>> 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] "when" statement deviation

2017-01-09 Thread Alex Campbell

I don't see how a "when" statement modified by a deviation is any more 
complicated to implement than a "when" statement outside of a deviation - 
presuming that augments and deviations are processed before "when" statements.


Alex



From: Andy Bierman 
Sent: Tuesday, 10 January 2017 11:20 a.m.
To: Alex Campbell
Cc: netmod@ietf.org
Subject: Re: [netmod] "when" statement deviation

Hi,

This is not allowed because it is too complicated to implement.
Changing the schema tree based on values of instances within the schema tree
is full of complications.

Note that when-stmt used where allowed enables or disables the schema tree
without changing it. This is hard enough to support.


Andy


On Mon, Jan 9, 2017 at 1:56 PM, Alex Campbell 
> wrote:

Hi,


I have a module that adds some configuration to interfaces (the specific 
feature being configured isn't important here, so I'll just call it "feature").

I want to implement this module, but the device I'm working on only supports 
the feature on some kinds of interfaces.

So I want to add a "when" constraint in a deviation module that says the 
feature configuration is only available for these kinds of interfaces.


However, I found that "when" statements are not allowed to be affected by 
deviations (according to the RFC and according to confdc).

Is there a reason for this? It seems like an oversight.


Example:


module feature-module {

// ... prefix, imports, etc ...

import ietf-interfaces {prefix if;}


augment /if:interfaces/if:interface {

container feature {

leaf enabled {

type boolean;

description "Enables the feature";

}

}

}

}


module feature-module-deviations {

// ... prefix, imports, etc ...

import feature-module {prefix fm;}

import iana-if-types {prefix ianaift;}


deviation /if:interfaces/if:interface/fm:feature {

deviate add {

// parsing fails here; "when" is not allowed as a child of 
"deviate"

when "../if:type = 'ianaift:ethernetCsmacd' or ../if:type = 
'ianaift:ieee8023adLag'";

}

}

}


Alex


___
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] "when" statement deviation

2017-01-09 Thread Andy Bierman

Hi,

This is not allowed because it is too complicated to implement.
Changing the schema tree based on values of instances within the schema tree
is full of complications.

Note that when-stmt used where allowed enables or disables the schema tree
without changing it. This is hard enough to support.


Andy


On Mon, Jan 9, 2017 at 1:56 PM, Alex Campbell 
wrote:

> Hi,
>
>
> I have a module that adds some configuration to interfaces (the specific
> feature being configured isn't important here, so I'll just call it
> "feature").
>
> I want to implement this module, but the device I'm working on only
> supports the feature on some kinds of interfaces.
>
> So I want to add a "when" constraint in a deviation module that says the
> feature configuration is only available for these kinds of interfaces.
>
>
> However, I found that "when" statements are not allowed to be affected by
> deviations (according to the RFC and according to confdc).
>
> Is there a reason for this? It seems like an oversight.
>
>
> Example:
>
>
> module feature-module {
>
> // ... prefix, imports, etc ...
>
> import ietf-interfaces {prefix if;}
>
>
> augment /if:interfaces/if:interface {
>
> container feature {
>
> leaf enabled {
>
> type boolean;
>
> description "Enables the feature";
>
> }
>
> }
>
> }
>
> }
>
>
> module feature-module-deviations {
>
> // ... prefix, imports, etc ...
>
> import feature-module {prefix fm;}
>
> import iana-if-types {prefix ianaift;}
>
>
> deviation /if:interfaces/if:interface/fm:feature {
>
> deviate add {
>
> // parsing fails here; "when" is not allowed as a child of
> "deviate"
>
> when "../if:type = 'ianaift:ethernetCsmacd' or ../if:type
> = 'ianaift:ieee8023adLag'";
>
> }
>
> }
>
> }
>
>
> Alex
>
>
>
> ___
> 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] "when" statement deviation

2017-01-09 Thread Alex Campbell

Hi,


I have a module that adds some configuration to interfaces (the specific 
feature being configured isn't important here, so I'll just call it "feature").

I want to implement this module, but the device I'm working on only supports 
the feature on some kinds of interfaces.

So I want to add a "when" constraint in a deviation module that says the 
feature configuration is only available for these kinds of interfaces.


However, I found that "when" statements are not allowed to be affected by 
deviations (according to the RFC and according to confdc).

Is there a reason for this? It seems like an oversight.


Example:


module feature-module {

// ... prefix, imports, etc ...

import ietf-interfaces {prefix if;}


augment /if:interfaces/if:interface {

container feature {

leaf enabled {

type boolean;

description "Enables the feature";

}

}

}

}


module feature-module-deviations {

// ... prefix, imports, etc ...

import feature-module {prefix fm;}

import iana-if-types {prefix ianaift;}


deviation /if:interfaces/if:interface/fm:feature {

deviate add {

// parsing fails here; "when" is not allowed as a child of 
"deviate"

when "../if:type = 'ianaift:ethernetCsmacd' or ../if:type = 
'ianaift:ieee8023adLag'";

}

}

}


Alex

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

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

2017-01-09 Thread Andy Bierman

On Mon, Jan 9, 2017 at 12:51 PM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Mon, Jan 09, 2017 at 09:18:46PM +0100, Ladislav Lhotka wrote:
> >
> > I am more concerned about use cases that are not known so far, and so I
> am against standardizing this (or any other) workflow as the only one
> supported by NETCONF/RESTCONF and YANG. I believe both the protocols and
> YANG can work with any set of datastores, but their choice depends on the
> use case at hand. Why should IoT developers be exposed to the
> running-intended-applied complexity, even if they are allowed to lump all
> three into one?
> >
>
> Please point me to the statement in the I-D that makes you believe an
> implementation is required to support all datastores.
>
> > > There are no standard mechanisms that cause  to be
> > > different from , so I would agree the intended datastore
> > > needs a lot more standards support before it is useful.
> > >
> >
> > The only difference seems to be the presence of templates but I don't
> know what they are.
> >
>
> The I-D says:
>
> |// e.g., removal of 'inactive'
> |// nodes, expansion of templates
>
> So it is not just templates. And yes, these are things several
> real-world implementations can do but where the IETF did not yet
> managed to standardize anything. The basic question is whether we want
> a model that is (a) capable to match real-world implementation and
> that allows for future standards of existing proprietary technology or
> (b) we go with what we have today (either chartered or published) and
> we keep revising the model as we move ahead.
>
>

I think itt is not realistic to say that datastores are optional.

e.g.  leaf:  If there is a standard way to enable/disable config
then individual "enabled" leafs are redundant. However XPath (must/when)
has no way to describe if the subtree is enabled (which is a show-stopper)

 vs .  If the applied or operational datastore is
assumed,
then there is no need to model the redundant config-as-operstate.
If this is left out of the model, then the datastore becomes mandatory.
If it is left in the model, the datasore becomes redundant.

The basic premise that these datastores are optional is flawed.
One cannot design a YANG module assuming the datastores are present
if they are in fact optional.


/js
>
>
Andy



> --
> 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] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

2017-01-09 Thread Juergen Schoenwaelder

On Mon, Jan 09, 2017 at 09:18:46PM +0100, Ladislav Lhotka wrote:
> 
> I am more concerned about use cases that are not known so far, and so I am 
> against standardizing this (or any other) workflow as the only one supported 
> by NETCONF/RESTCONF and YANG. I believe both the protocols and YANG can work 
> with any set of datastores, but their choice depends on the use case at hand. 
> Why should IoT developers be exposed to the running-intended-applied 
> complexity, even if they are allowed to lump all three into one?   
>

Please point me to the statement in the I-D that makes you believe an
implementation is required to support all datastores.

> > There are no standard mechanisms that cause  to be
> > different from , so I would agree the intended datastore
> > needs a lot more standards support before it is useful.
> > 
> 
> The only difference seems to be the presence of templates but I don't know 
> what they are.
>

The I-D says:

|// e.g., removal of 'inactive'
|// nodes, expansion of templates

So it is not just templates. And yes, these are things several
real-world implementations can do but where the IETF did not yet
managed to standardize anything. The basic question is whether we want
a model that is (a) capable to match real-world implementation and
that allows for future standards of existing proprietary technology or
(b) we go with what we have today (either chartered or published) and
we keep revising the model as we move ahead.

/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] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

2017-01-09 Thread Ladislav Lhotka


> On 9 Jan 2017, at 19:37, Andy Bierman  wrote:
> 
> 
> 
> On Mon, Jan 9, 2017 at 4:50 AM, Ladislav Lhotka  wrote:
> 
> > On 9 Jan 2017, at 13:38, Lou Berger  wrote:
> >
> >
> >
> > On January 9, 2017 7:25:24 AM Ladislav Lhotka  wrote:
> >>
> >> The current document involves quite a lot of hand-waving, and that's why I 
> >> was also reluctant to accept it as a WG standard-track deliverable.
> >
> 
> 
> I do not agree with this hand-waving assessment.
> What are the show-shoppers?
> 
> I agree the draft is light on use-cases.

I am more concerned about use cases that are not known so far, and so I am 
against standardizing this (or any other) workflow as the only one supported by 
NETCONF/RESTCONF and YANG. I believe both the protocols and YANG can work with 
any set of datastores, but their choice depends on the use case at hand. Why 
should IoT developers be exposed to the running-intended-applied complexity, 
even if they are allowed to lump all three into one?   

> There are no standard mechanisms that cause  to be
> different from , so I would agree the intended datastore
> needs a lot more standards support before it is useful.
> 

The only difference seems to be the presence of templates but I don't know what 
they are.

Lada

> 
>  
> > IMO I think we should do and document the work and then, once the is 
> > general agreement,  worry about number and publication status of documents.
> 
> I agree, but we have to accept it will take some time. The problem I see is 
> that quite a few people already work with the solution.
> 
> 
> The solutions I've seen were not very good, so they need a lot of work.
> I expect that the operational datastore will be more widely implemented
> than any of the others.  Designing a  replacement is not that difficult.
> 
> 
> 
> Lada
> 
> Andy
>  
> 
> >
> > Lou
> >
> >
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> 
> 
> 
> 
> 

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





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

Re: [netmod] Tacacs and YANG

2017-01-09 Thread Mahesh Jethanandani

> On Jan 9, 2017, at 4:16 AM, Balazs Lengyel  
> wrote:
> 
> Hello,
> 
> We already have a radius model part in ietf-system; but are there any plans 
> to develop a TACACS+ model for YANG?
> 
> How widely is TACACS+ used for remote authorization/accounting ? As an 
> outsider I would guess that remote authorization could really slow down 
> processing e.g. a big CLI script.

Of the customers that I am interacting with, both use TACACS+ for authorization 
and accounting. My take is that there would a requirement for NETCONF to be 
able to interact with the server.

One way to deal with authorization is for the server to download the 
authorization rules and do local authorization instead of sending all the 
requests to the server, which as you point out would otherwise slow 
authorization down. 

A related question is, if NACM is used to setup rules for authorization, and 
there is a remote AAA server configured, are the rules for the NETCONF server 
to store and manage or are they for the AAA server? If the latter, what is 
communication channel between them?

Thanks.

Mahesh Jethanandani
mjethanand...@gmail.com

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

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

2017-01-09 Thread Ladislav Lhotka


> On 9 Jan 2017, at 13:38, Lou Berger  wrote:
> 
> 
> 
> On January 9, 2017 7:25:24 AM Ladislav Lhotka  wrote:
>> 
>> The current document involves quite a lot of hand-waving, and that's why I 
>> was also reluctant to accept it as a WG standard-track deliverable.
> 
> IMO I think we should do and document the work and then, once the is general 
> agreement,  worry about number and publication status of documents.

I agree, but we have to accept it will take some time. The problem I see is 
that quite a few people already work with the solution.

Lada 

> 
> Lou
> 
> 

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





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

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

2017-01-09 Thread Lou Berger




On January 9, 2017 7:25:24 AM Ladislav Lhotka  wrote:


The current document involves quite a lot of hand-waving, and that's why I 
was also reluctant to accept it as a WG standard-track deliverable.


IMO I think we should do and document the work and then, once the is 
general agreement,  worry about number and publication status of documents.


Lou


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

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

2017-01-09 Thread Ladislav Lhotka


> On 6 Jan 2017, at 20:57, Andy Bierman  wrote:
> 
> 
> 
> On Fri, Jan 6, 2017 at 11:05 AM, Mehmet Ersue  wrote:
> Hi Juergen,
> 
> I don't think it is duplicate work. One is as I understand the architecture 
> and concept document you were asking for
> and the other draft is the standard DS framework RFC to be used as the basis 
> for different documents.
> 
> 
> I do not understand the difference between these 2 documents.
> 
> There should be 1 document that is protocol-independent that includes:
>- definition of datastores
>- discussion of interactions between datastores
>- use-cases in scope for new datastores
>- applicability guidance for server developers

The current document involves quite a lot of hand-waving, and that's why I was 
also reluctant to accept it as a WG standard-track deliverable. I don't care 
that much about the number of documents that depend on it because any mistakes 
may be pretty expensive here. I pointed out some gaps in my previous review, 
e.g. it talks about templates without defining what they are. If running 
contains templates, does it mean it needn't be valid according to the data 
model?

> 
> Each protocol that wants to use these new datastores needs to define
> mechanisms to do that in a separate document.
> 

That's one part, the other are changes inflicted to YANG. I think the best way 
would be to make YANG independent of a particular setup of datastores and their 
semantics. Then I2RS or anybody else can do whatever they need without 
affecting YANG spec any more.

I believe this wouldn't be a terribly difficult thing to do, but Juergen wants 
me to write a meta-model document first.

Lada

> 
> 
> 
> Cheers,
> Mehmet
> 
> 
> Andy
>  
> 
> -Original Message-
> From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
> Sent: Friday, January 6, 2017 7:45 PM
> To: Mehmet Ersue 
> Cc: 'Netconf' ; 'NetMod WG' 
> Subject: Re: [Netconf] Decision on the Intended Status of the Revised DS 
> Draft WAS:RE: :candidate, :writable-running and RESTCONF edits
> 
> On Fri, Jan 06, 2017 at 07:04:14PM +0100, Mehmet Ersue wrote:
> >
> > It is correct that we need a standard track document for the new DS 
> > framework - to provide a basis for other RFCs to develope.  However the 
> > current DT solution draft has not been prepared as a standard track 
> > document nor it has standard relevant content. Such concept description is 
> > usually prepared as an architecture document (see example in  
> >  RFC 6244).
> >
> > As I stated earlier I believe “a new protocol- and language-independent 
> > standard document” should be prepared defining the generic datastore 
> > framework (based on and following the concept in the DT solution draft).
> >
> 
> To me, this sounds like duplicate work for no real technical value. If the 
> existance of two WG results into actions like this, we should seriously 
> consider the option to merge NETMOD and NETCONF into one WG.
> 
> /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

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





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

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

Re: [netmod] "when" statement deviation

Re: [netmod] "when" statement deviation

Re: [netmod] "when" statement deviation

Re: [netmod] "when" statement deviation

[netmod] "when" statement deviation

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

Re: [netmod] Tacacs and YANG

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits

13 matches

Site Navigation

Mail list logo

Footer information