Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-04 and draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03 drafts available

From: "Jonathan Hansford" <[email-masked]>
Date: Wed, 11 Mar 2015 11:48:52 +0000

RESTCONF provides a "Simple Subset of NETCONF Functionality",
excluding locking, validation, confirmed commits and the startup and
candidate datastores. A number of potential suppliers of devices we
are considering for out system already provide a web-based interface
and may be far more comfortable with migrating to (or via) RESTCONF
rather than directly to NETCONF. However these excluded features are
ones we had hoped to leverage.

Section 1.1 states "The following transaction features are not
directly provided in RESTCONF". Is the word "directly" intended to
convey there may be indirect means of providing these features with
RESTCONF? If so, is there any guidance on how? If not, would it not be
better to remove the word?

Thanks

Jonathan

On 5 February 2015 at 13:22, Ersue, Mehmet (NSN - DE/Munich)  wrote:

	Dear NETCONF WG, 

	we hereby issue a WG Last Call for 3 weeks for the drafts below:  

	https://tools.ietf.org/html/draft-ietf-netconf-restconf-04 [2]  

	https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03 [3]  

	Please review and send your comments to the NETCONF WG mailing list
by February 26, 2015 EOB PT.  

	The related draft-ietf-netconf-yang-library will follow with LC as
soon as the remaining two issues are solved  

	(see http://tools.ietf.org/html/draft-ietf-netconf-yang-library [4]).

	RESTCONF documents are planned to publish as standard track
documents. 

	As RESTCONF is a major protocol we expect a detailed and thorough
review within NETCONF WG but also by the related WGs before
publishing. 

	Therefore the WGLC is planned for 3 weeks and APP, INT and RTG area
ADs will be informed as well as Core, I2rs, 6lo, and 6tisch WGs are
invited to review. 

	Please state explicitly that you have read/reviewed and whether you
support the publication. 

	Please indicate also if you plan to implement or have already
implementation experience with RESTCONF. 

	Thank you, 

	Mehmet and Mahesh 

	FROM: Netconf [mailto:[email-masked] [5]] ON BEHALF OF ext
Ersue, Mehmet (NSN - DE/Munich)
SENT: Saturday, January 31, 2015 4:05 PM
TO: [email-masked] [6]
SUBJECT: [Netconf] Restconf-04 and YANG-Patch-03 drafts available   

	All,   

	1 YANG patch and 9 Restconf issues have been solved and provided in
the drafts below.    

	These issues have been set to the status Review
(https://github.com/netconf-wg/restconf/issues [7]).   

	Please check and comment on the drafts below before we go to WGLC
soon:   

	https://tools.ietf.org/html/draft-ietf-netconf-restconf-04 [8]    

	https://tools.ietforg/html/draft-ietf-netconf-yang-patch-03 [9]    

	Regards, 
 Mehmet    

_______________________________________________
 Netconf mailing list
[email-masked] [10]
https://www.ietf.org/mailman/listinfo/netconf [11]

Links:
------
[1] mailto:[email-masked]
[2] https://tools.ietf.org/html/draft-ietf-netconf-restconf-04
[3] https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03
[4] http://tools.ietf.org/html/draft-ietf-netconf-yang-library
[5] mailto:[email-masked]
[6] mailto:[email-masked]
[7] https://github.com/netconf-wg/restconf/issues
[8] https://tools.ietf.org/html/draft-ietf-netconf-restconf-04
[9] https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03
[10] mailto:[email-masked]
[11] https://www.ietf.org/mailman/listinfo/netconf

---

From: Kent Watsen <[email-masked]>
Date: Thu, 12 Mar 2015 14:20:03 +0000

Hi Jonathan,

I somewhat agree and even raised the same internally with the author's a few weeks ago - including a solution no less, and it wasn't even hard (contrary to what others have said).   The response to this inquiry has always been along the lines of "use netconf if you want fancy stuff" and "we need to get this draft out the door".   Personally, I feel like this is shortsighted and would rather see a complete solution.   That said, I haven't pushed it because RESTCONF is sufficient the use cases I care about most.

Thanks,
Kent

From: Jonathan Hansford <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 11, 2015 at 7:48 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-04 and draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03 drafts available

RESTCONF provides a "Simple Subset of NETCONF Functionality", excluding locking, validation, confirmed commits and the startup and candidate datastores. A number of potential suppliers of devices we are considering for out system already provide a web-based interface and may be far more comfortable with migrating to (or via) RESTCONF rather than directly to NETCONF. However these excluded features are ones we had hoped to leverage.

Section 1.1 states "The following transaction features are not directly provided in RESTCONF". Is the word "directly" intended to convey there may be indirect means of providing these features with RESTCONF? If so, is there any guidance on how? If not, would it not be better to remove the word?

Thanks

Jonathan

On 5 February 2015 at 13:22, Ersue, Mehmet (NSN - DE/Munich) <[email-masked]<mailto:[email-masked]>> wrote:
Dear NETCONF WG,
we hereby issue a WG Last Call for 3 weeks for the drafts below:

https://tools.ietf.org/html/draft-ietf-netconf-restconf-04
https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03

Please review and send your comments to the NETCONF WG mailing list by February 26, 2015 EOB PT.
The related draft-ietf-netconf-yang-library will follow with LC as soon as the remaining two issues are solved
(see http://tools.ietf.org/html/draft-ietf-netconf-yang-library).
RESTCONF documents are planned to publish as standard track documents.
As RESTCONF is a major protocol we expect a detailed and thorough review within NETCONF WG but also by the related WGs before publishing.
Therefore the WGLC is planned for 3 weeks and APP, INT and RTG area ADs will be informed as well as Core, I2rs, 6lo, and 6tisch WGs are invited to review.
Please state explicitly that you have read/reviewed and whether you support the publication.
Please indicate also if you plan to implement or have already implementation experience with RESTCONF.

Thank you,
Mehmet and Mahesh

From: Netconf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Ersue, Mehmet (NSN - DE/Munich)
Sent: Saturday, January 31, 2015 4:05 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Netconf] Restconf-04 and YANG-Patch-03 drafts available

All,

1 YANG patch and 9 Restconf issues have been solved and provided in the drafts below.
These issues have been set to the status Review (https://github.com/netconf-wg/restconf/issues).

Please check and comment on the drafts below before we go to WGLC soon:
https://tools.ietf.org/html/draft-ietf-netconf-restconf-04
https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03

Regards,
Mehmet

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Thu, 12 Mar 2015 07:48:08 -0700

Hi,

One problem I have with exposing multiple targets (e.g..
candidate, running, startup) is that the operations become
much more stateful.  NETCONF has a concept of application
sessions.  NETCONF defines locking and cleanup after
lost sessions.   NETCONF does not embed the target datastore
in the URI like RESTCONF.  This makes the Location headers
returned for new resources datastore-specific.  The client should
not use hacks to parse the Location header
and make new ones for each datastore.

That said, it is fairly trivial for one who knows NETCONF to
figure out how to use /restconf/operations/edit-config (and commit)
to do NETCONF-based editing.

Andy

On Thu, Mar 12, 2015 at 7:20 AM, Kent Watsen <[email-masked]> wrote:
>
> Hi Jonathan,
>
> I somewhat agree and even raised the same internally with the author's a few
> weeks ago – including a solution no less, and it wasn't even hard (contrary
> to what others have said).   The response to this inquiry has always been
> along the lines of "use netconf if you want fancy stuff" and "we need to get
> this draft out the door".   Personally, I feel like this is shortsighted and
> would rather see a complete solution.   That said, I haven't pushed it
> because RESTCONF is sufficient the use cases I care about most.
>
> Thanks,
> Kent
>
> From: Jonathan Hansford <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-04 and
> draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03
> drafts available
>
> RESTCONF provides a "Simple Subset of NETCONF Functionality", excluding
> locking, validation, confirmed commits and the startup and candidate
> datastores. A number of potential suppliers of devices we are considering
> for out system already provide a web-based interface and may be far more
> comfortable with migrating to (or via) RESTCONF rather than directly to
> NETCONF. However these excluded features are ones we had hoped to leverage.
>
> Section 1.1 states "The following transaction features are not directly
> provided in RESTCONF". Is the word "directly" intended to convey there may
> be indirect means of providing these features with RESTCONF? If so, is there
> any guidance on how? If not, would it not be better to remove the word?
>
> Thanks
>
> Jonathan
>
>
> On 5 February 2015 at 13:22, Ersue, Mehmet (NSN - DE/Munich)
> <[email-masked]> wrote:
>>
>> Dear NETCONF WG,
>>
>> As RESTCONF is a major protocol we expect a detailed and thorough review
>> within NETCONF WG but also by the related WGs before publishing.
>>
>> Therefore the WGLC is planned for 3 weeks and APP, INT and RTG area ADs
>> will be informed as well as Core, I2rs, 6lo, and 6tisch WGs are invited to
>> review.
>>
>> From: Netconf [mailto:[email-masked]] On Behalf Of ext Ersue,
>> Mehmet (NSN - DE/Munich)
>> To: [email-masked]
>> (https://github.com/netconf-wg/restconf/issues).
>>
>>
>>
>> [email-masked]
> [email-masked]

---

From: "Jonathan Hansford" <[email-masked]>
Date: Thu, 12 Mar 2015 15:18:17 +0000

Hi,
I'm willing to accept that "it is fairly trivial for one who knows
NETCONF to figure out how to use /restconf/operations/edit-config (and
commit) to do NETCONF-based editing." However, for anyone starting
with RESTCONF with a view to possibly migrating to NETCONF at a later
date, some guidance would be useful. I, for one, am still waiting for
my company to start implementing anything based on NETCONF or RESTCONF
and consequently any knowledge is currently theoretical.

Jonathan

----- Original Message -----
From: "Andy Bierman" 
To:"Kent Watsen" 
Cc:"Jonathan Hansford" , "[email-masked]" 
Sent:Thu, 12 Mar 2015 07:48:08 -0700
Subject:Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-04
and draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and
YANG-Patch-03 drafts available

 Hi,

 Andy

 On Thu, Mar 12, 2015 at 7:20 AM, Kent Watsen  wrote:
 > From: Jonathan Hansford 
 > To: "[email-masked]" 
excluding
 > NETCONF However these excluded features are ones we had hoped to
leverage.
 > Section 1.1 states "The following transaction features are not
directly
 >  wrote:
 >> Please review and send your comments to the NETCONF WG mailing
list by
 >> February 26, 2015 EOB PT.
 >>
soon as
 >> the remaining two issues are solved
 >>
documents.
 >> As RESTCONF is a major protocol we expect a detailed and thorough
review
 >> 1 YANG patch and 9 Restconf issues have been solved and provided
in the
 >> drafts below.
soon:
 > https://www.ietforg/mailman/listinfo/netconf
 >

---

From: Andy Bierman <[email-masked]>
Date: Thu, 12 Mar 2015 09:13:27 -0700

On Thu, Mar 12, 2015 at 8:18 AM, Jonathan Hansford
<[email-masked]> wrote:
>  Hi,
>
> I'm willing to accept that "it is fairly trivial for one who knows NETCONF
> to figure out how to use /restconf/operations/edit-config (and commit) to do
> NETCONF-based editing." However, for anyone starting with RESTCONF with a
> view to possibly migrating to NETCONF at a later date, some guidance would
> be useful. I, for one, am still waiting for my company to start implementing
> anything based on NETCONF or RESTCONF and consequently any knowledge is
> currently theoretical.
>

There is no requirement for the server to expose the NETCONF operations
in RESTCONF, so it seems inappropriate to discuss it in the RESTCONF draft.
I agree with Martin that NETCONF should be used if you wnt these features.

I don't really see any benefit to using RESTCONF POST to invoke
NETCONF RPC calls.  This is not REST-like at all, so leveraging
existing code seems unlikely.

I also think NETCONF candidate config is a bad transaction model
because it is shared and NETCONF locking is so expensive to use.
It should be possible to add rollback and control of NV-save to
RESTCONF in the future.

Andy

> From:
> "Andy Bierman" <[email-masked]>
>
> To:
> "Kent Watsen" <[email-masked]>
> Cc:
> "Jonathan Hansford" <[email-masked]>, "[email-masked]"
> <[email-masked]>
> Sent:
> Subject:
> Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-04 and
>>> The related draft-ietf-netconf-yang-library will follow with LC as soon
>>> as