Results and analysis of the survey of I-D authors on formats and tools

2021-02-03 Thread IETF Executive Director
In October-November 2020 the IETF Administration LLC ran a survey of I-D 
authors on the formats and tools that they use.  This survey was issued to a 
total of 6037 email addresses, with that list built from the addresses of 
everyone who submitted an I-D, or was listed as an author, in the five years 
previous.  718 responses were received, giving a margin of error of +/- 3.43%. 
We wish to thank all of you that took the time to reply to this survey.

The results of this survey are now available as a basic web report:

https://ql.tc/T0WvDV

Additionally, the IETF Executive Director and Temporary RFC Series Project 
Manager have produced a detailed report of analysis and recommendations:


https://www.ietf.org/media/documents/REPORT__Survey_of_I-D_Authors_on_Formats_and_Tools.pdf

I recommend that any discussion on this subject takes place on either 
rfc-inter...@rfc-editor.org or tools-disc...@ietf.org as appropriate.

Please feel free to contact me directly if you have any questions.

-- 
Jay Daley
IETF Executive Director
exec-direc...@ietf.org

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


Deployment of new IETF ticketing system

2021-02-03 Thread IETF Secretariat
Tomorrow, 4 February, we will deploy a new IETF ticketing system. This change 
is being made in an effort to improve the issue reporting process; it was 
announced as part of the 109 technical retrospective [1] and emerged from 
recent meeting survey feedback [2]. The new ticketing system is the first step 
towards making it simpler for the IETF community to request assistance and 
report issues. 

The plan is to have a single ticketing system (JitBit), and a single address 
for reporting all issues (supp...@ietf.org), in place for IETF 110. This 
process will take place in several phases:

1. Tomorrow, all Secretariat reporting addresses will transition into the new 
IETF system, JitBit. All current reporting addresses (e.g., ietf-action, 
registrar, agenda, mtd) will continue to function as they do now. (Note that 
the current system, RT, will remain online for several months in order to allow 
for resolution of any currently active tickets). 

2. The NOC is also working to move to JitBit prior to IETF 110. The current 
Trac system will remain online for several months post-transition.

3. Before IETF 110, the disparate support addresses will be replaced by a 
single point of contact: supp...@ietf.org. The prior addresses will continue to 
function, but will not be publicly promoted on the website (or elsewhere) in an 
effort to encourage adoption of a single support address.

Alexa Morris
Managing Director, IETF Secretariat

[1] https://www.ietf.org/blog/ietf-109-technical-retrospective/
[2] https://www.ietf.org/blog/ietf-108-meeting-survey/

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


Protocol Action: 'Version-Independent Properties of QUIC' to Proposed Standard (draft-ietf-quic-invariants-13.txt)

2021-02-03 Thread The IESG
The IESG has approved the following document:
- 'Version-Independent Properties of QUIC'
  (draft-ietf-quic-invariants-13.txt) as Proposed Standard

This document is the product of the QUIC Working Group.

The IESG contact persons are Martin Duke and Magnus Westerlund.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-quic-invariants/




Technical Summary:

QUIC is a standards-track, UDP-based, stream-multiplexing, encrypted
transport protocol. Its main features are minimizing connection
establishment and overall transport latency for applications such as
HTTP/3, providing multiplexing without head-of-line blocking, requiring
only changes to path endpoints to enable deployment, providing
always-secure transport using TLS 1.3.

This document set specifies the QUIC transport protocol and it
version-independent invariants, its loss detection and recovery
approach, its use of TLS1.3 for providing security, and a new version of
HTTP that uses QUIC (HTTP/3), along with QPACK for header compression in
that protocol.

Working Group Summary:

As can be expected, discussion on many aspects of QUIC was quite
intense. The resulting consensus, however, was judged by the chairs to
be both strong and broad.

Document Quality:

There are over twenty implementations of QUIC that are participating in
interop testing, including all major web browsers and many server, CDN
and standalone library implementations.

The acknowledgements sections of the I-Ds highlight the individuals that
made major contributions to a given document.

Personnel:

The document shepherds for the individual I-Ds are:

-   Lucas Pardue:
-   draft-ietf-quic-http
-   draft-ietf-quic-qpack
-   Lars Eggert:
-   draft-ietf-quic-transport
-   draft-ietf-quic-recovery
-   Mark Nottingham:
-   draft-ietf-quic-tls
-   draft-ietf-quic-invariants

The responsible AD for the document set is Magnus Westerlund.


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


Protocol Action: 'QUIC Loss Detection and Congestion Control' to Proposed Standard (draft-ietf-quic-recovery-34.txt)

2021-02-03 Thread The IESG
The IESG has approved the following document:
- 'QUIC Loss Detection and Congestion Control'
  (draft-ietf-quic-recovery-34.txt) as Proposed Standard

This document is the product of the QUIC Working Group.

The IESG contact persons are Martin Duke and Magnus Westerlund.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/




Technical Summary:

QUIC is a standards-track, UDP-based, stream-multiplexing, encrypted
transport protocol. Its main features are minimizing connection
establishment and overall transport latency for applications such as
HTTP/3, providing multiplexing without head-of-line blocking, requiring
only changes to path endpoints to enable deployment, providing
always-secure transport using TLS 1.3.

This document set specifies the QUIC transport protocol and it
version-independent invariants, its loss detection and recovery
approach, its use of TLS1.3 for providing security, and a new version of
HTTP that uses QUIC (HTTP/3), along with QPACK for header compression in
that protocol.

Working Group Summary:

As can be expected, discussion on many aspects of QUIC was quite
intense. The resulting consensus, however, was judged by the chairs to
be both strong and broad.

Document Quality:

There are over twenty implementations of QUIC that are participating in
interop testing, including all major web browsers and many server, CDN
and standalone library implementations.

The acknowledgements sections of the I-Ds highlight the individuals that
made major contributions to a given document.

Personnel:

The document shepherds for the individual I-Ds are:

-   Lucas Pardue:
-   draft-ietf-quic-http
-   draft-ietf-quic-qpack
-   Lars Eggert:
-   draft-ietf-quic-transport
-   draft-ietf-quic-recovery
-   Mark Nottingham:
-   draft-ietf-quic-tls
-   draft-ietf-quic-invariants

The responsible AD for the document set is Magnus Westerlund.


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


Protocol Action: 'Using TLS to Secure QUIC' to Proposed Standard (draft-ietf-quic-tls-34.txt)

2021-02-03 Thread The IESG
The IESG has approved the following document:
- 'Using TLS to Secure QUIC'
  (draft-ietf-quic-tls-34.txt) as Proposed Standard

This document is the product of the QUIC Working Group.

The IESG contact persons are Martin Duke and Magnus Westerlund.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-quic-tls/




Technical Summary:

QUIC is a standards-track, UDP-based, stream-multiplexing, encrypted
transport protocol. Its main features are minimizing connection
establishment and overall transport latency for applications such as
HTTP/3, providing multiplexing without head-of-line blocking, requiring
only changes to path endpoints to enable deployment, providing
always-secure transport using TLS 1.3.

This document set specifies the QUIC transport protocol and it
version-independent invariants, its loss detection and recovery
approach, its use of TLS1.3 for providing security, and a new version of
HTTP that uses QUIC (HTTP/3), along with QPACK for header compression in
that protocol.

Working Group Summary:

As can be expected, discussion on many aspects of QUIC was quite
intense. The resulting consensus, however, was judged by the chairs to
be both strong and broad.

Document Quality:

There are over twenty implementations of QUIC that are participating in
interop testing, including all major web browsers and many server, CDN
and standalone library implementations.

The acknowledgements sections of the I-Ds highlight the individuals that
made major contributions to a given document.

Personnel:

The document shepherds for the individual I-Ds are:

-   Lucas Pardue:
-   draft-ietf-quic-http
-   draft-ietf-quic-qpack
-   Lars Eggert:
-   draft-ietf-quic-transport
-   draft-ietf-quic-recovery
-   Mark Nottingham:
-   draft-ietf-quic-tls
-   draft-ietf-quic-invariants

The responsible AD for the document set is Magnus Westerlund.


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


Protocol Action: 'QUIC: A UDP-Based Multiplexed and Secure Transport' to Proposed Standard (draft-ietf-quic-transport-34.txt)

2021-02-03 Thread The IESG
The IESG has approved the following document:
- 'QUIC: A UDP-Based Multiplexed and Secure Transport'
  (draft-ietf-quic-transport-34.txt) as Proposed Standard

This document is the product of the QUIC Working Group.

The IESG contact persons are Martin Duke and Magnus Westerlund.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-quic-transport/




Technical Summary:

QUIC is a standards-track, UDP-based, stream-multiplexing, encrypted
transport protocol. Its main features are minimizing connection
establishment and overall transport latency for applications such as
HTTP/3, providing multiplexing without head-of-line blocking, requiring
only changes to path endpoints to enable deployment, providing
always-secure transport using TLS 1.3.

This document set specifies the QUIC transport protocol and it
version-independent invariants, its loss detection and recovery
approach, its use of TLS1.3 for providing security, and a new version of
HTTP that uses QUIC (HTTP/3), along with QPACK for header compression in
that protocol.

Working Group Summary:

As can be expected, discussion on many aspects of QUIC was quite
intense. The resulting consensus, however, was judged by the chairs to
be both strong and broad.

Document Quality:

There are over twenty implementations of QUIC that are participating in
interop testing, including all major web browsers and many server, CDN
and standalone library implementations.

The acknowledgements sections of the I-Ds highlight the individuals that
made major contributions to a given document.

Personnel:

The document shepherds for the individual I-Ds are:

-   Lucas Pardue:
-   draft-ietf-quic-http
-   draft-ietf-quic-qpack
-   Lars Eggert:
-   draft-ietf-quic-transport
-   draft-ietf-quic-recovery
-   Mark Nottingham:
-   draft-ietf-quic-tls
-   draft-ietf-quic-invariants

The responsible AD for the document set is Magnus Westerlund.


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce