Gorry Fairhurst | 19 May 12:53 2016
Picon
Picon

TSVWG working group :: detailed status update on work items

The list below shows the status of the working group documents as we see 
it. Please check below and comment on drafts using the list. Please do 
send any corrections/omissions to the chairs.

Gorry & David
(TSVWG Chairs)
May 2016

-------------------------------------------------------------------
Documents recently published:

RFC 7496 (was draft-ietf-tsvwg-sctp-prpolicies) Additional Policies for 
the Partially Reliable Stream Control Transmission Protocol Extension - 
Document Shepherd: Gorry

RFC 7605 (was draft-ietf-tsvwg-port-use) Recommendations on Using 
Assigned Transport Port Numbers -Document Shepherd: Gorry

RFC 7857 (was draft-ietf-tsvwg-behave-requirements-update) Updates to 
Network Address Translation (NAT) Behavioral Requirements - Document 
Shepherd: David

RFC 7829 (was draft-ietf-tsvwg-sctp-failover)  SCTP-PF: A Quick Failover 
Algorithm for the Stream Control Transmission Protocol - Document 
Shepherd: Gorry

-------------------------------------------------------------------
IDs in RFC Editor Queue (http://www.rfc-editor.org/queue.html):

draft-ietf-tsvwg-sctp-dtls-encaps - PS - Document Shepherd: Gorry
(Continue reading)

Ben Campbell | 19 May 00:55 2016

Ben Campbell's Yes on draft-ietf-tsvwg-rtcweb-qos-16: (with COMMENT)

Ben Campbell has entered the following ballot position for
draft-ietf-tsvwg-rtcweb-qos-16: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I had the same comment as Alissa.

internet-drafts | 18 May 22:13 2016
Picon

I-D Action: draft-ietf-tsvwg-natsupp-09.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group of the IETF.

        Title           : Stream Control Transmission Protocol (SCTP) Network Address Translation Support
        Authors         : Randall R. Stewart
                          Michael Tuexen
                          Irene Ruengeler
	Filename        : draft-ietf-tsvwg-natsupp-09.txt
	Pages           : 44
	Date            : 2016-05-18

Abstract:
   The Stream Control Transmission Protocol (SCTP) provides a reliable
   communications channel between two end-hosts in many ways similar to
   the Transmission Control Protocol (TCP).  With the widespread
   deployment of Network Address Translators (NAT), specialized code has
   been added to NAT for TCP that allows multiple hosts to reside behind
   a NAT and yet use only a single globally unique IPv4 address, even
   when two hosts (behind a NAT) choose the same port numbers for their
   connection.  This additional code is sometimes classified as Network
   Address and Port Translation (NAPT).

   This document describes the protocol extensions required for the SCTP
   endpoints and the mechanisms for NATs necessary to provide similar
   features of NAPT in the single-point and multi-point traversal
   scenario.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-natsupp/
(Continue reading)

Stephen Farrell | 18 May 18:06 2016
Picon
Picon

Stephen Farrell's No Objection on draft-ietf-tsvwg-rtcweb-qos-16: (with COMMENT)

Stephen Farrell has entered the following ballot position for
draft-ietf-tsvwg-rtcweb-qos-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I was a little surprised that there's no additional security
considerations due to the fact that JS can set the
application priority - isn't that different enough (from
earlier uses of DSCP) that a browser might want to be a
little suspicious if some JS wants to try send too much
stuff as high priority, given that that same JS code might
be running on many many browsers all at once for a while
after some WebRTC server has been hacked? Or do we conclude
that that won't make any real difference or make it easier
for such JS malware to cause some kind of DoS somewhere?

Suresh Krishnan | 18 May 06:29 2016
Picon

Suresh Krishnan's No Objection on draft-ietf-tsvwg-rtcweb-qos-16: (with COMMENT)

Suresh Krishnan has entered the following ballot position for
draft-ietf-tsvwg-rtcweb-qos-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 5:

The draft claims that "Currently, all WebRTC video is assumed to be
interactive" and makes a reference to [I-D.ietf-rtcweb-transports], but
the referred draft does not contain any explanation regarding this. Is
this some kind of well known fact in WebRTC circles? If so, is it
documented somewhere?

Section 8:

Is this really required to be in the document? The shepherd writeup does
explain the rationale for the downrefs.

(Continue reading)

The IESG | 18 May 04:25 2016
Picon

Protocol Action: 'Network Transport Circuit Breakers' to Best Current Practice (draft-ietf-tsvwg-circuit-breaker-15.txt)

The IESG has approved the following document:
- 'Network Transport Circuit Breakers'
  (draft-ietf-tsvwg-circuit-breaker-15.txt) as Best Current Practice

This document is the product of the Transport Area Working Group.

The IESG contact persons are Mirja Kühlewind and Spencer Dawkins.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-circuit-breaker/

Technical Summary

   This document explains what is meant by the term "network transport
   Circuit Breaker" (CB).  It describes the need for circuit breakers
   when using network tunnels, and other non-congestion controlled
   applications.  It also defines requirements for building a circuit
   breaker and the expected outcomes of using a circuit breaker within
   the Internet.

The WG has requested Best Current Practice status because this draft
provides protocol design (and in some cases, operational) guidelines
for the Internet.  This request is the rough consensus of the WG.

Working Group Summary

The Transport Area WG (TSVWG) is a collection of people with varied
interests that don't individually justify their own working groups.

This draft is strongly supported by the portion of the TSVWG that is
(Continue reading)

Alissa Cooper | 17 May 20:13 2016
Picon

Alissa Cooper's Yes on draft-ietf-tsvwg-rtcweb-qos-16: (with COMMENT)

Alissa Cooper has entered the following ballot position for
draft-ietf-tsvwg-rtcweb-qos-16: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I would suggest doing a pass through the document to check for uses of
the term "browser" and "non-browser" to see if they could or should align
with the terms defined in RFC 7742. It's not obvious to me why this
document is using a different definition of "browser" than is used in
that document.

Mirja Kuehlewind | 17 May 17:20 2016
Picon

Mirja Kühlewind's Yes on draft-ietf-tsvwg-rtcweb-qos-16: (with COMMENT)

Mirja Kühlewind has entered the following ballot position for
draft-ietf-tsvwg-rtcweb-qos-16: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

A very-well written document! Thanks for all the work!

One question: the doc says:
"This specification [...] does not change any advice or requirements in
other
   IETF RFCs.  The contents of this specification are intended to be a
   simple set of implementation recommendations based on the previous
   RFCs."
This sounds like an information doc for me. However, I'm okay with
standards track as this should be consistently applied by WebRTC
browsers. Just wondering if this was discussed (because it also reads
like this change in scope was applied in a later phase of the live-time
of this doc)?
(Continue reading)

Gorry Fairhurst | 16 May 16:05 2016
Picon
Picon

Comments on draft-ietf-tsvwg-diffserv-intercon-05

I have read:

https://tools.ietf.org/html/draft-ietf-tsvwg-diffserv-intercon-05

One major comment on the recommendations:

I know the inclusion of a new class for LBE was discussed, and has not 
been taken forward, the recommendation  seems broken in the current text:

         / RFC 4594

            Low-priority data may be forwarded by a Lower Effort PHB in

            one domain (like the PHB proposed by Informational

            [RFC3662]), but is remarked with DSCP CS0 at a Diffserv-

            Intercon network interconnection./

- My concern is that there may have significant implications if you 
follow this approach to the future deployability of the Lower Effort 
PHB, if there is a significant proportion of this low priority traffic, 
or that traffic that relies upon this DSCP to protect other traffic from 
collateral damage will then result in sharing the network capacity with 
the default class.

- It could for instance be OK to say that this document does not define 
specific techniques to support a Lower Effort PHB, therefore the method 
provided by this recommendation would result in this being mapped 
remarked with DSCP CS0 at a Diffserv-Intercon network interconnection. 
(Continue reading)

Jana Iyengar | 12 May 20:56 2016
Picon

Proposed QUIC BoF at IETF96

We are proposing a wg-forming QUIC BoF at IETF96 to kick off an IETF effort to standardize QUIC. The IETF mailing list for discussion of this proposal has been set up at quic <at> ietf.org (link below), where we also expect to post and start a discussion of the proposed charter soon.

Gorry Fairhurst | 12 May 10:44 2016
Picon
Picon

New Internet-Draft: draft-ietf-tsvwg-rfc5405bis-13.txt

I'm pleased to announce a new revision to the UDP Usage Guidelines ID,
which now includes the feedback that the editors received on the use of
protocol timers. I think this recent addition is helpful to implementers
of UDP applications, and also aligns the UDP recommendations with recent 
work in the TCPM WG on the management of RTT/RTO.

Thanks to all who provided feedback and who proof-read the various new
paragraphs,

Gorry, Lars and Greg.

 >
 > A New Internet-Draft is available from the on-line Internet-Drafts
 > directories.
 > This draft is a work item of the Transport Area Working Group of the 
IETF.
 >
 >         Title           : UDP Usage Guidelines
 >         Authors         : Lars Eggert
 >                           Godred Fairhurst
 >                           Greg Shepherd
 > 	Filename        : draft-ietf-tsvwg-rfc5405bis-13.txt
 > 	Pages           : 57
 > 	Date            : 2016-05-10
 >
 > Abstract:
 >    The User Datagram Protocol (UDP) provides a minimal message-passing
 >    transport that has no inherent congestion control mechanisms.  This
 >    document provides guidelines on the use of UDP for the designers of
 >    applications, tunnels and other protocols that use UDP.  Congestion
 >    control guidelines are a primary focus, but the document also
 >    provides guidance on other topics, including message sizes,
 >    reliability, checksums, middlebox traversal, the use of ECN, DSCPs,
 >    and ports.
 >
 >    Because congestion control is critical to the stable operation of the
 >    Internet, applications and other protocols that choose to use UDP as
 >    an Internet transport must employ mechanisms to prevent congestion
 >    collapse and to establish some degree of fairness with concurrent
 >    traffic.  They may also need to implement additional mechanisms,
 >    depending on how they use UDP.
 >
 >    Some guidance is also applicable to the design of other protocols
 >    (e.g., protocols layered directly on IP or via IP-based tunnels),
 >    especially when these protocols do not themselves provide congestion
 >    control.
 >
 >    This document obsoletes RFC5405 and adds guidelines for multicast UDP
 >    usage.
 >
 >
 > The IETF datatracker status page for this draft is:
 > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/
 >
 > There's also a htmlized version available at:
 > https://tools.ietf.org/html/draft-ietf-tsvwg-rfc5405bis-13
 >
 > A diff from the previous version is available at:
 > https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc5405bis-13
 >
 >
 > Please note that it may take a couple of minutes from the time of
 > submission
 > until the htmlized version and diff are available at tools.ietf.org.
 >
 > Internet-Drafts are also available by anonymous FTP at:
 > ftp://ftp.ietf.org/internet-drafts/
 >


Gmane