Manageability of the QUIC Transport Protocol
draft-ietf-quic-manageability-16
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2022-05-02
|
16 | Paul Wouters | [Ballot comment] Good document, thank you for doing this. Let's hope the middlebox vendors read it carefully. The following information is exposed in … [Ballot comment] Good document, thank you for doing this. Let's hope the middlebox vendors read it carefully. The following information is exposed in QUIC packet headers in all versions of QUIC: Does this mean the invariant parts? Or can this be variant parts that just happen to be true today? cryptographically obfuscates An odd term. I see obfuscation to be non-cryptographic and cryptographic transformation to not be as weak as to be seen as obfuscation (but as encryption or secure hashing) The Key Phase bit is cryptographically protected. So could this be only obfuscated, or do you mean really protected? :) However,if the connection ID is zero-length, all packets of the 5-tuple likely belong to the same QUIC connection. This is likely my ignorance, but why likely? Wouldn't NAT cause multiple clients on the same 4-tuple, and if both use connection ID 0, actually be a likely thing? or leaving unused payload in the UDP packet after the Initial packet. This reads a bit as in "uninitialized memory", which I am sure is not the case. While heuristics based on the first byte of the packet (packet type) could be used to separate valid from invalid first packet types, the deployment of such heuristics is not recommended, as bits in the first byte may have different meanings in future versions of the protocol. I would make this stronger than not recommended. For DNS with the DO and AD bits, routers doing stupid matching on the flags field and dropping the packets as "invalid DNS packets" caused a 5 year deployment delay of DNSSEC. The only thing the IETF could do was wait for these bad CPEs to become obsolete. E.g., PADDING frames, each consisting of a single zero byte, Padding can only happen for one byte per frame ? I guess I have to read up on the QUIC spec for this to make sense to me. |
|
2022-05-02
|
16 | Paul Wouters | [Ballot Position Update] New position, Yes, has been recorded for Paul Wouters |
|
2022-04-21
|
16 | Martin Duke | [Ballot comment] 2.1 Retry and VN packets “are not encrypted or protected in any way.” While this is made clear later in the document, it … [Ballot comment] 2.1 Retry and VN packets “are not encrypted or protected in any way.” While this is made clear later in the document, it would be good to way that Retry packets are (forgibly) integrity-protected and that QUIC TPs later authenticate most of the contents of these packets. 2.4 s/byes/bytes 3.1.1 it’s worth noting that compatible version negotiation can cause the version to change mid-handshake. The true signal is a server-chosen version field echoed in a client packet. 4.7 please update the QUIC-lb reference to draft-duke/ietf-quic-retry-offload. |
|
2022-04-21
|
16 | Martin Duke | [Ballot Position Update] New position, Yes, has been recorded for Martin Duke |
|
2022-04-21
|
16 | (System) | Changed action holders to Brian Trammell, Mirja Kühlewind (IESG state changed) |
|
2022-04-21
|
16 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
|
2022-04-21
|
16 | Robert Wilton | [Ballot comment] Hi, Thanks for this document that is well written and gives a lot of detail about various aspects of the QUIC. I would … [Ballot comment] Hi, Thanks for this document that is well written and gives a lot of detail about various aspects of the QUIC. I would also like to thank Al Morton for his review and for the authors diligently working with Al to reach a consensus position. I have to confess that I find some aspects of this document to be a bit of a odd duck, which I think that is based on the underlying design goals of QUIC to maximize privacy and prevent interference. I.e., a lot of the sections seem to end up implying that "you can't really do that in easy/reliable way with QUIC, or you shouldn't do it". From my reading of this doc, I get the overriding feeling that QUIC is not really designed to be easily distinguishable from regular UDP traffic, and at the same time, there seem to be some recommendations or suggestions about how QUIC traffic should be handled potentially differently from other UDP traffic under some circumstances. It will be interesting to see how QUIC deployment evolves over time, and whether some operators will restrict its usage to a few well known ports. Hopefully not. A few specific minor comments: 1. Section 1 states: No information in the protocol header, even that which can be inspected, is mutable by the network. This is enforced through integrity protection of the wire image [WIRE-IMAGE]. Section 2.1 states: Retry (Section 17.2.5 of [QUIC-TRANSPORT]) and Version Negotiation (Section 17.2.1 of [QUIC-TRANSPORT]) packets are not encrypted or protected in any way. Do these two statements conflict: re protection? 2. On long header packets, the length of the connection IDs is also present; on short header packets, the length of the destination connection ID is implicit. I presume that it is implicit in the sense that each endpoint knows how long the connection IDs are? 3. 2.6. Connection ID and Rebinding Further it can be used by in-network devices to ensure that related 5-tuple flows are appropriately balanced together. When I read this, I thought that you were talking about ECMP and L2 load-balancing over LAG, but I presume that is not the intention here, and that you are referring to application layer load balancing? Regards, Rob |
|
2022-04-21
|
16 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
|
2022-04-21
|
16 | Francesca Palombini | [Ballot comment] Thank you for the work on this document. Many thanks to Peter Saint-Andre for his review: https://mailarchive.ietf.org/arch/msg/art/jB34IuU065v-PcPjUwL4QX6Dz00/ , and thanks to the authors … [Ballot comment] Thank you for the work on this document. Many thanks to Peter Saint-Andre for his review: https://mailarchive.ietf.org/arch/msg/art/jB34IuU065v-PcPjUwL4QX6Dz00/ , and thanks to the authors for addressing it. Francesca |
|
2022-04-21
|
16 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
|
2022-04-21
|
16 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
|
2022-04-20
|
16 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
|
2022-04-20
|
16 | Zaheduzzaman Sarker | Changed consensus to Yes from Unknown |
|
2022-04-19
|
16 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if … [Ballot comment] Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Matt Joras for the shepherd's write-up including the WG consensus and the intended status. I hope that this helps to improve the document, Regards, -éric Note for the shepherding AD: missing consensus boilerplate. Should there be a section on the usefulness of IPFIX with QUIC ? ## Section 2.1 "All deployed versions are maintained in an IANA registry" is it "deployed" or "specified" ? I.e., an operator could always deploy an experimental version not yet in the IANA registry. The text appears inconsistent to me: - "Short headers contain only an optional destination connection ID" - "source and destination connection ID: short and long headers carry a destination connection ID", i.e., is it optional or not ? Also some inconsistency about the spin bit, is it only in v1 or is it an invariant ? Security ADs will know more of course but for me "cryptographically protected" is unclear whether it is confidentiality or integrity or both... Suggest to use "is confidentiality/integrity protected with cryptography" (or a lighter sentence than this one). ## Section 3 "Here we assume a bidirectional observer", let's also state that there is no section about unidirectional observer ? ## Section 3.1 Could the first 1200-byte QUIC packet be used to suspect a QUIC connection establishment ? ## Section 3.7 Can the data rate in each direction always be used to detect which side is the client/initiator vs. server/responder ? Even for HTTP/3 a POST can be larger than the reply. Or did I misread this paragraph ? ## Section 4.1 Suggest to expand "CE markings" ## Section 4.2 Thank you for this section, this may be the most useful one :-) (together with section 4.9) BTW, should there be 2 different time-outs? One for the "connection establishment" and one, longer, for "normal traffic". ## Section 4.6 "DDoS" is used while 4.7 use "DDOS" and expand the acronym ;-) (reading the I-D as first task in the morning with 2 cups of coffee has some side effects on my eyes ;-) ) |
|
2022-04-19
|
16 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
|
2022-04-19
|
16 | Lars Eggert | [Ballot comment] Section 2.1, paragraph 1, comment: > All deployed versions are maintained in an IANA > registry (see Section 22.2 … [Ballot comment] Section 2.1, paragraph 1, comment: > All deployed versions are maintained in an IANA > registry (see Section 22.2 of [QUIC-TRANSPORT]). I don't think it's correct to claim that "all deployed versions are maintained in an IANA registry" - many versions are being and have been deployed that are not in that IANA registry at all (see https://github.com/quicwg/base-drafts/wiki/QUIC-Versions); there is a huge range for experimental versions. Section 3.1, paragraph 1, comment: > At the time of writing, two application bindings for QUIC have been > published or adopted by the IETF: HTTP/3 [QUIC-HTTP] and DNS over > Dedicated QUIC Connections [I-D.ietf-dprive-dnsoquic]. These are > both known at the time of writing to have active Internet > deployments, so an assumption that all QUIC traffic is HTTP/3 is not > valid. HTTP/3 uses UDP port 443 by convention but various methods > can be used to specify alternate port numbers. Simple assumptions > about whether a given flow is using QUIC based upon a UDP port number > may therefore not hold; see also Section 5 of [RFC7605]. AFAIK Microsoft's SMB-over-QUIC also uses 443. The datatracker state does not indicate whether the consensus boilerplate should be included in this document. Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term "traditional"; alternatives might be "classic", "classical", "common", "conventional", "customary", "fixed", "habitual", "historic", "long-established", "popular", "prescribed", "regular", "rooted", "time-honored", "universal", "widely used", "widespread" * Term "invalid"; alternatives might be "not valid", "unenforceable", "not binding", "inoperative", "illegitimate", "incorrect", "improper", "unacceptable", "inapplicable", "revoked", "rescinded" Thanks to Elwyn Davies for their General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/5c_ZgBH4YmAn13j0IszsrYKTVmI). ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 2.1, paragraph 1, nit: - used to identify the connection associated with a QUIC packet, for + used by the endpoints to identify the connection associated with a QUIC packet, for + +++++++++++++++++ Section 2.1, paragraph 1, nit: - is implicit. + is only known to the endpoints. Section 2.1, paragraph 1, nit: - endpoints might use an extension that varies the bit. Therefore, + endpoints might use an extension that varies the bit [QUIC-GREASE]. Therefore, + ++++++++++++++ Section 2.1, paragraph 1, nit: - headers, while it is implicit (depending on destination connection - ^^^^^^ + headers, while it is known only to the endpoints (depending on destination connection + +++++++++++++++++++++++ ^ + Section 2.8, paragraph 1, nit: - ossification in the implementation on the selection mechanism. - ^ + ossification in the implementation of the selection mechanism. + ^ Section 2.8, paragraph 1, nit: - traffic recognition will therefore behave differently than with these - ^^^ ^ ^^^^^^^^^ + traffic recognition will therefore be more problematic than with these + ^^^^ ^^^^^^^^^ ^ Section 4.2, paragraph 1, nit: - forwarding decison is not viable as it will break connectivity, or at + forwarding decision is not viable as it will break connectivity, or at + + Section 4.8, paragraph 1, nit: - Note that the 5-tuple of a QUIC connnection can change due to - - Section 4.8, paragraph 1, nit: - maybe be treated differently, as congestion control is usualy reset + maybe be treated differently, as congestion control is usually reset + + Section 4.10, paragraph 1, nit: - DF bit set, because fragmention occurs below the IP layer. However, + DF bit set, because fragmentation occurs below the IP layer. However, + ++ Section 6, paragraph 1, nit: - However, some information is still observerable, as supporting - -- Section 8, paragraph 1, nit: - Special thanks to last call reviewers Elwyn Davies, Barry Lieba, Al - - + Special thanks to last call reviewers Elwyn Davies, Barry Leiba, Al + + Section 2.4, paragraph 1, nit: > delays that trigger a spurious Probe Timeout ({Section 6.2 of > RFC9002}). If QUIC packets get lost or reordered, packets belonging This looks like broken Markdown. Document references draft-ietf-quic-applicability-15, but -16 is the latest available revision. Document references draft-ietf-tsvwg-transport-encrypt, but that has been published as RFC9065. Paragraph 7659, nit: > TP/3 uses UDP port 443 by convention but various methods can be used to speci > ^^^^ Use a comma before "but" if it connects two independent clauses (unless they are closely connected and short). |
|
2022-04-19
|
16 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
|
2022-04-18
|
16 | Roman Danyliw | [Ballot comment] Thank you to Barry Leiba for the SECDIR review. Thank you for this companion document considering the operational view of the wire image. … [Ballot comment] Thank you to Barry Leiba for the SECDIR review. Thank you for this companion document considering the operational view of the wire image. It is a model to pattern for other protocols. ** Section 2.8 Using a particular version number to recognize valid QUIC traffic is likely to persistently miss a fraction of QUIC flows, and completely fail in the near future. Reliance on the version number field for the purposes of admission control is similarly likely to rapidly lead to unintended failure modes. Admission of QUIC traffic regardless of version avoids these failure modes, avoids unnecessary deployment delays, and supports continuous version-based evolution. -- True, but this guidance seems a bit too strong. Operators may choose to explicitly exclude traffic from particular “experimental versions" and should likely be curating their ACLs/admission control practices. -- Consider if the text "... likely to rapidly lead to unintended failure modes” will age well. -- Would there be an opportunity to fingerprint a unique application using a specific experimental version number (in an ecosystem of continuous evolution and experimentation suggested above)? ** Section 4.7. Other uses include support for security audits (e.g., verifying the compliance with ciphersuites); client and application fingerprinting for inventory; and to provide alerts for network intrusion detection and other next generation firewall functions. This text seems unrelated to the focus of this section -- DDoS detection and mitigation. Is it really needed? ** Section 4.7 Current practices in detection and mitigation of DDoS attacks generally involve classification of incoming traffic (as packets, flows, or some other aggregate) into "good" (productive) and "bad" (DDoS) traffic, This describes a “scrubbing” approach. DDoS mitigation can use the less nuanced rate limiting approach. DOTS has support for that too. ** Section 4.7 It is also possible for endpoints to directly support security functions such as DoS classification and mitigation. Endpoints can cooperate with an in-network device directly by e.g., sharing information about connection IDs. Does that happen now? How would that signaling work? Typos: ** Section 4.8. Typo. s/connnection/connection/ ** Section 4.8. Typo. s/usualy/usually/ |
|
2022-04-18
|
16 | Roman Danyliw | Ballot comment text updated for Roman Danyliw |
|
2022-04-18
|
16 | Roman Danyliw | [Ballot comment] Thank you to Barry Lieba for the SECDIR review. Thank you for this companion document considering the operational view of the wire image. … [Ballot comment] Thank you to Barry Lieba for the SECDIR review. Thank you for this companion document considering the operational view of the wire image. It is a model to pattern for other protocols. ** Section 2.8 Using a particular version number to recognize valid QUIC traffic is likely to persistently miss a fraction of QUIC flows, and completely fail in the near future. Reliance on the version number field for the purposes of admission control is similarly likely to rapidly lead to unintended failure modes. Admission of QUIC traffic regardless of version avoids these failure modes, avoids unnecessary deployment delays, and supports continuous version-based evolution. -- True, but this guidance seems a bit too strong. Operators may choose to explicitly exclude traffic from particular “experimental versions" and should likely be curating their ACLs/admission control practices. -- Consider if the text "... likely to rapidly lead to unintended failure modes” will age well. -- Would there be an opportunity to fingerprint a unique application using a specific experimental version number (in an ecosystem of continuous evolution and experimentation suggested above)? ** Section 4.7. Other uses include support for security audits (e.g., verifying the compliance with ciphersuites); client and application fingerprinting for inventory; and to provide alerts for network intrusion detection and other next generation firewall functions. This text seems unrelated to the focus of this section -- DDoS detection and mitigation. Is it really needed? ** Section 4.7 Current practices in detection and mitigation of DDoS attacks generally involve classification of incoming traffic (as packets, flows, or some other aggregate) into "good" (productive) and "bad" (DDoS) traffic, This describes a “scrubbing” approach. DDoS mitigation can use the less nuanced rate limiting approach. DOTS has support for that too. ** Section 4.7 It is also possible for endpoints to directly support security functions such as DoS classification and mitigation. Endpoints can cooperate with an in-network device directly by e.g., sharing information about connection IDs. Does that happen now? How would that signaling work? Typos: ** Section 4.8. Typo. s/connnection/connection/ ** Section 4.8. Typo. s/usualy/usually/ |
|
2022-04-18
|
16 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
|
2022-04-12
|
16 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
|
2022-04-12
|
16 | Cindy Morgan | Placed on agenda for telechat - 2022-04-21 |
|
2022-04-11
|
16 | Zaheduzzaman Sarker | Ballot has been issued |
|
2022-04-11
|
16 | Zaheduzzaman Sarker | [Ballot Position Update] New position, Yes, has been recorded for Zaheduzzaman Sarker |
|
2022-04-11
|
16 | Zaheduzzaman Sarker | Created "Approve" ballot |
|
2022-04-11
|
16 | Zaheduzzaman Sarker | IESG state changed to IESG Evaluation from Waiting for Writeup |
|
2022-04-11
|
16 | Zaheduzzaman Sarker | Ballot writeup was changed |
|
2022-04-06
|
16 | Brian Trammell | New version available: draft-ietf-quic-manageability-16.txt |
|
2022-04-06
|
16 | (System) | New version approved |
|
2022-04-06
|
16 | (System) | Request for posting confirmation emailed to previous authors: Brian Trammell <ietf@trammell.ch>, Mirja Kuehlewind <mirja.kuehlewind@ericsson.com> |
|
2022-04-06
|
16 | Brian Trammell | Uploaded new revision |
|
2022-03-07
|
15 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
|
2022-03-07
|
15 | Brian Trammell | New version available: draft-ietf-quic-manageability-15.txt |
|
2022-03-07
|
15 | (System) | New version approved |
|
2022-03-07
|
15 | (System) | Request for posting confirmation emailed to previous authors: Brian Trammell <ietf@trammell.ch>, Mirja Kuehlewind <mirja.kuehlewind@ericsson.com> |
|
2022-03-07
|
15 | Brian Trammell | Uploaded new revision |
|
2022-02-14
|
14 | Peter Saint-Andre | Request for Last Call review by ARTART Completed: Ready with Nits. Reviewer: Peter Saint-Andre. Sent review to list. |
|
2022-02-07
|
14 | Elwyn Davies | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Elwyn Davies. Sent review to list. |
|
2022-02-07
|
14 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
|
2022-02-05
|
14 | Al Morton | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Al Morton. Sent review to list. |
|
2022-02-04
|
14 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
|
2022-02-04
|
14 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-quic-manageability-14, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-quic-manageability-14, which is currently in Last Call, 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, Sabrina Tanamal Lead IANA Services Specialist |
|
2022-02-01
|
14 | Barry Leiba | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Barry Leiba. Sent review to list. |
|
2022-01-28
|
14 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Barry Leiba |
|
2022-01-28
|
14 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Barry Leiba |
|
2022-01-28
|
14 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
|
2022-01-28
|
14 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
|
2022-01-28
|
14 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Al Morton |
|
2022-01-28
|
14 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Al Morton |
|
2022-01-25
|
14 | Barry Leiba | Request for Last Call review by ARTART is assigned to Peter Saint-Andre |
|
2022-01-25
|
14 | Barry Leiba | Request for Last Call review by ARTART is assigned to Peter Saint-Andre |
|
2022-01-24
|
14 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
|
2022-01-24
|
14 | Cindy Morgan | The following Last Call announcement was sent out (ends 2022-02-07):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: Zaheduzzaman.Sarker@ericsson.com, draft-ietf-quic-manageability@ietf.org, … The following Last Call announcement was sent out (ends 2022-02-07):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: Zaheduzzaman.Sarker@ericsson.com, draft-ietf-quic-manageability@ietf.org, matt.joras@gmail.com, quic-chairs@ietf.org, quic@ietf.org Reply-To: last-call@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-quic-manageability-14.txt> (Manageability of the QUIC Transport Protocol) to Informational RFC The IESG has received a request from the QUIC WG (quic) to consider the following document: - 'Manageability of the QUIC Transport Protocol' <draft-ietf-quic-manageability-14.txt> as Informational RFC 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 last-call@ietf.org mailing lists by 2022-02-07. 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 discusses manageability of the QUIC transport protocol, focusing on the implications of QUIC's design and wire image on network operations involving QUIC traffic. It is intended as a "user's manual" for the wire image, providing guidance for network operators and equipment vendors who rely on the use of transport- aware network functions. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-quic-manageability/ No IPR declarations have been submitted directly on this I-D. |
|
2022-01-24
|
14 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
|
2022-01-24
|
14 | Zaheduzzaman Sarker | Last call was requested |
|
2022-01-24
|
14 | Zaheduzzaman Sarker | Last call announcement was generated |
|
2022-01-24
|
14 | Zaheduzzaman Sarker | Ballot approval text was generated |
|
2022-01-24
|
14 | Zaheduzzaman Sarker | Ballot writeup was generated |
|
2022-01-24
|
14 | Zaheduzzaman Sarker | IESG state changed to Last Call Requested from AD Evaluation |
|
2022-01-21
|
14 | Brian Trammell | New version available: draft-ietf-quic-manageability-14.txt |
|
2022-01-21
|
14 | (System) | New version approved |
|
2022-01-21
|
14 | (System) | Request for posting confirmation emailed to previous authors: Brian Trammell <ietf@trammell.ch>, Mirja Kuehlewind <mirja.kuehlewind@ericsson.com> |
|
2022-01-21
|
14 | Brian Trammell | Uploaded new revision |
|
2021-10-22
|
13 | (System) | Changed action holders to Zaheduzzaman Sarker (IESG state changed) |
|
2021-10-22
|
13 | Zaheduzzaman Sarker | IESG state changed to AD Evaluation from Publication Requested |
|
2021-10-06
|
13 | Matt Joras | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational. This is the proper type as this document is not a standard and is quite literally informational we'd like the Internet community to know about. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document discusses manageability of the QUIC transport protocol, focusing on the implications of QUIC's design and wire image on network operations involving QUIC traffic. Its intended audience is network operators and equipment vendors who rely on the use of transport-aware network functions. Working Group Summary: This document has been reviewed and contributed to by many participants in the QUIC WG, including those from companies with major QUIC deployments and operators of networks with significant QUIC traffic volumes. Document Quality: This document is informational and meant for network operators. There has been extensive feedback on the contents from implementers, QUIC deployments, network operators, and researchers. We believe it to be high quality information about QUIC for network operators. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Matt Joras is the document shepherd, Zahed Sarker the AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have reviewed the document several times both as an indivudal in the WG and now as a shepherd in its current form. I believe it is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No, it has gone through several reviews and we have a wide diversity of perspectives in the feedback so far. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. I don't believe so. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No specific concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? There are no IPR disclosures require for this document. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? It has received a wide diversity of review from implementers, deployers of QUIC, network operators, and researchers. There have been two WGLCs, where feedback from the first was integrated, thus the consensus is good though the engagement has overall been less than the original QUIC documents. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. 4 non-ascii characters, outdated references to documents now published as RFCs. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). N/A. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. N/A. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. N/A (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? N/A |
|
2021-10-06
|
13 | Matt Joras | Responsible AD changed to Zaheduzzaman Sarker |
|
2021-10-06
|
13 | Matt Joras | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
|
2021-10-06
|
13 | Matt Joras | IESG state changed to Publication Requested from I-D Exists |
|
2021-10-06
|
13 | Matt Joras | IESG process started in state Publication Requested |
|
2021-10-06
|
13 | Matt Joras | Tag Doc Shepherd Follow-up Underway cleared. |
|
2021-09-10
|
13 | Matt Joras | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational. This is the proper type as this document is not a standard and is quite literally informational we'd like the Internet community to know about. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document discusses manageability of the QUIC transport protocol, focusing on the implications of QUIC's design and wire image on network operations involving QUIC traffic. Its intended audience is network operators and equipment vendors who rely on the use of transport-aware network functions. Working Group Summary: This document has been reviewed and contributed to by many participants in the QUIC WG, including those from companies with major QUIC deployments and operators of networks with significant QUIC traffic volumes. Document Quality: This document is informational and meant for network operators. There has been extensive feedback on the contents from implementers, QUIC deployments, network operators, and researchers. We believe it to be high quality information about QUIC for network operators. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Matt Joras is the document shepherd, Zahed Sarker the AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have reviewed the document several times both as an indivudal in the WG and now as a shepherd in its current form. I believe it is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No, it has gone through several reviews and we have a wide diversity of perspectives in the feedback so far. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. I don't believe so. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No specific concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? There are no IPR disclosures require for this document. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? It has received a wide diversity of review from implementers, deployers of QUIC, network operators, and researchers. There have been two WGLCs, where feedback from the first was integrated, thus the consensus is good though the engagement has overall been less than the original QUIC documents. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. 4 non-ascii characters, outdated references to documents now published as RFCs. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). N/A. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. N/A. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. N/A (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? N/A |
|
2021-09-02
|
13 | Brian Trammell | New version available: draft-ietf-quic-manageability-13.txt |
|
2021-09-02
|
13 | (System) | New version approved |
|
2021-09-02
|
13 | (System) | Request for posting confirmation emailed to previous authors: Brian Trammell <ietf@trammell.ch>, Mirja Kuehlewind <mirja.kuehlewind@ericsson.com> |
|
2021-09-02
|
13 | Brian Trammell | Uploaded new revision |
|
2021-07-15
|
12 | Matt Joras | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational. This is the proper type as this document is not a standard and is quite literally informational we'd like the Internet community to know about. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document discusses manageability of the QUIC transport protocol, focusing on the implications of QUIC's design and wire image on network operations involving QUIC traffic. Its intended audience is network operators and equipment vendors who rely on the use of transport-aware network functions. Working Group Summary: This document has been reviewed and contributed to by many participants in the QUIC WG, including those from companies with major QUIC deployments and operators of networks with significant QUIC traffic volumes. Document Quality: This document is informational and meant for network operators. There has been extensive feedback on the contents from implementers, QUIC deployments, network operators, and researchers. We believe it to be high quality information about QUIC for network operators. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Matt Joras is the document shepherd, Zahed Sarker the AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have reviewed the document several times both as an indivudal in the WG and now as a shepherd in its current form. I believe it is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Not particularly, it has gone through several reviews and we have a wide diversity of perspectives in the feedback so far. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. I don't believe so. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No specific concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? There are no IPR disclosures require for this document. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? It has received a wide diversity of review from implementers, deployers of QUIC, network operators, and researchers. I would say the consensus is fairly good though the engagement has overall been less than the original QUIC documents. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. 4 non-ascii characters, outdated references to documents now published as RFCs. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). N/A. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. N/A. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. N/A (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? N/A |
|
2021-07-07
|
12 | Matt Joras | Tag Doc Shepherd Follow-up Underway set. |
|
2021-07-07
|
12 | Matt Joras | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
|
2021-07-07
|
12 | Matt Joras | Notification list changed to matt.joras@gmail.com because the document shepherd was set |
|
2021-07-07
|
12 | Matt Joras | Document shepherd changed to Matt Joras |
|
2021-06-30
|
12 | Brian Trammell | New version available: draft-ietf-quic-manageability-12.txt |
|
2021-06-30
|
12 | (System) | New version approved |
|
2021-06-30
|
12 | (System) | Request for posting confirmation emailed to previous authors: Brian Trammell <ietf@trammell.ch>, Mirja Kuehlewind <mirja.kuehlewind@ericsson.com> |
|
2021-06-30
|
12 | Brian Trammell | Uploaded new revision |
|
2021-04-21
|
11 | Brian Trammell | New version available: draft-ietf-quic-manageability-11.txt |
|
2021-04-21
|
11 | (System) | New version approved |
|
2021-04-21
|
11 | (System) | Request for posting confirmation emailed to previous authors: Brian Trammell <ietf@trammell.ch>, Mirja Kuehlewind <mirja.kuehlewind@ericsson.com> |
|
2021-04-21
|
11 | Brian Trammell | Uploaded new revision |
|
2021-02-22
|
10 | Mirja Kühlewind | New version available: draft-ietf-quic-manageability-10.txt |
|
2021-02-22
|
10 | (System) | New version approved |
|
2021-02-22
|
10 | (System) | Request for posting confirmation emailed to previous authors: Brian Trammell <ietf@trammell.ch>, Mirja Kuehlewind <mirja.kuehlewind@ericsson.com> |
|
2021-02-22
|
10 | Mirja Kühlewind | Uploaded new revision |
|
2021-02-04
|
09 | Matt Joras | IETF WG state changed to In WG Last Call from WG Document |
|
2021-01-22
|
09 | Brian Trammell | New version available: draft-ietf-quic-manageability-09.txt |
|
2021-01-22
|
09 | (System) | New version accepted (logged-in submitter: Brian Trammell) |
|
2021-01-22
|
09 | Brian Trammell | Uploaded new revision |
|
2020-11-02
|
08 | Brian Trammell | New version available: draft-ietf-quic-manageability-08.txt |
|
2020-11-02
|
08 | (System) | New version approved |
|
2020-11-02
|
08 | (System) | Request for posting confirmation emailed to previous authors: Brian Trammell <ietf@trammell.ch>, Mirja Kuehlewind <mirja.kuehlewind@ericsson.com> |
|
2020-11-02
|
08 | Brian Trammell | Uploaded new revision |
|
2020-11-02
|
08 | Brian Trammell | Uploaded new revision |
|
2020-07-08
|
07 | Brian Trammell | New version available: draft-ietf-quic-manageability-07.txt |
|
2020-07-08
|
07 | (System) | New version approved |
|
2020-07-08
|
07 | (System) | Request for posting confirmation emailed to previous authors: Brian Trammell <ietf@trammell.ch>, Mirja Kuehlewind <mirja.kuehlewind@ericsson.com> |
|
2020-07-08
|
07 | Brian Trammell | Uploaded new revision |
|
2020-07-08
|
07 | Brian Trammell | Uploaded new revision |
|
2020-01-06
|
06 | Brian Trammell | New version available: draft-ietf-quic-manageability-06.txt |
|
2020-01-06
|
06 | (System) | New version approved |
|
2020-01-06
|
06 | (System) | Request for posting confirmation emailed to previous authors: Brian Trammell <ietf@trammell.ch>, Mirja Kuehlewind <mirja.kuehlewind@ericsson.com> |
|
2020-01-06
|
06 | Brian Trammell | Uploaded new revision |
|
2020-01-06
|
06 | Brian Trammell | Uploaded new revision |
|
2020-01-06
|
05 | (System) | Document has expired |
|
2019-07-05
|
05 | Brian Trammell | New version available: draft-ietf-quic-manageability-05.txt |
|
2019-07-05
|
05 | (System) | New version approved |
|
2019-07-05
|
05 | (System) | Request for posting confirmation emailed to previous authors: Mirja Kuehlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Brian Trammell <ietf@trammell.ch>, quic-chairs@ietf.org |
|
2019-07-05
|
05 | Brian Trammell | Uploaded new revision |
|
2019-07-05
|
05 | Brian Trammell | Uploaded new revision |
|
2019-04-24
|
04 | Brian Trammell | New version available: draft-ietf-quic-manageability-04.txt |
|
2019-04-24
|
04 | (System) | New version approved |
|
2019-04-24
|
04 | (System) | Request for posting confirmation emailed to previous authors: Mirja Kuehlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Brian Trammell <ietf@trammell.ch> |
|
2019-04-24
|
04 | Brian Trammell | Uploaded new revision |
|
2019-04-24
|
04 | Brian Trammell | Uploaded new revision |
|
2018-10-22
|
03 | Brian Trammell | New version available: draft-ietf-quic-manageability-03.txt |
|
2018-10-22
|
03 | (System) | New version approved |
|
2018-10-22
|
03 | (System) | Request for posting confirmation emailed to previous authors: Mirja Kuehlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Brian Trammell <ietf@trammell.ch> |
|
2018-10-22
|
03 | Brian Trammell | Uploaded new revision |
|
2018-07-02
|
02 | Mirja Kühlewind | New version available: draft-ietf-quic-manageability-02.txt |
|
2018-07-02
|
02 | (System) | New version approved |
|
2018-07-02
|
02 | (System) | Request for posting confirmation emailed to previous authors: Mirja Kuehlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Brian Trammell <ietf@trammell.ch> |
|
2018-07-02
|
02 | Mirja Kühlewind | Uploaded new revision |
|
2018-04-28
|
01 | (System) | Document has expired |
|
2018-02-13
|
01 | Lars Eggert | Intended Status changed to Informational from None |
|
2017-10-25
|
01 | Mirja Kühlewind | New version available: draft-ietf-quic-manageability-01.txt |
|
2017-10-25
|
01 | (System) | New version approved |
|
2017-10-25
|
01 | (System) | Request for posting confirmation emailed to previous authors: Mirja Kuehlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Brian Trammell <ietf@trammell.ch>, Dan Druta <dd5826@att.com>, quic-chairs@ietf.org |
|
2017-10-25
|
01 | Mirja Kühlewind | Uploaded new revision |
|
2017-07-03
|
00 | Lars Eggert | This document now replaces draft-kuehlewind-quic-manageability instead of None |
|
2017-07-03
|
00 | Brian Trammell | New version available: draft-ietf-quic-manageability-00.txt |
|
2017-07-03
|
00 | (System) | WG -00 approved |
|
2017-07-03
|
00 | Brian Trammell | Set submitter to "Brian Trammell <ietf@trammell.ch>", replaces to (none) and sent approval email to group chairs: quic-chairs@ietf.org |
|
2017-07-03
|
00 | Brian Trammell | Uploaded new revision |