Skip to main content

RESTCONF Protocol
draft-ietf-netconf-restconf-18

Revision differences

Document history

Date Rev. By Action
2017-01-25
18 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2016-12-21
18 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2016-12-19
18 (System) RFC Editor state changed to RFC-EDITOR from AUTH
2016-12-12
18 (System) RFC Editor state changed to AUTH from EDIT
2016-11-12
18 Jean Mahoney Closed request for Telechat review by GENART with state 'No Response'
2016-11-07
18 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2016-11-04
18 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2016-11-03
18 (System) IANA Action state changed to Waiting on Authors from In Progress
2016-11-01
18 (System) IANA Action state changed to In Progress from On Hold
2016-11-01
18 (System) RFC Editor state changed to EDIT
2016-11-01
18 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2016-11-01
18 (System) Announcement was received by RFC Editor
2016-10-31
18 (System) IANA Action state changed to On Hold
2016-10-31
18 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2016-10-31
18 Amy Vezza IESG has approved the document
2016-10-31
18 Amy Vezza Closed "Approve" ballot
2016-10-31
18 Amy Vezza Ballot approval text was generated
2016-10-31
18 Amy Vezza IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2016-10-31
18 Amy Vezza Ballot writeup was changed
2016-10-28
18 Alexey Melnikov [Ballot comment]
Thank you for addressing my DISCUSS and comments.
2016-10-28
18 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to Yes from Discuss
2016-10-27
18 (System) Sub state has been changed to AD Followup from Revised ID Needed
2016-10-27
18 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2016-10-27
18 Andy Bierman New version available: draft-ietf-netconf-restconf-18.txt
2016-10-27
18 (System) New version approved
2016-10-27
18 (System) Request for posting confirmation emailed to previous authors: "Kent Watsen" , "Andy Bierman" , "Martin Bjorklund"
2016-10-27
18 Andy Bierman Uploaded new revision
2016-10-13
17 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2016-10-13
17 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2016-10-12
17 Stephen Farrell
[Ballot comment]

- What about tls1.3 0RTT/replayable-data? There may be a case
to be made to mention this here and e.g. to say that only …
[Ballot comment]

- What about tls1.3 0RTT/replayable-data? There may be a case
to be made to mention this here and e.g. to say that only
idempotent requests (or none) are allowed use 0RTT early data.
Equally you could argue to not say anything since tls1.3 isn't
yet finished. I'd argue that saying something here is better
(and that saying to not use 0RTT at all is best) since
RESTCONF will use standard https libraries, which will at some
point soon support 0RTT and that might even make that happen
more easily than they ought. (This isn't a discuss as tls1.3
isn't yet done so I'd not feel right blocking on this basis,
but were tls1.3 done, which it will be soon I hope, this
would be a definite discuss as RESTCONF differs enough from
a browser for this to be a cause of possibly really bad
security problems.)

1.4: "Note that there are no interactions at all between the
NETCONF protocol and RESTCONF protocol.  It is possible that
locks are in use on a RESTCONF server, even though RESTCONF
cannot manipulate locks.  In such a case, the RESTCONF
protocol will not be granted write access to data resources
within a datastore." What you mean is clear, but the text is,
I think, self-contradictory - what is described is an
interaction between the two protocols. (And so is the fact
that access controls need to be commensurate between the two
protocols.)

- section 2: would it be useful to add a reference to BCP195
and say that adhering to that is a good idea?  I think you
could maybe actually lose some (but not all) of the text here
via that single reference. (That might help a bit with
Alexey's discuss, not sure.)

- 2.5: "MUST use tls-cilent-auth or MUST use any HTTP
authentication scheme" is (as Kathleen noted) wishy washy.
And that leaves out html-form-based client auth methods too it
seems. I think you could word this better. (Not that that's
likely to affect the reality that clients here will just use
web engines so there's probably no point in expecting that
RESTCONF can use anything out of the ordinary.) The same
comment applies to section 12 where the same wishy-washy
statement occurs.

- 12: "There are many patterns of attack..." that screams
out for references, please add some to give the reader
a chance to understand if they don't already know.
2016-10-12
17 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2016-10-12
17 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2016-10-12
17 Amanda Baber IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2016-10-12
17 Ben Campbell
[Ballot comment]
(I would have balloted DISCUSS based on the major comment, but Alexey beat me to it:)

Major:
- 4.6:  The first patch says …
[Ballot comment]
(I would have balloted DISCUSS based on the major comment, but Alexey beat me to it:)

Major:
- 4.6:  The first patch says the sever MUST support PATCH, and also that implementation of PATCH is optional. Language in 4.1 seems to assume the latter.

Minor:

- 2.5: I'm a bit surprised to see basic authentication encouraged to the same degree as other options.

- 5.2:  Did the working group consider the interoperability impact of not making either encoding MTI?

- 12, paragraph 4: Please consider not repeating the 2119 language from other sections.

Editorial/Nits:

-1.4, 6th paragraph: "...then this commit will act as the
  confirming commit": Which commit is "this" commit?

- 5.3, first sentence: Missing word?
2016-10-12
17 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2016-10-12
17 Alexey Melnikov
[Ballot discuss]
Thank you for a well written document. I have a few minor points which I would like to discuss before recommending approval of …
[Ballot discuss]
Thank you for a well written document. I have a few minor points which I would like to discuss before recommending approval of this document:

1) In 2.4: TLS server identity verification using RFC 6125 is underspecified. Please provide all details as described in Section 3 of RFC 6125, in particular, please specify which of CN-ID, DNS-ID, SRV-ID, URI-ID are allowed/required and whether wildcards are allowed in them.

2) In 3.5.3.1:

api-path is using "|" instead of "/" for alternatives.

The "*" must be before a rule, not after it.

It looks like the ABNF was not validated with a tool, so there might be other errors in it.

3) In 4.6:
... server MUST support the PATCH method. ... . It is optional to implement by the server.

- These statements seem to be in conflict.

4) In 5.2:

The server is only required to implement one of XML / JSON. Does this mean that a compliant client need to support both in order to achieve interoperability? The document doesn't say that.
2016-10-12
17 Alexey Melnikov
[Ballot comment]
In 1.4: is it possible to expose separate :candidate, :startup and :writeable-running over RESTCONF? Section 1.4 seem to imply that only one can …
[Ballot comment]
In 1.4: is it possible to expose separate :candidate, :startup and :writeable-running over RESTCONF? Section 1.4 seem to imply that only one can be used.

In 3.5.3: you are listing "reserved" URI characters, you should point to RFC 3986 as the authoritative reference.

In 4.4.2: can 404 be returned instead of 403?

On page 45 (in the middle of the page): some references to RFCs and sections look incorrect (wrong formatting).

In 4.5: it would be good to see an example creating/replacing the whole datastore.

At the bottom of page 47: I see an extra dot in the middle of a sentence.

In 4.8.4: I think XPath should be a normative reference there.

In 5.5: what is the reason for Cache-Control being a SHOULD and not a MUST?

In 11.3.1:

Subtype must include "+xml" in its value.

Fragment identifier: can you just say "same as for application/xml"?

File extension: don't you want to define a new one? (.xml is fine as a fallback)

11.3.2:

The same comment about file extensions as above.
2016-10-12
17 Alexey Melnikov [Ballot Position Update] New position, Discuss, has been recorded for Alexey Melnikov
2016-10-12
17 Alissa Cooper
[Ballot comment]
Thanks for your work on this.

(1)
I'm curious how the WG settled on using Server-Sent Events. My understanding is that the SSE …
[Ballot comment]
Thanks for your work on this.

(1)
I'm curious how the WG settled on using Server-Sent Events. My understanding is that the SSE framework is somewhat brittle when used on its own and there can be problems when there are intermediaries in the path. Did the WG consider other options (e.g., H2 server push or long polling)?

(2)
I know the jukebox module is just an example, but it actually made me wonder if there would ever be cause for the server to return a 451 status code in response to a POST or GET request rather than a 401 or 403. Obviously there is no analog in the netconf status codes and the use for this would be pretty atypical, but figured I would mention this thought since it occurred to me.
2016-10-12
17 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2016-10-11
17 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2016-10-11
17 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2016-10-11
17 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2016-10-10
17 Kathleen Moriarty
[Ballot comment]
The draft is nicely written, thank you for that.  I have a point in the security consideration section that I think is important …
[Ballot comment]
The draft is nicely written, thank you for that.  I have a point in the security consideration section that I think is important to clarify in the draft.

Authentication for RESTconf - The method for HTTP authentication vary and some are really bad (HTTP Basic, digest isn't too far behind it).  This draft just requires some method, but I think a warning to research the methods since they have widely varying security levels is important.  For the HTTP Authentication methods, the RFCs cover the pitfalls well.  Here is the sentence:

  Client
  authentication MUST be implemented using client certificates or MUST
  be implemented using an HTTP authentication scheme.

How about:
  Client
  authentication MUST be implemented using client certificates or MUST
  be implemented using an HTTP authentication scheme.  The strength of
  these methods vary greatly and (certificates are recommended or HTTP basic is not recommended).

Digest isn't great either, but at least not recommending basic would be good.  There are also a few newer experimental HTTPAuth methods that improve things, but are experimental.  One gets rid of stored passwords (HOBA).
2016-10-10
17 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2016-10-10
17 Spencer Dawkins
[Ballot comment]
I'm not sure how PATCH is MUST support but optional to implement in

  The RESTCONF server MUST support the PATCH method.  RESTCONF …
[Ballot comment]
I'm not sure how PATCH is MUST support but optional to implement in

  The RESTCONF server MUST support the PATCH method.  RESTCONF uses the
  HTTP PATCH method defined in [RFC5789] to provide an extensible
  framework for resource patching mechanisms.  It is optional to
  implement by the server.
 
Can you help me understand?
2016-10-10
17 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2016-10-07
17 Dale Worley Request for Telechat review by GENART Completed: Ready. Reviewer: Dale Worley.
2016-10-06
17 Jean Mahoney Request for Telechat review by GENART is assigned to Robert Sparks
2016-10-06
17 Jean Mahoney Request for Telechat review by GENART is assigned to Robert Sparks
2016-10-06
17 Jean Mahoney Request for Telechat review by GENART is assigned to Dale Worley
2016-10-06
17 Jean Mahoney Request for Telechat review by GENART is assigned to Dale Worley
2016-10-04
17 Benoît Claise IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2016-09-28
17 Andy Bierman New version approved
2016-09-28
17 Andy Bierman New version available: draft-ietf-netconf-restconf-17.txt
2016-09-28
17 Andy Bierman Request for posting confirmation emailed to previous authors: "Kent Watsen" , "Andy Bierman" , "Martin Bjorklund"
2016-09-28
17 (System) Uploaded new revision
2016-09-25
16 Benoît Claise Telechat date has been changed to 2016-10-13 from 2016-09-29
2016-09-22
16 Jean Mahoney Request for Telechat review by GENART is assigned to Dale Worley
2016-09-22
16 Jean Mahoney Request for Telechat review by GENART is assigned to Dale Worley
2016-09-22
16 Jean Mahoney Request for Telechat review by GENART is assigned to Robert Sparks
2016-09-22
16 Jean Mahoney Request for Telechat review by GENART is assigned to Robert Sparks
2016-09-22
16 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2016-09-19
16 Benoît Claise Placed on agenda for telechat - 2016-09-29
2016-09-19
16 Benoît Claise Ballot has been issued
2016-09-19
16 Benoît Claise [Ballot Position Update] New position, Yes, has been recorded for Benoit Claise
2016-09-19
16 Benoît Claise Created "Approve" ballot
2016-09-19
16 Benoît Claise Ballot writeup was changed
2016-09-19
16 Benoît Claise IESG state changed to Waiting for AD Go-Ahead from Waiting for Writeup
2016-08-15
16 Andy Bierman IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2016-08-15
16 Andy Bierman New version available: draft-ietf-netconf-restconf-16.txt
2016-08-03
15 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2016-08-03
15 Sabrina Tanamal
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-netconf-restconf-15.txt. If any part of this review is inaccurate, please let us know.

IANA …
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-netconf-restconf-15.txt. If any part of this review is inaccurate, please let us know.

IANA has a question about one of the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are five actions which IANA must complete.

First, in the Link Relation Types subregistry of the Link Relations registry located at:

http://www.iana.org/assignments/link-relations/

a new type will be registered as follows:

Relation Name: restconf
Description: Identifies the root of RESTCONF API as configured on this HTTP server. The "restconf" relation defines the root of the API defined in [ RFC-to-be ]. Subsequent revisions of RESTCONF will use alternate relation values to support protocol versioning.
Reference: [ RFC-to-be ]
Notes:

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the YANG Module Names registry located at:

http://www.iana.org/assignments/yang-parameters/

a pair of YANG modules will be registered as follows:

Name: ietf-restconf
Namespace (Modules Only): urn:ietf:params:xml:ns:yang:ietf-restconf
Prefix (Modules Only): rc
Module (Submodules Only):
Reference: [ RFC-to-be ]

Name: ietf-restconf-monitoring
Namespace (Modules Only): urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring
Prefix (Modules Only): rcmon
Module (Submodules Only):
Reference: [ RFC-to-be ]

Third, in namespaces (ns) subregistry of the IETF XML registry located at:

http://www.iana.org/assignments/xml-registry/

two new namespaces are to be registered as follows:

ID: yang:ietf-restconf
URI: urn:ietf:params:xml:ns:yang:ietf-restconf
Filename: [ TBD-at-rregistration ]
Reference: { RFC-to-be ]

ID: yang:ietf-restconf-monitoring
URI: urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring
Filename: [ TBD-at-rregistration ]
Reference: { RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Fourth, in the application subregistry of the Media Types registry located at:

http://www.iana.org/assignments/media-types/

two new registrations are to be made as follows:

Name: yang-data
Template: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

Name: yang-data+json
Template: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Fifth, a new registry is to be created called the RESTCONF Capability URNs registry.

IANA QUESTION -> Where should this new registry be located? Is it a néw registry on the IANA Matrix or is it a subregistry of an existing registry? If it is a subregistry of an existing registry, in which registry will it be contained?

The new registry will be maintained using IETF Review as defined in RFC5226. There are initial registrations in the new registry as follows:

Index Capability Identifier Reference
----------------+-----------------------------------------------------+-------------
:defaults urn:ietf:params:restconf:capability:defaults:1.0 [ RFC-to-be ]
:depth urn:ietf:params:restconf:capability:depth:1.0 [ RFC-to-be ]
:fields urn:ietf:params:restconf:capability:fields:1.0 [ RFC-to-be ]
:filter urn:ietf:params:restconf:capability:filter:1.0 [ RFC-to-be ]
:replay urn:ietf:params:restconf:capability:replay:1.0 [ RFC-to-be ]
:with-defaults urn:ietf:params:restconf:capability:with-defaults:1.0 [ RFC-to-be ]


IANA understands that the five actions above are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN
2016-08-03
15 (System) IESG state changed to Waiting for Writeup from In Last Call
2016-08-01
15 Dale Worley Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Dale Worley.
2016-07-25
15 Gunter Van de Velde Request for Early review by OPSDIR Completed: Has Issues. Reviewer: Lionel Morand.
2016-07-21
15 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready. Reviewer: Liang Xia.
2016-07-14
15 Jean Mahoney Request for Last Call review by GENART is assigned to Dale Worley
2016-07-14
15 Jean Mahoney Request for Last Call review by GENART is assigned to Dale Worley
2016-07-14
15 Jean Mahoney Request for Last Call review by GENART is assigned to Robert Sparks
2016-07-14
15 Jean Mahoney Request for Last Call review by GENART is assigned to Robert Sparks
2016-07-14
15 Tero Kivinen Request for Last Call review by SECDIR is assigned to Liang Xia
2016-07-14
15 Tero Kivinen Request for Last Call review by SECDIR is assigned to Liang Xia
2016-07-13
15 Amy Vezza IANA Review state changed to IANA - Review Needed
2016-07-13
15 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: bclaise@cisco.com, draft-ietf-netconf-restconf@ietf.org, mehmet.ersue@nokia.com, netconf-chairs@ietf.org, netconf@ietf.org
Reply-To: ietf@ietf.org …
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: bclaise@cisco.com, draft-ietf-netconf-restconf@ietf.org, mehmet.ersue@nokia.com, netconf-chairs@ietf.org, netconf@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (RESTCONF Protocol) to Proposed Standard


The IESG has received a request from the Network Configuration WG
(netconf) to consider the following document:
- 'RESTCONF Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-08-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes an HTTP-based protocol that provides a
  programmatic interface for accessing data defined in YANG, using the
  datastore concepts defined in NETCONF.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ballot/


No IPR declarations have been submitted directly on this I-D.


2016-07-13
15 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2016-07-13
15 Amy Vezza Last call announcement was changed
2016-07-13
15 Benoît Claise Last call was requested
2016-07-13
15 Benoît Claise Last call announcement was generated
2016-07-13
15 Benoît Claise Ballot approval text was generated
2016-07-13
15 Benoît Claise Ballot writeup was generated
2016-07-13
15 Benoît Claise IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2016-07-07
15 (System) Sub state has been changed to AD Followup from Revised ID Needed
2016-07-07
15 Andy Bierman New version available: draft-ietf-netconf-restconf-15.txt
2016-06-30
14 Benoît Claise Reviewed v14. Some of the comments are not addressed.
2016-06-30
14 Benoît Claise IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2016-06-28
14 (System) Sub state has been changed to AD Followup from Revised ID Needed
2016-06-28
14 Andy Bierman New version available: draft-ietf-netconf-restconf-14.txt
2016-05-31
13 Benoît Claise IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2016-05-21
13 Gunter Van de Velde Request for Early review by OPSDIR is assigned to Lionel Morand
2016-05-21
13 Gunter Van de Velde Request for Early review by OPSDIR is assigned to Lionel Morand
2016-05-20
13 Benoît Claise IESG state changed to AD Evaluation from Publication Requested
2016-05-02
13 Cindy Morgan IESG process started in state Publication Requested
2016-05-02
13 Cindy Morgan Working group state set to Submitted to IESG for Publication
2016-05-02
13 Benoît Claise Intended Status changed to Proposed Standard from None
2016-05-02
13 Benoît Claise Changed consensus to Yes from Unknown
2016-05-02
13 Benoît Claise Shepherding AD changed to Benoit Claise
2016-05-01
13 Mehmet Ersue Changed document writeup
2016-05-01
13 Mehmet Ersue Notification list changed to "Mehmet Ersue" <mehmet.ersue@nokia.com>
2016-05-01
13 Mehmet Ersue Document shepherd changed to Mehmet Ersue
2016-04-27
13 Andy Bierman New version available: draft-ietf-netconf-restconf-13.txt
2016-04-12
12 Andy Bierman New version available: draft-ietf-netconf-restconf-12.txt
2016-04-10
11 Andy Bierman New version available: draft-ietf-netconf-restconf-11.txt
2016-03-16
10 Andy Bierman New version available: draft-ietf-netconf-restconf-10.txt
2016-01-14
09 Tero Kivinen Request for Early review by SECDIR Completed: Has Issues. Reviewer: Liang Xia.
2015-12-22
09 Tero Kivinen Request for Early review by SECDIR is assigned to Liang Xia
2015-12-22
09 Tero Kivinen Request for Early review by SECDIR is assigned to Liang Xia
2015-12-19
09 Jean Mahoney Request for Early review by GENART is assigned to Robert Sparks
2015-12-19
09 Jean Mahoney Request for Early review by GENART is assigned to Robert Sparks
2015-12-15
09 Andy Bierman New version available: draft-ietf-netconf-restconf-09.txt
2015-10-18
08 Andy Bierman New version available: draft-ietf-netconf-restconf-08.txt
2015-07-06
07 Andy Bierman New version available: draft-ietf-netconf-restconf-07.txt
2015-06-20
06 Andy Bierman New version available: draft-ietf-netconf-restconf-06.txt
2015-06-04
05 Andy Bierman New version available: draft-ietf-netconf-restconf-05.txt
2015-01-30
04 Andy Bierman New version available: draft-ietf-netconf-restconf-04.txt
2014-10-25
03 Andy Bierman New version available: draft-ietf-netconf-restconf-03.txt
2014-10-08
02 Andy Bierman New version available: draft-ietf-netconf-restconf-02.txt
2014-07-03
01 Andy Bierman New version available: draft-ietf-netconf-restconf-01.txt
2014-03-23
00 Andy Bierman New version available: draft-ietf-netconf-restconf-00.txt