From wwwrun@rfc-editor.org Sat Dec 1 15:50:45 2012 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 AE15D21E80CE for ; Sat, 1 Dec 2012 15:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.283 X-Spam-Level: X-Spam-Status: No, score=-102.283 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGZBz-7YX1rC for ; Sat, 1 Dec 2012 15:50:45 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 3940C21E80B7 for ; Sat, 1 Dec 2012 15:50:45 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id BF442B1E002; Sat, 1 Dec 2012 15:42:42 -0800 (PST) To: randall@lakerest.net, wes@mti-systems.com, martin.stiemerling@neclab.eu, gorry@erg.abdn.ac.uk, jmpolk@cisco.com, black_david@emc.com From: RFC Errata System Message-Id: <20121201234242.BF442B1E002@rfc-editor.org> Date: Sat, 1 Dec 2012 15:42:42 -0800 (PST) Cc: epontan@gmail.com, tsvwg@ietf.org, rfc-editor@rfc-editor.org Subject: [tsvwg] [Technical Errata Reported] RFC4960 (3423) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 23:50:45 -0000 The following errata report has been submitted for RFC4960, "Stream Control Transmission Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4960&eid=3423 -------------------------------------- Type: Technical Reported by: Pontus Andersson Section: B Original Text ------------- unsigned long generate_crc32c(unsigned char *buffer, unsigned int length) { unsigned int i; unsigned long crc32 = ~0L; Corrected Text -------------- unsigned long generate_crc32c(unsigned char *buffer, unsigned int length) { unsigned int i; unsigned long crc32 = 0xffffffffL; Notes ----- The remainder register (crc32) should be initialized to 0xffffffffL rather than ~0L, for correct operation on platforms where unisigned long is longer than 32 bits. I.e., 64-bit platforms. Instructions: ------------- This errata 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 (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4960 (draft-ietf-tsvwg-2960bis-05) -------------------------------------- Title : Stream Control Transmission Protocol Publication Date : September 2007 Author(s) : R. Stewart, Ed. Category : PROPOSED STANDARD Source : Transport Area Working Group Area : Transport Stream : IETF Verifying Party : IESG From Michael.Tuexen@lurchi.franken.de Sun Dec 2 01:22:46 2012 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 1271921F890C for ; Sun, 2 Dec 2012 01:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gh-ZpvGfXcTl for ; Sun, 2 Dec 2012 01:22:45 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id E932121F8908 for ; Sun, 2 Dec 2012 01:22:44 -0800 (PST) Received: from [192.168.1.103] (p5481AB02.dip.t-dialin.net [84.129.171.2]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 57A731C0C0BF4; Sun, 2 Dec 2012 10:22:43 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <20121201234242.BF442B1E002@rfc-editor.org> Date: Sun, 2 Dec 2012 10:22:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121201234242.BF442B1E002@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1283) Cc: gorry@erg.abdn.ac.uk, epontan@gmail.com, tsvwg@ietf.org, randall@lakerest.net, jmpolk@cisco.com, black_david@emc.com Subject: Re: [tsvwg] [Technical Errata Reported] RFC4960 (3423) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 09:22:46 -0000 On Dec 2, 2012, at 12:42 AM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC4960, > "Stream Control Transmission Protocol". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4960&eid=3D3423 >=20 > -------------------------------------- > Type: Technical > Reported by: Pontus Andersson >=20 > Section: B >=20 > Original Text > ------------- > unsigned long > generate_crc32c(unsigned char *buffer, unsigned int length) > { > unsigned int i; > unsigned long crc32 =3D ~0L; >=20 > Corrected Text > -------------- > unsigned long > generate_crc32c(unsigned char *buffer, unsigned int length) > { > unsigned int i; > unsigned long crc32 =3D 0xffffffffL; I would actually prefer to make use of uint32_t as the type of crc32. At = least this is what we do in the FreeBSD implementation and that runs fine on all = architectures. Best regards Michael >=20 > Notes > ----- > The remainder register (crc32) should be initialized to 0xffffffffL = rather than ~0L, for correct operation on platforms where unisigned long = is longer than 32 bits. I.e., 64-bit platforms. >=20 > Instructions: > ------------- > This errata 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 (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC4960 (draft-ietf-tsvwg-2960bis-05) > -------------------------------------- > Title : Stream Control Transmission Protocol > Publication Date : September 2007 > Author(s) : R. Stewart, Ed. > Category : PROPOSED STANDARD > Source : Transport Area Working Group > Area : Transport > Stream : IETF > Verifying Party : IESG >=20 From bob.briscoe@bt.com Thu Dec 6 15:56:31 2012 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 54BE321F86D8 for ; Thu, 6 Dec 2012 15:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.38 X-Spam-Level: X-Spam-Status: No, score=-3.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3H7PYcGDs3HO for ; Thu, 6 Dec 2012 15:56:30 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 1926921F86AD for ; Thu, 6 Dec 2012 15:56:30 -0800 (PST) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 6 Dec 2012 23:56:28 +0000 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 6 Dec 2012 23:56:27 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.318.4; Thu, 6 Dec 2012 23:56:26 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.0.95]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qB6NuNSO031176; Thu, 6 Dec 2012 23:56:24 GMT Message-ID: <201212062356.qB6NuNSO031176@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 6 Dec 2012 23:56:22 +0000 To: Joe Touch From: Bob Briscoe In-Reply-To: <4FCD4E0F.2080100@isi.edu> References: <20120601063417.29442.54679.idtracker@ietfa.amsl.com> <4FCD4E0F.2080100@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: tsvwg@ietf.org Subject: [tsvwg] draft-ietf-tsvwg-port-use-00 abolish system/user distinction? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 23:56:31 -0000 Joe, Can you write down your rationale for removing the distinction between system & user ports? I don't see why ceasing to allocate system ports will help. It's not clear whether you are trying to remove the false sense of security that system ports purport to offer, or whether you are trying to remove the higher bar to IANA allocation, both, neither, or what. There's too little written in the draft, on the list and around the bullets in your presentation of the draft to guess fully what you're driving at. Not a criticism - we all have limited time to write what splurges out of our minds - I'm just trying to understand. Cheers Bob At 00:08 05/06/2012, Joe Touch wrote: > - whether to deprecate the distinction between system and > user ports (or to do nothing at this time) At 18:30 30/01/2012, Joe Touch wrote: > - discuss and/or make a recommendation about whether to > continue the system/user port space distinction > (IMO, the only useful way to do this is to suggest > that IANA cease allocating system ports) ________________________________________________________________ Bob Briscoe, BT Innovate & Design From lear@cisco.com Thu Dec 6 21:40:09 2012 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 45ADA11E80D2 for ; Thu, 6 Dec 2012 21:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.456 X-Spam-Level: X-Spam-Status: No, score=-110.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8us4j4j+qUs for ; Thu, 6 Dec 2012 21:40:08 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5F421F86E2 for ; Thu, 6 Dec 2012 21:40:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=816; q=dns/txt; s=iport; t=1354858808; x=1356068408; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=tYXjh+4SoWkMDahUf/n3nnObg8PBt0BDwwI6/4u5Ftg=; b=AD+gqUZuckPWcheCV2LhorM9nLGvVenDx50XEBVbxrSeevWXgj7pmZ8a y/6VpQ+q4aEom0uuDexi5ySjVYNXbtWXfRudpN51LT7oJdub4KTCr/ZyR OZ5hSOhxD6jrhQhYwyiZ5l+KnhFXBkfAu0UVHeLSJ6pAVB1xx3WrtCcSo E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsHAACBwVCQ/khM/2dsb2JhbABEg0eCbrd/FnOCHgEBAQQjVQEQCxgCAgUWCwICCQMCAQIBRQYNAQcBAYgMsC+SXYEijk2BEwOWA5BHgnQ X-IronPort-AV: E=McAfee;i="5400,1158,6918"; a="78880981" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 07 Dec 2012 05:40:07 +0000 Received: from dhcp-10-55-81-119.cisco.com (dhcp-10-55-81-119.cisco.com [10.55.81.119]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qB75e6xh013082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Dec 2012 05:40:06 GMT Message-ID: <50C18136.1030108@cisco.com> Date: Fri, 07 Dec 2012 06:40:06 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Bob Briscoe References: <20120601063417.29442.54679.idtracker@ietfa.amsl.com> <4FCD4E0F.2080100@isi.edu> <201212062356.qB6NuNSO031176@bagheera.jungle.bt.co.uk> In-Reply-To: <201212062356.qB6NuNSO031176@bagheera.jungle.bt.co.uk> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org, Joe Touch Subject: Re: [tsvwg] draft-ietf-tsvwg-port-use-00 abolish system/user distinction? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 05:40:09 -0000 On 12/7/12 12:56 AM, Bob Briscoe wrote: > I don't see why ceasing to allocate system ports will help. It's not > clear whether you are trying to remove the false sense of security > that system ports purport to offer, or whether you are trying to > remove the higher bar to IANA allocation, both, neither, or what. > There's too little written in the draft, on the list and around the > bullets in your presentation of the draft to guess fully what you're > driving at. I support the notion of combining system and user for the simple reason that there is no technical difference between the two, there is no meaningful additional security offered by system. The distinction dates back to the notion that non-privileged users couldn't open a port below 1024 and we knew all Internet hosts by name. From bob.briscoe@bt.com Fri Dec 7 02:46:01 2012 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 AD49921F86F9 for ; Fri, 7 Dec 2012 02:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.411 X-Spam-Level: X-Spam-Status: No, score=-3.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-soDKqy2Lhj for ; Fri, 7 Dec 2012 02:46:01 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id A2A5921F882F for ; Fri, 7 Dec 2012 02:46:00 -0800 (PST) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 7 Dec 2012 10:45:51 +0000 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 7 Dec 2012 10:45:50 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.318.4; Fri, 7 Dec 2012 10:45:49 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qB7AjlvX000503; Fri, 7 Dec 2012 10:45:47 GMT Message-ID: <201212071045.qB7AjlvX000503@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 7 Dec 2012 10:45:49 +0000 To: Eliot Lear From: Bob Briscoe In-Reply-To: <50C18136.1030108@cisco.com> References: <20120601063417.29442.54679.idtracker@ietfa.amsl.com> <4FCD4E0F.2080100@isi.edu> <201212062356.qB6NuNSO031176@bagheera.jungle.bt.co.uk> <50C18136.1030108@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: tsvwg@ietf.org, Joe Touch Subject: Re: [tsvwg] draft-ietf-tsvwg-port-use-00 abolish system/user distinction? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 10:46:01 -0000 Elliot, I'm not saying I don't support removing the distinction in meaning (for the false sense of security reasons). I'm just saying there's nothing written about why it helps to achieve this if IANA no longer allocate ports under 1024. I can't work out the reasoning for this, but I'm sure Joe has got one. What's written so far doesn't help anyone understand unless they already understand. Bob At 05:40 07/12/2012, Eliot Lear wrote: >On 12/7/12 12:56 AM, Bob Briscoe wrote: > > I don't see why ceasing to allocate system ports will help. It's not > > clear whether you are trying to remove the false sense of security > > that system ports purport to offer, or whether you are trying to > > remove the higher bar to IANA allocation, both, neither, or what. > > There's too little written in the draft, on the list and around the > > bullets in your presentation of the draft to guess fully what you're > > driving at. > >I support the notion of combining system and user for the simple reason >that there is no technical difference between the two, there is no >meaningful additional security offered by system. The distinction dates >back to the notion that non-privileged users couldn't open a port below >1024 and we knew all Internet hosts by name. ________________________________________________________________ Bob Briscoe, BT Innovate & Design From touch@isi.edu Fri Dec 7 11:09:16 2012 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 02C0D21F8742 for ; Fri, 7 Dec 2012 11:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.154 X-Spam-Level: X-Spam-Status: No, score=-103.154 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsFFQgiWFXTW for ; Fri, 7 Dec 2012 11:09:15 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 75E2221F873C for ; Fri, 7 Dec 2012 11:09:15 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id qB7J8pfV002677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Dec 2012 11:08:53 -0800 (PST) Message-ID: <50C23EC3.5060704@isi.edu> Date: Fri, 07 Dec 2012 11:08:51 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Eliot Lear References: <20120601063417.29442.54679.idtracker@ietfa.amsl.com> <4FCD4E0F.2080100@isi.edu> <201212062356.qB6NuNSO031176@bagheera.jungle.bt.co.uk> <50C18136.1030108@cisco.com> In-Reply-To: <50C18136.1030108@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg@ietf.org Subject: Re: [tsvwg] draft-ietf-tsvwg-port-use-00 abolish system/user distinction? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 19:09:16 -0000 Hi, Bob, Eliot, et al., On 12/6/2012 9:40 PM, Eliot Lear wrote: > > On 12/7/12 12:56 AM, Bob Briscoe wrote: >> I don't see why ceasing to allocate system ports will help. It's not >> clear whether you are trying to remove the false sense of security >> that system ports purport to offer, or whether you are trying to >> remove the higher bar to IANA allocation, both, neither, or what. >> There's too little written in the draft, on the list and around the >> bullets in your presentation of the draft to guess fully what you're >> driving at. > > I support the notion of combining system and user for the simple reason > that there is no technical difference between the two, there is no > meaningful additional security offered by system. The distinction dates > back to the notion that non-privileged users couldn't open a port below > 1024 and we knew all Internet hosts by name. This was discussed at several IETFs before this doc was accepted as a WG item, so I thought there was context. The doc does need expanding on this, and I will do so in the next revision. My view is that: - the distinction has evolved to become meaningless, and thus treating any port as more trusted because of its assigned range is a bad idea (as Eliot points out above). Yes, there are plenty of systems that do continue to treat the two ranges as different, but enough others that don't that it seems a bad idea to continue to support the difference as meaningful. Which is why I propose the following as an overall goal: The range 0...49151 will be known as Assigned ports. Port assignments will no longer distinguish between 'user', 'system', 'well-known', and 'registered' subranges of Assigned ports. If we do deprecate the difference between the ranges, we need to decide how to move forward. First, regardless of how we move forward, IMO: Assigned ports should use the procedures from RFC 2780 that apply to User ports. There are two ways forward, given that goal (in the order of my preference): a) this document can officially deprecate the distinction between User and System ports by declaring that IANA should cease further assignments from the System range b) this document can suggest that users should not bother requesting system ports c) this document can officially deprecate the distinction between User and System ports by merging the two and letting users pick any available port from the Assigned range Of these options, I think (c) creates a "land rush" in the System space, and we don't have enough understanding of the impact on legacy protocols. (a) is the safest, since it merely requires that new services be designed in a way that assumes that they could be run by any user on any system - which, these days, seems like a reasonable recommendation. (b) is a way to circumvent the issue without deprecating the User/System distinction, and IMO just continues to ignore the current situation Thoughts? Joe From preethi.cis@gmail.com Mon Dec 10 14:16:00 2012 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 BFA9321F867D for ; Mon, 10 Dec 2012 14:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRU31+ohnWiu for ; Mon, 10 Dec 2012 14:16:00 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 342EB21F8674 for ; Mon, 10 Dec 2012 14:16:00 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so2266937pad.31 for ; Mon, 10 Dec 2012 14:16:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=IHDClOyjVFbHEY8RokPR6r2TB14eAyC99edS7KpBCko=; b=ylCqVOlV4n4fCpRHXf1MLycnDly8Gbmf9q6/oRTjOBuiDmYAgSrctk7pw+QtjTGjlN DnX45FtnusbIfFQ2dHWZuF9C8ULmEFpChqtrt5XA4EfLZcawdk0CC1uI/idkO/iusalX ug8rI5zYWqthWyQ1tFJLom1RT5Xrr5N7vpbhO8kxgPqM9CuncR3YJ5yfA2yAhgSziJyD GjVzXt7CvtQa7Y8elspS/QmBds8OxxJ64XT+pfFe5LjeQYsLKnQF8KY+qi4bGKUdUix2 vR9KJIP2wDTwsINp57W+26M5j4CRtHkr66w/SL05oEA8jQWx8UUIbVCdLYHi/WO1G5SA BqqA== Received: by 10.68.241.65 with SMTP id wg1mr22055323pbc.141.1355177759950; Mon, 10 Dec 2012 14:15:59 -0800 (PST) Received: from [10.33.22.105] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id s5sm8960024pay.31.2012.12.10.14.15.54 (version=SSLv3 cipher=OTHER); Mon, 10 Dec 2012 14:15:58 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.2.1.120420 Date: Mon, 10 Dec 2012 14:15:44 -0800 From: Preethi Natarajan To: Message-ID: Thread-Topic: New Version Notification for draft-pan-tsvwg-pie-00.txt In-Reply-To: <20121210191516.13359.45286.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "Chiara Piglione \(cpiglion\)" , "Bill Ver Steeg \(versteb\)" , "Fred Baker \(fred\)" , "Vijay Subramanian \(vijaynsu\)" , "Rong Pan \(ropan\)" , "Mythili Suryanarayana Prabhu \(mysuryan\)" , Preethi Natarajan Subject: [tsvwg] FW: New Version Notification for draft-pan-tsvwg-pie-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 22:16:00 -0000 Hi all, We've submitted a new draft discussing PIE (Proportional Integral controller Enhanced) AQM scheme. Please find the draft URL and submission details below. We are working with Cisco's legal team to have the PIE pseudo-code and implementations (ns-2, Linux) publicly available. We should have a pointer to these items in couple of weeks. Best, Preethi (on behalf of all authors). On 12/10/12 11:15 AM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-pan-tsvwg-pie-00.txt >has been successfully submitted by Rong Pan and posted to the >IETF repository. > >Filename: draft-pan-tsvwg-pie >Revision: 00 >Title: PIE: A Lightweight Control Scheme To Address the Bufferbloat >Problem >Creation date: 2012-12-10 >WG ID: Individual Submission >Number of pages: 12 >URL: >http://www.ietf.org/internet-drafts/draft-pan-tsvwg-pie-00.txt >Status: http://datatracker.ietf.org/doc/draft-pan-tsvwg-pie >Htmlized: http://tools.ietf.org/html/draft-pan-tsvwg-pie-00 > > >Abstract: > Bufferbloat is a phenomenon where excess buffers in the network cause > high latency and jitter. As more and more interactive applications > (e.g. voice over IP, real time video streaming and financial > transactions) run in the Internet, high latency and jitter degrade > application performance. There is a pressing need to design > intelligent queue management schemes that can control latency and > jitter; and hence provide desirable quality of service to users. > > We present here a lightweight design, PIE(Proportional Integral > controller Enhanced) that can effectively control the average > queueing latency to a target value. Simulation results, theoretical > analysis and Linux testbed results have shown that PIE can ensure low > latency and achieve high link utilization under various congestion > situations. The design does not require per-packet timestamp, so it > incurs very small overhead and is simple enough to implement in both > hardware and software. > > > > > >The IETF Secretariat > From gorry@erg.abdn.ac.uk Wed Dec 12 00:09:09 2012 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 6459F21F8727 for ; Wed, 12 Dec 2012 00:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.41 X-Spam-Level: X-Spam-Status: No, score=-102.41 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7sNR0Sl3lGp for ; Wed, 12 Dec 2012 00:09:09 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id C599521F86D6 for ; Wed, 12 Dec 2012 00:09:08 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 1A2672B4400 for ; Wed, 12 Dec 2012 08:09:07 +0000 (GMT) Received: from 195.101.98.59 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Wed, 12 Dec 2012 08:09:07 -0000 Message-ID: <2ed2b5b7450dd48db03b766f3533c674.squirrel@www.erg.abdn.ac.uk> Date: Wed, 12 Dec 2012 08:09:07 -0000 From: gorry@erg.abdn.ac.uk To: tsvwg@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [tsvwg] TSVWG Working Group Last Call: draft-ietf-6man-udpzero X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 08:09:09 -0000 This message starts a two week TSVWG Working Group on advancing: Title : Applicability Statement for the use of IPv6 UDP Datagrams with Zero Checksums Author(s) : Godred Fairhurst Magnus Westerlund Filename : draft-ietf-6man-udpzero-08.txt Pages : 37 Date : 2012-12-11 https://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/ This document is intended to be published as BCP via the 6MAN WG. This last call is being done given the number of changes and the time since the earlier last calls. The changes were discussed at the Atlanta IETF 6man & TSVWG sessions. The authors believe these changes will resolve the open IESG Discusses. Our AD will start a concurrent IETF last call as well. Substantive comments and statements of support for advancing this document should be directed to the tsvwg or 6man mailing list. Editorial suggestions can be sent to the authors. This last call will end on 26 December 2012. James, David & Gorry TSVWG Co-Chairs. From Mirko.Suznjevic@fer.hr Thu Dec 13 01:06:57 2012 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 89ACF21F8A5A; Thu, 13 Dec 2012 01:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EH0SZdnk+Y46; Thu, 13 Dec 2012 01:06:57 -0800 (PST) Received: from mail.zvne.fer.hr (mail.zvne.fer.hr [161.53.66.5]) by ietfa.amsl.com (Postfix) with ESMTP id 94A8221F8A56; Thu, 13 Dec 2012 01:06:55 -0800 (PST) Received: from munja.zvne.fer.hr (161.53.66.248) by mail.zvne.fer.hr (161.53.66.5) with Microsoft SMTP Server id 14.2.318.4; Thu, 13 Dec 2012 10:06:38 +0100 Received: from sluga.fer.hr ([161.53.66.244]) by munja.zvne.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Dec 2012 10:06:38 +0100 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDD911.289A6CC1" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 13 Dec 2012 10:06:41 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows Thread-Index: Ac3ZESqLi+BkjcfHSsa59QiO7XqseQ== From: =?iso-8859-2?Q?Mirko_Su=BEnjevi=E6?= To: , X-OriginalArrivalTime: 13 Dec 2012 09:06:38.0579 (UTC) FILETIME=[28CCBC30:01CDD911] Subject: [tsvwg] Draft: Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 09:06:57 -0000 ------_=_NextPart_001_01CDD911.289A6CC1 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hello, =20 We have just submitted the draft named Maximum Tolerable Delays when = using Tunneling Compressed Multiplexed Traffic Flows: = http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/ =20 It is an extension of tcmtf = http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/. Since a = specific list for tcmtf exists (tcmtf@ietf.org), the idea is to discuss = it there. =20 The draft contains recommendations for TCMTF multiplexing period for = different real-time services. In order to prevent QoE degradation of = real-time services using TCMTF, a policy defining a multiplexing period = can be employed. Values of maximum tolerable delays presented in the = draft form the base of such policy. The recommendations are presented = for real-time network services in which TCTMF bandwidth optimization is = applicable (i.e., services which have low payload to header size ratio = which results in high protocol overhead). =20 Your feedback will be welcome. Thank you. Sincerely, Mirko Suznjevic ------_=_NextPart_001_01CDD911.289A6CC1 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hello,

 

We have just submitted the draft named Maximum Tolerable = Delays when using Tunneling Compressed Multiplexed Traffic Flows: = http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/

 

It is an extension of tcmtf = http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/. Since a = specific list for tcmtf exists (tcmtf@ietf.org), the idea is to discuss = it there.

 

The draft contains recommendations for TCMTF multiplexing = period for different real-time services. In order to prevent QoE = degradation of real-time services using TCMTF, a policy defining=A0 a = multiplexing period can be employed. Values of maximum tolerable delays = presented in the draft form the base of such policy.=A0=A0=A0 The = recommendations are presented for real-time network services in which = TCTMF bandwidth optimization is applicable (i.e., services=A0 which have = low payload to header size ratio which results in high protocol = overhead).

 

Your feedback will be welcome. Thank = you.


Sincerely,

Mirko = Suznjevic

------_=_NextPart_001_01CDD911.289A6CC1-- From magnus.westerlund@ericsson.com Thu Dec 13 01:20:15 2012 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 77D6621F86DC for ; Thu, 13 Dec 2012 01:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.078 X-Spam-Level: X-Spam-Status: No, score=-106.078 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 719Pmck84U2Q for ; Thu, 13 Dec 2012 01:20:12 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0A621F855D for ; Thu, 13 Dec 2012 01:20:11 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-36-50c99dc9d1be Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 57.45.24873.9CD99C05; Thu, 13 Dec 2012 10:20:09 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Thu, 13 Dec 2012 10:20:09 +0100 Message-ID: <50C99DC8.7060505@ericsson.com> Date: Thu, 13 Dec 2012 10:20:08 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk References: <2ed2b5b7450dd48db03b766f3533c674.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <2ed2b5b7450dd48db03b766f3533c674.squirrel@www.erg.abdn.ac.uk> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3Rvfk3JMBBp+vqVq8bpvNaHHszV02 ByaPns8vmDyWLPnJFMAUxWWTkpqTWZZapG+XwJUxt+ULY0GTbMXmhT/YGxhPiXUxcnBICJhI /L+c2cXICWSKSVy4t56ti5GLQ0jgJKPErcXbmEESQgLLGSU2rM4CsXkFtCUad95iBbFZBFQl Nm3dwQhiswlYSNz80cgGYosK+ErM2vOLCaJeUOLkzCcsILaIgITEnA+rwWxmASGJN9sXgtUI C3hLdM65zwKxy0vi+tK9YPM5geL79raxQhwnKbFoWidUr57ElKstjBC2vETz1tlQd2pLNDR1 sE5gFJqFZPUsJC2zkLQsYGRexciem5iZk15utIkRGKgHt/xW3cF455zIIUZpDhYlcV7rrXv8 hQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTAmfNrxISY/yfvyElXTnj11nO+D18+QaU72E94o +9bkk/9m8UXBXJwrYucHK+uIBW7m+OmSceZzVkH6v2cyKovyl3AtFJ8pyBjTuVUu/Yn0rgd/ PLqFal3WKSXdbV5ZvmjJ8udBDfqmzmGmDRKV1pyzlgtO+B2wXWl5p/yRO0y6TE4HP6778UeJ pTgj0VCLuag4EQBDSQvzIgIAAA== Cc: tsvwg@ietf.org Subject: Re: [tsvwg] TSVWG Working Group Last Call: draft-ietf-6man-udpzero X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 09:20:15 -0000 Hi, I do hope we will get some reviews from TSVWG. But I would like to point out that the target is Standards Track. I also would recommend that you take a look at the document implementing the change in the IPv6 Specification also after having reviewed draft-ietf-6man-udpzero-08: The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'IPv6 and UDP Checksums for Tunneled Packets' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides an update of the Internet Protocol version 6 (IPv6) specification (RFC2460) to improve the performance in the use case when a tunnel protocol uses UDP with IPv6 to tunnel packets. The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for suitable tunneling protocol where header information is protected on the "inner" packet being carried. This relaxation removes the overhead associated with the computation of UDP checksums on IPv6 packets used to carry tunnel protocols. The specification describes how the IPv6 UDP checksum requirement can be relaxed for the situation where the encapsulated packet itself contains a checksum. The limitations and risks of this approach are described, and restrictions specified on the use of the method. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums/ballot/ No IPR declarations have been submitted directly on this I-D. On 2012-12-12 09:09, gorry@erg.abdn.ac.uk wrote: > This message starts a two week TSVWG Working Group on advancing: > > Title : Applicability Statement for the use of IPv6 UDP > Datagrams with Zero Checksums > Author(s) : Godred Fairhurst > Magnus Westerlund > Filename : draft-ietf-6man-udpzero-08.txt > Pages : 37 > Date : 2012-12-11 > > https://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/ > > This document is intended to be published as BCP via the 6MAN WG. > > This last call is being done given the number of changes > and the time since the earlier last calls. The changes were discussed at the > Atlanta IETF 6man & TSVWG sessions. The authors believe these changes > will resolve the > open IESG Discusses. Our AD will start a concurrent IETF last call as well. > > Substantive comments and statements of support for advancing this document > should > be directed to the tsvwg or 6man mailing list. Editorial suggestions can > be sent to the > authors. This last call will end on 26 December 2012. > > James, David & Gorry > TSVWG Co-Chairs. > > > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From gorry@erg.abdn.ac.uk Thu Dec 13 05:30:26 2012 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 E46B221F8951; Thu, 13 Dec 2012 05:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBeZLALH-rqD; Thu, 13 Dec 2012 05:30:26 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 59DBC21F8934; Thu, 13 Dec 2012 05:30:26 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 03E1B2B4096; Thu, 13 Dec 2012 13:30:24 +0000 (GMT) Received: from 217.108.124.185 (proxying for 10.5.0.211) (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 13 Dec 2012 13:30:25 -0000 Message-ID: <1747245efc625354ccb67504cf31a2d5.squirrel@www.erg.abdn.ac.uk> Date: Thu, 13 Dec 2012 13:30:25 -0000 From: gorry@erg.abdn.ac.uk To: tsvwg@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [tsvwg] ADOPTION CALL: sctp-dtls-encaps and sctp-sack-immediately X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 13:30:27 -0000 This email starts a WG call for adoption for 2 potential TSVWG work items proposing minor extensions to SCTP: This adoption call will conclude 3rd January 2013. 1) SCTP/DTLS The authors of "draft-tuexen-tsvwg-sctp-dtls-encaps-01" request that this is adopted as TSVWG item. The IETF-85 meeting indicated some WG support for this, so we are now ready to make a formal decision and this email is to allow people to confirm that there is sufficient energy to complete this work in TSVWG. 2) SCTP SACK Immediately The authors of "draft-tuexen-tsvwg-sctp-sack-immediately" request that this is adopted as TSVWG item. This draft was discussed at a number of previous IETFs and the IETF-85 meeting indicated some WG support for this, so we are now ready to make a formal decision and this email is to allow people to confirm that there is sufficient energy to complete this work in TSVWG. PLEASE send an email to this list: * if you think adopting either/both of these documents in TSVWG is a good or bad idea. * if you have implemented or plan to implement these extensions. * Please also indicate if you are willing to REVIEW either/both documents during its development. Best wishes, Gorry, David and James. (TSVWG Co-Chairs) From gorry@erg.abdn.ac.uk Thu Dec 13 05:30:26 2012 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 E2EDB21F894D; Thu, 13 Dec 2012 05:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qw6ioFkwHEFw; Thu, 13 Dec 2012 05:30:26 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA1721F8949; Thu, 13 Dec 2012 05:30:26 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 930F72B44A7; Thu, 13 Dec 2012 13:30:25 +0000 (GMT) Received: from 217.108.124.185 (proxying for 10.5.0.211) (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 13 Dec 2012 13:30:25 -0000 Message-ID: <84bb726d543bdad53679861bc6ff5cc1.squirrel@www.erg.abdn.ac.uk> Date: Thu, 13 Dec 2012 13:30:25 -0000 From: gorry@erg.abdn.ac.uk To: tsvwg@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [tsvwg] ADOPTION CALL: sctp-dtls-encaps and sctp-sack-immediately X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 13:30:27 -0000 This email starts a WG call for adoption for 2 potential TSVWG work items proposing minor extensions to SCTP: This adoption call will conclude 3rd January 2013. 1) SCTP/DTLS The authors of "draft-tuexen-tsvwg-sctp-dtls-encaps-01" request that this is adopted as TSVWG item. The IETF-85 meeting indicated some WG support for this, so we are now ready to make a formal decision and this email is to allow people to confirm that there is sufficient energy to complete this work in TSVWG. 2) SCTP SACK Immediately The authors of "draft-tuexen-tsvwg-sctp-sack-immediately" request that this is adopted as TSVWG item. This draft was discussed at a number of previous IETFs and the IETF-85 meeting indicated some WG support for this, so we are now ready to make a formal decision and this email is to allow people to confirm that there is sufficient energy to complete this work in TSVWG. PLEASE send an email to this list: * if you think adopting either/both of these documents in TSVWG is a good or bad idea. * if you have implemented or plan to implement these extensions. * Please also indicate if you are willing to REVIEW either/both documents during its development. Best wishes, Gorry, David and James. (TSVWG Co-Chairs) From gorry@erg.abdn.ac.uk Thu Dec 13 05:45:18 2012 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 130F221F89A7 for ; Thu, 13 Dec 2012 05:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Gp+3iOAWog1 for ; Thu, 13 Dec 2012 05:45:17 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id D5D6A21F887A for ; Thu, 13 Dec 2012 05:45:16 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 1831D2B44A7; Thu, 13 Dec 2012 13:45:16 +0000 (GMT) Received: from 217.108.124.185 (proxying for 10.5.0.211) (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 13 Dec 2012 13:45:16 -0000 Message-ID: Date: Thu, 13 Dec 2012 13:45:16 -0000 From: gorry@erg.abdn.ac.uk To: tsvwg@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: gorry@erg.abdn.ac.uk Subject: [tsvwg] DOCUMENT SUBMISSION TO AD: draft-ietf-tsvwg-byte-pkt-congest-09 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 13:45:18 -0000 TSVWG. The chairs plan to submit the draft draft-ietf-tsvwg-byte-pkt-congest-09 for publication after completing revision following WGLC. A copy of the proposed write-up is enclosed below. Gorry, David & James TSVWG Co-Chairs ------ TSVWG: Byte and Packet Congestion Notification As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document is intended as BCP. (This was discussed at IETF-81 and that the status changed from Informational to BCP, because the draft provides guidance to implementors and people configuring routers and hosts). (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document provides recommendations of best current practice for dropping or marking packets using active queue management (AQM) such as random early detection (RED) or pre-congestion notification (PCN). We give three strong recommendations: (1) packet size should be taken into account when transports read and respond to congestion indications, (2) packet size should not be taken into account when network equipment creates congestion signals (marking, dropping), and therefore (3) the byte-mode packet drop variant of the RED AQM algorithm that drops fewer small packets should not be used. This memo updates RFC 2309 to deprecate deliberate preferential treatment of small packets in AQM algorithms. Working Group Summary There was consensus to publish this as a WG document and agreement at IETF-82 that the document was now complete. Since then there have been a number of revisions to address WG feedback. Document Quality Annexe A summarises a survey by the original authors showing deployment of the techniques by router vendors. The recommendations are thought to be in line with that of IETF groups, such as TSVWG, TCPM, PCN, and are considered good advice for use in the general Internet. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? I am the document shepherd, G Fairhurst. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document was presented at IEWTF-82 (Taipei), with a request for WGLC. WGLC concluded with some discussion and suggested changes on Friday 30th March 2012. The changes were discussed on the list, and have been implemented in a revised draft. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No - the original (individual) draft had a lot of background material, much of this has been condensed or removed, resulting in a shorter document. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures have been submitted directly on draft-ietf-tsvwg-byte-pkt-congest. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has WG support and there is consensus to publish. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) Some people commented on the size of the document. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. One update is listed, RFC 2309, informational - replaced by this BCP. It deprecates deliberate preferential treatment of small packets in AQM algorithms. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Not applicable. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not applicable. From jsaldana@unizar.es Fri Dec 14 07:47:52 2012 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 2725C21F8654 for ; Fri, 14 Dec 2012 07:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.317 X-Spam-Level: X-Spam-Status: No, score=-6.317 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtrCRHyJOB+y for ; Fri, 14 Dec 2012 07:47:51 -0800 (PST) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1454021F8653 for ; Fri, 14 Dec 2012 07:47:50 -0800 (PST) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id qBEFlYaP021529; Fri, 14 Dec 2012 16:47:35 +0100 From: "Jose Saldana" To: "'Magnus Westerlund'" , References: <2ed2b5b7450dd48db03b766f3533c674.squirrel@www.erg.abdn.ac.uk> <50C99DC8.7060505@ericsson.com> In-Reply-To: <50C99DC8.7060505@ericsson.com> Date: Fri, 14 Dec 2012 16:47:45 +0100 Organization: Universidad de Zaragoza Message-ID: <00dc01cdda12$5cb82190$162864b0$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJyL2SopPMtTBgLhShWvNJw+2JB1wGXNu5FlsMH1AA= Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tsvwg@ietf.org Subject: Re: [tsvwg] TSVWG Working Group Last Call: draft-ietf-6man-udpzero X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 15:47:52 -0000 Hi all. I have read draft-ietf-6man-udpchecksums-06.txt. I support it. Only these comments (I hope they are useful): - Although the difference between "tunneling packet" and "tunneled = packet" is clear, I think something similar could be done when talking about "tunneling protocols". The document sometimes talks about "tunnel = protocols" and other times about "tunneling protocols". Perhaps the term could be unified. Sentences which could be improved: - " These different examples each help to significantly reduce the likelihood that a corrupted inner tunneled packet is finally delivered = to a protocol listener that can be affected by the packet." Sounds very complicated, IMHO. - "similar effects that reduce the likelihood that an mis-delivered = packet are delivered." Could say " similar effects that reduce the likelihood = that a mis-delivered packet is delivered." - " A corruption will commonly only effect the single packet, not established protocol state." Could say "A corruption will commonly = affect a single packet, not the established protocol state." - " Tunnel protocols encapsulating IP this will generally be safe," = could say "In tunnel protocols encapsulating IP, this will generally be safe," A small typo: - "Corruption of the address information in an encapsulating packets," = could say " Corruption of the address information in an encapsulating packet" Best regards, Jose Saldana > -----Mensaje original----- > De: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] En nombre = de > Magnus Westerlund > Enviado el: jueves, 13 de diciembre de 2012 10:20 > Para: gorry@erg.abdn.ac.uk > CC: tsvwg@ietf.org > Asunto: Re: [tsvwg] TSVWG Working Group Last Call: draft-ietf-6man- > udpzero >=20 > Hi, >=20 > I do hope we will get some reviews from TSVWG. But I would like to = point > out that the target is Standards Track. >=20 > I also would recommend that you take a look at the document = implementing > the change in the IPv6 Specification also after having reviewed > draft-ietf-6man-udpzero-08: >=20 >=20 > The IESG has received a request from the IPv6 Maintenance WG (6man) to > consider the following document: > - 'IPv6 and UDP Checksums for Tunneled Packets' > as Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-12-25. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the = beginning of > the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > This document provides an update of the Internet Protocol version 6 > (IPv6) specification (RFC2460) to improve the performance in the = use > case when a tunnel protocol uses UDP with IPv6 to tunnel packets. > The performance improvement is obtained by relaxing the IPv6 UDP > checksum requirement for suitable tunneling protocol where header > information is protected on the "inner" packet being carried. This > relaxation removes the overhead associated with the computation of > UDP checksums on IPv6 packets used to carry tunnel protocols. The > specification describes how the IPv6 UDP checksum requirement can = be > relaxed for the situation where the encapsulated packet itself > contains a checksum. The limitations and risks of this approach = are > described, and restrictions specified on the use of the method. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 >=20 > On 2012-12-12 09:09, gorry@erg.abdn.ac.uk wrote: > > This message starts a two week TSVWG Working Group on advancing: > > > > Title : Applicability Statement for the use of = IPv6 UDP > > Datagrams with Zero Checksums > > Author(s) : Godred Fairhurst > > Magnus Westerlund > > Filename : draft-ietf-6man-udpzero-08.txt > > Pages : 37 > > Date : 2012-12-11 > > > > https://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/ > > > > This document is intended to be published as BCP via the 6MAN WG. > > > > This last call is being done given the number of changes and the = time > > since the earlier last calls. The changes were discussed at the > > Atlanta IETF 6man & TSVWG sessions. The authors believe these = changes > > will resolve the open IESG Discusses. Our AD will start a = concurrent > > IETF last call as well. > > > > Substantive comments and statements of support for advancing this > > document should be directed to the tsvwg or 6man mailing list. > > Editorial suggestions can be sent to the authors. This last call = will > > end on 26 December 2012. > > > > James, David & Gorry > > TSVWG Co-Chairs. > > > > > > > > >=20 >=20 > -- >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From randall@lakerest.net Sun Dec 16 06:38:18 2012 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 664F521F84E2 for ; Sun, 16 Dec 2012 06:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id he9orx5RY1vg for ; Sun, 16 Dec 2012 06:38:17 -0800 (PST) Received: from lakerest.net (lakerest.net [70.155.160.98]) by ietfa.amsl.com (Postfix) with ESMTP id 883F721F84B2 for ; Sun, 16 Dec 2012 06:38:17 -0800 (PST) Received: from [10.1.1.101] (bsd4.lakerest.net [70.155.160.102]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id qBGEcDKC011140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 16 Dec 2012 09:38:13 -0500 (EST) (envelope-from randall@lakerest.net) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Randy Stewart In-Reply-To: Date: Sun, 16 Dec 2012 09:38:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1920D8B0-1385-4F16-BF5D-138DF10DCBFB@lakerest.net> References: <20121201234242.BF442B1E002@rfc-editor.org> To: Michael Tuexen X-Mailer: Apple Mail (2.1283) Cc: gorry@erg.abdn.ac.uk, epontan@gmail.com, tsvwg@ietf.org, jmpolk@cisco.com, black_david@emc.com, RFC Errata System Subject: Re: [tsvwg] [Technical Errata Reported] RFC4960 (3423) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 14:38:18 -0000 Michael: I agree! But as to the actual Errata.. this is correct as well. It should be 0xffffffff not 0. The use of uint32_t is much better since it avoids the issues = surrounding int's and longs (for those in the editors office, a long on a 32 bit = machine is a 32 bit int, a long on a 64 bit machine is a 64 bit number .. of course = I speak of Unix type O/S's.. other O/S's may not have this issue, but I think = clarity here is most important ;-D) R On Dec 2, 2012, at 4:22 AM, Michael Tuexen wrote: > On Dec 2, 2012, at 12:42 AM, RFC Errata System wrote: >=20 >>=20 >> The following errata report has been submitted for RFC4960, >> "Stream Control Transmission Protocol". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D4960&eid=3D3423 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Pontus Andersson >>=20 >> Section: B >>=20 >> Original Text >> ------------- >> unsigned long >> generate_crc32c(unsigned char *buffer, unsigned int length) >> { >> unsigned int i; >> unsigned long crc32 =3D ~0L; >>=20 >> Corrected Text >> -------------- >> unsigned long >> generate_crc32c(unsigned char *buffer, unsigned int length) >> { >> unsigned int i; >> unsigned long crc32 =3D 0xffffffffL; > I would actually prefer to make use of uint32_t as the type of crc32. = At least this > is what we do in the FreeBSD implementation and that runs fine on all = architectures. >=20 > Best regards > Michael >>=20 >> Notes >> ----- >> The remainder register (crc32) should be initialized to 0xffffffffL = rather than ~0L, for correct operation on platforms where unisigned long = is longer than 32 bits. I.e., 64-bit platforms. >>=20 >> Instructions: >> ------------- >> This errata 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 (IESG) >> can log in to change the status and edit the report, if necessary.=20 >>=20 >> -------------------------------------- >> RFC4960 (draft-ietf-tsvwg-2960bis-05) >> -------------------------------------- >> Title : Stream Control Transmission Protocol >> Publication Date : September 2007 >> Author(s) : R. Stewart, Ed. >> Category : PROPOSED STANDARD >> Source : Transport Area Working Group >> Area : Transport >> Stream : IETF >> Verifying Party : IESG >>=20 >=20 >=20 ----- Randall Stewart randall@lakerest.net From gorry@erg.abdn.ac.uk Mon Dec 17 23:46:35 2012 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 97B3421F884E for ; Mon, 17 Dec 2012 23:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qfDlePGXZuy for ; Mon, 17 Dec 2012 23:46:34 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8C78321F8722 for ; Mon, 17 Dec 2012 23:46:34 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id D85472B43BE for ; Tue, 18 Dec 2012 07:46:32 +0000 (GMT) Received: from 139.133.204.42 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Tue, 18 Dec 2012 07:46:32 -0000 Message-ID: Date: Tue, 18 Dec 2012 07:46:32 -0000 From: gorry@erg.abdn.ac.uk To: tsvwg@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [tsvwg] Forward from Randell Jesup X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 07:46:35 -0000 I think both draft-tuexen-tsvwg-sctp-dtls-encaps and draft-tuexen-tsvwg-sctp-sack-immediately should be made working-group items. They are required and useful (respectively) for the (rtcweb) DataChannels work we're doing. -- Randell Jesup randell-ietf@jesup.org From dreibh@iem.uni-due.de Wed Dec 19 05:36:58 2012 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 F35CE21F8A3D for ; Wed, 19 Dec 2012 05:36:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHTk+JsKuzr7 for ; Wed, 19 Dec 2012 05:36:57 -0800 (PST) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id C48C021F8740 for ; Wed, 19 Dec 2012 05:36:56 -0800 (PST) Received: from sognsvann.localnet ([77.88.71.188]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id qBJDar44011936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Dec 2012 14:36:53 +0100 From: Thomas Dreibholz To: tsvwg@ietf.org Date: Wed, 19 Dec 2012 14:36:49 +0100 Message-ID: <2561318.xzXlar5jm2@sognsvann> Organization: University of Duisburg-Essen, Institute for Experimental Mathematics User-Agent: KMail/4.9.4 (Linux/3.2.0-34-generic; KDE/4.9.4; x86_64; ; ) In-Reply-To: <1747245efc625354ccb67504cf31a2d5.squirrel@www.erg.abdn.ac.uk> References: <1747245efc625354ccb67504cf31a2d5.squirrel@www.erg.abdn.ac.uk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7855083.OTdIEBIlBe"; micalg="pgp-sha1"; protocol="application/pgp-signature" Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 Cc: gorry@erg.abdn.ac.uk Subject: Re: [tsvwg] ADOPTION CALL: sctp-dtls-encaps and sctp-sack-immediately X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 13:36:58 -0000 --nextPart7855083.OTdIEBIlBe Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Dear Gorry, I fully support the adoption of both documents in TSVWG. Both are very = useful=20 and, in particular, I already make use of the draft-tuexen-tsvwg-sctp-s= ack- immediately extension in my SCTP setups (as part of the NorNet project,= see=20 also http://www.nntb.no/). Of course, I am also willing to review both documents during their=20 development. Torsdag 13 desember 2012 13.30.25 skrev gorry@erg.abdn.ac.uk: > This email starts a WG call for adoption for 2 potential TSVWG work i= tems > proposing minor extensions to SCTP: This adoption call will conclude = 3rd > January 2013. >=20 > 1) SCTP/DTLS >=20 > The authors of "draft-tuexen-tsvwg-sctp-dtls-encaps-01" request that = this > is adopted as TSVWG item. >=20 > The IETF-85 meeting indicated some WG support for this, so we are now= > ready to make a formal decision and this email is to allow people to > confirm that there is sufficient energy to complete this work in TSVW= G. >=20 > 2) SCTP SACK Immediately >=20 > The authors of "draft-tuexen-tsvwg-sctp-sack-immediately" request tha= t > this is adopted as TSVWG item. >=20 > This draft was discussed at a number of previous IETFs and the IETF-8= 5 > meeting indicated some WG support for this, so we are now ready to ma= ke a > formal decision and this email is to allow people to confirm that the= re is > sufficient energy to complete this work in TSVWG. >=20 >=20 > PLEASE send an email to this list: >=20 > * if you think adopting either/both of these documents in TSVWG is a = good > or bad idea. >=20 > * if you have implemented or plan to implement these extensions. >=20 > * Please also indicate if you are willing to REVIEW either/both docum= ents > during its development. >=20 > Best wishes, >=20 > Gorry, David and James. > (TSVWG Co-Chairs) --=20 Best regards / Mit freundlichen Gr=FC=DFen / Med vennlig hilsen =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thomas Dreibholz Simula Research Laboratory Simula Innovation AS, Network Systems Group Visiting address: Martin Linges vei 17, 1364 Fornebu, Norway Mailing address: P.O.Box 134, 1325 Lysaker, Norway -----------------------------------------------------------------------= E-Mail: dreibh@simula.no Homepage: http://simula.no/people/dreibh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --nextPart7855083.OTdIEBIlBe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAlDRwvEACgkQ32BbsHYPLWVJ9ACg3D46g+MMZv2zpwVCMqQ6cyZ7 TtkAnjuemT8T5c+F9xi47OfhPunu0Uzc =Ib+a -----END PGP SIGNATURE----- --nextPart7855083.OTdIEBIlBe-- From martin.becke@uni-due.de Wed Dec 19 06:25:55 2012 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 E82A921F857A for ; Wed, 19 Dec 2012 06:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMK5JaeQWCO8 for ; Wed, 19 Dec 2012 06:25:55 -0800 (PST) Received: from mailoutzim.uni-due.de (mailoutzim.uni-due.de [132.252.185.16]) by ietfa.amsl.com (Postfix) with ESMTP id 06BF121F8558 for ; Wed, 19 Dec 2012 06:25:54 -0800 (PST) Received: from HT02.win.uni-due.de (virt098.zim.uni-duisburg-essen.de [132.252.185.98]) by mailoutzim.uni-due.de (8.13.1/8.13.1) with ESMTP id qBJEPqnT002255; Wed, 19 Dec 2012 15:25:52 +0100 Received: from ccr02.win.uni-due.de ([169.254.2.147]) by HT02.win.uni-due.de ([132.252.190.234]) with mapi id 14.02.0318.004; Wed, 19 Dec 2012 15:25:52 +0100 From: "Becke, Martin" To: " " Thread-Topic: [tsvwg] ADOPTION CALL: sctp-dtls-encaps and sctp-sack-immediately Thread-Index: AQHN2TYMK7i9ELVHs0iWZjhVfp+hQZggJk6A Date: Wed, 19 Dec 2012 14:25:51 +0000 Message-ID: References: <1747245efc625354ccb67504cf31a2d5.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <1747245efc625354ccb67504cf31a2d5.squirrel@www.erg.abdn.ac.uk> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.252.151.202] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <96E6530406834747A388EF5BA5B08DCE@win.uni-due.de> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.16 Cc: "" , Sebastian Werner Subject: Re: [tsvwg] ADOPTION CALL: sctp-dtls-encaps and sctp-sack-immediately X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 14:25:56 -0000 Hi Gorry, 1) This draft is important in the context of the RTCWeb/WebRTC discussion.=20 If the RTCWeb/WebRTC solution comes up with SCTP and DTLS we need an agreem= ent here.=20 The WG should discuss about the best way, I would like to see the ID in the= WG.=20 We (especially Sebastian) implement the current discussed RTCWeb stack in t= he Omnet++/Inet Environment.=20 2) For my feeling the motivation for this kind of extension is strong enough. Furthermore I see no drawbacks, but the approach provides a possible improv= ement without changing the nature of the protocol. That is why I support the adoption of this draft. Martin Am 13.12.2012 um 14:30 schrieb : > This email starts a WG call for adoption for 2 potential TSVWG work items > proposing minor extensions to SCTP: This adoption call will conclude 3rd > January 2013. >=20 > 1) SCTP/DTLS >=20 > The authors of "draft-tuexen-tsvwg-sctp-dtls-encaps-01" request that this > is adopted as TSVWG item. >=20 > The IETF-85 meeting indicated some WG support for this, so we are now > ready to make a formal decision and this email is to allow people to > confirm that there is sufficient energy to complete this work in TSVWG. >=20 > 2) SCTP SACK Immediately >=20 > The authors of "draft-tuexen-tsvwg-sctp-sack-immediately" request that > this is adopted as TSVWG item. >=20 > This draft was discussed at a number of previous IETFs and the IETF-85 > meeting indicated some WG support for this, so we are now ready to make a > formal decision and this email is to allow people to confirm that there i= s > sufficient energy to complete this work in TSVWG. >=20 >=20 > PLEASE send an email to this list: >=20 > * if you think adopting either/both of these documents in TSVWG is a good > or bad idea. >=20 > * if you have implemented or plan to implement these extensions. >=20 > * Please also indicate if you are willing to REVIEW either/both documents > during its development. >=20 > Best wishes, >=20 > Gorry, David and James. > (TSVWG Co-Chairs) >=20 >=20 From salvatore.loreto@ericsson.com Wed Dec 19 07:50:15 2012 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 C6FD121F8614 for ; Wed, 19 Dec 2012 07:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.189 X-Spam-Level: X-Spam-Status: No, score=-106.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpzQ1g4KbEx9 for ; Wed, 19 Dec 2012 07:50:14 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE9521F85DF for ; Wed, 19 Dec 2012 07:50:14 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-4f-50d1e235aa0f Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id FC.A6.24873.532E1D05; Wed, 19 Dec 2012 16:50:13 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Wed, 19 Dec 2012 16:50:13 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D5DEB2ABD for ; Wed, 19 Dec 2012 17:50:12 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 86CE453F3E for ; Wed, 19 Dec 2012 17:50:11 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 158D253D14 for ; Wed, 19 Dec 2012 17:50:10 +0200 (EET) Message-ID: <50D1E233.7000404@ericsson.com> Date: Wed, 19 Dec 2012 16:50:11 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: tsvwg@ietf.org References: <1747245efc625354ccb67504cf31a2d5.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <1747245efc625354ccb67504cf31a2d5.squirrel@www.erg.abdn.ac.uk> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUyM+Jvja7po4sBBidmiFsce3OXzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGXu2nGcrmMlXsX9SK1sD4yzuLkZODgkBE4l7h3oZIWwxiQv3 1rN1MXJxCAmcZJT4ObmLHcLZwCjRfPUlM4RznlFi8/8tUGWHGCVa7+5mhHBOM0q87mtjARnG K6At8e3MQlYQm0VAVWJNTztYnE3ATOL5wy3MILaoQKzE1kuX2SDqBSVOznwCViMiICRx7d9D sLiwgJ/E/e+HwQ4UEvCSeLzhIFMXIwcHp4C3xL7/JSBhZgFbiQtzrrNA2PIS29/OYYb4R03i 6rlNzBCtWhK9ZzuZJjCKzEKybRaS9llI2hcwMq9iZM9NzMxJLzfaxAgM5oNbfqvuYLxzTuQQ ozQHi5I4b7jrhQAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjPO6M9J3KeW82B740nrFz00l G14/v6VWHazU/MCdPfDDTCnFNqvNN/fpaWfcr3X7/lXj1uPspxfNt5ir9esrHDt/PPWKaGyz 55T163/6N1nH/HI8u/hXRs+x+oozV8ryhS35NY9c73/w5dlyVo/wFw3TNfp/Tl9juLl94ck7 l807dfaJK+114FdiKc5INNRiLipOBACN3VeTNAIAAA== Subject: Re: [tsvwg] ADOPTION CALL: sctp-dtls-encaps and sctp-sack-immediately X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 15:50:15 -0000 Dear Gorry, David and James, Ericsson is interested and support the adoption of both documents in tsvwg. We are interested to sctp-sack-immediately, but we have not implemented it yet but we plan to do it in the near future and also follow up tsvwg activities on it. We are also interested in sctp-dtls-encaps-01, but not sure about the implementation plan -- Salvatore Loreto, PhD www.sloreto.com On 12/13/12 2:30 PM, gorry@erg.abdn.ac.uk wrote: > This email starts a WG call for adoption for 2 potential TSVWG work items > proposing minor extensions to SCTP: This adoption call will conclude 3rd > January 2013. > > 1) SCTP/DTLS > > The authors of "draft-tuexen-tsvwg-sctp-dtls-encaps-01" request that this > is adopted as TSVWG item. > > The IETF-85 meeting indicated some WG support for this, so we are now > ready to make a formal decision and this email is to allow people to > confirm that there is sufficient energy to complete this work in TSVWG. > > 2) SCTP SACK Immediately > > The authors of "draft-tuexen-tsvwg-sctp-sack-immediately" request that > this is adopted as TSVWG item. > > This draft was discussed at a number of previous IETFs and the IETF-85 > meeting indicated some WG support for this, so we are now ready to make a > formal decision and this email is to allow people to confirm that there is > sufficient energy to complete this work in TSVWG. > > > PLEASE send an email to this list: > > * if you think adopting either/both of these documents in TSVWG is a good > or bad idea. > > * if you have implemented or plan to implement these extensions. > > * Please also indicate if you are willing to REVIEW either/both documents > during its development. > > Best wishes, > > Gorry, David and James. > (TSVWG Co-Chairs) > > From I.Ruengeler@fh-muenster.de Thu Dec 20 00:38:00 2012 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 3E99021F85B8 for ; Thu, 20 Dec 2012 00:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxS7JFyhc4Od for ; Thu, 20 Dec 2012 00:37:59 -0800 (PST) Received: from mail.fh-muenster.de (mail.fh-muenster.de [193.174.88.235]) by ietfa.amsl.com (Postfix) with ESMTP id 8123C21F85AE for ; Thu, 20 Dec 2012 00:37:58 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.fh-muenster.de (Postfix) with ESMTP id 4636134356 for ; Thu, 20 Dec 2012 09:37:55 +0100 (CET) Received: from mail.fh-muenster.de ([127.0.0.1]) by localhost (mail.fh-muenster.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMp216Uyk3U6 for ; Thu, 20 Dec 2012 09:37:54 +0100 (CET) Received: from macpro2.nplab.fh-muenster.de (unknown [212.201.121.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: ruengele) by mail.fh-muenster.de (Postfix) with ESMTP id B94FB34350 for ; Thu, 20 Dec 2012 09:37:51 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_19DE4AFC-DD57-4224-9E5D-054AC6AE2E12" From: =?iso-8859-1?Q?Irene_R=FCngeler?= X-Priority: 3 (Normal) In-Reply-To: Date: Thu, 20 Dec 2012 09:37:50 +0100 Message-Id: <1DFA114C-64C9-44F6-BD0A-DE38AD4B1114@fh-muenster.de> References: <84bb726d543bdad53679861bc6ff5cc1.squirrel@www.erg.abdn.ac.uk> To: tsvwg X-Mailer: Apple Mail (2.1283) Subject: Re: [tsvwg] ADOPTION CALL: sctp-dtls-encaps and sctp-sack-immediately X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 08:38:00 -0000 --Apple-Mail=_19DE4AFC-DD57-4224-9E5D-054AC6AE2E12 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Dear Gorry In my opinion the documents are very important. sctp-dtls-encaps is = needed for rtcweb and sctp-sack-immediately shortens the time for a dtls = handshake significantly. I am willing to review the documents. Best wishes Irene --Apple-Mail=_19DE4AFC-DD57-4224-9E5D-054AC6AE2E12 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Dear = Gorry

In my opinion the documents are very important. = sctp-dtls-encaps is needed for rtcweb and sctp-sack-immediately shortens = the time for a dtls handshake significantly.
I am willing to = review the documents.

Best = wishes

Irene





= --Apple-Mail=_19DE4AFC-DD57-4224-9E5D-054AC6AE2E12-- From gorry@erg.abdn.ac.uk Thu Dec 20 00:39:46 2012 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 B2F0021F85C3 for ; Thu, 20 Dec 2012 00:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwXbA6b--Db4 for ; Thu, 20 Dec 2012 00:39:45 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 83FA521F85BF for ; Thu, 20 Dec 2012 00:39:45 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 6C3932B4400 for ; Thu, 20 Dec 2012 08:39:44 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 20 Dec 2012 08:39:44 -0000 Message-ID: <7e15ff36dba70a22991f302a01a5f5fd.squirrel@www.erg.abdn.ac.uk> Date: Thu, 20 Dec 2012 08:39:44 -0000 From: gorry@erg.abdn.ac.uk To: tsvwg@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [tsvwg] tsvwg status - December 2012 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 08:39:46 -0000 The list below shows the status of the working group documents as we see it. Please check below and comment on drafts using the list. Please do send any corrections/omissions to the chairs. Best wishes, Gorry, David & James (TSVWG Chairs) --- Recently published: draft-ietf-tsvwg-rsvp-security-groupkeying was published as RFC 6411. draft-ietf-tsvwg-sctpsocket was published as RFC 6458. draft-ietf-tsvwg-sctp-strrst was published as RFC 6535. draft-ietf-tsvwg-source-quench was published as RFC 6633. ------------------------------------------------------------------- IDs in RFC Editor Queue: http://www.rfc-editor.org/queue.html None. ------------------------------------------------------------------- IDs in IESG processing: draft-ietf-tsvwg-sctp-udp-encap (Replaced: draft-tuexen-sctp-udp-encap) Lars sent a note as AD agreeing to progress this work. Work was coordinated with DCCP work on encaps. draft-tuexen-sctp-udp-encaps-06, January 10, 2011 Adopted as a work item 21 Sept 2011 (Gorry) WG -02 8 Dec 2011 WGLC completed Friday 20th April 2012, many discussion and notes that there were implementations (including: FreeBSD and released in 9.1 & MacOS X) ID was ready for AD submission, 20th Oct 2012 Checked IANA port usage. STATUS: Write-up sent to AD. --- draft-ietf-tsvwg-byte-pkt-congest New editor added Jul 2010. New revision 25 Oct 2010. WG -01, June 10, 2011 IETF-81: discussed whether this should be BCP. ADs & Chairs agree to progress as a BCP Status changed to BCP (new-ID WG -05) Presented at IETF-82 (Taipei), request for WGLC. Gorry added as Shepherd (Jan 2012), Wes added as responsible AD (Jun 2012). WGLC concluded with comments on I-D, Friday 30th March 2012. Draft version of write-up sent to list, comments received. - Gorry working with authors to clear list of WGLC questions (5 sept 2012). WG Chair received version that includes additional feedback during WGLC STATUS: Write-up sent to AD. ------------------------------------------------------------------- WG Drafts with Chairs: None. ------------------------------------------------------------------- WG Drafts: draft-ietf-tsvwg-rsvp-pcn Previous version : draft-karagiannis-pcn-tsvwg-rsvp-pcn WG interest in this topic recorded at IETF-81. Individual -01, 2011-07-11 AD decision allowed this to be added to the milestones The document was adopted, status will be EXP (IETF-84 due to dependencies on PCN RFCs) WG -00 8 Oct 2011 RSVP-DIR review requested 13th Oct 2012 DUE: Please comment on RVSP & PCN aspects --- draft-ietf-tsvwg-natsupp-tsvwg (Replaced: draft-stewart-natsupp-tsvwg) http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-natsupp/ Dependency from BEHAVE WG. Adopted as a work item 21 Sept 2010 (Gorry). WG -00, 29/11/2010 Uploaded as: draft-ietf-natsupp-tsvwg WG -01, June 1, 2011 Authors restructured draft (-03) - Done for single home - Concept done for multihome, no spec DUE: Please comment on list. --- draft-ietf-tsvwg-sctp-failover replaces: draft-nishida-tsvwg-sctp-failover Individual-00 Presented in Prague, IETF-80. - understood not to conflict with draft-tuexen-tsvwg-sctp-multipath - PF has been coded into FreeBSD WG adoption was approved - request to comment to list on 26/6/2012. Adopted by WG. --- draft-ietf-tsvwg-intserv-multiple-tspec WG interest in this topic recorded at IETF-78. Charter update would be needed to progress this work. 5 Reviews needed to determine energy/technical direction. WG -05 (presented in Beijing, IETF-79) WG -06 (presented in Prague, IETF-80) RSVP directorate was consulted. 2 reviews from RSVP-DIR received (Bruce Davie, ?) 2 additional reviews promised (Ken Carlberg, Francois LeF) Chairs asked AD for a Charter update (IESG agreed) Draft discussed at IETF-80, and request to update charter agreed - AD advised 4 named reviewers will be required Adopted for progression as PS, for May 2012 - New approach presented following WG comments DUE: Discussion needed on list. --- draft-ietf-tsvwg-port-use-00 (replaces draft-touch-tsvwg-port-use-00) - Intended to be advice to protocol designers needing a port. 5 people have looked at this document, Prague IETF-80 Individual -01 July 2011 IETF-81 insufficient feedback from WG at this time. WG needs to assess if the new draft should be a work item. IETF-82, discussed - Chairs will ask WG to consider. Adopted by WG DUE: Revised ID expected to complete missing sections & include feedback from IETF-85 --- draft-polk-tsvwg-rsvp-app-id-vv-profiles -01 Presented in Beijing, IETF-79. -02, 14-Mar-2011 Presented IET-80. WG needs to assess if the new draft should be a work item. Seek to coordinate with music with partner ID: draft-polk-mmusic-traffic-class-for-sdp Author requests to make a WG work item... Gorry liaised with MMUSIC WG Chairs on companion draft, intended for LC early 2013. Adopted as a TSVWG work item - December 2012. DUE: Waiting for author to respond with milestone date. ------------------------------------------------------------------- WG action required: WGLC: UDP/IPv6 draft-ietf-6man-udpzero Previously: draft-fairhurst-tsvwg-6man-udpzero Related draft: draft-ietf-6man-udpchecksums-00 This draft was also LC'ed in TSVWG (end 3rd May 2012) DUE: Updated to become a BCP applicability statement - new WGLC in TSVWG started for 26 Dec 2012. --- Adoption call: SCTP/DTLS draft-tuexen-tsvwg-sctp-dtls-encaps-01 Implemented in Firefox, Chrome interested. This adoption call will conclude 3rd January 2013. DUE: Please confirm adoption by working group on mailing list. Responses to call: [MB:TD:SL] --- Adoption call: SCTP/SACK-Immediately draft-tuexen-tsvwg-sctp-sack-immediately -05, 2011-01-02 - Aug 2011, discussed on list and issues raised. - Implemented in BSD & Linux This adoption call will conclude 3rd January 2013. DUE: Please confirm adoption by working group on mailing list. Responses to call: [MB:TD:SL] ------------------------------------------------------------------- The following have received recent discussion at TSVWG meetings or on the list. Inclusion in the list below does not indicate support for these specific drafts and other contributions are also warmly welcomed. draft-polk-tsvwg-rfc4594-update Discussed at IETF-83, Paris - noted at IETF-84, but not discussed (no time). DUE: Please comment on list. --- draft-polk-tsvwg-new-dscp-assignments - noted at IETF-84, but not discussed (no time). DUE: Please comment on list. --- draft-stewart-tsvwg-sctpecn-02Partially replaces (draft-stewart-tsvwg-sctp-nonce) IETF-78 suggested there was interest in this topic. Discussed at IETF-83, Paris. DUE: ECN was confirmed to be within the TSVWG Charter DUE: A call for adoption will be made on the list, please comment on this draft contents. --- draft-tuexen-tsvwg-sctp-multipath (CMT) -00 Presented in Prague, IETF-80. - understood not to conflict with draft-nishida-tsvwg-sctp-failover - Implemented in FreeBSD (ns2, inet) - subsumes NR-SACK -01, 2010-12-27 DUE: Please comment to list. DUE: Need to decide if this can be adopted as a WG Item --- draft-carlberg-tsvwg-ecn-reactions Reactions to Signaling from ECN Support for RTP/RTCP -00 presented IETF-82 Not yet requested to become a work item. - This draft is related to the new rmcat work. DUE: Please comment on list. ------------------------------------------------------------------- Related non-TSVWG items: draft-ietf-behave-sctpnat-03.txt BEHAVE WG item linked to SCTP encapsulation work. draft-ohanlon-rmcat-dflow Discussed at IETF-84, Vancouver This draft is related to the new rmcat work. Comments received on list prior to IETF-85. DUE: Revised ID needed ------------------------------------------------------------------ Other news: RSVP Directorate (formed in May 2010) Charter updated Aug 2011. New co-chair: Rolf Winter ITU-T Study Group 12 Liaison on QoS Classes & markings for interconnection ------------------------------------------------------------------ Other draft history: draft-ietf-behave-sctpnat-03.txt waiting on: draft-ietf-tsvwg-natsupp-04 --- draft-briscoe-tsvwg-ecn-encap-guidelines -00 Presented in Prague, IETF-80. - comments at IETF-80 (see minutes) Authors need to update this draft. DUE: Please comment on list. DUE: Please check liaison status with other SDOs. From wes@mti-systems.com Thu Dec 20 13:45:46 2012 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 1CC7E21F8A9D for ; Thu, 20 Dec 2012 13:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WOYrNnn8JGw for ; Thu, 20 Dec 2012 13:45:45 -0800 (PST) Received: from atl4mhob11.myregisteredsite.com (atl4mhob11.myregisteredsite.com [209.17.115.49]) by ietfa.amsl.com (Postfix) with ESMTP id E6AE121F8A9A for ; Thu, 20 Dec 2012 13:45:31 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob11.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qBKLjU84013377 for ; Thu, 20 Dec 2012 16:45:30 -0500 Received: (qmail 16706 invoked by uid 0); 20 Dec 2012 21:45:30 -0000 Received: from unknown (HELO ?192.168.1.145?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 20 Dec 2012 21:45:30 -0000 Message-ID: <50D386EE.7060509@mti-systems.com> Date: Thu, 20 Dec 2012 16:45:18 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: tsvwg@ietf.org References: <20121128002033.10683.71629.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [tsvwg] FW: New Version Notification for draft-dhesikan-tsvwg-rtcweb-qos-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 21:45:46 -0000 On 11/27/2012 7:27 PM, Subha Dhesikan (sdhesika) wrote: > This document was originally submitted in RTCWeb WG and was adopted as a WG document. The transport AD requested that this be moved to TSVWG. Therefore, this document is now submitted as an individual submission to TSVWG. To provide some context ... during the Atlanta IETF, it became clear that having this document in RTCWEB (where it was a WG draft) was confusing on at least 2 counts: (1) TSVWG is the place in the IETF where we should be making any recommendations about use of DiffServ; it would get crazy if every WG had its own set of guidance about this. (2) It seemed to be advocating using multiple 6-tuples (address pairs, port pairs, protocol, and DSCP) that differ only in their DSCP, for distinguishing the QoS desires of individual packets within an RTCWEB flow that's muxing potentially lots of different things (voice, video, bulk, and interactive data) with different QoS desires. This was potentially not going to interact well with things we have been talking about in RMCAT, like allocating congestion responses between elastic and inelastic sub-flows. If those sub- flows are on separate 6-tuples, this may not make any sense, as they'd be seeing different queues within the network. So, in summary, TSVWG is the right place to talk about this draft, though I'm not sure it's technically a very good idea, myself, given other work being done in the IETF currently. -- Wes Eddy MTI Systems From Ruediger.Geib@telekom.de Thu Dec 20 23:41:51 2012 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 A3D0421F84C1 for ; Thu, 20 Dec 2012 23:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhw1OK0OVYiV for ; Thu, 20 Dec 2012 23:41:51 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id C662E21F8449 for ; Thu, 20 Dec 2012 23:41:50 -0800 (PST) Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 21 Dec 2012 08:41:11 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by he110890 ([10.134.92.131]) with mapi; Fri, 21 Dec 2012 08:41:10 +0100 From: To: Date: Fri, 21 Dec 2012 08:41:09 +0100 Thread-Topic: [tsvwg] FW: New Version Notification for draft-dhesikan-tsvwg-rtcweb-qos-00.txt Thread-Index: Ac3e+2ZbBpIgX8GTTdCKOPQvl2QU3QAUaHuA Message-ID: References: <20121128002033.10683.71629.idtracker@ietfa.amsl.com> <50D386EE.7060509@mti-systems.com> In-Reply-To: <50D386EE.7060509@mti-systems.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsvwg@ietf.org Subject: Re: [tsvwg] FW: New Version Notification for draft-dhesikan-tsvwg-rtcweb-qos-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 07:41:51 -0000 Wes, thanks. (2) may advocate starting with a problem statement and a framework = on QoS for RTCWeb. I'd support that. Regards, R=FCdiger -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of W= esley Eddy Sent: Thursday, December 20, 2012 10:45 PM To: tsvwg@ietf.org Subject: Re: [tsvwg] FW: New Version Notification for draft-dhesikan-tsvwg-= rtcweb-qos-00.txt On 11/27/2012 7:27 PM, Subha Dhesikan (sdhesika) wrote: > This document was originally submitted in RTCWeb WG and was adopted as a = WG document. The transport AD requested that this be moved to TSVWG. There= fore, this document is now submitted as an individual submission to TSVWG. To provide some context ... during the Atlanta IETF, it became clear that having this document in RTCWEB (where it was a WG draft) was confusing on at least 2 counts: (1) TSVWG is the place in the IETF where we should be making any recommendations about use of DiffServ; it would get crazy if every WG had its own set of guidance about this. (2) It seemed to be advocating using multiple 6-tuples (address pairs, port pairs, protocol, and DSCP) that differ only in their DSCP, for distinguishing the QoS desires of individual packets within an RTCWEB flow that's muxing potentially lots of different things (voice, video, bulk, and interactive data) with different QoS desires. This was potentially not going to interact well with things we have been talking about in RMCAT, like allocating congestion responses between elastic and inelastic sub-flows. If those sub- flows are on separate 6-tuples, this may not make any sense, as they'd be seeing different queues within the network. So, in summary, TSVWG is the right place to talk about this draft, though I'm not sure it's technically a very good idea, myself, given other work being done in the IETF currently. -- Wes Eddy MTI Systems From Ruediger.Geib@telekom.de Fri Dec 21 01:49:06 2012 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 C634E21F89E8 for ; Fri, 21 Dec 2012 01:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.21 X-Spam-Level: X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTeAEi1CtKN1 for ; Fri, 21 Dec 2012 01:49:05 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id D872821F8505 for ; Fri, 21 Dec 2012 01:49:03 -0800 (PST) Received: from he113657.emea1.cds.t-internal.com ([10.134.99.17]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 21 Dec 2012 10:48:57 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113657.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 21 Dec 2012 10:48:47 +0100 From: To: Date: Fri, 21 Dec 2012 10:48:46 +0100 Thread-Topic: Diffserv for interconnection Thread-Index: Ac3KljebdjQRdxroSiOKNiDbMqMC/ABF5BIQAAKa+bAE6CfYkA== Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE71284D3FF1B@MX15A.corp.emc.com> <94C682931C08B048B7A8645303FDC9F36E98722964@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E98722964@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pierre.levis@orange.com, tsvwg@ietf.org, christian.jacquenet@orange.com Subject: Re: [tsvwg] Diffserv for interconnection X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 09:49:06 -0000 Dear Med, after having read RFC5160, I'm happy that you agree that an interconnection class and codepoint scheme and RFC5160 complement each other. I'll add a reference, when I update my draft. I may come back with questions on some details, but there's one point which I'd like to discuss. Your terminology is quite clear about Local-QoS-Class (l-QC) A QoS transfer capability across a single domain, characterized by a set of QoS performance parameters denoted by (D, J, L). From a Diffserv [RFC2475] perspective, an l-QC is an occurrence of a Per Domain Behavior (PDB) [RFC3086]. >From what I know, a PDB may be optimised for cetrtain kinds of traffic: pure VoIP RTP or TCP, to give examples. Traffic conditioning and scheduling may be optimised on the recommended usage of a class. If that's the case, then first there's the PDB or class specification on a level closer to transport or application and then there's a description by SLA properties. Taking it the other way around: by just looking at SLA properties D, J, L and a PDB name (which may not be standardised), interconnection QoS may not always work as desired. Especially with AF classes. What I propose is to add some explaining text in a document we would have to agree on (maybe my draft, could be any other). That may be done in a way as proposed by http://tools.ietf.org/html/rfc3086#sect= ion-8. What's left for me this year is wishing merry christmas to those celebrating and a relaxed and good start into 2013 to those who don't R=FCdiger -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Monday, November 26, 2012 11:23 AM To: Geib, R=FCdiger; david.black@emc.com Cc: LEVIS Pierre OLNC/OLPS; tsvwg@ietf.org; JACQUENET Christian OLNC/OLN Subject: RE: Diffserv for interconnection Dear Ruediger, Please see inline. Cheers, Med >-----Message d'origine----- >De : tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] De >la part de Ruediger.Geib@telekom.de >Envoy=E9 : lundi 26 novembre 2012 09:30 >=C0 : david.black@emc.com >Cc : LEVIS Pierre OLNC/OLPS; tsvwg@ietf.org; JACQUENET >Christian OLNC/OLN >Objet : Re: [tsvwg] Diffserv for interconnection > >David, > >thanks. I submitted a draft on the issue and I'm also involved >in the ITU liaision. > >Yes, to me IETF should pick up the subject of limited and >"well enough defined" >set of interconnection QoS classes. > >I've reread RFC5127. If it stays informational, I got no >qualms with it. If a revised >version of RFC5127 ist to be put on standards track, some >parts of it must be >better explained and possibly rewritten. If it is not touched, >some parts of what >is required in a revised 5127 from my point of view should >become part of the >interconnection work. > >I'm halfway through http://tools.ietf.org/html/rfc5160 and the >authors asked how I'd >position my proposal with regard it. It is a more abstract >document about >inter provider QoS agreements. Med: FWIW, the rationale we adopted in RFC5160 is as follows: * Network Providers are free to define their own traffic engineering polici= es and their QoS class of services in their domains. * Diffserv is only a means among other to achieve differentiated forwarding * The number and the definition of QoS classes is not universal * Network Providers are not obliged to expose their internal class of servi= ces to external parties * When extending some QoS classes beyond the boundaries of a given domain, = it is required to establish contractual agreements between network provider= s, otherwise the traffic will be handed as BE. * These agreements will be the place where class identification is discusse= d and agreed. * Remarking is likely to be always enforced in both exit border router and = entry border router: local class of services are not advertised outside the= domain. * Providers need a tool to help deciding how to bind one/multiple local QoS= classes with adjacent class of service: hence the concept of meta-QoS-Clas= s. * CoS identifier is not sufficient to provide QoS: additional parameters ar= e to be agreed between network providers. Examples of these parameters are:= constraints on the traffic (eg., tcp-friendly), network resources for the = class / overall traffic using this class, etc. So far I think, RFC5160 and the >proposals of my >draft would complement each other. Med: Agreed. I personally see a value in standardizing a very limited set o= f interconnection classes. In addition to the interconnection class name/id= entifier discussion point, it is important also to have a detailed definiti= on of the class itself (in terms of attributes, target services, traffic co= nditions, etc.). Perhaps, try the http://tools.ietf.org/html/rfc3086#sectio= n-8 ;-)? > >Regards, > >R=FCdiger > > > >-----Original Message----- >From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] >On Behalf Of Black, David >Sent: Saturday, November 24, 2012 11:51 PM >To: tsvwg@ietf.org >Subject: [tsvwg] Diffserv for interconnection > >Hello - this is your new tsvwg co-chair again, with . > >The Atlanta tsvwg minutes are at: > http://www.ietf.org/proceedings/85/minutes/minutes-85-tsvwg > >This message is about my second action item, on use of Diffserv for >network interconnection. > >Excerpt from the minutes (explanation below): >--------------- >Topic: interconnect liaison with ITU-T >- (James Polk) describing set of code points (?) for the >interconnection > of core providers. >- (Gorry Fairhurst) asks if we should make a new set of >recommendations for > a particular interface. >- (David Black) thinks we should. As Chair, he asks the room >if we should > work on this? The room (by show of hands) indicates yes. > So we'll put this on the list >(Joel Halpern) thinks we don't need to do anymore at this meeting. We > should state "this is an interesting problem, and we should do > something about this" >--------------- > >So the immediate question is what was "this" in Joel's comment? > >The short answer is that it's slide 6 in this set of slides: > http://www.ietf.org/proceedings/85/slides/slides-85-tsvwg-8.pdf > >The rationale for doing "this" is also on that slide - it's basically >scaling/reuse of configuration, so that a carrier or operator can apply >a single diffserv configuration to interconnections with multiple other >networks. Also see draft-geib-tsvwg-diffserv-intercon-00 . > >The item that I recall asking about was whether the IETF >should work on a >single set of recommended diffserv behavior (PHBs) and >codepoints (DSCPs) >for use in carrier interconnection? > >The sense of the room in Atlanta (as noted in the minutes) was that the >IETF should work on this, with details of how to do that TBD - in >particular there was no assumption about the relationship of this work >to RFC 5127 on aggregation of Diffserv Classes (e.g., if undertaken, >this new work may or may not be carried out by revising RFC 5127). > >If anyone disagrees with the sense of the room in Atlanta, now would >be a good time to speak up. > >If the sense of the room in Atlanta is confirmed, the next action is >for me to work through the ITU-T SG12 liaison (primarily the draft of >y.qosmap) and consult with Ruediger about what makes sense before >bringing a proposal for what to do back to this list. > >Thanks, >--David >---------------------------------------------------- >David L. Black, Distinguished Engineer >EMC Corporation, 176 South St., Hopkinton, MA 01748 >+1 (508) 293-7953 FAX: +1 (508) 293-7786 >david.black@emc.com Mobile: +1 (978) 394-7754 >---------------------------------------------------- > > From ietfc@btconnect.com Fri Dec 21 06:35:17 2012 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 3FC5521F8625 for ; Fri, 21 Dec 2012 06:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.597 X-Spam-Level: X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[AWL=1.002, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLOM++orbNWj for ; Fri, 21 Dec 2012 06:35:16 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 01A0221F8635 for ; Fri, 21 Dec 2012 06:35:15 -0800 (PST) Received: from mail65-tx2-R.bigfish.com (10.9.14.238) by TX2EHSOBE011.bigfish.com (10.9.40.31) with Microsoft SMTP Server id 14.1.225.23; Fri, 21 Dec 2012 14:35:15 +0000 Received: from mail65-tx2 (localhost [127.0.0.1]) by mail65-tx2-R.bigfish.com (Postfix) with ESMTP id 3E14B1A0171; Fri, 21 Dec 2012 14:35:15 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -36 X-BigFish: PS-36(zzbb2dI9371I936eI1403R542Iec9Nzz1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h304l1155h) Received: from mail65-tx2 (localhost.localdomain [127.0.0.1]) by mail65-tx2 (MessageSwitch) id 135610051390170_10294; Fri, 21 Dec 2012 14:35:13 +0000 (UTC) Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.244]) by mail65-tx2.bigfish.com (Postfix) with ESMTP id 11934A004D; Fri, 21 Dec 2012 14:35:13 +0000 (UTC) Received: from AM2PRD0710HT003.eurprd07.prod.outlook.com (157.56.249.213) by TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 21 Dec 2012 14:35:12 +0000 Received: from DB3PRD0210HT004.eurprd02.prod.outlook.com (157.56.253.69) by pod51017.outlook.com (10.255.165.38) with Microsoft SMTP Server (TLS) id 14.16.245.2; Fri, 21 Dec 2012 14:35:08 +0000 Message-ID: <066101cddf88$1e6cb740$4001a8c0@gateway.2wire.net> From: t.petch To: gorry fairhurst , References: <7e15ff36dba70a22991f302a01a5f5fd.squirrel@www.erg.abdn.ac.uk> Date: Fri, 21 Dec 2012 14:32:59 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.69] X-OriginatorOrg: btconnect.com Subject: Re: [tsvwg] tsvwg status - December 2012 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 14:35:17 -0000 Gorry RFC6535 is Subject: RFC 6535 on Dual-Stack Hosts Using "Bump-in-the-Host" (BIH) From: To: Sent: Thursday, December 20, 2012 8:39 AM Subject: [tsvwg] tsvwg status - December 2012 The list below shows the status of the working group documents as we see it. Please check below and comment on drafts using the list. Please do send any corrections/omissions to the chairs. Best wishes, Gorry, David & James (TSVWG Chairs) --- Recently published: draft-ietf-tsvwg-rsvp-security-groupkeying was published as RFC 6411. draft-ietf-tsvwg-sctpsocket was published as RFC 6458. draft-ietf-tsvwg-sctp-strrst was published as RFC 6535. draft-ietf-tsvwg-source-quench was published as RFC 6633. ------------------------------------------------------------------- IDs in RFC Editor Queue: http://www.rfc-editor.org/queue.html None. ------------------------------------------------------------------- IDs in IESG processing: draft-ietf-tsvwg-sctp-udp-encap (Replaced: draft-tuexen-sctp-udp-encap) Lars sent a note as AD agreeing to progress this work. Work was coordinated with DCCP work on encaps. draft-tuexen-sctp-udp-encaps-06, January 10, 2011 Adopted as a work item 21 Sept 2011 (Gorry) WG -02 8 Dec 2011 WGLC completed Friday 20th April 2012, many discussion and notes that there were implementations (including: FreeBSD and released in 9.1 & MacOS X) ID was ready for AD submission, 20th Oct 2012 Checked IANA port usage. STATUS: Write-up sent to AD. --- draft-ietf-tsvwg-byte-pkt-congest New editor added Jul 2010. New revision 25 Oct 2010. WG -01, June 10, 2011 IETF-81: discussed whether this should be BCP. ADs & Chairs agree to progress as a BCP Status changed to BCP (new-ID WG -05) Presented at IETF-82 (Taipei), request for WGLC. Gorry added as Shepherd (Jan 2012), Wes added as responsible AD (Jun 2012). WGLC concluded with comments on I-D, Friday 30th March 2012. Draft version of write-up sent to list, comments received. - Gorry working with authors to clear list of WGLC questions (5 sept 2012). WG Chair received version that includes additional feedback during WGLC STATUS: Write-up sent to AD. ------------------------------------------------------------------- WG Drafts with Chairs: None. ------------------------------------------------------------------- WG Drafts: draft-ietf-tsvwg-rsvp-pcn Previous version : draft-karagiannis-pcn-tsvwg-rsvp-pcn WG interest in this topic recorded at IETF-81. Individual -01, 2011-07-11 AD decision allowed this to be added to the milestones The document was adopted, status will be EXP (IETF-84 due to dependencies on PCN RFCs) WG -00 8 Oct 2011 RSVP-DIR review requested 13th Oct 2012 DUE: Please comment on RVSP & PCN aspects --- draft-ietf-tsvwg-natsupp-tsvwg (Replaced: draft-stewart-natsupp-tsvwg) http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-natsupp/ Dependency from BEHAVE WG. Adopted as a work item 21 Sept 2010 (Gorry). WG -00, 29/11/2010 Uploaded as: draft-ietf-natsupp-tsvwg WG -01, June 1, 2011 Authors restructured draft (-03) - Done for single home - Concept done for multihome, no spec DUE: Please comment on list. --- draft-ietf-tsvwg-sctp-failover replaces: draft-nishida-tsvwg-sctp-failover Individual-00 Presented in Prague, IETF-80. - understood not to conflict with draft-tuexen-tsvwg-sctp-multipath - PF has been coded into FreeBSD WG adoption was approved - request to comment to list on 26/6/2012. Adopted by WG. --- draft-ietf-tsvwg-intserv-multiple-tspec WG interest in this topic recorded at IETF-78. Charter update would be needed to progress this work. 5 Reviews needed to determine energy/technical direction. WG -05 (presented in Beijing, IETF-79) WG -06 (presented in Prague, IETF-80) RSVP directorate was consulted. 2 reviews from RSVP-DIR received (Bruce Davie, ?) 2 additional reviews promised (Ken Carlberg, Francois LeF) Chairs asked AD for a Charter update (IESG agreed) Draft discussed at IETF-80, and request to update charter agreed - AD advised 4 named reviewers will be required Adopted for progression as PS, for May 2012 - New approach presented following WG comments DUE: Discussion needed on list. --- draft-ietf-tsvwg-port-use-00 (replaces draft-touch-tsvwg-port-use-00) - Intended to be advice to protocol designers needing a port. 5 people have looked at this document, Prague IETF-80 Individual -01 July 2011 IETF-81 insufficient feedback from WG at this time. WG needs to assess if the new draft should be a work item. IETF-82, discussed - Chairs will ask WG to consider. Adopted by WG DUE: Revised ID expected to complete missing sections & include feedback from IETF-85 --- draft-polk-tsvwg-rsvp-app-id-vv-profiles -01 Presented in Beijing, IETF-79. -02, 14-Mar-2011 Presented IET-80. WG needs to assess if the new draft should be a work item. Seek to coordinate with music with partner ID: draft-polk-mmusic-traffic-class-for-sdp Author requests to make a WG work item... Gorry liaised with MMUSIC WG Chairs on companion draft, intended for LC early 2013. Adopted as a TSVWG work item - December 2012. DUE: Waiting for author to respond with milestone date. ------------------------------------------------------------------- WG action required: WGLC: UDP/IPv6 draft-ietf-6man-udpzero Previously: draft-fairhurst-tsvwg-6man-udpzero Related draft: draft-ietf-6man-udpchecksums-00 This draft was also LC'ed in TSVWG (end 3rd May 2012) DUE: Updated to become a BCP applicability statement - new WGLC in TSVWG started for 26 Dec 2012. --- Adoption call: SCTP/DTLS draft-tuexen-tsvwg-sctp-dtls-encaps-01 Implemented in Firefox, Chrome interested. This adoption call will conclude 3rd January 2013. DUE: Please confirm adoption by working group on mailing list. Responses to call: [MB:TD:SL] --- Adoption call: SCTP/SACK-Immediately draft-tuexen-tsvwg-sctp-sack-immediately -05, 2011-01-02 - Aug 2011, discussed on list and issues raised. - Implemented in BSD & Linux This adoption call will conclude 3rd January 2013. DUE: Please confirm adoption by working group on mailing list. Responses to call: [MB:TD:SL] ------------------------------------------------------------------- The following have received recent discussion at TSVWG meetings or on the list. Inclusion in the list below does not indicate support for these specific drafts and other contributions are also warmly welcomed. draft-polk-tsvwg-rfc4594-update Discussed at IETF-83, Paris - noted at IETF-84, but not discussed (no time). DUE: Please comment on list. --- draft-polk-tsvwg-new-dscp-assignments - noted at IETF-84, but not discussed (no time). DUE: Please comment on list. --- draft-stewart-tsvwg-sctpecn-02Partially replaces (draft-stewart-tsvwg-sctp-nonce) IETF-78 suggested there was interest in this topic. Discussed at IETF-83, Paris. DUE: ECN was confirmed to be within the TSVWG Charter DUE: A call for adoption will be made on the list, please comment on this draft contents. --- draft-tuexen-tsvwg-sctp-multipath (CMT) -00 Presented in Prague, IETF-80. - understood not to conflict with draft-nishida-tsvwg-sctp-failover - Implemented in FreeBSD (ns2, inet) - subsumes NR-SACK -01, 2010-12-27 DUE: Please comment to list. DUE: Need to decide if this can be adopted as a WG Item --- draft-carlberg-tsvwg-ecn-reactions Reactions to Signaling from ECN Support for RTP/RTCP -00 presented IETF-82 Not yet requested to become a work item. - This draft is related to the new rmcat work. DUE: Please comment on list. ------------------------------------------------------------------- Related non-TSVWG items: draft-ietf-behave-sctpnat-03.txt BEHAVE WG item linked to SCTP encapsulation work. draft-ohanlon-rmcat-dflow Discussed at IETF-84, Vancouver This draft is related to the new rmcat work. Comments received on list prior to IETF-85. DUE: Revised ID needed ------------------------------------------------------------------ Other news: RSVP Directorate (formed in May 2010) Charter updated Aug 2011. New co-chair: Rolf Winter ITU-T Study Group 12 Liaison on QoS Classes & markings for interconnection ------------------------------------------------------------------ Other draft history: draft-ietf-behave-sctpnat-03.txt waiting on: draft-ietf-tsvwg-natsupp-04 --- draft-briscoe-tsvwg-ecn-encap-guidelines -00 Presented in Prague, IETF-80. - comments at IETF-80 (see minutes) Authors need to update this draft. DUE: Please comment on list. DUE: Please check liaison status with other SDOs. From internet-drafts@ietf.org Sun Dec 23 08:14:49 2012 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 1F91B21F8A8C; Sun, 23 Dec 2012 08:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.983 X-Spam-Level: X-Spam-Status: No, score=-101.983 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aM5DSc9zCnxH; Sun, 23 Dec 2012 08:14:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF4221F8AA5; Sun, 23 Dec 2012 08:14:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121223161447.27812.5942.idtracker@ietfa.amsl.com> Date: Sun, 23 Dec 2012 08:14:47 -0800 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-udp-encaps-07.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 16:14:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working Grou= p of the IETF. Title : UDP Encapsulation of SCTP Packets Author(s) : Michael Tuexen Randall R. Stewart Filename : draft-ietf-tsvwg-sctp-udp-encaps-07.txt Pages : 10 Date : 2012-12-23 Abstract: This document describes a simple method of encapsulating SCTP Packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NAT not supporting SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP-layer, for example implementing it as part of the application without requiring special privileges. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-udp-encaps There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-udp-encaps-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-sctp-udp-encaps-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From david.black@emc.com Fri Dec 28 13:43:50 2012 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 3A23121F8E0B for ; Fri, 28 Dec 2012 13:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.715 X-Spam-Level: X-Spam-Status: No, score=-102.715 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkVDXBIld9ef for ; Fri, 28 Dec 2012 13:43:48 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id BB06D21F8E09 for ; Fri, 28 Dec 2012 13:43:48 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qBSLhlQT014744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 28 Dec 2012 16:43:47 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Fri, 28 Dec 2012 16:43:37 -0500 Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qBSLhaCm022241 for ; Fri, 28 Dec 2012 16:43:36 -0500 Received: from mxhub40.corp.emc.com (128.222.70.107) by mxhub10.corp.emc.com (10.254.92.105) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 28 Dec 2012 16:43:36 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub40.corp.emc.com ([128.222.70.107]) with mapi; Fri, 28 Dec 2012 16:43:36 -0500 From: "Black, David" To: "tsvwg@ietf.org" Date: Fri, 28 Dec 2012 16:43:35 -0500 Thread-Topic: Diffserv classes (rfc4594bis): Check on Atlanta "hum" Thread-Index: Ac3Kk+lc4r+wsGOrTG27ykn3TJxxqwBHImFQBmTTWgA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE71287CBF072@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71284D3FF1A@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [tsvwg] Diffserv classes (rfc4594bis): Check on Atlanta "hum" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2012 21:43:50 -0000 Ok, this topic has had sufficient "soak time" - having seen no objections, the Atlanta "hum" on Diffserv Classes is confirmed as the rough consensus of the tsvwg WG: > Restating - the sense of the room in Atlanta was that interactive > media (e.g., multi-media conferencing) needs to be broken out of the > existing diffserv media classes into at least one new class. As promised, I will work with James on the next steps: > If the sense of the room in Atlanta is confirmed, the next steps on > Diffserv Classes are that I will work with James to come up with a list > of all the things that he's proposing to change in > draft-polk-tsvwg-rfc4594-update and ask the list whether each one > of them needs attention (single subject/question emails). My preference is to get the answers to those questions before asking whether the tsvwg WG should adopt that draft as a WG draft. Thanks, --David (tsvwg WG co-chair) ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.black@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: Monday, November 26, 2012 3:47 AM > To: Black, David > Cc: tsvwg@ietf.org > Subject: RE: Diffserv classes (rfc4594bis): Check on Atlanta "hum" >=20 > David, >=20 > again thanks for a well formulated proposal. >=20 > After a brief talk with my audio/video QoE experts I agree > to differing telecoferencing (or whatever we call it) from > streaming in DiffServ standards. >=20 > I see a need to clarify aggregation of DiffServ classes, > if a revised RFC5127 or a revised RFC4594 are put on > standards track. I'm having issues with RFC5127. >=20 > And a side one: terminology may be an issue - we all > use "classes" in our exchanges and Brian correctly pointed > out that it is not as well defined as major parts of the > DiffServ terminology (which, I think, we however hardly use). >=20 > Regards, >=20 > R=FCdiger >=20 > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of > Black, David > Sent: Saturday, November 24, 2012 11:35 PM > To: tsvwg@ietf.org > Subject: [tsvwg] Diffserv classes (rfc4594bis): Check on Atlanta "hum" >=20 > Hello - this is your new tsvwg co-chair, with . >=20 > The Atlanta tsvwg minutes are at: > http://www.ietf.org/proceedings/85/minutes/minutes-85-tsvwg >=20 > Many thanks to Ken and Mirja for being the note-takers. I have two > action items from the Thursday diffserv-oriented meeting - this > message is about the first, the possible update to the Diffserv > Classes RFC (RFC 4594). >=20 > Excerpt from the minutes (slightly edited/corrected): > --------------- > - (David Black) there is a suggestion that multi-media conferencing > was not properly supported when Diffserv Classes were first defined. >=20 > So, what does the room think about this? Audience "hum" thinks > James Polk is correct and that a new more granular class is needed. > Particularly, RFCs 4594 and 5127 need some work. >=20 > Black states that we need to put this on the list and discuss how > many more things we need to fix. > --------------- >=20 > Restating - the sense of the room in Atlanta was that interactive > media (e.g., multi-media conferencing) needs to be broken out of the > existing diffserv media classes into at least one new class. >=20 > If anyone disagrees with that sense of the room in Atlanta, please > speak up now (please review the appropriate portion of the Atlanta > minutes first). >=20 > Caveat: this topic and email are entirely about Diffserv Classes, i.e., > revising RFC 4594. If RFC 4594 is revised, RFC 5127 on diffserv class > aggregation will need a corresponding update to fit the new classes > into its aggregates. This email is *not* about the discussion > of diffserv usage for interconnection (e.g., the ITU-T SG12 liaison). > That interconnection topic may or may not involve a revision to RFC > 5127 (e.g., it could be done in an entirely new document) and will > be covered in a separate email thread; please wait for it. >=20 > If the sense of the room in Atlanta is confirmed, the next steps on > Diffserv Classes are that I will work with James to come up with a list > of all the things that he's proposing to change in > draft-polk-tsvwg-rfc4594-update and ask the list whether each one > of them needs attention (single subject/question emails). >=20 > In particular, this is *not* a call for whether tsvwg should adopt > draft-polk-tsvwg-rfc4594-update - the initial steps are to figure > out the scope of work that should be done. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 >=20 From david.black@emc.com Fri Dec 28 14:39:13 2012 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 958F421F8E34 for ; Fri, 28 Dec 2012 14:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTYqIrzrKphx for ; Fri, 28 Dec 2012 14:39:12 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 48F7521F8E2E for ; Fri, 28 Dec 2012 14:39:11 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qBSMdAFa029661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 28 Dec 2012 17:39:10 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Fri, 28 Dec 2012 17:38:56 -0500 Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.222.70.203]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qBSMcroo013891 for ; Fri, 28 Dec 2012 17:38:55 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub06.corp.emc.com ([128.222.70.203]) with mapi; Fri, 28 Dec 2012 17:38:54 -0500 From: "Black, David" To: "tsvwg@ietf.org" Date: Fri, 28 Dec 2012 17:38:53 -0500 Thread-Topic: Diffserv for interconnection - Atlanta "hum" confirmation Thread-Index: Ac3KljebdjQRdxroSiOKNiDbMqMC/AatI9gw Message-ID: <8D3D17ACE214DC429325B2B98F3AE71287CBF082@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71284D3FF1B@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71284D3FF1B@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [tsvwg] Diffserv for interconnection - Atlanta "hum" confirmation X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2012 22:39:14 -0000 This topic has also had sufficient "soak time" and hence having seen no objections, the Atlanta "hum" on diffserv for interconnection is confirmed as the rough consensus of the tsvwg WG: > The item that I recall asking about was whether the IETF should work on a > single set of recommended diffserv behavior (PHBs) and codepoints (DSCPs) > for use in carrier interconnection? >=20 > The sense of the room in Atlanta (as noted in the minutes) was that the > IETF should work on this, with details of how to do that TBD - in > particular there was no assumption about the relationship of this work > to RFC 5127 on aggregation of Diffserv Classes (e.g., if undertaken, > this new work may or may not be carried out by revising RFC 5127). The next step is going to take a little while: > If the sense of the room in Atlanta is confirmed, the next action is > for me to work through the ITU-T SG12 liaison (primarily the draft of > y.qosmap) and consult with Ruediger about what makes sense before > bringing a proposal for what to do back to this list. I will send a separate note on RFC 5160 shortly, and do intend to work through the liaison material in order to get a proposal for what to do out to the list in time for it to be an input to the liaison response to SG12 that is due at the end of February.=20 Thanks, --David (tsvwg WG co-chair) ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Black, David > Sent: Saturday, November 24, 2012 5:51 PM > To: tsvwg@ietf.org > Cc: Black, David > Subject: Diffserv for interconnection >=20 > Hello - this is your new tsvwg co-chair again, with . >=20 > The Atlanta tsvwg minutes are at: > http://www.ietf.org/proceedings/85/minutes/minutes-85-tsvwg >=20 > This message is about my second action item, on use of Diffserv for > network interconnection. >=20 > Excerpt from the minutes (explanation below): > --------------- > Topic: interconnect liaison with ITU-T > - (James Polk) describing set of code points (?) for the interconnection > of core providers. > - (Gorry Fairhurst) asks if we should make a new set of recommendations f= or > a particular interface. > - (David Black) thinks we should. As Chair, he asks the room if we should > work on this? The room (by show of hands) indicates yes. > So we'll put this on the list > (Joel Halpern) thinks we don't need to do anymore at this meeting. We > should state "this is an interesting problem, and we should do > something about this" > --------------- >=20 > So the immediate question is what was "this" in Joel's comment? >=20 > The short answer is that it's slide 6 in this set of slides: > http://www.ietf.org/proceedings/85/slides/slides-85-tsvwg-8.pdf >=20 > The rationale for doing "this" is also on that slide - it's basically > scaling/reuse of configuration, so that a carrier or operator can apply > a single diffserv configuration to interconnections with multiple other > networks. Also see draft-geib-tsvwg-diffserv-intercon-00 . >=20 > The item that I recall asking about was whether the IETF should work on a > single set of recommended diffserv behavior (PHBs) and codepoints (DSCPs) > for use in carrier interconnection? >=20 > The sense of the room in Atlanta (as noted in the minutes) was that the > IETF should work on this, with details of how to do that TBD - in > particular there was no assumption about the relationship of this work > to RFC 5127 on aggregation of Diffserv Classes (e.g., if undertaken, > this new work may or may not be carried out by revising RFC 5127). >=20 > If anyone disagrees with the sense of the room in Atlanta, now would > be a good time to speak up. >=20 > If the sense of the room in Atlanta is confirmed, the next action is > for me to work through the ITU-T SG12 liaison (primarily the draft of > y.qosmap) and consult with Ruediger about what makes sense before > bringing a proposal for what to do back to this list. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- From david.black@emc.com Fri Dec 28 15:21:29 2012 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 B53F121F8E2A for ; Fri, 28 Dec 2012 15:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSGzQwJaxsRh for ; Fri, 28 Dec 2012 15:21:28 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4C73D21F8E18 for ; Fri, 28 Dec 2012 15:21:27 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qBSNLQmN013709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Dec 2012 18:21:26 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Fri, 28 Dec 2012 18:21:20 -0500 Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qBSNLJAu009787; Fri, 28 Dec 2012 18:21:19 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub10.corp.emc.com ([10.254.92.105]) with mapi; Fri, 28 Dec 2012 18:21:19 -0500 From: "Black, David" To: "Ruediger.Geib@telekom.de" , "mohamed.boucadair@orange.com" Date: Fri, 28 Dec 2012 18:21:18 -0500 Thread-Topic: RFC 5160 and Diffserv for interconnection Thread-Index: Ac3KljebdjQRdxroSiOKNiDbMqMC/ABF5BIQAAKa+bAE6CfYkAF9A5ew Message-ID: <8D3D17ACE214DC429325B2B98F3AE71287CBF08E@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71284D3FF1B@MX15A.corp.emc.com> <94C682931C08B048B7A8645303FDC9F36E98722964@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "pierre.levis@orange.com" , "tsvwg@ietf.org" , "christian.jacquenet@orange.com" Subject: [tsvwg] RFC 5160 and Diffserv for interconnection X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2012 23:21:29 -0000 I've also taken a look at RFC 5160, and have some comments as an individual who's worked on QoS at the IETF, not as a WG co-chair. Like Ruediger, I'm pleased to see agreement on the value of "standardizing a very limited set of interconnection classes". I note that RFC 5160 was published as an RFC Editor independent submission, so its status is indicated by the IESG Note on page 1: This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and notes that the decision to publish is not based on IETF review apart from IESG review for conflict with IETF work. The RFC Editor has chosen to publish this document at its discretion. See RFC 3932 for more information. I do appreciate the authors introducing RFC 5160 as interesting input, and as input, it's interesting (thank you), but I don't believe that it should be treated as more than interesting input. For that reason, while there are a number of things in RFC 5160 that I don't agree with (e.g., I concur with Ruediger's critique of the D,J,L framework), much of that is not relevant to this discussion, as I see no problem with considering interesting input and then deciding to do something else. The core mechanism for interconnection QoS in RFC 5160 is the cross-domain binding of Local QoS Classes described in Section 5.2. As I understand Ruediger's critique of current Diffserv interconnection practices, that cross domain binding mechanism is an example of the per-peer QoS mapping that currently prevails - for a discussion of why that can be problematic, see Section 3 of draft-geib-tsvwg-diffserv-intercon-00.txt . RFC 5160 then proceeds to constrain that per-peer QoS mapping via a notion of Meta-QOS-Classes, but it doesn't seem to proceed beyond an abstract level in developing that concept in Section 5.3. In contrast, to render the proposed Diffserv for interconnection work into RFC 5160's terminology framework, the proposed work is to use the existing Diffserv specifications as the basis for standardizing a small number of Meta-QOS-Classes (Diffserv PHBs) and associated codepoints (Diffserv DSCPs) for use in network interconnection. This is intended to enable a network operator to map traffic between their network-internal QoS management framework and a single standardized set of PHBs and codepoints at network edges in order to obtain QoS behavior across interconnections with other networks (as opposed to having to do such mapping on a per-peer-network basis). Thanks, --David (as individual, not WG co-chair) > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of > Ruediger.Geib@telekom.de > Sent: Friday, December 21, 2012 4:49 AM > To: mohamed.boucadair@orange.com > Cc: pierre.levis@orange.com; tsvwg@ietf.org; christian.jacquenet@orange.c= om > Subject: Re: [tsvwg] Diffserv for interconnection >=20 > Dear Med, >=20 > after having read RFC5160, I'm happy that you agree that an > interconnection class and codepoint scheme and RFC5160 > complement each other. I'll add a reference, when I update > my draft. >=20 > I may come back with questions on some details, but there's > one point which I'd like to discuss. >=20 > Your terminology is quite clear about >=20 > Local-QoS-Class (l-QC) >=20 > A QoS transfer capability across a single domain, characterized by > a set of QoS performance parameters denoted by (D, J, L). From a > Diffserv [RFC2475] perspective, an l-QC is an occurrence of a Per > Domain Behavior (PDB) [RFC3086]. >=20 > From what I know, a PDB may be optimised for cetrtain kinds of traffic: > pure VoIP RTP or TCP, to give examples. Traffic conditioning and > scheduling may be optimised on the recommended usage of a class. If > that's the case, then first there's the PDB or class specification on > a level closer to transport or application and then there's a > description by SLA properties. >=20 > Taking it the other way around: by just looking at SLA properties > D, J, L and a PDB name (which may not be standardised), > interconnection QoS may not always work as desired. Especially > with AF classes. >=20 > What I propose is to add some explaining text in a document we > would have to agree on (maybe my draft, could be any other). That > may be done in a way as proposed by > http://tools.ietf.org/html/rfc3086#section-8. >=20 > What's left for me this year is wishing merry christmas to those > celebrating and a relaxed and good start into 2013 to those > who don't >=20 > R=FCdiger >=20 >=20 > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Monday, November 26, 2012 11:23 AM > To: Geib, R=FCdiger; david.black@emc.com > Cc: LEVIS Pierre OLNC/OLPS; tsvwg@ietf.org; JACQUENET Christian OLNC/OLN > Subject: RE: Diffserv for interconnection >=20 > Dear Ruediger, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > >-----Message d'origine----- > >De : tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] De > >la part de Ruediger.Geib@telekom.de > >Envoy=E9 : lundi 26 novembre 2012 09:30 > >=C0 : david.black@emc.com > >Cc : LEVIS Pierre OLNC/OLPS; tsvwg@ietf.org; JACQUENET > >Christian OLNC/OLN > >Objet : Re: [tsvwg] Diffserv for interconnection > > > >David, > > > >thanks. I submitted a draft on the issue and I'm also involved > >in the ITU liaision. > > > >Yes, to me IETF should pick up the subject of limited and > >"well enough defined" > >set of interconnection QoS classes. > > > >I've reread RFC5127. If it stays informational, I got no > >qualms with it. If a revised > >version of RFC5127 ist to be put on standards track, some > >parts of it must be > >better explained and possibly rewritten. If it is not touched, > >some parts of what > >is required in a revised 5127 from my point of view should > >become part of the > >interconnection work. > > > >I'm halfway through http://tools.ietf.org/html/rfc5160 and the > >authors asked how I'd > >position my proposal with regard it. It is a more abstract > >document about > >inter provider QoS agreements. >=20 > Med: FWIW, the rationale we adopted in RFC5160 is as follows: >=20 > * Network Providers are free to define their own traffic engineering poli= cies > and their QoS class of services in their domains. > * Diffserv is only a means among other to achieve differentiated forwardi= ng > * The number and the definition of QoS classes is not universal > * Network Providers are not obliged to expose their internal class of ser= vices > to external parties > * When extending some QoS classes beyond the boundaries of a given domain= , it > is required to establish contractual agreements between network providers= , > otherwise the traffic will be handed as BE. > * These agreements will be the place where class identification is discus= sed > and agreed. > * Remarking is likely to be always enforced in both exit border router an= d > entry border router: local class of services are not advertised outside t= he > domain. > * Providers need a tool to help deciding how to bind one/multiple local Q= oS > classes with adjacent class of service: hence the concept of meta-QoS-Cla= ss. > * CoS identifier is not sufficient to provide QoS: additional parameters = are > to be agreed between network providers. Examples of these parameters are: > constraints on the traffic (eg., tcp-friendly), network resources for the > class / overall traffic using this class, etc. >=20 >=20 > So far I think, RFC5160 and the > >proposals of my > >draft would complement each other. >=20 > Med: Agreed. I personally see a value in standardizing a very limited set= of > interconnection classes. In addition to the interconnection class > name/identifier discussion point, it is important also to have a detailed > definition of the class itself (in terms of attributes, target services, > traffic conditions, etc.). Perhaps, try the > http://tools.ietf.org/html/rfc3086#section-8 ;-)? >=20 > > > >Regards, > > > >R=FCdiger > > > > > > > >-----Original Message----- > >From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] > >On Behalf Of Black, David > >Sent: Saturday, November 24, 2012 11:51 PM > >To: tsvwg@ietf.org > >Subject: [tsvwg] Diffserv for interconnection > > > >Hello - this is your new tsvwg co-chair again, with . > > > >The Atlanta tsvwg minutes are at: > > http://www.ietf.org/proceedings/85/minutes/minutes-85-tsvwg > > > >This message is about my second action item, on use of Diffserv for > >network interconnection. > > > >Excerpt from the minutes (explanation below): > >--------------- > >Topic: interconnect liaison with ITU-T > >- (James Polk) describing set of code points (?) for the > >interconnection > > of core providers. > >- (Gorry Fairhurst) asks if we should make a new set of > >recommendations for > > a particular interface. > >- (David Black) thinks we should. As Chair, he asks the room > >if we should > > work on this? The room (by show of hands) indicates yes. > > So we'll put this on the list > >(Joel Halpern) thinks we don't need to do anymore at this meeting. We > > should state "this is an interesting problem, and we should do > > something about this" > >--------------- > > > >So the immediate question is what was "this" in Joel's comment? > > > >The short answer is that it's slide 6 in this set of slides: > > http://www.ietf.org/proceedings/85/slides/slides-85-tsvwg-8.pdf > > > >The rationale for doing "this" is also on that slide - it's basically > >scaling/reuse of configuration, so that a carrier or operator can apply > >a single diffserv configuration to interconnections with multiple other > >networks. Also see draft-geib-tsvwg-diffserv-intercon-00 . > > > >The item that I recall asking about was whether the IETF > >should work on a > >single set of recommended diffserv behavior (PHBs) and > >codepoints (DSCPs) > >for use in carrier interconnection? > > > >The sense of the room in Atlanta (as noted in the minutes) was that the > >IETF should work on this, with details of how to do that TBD - in > >particular there was no assumption about the relationship of this work > >to RFC 5127 on aggregation of Diffserv Classes (e.g., if undertaken, > >this new work may or may not be carried out by revising RFC 5127). > > > >If anyone disagrees with the sense of the room in Atlanta, now would > >be a good time to speak up. > > > >If the sense of the room in Atlanta is confirmed, the next action is > >for me to work through the ITU-T SG12 liaison (primarily the draft of > >y.qosmap) and consult with Ruediger about what makes sense before > >bringing a proposal for what to do back to this list. > > > >Thanks, > >--David > >---------------------------------------------------- > >David L. Black, Distinguished Engineer > >EMC Corporation, 176 South St., Hopkinton, MA 01748 > >+1 (508) 293-7953 FAX: +1 (508) 293-7786 > >david.black@emc.com Mobile: +1 (978) 394-7754 > >---------------------------------------------------- > > > >