Network Coding for Satellite Systems
draft-irtf-nwcrg-network-coding-satellites-15
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2021-01-19
|
15 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2021-01-08
|
15 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-12-22
|
15 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2020-12-01
|
15 | (System) | RFC Editor state changed to EDIT |
2020-11-30
|
15 | (System) | IANA Action state changed to No IANA Actions |
2020-11-30
|
15 | Colin Perkins | IRTF state changed to Sent to the RFC Editor from Waiting for IRTF Chair |
2020-11-30
|
15 | Colin Perkins | Sent request for publication to the RFC Editor |
2020-11-16
|
15 | Vincent Roca | IRTF state changed to Waiting for IRTF Chair from Waiting for Document Shepherd |
2020-11-03
|
15 | Vincent Roca | This document is the product and represents the consensus of the Coding for Efficient Network Communications Research Group (NWCRG). It discusses opportunities for adding network … This document is the product and represents the consensus of the Coding for Efficient Network Communications Research Group (NWCRG). It discusses opportunities for adding network coding techniques above the network OSI layer in satellite communication systems. The document went through two RG Last Calls (April 2019 and October 2019), it has been shared on the dtn@ietf.org list as well (which generated many challenging yet useful comments from one of the participants), and has been carefully reviewed by the RG Chairs. I believe this document is now ready for IRSG review. Following the IESG evaluation, and more particularly Benjamin Kaduk comment, the authors added in v15 related works on VSAT (in)security that calls for traffic encryption. The other comment on related IETF work is well known by the IRTF group and authors. There is no direct reference in this document, but this is the case in RFC 8406 (cited) for instance. |
2020-10-30
|
15 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2020-10-30
|
15 | Nicolas Kuhn | New version available: draft-irtf-nwcrg-network-coding-satellites-15.txt |
2020-10-30
|
15 | (System) | New version approved |
2020-10-30
|
15 | (System) | Request for posting confirmation emailed to previous authors: Emmanuel Lochin , Nicolas Kuhn |
2020-10-30
|
15 | Nicolas Kuhn | Uploaded new revision |
2020-10-27
|
14 | Colin Perkins | IESG conflict review completed: "The IESG has concluded that this work is related to IETF work done in the rmt, tsvwg, and quic WGs, but … IESG conflict review completed: "The IESG has concluded that this work is related to IETF work done in the rmt, tsvwg, and quic WGs, but this relationship does not prevent publishing". There is a comment from Benjamin Kaduk in the datatracker at https://datatracker.ietf.org/doc/conflict-review-irtf-nwcrg-network-coding-satellites/ballot/ – does this require a document update? |
2020-10-27
|
14 | Colin Perkins | Tag IESG Review Completed set. |
2020-10-27
|
14 | Colin Perkins | IRTF state changed to Waiting for Document Shepherd from In IESG Review |
2020-06-24
|
14 | (System) | IANA Review state changed to IANA OK - No Actions Needed |
2020-06-24
|
14 | Michelle Cotton | (Via drafts-eval-comment@iana.org): IESG/Authors/IRTF Chair: The IANA Functions Operator has reviewed draft-irtf-nwcrg-network-coding-satellites-14 and has the following comments: We understand that this document doesn't require any … (Via drafts-eval-comment@iana.org): IESG/Authors/IRTF Chair: The IANA Functions Operator has reviewed draft-irtf-nwcrg-network-coding-satellites-14 and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Michelle Cotton Protocol Parameters Engagement Sr. Manager IANA Services |
2020-06-23
|
14 | Colin Perkins | IETF conflict review initiated - see conflict-review-irtf-nwcrg-network-coding-satellites |
2020-06-23
|
14 | Colin Perkins | -14 addressed IRSG final poll comments; sending for IESG conflict review. |
2020-06-23
|
14 | Colin Perkins | IRTF state changed to In IESG Review from Waiting for Document Shepherd |
2020-05-29
|
14 | (System) | Revised ID Needed tag cleared |
2020-05-29
|
14 | Nicolas Kuhn | New version available: draft-irtf-nwcrg-network-coding-satellites-14.txt |
2020-05-29
|
14 | (System) | New version approved |
2020-05-29
|
14 | (System) | Request for posting confirmation emailed to previous authors: Nicolas Kuhn , Emmanuel Lochin |
2020-05-29
|
14 | Nicolas Kuhn | Uploaded new revision |
2020-05-25
|
13 | Colin Perkins | IRSG poll completed. Needs updated draft to address nits, then ready to progress. Poll results at https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-satellites/ballot/irsg/ |
2020-05-25
|
13 | Colin Perkins | Tag Revised I-D Needed set. |
2020-05-25
|
13 | Colin Perkins | IRTF state changed to Waiting for Document Shepherd from In IRSG Poll |
2020-05-25
|
13 | Colin Perkins | Closed "IRSG Approve" ballot |
2020-05-22
|
13 | Spencer Dawkins | [Ballot comment] My ballot was previously sent to the IRSG via e-mail, but I'm recording it here, since the datatracker now allows at-large IRSG members … [Ballot comment] My ballot was previously sent to the IRSG via e-mail, but I'm recording it here, since the datatracker now allows at-large IRSG members to enter their own ballots. A nit - "A glossary is proposed in Section 6 to clarify the terminology use throughout the document." should probably be something like "A glossary is included in Section 6 to clarify the terminology use throughout the document." I'm not sure I can parse While there is an active research Community working on network coding techniques above the network layer in general and in SATCOM in particular, not much of this work made it to commercial systems in ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the satellite industry. Is "made it to commercial systems" something like "has been deployed in commercial systems"? Now that you are requesting publication, you can probably change In this context, this document aims at ^^^^^^ identifying opportunities for further usage of network coding in ^^^^^^^^^^^ commercial SATCOM networks. to In this context, this document identifies opportunities for further usage of network coding in ^^^^^^^^^ commercial SATCOM networks. I know it's hard to say clearly, but o Forward Erasure Correction (FEC) (also called Application-Level FEC) operates in and above the network layer and targets packet ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ loss recovery. "in and above the network layer" is ambiguous. I think it means "in, above, or both", but it's hard to read. Perhaps o Forward Erasure Correction (FEC) (also called Application-Level FEC) operates above the PHYsical (PHY) layer and targets packet ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ loss recovery. (since you used that term in the previous bullet), or "above the link payer" if that term is more accurate. Using ISO terms to describe an Internet protocol stack is hard ("subnetwork layer" is another choice) :-) In There are multiple SATCOM systems, for example broadcast TV, point to point communication or IoT and monitoring ^^^^^^^^^^^^^^^^^^ Is "IoT and monitoring" one term or two? If "two", "monitoring" is vague (would this include medical monitoring?) If you can qualify "monitoring" in any way, that would be clearer to me. In This could also be achieved by using other multicast or broadcast systems, such as NACK-Oriented Reliable Multicast (NORM) [RFC5740] or File Delivery over Unidirectional Transport (FLUTE) [RFC6726]. Both NORM and FLUTE are limited to block coding, none of them supporting ^^^^^^^^^^^^^^ more flexible sliding window encoding schemes that allow decoding before receiving the whole block an added delay benefit [RFC8406][RFC8681]. should probably be "; neither of them" with a semicolon. This text Depending on the use-case (e.g., very high frequency bands, mobile users) or ^^^^^^^^ depending on the deployment use-cases (e.g., performance of the ^^^^^^^^^ network between each individual data block), the relevance of adding network coding is different. uses the same term in two very different contexts, and only one is qualified. Is there a qualifier you can attach to the first use? Or could these examples be merged into one list of use case examples? In this text, Many SATCOM systems typically use Performance Enhancing Proxy (PEP) RFC 3135 [RFC3135]. PEPs usually split end-to-end connections and forward transport or application layer packets to the satellite baseband gateway that deals with layer-2 and layer-1 encapsulation. ^^^^^^^^^^^^^^^^^^^ PEPs contribute to mitigate congestion in a SATCOM systems by limiting the impact of long delays on Internet protocols. A PEP mechanism could also include network coding operation and thus support the use-cases that have been discussed in the Section 3 of this document. Are these PHY (used previously) and Link Layers? Or something else? If this is a new term for the same thing, it would be great to pick one term and use it consistently. I think this Communications among deep-space platforms and terrestrial gateways can be a challenge. Reliable end-to-end (E2E) communications over such paths must cope with very long delays and frequent link disruptions; indeed, E2E connectivity may be available only ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ intermittently. Delay/Disruption Tolerant Networking (DTN) [RFC4838] ^^^^^^^^^^^^^^ is a solution to enable reliable internetworking space communications where both standard ad-hoc routing and E2E Internet protocols cannot be used. Moreover, DTN can also be seen as an alternative solution to transfer data between a central PEP and a remote PEP. is more correctly "E2E connectivity may only be available intermittently, if at all" - there may not be a continuous end-to-end path at all in DTN, or do I misunderstand? In this text, o PEP: Performance Enhancing Proxy [RFC3135] - a typical PEP for satellite communications include compression, caching and TCP ^^^ acceleration; ^^^^^^^^^^^^ I know "TCP acceleration" is the correct marketing term (I worked at a company that sold them, in my darkest past), but would it be correct to say something like "TCP ACK spoofing", or "TCP connection splicing", which is I think the 3GPP term? |
2020-05-22
|
13 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2020-05-22
|
13 | Lars Eggert | [Ballot comment] Section 3.4., paragraph 1: > This use-case considers using network coding in the scenario where a > lossy WIFI link is … [Ballot comment] Section 3.4., paragraph 1: > This use-case considers using network coding in the scenario where a > lossy WIFI link is used to connect to the SATCOM network. When > encrypted end-to-end applications based on UDP are used, a > Performance Enhancing Proxy (PEP) cannot operate hence other > mechanism need to be used. The WIFI packet losses will result in an > end-to-end retransmission that will harm the end-user quality of > experience and poorly utilize SATCOM bottleneck resource for non- > revenue generating traffic. In this use-case, adding network coding > techniques will prevent the end-to-end retransmission from occurring > since the packet losses would probably recovered. It's 2020. 802.11 reaches multiple Gs of application-level goodput. It couldn't do that if it didn't handle L2 loss efficiently already. Where are these hypothetical lossy WLANs? Also, if this were an issue it wouldn't be a satcom-specific one, so it's not clear why it needs to be discussed in this draft (the WAN RTT is >> the LAN one, even without a sat link involved.) |
2020-05-22
|
13 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
2020-05-20
|
13 | Carsten Bormann | [Ballot comment] I'm always a bit surprised when people are still paying lip service to the OSI model (and then call it ISO model); in … [Ballot comment] I'm always a bit surprised when people are still paying lip service to the OSI model (and then call it ISO model); in the I*TF context by now I'm expecting references to the Internet layer model (RFC 1122). Other nits have been sent to the authors. Thank you for compiling this information! |
2020-05-20
|
13 | Carsten Bormann | [Ballot Position Update] New position, Yes, has been recorded for Carsten Bormann |
2020-05-19
|
13 | Jianfei(Jeffrey) HE | [Ballot comment] I reviewed it and think it is ready to go. The use cases are clearly described and helpful to understand the application of … [Ballot comment] I reviewed it and think it is ready to go. The use cases are clearly described and helpful to understand the application of network coding in Satellite systems. One minor thing in its reference part somehow comes to my attention : ) It looks strange to quote a draft written in 2017 with "work in progress". Should these (as below) be changed to "expired" to keep consistent with their status in the datatracker? [I-D.chin-nfvrg-cloud-5g-core-structure-yang] Chen, C. and Z. Pan, "Yang Data Model for Cloud Native 5G Core structure", draft-chin-nfvrg-cloud-5g-core-structure- yang-00 (work in progress), December 2017. [I-D.vazquez-nfvrg-netcod-function-virtualization] Vazquez-Castro, M., Do-Duy, T., Romano, S., and A. Tulino, "Network Coding Function Virtualization", draft-vazquez- nfvrg-netcod-function-virtualization-02 (work in progress), November 2017. |
2020-05-19
|
13 | Jianfei(Jeffrey) HE | [Ballot Position Update] New position, Yes, has been recorded for Jianfei He |
2020-05-15
|
13 | Rodney Van Meter | [Ballot comment] I skimmed it. Other than my uncertainty as to whether "this is not an IETF product" is appropriate and accurate, I have no … [Ballot comment] I skimmed it. Other than my uncertainty as to whether "this is not an IETF product" is appropriate and accurate, I have no objections. I will say I found the ASCII art system figures a little harder to parse than most such, largely because I found it took quite a bit of attention to parse which are unidirectional, high-latency links and which are bidirectional, low-latency links. |
2020-05-15
|
13 | Rodney Van Meter | [Ballot Position Update] New position, No Objection, has been recorded for Rodney Van Meter |
2020-05-14
|
13 | Dirk Kutscher | [Ballot Position Update] New position, Yes, has been recorded for Dirk Kutscher |
2020-05-11
|
13 | Melinda Shore | [Ballot comment] This is not my area of expertise but I thought it was clear and easily understandable and that it did not contain any … [Ballot comment] This is not my area of expertise but I thought it was clear and easily understandable and that it did not contain any obviously problematic material. One minor typo in the last sentence of section 3.4: "In this use-case, adding network coding techniques will prevent the end-to-end retransmission from occurring since the packet losses would probably recovered." I don't know if that should be "recover" or "be recovered" (or something else entirely). I'm also curious how various network coding mechanisms would or would not work for encrypted traffic (for example, mixing), but I am comfortable with that being out-of-scope for this document. |
2020-05-11
|
13 | Melinda Shore | [Ballot Position Update] New position, Yes, has been recorded for Melinda Shore |
2020-05-05
|
13 | David Oran | [Ballot comment] I reviewed this during last call and thought it was essentially ready then. I quickly skimmed the new version and I think it's … [Ballot comment] I reviewed this during last call and thought it was essentially ready then. I quickly skimmed the new version and I think it's ready to go. |
2020-05-05
|
13 | David Oran | [Ballot Position Update] New position, No Objection, has been recorded for David Oran |
2020-05-05
|
13 | Mirja Kühlewind | [Ballot comment] Comments were already sent by mail; repeating here for the record: I reviewed this document and think it is ready to go. A … [Ballot comment] Comments were already sent by mail; repeating here for the record: I reviewed this document and think it is ready to go. A few small editorial points: Based on the RFC style guide you cannot have references in the abstract (meaning just remove the actual reference and only write RFC8406). Also I think the abstract could be a bit short and more crisp. And while there is an nice and quiet extensive glossary at the end, there are a couple of mostly well-know acronyms which might still be worth spelling out on first occurrence, given the desired audience: mainly FEC, CPE, RTT, and DTN. And finally the security considerations section is quite short, which is fine as. I don’t think there is much to discuss, but maybe there is a good reference to give to another NC document that has more discussion about security implication…? |
2020-05-05
|
13 | Mirja Kühlewind | Ballot comment text updated for Mirja Kühlewind |
2020-05-05
|
13 | Mirja Kühlewind | [Ballot Position Update] New position, Yes, has been recorded for Mirja Kühlewind |
2020-05-04
|
13 | Colin Perkins | IRTF state changed to In IRSG Poll from Waiting for IRTF Chair |
2020-05-04
|
13 | Colin Perkins | Created IRSG Ballot |
2020-05-04
|
13 | Colin Perkins | IRSG review completed. Ready for final poll. |
2020-05-04
|
13 | Colin Perkins | IRTF state changed to Waiting for IRTF Chair from Waiting for Document Shepherd |
2020-04-27
|
13 | (System) | Revised ID Needed tag cleared |
2020-04-27
|
13 | Nicolas Kuhn | New version available: draft-irtf-nwcrg-network-coding-satellites-13.txt |
2020-04-27
|
13 | (System) | New version accepted (logged-in submitter: Nicolas Kuhn) |
2020-04-27
|
13 | Nicolas Kuhn | Uploaded new revision |
2020-04-27
|
12 | Colin Perkins | Minor revision needed, to address review from Mirja. |
2020-04-27
|
12 | Colin Perkins | Tag Revised I-D Needed set. |
2020-04-27
|
12 | Colin Perkins | IRTF state changed to Waiting for Document Shepherd from Awaiting IRSG Reviews |
2020-04-20
|
12 | Colin Perkins | IRTF state changed to Awaiting IRSG Reviews from Waiting for Document Shepherd |
2020-04-14
|
12 | (System) | Revised ID Needed tag cleared |
2020-04-14
|
12 | Nicolas Kuhn | New version available: draft-irtf-nwcrg-network-coding-satellites-12.txt |
2020-04-14
|
12 | (System) | New version approved |
2020-04-14
|
12 | (System) | Request for posting confirmation emailed to previous authors: irtf-chair@irtf.org, nwcrg-chairs@ietf.org, Emmanuel Lochin , Nicolas Kuhn |
2020-04-14
|
12 | Nicolas Kuhn | Uploaded new revision |
2020-04-13
|
11 | Colin Perkins | Revised I-D needed to address editorial nits, before IRSG review. |
2020-04-13
|
11 | Colin Perkins | Tag Revised I-D Needed set. |
2020-04-13
|
11 | Colin Perkins | IRTF state changed to Waiting for Document Shepherd from Waiting for IRTF Chair |
2020-04-13
|
11 | Colin Perkins | Changed consensus to Yes from Unknown |
2020-04-05
|
11 | Vincent Roca | Intended Status changed to Informational from None |
2020-03-26
|
11 | Vincent Roca | IRTF state changed to Waiting for IRTF Chair from Waiting for Document Shepherd |
2020-03-25
|
11 | Vincent Roca | This document is the product and represents the consensus of the Coding for Efficient Network Communications Research Group (NWCRG). It discusses opportunities for adding network … This document is the product and represents the consensus of the Coding for Efficient Network Communications Research Group (NWCRG). It discusses opportunities for adding network coding techniques above the network OSI layer in satellite communication systems. The document went through two RG Last Calls (April 2019 and October 2019), it has been shared on the dtn@ietf.org list as well (which generated many challenging yet useful comments from one of the participants), and has been carefully reviewed by the RG Chairs. I believe this document is now ready for IRSG review. |
2020-03-09
|
11 | Vincent Roca | IRTF state changed to Waiting for Document Shepherd from In RG Last Call |
2020-02-28
|
11 | Nicolas Kuhn | New version available: draft-irtf-nwcrg-network-coding-satellites-11.txt |
2020-02-28
|
11 | (System) | New version approved |
2020-02-28
|
11 | (System) | Request for posting confirmation emailed to previous authors: Emmanuel Lochin , Nicolas Kuhn |
2020-02-28
|
11 | Nicolas Kuhn | Uploaded new revision |
2020-02-27
|
10 | Nicolas Kuhn | New version available: draft-irtf-nwcrg-network-coding-satellites-10.txt |
2020-02-27
|
10 | (System) | New version approved |
2020-02-27
|
10 | (System) | Request for posting confirmation emailed to previous authors: Nicolas Kuhn , Emmanuel Lochin |
2020-02-27
|
10 | Nicolas Kuhn | Uploaded new revision |
2019-12-11
|
09 | Nicolas Kuhn | New version available: draft-irtf-nwcrg-network-coding-satellites-09.txt |
2019-12-11
|
09 | (System) | New version approved |
2019-12-11
|
09 | (System) | Request for posting confirmation emailed to previous authors: Nicolas Kuhn , Emmanuel Lochin |
2019-12-11
|
09 | Nicolas Kuhn | Uploaded new revision |
2019-11-18
|
08 | Nicolas Kuhn | New version available: draft-irtf-nwcrg-network-coding-satellites-08.txt |
2019-11-18
|
08 | (System) | New version approved |
2019-11-18
|
08 | (System) | Request for posting confirmation emailed to previous authors: Nicolas Kuhn , Emmanuel Lochin |
2019-11-18
|
08 | Nicolas Kuhn | Uploaded new revision |
2019-10-30
|
07 | Nicolas Kuhn | New version available: draft-irtf-nwcrg-network-coding-satellites-07.txt |
2019-10-30
|
07 | (System) | New version approved |
2019-10-30
|
07 | (System) | Request for posting confirmation emailed to previous authors: Nicolas Kuhn , Emmanuel Lochin |
2019-10-30
|
07 | Nicolas Kuhn | Uploaded new revision |
2019-08-20
|
06 | Nicolas Kuhn | New version available: draft-irtf-nwcrg-network-coding-satellites-06.txt |
2019-08-20
|
06 | (System) | New version approved |
2019-08-20
|
06 | (System) | Request for posting confirmation emailed to previous authors: Nicolas Kuhn , Emmanuel Lochin |
2019-08-20
|
06 | Nicolas Kuhn | Uploaded new revision |
2019-06-04
|
05 | (System) | Revised ID Needed tag cleared |
2019-06-04
|
05 | Nicolas Kuhn | New version available: draft-irtf-nwcrg-network-coding-satellites-05.txt |
2019-06-04
|
05 | (System) | New version approved |
2019-06-04
|
05 | (System) | Request for posting confirmation emailed to previous authors: Nicolas Kuhn , Emmanuel Lochin |
2019-06-04
|
05 | Nicolas Kuhn | Uploaded new revision |
2019-05-13
|
04 | Vincent Roca | RG Last Call started April 18th for 3 weeks till May 9th. |
2019-05-13
|
04 | Vincent Roca | Tag Revised I-D Needed set. |
2019-05-13
|
04 | Vincent Roca | IRTF state changed to In RG Last Call |
2019-05-13
|
04 | Vincent Roca | Notification list changed to Vincent Roca <vincent.roca@inria.fr> |
2019-05-13
|
04 | Vincent Roca | Document shepherd changed to Vincent Roca |
2019-01-03
|
04 | Nicolas Kuhn | New version available: draft-irtf-nwcrg-network-coding-satellites-04.txt |
2019-01-03
|
04 | (System) | New version approved |
2019-01-03
|
04 | (System) | Request for posting confirmation emailed to previous authors: Nicolas Kuhn , Emmanuel Lochin |
2019-01-03
|
04 | Nicolas Kuhn | Uploaded new revision |
2018-12-11
|
03 | Nicolas Kuhn | New version available: draft-irtf-nwcrg-network-coding-satellites-03.txt |
2018-12-11
|
03 | (System) | New version approved |
2018-12-11
|
03 | (System) | Request for posting confirmation emailed to previous authors: Nicolas Kuhn , Emmanuel Lochin |
2018-12-11
|
03 | Nicolas Kuhn | Uploaded new revision |
2018-11-12
|
02 | Nicolas Kuhn | New version available: draft-irtf-nwcrg-network-coding-satellites-02.txt |
2018-11-12
|
02 | (System) | New version approved |
2018-11-12
|
02 | (System) | Request for posting confirmation emailed to previous authors: Nicolas Kuhn , Emmanuel Lochin |
2018-11-12
|
02 | Nicolas Kuhn | Uploaded new revision |
2018-11-11
|
01 | Nicolas Kuhn | New version available: draft-irtf-nwcrg-network-coding-satellites-01.txt |
2018-11-11
|
01 | (System) | New version approved |
2018-11-11
|
01 | (System) | Request for posting confirmation emailed to previous authors: Nicolas Kuhn , Emmanuel Lochin |
2018-11-11
|
01 | Nicolas Kuhn | Uploaded new revision |
2018-10-17
|
00 | Vincent Roca | This document now replaces draft-kuhn-nwcrg-network-coding-satellites instead of None |
2018-10-05
|
00 | Nicolas Kuhn | New version available: draft-irtf-nwcrg-network-coding-satellites-00.txt |
2018-10-05
|
00 | (System) | WG -00 approved |
2018-10-05
|
00 | Nicolas Kuhn | Set submitter to "Nicolas Kuhn ", replaces to (none) and sent approval email to group chairs: nwcrg-chairs@ietf.org |
2018-10-05
|
00 | Nicolas Kuhn | Uploaded new revision |