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 |