From nobody Tue Jan 3 11:58:35 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3851C12940F for ; Tue, 3 Jan 2017 11:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQ9hyznk-u7e for ; Tue, 3 Jan 2017 11:58:31 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C16E129455 for ; Tue, 3 Jan 2017 11:58:31 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v03Jw4lj023554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 3 Jan 2017 11:58:05 -0800 (PST) References: <148347324864.27961.10295686513674586573.idtracker@ietfa.amsl.com> To: tsvwg From: Joe Touch X-Forwarded-Message-Id: <148347324864.27961.10295686513674586573.idtracker@ietfa.amsl.com> Message-ID: Date: Tue, 3 Jan 2017 11:58:04 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <148347324864.27961.10295686513674586573.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------E036CA563067A0448BF09646" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: [tsvwg] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 19:58:34 -0000 This is a multi-part message in MIME format. --------------E036CA563067A0448BF09646 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit FYI - this version includes updates that clarify the previous content. Joe -------- Forwarded Message -------- Subject: New Version Notification for draft-touch-tsvwg-udp-options-04.txt Date: Tue, 03 Jan 2017 11:54:08 -0800 From: internet-drafts@ietf.org To: Joe Touch , Joseph Touch A new version of I-D, draft-touch-tsvwg-udp-options-04.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Name: draft-touch-tsvwg-udp-options Revision: 04 Title: Transport Options for UDP Document date: 2017-01-03 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-04.txt Status: https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/ Htmlized: https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-04 Diff: https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-04 Abstract: Transport protocols are extended through the use of transport header options. This document experimentally extends UDP to provide a location, syntax, and semantics for transport layer options. 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. The IETF Secretariat --------------E036CA563067A0448BF09646 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

FYI - this version includes updates that clarify the previous content.

Joe



-------- Forwarded Message --------
Subject: New Version Notification for draft-touch-tsvwg-udp-options-04.txt
Date: Tue, 03 Jan 2017 11:54:08 -0800
From: internet-drafts@ietf.org
To: Joe Touch <touch@isi.edu>, Joseph Touch <touch@isi.edu> 


A new version of I-D, draft-touch-tsvwg-udp-options-04.txt
has been successfully submitted by Joe Touch and posted to the
IETF repository.

Name:		draft-touch-tsvwg-udp-options
Revision:	04
Title:		Transport Options for UDP
Document date:	2017-01-03
Group:		Individual Submission
Pages:		16
URL:            https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-04.txt
Status:         https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/
Htmlized:       https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-04
Diff:           https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-04

Abstract:
   Transport protocols are extended through the use of transport header
   options. This document experimentally extends UDP to provide a
   location, syntax, and semantics for transport layer options.

                                                                                  


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.

The IETF Secretariat
--------------E036CA563067A0448BF09646-- From nobody Wed Jan 4 10:12:11 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B3C127ABE for ; Wed, 4 Jan 2017 10:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=udel-edu.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgdakFWg3j7d for ; Wed, 4 Jan 2017 10:12:05 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64C0E1296D6 for ; Wed, 4 Jan 2017 10:12:05 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id c47so497931407qtc.2 for ; Wed, 04 Jan 2017 10:12:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udel-edu.20150623.gappssmtp.com; s=20150623; h=from:subject:to:message-id:date:user-agent:mime-version; bh=S7+j04108LGX85al5ofyw89MRgue9qXANjDNypffPKE=; b=i27e6Vah5qzb9zKqWYaGhDS7ctjVWixJVgApZ3nPsJKVPHORYS3uR2ZSvZ25xYZG1M UUMS79my6zSHf3uzcF7yXAlPC7F4wlCD8hl74EPuXCQKOTaz4ZYjX9++gb0YhFimHDM+ 4gs0Hro6Av3FfOl1BM0OXRBJh7fwY9wchY1do8IRcjfeQUi9xbu5ZsnZcpX8lWVykcT0 JzmqtrfrJ5RXaYGPnzCBiRbIodNpTqD5LEQF2AgTvng5xhA3k5wXnTSxjjT3/s+Z8uw3 1z/CF48agEmDWD8Oiqpyk2CruuG7kVHBzsD5A4NZITAh8cbyTuuUDO90ANwVcgACZpsC dV6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version; bh=S7+j04108LGX85al5ofyw89MRgue9qXANjDNypffPKE=; b=WS2CZjO29y6zk47aWQCwyhcd9V+Sfi7CHV/obOrX23kEL8/p5+XDnldZ8z7+e76qEh 0XoHZEg34e1iIh1poXsSGlO/HuWif1OIVqw2E9qPJcIUhEQxihSsxi/GrvlXeji5EXwO 8Y0TvYvNs3lLgOa3V+TySUFLaBCDMblNI/v0uBhVa3l3zKplJgsqFp3gSsmJTyplSL5K Gahj7gStyv/5AQwYsjy4CF7DTupknlzux6Yz6+rSfQCpD3Q/uTMdVSVFlRU7tSj0cS2i bftwMNuZreHOXfS1nZhXxTivjEmVmrCHXsldHQWLDuQc7HBIARK53CzuL1IGM+VZ1uSo Glcg== X-Gm-Message-State: AIkVDXJ+CZOTjFMO4MH7e4XVk3O9f5f8ytdg6uyEYoiwwDFfu6opfRK/Mhj/EwnymCiloufB X-Received: by 10.237.41.161 with SMTP id o30mr59281424qtd.209.1483553524267; Wed, 04 Jan 2017 10:12:04 -0800 (PST) Received: from iMac-27.local ([2601:183:4102:810d:ce6:9155:f29b:9fd0]) by smtp.gmail.com with ESMTPSA id 14sm46352194qtp.19.2017.01.04.10.12.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jan 2017 10:12:03 -0800 (PST) From: "Jonathan T. Leighton" To: tsvwg@ietf.org Message-ID: <98348439-7bb7-a37b-7933-db39ae334ba5@udel.edu> Date: Wed, 4 Jan 2017 13:12:02 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------E67D6B968950140FB45E4019" Archived-At: Subject: [tsvwg] Proposed errata for RFC 6458 sctp_bindx X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 18:12:09 -0000 This is a multi-part message in MIME format. --------------E67D6B968950140FB45E4019 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I've been discussing a possible errata for the sctp_bindx() description in RFC 6458 with Michael Tuexen, and he suggested posting the issue here for further comment. The current language is vague regarding passing IPv4 addresses versus IPv4-mapped IPv6 addresses, as well as required versus allowed behavior. I've been advised that there is some disagreement about whether or not the term "IPv4 address" includes IPv4-mapped IPv6 address, so the proposed text attempts to avoid that issue. OLD TEXT: If sd is an IPv4 socket, the addresses passed must be IPv4 addresses. If the sd is an IPv6 socket, the addresses passed can either be IPv4 or IPv6 addresses. NEW TEXT: If sd is an IPv4 socket, the passed addresses must be stored in sockaddr_in structures. If sd is an IPv6 socket, the passed addresses typically must be stored in sockaddr_in6 structures, however some implementations may also allow addresses to be stored in sockaddr_in structures. For implementations that require addresses to be stored in sockaddr_in6 structures, use IPv4-mapped IPv6 addresses to bind the socket to the corresponding IPv4 addresses. Best regards Jon --------------E67D6B968950140FB45E4019 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit I've been discussing a possible errata for the sctp_bindx() description in RFC 6458 with Michael Tuexen, and he suggested posting the issue here for further comment. The current language is vague regarding passing IPv4 addresses versus IPv4-mapped IPv6 addresses, as well as required versus allowed behavior. I've been advised that there is some disagreement about whether or not the term "IPv4 address" includes IPv4-mapped IPv6 address, so the proposed text attempts to avoid that issue.

OLD TEXT:
If sd is an IPv4 socket, the addresses passed must be IPv4 addresses.
If the sd is an IPv6 socket, the addresses passed can either be IPv4
or IPv6 addresses.
NEW TEXT:
If sd is an IPv4 socket, the passed addresses must be stored in
sockaddr_in structures. If sd is an IPv6 socket, the passed addresses
typically must be stored in sockaddr_in6 structures, however some
implementations may also allow addresses to be stored in sockaddr_in
structures. For implementations that require addresses to be stored
in sockaddr_in6 structures, use IPv4-mapped IPv6 addresses to bind
the socket to the corresponding IPv4 addresses.

Best regards
Jon
--------------E67D6B968950140FB45E4019-- From nobody Wed Jan 4 13:21:58 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8931296D4 for ; Wed, 4 Jan 2017 13:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=Nu5RulTX; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=CcQrXQz2 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSdniBFA8Hgd for ; Wed, 4 Jan 2017 13:21:56 -0800 (PST) Received: from esa2.dell-outbound.iphmx.com (esa2.dell-outbound.iphmx.com [68.232.149.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E302B129463 for ; Wed, 4 Jan 2017 13:21:55 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-originating-ip:Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=FcOPC/qYFpAYOeA6fLbIG2k6/+LlrvpCCPq497FkHmfIQxh5SYX2vhQx vgRNThz8yQG7uQPNUzMjrYYwB4dJznffCZiZSlUXqWq0tDJaFER0v7Mfz wLXApNirfv0sY/rXa5JUze5h0cfqxDQEpO5UZ23O4VLuwRyxR3BBBJaTJ k=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1483564915; x=1515100915; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Rhc1zebQNyFeNf7t2PdcUa6zGVW3h7NK/2HecnaW4OM=; b=Nu5RulTXxGcG85IRCs1r35CjnAK1zKIvIHOQDaCBUJH7OdfGgevHm7s/ t3oeQNs4CfETpJof3euBLWv/K6QKcvYB7dWBKH9Jt5OjPwXR1BJoffVcS mzoTeSoeZBDVusHRNZndwGC0bghHfXlV07dvgIVMexqD5/qosgkdmZ0JY g=; Received: from esa4.dell-outbound2.iphmx.com ([68.232.154.98]) by esa2.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jan 2017 15:21:55 -0600 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa4.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jan 2017 03:21:54 +0600 Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v04LLrLL015806 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 4 Jan 2017 16:21:54 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com v04LLrLL015806 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1483564914; bh=J/pQ4JfDOv8+BNZzhE9fvMz0Wec=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=CcQrXQz25DBdUXksr42CxJwaoBX6K+TR2ykDCiqaVyMJ1RJcf96LU5mH91aOxT7iT qtN2IpZH590JfCWXGbwIcbwV1NCWF/7qSDIYYsY5XBJhV8Jq0r+EQxYZtXQlpeC6hf tM0YGRatt8sQ0ty/o9duz6EEU4pEJ+Ya9ukxuoOA= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com v04LLrLL015806 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd52.lss.emc.com (RSA Interceptor) for ; Wed, 4 Jan 2017 16:20:58 -0500 Received: from MXHUB313.corp.emc.com (MXHUB313.corp.emc.com [10.146.3.91]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v04LLajU005716 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Wed, 4 Jan 2017 16:21:37 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB313.corp.emc.com ([10.146.3.91]) with mapi id 14.03.0266.001; Wed, 4 Jan 2017 16:21:36 -0500 To: "tsvwg@ietf.org" Thread-Topic: David Black's review of draft-ietf-tsvwg-ieee-802-11-01 Thread-Index: AdJm0ISGUmZYRnY+RZu3kgE4YNJohQ== Date: Wed, 4 Jan 2017 21:21:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.105.8.135] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [tsvwg] David Black's review of draft-ietf-tsvwg-ieee-802-11-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 21:21:58 -0000 While it's slightly after the end date of WG Last Call, I have done a revie= w of this draft, as an individual, although as WG chair, I'll comment that = the major issues MUST be addressed and the minor issues SHOULD be addressed= - a revision of the draft will definitely be needed. We'll also need to f= ind some more people to review the draft, as we like to see more than one W= GLC review, and I'm not able to review the discussion of how WiFi works. Review of: draft-ietf-tsvwg-ieee-802-11-01 Reviewer: David Black Date: January 4, 2017 ------------------------------------------------------- This draft is a significant piece of very useful work that the IETF should publish as an RFC. I have now done a detailed review and found a number of things, starting with major security and Diffserv architecture issues. Unfortunately, I'm not able to review Section 6's discussion of how 802.11 (WiFi) works for correctness, so someone who is an 802.11 expert will need to check that text. This review may seem long and daunting - I'd ask the authors to take this as a backhanded compliment as I only invest this much review time/effort in work that is seriously good and important - overall, the recommended mappings are solid, and the problems are in the surrounding material and some of the details. In 20/20 hindsight, I wish I'd found the time to do this level of review a year ago, and apologize for not doing so. --- Major Issues --- [1] Security!! This text in Section 3 ... o trust the DSCP markings set by wireless endpoint devices (as discussed in Section 5.3) ... strikes me as sufficient to send a knowledgeable security directorate reviewer into low earth orbit. =20 I would hope the recent IoT-botnet-based DDoS attacks make it painfully clear that the operating systems and applications in endpoint devices cannot be trusted, at least as the term "trust" is used here. The only cases where I'd find some form of trust argument plausible are where the network operator controls device software/firmware (e.g., dumb phones, un-rooted smartphones in some cases), and even then, latent vulnerabilities can enable introduction of untrusted code. IMNSHO, Section 5.3 needs a complete rethink and rewrite. [In My Not-So-Humble Opinion] The Security Considerations in section 8 also need attention, as this topic is not mentioned there. Authors - please let me know whether I should try to find a security expert to help. [2] Diffserv domain/region boundaries. The same bullet in section 3 that exhibits the security problem: o trust the DSCP markings set by wireless endpoint devices (as discussed in Section 5.3) is also incorrect if the wireless-to-wired network interconnect is a Diffserv domain boundary, especially if that Diffserv domain boundary is also a Diffserv region boundary. It may suffice to call out this exception, but see RFC 2475 for further discussion. There's actually good material on this topic elsewhere in the draft that could form the basis for a higher-level discussion on Diffserv boundaries. In the downstream direction, there's some useful material in Section 4.1.1, but that's too specific a section (network control) for this discussion. There also appears to be some useful material on upstream traffic in Section 5.2. I think a new section on this topic is called for as it applies to traffic in both directions. [3] Section 4 - Relationship to RFC 4594 In Section 4, significant discussion, and often actual text are reproduced from RFC 4594, without making it clear that RFC 4594 is the source. For example, Section 4.1 (without subsections) is entirely from RFC 4594 (there is nothing in there that isn't covered by RFC 4594). All of section 4 needs to be edited to indicate what concepts are repeated from RFC 4594 vs. what is new to this draft.=20 --- Minor Issues --- [A] Optimality s/b Consistency Starting with this text in the Abstract: and, as such, to optimize wired-and-wireless interconnect QoS. the draft is written in terms of optimizing and (even worse) optimal QoS. The latter is not realistic - a fine companion to the tooth fairy, Santa Claus and the Easter Bunny. I suggest changing from optimal QoS as the goal to consistent QoS, e.g.: and thereby enable consistent wired-and-wireless QoS among interconnected networks. This needs to be done throughout the draft. All related terms need to be changed, e.g., "sub-optimal" -> "inconsistent" or "less consistent" [B] 1.2. Interaction with RFC 7561 The GSMA specification was developed without reference to the service plan documented in Section 1.1, and conflicts both in the services specified and the code points specified for them. The above sentence is unclear. Section 1.1 does not describe a service plan (e.g., that term doesn't occur there), and the nature of the conflict is unclear. I suggest focusing this sentence to say that RFC 7561 and RFC 4594 conflict and add text to section 1.1 about the role of RFC 4594. The term "service plan" is also vague in this context, and probably should not be used - see RFC 4594 for ideas on what to say instead. [C] This draft needs a terminology section, as the initial expansions of acronyms are sprinkled across a number of places including the Abstract. The terminology section needs to include AP, UP, DSCP, WiFi, QoS, and all the acronyms in the 6.x section headings. Also, please ensure that WiFi is never hyphenated across a line break as Wi-Fi. While this concern is nominally editorial, it is a significant hurdle for document accessibility to non-experts, and hence I've tagged it as a minor issue. [D] Section 2. Comparison and Default Interoperation ... "Comparison" -> "Service Comparison" to fit the scope of the section. The following comparisons between IEEE 802.11 and DiffServ should be noted: "comparisons" -> "service comparisons" OR insert "services" after "Diffserv"=20 Also note that lower case 's' is the correct capitalization of Diffserv (i.e., not camel-case DiffServ). [E] 2.2. Default UP-to-DSCP Mappings and Conflicts o Mapping UP 4 (Multimedia Conferencing and/or Real-Time Interactive) to CS4, thus losing the ability to distinguish between these two distinct traffic classes Need to explain somewhere how to differentiate between these two distinct traffic classes for this bullet item and following ones. Also, are these traffic classes defined by RFC 4594 or 802.11? That's not clear for bullets after the first one in the list where the quoted text is the second bullet item. [F] 4.1.1. Network Control Protocols (DSCP usage) Following this recommendation, it is RECOMMENDED that all packets marked to DiffServ Codepoints not in use over the wireless network be dropped or remarked at the edge of the DiffServ domain. This general recommendation should not be buried in a section on network control protocols. At the very least it should be elevated to section 4 and included in the summary in section 3. Also, this recommendation originates from RFC 2475 and should be described accordingly, although the recommendation may not be stated as concisely in RFC 2475 by comparison to RFC 4594. [G] 4.1.1. Network Control Protocols (drop CS6 at domain boundaries) For example, in most commonly deployed models, the wireless access point represents not only the edge of the DiffServ domain, but also the edge of the network infrastructure itself. As such, and in line with the above recommendation, traffic marked CS7 DSCP SHOULD be dropped or remarked at this edge (as it is typically unused, as CS7 SHOULD be reserved for future use). So too SHOULD Network Control traffic marked CS6 DSCP, considering that only client devices (and no network infrastructure devices) are downstream from the wireless access points in these deployment models. This text bothers me, starting with the last sentence being incorrect if there are AP-to-AP WiFi hops. A specific concern is that I think this recommendation to drop CS6 prevents running routing protocols across the wireless-to-wired boundary in this case. While not typical, I believe that this can be done, although in the specific case of routing protocols, the boundary AP ought to be a participant in any IGP (internal) routing protocol. OTOH, I suppose one could run an EGP (external) routing protocol= , e.g., BGP here, and the AP is unlikely to be an inter-domain BGP speaker. Some more discussion seems to be in order, and the discussion should probably also note that encapsulated routing protocols for encapsulated or overlay networks (e.g., VPN, NVO3) are not network control traffic for any physical network at the AP, and hence SHOULD NOT be marked with CS6 in the first place. [H] 4.2.7. Low-Latency Data In line with the recommendations made in Section 4.2.2, mapping Low- Latency Data to UP 3 may allow such to receive a superior level of service via transmit queues servicing the EDCAF hardware for the Best Effort Access Category (AC_BE). This cross-reference to Section 4.2.2 is hard to follow. The discussion of EDCAF hardware behavior should be factored out to somewhere near the start of Section 4. While this concern is nominally editorial, it is a significant clarity problem for non-experts, and hence I've tagged it as a minor issue. [I] 4.3. DSCP-to-UP Mapping Recommendations Summary In Figure 1, the "(See Section 4.1.1)" text for Network Control traffic won't suffice for an implementer who is looking at the 4.3 summary because Section 4 in its entirety caused a tl;dr [too long; didn't read] reaction. Please add a short paragraph summarizing what to do (always drop CS7, drop CS6 at Diffserv boundaries, otherwise map CS6 to ...). [J] 5.1. Upstream DSCP-to-UP Mapping it is RECOMMENDED that such wireless client operating systems utilize instead the same DSCP- to-UP mapping recommendations presented in Section 4 and/or fully customizable UP markings. I don't understand "and/or fully customizable UP markings." As written, this allows arbitrary mappings to be consistent with the recommendation which is surely not what was intended. I suggest ending the sentence with a period after "Section 4" and handling customizable UP markings in a separate sentence. --- Editorial/Nits --- - Abstract OLD The purpose of this document is to propose NEW This document specifies - 1. Introduction OLD Wireless has become the medium of choice for endpoints connecting to business and private networks. NEW Wireless has become a frequently used medium for endpoints connecting to business and private networks. Original text overstates the point. OLD other challenges relate to the fact that the 802.11 standard is not administered by the standards body that administers the rest of the IP network. NEW other challenges relate to the fact that the 802.11 standard is not administered by the same standards body as IP networking standards. The IETF does not administer any IP networks. - 1.1. Related work (Editorial) o [RFC2475] defines a DiffServ architecture a -> the Overall, the inconsistent use of verbs in section 1.1. is a problem - I counted 7 (specifies, defines, details, etc.). This should be reduced to 2 or 3. In turn, the relevant standard for wireless QoS is IEEE 802.11, which is being progressively updated; the current version of which (at the time of writing) is IEEE 802.11-2012. Add a citation of [IEEE.802-11.2012] at the end of the sentence. - 1.3. Applicability Statement This document primarily applies to wired IP networks that have wireless access points at their edges, but can also be applied to Wi- Fi backhaul, wireless mesh solutions or any other type of AP-to-AP wireless network that serves to extend the IP network infrastructure. "serves to extend" -> "interconnects with" These are peer networks at the IP level. - Section 2. Comparison and Default Interoperation ... In this section, I prefer "assure" to "guarantee" as the former term is somewhat looser. o 802.11 loosely supports a [RFC3662] Lower PDB service via the Background Access Category (AC_BK) Lower -> Lower Effort Make this change wherever "Lower PDB" occurs. - 2.1. Default DSCP-to-UP Mappings and Conflicts OLD wherein the 3 Most Significant Bits (MSB) of the DSCP are transcribed to generate the corresponding L2 markings. NEW wherein the 3 Most Significant Bits (MSB) of the DSCP are used as the corresponding L2 marking. -- 2.2. Default UP-to-DSCP Mappings and Conflicts OLD Thus, the next sections of this draft seek to address these limitations and concerns and reconcile the intents of [RFC4594] and IEEE 802.11. NEW The following sections address these limitations and concerns in order to reconcile the[RFC4594] and IEEE 802.11. Also, add an 802.11 citation to the end of the new sentence. - 3. Wireless Device Marking and Mapping Capability Recommendations and as such may be overridden by network administrators, as needed. may -> MAY - 4. DSCP-to-UP Mapping Recommendations The following section proposes downstream (wired-to-wireless) mappings between [RFC4594] Configuration Guidelines for DiffServ Service Classes and IEEE 802.11. As such, this section draws heavily from [RFC4594], including traffic class definitions and recommendations. "proposes" -> "specifies" Also, the role of RFC 4594 should be discussed much earlier - see issues [3] and [B] above. - 4.2.2 Signaling The Signaling service class is RECOMMENDED for delay-sensitive client-server (traditional telephony) and peer-to-peer application signaling Insert "e.g.," before "traditional telephony" within the parentheses. Thanks, --David -------------------------------------------------------- David L. Black, Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0 Cell: +1 (978) 394-7754 David.Black@dell.com <=3D=3D=3D NEW =3D=3D=3D -------------------------------------------------------- From nobody Thu Jan 5 07:01:29 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E3D1294E7 for ; Thu, 5 Jan 2017 07:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=Ok9gXbl3; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=rsa.com header.b=ZPsoCvMA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKOvxBl5Cv_C for ; Thu, 5 Jan 2017 07:01:21 -0800 (PST) Received: from esa6.dell-outbound.iphmx.com (esa6.dell-outbound.iphmx.com [68.232.149.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BA3A12956F for ; Thu, 5 Jan 2017 07:01:14 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:To:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=kO2XcyoFIsyz1JLyKTqmKYpn8/BdElrZRbSfVGlAXAh9lZKBOc8XW/9W vHeCLX3wc4bwLpALN4PGXFrNyM+j9DInuqt2hOankgnzF3tc8nlMS1NYe +2rf4nUskxThQrKm0BvUuegRtJEEWaFUtIQ4uP9poooQMjq9juTgnlyxC o=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1483628474; x=1515164474; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=sRkMfLQuXdI9hSsz4pBQ4mAtL2F9Qm0RPOqVFaNF/LU=; b=Ok9gXbl3VOAVe6DQb7B1JlS9M5hzIv7T6d7OURKbU5RUwcd/N39D53tD hBUKMHMd5M24+Uiu1BkR4L45ThJfmlh9sUmLWKg1US/y2ZWnjXhkeUTZM A5Mdx0Grb76nKblPDRrVOWrK3QJxSfWO7vLnTk9xXeFvuLLkpElg1jg+7 U=; Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa6.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jan 2017 09:01:14 -0600 From: "Black, David" To: "Black, David" , "tsvwg@ietf.org" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jan 2017 21:01:09 +0600 Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd05.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v05F18Tk011142 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 5 Jan 2017 10:01:09 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com v05F18Tk011142 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=rsa.com; s=jan2013; t=1483628469; bh=Lg/j2FZzwrW08WXAnDv2op5PwVw=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=ZPsoCvMAMUjCjs9X3QnezbNFgP6AiR9peNk+lUKHy8qa6C8Nnr48czPE9iH3XC+2I PQr7Y0kmfRe6bmXfeu8FjOoU6bnJ+zMr/1u+6lkm8ZmJgBpl7nBBjh8S5sLaNb198b io/qXuM8ZmWBSq2pSy3r4oP/zH8Eml1s36k5oZsc= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com v05F18Tk011142 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd02.lss.emc.com (RSA Interceptor) for ; Thu, 5 Jan 2017 10:00:36 -0500 Received: from MXHUB309.corp.emc.com (MXHUB309.corp.emc.com [10.146.3.35]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v05F0stZ027438 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL) for ; Thu, 5 Jan 2017 10:00:54 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB309.corp.emc.com ([10.146.3.35]) with mapi id 14.03.0266.001; Thu, 5 Jan 2017 10:00:53 -0500 Thread-Topic: David Black's review of draft-ietf-tsvwg-ieee-802-11-01 Thread-Index: AdJm0ISGUmZYRnY+RZu3kgE4YNJohQAk9JHA Date: Thu, 5 Jan 2017 15:00:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.105] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tsvwg] David Black's review of draft-ietf-tsvwg-ieee-802-11-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 15:01:28 -0000 > We'll also need to find some more people to > review the draft, as we like to see more than one WGLC review, and I'm no= t able > to review the discussion of how WiFi works. It's been pointed out that I overlooked Vincent Roca's December 20 review o= f this draft, so allow me to apologize, and publicly thank Vincent for that review= . Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Black, David > Sent: Wednesday, January 04, 2017 4:22 PM > To: tsvwg@ietf.org > Subject: [tsvwg] David Black's review of draft-ietf-tsvwg-ieee-802-11-01 >=20 > While it's slightly after the end date of WG Last Call, I have done a rev= iew of this > draft, as an individual, although as WG chair, I'll comment that the majo= r issues > MUST be addressed and the minor issues SHOULD be addressed - a revision o= f > the draft will definitely be needed. We'll also need to find some more p= eople to > review the draft, as we like to see more than one WGLC review, and I'm no= t able > to review the discussion of how WiFi works. >=20 > Review of: draft-ietf-tsvwg-ieee-802-11-01 > Reviewer: David Black > Date: January 4, 2017 > ------------------------------------------------------- >=20 > This draft is a significant piece of very useful work that the > IETF should publish as an RFC. I have now done a detailed review > and found a number of things, starting with major security and > Diffserv architecture issues. Unfortunately, I'm not able to > review Section 6's discussion of how 802.11 (WiFi) works for > correctness, so someone who is an 802.11 expert will need to > check that text. >=20 > This review may seem long and daunting - I'd ask the authors to > take this as a backhanded compliment as I only invest this much > review time/effort in work that is seriously good and important > - overall, the recommended mappings are solid, and the problems > are in the surrounding material and some of the details. In > 20/20 hindsight, I wish I'd found the time to do this level of > review a year ago, and apologize for not doing so. >=20 > --- Major Issues --- >=20 > [1] Security!! >=20 > This text in Section 3 ... >=20 > o trust the DSCP markings set by wireless endpoint devices (as > discussed in Section 5.3) >=20 > ... strikes me as sufficient to send a knowledgeable security > directorate reviewer into low earth orbit. >=20 > I would hope the recent IoT-botnet-based DDoS attacks make it > painfully clear that the operating systems and applications in > endpoint devices cannot be trusted, at least as the term "trust" is > used here. >=20 > The only cases where I'd find some form of trust argument plausible > are where the network operator controls device software/firmware > (e.g., dumb phones, un-rooted smartphones in some cases), and even > then, latent vulnerabilities can enable introduction of untrusted code. >=20 > IMNSHO, Section 5.3 needs a complete rethink and rewrite. > [In My Not-So-Humble Opinion] The Security Considerations in > section 8 also need attention, as this topic is not mentioned there. >=20 > Authors - please let me know whether I should try to find a > security expert to help. >=20 > [2] Diffserv domain/region boundaries. >=20 > The same bullet in section 3 that exhibits the security problem: >=20 > o trust the DSCP markings set by wireless endpoint devices (as > discussed in Section 5.3) >=20 > is also incorrect if the wireless-to-wired network interconnect > is a Diffserv domain boundary, especially if that Diffserv > domain boundary is also a Diffserv region boundary. It may suffice > to call out this exception, but see RFC 2475 for further discussion. >=20 > There's actually good material on this topic elsewhere in the draft > that could form the basis for a higher-level discussion on Diffserv > boundaries. In the downstream direction, there's some useful material > in Section 4.1.1, but that's too specific a section (network control) > for this discussion. There also appears to be some useful material > on upstream traffic in Section 5.2. >=20 > I think a new section on this topic is called for as it applies to > traffic in both directions. >=20 > [3] Section 4 - Relationship to RFC 4594 >=20 > In Section 4, significant discussion, and often actual text are > reproduced from RFC 4594, without making it clear that RFC 4594 > is the source. For example, Section 4.1 (without subsections) is > entirely from RFC 4594 (there is nothing in there that isn't > covered by RFC 4594). All of section 4 needs to be edited to > indicate what concepts are repeated from RFC 4594 vs. what is new > to this draft. >=20 > --- Minor Issues --- >=20 > [A] Optimality s/b Consistency >=20 > Starting with this text in the Abstract: >=20 > and, as such, to optimize > wired-and-wireless interconnect QoS. >=20 > the draft is written in terms of optimizing and (even worse) > optimal QoS. The latter is not realistic - a fine companion > to the tooth fairy, Santa Claus and the Easter Bunny. I > suggest changing from optimal QoS as the goal to consistent > QoS, e.g.: >=20 > and thereby enable consistent > wired-and-wireless QoS among interconnected networks. >=20 > This needs to be done throughout the draft. All related terms > need to be changed, e.g., "sub-optimal" -> "inconsistent" or > "less consistent" >=20 > [B] 1.2. Interaction with RFC 7561 >=20 > The GSMA specification was developed without reference to the service > plan documented in Section 1.1, and conflicts both in the services > specified and the code points specified for them. >=20 > The above sentence is unclear. Section 1.1 does not describe > a service plan (e.g., that term doesn't occur there), and the nature > of the conflict is unclear. I suggest focusing this sentence to say > that RFC 7561 and RFC 4594 conflict and add text to section 1.1 about > the role of RFC 4594. The term "service plan" is also vague in this > context, and probably should not be used - see RFC 4594 for ideas on > what to say instead. >=20 > [C] This draft needs a terminology section, as the initial expansions > of acronyms are sprinkled across a number of places including the > Abstract. The terminology section needs to include AP, UP, DSCP, WiFi, > QoS, and all the acronyms in the 6.x section headings. Also, please > ensure that WiFi is never hyphenated across a line break as Wi-Fi. > While this concern is nominally editorial, it is a significant hurdle > for document accessibility to non-experts, and hence I've tagged it as > a minor issue. >=20 > [D] Section 2. Comparison and Default Interoperation ... >=20 > "Comparison" -> "Service Comparison" to fit the scope of the section. >=20 > The following comparisons between IEEE 802.11 and DiffServ should be > noted: >=20 > "comparisons" -> "service comparisons" OR > insert "services" after "Diffserv" >=20 > Also note that lower case 's' is the correct capitalization of Diffserv > (i.e., not camel-case DiffServ). >=20 > [E] 2.2. Default UP-to-DSCP Mappings and Conflicts >=20 > o Mapping UP 4 (Multimedia Conferencing and/or Real-Time > Interactive) to CS4, thus losing the ability to distinguish > between these two distinct traffic classes >=20 > Need to explain somewhere how to differentiate between these > two distinct traffic classes for this bullet item and following ones. >=20 > Also, are these traffic classes defined by RFC 4594 or 802.11? > That's not clear for bullets after the first one in the list > where the quoted text is the second bullet item. >=20 > [F] 4.1.1. Network Control Protocols (DSCP usage) >=20 > Following this recommendation, it is RECOMMENDED that all packets > marked to DiffServ Codepoints not in use over the wireless network be > dropped or remarked at the edge of the DiffServ domain. >=20 > This general recommendation should not be buried in a section on > network control protocols. At the very least it should be elevated > to section 4 and included in the summary in section 3. Also, this > recommendation originates from RFC 2475 and should be described > accordingly, although the recommendation may not be stated as > concisely in RFC 2475 by comparison to RFC 4594. >=20 > [G] 4.1.1. Network Control Protocols (drop CS6 at domain boundaries) >=20 > For example, in most commonly deployed models, the wireless access > point represents not only the edge of the DiffServ domain, but also > the edge of the network infrastructure itself. As such, and in line > with the above recommendation, traffic marked CS7 DSCP SHOULD be > dropped or remarked at this edge (as it is typically unused, as CS7 > SHOULD be reserved for future use). So too SHOULD Network Control > traffic marked CS6 DSCP, considering that only client devices (and no > network infrastructure devices) are downstream from the wireless > access points in these deployment models. >=20 > This text bothers me, starting with the last sentence being incorrect > if there are AP-to-AP WiFi hops. A specific concern is that I think > this recommendation to drop CS6 prevents running routing protocols across > the wireless-to-wired boundary in this case. While not typical, I believ= e > that this can be done, although in the specific case of routing protocols= , > the boundary AP ought to be a participant in any IGP (internal) routing > protocol. OTOH, I suppose one could run an EGP (external) routing protoc= ol, > e.g., BGP here, and the AP is unlikely to be an inter-domain BGP speaker. >=20 > Some more discussion seems to be in order, and the discussion should > probably also note that encapsulated routing protocols for encapsulated > or overlay networks (e.g., VPN, NVO3) are not network control traffic > for any physical network at the AP, and hence SHOULD NOT be marked > with CS6 in the first place. >=20 > [H] 4.2.7. Low-Latency Data >=20 > In line with the recommendations made in Section 4.2.2, mapping Low- > Latency Data to UP 3 may allow such to receive a superior level of > service via transmit queues servicing the EDCAF hardware for the Best > Effort Access Category (AC_BE). >=20 > This cross-reference to Section 4.2.2 is hard to follow. The discussion > of EDCAF hardware behavior should be factored out to somewhere near the > start of Section 4. While this concern is nominally editorial, it is a > significant clarity problem for non-experts, and hence I've tagged it as > a minor issue. >=20 > [I] 4.3. DSCP-to-UP Mapping Recommendations Summary >=20 > In Figure 1, the "(See Section 4.1.1)" text for Network Control > traffic won't suffice for an implementer who is looking at the 4.3 > summary because Section 4 in its entirety caused a tl;dr [too long; > didn't read] reaction. Please add a short paragraph summarizing > what to do (always drop CS7, drop CS6 at Diffserv boundaries, > otherwise map CS6 to ...). >=20 > [J] 5.1. Upstream DSCP-to-UP Mapping >=20 > it is RECOMMENDED that > such wireless client operating systems utilize instead the same DSCP- > to-UP mapping recommendations presented in Section 4 and/or fully > customizable UP markings. >=20 > I don't understand "and/or fully customizable UP markings." As written, > this allows arbitrary mappings to be consistent with the recommendation > which is surely not what was intended. I suggest ending the sentence wit= h > a period after "Section 4" and handling customizable UP markings in a > separate sentence. >=20 > --- Editorial/Nits --- >=20 > - Abstract >=20 > OLD > The purpose of this document is to propose > NEW > This document specifies >=20 > - 1. Introduction >=20 > OLD > Wireless has become the medium of choice for endpoints connecting to > business and private networks. > NEW > Wireless has become a frequently used medium for endpoints connecting = to > business and private networks. >=20 > Original text overstates the point. >=20 > OLD > other challenges relate to the fact that the > 802.11 standard is not administered by the standards body that > administers the rest of the IP network. > NEW > other challenges relate to the fact that the > 802.11 standard is not administered by the same standards body > as IP networking standards. >=20 > The IETF does not administer any IP networks. >=20 > - 1.1. Related work (Editorial) >=20 > o [RFC2475] defines a DiffServ architecture >=20 > a -> the >=20 > Overall, the inconsistent use of verbs in section 1.1. is a problem - I > counted 7 (specifies, defines, details, etc.). This should be reduced > to 2 or 3. >=20 > In turn, the relevant standard for wireless QoS is IEEE 802.11, which > is being progressively updated; the current version of which (at the > time of writing) is IEEE 802.11-2012. >=20 > Add a citation of [IEEE.802-11.2012] at the end of the sentence. >=20 > - 1.3. Applicability Statement >=20 > This document primarily applies to wired IP networks that have > wireless access points at their edges, but can also be applied to Wi- > Fi backhaul, wireless mesh solutions or any other type of AP-to-AP > wireless network that serves to extend the IP network infrastructure. >=20 > "serves to extend" -> "interconnects with" >=20 > These are peer networks at the IP level. >=20 > - Section 2. Comparison and Default Interoperation ... >=20 > In this section, I prefer "assure" to "guarantee" as the former term is > somewhat looser. >=20 > o 802.11 loosely supports a [RFC3662] Lower PDB service via the > Background Access Category (AC_BK) >=20 > Lower -> Lower Effort > Make this change wherever "Lower PDB" occurs. >=20 > - 2.1. Default DSCP-to-UP Mappings and Conflicts >=20 > OLD > wherein the 3 Most Significant Bits (MSB) of > the DSCP are transcribed to generate the corresponding L2 markings. > NEW > wherein the 3 Most Significant Bits (MSB) of > the DSCP are used as the corresponding L2 marking. >=20 > -- 2.2. Default UP-to-DSCP Mappings and Conflicts >=20 > OLD > Thus, the next sections of this draft seek to address these > limitations and concerns and reconcile the intents of [RFC4594] and > IEEE 802.11. > NEW > The following sections address these limitations and concerns in > order to reconcile the[RFC4594] and IEEE 802.11. >=20 > Also, add an 802.11 citation to the end of the new sentence. >=20 > - 3. Wireless Device Marking and Mapping Capability Recommendations >=20 > and as such may be overridden by network administrators, as needed. >=20 > may -> MAY >=20 > - 4. DSCP-to-UP Mapping Recommendations >=20 > The following section proposes downstream (wired-to-wireless) > mappings between [RFC4594] Configuration Guidelines for DiffServ > Service Classes and IEEE 802.11. As such, this section draws heavily > from [RFC4594], including traffic class definitions and > recommendations. >=20 > "proposes" -> "specifies" >=20 > Also, the role of RFC 4594 should be discussed much earlier - see > issues [3] and [B] above. >=20 > - 4.2.2 Signaling >=20 > The Signaling service class is RECOMMENDED for delay-sensitive > client-server (traditional telephony) and peer-to-peer application > signaling >=20 > Insert "e.g.," before "traditional telephony" within the parentheses. >=20 > Thanks, --David > -------------------------------------------------------- > David L. Black, Distinguished Engineer > Dell EMC, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0 Cell: +1 (978) 394-7754 > David.Black@dell.com <=3D=3D=3D NEW =3D=3D=3D > -------------------------------------------------------- >=20 From nobody Wed Jan 11 18:47:50 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE561293E9 for ; Wed, 11 Jan 2017 18:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rp6sAbWggSCn for ; Wed, 11 Jan 2017 18:47:46 -0800 (PST) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E782C126BF7 for ; Wed, 11 Jan 2017 18:47:45 -0800 (PST) Received: by mail-pf0-x22a.google.com with SMTP id y143so4426329pfb.0 for ; Wed, 11 Jan 2017 18:47:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=kaWYtaa2hygc5M+kj0RETgWO5tmKEK1CPlI7tyMiBkk=; b=LmNNgEkpRX7f2PjM8qQYM+eFaTE0dcixfpWDxSZrKpPl/hrcx5olY4J6kcmQNlI9SD DRzh1V9+XHRAh7GrXtPkDIaSj5pJPo2MJ46eVOa1LjgDIwo9VK/1N3BpyMvo/hvm/+rP oTXL8PhtsbNN8ikRowmb/kpDieUiw6/ExP03ZkFceFXoqu1SJa6YFiRpUOP/X2ERLOf5 Gnj+hQwGJRGR6uumsAXYGnox6YFrN+tq8a1vT2Wl5oQRg+R/3PY0389NxB4mjeScU+os Mr1+/N1HRbse+N4uJUn1oCFa4+DDyh31kWMUtnbWSh1+YSh+WLvPtPEU0xvFJu9ZYQSD 1Czw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=kaWYtaa2hygc5M+kj0RETgWO5tmKEK1CPlI7tyMiBkk=; b=Zm1UoZph3AW5hNv7YDziOFlZZOtsP6XqbYynw9W8HyUjbHbM0xv4t3Ncwa0gOVWKPo 7jwHp+6uN/S97lHkWgphhhajxgwx+GN3dU/gNggFZ3+vlwkdsWrb6tKarnMizbatu2of 1FDhGEd+bElAM2aFwebMrsThDETXLHui6ELmbXNsYgo+6qxT0vxErhlwaOBemQCMzig7 BeLBt8BC409HFzcUnESpuuJaK3YhkK+dZjRPyzP5WpiFcdCtMdCFGO7xk3DlDZGM2AwI NOi1TmTO/tJR4oIWf1g+5to8COSMkxZLT66NoqWFaEgUuMNr78VEOaCSLMHC0wM42+rq BYuw== X-Gm-Message-State: AIkVDXIK+Hn5FF/fNI4xBFk+MC2XyoQ3b4U3ug7qF0d/Y9QNyb2OoU8glouwDkXtMpMxgg== X-Received: by 10.98.81.199 with SMTP id f190mr13810093pfb.180.1484189265079; Wed, 11 Jan 2017 18:47:45 -0800 (PST) Received: from ?IPv6:2406:e007:611f:1:28cc:dc4c:9703:6781? ([2406:e007:611f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id a25sm16837963pgd.26.2017.01.11.18.47.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jan 2017 18:47:44 -0800 (PST) To: "Black, David" , "tsvwg@ietf.org" References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <6bb1e258-461c-d931-e056-066e3d363167@gmail.com> Date: Thu, 12 Jan 2017 15:47:47 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] David Black's review of draft-ietf-tsvwg-ieee-802-11-01 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 02:47:49 -0000 Good review, David. I have inserted a few comments in line below, tagged [BC]: On 05/01/2017 10:21, Black, David wrote: > While it's slightly after the end date of WG Last Call, I have done a review of this draft, as an individual, although as WG chair, I'll comment that the major issues MUST be addressed and the minor issues SHOULD be addressed - a revision of the draft will definitely be needed. We'll also need to find some more people to review the draft, as we like to see more than one WGLC review, and I'm not able to review the discussion of how WiFi works. > > Review of: draft-ietf-tsvwg-ieee-802-11-01 > Reviewer: David Black > Date: January 4, 2017 > ------------------------------------------------------- > > This draft is a significant piece of very useful work that the > IETF should publish as an RFC. I have now done a detailed review > and found a number of things, starting with major security and > Diffserv architecture issues. Unfortunately, I'm not able to > review Section 6's discussion of how 802.11 (WiFi) works for > correctness, so someone who is an 802.11 expert will need to > check that text. > > This review may seem long and daunting - I'd ask the authors to > take this as a backhanded compliment as I only invest this much > review time/effort in work that is seriously good and important > - overall, the recommended mappings are solid, and the problems > are in the surrounding material and some of the details. In > 20/20 hindsight, I wish I'd found the time to do this level of > review a year ago, and apologize for not doing so. > > --- Major Issues --- > > [1] Security!! > > This text in Section 3 ... > > o trust the DSCP markings set by wireless endpoint devices (as > discussed in Section 5.3) > > ... strikes me as sufficient to send a knowledgeable security > directorate reviewer into low earth orbit. > > I would hope the recent IoT-botnet-based DDoS attacks make it > painfully clear that the operating systems and applications in > endpoint devices cannot be trusted, at least as the term "trust" is > used here. > > The only cases where I'd find some form of trust argument plausible > are where the network operator controls device software/firmware > (e.g., dumb phones, un-rooted smartphones in some cases), and even > then, latent vulnerabilities can enable introduction of untrusted code. [BC] Exactly. As stated in RFC 2474, in fact: The defense against this class of theft- and denial-of-service attacks consists of the combination of traffic conditioning at DS domain boundaries with security and integrity of the network infrastructure within a DS domain. If the network includes devices that have been maliciously programmed to set EF on every packet, and if a router implements EF correctly, the result would be that every packet beyond the capacity allocated to EF "SHOULD be dropped" according to RFC 3246. So the service would be significantly worse than best effort. The same therefore applies to any 802.11 marking that is mapped to EF. There could be similar but less serious effects from spurious CSx or AFxy markings. You can't trust markings from random devices. Unless devices have been identified, authenticated and authorized they aren't trustworthy. Several WGs are expending considerable effort on this problem; I'm no expert, but draft-ietf-anima-bootstrapping-keyinfra is one example. BTW, I noticed that section 5.3 refers to sections 3.1 and 3.2, which don't exist. > IMNSHO, Section 5.3 needs a complete rethink and rewrite. > [In My Not-So-Humble Opinion] The Security Considerations in > section 8 also need attention, as this topic is not mentioned there. > > Authors - please let me know whether I should try to find a > security expert to help. > > [2] Diffserv domain/region boundaries. > > The same bullet in section 3 that exhibits the security problem: > > o trust the DSCP markings set by wireless endpoint devices (as > discussed in Section 5.3) > > is also incorrect if the wireless-to-wired network interconnect > is a Diffserv domain boundary, especially if that Diffserv > domain boundary is also a Diffserv region boundary. It may suffice > to call out this exception, but see RFC 2475 for further discussion. [BC] Correct. Since the QoS characteristics of wired and wireless networks are quite different, it might in fact be exactly the right place for a diffserv domain boundary, complete with traffic classification, re-marking and policing. > > There's actually good material on this topic elsewhere in the draft > that could form the basis for a higher-level discussion on Diffserv > boundaries. In the downstream direction, there's some useful material > in Section 4.1.1, but that's too specific a section (network control) > for this discussion. There also appears to be some useful material > on upstream traffic in Section 5.2. > > I think a new section on this topic is called for as it applies to > traffic in both directions. > > [3] Section 4 - Relationship to RFC 4594 > > In Section 4, significant discussion, and often actual text are > reproduced from RFC 4594, without making it clear that RFC 4594 > is the source. For example, Section 4.1 (without subsections) is > entirely from RFC 4594 (there is nothing in there that isn't > covered by RFC 4594). All of section 4 needs to be edited to > indicate what concepts are repeated from RFC 4594 vs. what is new > to this draft. [BC] Agreed. > > --- Minor Issues --- > > [A] Optimality s/b Consistency > > Starting with this text in the Abstract: > > and, as such, to optimize > wired-and-wireless interconnect QoS. > > the draft is written in terms of optimizing and (even worse) > optimal QoS. The latter is not realistic - a fine companion > to the tooth fairy, Santa Claus and the Easter Bunny. I [BC] It's also perhaps Quixotic. As I just noted, wired and wireless QoS are intrinsically different so anything like 1:1 mapping is probably doomed in advance. > suggest changing from optimal QoS as the goal to consistent > QoS, e.g.: > > and thereby enable consistent > wired-and-wireless QoS among interconnected networks. > > This needs to be done throughout the draft. All related terms > need to be changed, e.g., "sub-optimal" -> "inconsistent" or > "less consistent" > > [B] 1.2. Interaction with RFC 7561 > > The GSMA specification was developed without reference to the service > plan documented in Section 1.1, and conflicts both in the services > specified and the code points specified for them. > > The above sentence is unclear. Section 1.1 does not describe > a service plan (e.g., that term doesn't occur there), and the nature > of the conflict is unclear. I suggest focusing this sentence to say > that RFC 7561 and RFC 4594 conflict and add text to section 1.1 about > the role of RFC 4594. The term "service plan" is also vague in this > context, and probably should not be used - see RFC 4594 for ideas on > what to say instead. > > [C] This draft needs a terminology section, as the initial expansions > of acronyms are sprinkled across a number of places including the > Abstract. The terminology section needs to include AP, UP, DSCP, WiFi, > QoS, and all the acronyms in the 6.x section headings. Also, please > ensure that WiFi is never hyphenated across a line break as Wi-Fi. > While this concern is nominally editorial, it is a significant hurdle > for document accessibility to non-experts, and hence I've tagged it as > a minor issue. > > [D] Section 2. Comparison and Default Interoperation ... > > "Comparison" -> "Service Comparison" to fit the scope of the section. > > The following comparisons between IEEE 802.11 and DiffServ should be > noted: > > "comparisons" -> "service comparisons" OR > insert "services" after "Diffserv" > > Also note that lower case 's' is the correct capitalization of Diffserv > (i.e., not camel-case DiffServ). > > [E] 2.2. Default UP-to-DSCP Mappings and Conflicts > > o Mapping UP 4 (Multimedia Conferencing and/or Real-Time > Interactive) to CS4, thus losing the ability to distinguish > between these two distinct traffic classes > > Need to explain somewhere how to differentiate between these > two distinct traffic classes for this bullet item and following ones. > > Also, are these traffic classes defined by RFC 4594 or 802.11? > That's not clear for bullets after the first one in the list > where the quoted text is the second bullet item. > > [F] 4.1.1. Network Control Protocols (DSCP usage) > > Following this recommendation, it is RECOMMENDED that all packets > marked to DiffServ Codepoints not in use over the wireless network be > dropped or remarked at the edge of the DiffServ domain. > > This general recommendation should not be buried in a section on > network control protocols. At the very least it should be elevated > to section 4 and included in the summary in section 3. Also, this > recommendation originates from RFC 2475 and should be described > accordingly, although the recommendation may not be stated as > concisely in RFC 2475 by comparison to RFC 4594. > > [G] 4.1.1. Network Control Protocols (drop CS6 at domain boundaries) > > For example, in most commonly deployed models, the wireless access > point represents not only the edge of the DiffServ domain, but also > the edge of the network infrastructure itself. As such, and in line > with the above recommendation, traffic marked CS7 DSCP SHOULD be > dropped or remarked at this edge (as it is typically unused, as CS7 > SHOULD be reserved for future use). So too SHOULD Network Control > traffic marked CS6 DSCP, considering that only client devices (and no > network infrastructure devices) are downstream from the wireless > access points in these deployment models. > > This text bothers me, starting with the last sentence being incorrect > if there are AP-to-AP WiFi hops. A specific concern is that I think > this recommendation to drop CS6 prevents running routing protocols across > the wireless-to-wired boundary in this case. While not typical, I believe > that this can be done, although in the specific case of routing protocols, > the boundary AP ought to be a participant in any IGP (internal) routing > protocol. OTOH, I suppose one could run an EGP (external) routing protocol, > e.g., BGP here, and the AP is unlikely to be an inter-domain BGP speaker. [BC] It's dangerous. If somebody has legitimately marked traffic as CS6 or CS7, we would be arrogant to assume that we know better and the packet can be dropped. Saying that it should be re-marked, even to CS0, would be reasonable. RPL (RFC 6550) is absolutely intended to cross wireless/wired boundaries. I don't know whether RPL deployments apply CS6 but it seems entirely reasonable that they might. It's apparently been discussed in 6tisch, which is IEEE 802.15.4. > > Some more discussion seems to be in order, and the discussion should > probably also note that encapsulated routing protocols for encapsulated > or overlay networks (e.g., VPN, NVO3) are not network control traffic > for any physical network at the AP, and hence SHOULD NOT be marked > with CS6 in the first place. > > [H] 4.2.7. Low-Latency Data > > In line with the recommendations made in Section 4.2.2, mapping Low- > Latency Data to UP 3 may allow such to receive a superior level of > service via transmit queues servicing the EDCAF hardware for the Best > Effort Access Category (AC_BE). > > This cross-reference to Section 4.2.2 is hard to follow. The discussion > of EDCAF hardware behavior should be factored out to somewhere near the > start of Section 4. While this concern is nominally editorial, it is a > significant clarity problem for non-experts, and hence I've tagged it as > a minor issue. > > [I] 4.3. DSCP-to-UP Mapping Recommendations Summary > > In Figure 1, the "(See Section 4.1.1)" text for Network Control > traffic won't suffice for an implementer who is looking at the 4.3 > summary because Section 4 in its entirety caused a tl;dr [too long; > didn't read] reaction. Please add a short paragraph summarizing > what to do (always drop CS7, drop CS6 at Diffserv boundaries, > otherwise map CS6 to ...). > > [J] 5.1. Upstream DSCP-to-UP Mapping > > it is RECOMMENDED that > such wireless client operating systems utilize instead the same DSCP- > to-UP mapping recommendations presented in Section 4 and/or fully > customizable UP markings. > > I don't understand "and/or fully customizable UP markings." As written, > this allows arbitrary mappings to be consistent with the recommendation > which is surely not what was intended. I suggest ending the sentence with > a period after "Section 4" and handling customizable UP markings in a > separate sentence. > > --- Editorial/Nits --- > > - Abstract > > OLD > The purpose of this document is to propose > NEW > This document specifies > > - 1. Introduction > > OLD > Wireless has become the medium of choice for endpoints connecting to > business and private networks. > NEW > Wireless has become a frequently used medium for endpoints connecting to > business and private networks. > > Original text overstates the point. > > OLD > other challenges relate to the fact that the > 802.11 standard is not administered by the standards body that > administers the rest of the IP network. > NEW > other challenges relate to the fact that the > 802.11 standard is not administered by the same standards body > as IP networking standards. > > The IETF does not administer any IP networks. > > - 1.1. Related work (Editorial) > > o [RFC2475] defines a DiffServ architecture > > a -> the > > Overall, the inconsistent use of verbs in section 1.1. is a problem - I > counted 7 (specifies, defines, details, etc.). This should be reduced > to 2 or 3. > > In turn, the relevant standard for wireless QoS is IEEE 802.11, which > is being progressively updated; the current version of which (at the > time of writing) is IEEE 802.11-2012. > > Add a citation of [IEEE.802-11.2012] at the end of the sentence. > > - 1.3. Applicability Statement > > This document primarily applies to wired IP networks that have > wireless access points at their edges, but can also be applied to Wi- > Fi backhaul, wireless mesh solutions or any other type of AP-to-AP > wireless network that serves to extend the IP network infrastructure. > > "serves to extend" -> "interconnects with" > > These are peer networks at the IP level. > > - Section 2. Comparison and Default Interoperation ... > > In this section, I prefer "assure" to "guarantee" as the former term is > somewhat looser. > > o 802.11 loosely supports a [RFC3662] Lower PDB service via the > Background Access Category (AC_BK) > > Lower -> Lower Effort > Make this change wherever "Lower PDB" occurs. [BC] Maybe this draft should cite draft-tsvwg-le-phb instead of RFC3662? Regards Brian > > - 2.1. Default DSCP-to-UP Mappings and Conflicts > > OLD > wherein the 3 Most Significant Bits (MSB) of > the DSCP are transcribed to generate the corresponding L2 markings. > NEW > wherein the 3 Most Significant Bits (MSB) of > the DSCP are used as the corresponding L2 marking. > > -- 2.2. Default UP-to-DSCP Mappings and Conflicts > > OLD > Thus, the next sections of this draft seek to address these > limitations and concerns and reconcile the intents of [RFC4594] and > IEEE 802.11. > NEW > The following sections address these limitations and concerns in > order to reconcile the[RFC4594] and IEEE 802.11. > > Also, add an 802.11 citation to the end of the new sentence. > > - 3. Wireless Device Marking and Mapping Capability Recommendations > > and as such may be overridden by network administrators, as needed. > > may -> MAY > > - 4. DSCP-to-UP Mapping Recommendations > > The following section proposes downstream (wired-to-wireless) > mappings between [RFC4594] Configuration Guidelines for DiffServ > Service Classes and IEEE 802.11. As such, this section draws heavily > from [RFC4594], including traffic class definitions and > recommendations. > > "proposes" -> "specifies" > > Also, the role of RFC 4594 should be discussed much earlier - see > issues [3] and [B] above. > > - 4.2.2 Signaling > > The Signaling service class is RECOMMENDED for delay-sensitive > client-server (traditional telephony) and peer-to-peer application > signaling > > Insert "e.g.," before "traditional telephony" within the parentheses. > > Thanks, --David > -------------------------------------------------------- > David L. Black, Distinguished Engineer > Dell EMC, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 Cell: +1 (978) 394-7754 > David.Black@dell.com <=== NEW === > -------------------------------------------------------- > > > From nobody Thu Jan 12 09:36:48 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65FC1294BD for ; Thu, 12 Jan 2017 09:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=udel-edu.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZYMygZiRNdE for ; Thu, 12 Jan 2017 09:36:45 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B093129507 for ; Thu, 12 Jan 2017 09:36:42 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id 11so27999924qkl.3 for ; Thu, 12 Jan 2017 09:36:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udel-edu.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=B9y656PjzrwvdOpSximo3Du5egX1nl3Kc+jRFRTSTlQ=; b=lSZLIGLqvNhENRfD8p6Ezs/9QGZDmv+k0wBMfzHVmx91N610RiEbZ0pWcyJ57/EOCM ll8ew1kdXoCUtnp73NniRtWjA6oDjsXPrE+2oNlXcW6mC34AaMwhriWX48Hqx++JIKW4 1kw0XZ0Edf3v5zQu6oGitjNssQiK+YAhQ07NloVfoZW1Y8aWKliL7nOSfCYPoEXNHgXl ql6R/wVf2nwnUU+MWtSb1ANz4yYO13tp+EXVDHuQdAcbzbS1vz6Iic0oxzzsNw/QJ88Q 7QKVTsPS5u8gYohbO/9w2UP74mH7nZ3RsiZPrZFEqz48I15gWCxwcVrnHyGHlZ0HXpyn yPIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=B9y656PjzrwvdOpSximo3Du5egX1nl3Kc+jRFRTSTlQ=; b=DVbRgzMXVOFcpei3gXeAs+rIHPiJcIgXmZ1Fg/OEIsXuxwA2j5OsIUOpOlA44uYNW9 o0Q39NW4JA93wuce7hSPMMHHD8UMpD8LdJY2jEt3blMst7TZl6QnO1AminOgU7QnxMtj vbTJ+20ZSm38/25knHMxv+RT28mPHTvYoo129iSOM9yi4ULxbmbxmErfVB1rlClXdLyG zHggYW+chjqQu7tSXx8G5Mngx13byoNXLrz7FbZrBG63pLwJKWvky19t7Z+z/C3b7YZj WS8m7cyBqIdKSvVofjb9U7SzlFdokVa8DCVW8TEwdBxFz/3fYtYyWVnw2JbjH9ujfgzm EgTQ== X-Gm-Message-State: AIkVDXIVU/mRz0SAoOU+P15kbhPW5M+cGuzLX1elPbfmsr44REJytFNpRr5/EmBsqWEfixKb X-Received: by 10.55.163.11 with SMTP id m11mr14199680qke.16.1484242601079; Thu, 12 Jan 2017 09:36:41 -0800 (PST) Received: from iMac-27.local ([2601:183:4102:810d:dcd1:6841:b603:eb43]) by smtp.gmail.com with ESMTPSA id r60sm7113383qtd.24.2017.01.12.09.36.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 09:36:40 -0800 (PST) To: tsvwg@ietf.org References: <98348439-7bb7-a37b-7933-db39ae334ba5@udel.edu> From: "Jonathan T. Leighton" Message-ID: <5fe2fc97-8188-c3cc-d009-d09bc9f47640@udel.edu> Date: Thu, 12 Jan 2017 12:36:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <98348439-7bb7-a37b-7933-db39ae334ba5@udel.edu> Content-Type: multipart/alternative; boundary="------------CD96FC076EB9080BE91B55B6" Archived-At: Subject: Re: [tsvwg] Proposed errata for RFC 6458 sctp_bindx X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 17:36:48 -0000 This is a multi-part message in MIME format. --------------CD96FC076EB9080BE91B55B6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Michael - I posted this to tsvwg@ietf.org on 1/4/17, but it's been over a week now and I haven't had any response. I can try posting it again, or I can submit an errata and see how the authors respond. Do you have a suggestion about how best to proceed? Best regards, Jon On 1/4/17 1:12 PM, Jonathan T. Leighton wrote: > I've been discussing a possible errata for the sctp_bindx() > description in RFC 6458 > with Michael Tuexen, and he suggested posting the issue here for > further comment. The current language is vague regarding passing IPv4 > addresses versus IPv4-mapped IPv6 addresses, as well as required > versus allowed behavior. I've been advised that there is some > disagreement about whether or not the term "IPv4 address" includes > IPv4-mapped IPv6 address, so the proposed text attempts to avoid that > issue. > > OLD TEXT: > > If sd is an IPv4 socket, the addresses passed must be IPv4 addresses. > If the sd is an IPv6 socket, the addresses passed can either be IPv4 > or IPv6 addresses. > > NEW TEXT: > > If sd is an IPv4 socket, the passed addresses must be stored in > sockaddr_in structures. If sd is an IPv6 socket, the passed addresses > typically must be stored in sockaddr_in6 structures, however some > implementations may also allow addresses to be stored in sockaddr_in > structures. For implementations that require addresses to be stored > in sockaddr_in6 structures, use IPv4-mapped IPv6 addresses to bind > the socket to the corresponding IPv4 addresses. > > > Best regards > Jon --------------CD96FC076EB9080BE91B55B6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi Michael -

I posted this to tsvwg@ietf.org on 1/4/17, but it's been over a week now and I haven't had any response. I can try posting it again, or I can submit an errata and see how the authors respond. Do you have a suggestion about how best to proceed?

Best regards,
Jon


On 1/4/17 1:12 PM, Jonathan T. Leighton wrote:
I've been discussing a possible errata for the sctp_bindx() description in RFC 6458 with Michael Tuexen, and he suggested posting the issue here for further comment. The current language is vague regarding passing IPv4 addresses versus IPv4-mapped IPv6 addresses, as well as required versus allowed behavior. I've been advised that there is some disagreement about whether or not the term "IPv4 address" includes IPv4-mapped IPv6 address, so the proposed text attempts to avoid that issue.

OLD TEXT:
If sd is an IPv4 socket, the addresses passed must be IPv4 addresses.
If the sd is an IPv6 socket, the addresses passed can either be IPv4
or IPv6 addresses.
NEW TEXT:
If sd is an IPv4 socket, the passed addresses must be stored in
sockaddr_in structures. If sd is an IPv6 socket, the passed addresses
typically must be stored in sockaddr_in6 structures, however some
implementations may also allow addresses to be stored in sockaddr_in
structures. For implementations that require addresses to be stored
in sockaddr_in6 structures, use IPv4-mapped IPv6 addresses to bind
the socket to the corresponding IPv4 addresses.

Best regards
Jon

--------------CD96FC076EB9080BE91B55B6-- From nobody Thu Jan 12 12:00:09 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E2A12959B for ; Thu, 12 Jan 2017 12:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvxSKiG25K0G for ; Thu, 12 Jan 2017 12:00:06 -0800 (PST) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC5CD129561 for ; Thu, 12 Jan 2017 12:00:05 -0800 (PST) Received: from [IPv6:2003:cd:6bc9:5900:a944:d131:612c:7ac0] (p200300CD6BC95900A944D131612C7AC0.dip0.t-ipconnect.de [IPv6:2003:cd:6bc9:5900:a944:d131:612c:7ac0]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id BFFC2721E281E; Thu, 12 Jan 2017 21:00:02 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Michael Tuexen In-Reply-To: <5fe2fc97-8188-c3cc-d009-d09bc9f47640@udel.edu> Date: Thu, 12 Jan 2017 21:00:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <31CDAF39-DC53-4DF9-B6AD-73304181A515@lurchi.franken.de> References: <98348439-7bb7-a37b-7933-db39ae334ba5@udel.edu> <5fe2fc97-8188-c3cc-d009-d09bc9f47640@udel.edu> To: "Jonathan T. Leighton" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Kacheong Poon , Vlad Yasevich , tsvwg WG Subject: Re: [tsvwg] Proposed errata for RFC 6458 sctp_bindx X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 20:00:08 -0000 > On 12 Jan 2017, at 18:36, Jonathan T. Leighton = wrote: >=20 > Hi Michael - >=20 > I posted this to tsvwg@ietf.org on 1/4/17, but it's been over a week = now and I haven't had any response. I can try posting it again, or I can = submit an errata and see how the authors respond. Do you have a = suggestion about how best to proceed? I CC'ed some individuals... Given them a couple of days. Then file an errata if you want. I'm find with the text suggested by you. Best regards Michael >=20 > Best regards, > Jon >=20 >=20 > On 1/4/17 1:12 PM, Jonathan T. Leighton wrote: >> I've been discussing a possible errata for the sctp_bindx() = description in RFC 6458 with Michael Tuexen, and he suggested posting = the issue here for further comment. The current language is vague = regarding passing IPv4 addresses versus IPv4-mapped IPv6 addresses, as = well as required versus allowed behavior. I've been advised that there = is some disagreement about whether or not the term "IPv4 address" = includes IPv4-mapped IPv6 address, so the proposed text attempts to = avoid that issue. >>=20 >> OLD TEXT: >> If sd is an IPv4 socket, the addresses passed must be IPv4 addresses. >> If the sd is an IPv6 socket, the addresses passed can either be IPv4 >> or IPv6 addresses. >> NEW TEXT: >> If sd is an IPv4 socket, the passed addresses must be stored in >> sockaddr_in structures. If sd is an IPv6 socket, the passed addresses >> typically must be stored in sockaddr_in6 structures, however some >> implementations may also allow addresses to be stored in sockaddr_in >> structures. For implementations that require addresses to be stored >> in sockaddr_in6 structures, use IPv4-mapped IPv6 addresses to bind >> the socket to the corresponding IPv4 addresses. >>=20 >>=20 >> Best regards >> Jon >=20 From nobody Fri Jan 13 10:05:52 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36514129D07 for ; Fri, 13 Jan 2017 10:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWraKNNpllev for ; Fri, 13 Jan 2017 10:05:47 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id B423B129D0E for ; Fri, 13 Jan 2017 10:05:36 -0800 (PST) Received: from [192.168.0.8] (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id BFA6C1B000D4; Fri, 13 Jan 2017 20:03:35 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: "Gorry (erg)" X-Mailer: iPhone Mail (14C92) In-Reply-To: <31CDAF39-DC53-4DF9-B6AD-73304181A515@lurchi.franken.de> Date: Fri, 13 Jan 2017 18:05:34 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <17B55714-87FC-4881-AF46-CE0808AC4179@erg.abdn.ac.uk> References: <98348439-7bb7-a37b-7933-db39ae334ba5@udel.edu> <5fe2fc97-8188-c3cc-d009-d09bc9f47640@udel.edu> <31CDAF39-DC53-4DF9-B6AD-73304181A515@lurchi.franken.de> To: Michael Tuexen Archived-At: Cc: Kacheong Poon , Vlad Yasevich , tsvwg WG Subject: Re: [tsvwg] Proposed errata for RFC 6458 sctp_bindx X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 18:05:51 -0000 Is this somehow different to how you handle this in TCP? Maybe I missed some= thing? The RFC is informational, so I am not sure how important it is to make this c= hange ... but I would be interested in other opinions... do speak up on the l= ist if you think this is important. Gorry On 12 Jan 2017, at 20:00, Michael Tuexen w= rote: >> On 12 Jan 2017, at 18:36, Jonathan T. Leighton wrote:= >>=20 >> Hi Michael - >>=20 >> I posted this to tsvwg@ietf.org on 1/4/17, but it's been over a week now a= nd I haven't had any response. I can try posting it again, or I can submit a= n errata and see how the authors respond. Do you have a suggestion about how= best to proceed? > I CC'ed some individuals... Given them a couple of days. > Then file an errata if you want. >=20 > I'm find with the text suggested by you. >=20 > Best regards > Michael >>=20 >> Best regards, >> Jon >>=20 >>=20 >>> On 1/4/17 1:12 PM, Jonathan T. Leighton wrote: >>> I've been discussing a possible errata for the sctp_bindx() description i= n RFC 6458 with Michael Tuexen, and he suggested posting the issue here for = further comment. The current language is vague regarding passing IPv4 a= ddresses versus IPv4-mapped IPv6 addresses, as well as required versus allow= ed behavior. I've been advised that there is some disagreement about whether= or not the term "IPv4 address" includes IPv4-mapped IPv6 address, so the pr= oposed text attempts to avoid that issue. >>>=20 >>> OLD TEXT: >>> If sd is an IPv4 socket, the addresses passed must be IPv4 addresses. >>> If the sd is an IPv6 socket, the addresses passed can either be IPv4 >>> or IPv6 addresses. >>> NEW TEXT: >>> If sd is an IPv4 socket, the passed addresses must be stored in >>> sockaddr_in structures. If sd is an IPv6 socket, the passed addresses >>> typically must be stored in sockaddr_in6 structures, however some >>> implementations may also allow addresses to be stored in sockaddr_in >>> structures. For implementations that require addresses to be stored >>> in sockaddr_in6 structures, use IPv4-mapped IPv6 addresses to bind >>> the socket to the corresponding IPv4 addresses. >>>=20 >>>=20 >>> Best regards >>> Jon >>=20 From nobody Fri Jan 13 10:49:20 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4C8129D53 for ; Fri, 13 Jan 2017 10:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-ET3pstaPo4 for ; Fri, 13 Jan 2017 10:49:15 -0800 (PST) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7081E1294BF for ; Fri, 13 Jan 2017 10:49:15 -0800 (PST) Received: from [IPv6:2003:cd:6bc9:5900:1034:e94d:1612:3460] (p200300CD6BC959001034E94D16123460.dip0.t-ipconnect.de [IPv6:2003:cd:6bc9:5900:1034:e94d:1612:3460]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 58F33721E2822; Fri, 13 Jan 2017 19:49:12 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Michael Tuexen In-Reply-To: <17B55714-87FC-4881-AF46-CE0808AC4179@erg.abdn.ac.uk> Date: Fri, 13 Jan 2017 19:49:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <98348439-7bb7-a37b-7933-db39ae334ba5@udel.edu> <5fe2fc97-8188-c3cc-d009-d09bc9f47640@udel.edu> <31CDAF39-DC53-4DF9-B6AD-73304181A515@lurchi.franken.de> <17B55714-87FC-4881-AF46-CE0808AC4179@erg.abdn.ac.uk> To: Gorry Fairhurst X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Kacheong Poon , Vlad Yasevich , tsvwg WG Subject: Re: [tsvwg] Proposed errata for RFC 6458 sctp_bindx X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 18:49:18 -0000 > On 13 Jan 2017, at 19:05, Gorry (erg) wrote: >=20 > Is this somehow different to how you handle this in TCP? Maybe I = missed something? TCP only allows to bind to a single address. MP-TCP allows to bind = multiple addresses, but I'm not sure about the API they are using. The point is that sctp_bindx(), at least on FreeBSD, supports a mixture = of sockaddr_in and sockaddr_in6 structures. Other platforms might only = support sockaddr_in6 structures. Best regards Michael >=20 > The RFC is informational, so I am not sure how important it is to make = this change ... but I would be interested in other opinions... do speak = up on the list if you think this is important. >=20 > Gorry >=20 > On 12 Jan 2017, at 20:00, Michael Tuexen = wrote: >=20 >>> On 12 Jan 2017, at 18:36, Jonathan T. Leighton = wrote: >>>=20 >>> Hi Michael - >>>=20 >>> I posted this to tsvwg@ietf.org on 1/4/17, but it's been over a week = now and I haven't had any response. I can try posting it again, or I can = submit an errata and see how the authors respond. Do you have a = suggestion about how best to proceed? >> I CC'ed some individuals... Given them a couple of days. >> Then file an errata if you want. >>=20 >> I'm find with the text suggested by you. >>=20 >> Best regards >> Michael >>>=20 >>> Best regards, >>> Jon >>>=20 >>>=20 >>>> On 1/4/17 1:12 PM, Jonathan T. Leighton wrote: >>>> I've been discussing a possible errata for the sctp_bindx() = description in RFC 6458 with Michael Tuexen, and he suggested posting = the issue here for further comment. The current language is vague = regarding passing IPv4 addresses versus IPv4-mapped IPv6 addresses, as = well as required versus allowed behavior. I've been advised that there = is some disagreement about whether or not the term "IPv4 address" = includes IPv4-mapped IPv6 address, so the proposed text attempts to = avoid that issue. >>>>=20 >>>> OLD TEXT: >>>> If sd is an IPv4 socket, the addresses passed must be IPv4 = addresses. >>>> If the sd is an IPv6 socket, the addresses passed can either be = IPv4 >>>> or IPv6 addresses. >>>> NEW TEXT: >>>> If sd is an IPv4 socket, the passed addresses must be stored in >>>> sockaddr_in structures. If sd is an IPv6 socket, the passed = addresses >>>> typically must be stored in sockaddr_in6 structures, however some >>>> implementations may also allow addresses to be stored in = sockaddr_in >>>> structures. For implementations that require addresses to be stored >>>> in sockaddr_in6 structures, use IPv4-mapped IPv6 addresses to bind >>>> the socket to the corresponding IPv4 addresses. >>>>=20 >>>>=20 >>>> Best regards >>>> Jon >>>=20 >=20 From nobody Fri Jan 13 12:52:55 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD86E129E41 for ; Fri, 13 Jan 2017 12:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=udel-edu.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mw8_miHqMyr9 for ; Fri, 13 Jan 2017 12:52:52 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B394D129E40 for ; Fri, 13 Jan 2017 12:52:52 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id a20so66973280qkc.1 for ; Fri, 13 Jan 2017 12:52:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udel-edu.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=xWXOBUtPtvXe9rSyvFlKwGEeCmLfW1Adxm0/OaPJPKI=; b=wklvS7daA1T0loYKPuClC0RN59xNBdIyWJE9ZK1tBmrmANTRE1Jso/ASQb3D1F43qL HmDiF27YGrr5cO2wFcx68a0m9z1HtNYVGBo120drVLp7GjWbRjNfIr5W2zxa2vqTTLuM xdqeA6WUzG5EgRbIty2utTs8U52CMU1wGjEG/fMQQsZyJ/nWMg9w1/T8JcvUmCvzSA4d Jx29zIgwacwgyTzYYr9k3PZteYTZS7pd0jIKmSYKNs+LzFFcmUIJWvuhO5oQmIsIuKTV JJ5l2O1vFdzn2jsoKw71Ls3XBjdulxYm9EtLkNnNLvZ2Bk2Iwm1hT5M7qeG7HlofbJGK AFrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=xWXOBUtPtvXe9rSyvFlKwGEeCmLfW1Adxm0/OaPJPKI=; b=YsLArKsPLH0uNIDuwGYBmU7zMexdEmW7A1/7BETekEIf/vJ7BZrnLfcFnanS3CIpRF 2b8teDdyOnyVqEh4lBwriGgOPq6SDrgdDqIVmYyUzgim2TactgX2e2YOWdouMSVlOOFC 2HHKXehrbBspzyLVcPrq+EGgGhSz8yFVa3M9cSLWDkI1CVGAYQlvwsE/JAvm7dxUZrEQ xVc2Owm7RymTOMn9C4OmQegLz55bQaimih5686aGF5V+KTNUlVgBPn5o19FqeQAqZolH cdMHZiCdnXGhCmiRDWURHTf3M1Z3+G2urQSGXLUVd4n9gcaf2BTDF8H6aous1pzvCipG HMug== X-Gm-Message-State: AIkVDXKsGQC9JSfjOqo2yvJQs0g/Qnu4VsEvhk5VXTPvWD0asKZbu966uRECenKZuGdrpWgm X-Received: by 10.55.111.199 with SMTP id k190mr10841022qkc.25.1484340771692; Fri, 13 Jan 2017 12:52:51 -0800 (PST) Received: from iMac-27.local ([2601:183:4102:810d:e9a0:81f7:d027:3bcf]) by smtp.gmail.com with ESMTPSA id h43sm10044704qth.29.2017.01.13.12.52.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jan 2017 12:52:50 -0800 (PST) To: "Gorry (erg)" , Michael Tuexen References: <98348439-7bb7-a37b-7933-db39ae334ba5@udel.edu> <5fe2fc97-8188-c3cc-d009-d09bc9f47640@udel.edu> <31CDAF39-DC53-4DF9-B6AD-73304181A515@lurchi.franken.de> <17B55714-87FC-4881-AF46-CE0808AC4179@erg.abdn.ac.uk> From: "Jonathan T. Leighton" Message-ID: <2e096b5f-a271-b29f-f4a3-dc065d442010@udel.edu> Date: Fri, 13 Jan 2017 15:52:49 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <17B55714-87FC-4881-AF46-CE0808AC4179@erg.abdn.ac.uk> Content-Type: multipart/alternative; boundary="------------2F9735BCFD3036CA0025FC4F" Archived-At: Cc: Kacheong Poon , Vlad Yasevich , tsvwg WG Subject: Re: [tsvwg] Proposed errata for RFC 6458 sctp_bindx X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 20:52:54 -0000 This is a multi-part message in MIME format. --------------2F9735BCFD3036CA0025FC4F Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 1/13/17 1:05 PM, Gorry (erg) wrote: > Is this somehow different to how you handle this in TCP? Maybe I missed something? It is not different, though at least one SCTP implementation allows a variation that is not normally available, and to the best of my knowledge is not available in any TCP implementation. I think I should back up a bit and say that my original motivation for proposing an errata was this sentence in the description of sctp_bindx(): If the sd is an IPv6 socket, the addresses passed can either be IPv4 or IPv6 addresses. With the exception of one SCTP implementation, I know of no TCP or SCTP implementation that allows binding an IPv4 address to an IPv6 socket. Instead, IPv4-mapped IPv6 addresses are used. Given that I have encountered a good bit of confusion in some quarters about the different ways to translate IPv4 addresses to IPv6 (embedded, compatible, mapped, ...), it seems to me that the RFC should explicitly mention that IPv4-mapped IPv6 addresses are the appropriate translation to use: If the sd is an IPv6 socket, the addresses passed must be IPv6 addresses. Use IPv4-mapped IPv6 addresses to bind an IPv6 socket to an IPv4 address. It was pointed out to me that at least one SCTP implementation allows IPv4 addresses to be passed directly to sctp_bindx(), so the following change also seems appropriate: If the sd is an IPv6 socket, the addresses passed must be IPv6 addresses. Use IPv4-mapped IPv6 addresses to bind an IPv6 socket to an IPv4 address. Note that some implementations optionally allow IPv4 addresses to be passed in directly. I can explain why I originally suggested a wordier version that mentions the various structures involved if anyone is interested, but the above text is what I'd most like to see. Best regards, Jon > The RFC is informational, so I am not sure how important it is to make this change ... but I would be interested in other opinions... do speak up on the list if you think this is important. > > Gorry > > On 12 Jan 2017, at 20:00, Michael Tuexen wrote: > >>> On 12 Jan 2017, at 18:36, Jonathan T. Leighton wrote: >>> >>> Hi Michael - >>> >>> I posted this to tsvwg@ietf.org on 1/4/17, but it's been over a week now and I haven't had any response. I can try posting it again, or I can submit an errata and see how the authors respond. Do you have a suggestion about how best to proceed? >> I CC'ed some individuals... Given them a couple of days. >> Then file an errata if you want. >> >> I'm find with the text suggested by you. >> >> Best regards >> Michael >>> Best regards, >>> Jon >>> >>> >>>> On 1/4/17 1:12 PM, Jonathan T. Leighton wrote: >>>> I've been discussing a possible errata for the sctp_bindx() description in RFC 6458 with Michael Tuexen, and he suggested posting the issue here for further comment. The current language is vague regarding passing IPv4 addresses versus IPv4-mapped IPv6 addresses, as well as required versus allowed behavior. I've been advised that there is some disagreement about whether or not the term "IPv4 address" includes IPv4-mapped IPv6 address, so the proposed text attempts to avoid that issue. >>>> >>>> OLD TEXT: >>>> If sd is an IPv4 socket, the addresses passed must be IPv4 addresses. >>>> If the sd is an IPv6 socket, the addresses passed can either be IPv4 >>>> or IPv6 addresses. >>>> NEW TEXT: >>>> If sd is an IPv4 socket, the passed addresses must be stored in >>>> sockaddr_in structures. If sd is an IPv6 socket, the passed addresses >>>> typically must be stored in sockaddr_in6 structures, however some >>>> implementations may also allow addresses to be stored in sockaddr_in >>>> structures. For implementations that require addresses to be stored >>>> in sockaddr_in6 structures, use IPv4-mapped IPv6 addresses to bind >>>> the socket to the corresponding IPv4 addresses. >>>> >>>> >>>> Best regards >>>> Jon --------------2F9735BCFD3036CA0025FC4F Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit On 1/13/17 1:05 PM, Gorry (erg) wrote:
Is this somehow different to how you handle this in TCP? Maybe I missed something?

It is not different, though at least one SCTP implementation allows a variation that is not normally available, and to the best of my knowledge is not available in any TCP implementation.

I think I should back up a bit and say that my original motivation for proposing an errata was this sentence in the description of sctp_bindx():
If the sd is an IPv6 socket, the addresses passed can either be IPv4
or IPv6 addresses.
With the exception of one SCTP implementation, I know of no TCP or SCTP implementation that allows binding an IPv4 address to an IPv6 socket. Instead, IPv4-mapped IPv6 addresses are used. Given that I have encountered a good bit of confusion in some quarters about the different ways to translate IPv4 addresses to IPv6 (embedded, compatible, mapped, ...), it seems to me that the RFC should explicitly mention that IPv4-mapped IPv6 addresses are the appropriate translation to use:
If the sd is an IPv6 socket, the addresses passed must be IPv6 addresses.
Use IPv4-mapped IPv6 addresses to bind an IPv6 socket to an IPv4 address.
It was pointed out to me that at least one SCTP implementation allows IPv4 addresses to be passed directly to sctp_bindx(), so the following change also seems appropriate:
If the sd is an IPv6 socket, the addresses passed must be IPv6 addresses.
Use IPv4-mapped IPv6 addresses to bind an IPv6 socket to an IPv4 address.
Note that some implementations optionally allow IPv4 addresses to be
passed in directly.
I can explain why I originally suggested a wordier version that mentions the various structures involved if anyone is interested, but the above text is what I'd most like to see.

Best regards,
Jon

The RFC is informational, so I am not sure how important it is to make this change ... but I would be interested in other opinions... do speak up on the list if you think this is important.

Gorry

On 12 Jan 2017, at 20:00, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:


On 12 Jan 2017, at 18:36, Jonathan T. Leighton <jtleight@UDel.Edu> wrote:

Hi Michael -

I posted this to tsvwg@ietf.org on 1/4/17, but it's been over a week now and I haven't had any response. I can try posting it again, or I can submit an errata and see how the authors respond. Do you have a suggestion about how best to proceed?

I CC'ed some individuals... Given them a couple of days.
Then file an errata if you want.

I'm find with the text suggested by you.

Best regards
Michael

Best regards,
Jon



On 1/4/17 1:12 PM, Jonathan T. Leighton wrote:
I've been discussing a possible errata for the sctp_bindx() description in RFC 6458 with Michael Tuexen, and he suggested posting the issue here for       further comment. The current language is vague regarding passing IPv4 addresses versus IPv4-mapped IPv6 addresses, as well as required versus allowed behavior. I've been advised that there is some disagreement about whether or not the term "IPv4 address" includes IPv4-mapped IPv6 address, so the proposed text attempts to avoid that issue.

OLD TEXT:
If sd is an IPv4 socket, the addresses passed must be IPv4 addresses.
If the sd is an IPv6 socket, the addresses passed can either be IPv4
or IPv6 addresses.
NEW TEXT:
If sd is an IPv4 socket, the passed addresses must be stored in
sockaddr_in structures. If sd is an IPv6 socket, the passed addresses
typically must be stored in sockaddr_in6 structures, however some
implementations may also allow addresses to be stored in sockaddr_in
structures. For implementations that require addresses to be stored
in sockaddr_in6 structures, use IPv4-mapped IPv6 addresses to bind
the socket to the corresponding IPv4 addresses.


Best regards
Jon


        

      

      

    

    

  


--------------2F9735BCFD3036CA0025FC4F--


From nobody Sat Jan 14 02:09:03 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8ABB1299B3 for ; Sat, 14 Jan 2017 02:09:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.8
X-Spam-Level: 
X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtfP_IpAyG6h for ; Sat, 14 Jan 2017 02:09:00 -0800 (PST)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC0F01299C0 for ; Sat, 14 Jan 2017 02:08:59 -0800 (PST)
Received: from [IPv6:2003:cd:6bc9:5900:1034:e94d:1612:3460] (p200300CD6BC959001034E94D16123460.dip0.t-ipconnect.de [IPv6:2003:cd:6bc9:5900:1034:e94d:1612:3460]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id B1BCF721E2823; Sat, 14 Jan 2017 11:08:56 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Michael Tuexen 
In-Reply-To: <2e096b5f-a271-b29f-f4a3-dc065d442010@udel.edu>
Date: Sat, 14 Jan 2017 11:08:56 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <98348439-7bb7-a37b-7933-db39ae334ba5@udel.edu> <5fe2fc97-8188-c3cc-d009-d09bc9f47640@udel.edu> <31CDAF39-DC53-4DF9-B6AD-73304181A515@lurchi.franken.de> <17B55714-87FC-4881-AF46-CE0808AC4179@erg.abdn.ac.uk> <2e096b5f-a271-b29f-f4a3-dc065d442010@udel.edu>
To: "Jonathan T. Leighton" 
X-Mailer: Apple Mail (2.3259)
Archived-At: 
Cc: Gorry Fairhurst , Kacheong Poon , Vlad Yasevich , tsvwg WG 
Subject: Re: [tsvwg] Proposed errata for RFC 6458 sctp_bindx
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 14 Jan 2017 10:09:02 -0000

> On 13 Jan 2017, at 21:52, Jonathan T. Leighton  =
wrote:
>=20
> On 1/13/17 1:05 PM, Gorry (erg) wrote:
>> Is this somehow different to how you handle this in TCP? Maybe I =
missed something?
>=20
> It is not different, though at least one SCTP implementation allows a =
variation that is not normally available, and to the best of my =
knowledge is not available in any TCP implementation.
What system call used by TCP has *multiple* IP addresses as a parameter?

Best regards
Michael
>=20
> I think I should back up a bit and say that my original motivation for =
proposing an errata was this sentence in the description of =
sctp_bindx():
> If the sd is an IPv6 socket, the addresses passed can either be IPv4
> or IPv6 addresses.
>=20
> With the exception of one SCTP implementation, I know of no TCP or =
SCTP implementation that allows binding an IPv4 address to an IPv6 =
socket. Instead, IPv4-mapped IPv6 addresses are used. Given that I have =
encountered a good bit of confusion in some quarters about the different =
ways to translate IPv4 addresses to IPv6 (embedded, compatible, mapped, =
...), it seems to me that the RFC should explicitly mention that =
IPv4-mapped IPv6 addresses are the appropriate translation to use:
> If the sd is an IPv6 socket, the addresses passed must be IPv6 =
addresses.
> Use IPv4-mapped IPv6 addresses to bind an IPv6 socket to an IPv4 =
address.
>=20
> It was pointed out to me that at least one SCTP implementation allows =
IPv4 addresses to be passed directly to sctp_bindx(), so the following =
change also seems appropriate:
> If the sd is an IPv6 socket, the addresses passed must be IPv6 =
addresses.
> Use IPv4-mapped IPv6 addresses to bind an IPv6 socket to an IPv4 =
address.
> Note that some implementations optionally allow IPv4 addresses to be
> passed in directly.=20
>=20
> I can explain why I originally suggested a wordier version that =
mentions the various structures involved if anyone is interested, but =
the above text is what I'd most like to see.
>=20
> Best regards,
> Jon
>=20
>> The RFC is informational, so I am not sure how important it is to =
make this change ... but I would be interested in other opinions... do =
speak up on the list if you think this is important.
>>=20
>> Gorry
>>=20
>> On 12 Jan 2017, at 20:00, Michael Tuexen=20
>> 
>>  wrote:
>>=20
>>=20
>>>> On 12 Jan 2017, at 18:36, Jonathan T. Leighton 
>>>>  wrote:
>>>>=20
>>>> Hi Michael -
>>>>=20
>>>> I posted this to=20
>>>> tsvwg@ietf.org
>>>>  on 1/4/17, but it's been over a week now and I haven't had any =
response. I can try posting it again, or I can submit an errata and see =
how the authors respond. Do you have a suggestion about how best to =
proceed?
>>>>=20
>>> I CC'ed some individuals... Given them a couple of days.
>>> Then file an errata if you want.
>>>=20
>>> I'm find with the text suggested by you.
>>>=20
>>> Best regards
>>> Michael
>>>=20
>>>> Best regards,
>>>> Jon
>>>>=20
>>>>=20
>>>>=20
>>>>> On 1/4/17 1:12 PM, Jonathan T. Leighton wrote:
>>>>> I've been discussing a possible errata for the sctp_bindx() =
description in RFC 6458 with Michael Tuexen, and he suggested posting =
the issue here for       further comment. The current language is vague =
regarding passing IPv4 addresses versus IPv4-mapped IPv6 addresses, as =
well as required versus allowed behavior. I've been advised that there =
is some disagreement about whether or not the term "IPv4 address" =
includes IPv4-mapped IPv6 address, so the proposed text attempts to =
avoid that issue.
>>>>>=20
>>>>> OLD TEXT:
>>>>> If sd is an IPv4 socket, the addresses passed must be IPv4 =
addresses.
>>>>> If the sd is an IPv6 socket, the addresses passed can either be =
IPv4
>>>>> or IPv6 addresses.
>>>>> NEW TEXT:
>>>>> If sd is an IPv4 socket, the passed addresses must be stored in
>>>>> sockaddr_in structures. If sd is an IPv6 socket, the passed =
addresses
>>>>> typically must be stored in sockaddr_in6 structures, however some
>>>>> implementations may also allow addresses to be stored in =
sockaddr_in
>>>>> structures. For implementations that require addresses to be =
stored
>>>>> in sockaddr_in6 structures, use IPv4-mapped IPv6 addresses to bind
>>>>> the socket to the corresponding IPv4 addresses.
>>>>>=20
>>>>>=20
>>>>> Best regards
>>>>> Jon
>>>>>=20
>=20


From nobody Sat Jan 14 02:45:48 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080EB1299E1 for ; Sat, 14 Jan 2017 02:45:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Level: 
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xCHKJD-I6uZ for ; Sat, 14 Jan 2017 02:45:43 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id EAE151299DE for ; Sat, 14 Jan 2017 02:45:42 -0800 (PST)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 9774D1B000E0; Sat, 14 Jan 2017 12:43:12 +0000 (GMT)
Message-ID: <587A0137.8010901@erg.abdn.ac.uk>
Date: Sat, 14 Jan 2017 10:45:11 +0000
From: Gorry Fairhurst 
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Michael Tuexen 
References: <98348439-7bb7-a37b-7933-db39ae334ba5@udel.edu> <5fe2fc97-8188-c3cc-d009-d09bc9f47640@udel.edu> <31CDAF39-DC53-4DF9-B6AD-73304181A515@lurchi.franken.de> <17B55714-87FC-4881-AF46-CE0808AC4179@erg.abdn.ac.uk> <2e096b5f-a271-b29f-f4a3-dc065d442010@udel.edu> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: Kacheong Poon , Vlad Yasevich , tsvwg WG 
Subject: Re: [tsvwg] Proposed errata for RFC 6458 sctp_bindx
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 14 Jan 2017 10:45:46 -0000

Is this then about recognising that the address format is IPv6...?  and 
if so, is the correction along the lines of (with appropriate wording of 
course):

OLD:
If the sd is an IPv6 socket, the addresses passed can either be IPv4 or 
IPv6 addresses.

NEW:

If the sd is an IPv6 socket, the addresses passed can be either IPv6 addresses
or IPv4-Compatible IPv6 addresses (RFC 4291).

Gorry

On 14/01/2017 10:08, Michael Tuexen wrote:
>> On 13 Jan 2017, at 21:52, Jonathan T. Leighton  wrote:
>>
>> On 1/13/17 1:05 PM, Gorry (erg) wrote:
>>> Is this somehow different to how you handle this in TCP? Maybe I missed something?
>> It is not different, though at least one SCTP implementation allows a variation that is not normally available, and to the best of my knowledge is not available in any TCP implementation.
> What system call used by TCP has *multiple* IP addresses as a parameter?
>
> Best regards
> Michael
>> I think I should back up a bit and say that my original motivation for proposing an errata was this sentence in the description of sctp_bindx():
>> If the sd is an IPv6 socket, the addresses passed can either be IPv4
>> or IPv6 addresses.
>>
>> With the exception of one SCTP implementation, I know of no TCP or SCTP implementation that allows binding an IPv4 address to an IPv6 socket. Instead, IPv4-mapped IPv6 addresses are used. Given that I have encountered a good bit of confusion in some quarters about the different ways to translate IPv4 addresses to IPv6 (embedded, compatible, mapped, ...), it seems to me that the RFC should explicitly mention that IPv4-mapped IPv6 addresses are the appropriate translation to use:
>> If the sd is an IPv6 socket, the addresses passed must be IPv6 addresses.
>> Use IPv4-mapped IPv6 addresses to bind an IPv6 socket to an IPv4 address.
>>
>> It was pointed out to me that at least one SCTP implementation allows IPv4 addresses to be passed directly to sctp_bindx(), so the following change also seems appropriate:
>> If the sd is an IPv6 socket, the addresses passed must be IPv6 addresses.
>> Use IPv4-mapped IPv6 addresses to bind an IPv6 socket to an IPv4 address.
>> Note that some implementations optionally allow IPv4 addresses to be
>> passed in directly.
>>
>> I can explain why I originally suggested a wordier version that mentions the various structures involved if anyone is interested, but the above text is what I'd most like to see.
>>
>> Best regards,
>> Jon
>>
>>> The RFC is informational, so I am not sure how important it is to make this change ... but I would be interested in other opinions... do speak up on the list if you think this is important.
>>>
>>> Gorry
>>>
>>> On 12 Jan 2017, at 20:00, Michael Tuexen
>>> 
>>>   wrote:
>>>
>>>
>>>>> On 12 Jan 2017, at 18:36, Jonathan T. Leighton
>>>>>   wrote:
>>>>>
>>>>> Hi Michael -
>>>>>
>>>>> I posted this to
>>>>> tsvwg@ietf.org
>>>>>   on 1/4/17, but it's been over a week now and I haven't had any response. I can try posting it again, or I can submit an errata and see how the authors respond. Do you have a suggestion about how best to proceed?
>>>>>
>>>> I CC'ed some individuals... Given them a couple of days.
>>>> Then file an errata if you want.
>>>>
>>>> I'm find with the text suggested by you.
>>>>
>>>> Best regards
>>>> Michael
>>>>
>>>>> Best regards,
>>>>> Jon
>>>>>
>>>>>
>>>>>
>>>>>> On 1/4/17 1:12 PM, Jonathan T. Leighton wrote:
>>>>>> I've been discussing a possible errata for the sctp_bindx() description in RFC 6458 with Michael Tuexen, and he suggested posting the issue here for       further comment. The current language is vague regarding passing IPv4 addresses versus IPv4-mapped IPv6 addresses, as well as required versus allowed behavior. I've been advised that there is some disagreement about whether or not the term "IPv4 address" includes IPv4-mapped IPv6 address, so the proposed text attempts to avoid that issue.
>>>>>>
>>>>>> OLD TEXT:
>>>>>> If sd is an IPv4 socket, the addresses passed must be IPv4 addresses.
>>>>>> If the sd is an IPv6 socket, the addresses passed can either be IPv4
>>>>>> or IPv6 addresses.
>>>>>> NEW TEXT:
>>>>>> If sd is an IPv4 socket, the passed addresses must be stored in
>>>>>> sockaddr_in structures. If sd is an IPv6 socket, the passed addresses
>>>>>> typically must be stored in sockaddr_in6 structures, however some
>>>>>> implementations may also allow addresses to be stored in sockaddr_in
>>>>>> structures. For implementations that require addresses to be stored
>>>>>> in sockaddr_in6 structures, use IPv4-mapped IPv6 addresses to bind
>>>>>> the socket to the corresponding IPv4 addresses.
>>>>>>
>>>>>>
>>>>>> Best regards
>>>>>> Jon
>>>>>>


From nobody Sat Jan 14 11:32:02 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3818129D29 for ; Sat, 14 Jan 2017 11:31:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=udel-edu.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzAH3IX5hRYE for ; Sat, 14 Jan 2017 11:31:58 -0800 (PST)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 067521294BF for ; Sat, 14 Jan 2017 11:31:57 -0800 (PST)
Received: by mail-qk0-x229.google.com with SMTP id s140so85707059qke.0 for ; Sat, 14 Jan 2017 11:31:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udel-edu.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=is/FKz5NjFDjhB9XR1w37jZ6JRHhm85R4A/YlR/qSx8=; b=j0uhoc56ikwKL/D2ygX2UYOLkFVGEJfHXZVQil37HSlldTGxPdrRapZoDghq0NctB+ jWM5hUmlD/WMSRrv4CQ4gqlKLhgRS/pB87vBVYk94hk4/emFBkg0DkRw6KmCpAexuWm2 UKaA5I88leN8Y8BJ97SPiyvxWJMDdVnrJIuH17Q2hcJA2HqWN9ZGf+rR6Fkfqvpag+3O 3GCPyRbeiTb2OeT9A4j6xyL/STBgIACaqYCVdZTX4hG1LtTpx9yQeJO1xAbjN097PLnF 4oDntf8TbGIOnH4PIALhaTBpNZEe260bubDje8XAKBsyXs9kl6Q37ZFuAZ+w9qlIsnYY Derg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=is/FKz5NjFDjhB9XR1w37jZ6JRHhm85R4A/YlR/qSx8=; b=oHa2owBFGF3ej6jS2pG7sSsjlfEIHPteaihb6sGEJ1r1mozi70LyrrVA5pbfsLTjx9 XlHGjKuvGGtdFNm+/1+EmKCrNvjm/ItOFr7voeIDBNruopoEP6IYO7bVTLIsZryMpcH5 Db6NW924WLdi6ZRTxyZiQsG0ByA+lY6Q2uVCoPl9wTIHyJ0ZmLnrlR+MBjNrTvtehWgU XKUX3wNUOGsL2hmmn0WvAOBVF7Y6ynFyI+7niL6EjUxsEy4zpxAcD9Pu4QlL6Aosgnk4 rnex7vdL7W7qgUczACKiY8FlAbEe8Dz19ofX7uCfmej732E9mWtgGa4ihEIEW5T+QZYb r26w==
X-Gm-Message-State: AIkVDXLmY/71TI3dvHWgVCWeYPw/dirWqksbRtxhG5kA2q2qN3/VfjODjtn2h+WRy0mrNRNP
X-Received: by 10.55.143.71 with SMTP id r68mr4666234qkd.84.1484422316881; Sat, 14 Jan 2017 11:31:56 -0800 (PST)
Received: from iMac-27.local ([2601:183:4102:810d:f0e5:7669:9866:4be6]) by smtp.gmail.com with ESMTPSA id m9sm12091110qte.43.2017.01.14.11.31.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Jan 2017 11:31:56 -0800 (PST)
To: Michael Tuexen 
References: <98348439-7bb7-a37b-7933-db39ae334ba5@udel.edu> <5fe2fc97-8188-c3cc-d009-d09bc9f47640@udel.edu> <31CDAF39-DC53-4DF9-B6AD-73304181A515@lurchi.franken.de> <17B55714-87FC-4881-AF46-CE0808AC4179@erg.abdn.ac.uk> <2e096b5f-a271-b29f-f4a3-dc065d442010@udel.edu> 
From: "Jonathan T. Leighton" 
Message-ID: <5d2dbf3f-215e-5316-b22e-1debf91b4e36@udel.edu>
Date: Sat, 14 Jan 2017 14:31:54 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: Gorry Fairhurst , Kacheong Poon , Vlad Yasevich , tsvwg WG 
Subject: Re: [tsvwg] Proposed errata for RFC 6458 sctp_bindx
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 14 Jan 2017 19:32:00 -0000

On 1/14/17 5:08 AM, Michael Tuexen wrote:
>> On 13 Jan 2017, at 21:52, Jonathan T. Leighton  wrote:
>>
>> On 1/13/17 1:05 PM, Gorry (erg) wrote:
>>> Is this somehow different to how you handle this in TCP? Maybe I missed something?
>> It is not different, though at least one SCTP implementation allows a variation that is not normally available, and to the best of my knowledge is not available in any TCP implementation.
> What system call used by TCP has *multiple* IP addresses as a parameter?

I think we interpreted Gorry's question differently. I was not referring 
to the ability to bind to multiple addresses. I was referring to how 
IPv4 and Ipv6 addresses are bound to IPv6 sockets. For both TCP and 
SCTP, IPv4 address must be translated to IPv4-mapped IPv6 addresses. 
FreeBSD's sctp_bindx() implementation is an exception to that.

Best regards,
Jon

> Best regards
> Michael
>> I think I should back up a bit and say that my original motivation for proposing an errata was this sentence in the description of sctp_bindx():
>> If the sd is an IPv6 socket, the addresses passed can either be IPv4
>> or IPv6 addresses.
>>
>> With the exception of one SCTP implementation, I know of no TCP or SCTP implementation that allows binding an IPv4 address to an IPv6 socket. Instead, IPv4-mapped IPv6 addresses are used. Given that I have encountered a good bit of confusion in some quarters about the different ways to translate IPv4 addresses to IPv6 (embedded, compatible, mapped, ...), it seems to me that the RFC should explicitly mention that IPv4-mapped IPv6 addresses are the appropriate translation to use:
>> If the sd is an IPv6 socket, the addresses passed must be IPv6 addresses.
>> Use IPv4-mapped IPv6 addresses to bind an IPv6 socket to an IPv4 address.
>>
>> It was pointed out to me that at least one SCTP implementation allows IPv4 addresses to be passed directly to sctp_bindx(), so the following change also seems appropriate:
>> If the sd is an IPv6 socket, the addresses passed must be IPv6 addresses.
>> Use IPv4-mapped IPv6 addresses to bind an IPv6 socket to an IPv4 address.
>> Note that some implementations optionally allow IPv4 addresses to be
>> passed in directly.
>>
>> I can explain why I originally suggested a wordier version that mentions the various structures involved if anyone is interested, but the above text is what I'd most like to see.
>>
>> Best regards,
>> Jon
>>
>>> The RFC is informational, so I am not sure how important it is to make this change ... but I would be interested in other opinions... do speak up on the list if you think this is important.
>>>
>>> Gorry
>>>
>>> On 12 Jan 2017, at 20:00, Michael Tuexen
>>> 
>>>   wrote:
>>>
>>>
>>>>> On 12 Jan 2017, at 18:36, Jonathan T. Leighton 
>>>>>   wrote:
>>>>>
>>>>> Hi Michael -
>>>>>
>>>>> I posted this to
>>>>> tsvwg@ietf.org
>>>>>   on 1/4/17, but it's been over a week now and I haven't had any response. I can try posting it again, or I can submit an errata and see how the authors respond. Do you have a suggestion about how best to proceed?
>>>>>
>>>> I CC'ed some individuals... Given them a couple of days.
>>>> Then file an errata if you want.
>>>>
>>>> I'm find with the text suggested by you.
>>>>
>>>> Best regards
>>>> Michael
>>>>
>>>>> Best regards,
>>>>> Jon
>>>>>
>>>>>
>>>>>
>>>>>> On 1/4/17 1:12 PM, Jonathan T. Leighton wrote:
>>>>>> I've been discussing a possible errata for the sctp_bindx() description in RFC 6458 with Michael Tuexen, and he suggested posting the issue here for       further comment. The current language is vague regarding passing IPv4 addresses versus IPv4-mapped IPv6 addresses, as well as required versus allowed behavior. I've been advised that there is some disagreement about whether or not the term "IPv4 address" includes IPv4-mapped IPv6 address, so the proposed text attempts to avoid that issue.
>>>>>>
>>>>>> OLD TEXT:
>>>>>> If sd is an IPv4 socket, the addresses passed must be IPv4 addresses.
>>>>>> If the sd is an IPv6 socket, the addresses passed can either be IPv4
>>>>>> or IPv6 addresses.
>>>>>> NEW TEXT:
>>>>>> If sd is an IPv4 socket, the passed addresses must be stored in
>>>>>> sockaddr_in structures. If sd is an IPv6 socket, the passed addresses
>>>>>> typically must be stored in sockaddr_in6 structures, however some
>>>>>> implementations may also allow addresses to be stored in sockaddr_in
>>>>>> structures. For implementations that require addresses to be stored
>>>>>> in sockaddr_in6 structures, use IPv4-mapped IPv6 addresses to bind
>>>>>> the socket to the corresponding IPv4 addresses.
>>>>>>
>>>>>>
>>>>>> Best regards
>>>>>> Jon
>>>>>>


From nobody Sat Jan 14 12:01:51 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CC3129D52 for ; Sat, 14 Jan 2017 12:01:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=udel-edu.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFP5DLQyISjd for ; Sat, 14 Jan 2017 12:01:48 -0800 (PST)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D75F129D60 for ; Sat, 14 Jan 2017 12:01:48 -0800 (PST)
Received: by mail-qk0-x230.google.com with SMTP id 11so85655929qkl.3 for ; Sat, 14 Jan 2017 12:01:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udel-edu.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=53kJLYdgBVaAZi/FTA8A4z0kROxpUPq8uU2Zyrdr+3k=; b=wTuH2NBF0eYg3XMtSukyAEUuvLWoArgeOJWcSz78tzt1jz2TK66+7+zOlN0sF7YYvB M+8a1zK9S2dnlwFxaUnKnihtr2NoJtCfPu1+X0owhSyNFFJJ7MvZQfpmPjb9Oo7GC9/b WCZ9rbK34QRq20B+igxA/4llSchuj1U4DWJzF5u9wxWKez7C23qC6eOeYvbKEQzxXIiz axbkhyZSz+MQYFQY9eOrT7fbOyXuL8NX6TbSQFEQCvJGEM2uuuEX2Gevvoc+LAWhRWHA 01+iPzWMWGo188do5vmynpmViy2VXJgfdr2x2F8vxxoJxZwuGO2Qh1RWGXCbXOCu86z4 s6dQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=53kJLYdgBVaAZi/FTA8A4z0kROxpUPq8uU2Zyrdr+3k=; b=qeBHrChroZYh73wtEGb0mD6N09r4R6OX4pUygSptJAXB9S0xt2VsmpKZS++wYudqLj kgmDKjCrlt3oT7t+XPpADdp4LGBXPUAoxZl8QUicKlzKc/aNaF1LIZdKmr5EOOCKRrlW k1oGNPSHyxzOSYIlaWUTiTd6lMtH5qRyFen8W1d+i2zSbdlJ9yuiqB2d/NAvsSHRiw8Q 7KVwlmH6d2nNLjnWp9I4wvZVVS0fZEBMGFeHcnr85fVrko5u2CHggx9NLjG+R4+/CmYS GA++VhrroQfF5mRb4l0hdaxS5Fpp6I+N2g7X8mygCdZJMounxgY4vEoN4tpS0B+ioU18 muNg==
X-Gm-Message-State: AIkVDXLPysgDzZ3gUpz9ERf74YGHwoLB9Mt+PwdzKa+PlQxVcTj7dqj4omNAicIZIduga+xV
X-Received: by 10.55.43.149 with SMTP id r21mr25823488qkr.123.1484424107552; Sat, 14 Jan 2017 12:01:47 -0800 (PST)
Received: from iMac-27.local ([2601:183:4102:810d:f0e5:7669:9866:4be6]) by smtp.gmail.com with ESMTPSA id k26sm12245094qtc.36.2017.01.14.12.01.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Jan 2017 12:01:46 -0800 (PST)
To: gorry@erg.abdn.ac.uk, Michael Tuexen 
References: <98348439-7bb7-a37b-7933-db39ae334ba5@udel.edu> <5fe2fc97-8188-c3cc-d009-d09bc9f47640@udel.edu> <31CDAF39-DC53-4DF9-B6AD-73304181A515@lurchi.franken.de> <17B55714-87FC-4881-AF46-CE0808AC4179@erg.abdn.ac.uk> <2e096b5f-a271-b29f-f4a3-dc065d442010@udel.edu>  <587A0137.8010901@erg.abdn.ac.uk>
From: "Jonathan T. Leighton" 
Message-ID: 
Date: Sat, 14 Jan 2017 15:01:45 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <587A0137.8010901@erg.abdn.ac.uk>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: Kacheong Poon , Vlad Yasevich , tsvwg WG 
Subject: Re: [tsvwg] Proposed errata for RFC 6458 sctp_bindx
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 14 Jan 2017 20:01:50 -0000

On 1/14/17 5:45 AM, Gorry Fairhurst wrote:
> Is this then about recognising that the address format is IPv6...? and 
> if so, is the correction along the lines of (with appropriate wording 
> of course):
>
> OLD:
> If the sd is an IPv6 socket, the addresses passed can either be IPv4 
> or IPv6 addresses.
>
> NEW:
>
> If the sd is an IPv6 socket, the addresses passed can be either IPv6 
> addresses
> or IPv4-Compatible IPv6 addresses (RFC 4291).

Yes - for me this is about recognizing that the address format is IPv6, 
but I think it should also mention that some implementations may allow 
the IPv4 format.

I would not use the term IPv4-Compatible IPv6 address since it's not the 
right format for binding, and because per RFC 4291 that type of address 
has been deprecated (sec. 2.5.5.1). RFC 4291 defines the IPv4-mapped 
IPv6 address and refers to RFC 4038 for a description of its use with 
IPv6 applications.

Best regards,
Jon

> Gorry
>
> On 14/01/2017 10:08, Michael Tuexen wrote:
>>> On 13 Jan 2017, at 21:52, Jonathan T. Leighton  
>>> wrote:
>>>
>>> On 1/13/17 1:05 PM, Gorry (erg) wrote:
>>>> Is this somehow different to how you handle this in TCP? Maybe I 
>>>> missed something?
>>> It is not different, though at least one SCTP implementation allows 
>>> a variation that is not normally available, and to the best of my 
>>> knowledge is not available in any TCP implementation.
>> What system call used by TCP has *multiple* IP addresses as a parameter?
>>
>> Best regards
>> Michael
>>> I think I should back up a bit and say that my original motivation 
>>> for proposing an errata was this sentence in the description of 
>>> sctp_bindx():
>>> If the sd is an IPv6 socket, the addresses passed can either be IPv4
>>> or IPv6 addresses.
>>>
>>> With the exception of one SCTP implementation, I know of no TCP or 
>>> SCTP implementation that allows binding an IPv4 address to an IPv6 
>>> socket. Instead, IPv4-mapped IPv6 addresses are used. Given that I 
>>> have encountered a good bit of confusion in some quarters about the 
>>> different ways to translate IPv4 addresses to IPv6 (embedded, 
>>> compatible, mapped, ...), it seems to me that the RFC should 
>>> explicitly mention that IPv4-mapped IPv6 addresses are the 
>>> appropriate translation to use:
>>> If the sd is an IPv6 socket, the addresses passed must be IPv6 
>>> addresses.
>>> Use IPv4-mapped IPv6 addresses to bind an IPv6 socket to an IPv4 
>>> address.
>>>
>>> It was pointed out to me that at least one SCTP implementation 
>>> allows IPv4 addresses to be passed directly to sctp_bindx(), so the 
>>> following change also seems appropriate:
>>> If the sd is an IPv6 socket, the addresses passed must be IPv6 
>>> addresses.
>>> Use IPv4-mapped IPv6 addresses to bind an IPv6 socket to an IPv4 
>>> address.
>>> Note that some implementations optionally allow IPv4 addresses to be
>>> passed in directly.
>>>
>>> I can explain why I originally suggested a wordier version that 
>>> mentions the various structures involved if anyone is interested, 
>>> but the above text is what I'd most like to see.
>>>
>>> Best regards,
>>> Jon
>>>
>>>> The RFC is informational, so I am not sure how important it is to 
>>>> make this change ... but I would be interested in other opinions... 
>>>> do speak up on the list if you think this is important.
>>>>
>>>> Gorry
>>>>
>>>> On 12 Jan 2017, at 20:00, Michael Tuexen
>>>> 
>>>>   wrote:
>>>>
>>>>
>>>>>> On 12 Jan 2017, at 18:36, Jonathan T. Leighton
>>>>>>   wrote:
>>>>>>
>>>>>> Hi Michael -
>>>>>>
>>>>>> I posted this to
>>>>>> tsvwg@ietf.org
>>>>>>   on 1/4/17, but it's been over a week now and I haven't had any 
>>>>>> response. I can try posting it again, or I can submit an errata 
>>>>>> and see how the authors respond. Do you have a suggestion about 
>>>>>> how best to proceed?
>>>>>>
>>>>> I CC'ed some individuals... Given them a couple of days.
>>>>> Then file an errata if you want.
>>>>>
>>>>> I'm find with the text suggested by you.
>>>>>
>>>>> Best regards
>>>>> Michael
>>>>>
>>>>>> Best regards,
>>>>>> Jon
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 1/4/17 1:12 PM, Jonathan T. Leighton wrote:
>>>>>>> I've been discussing a possible errata for the sctp_bindx() 
>>>>>>> description in RFC 6458 with Michael Tuexen, and he suggested 
>>>>>>> posting the issue here for       further comment. The current 
>>>>>>> language is vague regarding passing IPv4 addresses versus 
>>>>>>> IPv4-mapped IPv6 addresses, as well as required versus allowed 
>>>>>>> behavior. I've been advised that there is some disagreement 
>>>>>>> about whether or not the term "IPv4 address" includes 
>>>>>>> IPv4-mapped IPv6 address, so the proposed text attempts to avoid 
>>>>>>> that issue.
>>>>>>>
>>>>>>> OLD TEXT:
>>>>>>> If sd is an IPv4 socket, the addresses passed must be IPv4 
>>>>>>> addresses.
>>>>>>> If the sd is an IPv6 socket, the addresses passed can either be 
>>>>>>> IPv4
>>>>>>> or IPv6 addresses.
>>>>>>> NEW TEXT:
>>>>>>> If sd is an IPv4 socket, the passed addresses must be stored in
>>>>>>> sockaddr_in structures. If sd is an IPv6 socket, the passed 
>>>>>>> addresses
>>>>>>> typically must be stored in sockaddr_in6 structures, however some
>>>>>>> implementations may also allow addresses to be stored in 
>>>>>>> sockaddr_in
>>>>>>> structures. For implementations that require addresses to be stored
>>>>>>> in sockaddr_in6 structures, use IPv4-mapped IPv6 addresses to bind
>>>>>>> the socket to the corresponding IPv4 addresses.
>>>>>>>
>>>>>>>
>>>>>>> Best regards
>>>>>>> Jon
>>>>>>>
>


From nobody Sun Jan 15 01:10:40 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2568812945B for ; Sun, 15 Jan 2017 01:10:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.8
X-Spam-Level: 
X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkU3B_0v_ypW for ; Sun, 15 Jan 2017 01:10:36 -0800 (PST)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E9CB126B6D for ; Sun, 15 Jan 2017 01:10:35 -0800 (PST)
Received: from [IPv6:2003:cd:6bc9:5900:a559:c6b3:5f87:bc6d] (p200300CD6BC95900A559C6B35F87BC6D.dip0.t-ipconnect.de [IPv6:2003:cd:6bc9:5900:a559:c6b3:5f87:bc6d]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 2F87D721E2825; Sun, 15 Jan 2017 10:10:32 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Michael Tuexen 
In-Reply-To: <5d2dbf3f-215e-5316-b22e-1debf91b4e36@udel.edu>
Date: Sun, 15 Jan 2017 10:10:31 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <77FD859C-0E14-4065-85E4-325B0F346362@lurchi.franken.de>
References: <98348439-7bb7-a37b-7933-db39ae334ba5@udel.edu> <5fe2fc97-8188-c3cc-d009-d09bc9f47640@udel.edu> <31CDAF39-DC53-4DF9-B6AD-73304181A515@lurchi.franken.de> <17B55714-87FC-4881-AF46-CE0808AC4179@erg.abdn.ac.uk> <2e096b5f-a271-b29f-f4a3-dc065d442010@udel.edu>  <5d2dbf3f-215e-5316-b22e-1debf91b4e36@udel.edu>
To: "Jonathan T. Leighton" 
X-Mailer: Apple Mail (2.3259)
Archived-At: 
Cc: Gorry Fairhurst , Kacheong Poon , Vlad Yasevich , tsvwg WG 
Subject: Re: [tsvwg] Proposed errata for RFC 6458 sctp_bindx
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Jan 2017 09:10:39 -0000

> On 14 Jan 2017, at 20:31, Jonathan T. Leighton  =
wrote:
>=20
> On 1/14/17 5:08 AM, Michael Tuexen wrote:
>>> On 13 Jan 2017, at 21:52, Jonathan T. Leighton  =
wrote:
>>>=20
>>> On 1/13/17 1:05 PM, Gorry (erg) wrote:
>>>> Is this somehow different to how you handle this in TCP? Maybe I =
missed something?
>>> It is not different, though at least one SCTP implementation allows =
a variation that is not normally available, and to the best of my =
knowledge is not available in any TCP implementation.
>> What system call used by TCP has *multiple* IP addresses as a =
parameter?
>=20
> I think we interpreted Gorry's question differently. I was not =
referring to the ability to bind to multiple addresses. I was referring =
to how IPv4 and Ipv6 addresses are bound to IPv6 sockets. For both TCP =
and SCTP, IPv4 address must be translated to IPv4-mapped IPv6 addresses. =
FreeBSD's sctp_bindx() implementation is an exception to that.
I agree to that. But this doesn't affect TCP.

Best regards
Michael
>=20
> Best regards,
> Jon
>=20
>> Best regards
>> Michael
>>> I think I should back up a bit and say that my original motivation =
for proposing an errata was this sentence in the description of =
sctp_bindx():
>>> If the sd is an IPv6 socket, the addresses passed can either be IPv4
>>> or IPv6 addresses.
>>>=20
>>> With the exception of one SCTP implementation, I know of no TCP or =
SCTP implementation that allows binding an IPv4 address to an IPv6 =
socket. Instead, IPv4-mapped IPv6 addresses are used. Given that I have =
encountered a good bit of confusion in some quarters about the different =
ways to translate IPv4 addresses to IPv6 (embedded, compatible, mapped, =
...), it seems to me that the RFC should explicitly mention that =
IPv4-mapped IPv6 addresses are the appropriate translation to use:
>>> If the sd is an IPv6 socket, the addresses passed must be IPv6 =
addresses.
>>> Use IPv4-mapped IPv6 addresses to bind an IPv6 socket to an IPv4 =
address.
>>>=20
>>> It was pointed out to me that at least one SCTP implementation =
allows IPv4 addresses to be passed directly to sctp_bindx(), so the =
following change also seems appropriate:
>>> If the sd is an IPv6 socket, the addresses passed must be IPv6 =
addresses.
>>> Use IPv4-mapped IPv6 addresses to bind an IPv6 socket to an IPv4 =
address.
>>> Note that some implementations optionally allow IPv4 addresses to be
>>> passed in directly.
>>>=20
>>> I can explain why I originally suggested a wordier version that =
mentions the various structures involved if anyone is interested, but =
the above text is what I'd most like to see.
>>>=20
>>> Best regards,
>>> Jon
>>>=20
>>>> The RFC is informational, so I am not sure how important it is to =
make this change ... but I would be interested in other opinions... do =
speak up on the list if you think this is important.
>>>>=20
>>>> Gorry
>>>>=20
>>>> On 12 Jan 2017, at 20:00, Michael Tuexen
>>>> 
>>>>  wrote:
>>>>=20
>>>>=20
>>>>>> On 12 Jan 2017, at 18:36, Jonathan T. Leighton =

>>>>>>  wrote:
>>>>>>=20
>>>>>> Hi Michael -
>>>>>>=20
>>>>>> I posted this to
>>>>>> tsvwg@ietf.org
>>>>>>  on 1/4/17, but it's been over a week now and I haven't had any =
response. I can try posting it again, or I can submit an errata and see =
how the authors respond. Do you have a suggestion about how best to =
proceed?
>>>>>>=20
>>>>> I CC'ed some individuals... Given them a couple of days.
>>>>> Then file an errata if you want.
>>>>>=20
>>>>> I'm find with the text suggested by you.
>>>>>=20
>>>>> Best regards
>>>>> Michael
>>>>>=20
>>>>>> Best regards,
>>>>>> Jon
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> On 1/4/17 1:12 PM, Jonathan T. Leighton wrote:
>>>>>>> I've been discussing a possible errata for the sctp_bindx() =
description in RFC 6458 with Michael Tuexen, and he suggested posting =
the issue here for       further comment. The current language is vague =
regarding passing IPv4 addresses versus IPv4-mapped IPv6 addresses, as =
well as required versus allowed behavior. I've been advised that there =
is some disagreement about whether or not the term "IPv4 address" =
includes IPv4-mapped IPv6 address, so the proposed text attempts to =
avoid that issue.
>>>>>>>=20
>>>>>>> OLD TEXT:
>>>>>>> If sd is an IPv4 socket, the addresses passed must be IPv4 =
addresses.
>>>>>>> If the sd is an IPv6 socket, the addresses passed can either be =
IPv4
>>>>>>> or IPv6 addresses.
>>>>>>> NEW TEXT:
>>>>>>> If sd is an IPv4 socket, the passed addresses must be stored in
>>>>>>> sockaddr_in structures. If sd is an IPv6 socket, the passed =
addresses
>>>>>>> typically must be stored in sockaddr_in6 structures, however =
some
>>>>>>> implementations may also allow addresses to be stored in =
sockaddr_in
>>>>>>> structures. For implementations that require addresses to be =
stored
>>>>>>> in sockaddr_in6 structures, use IPv4-mapped IPv6 addresses to =
bind
>>>>>>> the socket to the corresponding IPv4 addresses.
>>>>>>>=20
>>>>>>>=20
>>>>>>> Best regards
>>>>>>> Jon
>>>>>>>=20
>=20


From nobody Sun Jan 15 01:12:47 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55C112945B for ; Sun, 15 Jan 2017 01:12:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.8
X-Spam-Level: 
X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zvAcKS54ekm for ; Sun, 15 Jan 2017 01:12:44 -0800 (PST)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E5E0126B6D for ; Sun, 15 Jan 2017 01:12:44 -0800 (PST)
Received: from [IPv6:2003:cd:6bc9:5900:a559:c6b3:5f87:bc6d] (p200300CD6BC95900A559C6B35F87BC6D.dip0.t-ipconnect.de [IPv6:2003:cd:6bc9:5900:a559:c6b3:5f87:bc6d]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 80FE5721E2825; Sun, 15 Jan 2017 10:12:41 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Michael Tuexen 
In-Reply-To: <587A0137.8010901@erg.abdn.ac.uk>
Date: Sun, 15 Jan 2017 10:12:41 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8C5BE7D7-1EAC-4CDD-806D-D40DE1D6FAA7@lurchi.franken.de>
References: <98348439-7bb7-a37b-7933-db39ae334ba5@udel.edu> <5fe2fc97-8188-c3cc-d009-d09bc9f47640@udel.edu> <31CDAF39-DC53-4DF9-B6AD-73304181A515@lurchi.franken.de> <17B55714-87FC-4881-AF46-CE0808AC4179@erg.abdn.ac.uk> <2e096b5f-a271-b29f-f4a3-dc065d442010@udel.edu>  <587A0137.8010901@erg.abdn.ac.uk>
To: Gorry Fairhurst 
X-Mailer: Apple Mail (2.3259)
Archived-At: 
Cc: Kacheong Poon , Vlad Yasevich , tsvwg WG 
Subject: Re: [tsvwg] Proposed errata for RFC 6458 sctp_bindx
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Jan 2017 09:12:47 -0000

> On 14 Jan 2017, at 11:45, Gorry Fairhurst  =
wrote:
>=20
> Is this then about recognising that the address format is IPv6...?  =
and if so, is the correction along the lines of (with appropriate =
wording of course):
>=20
> OLD:
> If the sd is an IPv6 socket, the addresses passed can either be IPv4 =
or IPv6 addresses.
>=20
> NEW:
>=20
> If the sd is an IPv6 socket, the addresses passed can be either IPv6 =
addresses
> or IPv4-Compatible IPv6 addresses (RFC 4291).
The point I wanted to allow that for sctp_bindx() you can also provide a =
mixture
of struct sockaddr_in and struct sockaddr_in6 structures. This is =
allowed in FreeBSD.
Your suggested test would not allow this.

Best regards
Michael
>=20
> Gorry
>=20
> On 14/01/2017 10:08, Michael Tuexen wrote:
>>> On 13 Jan 2017, at 21:52, Jonathan T. Leighton  =
wrote:
>>>=20
>>> On 1/13/17 1:05 PM, Gorry (erg) wrote:
>>>> Is this somehow different to how you handle this in TCP? Maybe I =
missed something?
>>> It is not different, though at least one SCTP implementation allows =
a variation that is not normally available, and to the best of my =
knowledge is not available in any TCP implementation.
>> What system call used by TCP has *multiple* IP addresses as a =
parameter?
>>=20
>> Best regards
>> Michael
>>> I think I should back up a bit and say that my original motivation =
for proposing an errata was this sentence in the description of =
sctp_bindx():
>>> If the sd is an IPv6 socket, the addresses passed can either be IPv4
>>> or IPv6 addresses.
>>>=20
>>> With the exception of one SCTP implementation, I know of no TCP or =
SCTP implementation that allows binding an IPv4 address to an IPv6 =
socket. Instead, IPv4-mapped IPv6 addresses are used. Given that I have =
encountered a good bit of confusion in some quarters about the different =
ways to translate IPv4 addresses to IPv6 (embedded, compatible, mapped, =
...), it seems to me that the RFC should explicitly mention that =
IPv4-mapped IPv6 addresses are the appropriate translation to use:
>>> If the sd is an IPv6 socket, the addresses passed must be IPv6 =
addresses.
>>> Use IPv4-mapped IPv6 addresses to bind an IPv6 socket to an IPv4 =
address.
>>>=20
>>> It was pointed out to me that at least one SCTP implementation =
allows IPv4 addresses to be passed directly to sctp_bindx(), so the =
following change also seems appropriate:
>>> If the sd is an IPv6 socket, the addresses passed must be IPv6 =
addresses.
>>> Use IPv4-mapped IPv6 addresses to bind an IPv6 socket to an IPv4 =
address.
>>> Note that some implementations optionally allow IPv4 addresses to be
>>> passed in directly.
>>>=20
>>> I can explain why I originally suggested a wordier version that =
mentions the various structures involved if anyone is interested, but =
the above text is what I'd most like to see.
>>>=20
>>> Best regards,
>>> Jon
>>>=20
>>>> The RFC is informational, so I am not sure how important it is to =
make this change ... but I would be interested in other opinions... do =
speak up on the list if you think this is important.
>>>>=20
>>>> Gorry
>>>>=20
>>>> On 12 Jan 2017, at 20:00, Michael Tuexen
>>>> 
>>>>  wrote:
>>>>=20
>>>>=20
>>>>>> On 12 Jan 2017, at 18:36, Jonathan T. Leighton
>>>>>>  wrote:
>>>>>>=20
>>>>>> Hi Michael -
>>>>>>=20
>>>>>> I posted this to
>>>>>> tsvwg@ietf.org
>>>>>>  on 1/4/17, but it's been over a week now and I haven't had any =
response. I can try posting it again, or I can submit an errata and see =
how the authors respond. Do you have a suggestion about how best to =
proceed?
>>>>>>=20
>>>>> I CC'ed some individuals... Given them a couple of days.
>>>>> Then file an errata if you want.
>>>>>=20
>>>>> I'm find with the text suggested by you.
>>>>>=20
>>>>> Best regards
>>>>> Michael
>>>>>=20
>>>>>> Best regards,
>>>>>> Jon
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> On 1/4/17 1:12 PM, Jonathan T. Leighton wrote:
>>>>>>> I've been discussing a possible errata for the sctp_bindx() =
description in RFC 6458 with Michael Tuexen, and he suggested posting =
the issue here for       further comment. The current language is vague =
regarding passing IPv4 addresses versus IPv4-mapped IPv6 addresses, as =
well as required versus allowed behavior. I've been advised that there =
is some disagreement about whether or not the term "IPv4 address" =
includes IPv4-mapped IPv6 address, so the proposed text attempts to =
avoid that issue.
>>>>>>>=20
>>>>>>> OLD TEXT:
>>>>>>> If sd is an IPv4 socket, the addresses passed must be IPv4 =
addresses.
>>>>>>> If the sd is an IPv6 socket, the addresses passed can either be =
IPv4
>>>>>>> or IPv6 addresses.
>>>>>>> NEW TEXT:
>>>>>>> If sd is an IPv4 socket, the passed addresses must be stored in
>>>>>>> sockaddr_in structures. If sd is an IPv6 socket, the passed =
addresses
>>>>>>> typically must be stored in sockaddr_in6 structures, however =
some
>>>>>>> implementations may also allow addresses to be stored in =
sockaddr_in
>>>>>>> structures. For implementations that require addresses to be =
stored
>>>>>>> in sockaddr_in6 structures, use IPv4-mapped IPv6 addresses to =
bind
>>>>>>> the socket to the corresponding IPv4 addresses.
>>>>>>>=20
>>>>>>>=20
>>>>>>> Best regards
>>>>>>> Jon
>>>>>>>=20
>=20


From nobody Mon Jan 16 01:16:06 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431B912950E for ; Mon, 16 Jan 2017 01:16:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.501
X-Spam-Level: 
X-Spam-Status: No, score=-5.501 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEDvgTc0PH_m for ; Mon, 16 Jan 2017 01:16:01 -0800 (PST)
Received: from aserp1050.oracle.com (aserp1050.oracle.com [141.146.126.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF7DA129454 for ; Mon, 16 Jan 2017 01:16:01 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by aserp1050.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v0G9G0Ax028632 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 16 Jan 2017 09:16:00 GMT
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v0G8tSQD008851 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 16 Jan 2017 08:55:29 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v0G8tSO2023088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 16 Jan 2017 08:55:28 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v0G8tRuH017335; Mon, 16 Jan 2017 08:55:27 GMT
Received: from [10.159.211.26] (/10.159.211.26) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 16 Jan 2017 00:55:27 -0800
Message-ID: <587C8A7C.20104@oracle.com>
Date: Mon, 16 Jan 2017 16:55:24 +0800
From: Ka-Cheong Poon 
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Michael Tuexen , "Jonathan T. Leighton" 
References: <98348439-7bb7-a37b-7933-db39ae334ba5@udel.edu> <5fe2fc97-8188-c3cc-d009-d09bc9f47640@udel.edu> <31CDAF39-DC53-4DF9-B6AD-73304181A515@lurchi.franken.de>
In-Reply-To: <31CDAF39-DC53-4DF9-B6AD-73304181A515@lurchi.franken.de>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: aserp1040.oracle.com [141.146.126.69]
Archived-At: 
Cc: Vlad Yasevich , tsvwg WG 
Subject: Re: [tsvwg] Proposed errata for RFC 6458 sctp_bindx
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Jan 2017 09:16:04 -0000

On 01/13/17 04:00 AM, Michael Tuexen wrote:
>> On 12 Jan 2017, at 18:36, Jonathan T. Leighton  wrote:
>>
>> Hi Michael -
>>
>> I posted this to tsvwg@ietf.org on 1/4/17, but it's been over a week now and I haven't had any response. I can try posting it again, or I can submit an errata and see how the authors respond. Do you have a suggestion about how best to proceed?
> I CC'ed some individuals... Given them a couple of days.
> Then file an errata if you want.
>
> I'm find with the text suggested by you.


The changes look fine to me too.  Thanks.


>> On 1/4/17 1:12 PM, Jonathan T. Leighton wrote:
>>> I've been discussing a possible errata for the sctp_bindx() description in RFC 6458 with Michael Tuexen, and he suggested posting the issue here for       further comment. The current language is vague regarding passing IPv4 addresses versus IPv4-mapped IPv6 addresses, as well as required versus allowed behavior. I've been advised that there is some disagreement about whether or not the term "IPv4 address" includes IPv4-mapped IPv6 address, so the proposed text attempts to avoid that issue.
>>>
>>> OLD TEXT:
>>> If sd is an IPv4 socket, the addresses passed must be IPv4 addresses.
>>> If the sd is an IPv6 socket, the addresses passed can either be IPv4
>>> or IPv6 addresses.
>>> NEW TEXT:
>>> If sd is an IPv4 socket, the passed addresses must be stored in
>>> sockaddr_in structures. If sd is an IPv6 socket, the passed addresses
>>> typically must be stored in sockaddr_in6 structures, however some
>>> implementations may also allow addresses to be stored in sockaddr_in
>>> structures. For implementations that require addresses to be stored
>>> in sockaddr_in6 structures, use IPv4-mapped IPv6 addresses to bind
>>> the socket to the corresponding IPv4 addresses.
>>>
>>>
>>> Best regards
>>> Jon
>>
>


-- 
K. Poon
ka-cheong.poon@oracle.com



From nobody Tue Jan 17 11:29:25 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6580C129486 for ; Tue, 17 Jan 2017 11:29:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=udel-edu.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibJpa-mNUY4h for ; Tue, 17 Jan 2017 11:29:22 -0800 (PST)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7698E12007C for ; Tue, 17 Jan 2017 11:29:22 -0800 (PST)
Received: by mail-yw0-x233.google.com with SMTP id l75so97317402ywb.0 for ; Tue, 17 Jan 2017 11:29:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udel-edu.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=bdAnChw8vdV6Dqh97T0KWGKNjwuXe9GZdNbGWl4SE1U=; b=SetBdeCI9RANmG7dknOM66P3TXGBcjUN2i04QRoyZkCfx+wdOQ2s5rk9oLEtQ89XZ/ iSoArKkOWSrCodiNJa67GtHJuCVOmT9VTBMA9AHMq4psKyY/EYVJ/0CvTrnAu1oQpg3N mMfuJrC1z3QwYMaxgkKJiwxl+JvqbqU5Mtdh8L59gDGLWjtBhiCxpnnFG+ax0YTi3Gm3 YIe390GMx9iI1tgpfC6J5IkL+fnMAfmUW/WUZLQOZQolkEnjn4CH5ZqFxUHJAqTc7IPc fqnDfoQrpr0w752MLxatS1cUVlTxnq0bV+HPt6DwkpkcnES2Azydq2wG4Bhmi74RDZTN kLIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=bdAnChw8vdV6Dqh97T0KWGKNjwuXe9GZdNbGWl4SE1U=; b=jrqXbwhe7JkK283g/qY4H4olN0VVFUr5J/n1AFGM+VF8W0NhccrVPq+zAVVdKoy/+H uk0UgeuLAFYO1qGwy7dBmf5JlWk//iHv6JnpvparySUmZNoIzxZC8YwQTsM0teKzFYnc f3/3iBn/yOpGq5XvqL7EuVq5zJqM8KQyqRNOoFPTirYu/2EQFroA1tQYfhlshQXhXwds b1YqREMKBJv1eSehtkHyZdmrmcZAKX0ACLCT78XJRPs8qjqIZ060M7IHk0Y2LilBedJJ r0dqlD/4J3G/sk68nC92xWw8IwuDeL3hCkFDwYTFQm5fFeapJJskRhZmEAp5kTJT3QFY bePw==
X-Gm-Message-State: AIkVDXL7Z4PEdHoHqv6c6q/lteJ1pQHStxFAxyGZdbXwBaHjjlKp38+FQQGvs6YfiOKKIMd3
X-Received: by 10.55.155.145 with SMTP id d139mr35610981qke.233.1484681361634;  Tue, 17 Jan 2017 11:29:21 -0800 (PST)
Received: from iMac-27.local ([2601:183:4102:810d:b9cd:eeb2:b33f:3eaf]) by smtp.gmail.com with ESMTPSA id h46sm19563338qta.35.2017.01.17.11.29.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jan 2017 11:29:21 -0800 (PST)
To: Ka-Cheong Poon 
References: <98348439-7bb7-a37b-7933-db39ae334ba5@udel.edu> <5fe2fc97-8188-c3cc-d009-d09bc9f47640@udel.edu> <31CDAF39-DC53-4DF9-B6AD-73304181A515@lurchi.franken.de> <587C8A7C.20104@oracle.com>
From: "Jonathan T. Leighton" 
Message-ID: <1cb7dd2f-4596-ad12-6786-184b0e3a2491@udel.edu>
Date: Tue, 17 Jan 2017 14:29:19 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <587C8A7C.20104@oracle.com>
Content-Type: multipart/alternative; boundary="------------AE9DAFD9D099CFA4602571D2"
Archived-At: 
Cc: Michael Tuexen , Vlad Yasevich , tsvwg WG 
Subject: Re: [tsvwg] Proposed errata for RFC 6458 sctp_bindx
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Jan 2017 19:29:24 -0000

This is a multi-part message in MIME format.
--------------AE9DAFD9D099CFA4602571D2
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 1/16/17 3:55 AM, Ka-Cheong Poon wrote:
> On 01/13/17 04:00 AM, Michael Tuexen wrote:
>>> On 12 Jan 2017, at 18:36, Jonathan T. Leighton  
>>> wrote:
>>>
>>> Hi Michael -
>>>
>>> I posted this to tsvwg@ietf.org on 1/4/17, but it's been over a week 
>>> now and I haven't had any response. I can try posting it again, or I 
>>> can submit an errata and see how the authors respond. Do you have a 
>>> suggestion about how best to proceed?
>> I CC'ed some individuals... Given them a couple of days.
>> Then file an errata if you want.
>>
>> I'm find with the text suggested by you.
>
>
> The changes look fine to me too.  Thanks.

Can you clarify whether you're referring to this version of the proposed 
change:

    NEW TEXT:
    If sd is an IPv4 socket, the passed addresses must be stored in
    sockaddr_in structures. If sd is an IPv6 socket, the passed addresses
    typically must be stored in sockaddr_in6 structures, however some
    implementations may also allow addresses to be stored in sockaddr_in
    structures. For implementations that require addresses to be stored
    in sockaddr_in6 structures, use IPv4-mapped IPv6 addresses to bind
    the socket to the corresponding IPv4 addresses.

or this version:

    NEW TEXT:
    If sd is an IPv4 socket, the passed addresses must be IPv4 addresses.
    If sd is an IPv6 socket, the passed addresses must be IPv6 addresses.
    Use IPv4-mapped IPv6 addresses to bind an IPv6 socket to an IPv4 address.
    Note that some implementations optionally allow IPv4 addresses to be
    passed in directly.

Thanks very much,
Jon


>>> On 1/4/17 1:12 PM, Jonathan T. Leighton wrote:
>>>> I've been discussing a possible errata for the sctp_bindx() 
>>>> description in RFC 6458 with Michael Tuexen, and he suggested 
>>>> posting the issue here for further comment. The current language is 
>>>> vague regarding passing IPv4 addresses versus IPv4-mapped IPv6 
>>>> addresses, as well as required versus allowed behavior. I've been 
>>>> advised that there is some disagreement about whether or not the 
>>>> term "IPv4 address" includes IPv4-mapped IPv6 address, so the 
>>>> proposed text attempts to avoid that issue.
>>>>
>>>> OLD TEXT:
>>>> If sd is an IPv4 socket, the addresses passed must be IPv4 addresses.
>>>> If the sd is an IPv6 socket, the addresses passed can either be IPv4
>>>> or IPv6 addresses.
>>>> NEW TEXT:
>>>> If sd is an IPv4 socket, the passed addresses must be stored in
>>>> sockaddr_in structures. If sd is an IPv6 socket, the passed addresses
>>>> typically must be stored in sockaddr_in6 structures, however some
>>>> implementations may also allow addresses to be stored in sockaddr_in
>>>> structures. For implementations that require addresses to be stored
>>>> in sockaddr_in6 structures, use IPv4-mapped IPv6 addresses to bind
>>>> the socket to the corresponding IPv4 addresses.
>>>>
>>>>
>>>> Best regards
>>>> Jon
>>>
>>
>
>


--------------AE9DAFD9D099CFA4602571D2
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    On 1/16/17 3:55 AM, Ka-Cheong Poon wrote:

    
On
      01/13/17 04:00 AM, Michael Tuexen wrote:
      

      

        
On 12 Jan 2017, at 18:36, Jonathan T.
          Leighton <jtleight@UDel.Edu> wrote:
          

          

          Hi Michael -
          

          

          I posted this to tsvwg@ietf.org on 1/4/17, but it's been over
          a week now and I haven't had any response. I can try posting
          it again, or I can submit an errata and see how the authors
          respond. Do you have a suggestion about how best to proceed?
          

        

        I CC'ed some individuals... Given them a couple of days.
        

        Then file an errata if you want.
        

        

        I'm find with the text suggested by you.
        

      

      

      

      The changes look fine to me too.  Thanks.
      

    

    

    Can you clarify whether you're referring to this version of the
    proposed change:

    
NEW TEXT: 

      If sd is an IPv4 socket, the passed addresses must be stored
        in 

      sockaddr_in structures. If sd is an IPv6 socket, the passed
        addresses 

      typically must be stored in sockaddr_in6 structures, however
        some 

      implementations may also allow addresses to be stored in
        sockaddr_in 

      structures. For implementations that require addresses to be
        stored 

      in sockaddr_in6 structures, use IPv4-mapped IPv6 addresses to
        bind 

      the socket to the corresponding IPv4 addresses.

    

    or this version:

    

      
NEW TEXT:
If sd is an IPv4 socket, the passed addresses must be IPv4 addresses.
If sd is an IPv6 socket, the passed addresses must be IPv6 addresses.
Use IPv4-mapped IPv6 addresses to bind an IPv6 socket to an IPv4 address.
Note that some implementations optionally allow IPv4 addresses to be
passed in directly.

    

    Thanks very much,

    Jon

    

    

    

      

        
On 1/4/17 1:12 PM, Jonathan T. Leighton
          wrote:
          

          
I've been discussing a possible errata
            for the sctp_bindx() description in RFC 6458 with Michael
            Tuexen, and he suggested posting the issue here for      
            further comment. The current language is vague regarding
            passing IPv4 addresses versus IPv4-mapped IPv6 addresses, as
            well as required versus allowed behavior. I've been advised
            that there is some disagreement about whether or not the
            term "IPv4 address" includes IPv4-mapped IPv6 address, so
            the proposed text attempts to avoid that issue.
            

            

            OLD TEXT:
            

            If sd is an IPv4 socket, the addresses passed must be IPv4
            addresses.
            

            If the sd is an IPv6 socket, the addresses passed can either
            be IPv4
            

            or IPv6 addresses.
            

            NEW TEXT:
            

            If sd is an IPv4 socket, the passed addresses must be stored
            in
            

            sockaddr_in structures. If sd is an IPv6 socket, the passed
            addresses
            

            typically must be stored in sockaddr_in6 structures, however
            some
            

            implementations may also allow addresses to be stored in
            sockaddr_in
            

            structures. For implementations that require addresses to be
            stored
            

            in sockaddr_in6 structures, use IPv4-mapped IPv6 addresses
            to bind
            

            the socket to the corresponding IPv4 addresses.
            

            

            

            Best regards
            

            Jon
            

          

          

        

        

      

      

      

    

    

  


--------------AE9DAFD9D099CFA4602571D2--


From nobody Tue Jan 17 17:00:35 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7721B129457 for ; Tue, 17 Jan 2017 17:00:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.401
X-Spam-Level: 
X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63w_klAhLN8y for ; Tue, 17 Jan 2017 17:00:33 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0D7B1293DC for ; Tue, 17 Jan 2017 17:00:32 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id CA388B81B1C; Tue, 17 Jan 2017 17:00:32 -0800 (PST)
To: babiarz@nortel.com, khchan@nortel.com, fred@cisco.com, spencerdawkins.ietf@gmail.com, ietf@kuehlewind.net, gorry@erg.abdn.ac.uk, david.black@emc.com, wes@mti-systems.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Message-Id: <20170118010032.CA388B81B1C@rfc-editor.org>
Date: Tue, 17 Jan 2017 17:00:32 -0800 (PST)
Archived-At: 
Cc: tsvwg@ietf.org, rfc-editor@rfc-editor.org
Subject: [tsvwg] [Editorial Errata Reported] RFC4594 (4910)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Jan 2017 01:00:34 -0000

The following errata report has been submitted for RFC4594,
"Configuration Guidelines for DiffServ Service Classes".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4594&eid=4910

--------------------------------------
Type: Editorial
Reported by: David Black 

Section: 4.8

Original Text
-------------
It can be assumed that this class will consume any available
bandwidth and that packets traversing congested links may
experience higher queuing delays or packet loss.

Corrected Text
--------------
As this class is expected to consist of TCP traffic and
other traffic with a TCP-like response to available bandwidth
and network bottlenecks, it can be assumed that this class
will consume any available bandwidth and that packets
traversing congested links may experience higher queuing
delays or packet loss.


Notes
-----
This errata adds some explanation to a sentence in the description of the High-Throughput Data Service Class.  The original sentence was misread to imply less than best effort service as part of work on WiFi mapping of Diffserv.  That implication is incorrect, e.g., as indicated by the AF1x DSCP marking recommendation.  The added explanation was agreed to with the WiFi Diffserv draft authors as sufficient to avoid any implication that less than best effort service is appropriate for this traffic service class.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4594 (draft-ietf-tsvwg-diffserv-service-classes-02)
--------------------------------------
Title               : Configuration Guidelines for DiffServ Service Classes
Publication Date    : August 2006
Author(s)           : J. Babiarz, K. Chan, F. Baker
Category            : INFORMATIONAL
Source              : Transport Area Working Group
Area                : Transport
Stream              : IETF
Verifying Party     : IESG


From nobody Thu Jan 19 06:22:06 2017
Return-Path: 
X-Original-To: tsvwg@ietf.org
Delivered-To: tsvwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A33129412; Thu, 19 Jan 2017 06:22:01 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148483572102.10461.17601490642338140384.idtracker@ietfa.amsl.com>
Date: Thu, 19 Jan 2017 06:22:01 -0800
Archived-At: 
Cc: Gorry Fairhurst , tsvwg-chairs@ietf.org, tsvwg@ietf.org, The IESG , draft-ietf-tsvwg-diffserv-intercon@ietf.org, rfc-editor@rfc-editor.org
Subject: [tsvwg] Document Action: 'Diffserv-Interconnection classes and practice' to Informational RFC (draft-ietf-tsvwg-diffserv-intercon-14.txt)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Jan 2017 14:22:01 -0000

The IESG has approved the following document:
- 'Diffserv-Interconnection classes and practice'
  (draft-ietf-tsvwg-diffserv-intercon-14.txt) as Informational RFC

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-diffserv-intercon/




Technical Summary

   This document defines a limited common set of Diffserv PHBs and
   codepoints (DSCPs) to be applied at (inter)connections of two
   separately administered and operated networks, and explains how this
   approach can simplify network configuration and operation.  Many
   network providers operate MPLS using Treatment Aggregates for traffic
   marked with different Diffserv PHBs, and use MPLS for interconnection
   with other networks.  This document offers a simple interconnection
   approach that may simplify operation of Diffserv for network
   interconnection among providers that use MPLS and apply the Short-
   Pipe tunnel mode.

Working Group Summary

   The document has received significant feedback from the WG.

   There is strong consensus on the discussed DSCPs.

Document Quality

   This document proceeded in parallel with related ITU-T specification (Y.1566).

Personnel

   Who is the Document Shepherd?  Gorry Fairhurst

  Who is the Responsible Area Director? Spencer Dawkins


From nobody Fri Jan 20 01:17:38 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32CE129ACB; Fri, 20 Jan 2017 01:17:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.401
X-Spam-Level: 
X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMwxeRA5ILgD; Fri, 20 Jan 2017 01:17:29 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 948DB129ABF; Fri, 20 Jan 2017 01:17:29 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 869DFB81B5E; Fri, 20 Jan 2017 01:17:29 -0800 (PST)
To: david.black@dell.com, babiarz@nortel.com, khchan@nortel.com, fred@cisco.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Message-Id: <20170120091729.869DFB81B5E@rfc-editor.org>
Date: Fri, 20 Jan 2017 01:17:29 -0800 (PST)
Archived-At: 
Cc: rfc-editor@rfc-editor.org, ietf@kuehlewind.net, iesg@ietf.org, tsvwg@ietf.org
Subject: [tsvwg] [Errata Verified] RFC4594 (4910)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jan 2017 09:17:31 -0000

The following errata report has been verified for RFC4594,
"Configuration Guidelines for DiffServ Service Classes". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4594&eid=4910

--------------------------------------
Status: Verified
Type: Editorial

Reported by: David Black 
Date Reported: 2017-01-18
Verified by: Mirja Kühlewind (IESG)

Section: 4.8

Original Text
-------------
It can be assumed that this class will consume any available
bandwidth and that packets traversing congested links may
experience higher queuing delays or packet loss.

Corrected Text
--------------
As this class is expected to consist of TCP traffic and
other traffic with a TCP-like response to available bandwidth
and network bottlenecks, it can be assumed that this class
will consume any available bandwidth and that packets
traversing congested links may experience higher queuing
delays or packet loss.


Notes
-----
This errata adds some explanation to a sentence in the description of the High-Throughput Data Service Class.  The original sentence was misread to imply less than best effort service as part of work on WiFi mapping of Diffserv.  That implication is incorrect, e.g., as indicated by the AF1x DSCP marking recommendation.  The added explanation was agreed to with the WiFi Diffserv draft authors as sufficient to avoid any implication that less than best effort service is appropriate for this traffic service class.

--------------------------------------
RFC4594 (draft-ietf-tsvwg-diffserv-service-classes-02)
--------------------------------------
Title               : Configuration Guidelines for DiffServ Service Classes
Publication Date    : August 2006
Author(s)           : J. Babiarz, K. Chan, F. Baker
Category            : INFORMATIONAL
Source              : Transport Area Working Group
Area                : Transport
Stream              : IETF
Verifying Party     : IESG


From nobody Fri Jan 20 08:10:19 2017
Return-Path: 
X-Original-To: tsvwg@ietf.org
Delivered-To: tsvwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 491CB129AB7; Fri, 20 Jan 2017 08:10:17 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Meeting Session Request Tool\"" 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148492861725.13347.2179525669652544511.idtracker@ietfa.amsl.com>
Date: Fri, 20 Jan 2017 08:10:17 -0800
Archived-At: 
Cc: david.black@emc.com, tsvwg@ietf.org, tsvwg-chairs@ietf.org
Subject: [tsvwg] tsvwg - Update to a Meeting Session Request for IETF 98
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Jan 2017 16:10:17 -0000

An update to a meeting session request has just been submitted by David L. Black, a Chair of the tsvwg working group.


---------------------------------------------------------
Working Group Name: Transport Area Working Group
Area Name: Transport Area
Session Requester: David Black

Number of Sessions: 2
Length of Session(s):  1 Hour, 2 Hours
Number of Attendees: 75
Conflicts to Avoid: 
 First Priority: tcpinc quic ippm taps mptcp tcpm rmcat aqm iccrg tsvarea intarea rtgwg opsarea
 Second Priority: dispatch tram v6ops rtcweb dtn
 Third Priority: artarea ccamp


Special Requests:
  [If rtcweb has 2 sessions, 1 should not conflict] 
[Must not conflict with Transport Area BoFs]

---------------------------------------------------------


From nobody Fri Jan 20 16:45:10 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B8A12962B for ; Fri, 20 Jan 2017 16:45:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.221
X-Spam-Level: 
X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=hU9GBx/d; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=sObkX0tX
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mp8UJz3PqzYO for ; Fri, 20 Jan 2017 16:45:06 -0800 (PST)
Received: from esa4.dell-outbound.iphmx.com (esa4.dell-outbound.iphmx.com [68.232.149.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7F30129625 for ; Fri, 20 Jan 2017 16:45:06 -0800 (PST)
DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-originating-ip:Content-Type:Content-Transfer-Encoding: MIME-Version:X-Sentrion-Hostname:X-RSA-Classifications; b=0aUZ9wM3QHHY7P+30x49SmboujljEzTOxlDezjOi4UMWg65EJJ0F158s +dFRJgXUDGk7UsSVRg1jJMH905qE56EZJaHfJ6OO8bLCu9Jl9DfGX3OXo gdbW4s7UVNWB72g/+TKB9+LIRAUUrIs47rAFhNAQSt+8vV6jHXpDOW7+B U=;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1484959506; x=1516495506; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=AoUExtHLNL8yq1r8PCzDAG1KkIGKYldJrWhEKnYUNvY=; b=hU9GBx/dr9s7LOR0+58+q+3me0L3vV3A9zDnAE85WDXRAOiWSdb71AfB kZH/ZoDYOZQgvcjFz1MUOEchnkX+yZwGyOzC4q2ebEhmVJ8leE8l6WBM5 t3ZMIBJZ1uELUGfIjUQTzFmAKAxouUdIKa9Z1pz+H8gi7+qIyRtqhrtp+ w=;
Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jan 2017 18:45:06 -0600
From: "Black, David" 
Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jan 2017 06:45:05 +0600
Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v0L0j4dh006144 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 20 Jan 2017 19:45:04 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com v0L0j4dh006144
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1484959505; bh=MrXJzKKvNhusClPOFzP8kS5kLWA=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=sObkX0tXHYHJCZcqPd/ynYoidr06Ydy90ntKdKfsDBwveQBZ4w7G9y1L0IdHQObbR W+KDvlaJBJ7AFe95m7DS/v6mxFqd18yESKihcMjEkK/Atu0Jo9j1jh7DG7Z31pWWVl Tpt5QTH2R0QwX/JdKpDm412jqelDQ6SFIazCpDmo=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com v0L0j4dh006144
Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd02.lss.emc.com (RSA Interceptor) for ; Fri, 20 Jan 2017 19:44:18 -0500
Received: from MXHUB301.corp.emc.com (MXHUB301.corp.emc.com [10.146.3.27]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v0L0ipUf021259 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL) for ; Fri, 20 Jan 2017 19:44:52 -0500
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB301.corp.emc.com ([10.146.3.27]) with mapi id 14.03.0266.001; Fri, 20 Jan 2017 19:44:51 -0500
To: tsvwg WG 
Thread-Topic: WGLC completion for draft-ietf-tsvwg-ieee-802-11-01 as PS
Thread-Index: AdJzf5I2uDx/mojeR86ji2rMYUJCCQ==
Date: Sat, 21 Jan 2017 00:44:50 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.238.44.108]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com
X-RSA-Classifications: public
Archived-At: 
Subject: [tsvwg] WGLC completion for draft-ietf-tsvwg-ieee-802-11-01 as PS
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Jan 2017 00:45:09 -0000

This email announces the conclusion of the TSVWG WGLC on draft-ietf-tsvwg-i=
eee-802-11-01.

The authors should prepare a revised draft to address the comments from Vin=
cent Roca, David Black and Brian Carpenter - working directly with the comm=
enters is suggested.  Due to the significance of the security and diffserv =
domain/region boundary issues that have been raised, the chairs anticipate =
holding a 2nd WGLC on this draft after it is suitably revised.=20

Thanks, --David, Gorry & Wes (TSVWG chairs)

> -----Original Message-----
> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Gorry Fairhurst
> Sent: Monday, December 12, 2016 12:27 PM
> To: tsvwg WG
> Subject: [tsvwg] WGLC for draft-ietf-tsvwg-ieee-802-11-01 as PS, closes 3=
1 Dec
> 2016
>=20
>=20
> This email announces a TSVWG Working Group Last Call (WGLC) on:
>=20
>                DiffServ to IEEE 802.11 Mapping
>                draft-ietf-tsvwg-ieee-802-11-01
>=20
>   https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11/
>=20
>   This WGLC will last for about 3 weeks weeks (due to the holiday season)=
.
>=20
>   Comments should be sent to the tsvwg@ietf.org list, although purely
>   editorial comments may be sent directly to the authors. Please cc: the
>   WG chairs at tsvwg-chairs@ietf.org  if you would like the chairs to
>   track such editorial comments as part of the WGLC process.
>=20
>   No IPR disclosures have been submitted directly on
>   draft-ietf-tsvwg-ieee-802-11-01
>=20
>   Thanks,
>   Gorry, David and Wes
>   (TSVWG Co-Chairs)
>=20


From nobody Sat Jan 21 00:24:50 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F4112964A for ; Sat, 21 Jan 2017 00:24:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.399
X-Spam-Level: 
X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppgBW-OHXveY for ; Sat, 21 Jan 2017 00:24:46 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9E2129405 for ; Sat, 21 Jan 2017 00:24:46 -0800 (PST)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 09B241B0020A for ; Sat, 21 Jan 2017 10:22:30 +0000 (GMT)
Message-ID: <58831ABF.2060808@erg.abdn.ac.uk>
Date: Sat, 21 Jan 2017 08:24:31 +0000
From: Gorry Fairhurst 
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: tsvwg@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [tsvwg] WGLC completion for draft-ietf-tsvwg-sctp-ndata as PS
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Jan 2017 08:24:49 -0000

This email announces the conclusion of the TSVWG WGLC on draft-ietf-tsvwg-sctp-ndata.

Comments have been received from at least 5 members of the TSVWG list
  - ranging from editorial to questions asking for clarification. There
were also notes saying the spec had been implemented.

The authors are now requested to submit a revised ID to
address the noted issues. The WG will await this updated draft,
hopefully in the next few weeks.

Thanks, -- Gorry, David&  Wes (TSVWG chairs)


From nobody Wed Jan 25 01:15:41 2017
Return-Path: 
X-Original-To: tsvwg@ietf.org
Delivered-To: tsvwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A95A012984C; Wed, 25 Jan 2017 01:15:39 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148533573968.6240.14956923866507677339.idtracker@ietfa.amsl.com>
Date: Wed, 25 Jan 2017 01:15:39 -0800
Archived-At: 
Cc: tsvwg@ietf.org
Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-tunnel-congestion-feedback-04.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Jan 2017 09:15:39 -0000

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           : Tunnel Congestion Feedback
        Authors         : Xinpeng Wei
                          Zhu Lei
                          Lingli Deng
	Filename        : draft-ietf-tsvwg-tunnel-congestion-feedback-04.txt
	Pages           : 18
	Date            : 2017-01-25

Abstract:
   This document describes a method to measure congestion on a tunnel
   segment based on recommendations from RFC 6040, "Tunneling of
   Explicit Congestion Notification", and to use IPFIX to communicate
   the congestion measurements from the tunnel's egress to a controller
   which can respond by modifying the traffic control policies at the
   tunnel's ingress.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-tunnel-congestion-feedback/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tsvwg-tunnel-congestion-feedback-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-tunnel-congestion-feedback-04


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/


From nobody Wed Jan 25 01:23:39 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9E312989D for ; Wed, 25 Jan 2017 01:23:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.42
X-Spam-Level: 
X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7BRzdmxQ-YE for ; Wed, 25 Jan 2017 01:23:36 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1BB212989C for ; Wed, 25 Jan 2017 01:23:35 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFE75871; Wed, 25 Jan 2017 09:23:31 +0000 (GMT)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 25 Jan 2017 09:23:30 +0000
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 25 Jan 2017 17:23:23 +0800
From: "Weixinpeng (Jackie)" 
To: "tsvwg@ietf.org" 
Thread-Topic: New Version Notification for draft-ietf-tsvwg-tunnel-congestion-feedback-04.txt
Thread-Index: AQHSduudYgwADlmS1kK6kjKK3GzLnKFI6YeA
Date: Wed, 25 Jan 2017 09:23:22 +0000
Message-ID: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.76.176]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.58886E94.0186, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: caf0f84422d3557df2734479ad021adb
Archived-At: 
Subject: [tsvwg] FW: New Version Notification for draft-ietf-tsvwg-tunnel-congestion-feedback-04.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Jan 2017 09:23:38 -0000

SGkgYWxsLA0KIEEgbmV3IHZlcnNpb24gb2YgZHJhZnQtaWV0Zi10c3Z3Zy10dW5uZWwtY29uZ2Vz
dGlvbi1mZWVkYmFjayBoYXMgYmVlbiBzdWJtaXR0ZWQuIFRoYW5rcyBKYWtlIEhvbGxhbmQgYW5k
IFZpbmNlbnQgUm9jYSBmb3IgdGhlaXIgc3VnZ2VzdGlvbnMuDQogVGhlIG1haW4gY2hhbmdlcyBp
biB0aGlzIHZlcnNpb24gaXMgYXMgZm9sbG93czoNCiAxLiBEaXJlY3QgZmVlZGJhY2sgbW9kZWwg
YW5kIGNlbnRyYWxpemVkIGZlZWRiYWNrIG1vZGVsIGlzIG1lcmdlZCB0b2dldGhlci4NCiAyLiBB
IG5ldyBleGFtcGxlIHNlY3Rpb24gb2YgaG93IHRoZSBzb2x1dGlvbiBjb3VsZCB3b3JrIGlzIGFk
ZGVkLg0KIDMuIFNldmVyYWwgY2xhcmlmaWNhdGlvbnMgaXMgYWRkZWQuDQogNC4gVGhlIHNlY3Vy
aXR5IENvbnNpZGVyYXRpb24gc2VjdGlvbiBpcyByZXZpc2VkIHdpdGggcHJpdmFjeSBjb25zaWRl
cmF0aW9uLg0KIDUuIElQRklYIEluZm9ybWF0aW9uIEVsZW1lbnQgbmFtZXMgYXJlIHJldmlzZWQu
DQoNClJlZ2FyZHMsDQotWGlucGVuZw0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5G
cm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0
Zi5vcmddDQo+U2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDI1LCAyMDE3IDU6MTYgUE0NCj5Ubzog
Wmh1bGVpIChNQkIgUmVzZWFyY2gpOyBaaHVsZWkgKE1CQiBSZXNlYXJjaCk7IFdlaXhpbnBlbmcg
KEphY2tpZSk7DQo+dHN2d2ctY2hhaXJzQGlldGYub3JnOyBMaW5nbGkgRGVuZw0KPlN1YmplY3Q6
IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj5kcmFmdC1pZXRmLXRzdndnLXR1bm5lbC1j
b25nZXN0aW9uLWZlZWRiYWNrLTA0LnR4dA0KPg0KPg0KPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBk
cmFmdC1pZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRiYWNrLTA0LnR4dA0KPmhhcyBi
ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWGlucGVuZyBXZWkgYW5kIHBvc3RlZCB0byB0
aGUgSUVURg0KPnJlcG9zaXRvcnkuDQo+DQo+TmFtZToJCWRyYWZ0LWlldGYtdHN2d2ctdHVubmVs
LWNvbmdlc3Rpb24tZmVlZGJhY2sNCj5SZXZpc2lvbjoJMDQNCj5UaXRsZToJCVR1bm5lbCBDb25n
ZXN0aW9uIEZlZWRiYWNrDQo+RG9jdW1lbnQgZGF0ZToJMjAxNy0wMS0yNQ0KPkdyb3VwOgkJdHN2
d2cNCj5QYWdlczoJCTE4DQo+VVJMOg0KPmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy
YWZ0cy9kcmFmdC1pZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRiYQ0KPmNrLTA0LnR4
dA0KPlN0YXR1czoNCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm
LXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRiYWNrLw0KPkh0bWxpemVkOg0KPmh0dHBzOi8v
dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZl
ZWRiYWNrLTA0DQo+RGlmZjoNCj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh
ZnQtaWV0Zi10c3Z3Zy10dW5uZWwtY29uZ2VzdGlvbi1mZWVkYmFjay0wDQo+NA0KPg0KPkFic3Ry
YWN0Og0KPiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWV0aG9kIHRvIG1lYXN1cmUgY29u
Z2VzdGlvbiBvbiBhIHR1bm5lbA0KPiAgIHNlZ21lbnQgYmFzZWQgb24gcmVjb21tZW5kYXRpb25z
IGZyb20gUkZDIDYwNDAsICJUdW5uZWxpbmcgb2YNCj4gICBFeHBsaWNpdCBDb25nZXN0aW9uIE5v
dGlmaWNhdGlvbiIsIGFuZCB0byB1c2UgSVBGSVggdG8gY29tbXVuaWNhdGUNCj4gICB0aGUgY29u
Z2VzdGlvbiBtZWFzdXJlbWVudHMgZnJvbSB0aGUgdHVubmVsJ3MgZWdyZXNzIHRvIGEgY29udHJv
bGxlcg0KPiAgIHdoaWNoIGNhbiByZXNwb25kIGJ5IG1vZGlmeWluZyB0aGUgdHJhZmZpYyBjb250
cm9sIHBvbGljaWVzIGF0IHRoZQ0KPiAgIHR1bm5lbCdzIGluZ3Jlc3MuDQo+DQo+DQo+DQo+DQo+
UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl
IHRpbWUgb2Ygc3VibWlzc2lvbg0KPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm
IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+DQo+VGhlIElFVEYgU2VjcmV0YXJp
YXQNCg0K


From nobody Fri Jan 27 01:13:45 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26FBF129485 for ; Fri, 27 Jan 2017 01:13:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.42
X-Spam-Level: 
X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMrTwNs8jk_I for ; Fri, 27 Jan 2017 01:13:41 -0800 (PST)
Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7067D129484 for ; Fri, 27 Jan 2017 01:13:40 -0800 (PST)
Received: from jsaldanalaptop (jsaldanalaptop.guest.tno.nl [139.63.185.42]) (authenticated bits=0) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id v0R9DamK020107 for ; Fri, 27 Jan 2017 10:13:37 +0100
From: "Jose Saldana" 
To: 
References: <148550731938.12166.6481903769933225526.idtracker@ietfa.amsl.com>
In-Reply-To: <148550731938.12166.6481903769933225526.idtracker@ietfa.amsl.com>
Date: Fri, 27 Jan 2017 10:13:45 +0100
Message-ID: <003601d2787d$a9b65670$fd230350$@unizar.es>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKAFx8JO259b9Q7lhVG+37TGdIT25/wzNVQ
Content-Language: es
X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter
Archived-At: 
Subject: [tsvwg] RV: New Version Notification for draft-saldana-tsvwg-simplemux-06.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2017 09:13:44 -0000

> -----Mensaje original-----
> De: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Enviado el: viernes, 27 de enero de 2017 9:55
> Para: Jose Saldana 
> Asunto: New Version Notification for =
draft-saldana-tsvwg-simplemux-06.txt
>=20
>=20
> A new version of I-D, draft-saldana-tsvwg-simplemux-06.txt
> has been successfully submitted by Jose Saldana and posted to the IETF
> repository.
>=20
> Name:		draft-saldana-tsvwg-simplemux
> Revision:	06
> Title:		Simplemux. A generic multiplexing protocol
> Document date:	2017-01-27
> Group:		Individual Submission
> Pages:		14
> URL:            =
https://www.ietf.org/internet-drafts/draft-saldana-tsvwg-
> simplemux-06.txt
> Status:         =
https://datatracker.ietf.org/doc/draft-saldana-tsvwg-simplemux/
> Htmlized:       =
https://tools.ietf.org/html/draft-saldana-tsvwg-simplemux-06
> Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-saldana-tsvwg-simplemux-
> 06
>=20
> Abstract:
>    The high amount of small packets present in nowaday's networks
>    results in a low efficiency, as the size of the headers and the
>    payload of these packets can be in the same order of magnitude.  In
>    some situations, multiplexing a number of small packets into a =
bigger
>    one is desirable in order to improve the efficiency.  For example, =
a
>    number of small packets can be sent together between a pair of
>    machines if they share a common network path.  Thus, the traffic
>    profile can be shifted from small to larger packets, reducing the
>    network overhead and the number of packets per second to be managed
>    by intermediate routers.
>=20
>    This document describes Simplemux, a protocol able to encapsulate a
>    number of packets belonging to different protocols into a single
>    packet.  Small headers (separators) are added at the beginning of
>    each multiplexed packet, including some flags, the packet length =
and
>    a "Protocol" field.  This allows the inclusion of a number of =
packets
>    belonging to different protocols (the "multiplexed packets") on a
>    packet of another protocol (the "tunneling protocol").
>=20
>    In order to reduce the overhead, the size of the multiplexing =
headers
>    is kept very low (it may be a single byte when multiplexing small
>    packets).
>=20
>=20
>=20
>=20
> 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.
>=20
> The IETF Secretariat



From nobody Fri Jan 27 13:18:41 2017
Return-Path: 
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53426129964 for ; Fri, 27 Jan 2017 13:18:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=udel-edu.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbeRMOKd7yxO for ; Fri, 27 Jan 2017 13:18:39 -0800 (PST)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E4981298C1 for ; Fri, 27 Jan 2017 13:18:39 -0800 (PST)
Received: by mail-qt0-x232.google.com with SMTP id k15so157482638qtg.3 for ; Fri, 27 Jan 2017 13:18:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udel-edu.20150623.gappssmtp.com; s=20150623; h=subject:references:cc:to:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=U49hrIs8R/+DtWsSsoZTp3tj+u7GZOTSH7EdTWcRCCU=; b=sehdAlNTIOxHArjoXeELgP7Z7NTW2xaP7gsPsd8O2PZ1cQTaJ3adUV9n6wVy6zt/V/ UpHnbxHNpMzaMJKCNAL3dBfhNSHxW7iI5ydVBABdSYyUlCMLicZ/GAb8IMO67II0pZG5 tOxADJRZmpl7rDDxON8LCvkg1P4Cf8N6ii/PTOMs0PI0enKV2plY3916QJ158iJ04xsH 7d6W0k9IvdCoquVSjSBaECsGN030hdc+g6j9XvproVotWjOTtmN/GIwwjE/Dl86Lh0Zw 1kUPpYeg5XBXZnbX6Jq6xmRo2jDLLobaNLXsu63L+vcsEJm3+0aQHBUxynyjLO6415+T Npcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:cc:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=U49hrIs8R/+DtWsSsoZTp3tj+u7GZOTSH7EdTWcRCCU=; b=FxDkZbbj3X1Orzq/n37EJfkGKW00mYynixwAkxt/MWxuihNuO9SKZGqmmvNhV8bTPC XNqGxjA3Wn2UOTFJ16cyBs9KWfI2us2lKfXYK4ocUb8RywQFUJmTWFxbSokCo9kHuioP LBXOcdnoG76TEJWYyk2q2GpGCmyT5QUcvb44/00ALmWeHakTvvULI40eu9N2Gd+P0BYx qNyKcdo4IRDTp2Z6nDncwULlG0K4HBpEZtUFxjfop8smw8SJSP2f5kVHwexMJEzxcgc3 jDmpyE3JIIaOAQi607vpqISlVfYINYlTPbd7dWw8f+nsY3horEByGITqOpfx+fsYyac4 gHaQ==
X-Gm-Message-State: AIkVDXKRuOHPJkvA20hdJ+O61xuID9tnb2dRSKJ08mfF3hLOUmaq1rq065PzRm8888yLdPlt
X-Received: by 10.237.36.166 with SMTP id t35mr9871310qtc.172.1485551918076; Fri, 27 Jan 2017 13:18:38 -0800 (PST)
Received: from iMac-27.local ([2601:183:4102:810d:3523:1d8f:20a9:4714]) by smtp.gmail.com with ESMTPSA id o99sm5144581qko.12.2017.01.27.13.18.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Jan 2017 13:18:37 -0800 (PST)
References: <98348439-7bb7-a37b-7933-db39ae334ba5@udel.edu> <5fe2fc97-8188-c3cc-d009-d09bc9f47640@udel.edu> <31CDAF39-DC53-4DF9-B6AD-73304181A515@lurchi.franken.de> <587C8A7C.20104@oracle.com>
To: tsvwg WG 
From: "Jonathan T. Leighton" 
Message-ID: 
Date: Fri, 27 Jan 2017 16:18:36 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <587C8A7C.20104@oracle.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: Ka-Cheong Poon , Vlad Yasevich , Michael Tuexen 
Subject: Re: [tsvwg] Proposed errata for RFC 6458 sctp_bindx
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2017 21:18:40 -0000

On 1/16/17 3:55 AM, Ka-Cheong Poon wrote:
> On 01/13/17 04:00 AM, Michael Tuexen wrote:
>>> On 12 Jan 2017, at 18:36, Jonathan T. Leighton  
>>> wrote:
>>>
>>> Hi Michael -
>>>
>>> I posted this to tsvwg@ietf.org on 1/4/17, but it's been over a week 
>>> now and I haven't had any response. I can try posting it again, or I 
>>> can submit an errata and see how the authors respond. Do you have a 
>>> suggestion about how best to proceed?
>> I CC'ed some individuals... Given them a couple of days.
>> Then file an errata if you want.
>>
>> I'm find with the text suggested by you.
>
>
> The changes look fine to me too.  Thanks.

If there are no more comments, I will submit at errata.

- Jon

>>> On 1/4/17 1:12 PM, Jonathan T. Leighton wrote:
>>>> I've been discussing a possible errata for the sctp_bindx() 
>>>> description in RFC 6458 with Michael Tuexen, and he suggested 
>>>> posting the issue here for further comment. The current language is 
>>>> vague regarding passing IPv4 addresses versus IPv4-mapped IPv6 
>>>> addresses, as well as required versus allowed behavior. I've been 
>>>> advised that there is some disagreement about whether or not the 
>>>> term "IPv4 address" includes IPv4-mapped IPv6 address, so the 
>>>> proposed text attempts to avoid that issue.
>>>>
>>>> OLD TEXT:
>>>> If sd is an IPv4 socket, the addresses passed must be IPv4 addresses.
>>>> If the sd is an IPv6 socket, the addresses passed can either be IPv4
>>>> or IPv6 addresses.
>>>> NEW TEXT:
>>>> If sd is an IPv4 socket, the passed addresses must be stored in
>>>> sockaddr_in structures. If sd is an IPv6 socket, the passed addresses
>>>> typically must be stored in sockaddr_in6 structures, however some
>>>> implementations may also allow addresses to be stored in sockaddr_in
>>>> structures. For implementations that require addresses to be stored
>>>> in sockaddr_in6 structures, use IPv4-mapped IPv6 addresses to bind
>>>> the socket to the corresponding IPv4 addresses.
>>>>
>>>>
>>>> Best regards
>>>> Jon
>>>
>>
>
>