From evnikita2@gmail.com Sun Jan 2 01:40:44 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 899B83A698F for ; Sun, 2 Jan 2011 01:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=-0.638, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7T-Cjs5OSEHc for ; Sun, 2 Jan 2011 01:40:42 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 5547A3A698E for ; Sun, 2 Jan 2011 01:40:42 -0800 (PST) Received: by bwz12 with SMTP id 12so12887262bwz.31 for ; Sun, 02 Jan 2011 01:42:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type; bh=0jWa3Ww2o75mh6wWqaXWm037xBh35WOOqsn9uSw8Zvs=; b=szH6Z3YqTl67ojtmwT8EmiU8d38SRNYZZGnC3pZJj6oxEBkrE1CIZnB8c76s6AHQqx im11J6d/ljaSsOxh6EeL99/LCTyIUGwC86i0/Vle9brSNHQ2GPY4kOc6Jp1gL6PahGdN xn7Z53E0WlVrUGUa1ktg8jGJPWOjVN7SX/j50= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; b=szLL+xT/LguCwTY3mc+3wXlYBNFcGZL2KuAzIlusU5kNTMs2S4LT4C6dRevxv5vMnP jfjud4OiHTzwxvyF07rtE5e+qVYYrIv9irp+c0lbGQByrgi9dhU1DWYeIdsLUFyJ7yOZ ml5gkaCXnsZW93wlkVu0juOE8DLR6TF9brqHI= Received: by 10.204.115.73 with SMTP id h9mr234572bkq.22.1293961366246; Sun, 02 Jan 2011 01:42:46 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id v1sm10857636bkt.17.2011.01.02.01.42.43 (version=SSLv3 cipher=RC4-MD5); Sun, 02 Jan 2011 01:42:44 -0800 (PST) Message-ID: <4D2048A5.8090106@gmail.com> Date: Sun, 02 Jan 2011 11:43:01 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: John C Klensin Subject: Re: draft-yevstifeyev-netblt-iana-00.txt References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030203070408020306030006" Cc: jccw@jccw.org, John C C White , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 09:40:44 -0000 This is a multi-part message in MIME format. --------------030203070408020306030006 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit John, all, I have read the document you mentioned (MIL-STD-.....). And the only thing I found interesting on these 111 pages is that the port number 1 is used for TACO2 and what mentioned in section 6.2 of it. As for White's draft. If he could kindly allow me to be the co-author of the document, I would like to work on this document. So, as I have applied for adopting my drafts as WG items, I ask to mention the corresponding port number (1) for TACO2 in /draft-yevstifeyev-netblt-iana/ while publishing it as WG draft (if that would be approved). All the best, Mykyta Yevstifeyev 28.12.2010 18:54, John C Klensin wrote: > Mykyta, > > Are you aware of NetBLT actually being in active use in the > public Internet, in the form documented in RFC 998? I'm not, > but that sort of transport protocol isn't something I've paid > careful attention to in many years. > > John C C White's 1997 Internet-Draft, > http://tools.ietf.org/html/draft-white-protocol-stack-00, > suggests that, in its original form, NetBLT contained some > defects that made it undesirable in practice. That draft also > suggested an update that would align NetBLT with then-current > practice in some private (in this case military) network > applications. As far as I can tell, that update never went > anywhere in the IETF, but that is (sadly) typical of such things > if no one is pushing for it. > > Especially if there is not significant evidence of its being in > active use in RFC 998 form on the public Internet, it might be > worthwhile to combine your effort to get the IANA registry in > order with some version or variation on John's draft so as to > bring the protocol itself up-to-date. > > The information on the standard to which John referred is at > http://www.gwg.nga.mil/ntb/baseline/docs/44500/index.html; it > doesn't appear to have changed much since his draft was produced. > > Even if it isn't useful to try to publish an updated version of > the specification, it would probably be desirable to get any > non-998 values used by the military standard into the registry > as well. > > I've copied John on this note. Since I don't know if he is > still at MITRE, I've also copied what is possibly his current > address based on a web search. I have no idea whether he would > still be interested, but he should at least be aware that I'm > suggesting another look at his 13+ year old work. > > best regards and best new year's wishes to both of you, > john --------------030203070408020306030006 Content-Type: text/html; charset=windows-1251 Content-Transfer-Encoding: 7bit John, all,

I have read the document you mentioned (MIL-STD-.....). And the only thing I found interesting on these 111 pages is that the port number 1 is used for TACO2 and what mentioned in section 6.2 of it.

As for White's draft. If he could kindly allow me to be the co-author of the document, I would like to work on this document.

So, as I have applied for adopting my drafts as WG items, I ask to mention the corresponding port number (1) for TACO2 in draft-yevstifeyev-netblt-iana while publishing it as WG draft (if that would be approved).

All the best,
Mykyta Yevstifeyev

28.12.2010 18:54, John C Klensin wrote:
Mykyta,

Are you aware of NetBLT actually being in active use in the
public Internet, in the form documented in RFC 998?  I'm not,
but that sort of transport protocol isn't something I've paid
careful attention to in many years.

John C C White's 1997 Internet-Draft,
http://tools.ietf.org/html/draft-white-protocol-stack-00,
suggests that, in its original form, NetBLT contained some
defects that made it undesirable in practice.  That draft also
suggested an update that would align NetBLT with then-current
practice in some private (in this case military) network
applications.  As far as I can tell, that update never went
anywhere in the IETF, but that is (sadly) typical of such things
if no one is pushing for it.

Especially if there is not significant evidence of its being in
active use in RFC 998 form on the public Internet, it might be
worthwhile to combine your effort to get the IANA registry in
order with some version or variation on John's draft so as to
bring the protocol itself up-to-date.

The information on the standard to which John referred is at
http://www.gwg.nga.mil/ntb/baseline/docs/44500/index.html; it
doesn't appear to have changed much since his draft was produced.

Even if it isn't useful to try to publish an updated version of
the specification, it would probably be desirable to get any
non-998 values used by the military standard into the registry
as well.

I've copied John on this note.  Since I don't know if he is
still at MITRE, I've also copied what is possibly his current
address based on a web search.  I have no idea whether he would
still be interested, but he should at least be aware that I'm
suggesting another look at his 13+ year old work.

best regards and best new year's wishes to both of you,
    john

--------------030203070408020306030006-- From evnikita2@gmail.com Sun Jan 2 02:57:10 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 743263A6956 for ; Sun, 2 Jan 2011 02:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=-0.629, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1anhem30VRs for ; Sun, 2 Jan 2011 02:57:09 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 9DF0B3A6953 for ; Sun, 2 Jan 2011 02:57:08 -0800 (PST) Received: by bwz12 with SMTP id 12so12907784bwz.31 for ; Sun, 02 Jan 2011 02:59:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=bmDzveAWebZmHtvOnUAjRvMi2vFX0IOKnckakw1mY6A=; b=k/TNmBtfZfjwMhSzVJzroIF8F3VPbJh7ls/YREI78IxaXRUGbGYSwMxA1n3py8Qgjf shYUqn94xlLNlv4VH808dvFQ4tn4UFirT15fD4pPXSjN93KVW6WaoHJDVS0YgTXzo4j0 9pbBjno10FUX4BvmgyO1FfT7wANy0HdFDP7Os= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=hZSQWtdbfRiJeqWX9Y2ms4rP3I8bCAf+7qeFChtgbF3an+cfftdI5+J3Yk5HGjgi8N c1kUIuttZva7PrZLwCDEW6a59wY+sv1Mnl0qJDXG+yy+Nzd2pUaS3Ii67XLSi4C9PVJJ 6E6qDii61WSkEkU+iNCpvfkjqCKV4H9Vb4pYk= Received: by 10.204.53.148 with SMTP id m20mr7894917bkg.150.1293965953122; Sun, 02 Jan 2011 02:59:13 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id a17sm10894742bku.23.2011.01.02.02.59.09 (version=SSLv3 cipher=RC4-MD5); Sun, 02 Jan 2011 02:59:11 -0800 (PST) Message-ID: <4D205A8F.3060206@gmail.com> Date: Sun, 02 Jan 2011 12:59:27 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: David Borman Subject: Re: Draft Review request - EUDP References: <4CF630B9.2070901@gmail.com> <4CF65BD7.20304@gmail.com> <2C2B9319-37F5-478C-B2E8-5B4EB0223D47@weston.borman.com> In-Reply-To: <2C2B9319-37F5-478C-B2E8-5B4EB0223D47@weston.borman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 10:57:10 -0000 Hello all, Now, almost after the month, I am ready to comment some issues we were discussing about EUDP (that is http://tools.ietf.org/html/draft-yevstifeyev-eudp-04). So, please find some comments below... 01.12.2010 18:10, David Borman wrote: > On Dec 1, 2010, at 8:29 AM, Mykyta Yevstifeyev wrote: > >> 01.12.2010 13:52, Lars Eggert wrote: >>> Hi, >>> >>> On 2010-12-1, at 13:25, Mykyta Yevstifeyev wrote: >>>> I have recently made a draft which, IMO, will be interesting >>>> for the WG. You can find it here: >>>> >>>> http://datatracker.ietf.org/doc/draft-yevstifeyev-eudp/?include_text=1 >>>> >>>> Could you please review it? >>> This is not a useful proposal. Why? UDP is IP plus ports and a checksum. There is no feature negotiation, no state machine to be extended, etc. *at the protocol level*. >> IMO (and this is the main purpose of the EUDP) if some feature concerns any protocol or data which is to be put into payload of the protocol of some layer, the corresponding option should be put in 'this-layer' protocol header. Moreover, UDP provides core service while TCP or DCCP provide many features which can be just not needed. EUDP can provide (or not provide) any features except core ones. >> It is made to provide the choice of features. > I read the document, and adding option space to UDP is not interesting if you don't also have at least one useful option defined at the same time. There is no motivation to implement this with just the NOP and EOL options. In addition, as Lars points out, UDP does not have a state machine. This means that adding any new option will require that the option can either be safely ignored, or negotiation needs to be added to the option itself. That implies potentially sending UDP packets with just options, and no data. Or the applications have to do the option negotiation. > > So, yes, if you want to add options to UDP, this would be a way to do it, but first you need to have at least one useful option to make use of the new mechanism. David, now I have added a few options that, IMO, would be quite useful for possible users. So, they are: Echo request and response (see http://tools.ietf.org/html/draft-yevstifeyev-eudp-04#section-2.3.2.3) and (maybe the most important) Packet ID and Packet Acknowledgment (see http://tools.ietf.org/html/draft-yevstifeyev-eudp-04#section-2.3.2.5). These two provide the possibility to request the acknowledgment of single, unit packet. For more detailed analysis of this packet ACKs mechanism can be found at http://tools.ietf.org/html/draft-yevstifeyev-eudp-04#section-2.5 . >>> (Sure, applications using UDP have these things. But they can *already* put whatever they like into the payload anyway. There is no need for a common spec.) >>> >>> Plus, by using a different IP protocol number, it is pretty much guaranteed that middleboxes will simply drop this traffic. >> Why do you think that if there is unknown protocol code the traffic will be dropped? Currently there are 142 IP Protocol umbers and near 10 are really used. Will you prove that other 132 are being dropped? > Middle boxes that filter traffic tend to first block everything and then only allow through things that they understand, otherwise if they let through unknown traffic it provides a wide-open door for the middle box to be circumvented. I really do not understand why do you think so. What danger could the traffic with unknown protocol cause? And if it is e. g. 253 or 254 (experimentation), middleboxes definitely can't know what protocol is used. In this occasion they will ignore that traffic, you think? > -David Borman > Waiting for other comments. All the best, Mykyta Yevstifeyev >>> Lars >>> >>> PS: Meta comment: You have submitted quite a number of IDs lately (http://tools.ietf.org/id/yevstifeyev). I really do applaud your enthusiasm. But the vast majority of your IDs to me appear to be rather pointless. I encourage you to follow some WGs that interest you most more closely, in order to learn where your contributions would be most useful. I'm being blunt here - please don't be offended. I don't want you to turn away from the IETF in frustration because your contributions don't get traction; I want your contributions to matter. >> Thank you for advice. >> >> I hope I have explained everything clearly. >> >> All the best, >> Mykyta Yevstifeyev > From gorry@erg.abdn.ac.uk Mon Jan 3 07:54:57 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 183C03A6A04 for ; Mon, 3 Jan 2011 07:54:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dOsCxA9NMJG for ; Mon, 3 Jan 2011 07:54:56 -0800 (PST) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 4F0583A69FF for ; Mon, 3 Jan 2011 07:54:54 -0800 (PST) Received: from dhcp-204-182.erg.abdn.ac.uk ([IPv6:2001:630:241:204:c62c:3ff:fe0e:5393]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p03FuqUD001368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 3 Jan 2011 15:56:52 GMT Message-ID: <4D21F1C6.3030707@erg.abdn.ac.uk> Date: Mon, 03 Jan 2011 15:56:54 +0000 From: Gorry Fairhurst User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: tsvwg list Subject: TSVWG Status Update (Jan 2011) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: "tsvwg-chairs@tools.ietf.org" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 15:54:57 -0000 The email below gives a brief snapshot of the current WG status for Jan 2011. Please look at what needs to be done. Do send notes of any corrections to tsvwg-chairs@tools.ietf.org. Gorry James (TSVWG Chairs) ================================================================== RFC Published: draft-ietf-tsvwg-admitted-realtime-dscp-07 (RFC 5865) draft-ietf-tsvwg-rsvp-proxy-approaches-09 (RFC 5945) draft-ietf-tsvwg-rsvp-proxy-proto-11 (RFC 5946) draft-ietf-tsvwg-rsvp-l3vpn-07 (RFC 6016) draft-ietf-tsvwg-ecn-tunnel-10 (RFC6040) --- IDs in RFC Editor Queue: draft-ietf-tsvwg-emergency-rsvp-15 (MISREF) Norm. ref to router alert draft (in the INT-area WG) draft-ietf-tsvwg-port-randomization-09 (Auth-48: Awaiting Shepherd) James is Shepherd. draft-ietf-tsvwg-emergency-rsvp (MISREF) Norm. ref to router alert draft (in the INT-area WG) draft-ietf-tsvwg-sctp-chunk-flags-02 (RFC-Ed) was: draft-tuexen-tsvwg-sctp-chunk-flags. TSVWG supported adoption (6 people, concluded 3/6/2010). List of reviewers supplied by document editor. WGLC ended Sept 6th 2010. New revision 7th Sept 2010. Proto write-up sent by shepherd 22/9/2010. IETF Last Call ended 7/10/2010. With RFC-Ed Gorry is Shepherd. draft-ietf-tsvwg-dtls-for-sctp-06 Proto write-up sent by shepherd AUTH-48 (Auth-48: Awaiting E Rescorla) Gorry is Shepherd. ------------------------------------------------------------------- IDs in IESG processing: None. ------------------------------------------------------------------- WG Drafts with Chairs: draft-ietf-tsvwg-rsvp-security-groupkeying WGLC of previous version completed. SECDIR review comments received, and updated as version -05. Short WGLC to confirm new text ended August 11th 2010. New version 22-10-2010. Due: Proto write-up needed by shepherd. James is Shepherd. ------------------------------------------------------------------- WG Drafts: draft-ietf-tsvwg-sctpsocket Expecting WGLC. New revision 25 Oct 2010. This will require an apps area review in WGLC. Due: Please volunteer to review this draft in WGLC. Due: WGLC due January 2011. draft-ietf-tsvwg-sctp-strrst Dependency on this for IPFIX document with RFC-Ed. Benoit Claise to review for IPFIX New revision (-08) 25 Oct 2010. Text on race-condition to be updated before WGLC Due: Please volunteer to review this draft in WGLC. Due: WGLC due January 2011. draft-ietf-tsvwg-iana-ports New revision 25 Oct 2010. Please volunteer to review this draft in WGLC. This will require a multi-working group LC. ADs to advice on which WGs need to be a part of LC. AD review received 21/12/2010. Due: Please volunteer to review this draft in WGLC. Due: WGLC due January 2011. Gorry is Shepherd. draft-ietf-tsvwg-byte-pkt-congest New editor added Jul 2010. New revision 25 Oct 2010. Comments needed before deciding if ready for WGLC. draft-ietf-tsvwg-sctp-udp-encap was: draft-tuexen-sctp-udp-encap Lars sent a note as AD agreeing to progress this work. Work to be coordinated with DCCP work on encaps. Adopted as a work item 21 Sept 2010 (Gorry). No WG -00 draft. New revision expected. draft-ietf-tsvwg-natsupp-tsvwg was: draft-stewart-natsupp-tsvwg. Dependency from BEHAVE WG. Adopted as a work item 21 Sept 2010 (Gorry). WG -00, 29/11/2010 New revision expected. ------------------------------------------------------------------- WG action required: draft-gont-tsvwg-source-quench-01.txt IETF-79 suggested there was interest in this topic. Comments to list in 2010 from: Fred Baker, Antonio DeSimone, James Polk, Gorry Fairhurst, Andrew Yourtchenko, and others. WG needs to assess if the new draft should be a work item. ------------------------------------------------------------------- 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-stewart-tsvwg-sctp-nonce IETF-78 suggested there was interest in this topic. Please comment to list. Revised draft to be uploaded with new name. WG needs to assess if the new draft should be a work item. draft-polk-tsvwg-intserv-multiple-tspec RSVP directorate to be consulted. 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. Author will update -04. New revision expected. draft-lefaucheur-tsvwg-rsvp-multiple-preemption RSVP directorate to be consulted. - Reviewers: Bruce Davie (awaiting other reviews) WG needs to assess if this topic should be a work item. draft-wing-tsvwg-happy-eyeballs-sctp Please comment to list. draft-tuexen-tsvwg-sctp-multipath Please comment to list. draft-tuexen-tsvwg-sctp-sack-immediately Please comment to list. draft-lei-tsvwg-sctp-compr-requirements-profile Please comment to list. draft-wei-tsvwg-nested-header-compression Please comment to list. draft-nishida-tsvwg-sctp-failover Please comment to list. draft-narayanan-tsvwg-rsvp-resource-sharing Please comment to list. draft-polk-tsvwg-rsvp-app-id-vv-profiles Please comment to list. draft-nishida-natarajan-sctp-failover Please comment to list. draft-wei-tsvwg-nested-header-compression Please comment to list. ------------------------------------------------------------------- Related non-WG items: draft-fairhurst-tsvwg-6man-udpzero Draft was adopted by 6man, please discuss on the 6man list. This will be LC'ed in TSVWG also. draft-ietf-dccp-udpencap DCCP WG item linked to encaps (WGLC) draft-narayanan-tsvwg-rsvp-resource-sharing Authors will take this draft to CCAMP WG. draft-ietf-behave-sctpnat-03.txt BEHAVE WG item linked to SCTP encapsulation work. ------------------------------------------------------------------ Other news: RSVP Directorate (formed in May 2010) - Rules and guidelines to be formulated Charter to be updated to indicate procedure for adoption. ------------------------------------------------------------------ ------------------------------------------------------------------ From gorry@erg.abdn.ac.uk Mon Jan 3 08:00:03 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 944E43A6A0A for ; Mon, 3 Jan 2011 08:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frXIN+1md8Sw for ; Mon, 3 Jan 2011 08:00:02 -0800 (PST) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 31FC63A6980 for ; Mon, 3 Jan 2011 08:00:01 -0800 (PST) Received: from dhcp-204-182.erg.abdn.ac.uk ([IPv6:2001:630:241:204:c62c:3ff:fe0e:5393]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p03G23sB001636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 3 Jan 2011 16:02:03 GMT Message-ID: <4D21F2FC.2090000@erg.abdn.ac.uk> Date: Mon, 03 Jan 2011 16:02:04 +0000 From: Gorry Fairhurst User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: tsvwg list , "tsvwg-chairs@tools.ietf.org" Subject: Deprecation of ICMP Source Quench messages (draft-gont-tsvwg-source-quench) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 16:00:03 -0000 There was discussion of the draft below on the TSVWG list and at the last IETF meeting. Deprecation of ICMP Source Quench messages (draft-gont-tsvwg-source-quench) http://tools.ietf.org/html/draft-gont-tsvwg-source-quench-01 We'd welcome feedback to the list on the question below: "Does the WG believe this document effectively addresses an existing problem, and should this draft form the basis for a solution?" Please email the chairs and/or list if you support this as a work item, or have comments on the suitability of this draft as a TSVWG work item. Best wishes, Gorry & James (TSVWG Co-Chairs) From prenatar@cisco.com Thu Dec 9 13:08:32 2010 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E65E3A6BD8 for ; Thu, 9 Dec 2010 13:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.636 X-Spam-Level: X-Spam-Status: No, score=-5.636 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_48=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYvlcw1xGfTb for ; Thu, 9 Dec 2010 13:08:31 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 524CD3A6BD7 for ; Thu, 9 Dec 2010 13:08:31 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQIAP7TAE2tJV2c/2dsb2JhbACjFGkCeKUamxKFSgSEZIYVgxqEcQ X-IronPort-AV: E=Sophos;i="4.59,322,1288569600"; d="scan'208";a="190978543" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 09 Dec 2010 21:10:01 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id oB9LA08g022875; Thu, 9 Dec 2010 21:10:00 GMT Received: from xmb-rcd-208.cisco.com ([72.163.62.215]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Dec 2010 15:10:00 -0600 Received: from 171.70.225.252 ([171.70.225.252]) by XMB-RCD-208.cisco.com ([72.163.62.215]) with Microsoft Exchange Server HTTP-DAV ; Thu, 9 Dec 2010 21:10:00 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Subject: Re: quick failover in SCTP From: Preethi Natarajan To: Michael =?ISO-8859-1?B?VPx4ZW4=?= , Message-ID: Thread-Topic: quick failover in SCTP Thread-Index: ActpXb1cT6+HGFabQ0Owkx0dQ+FirQuh7kIa In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 09 Dec 2010 21:10:00.0900 (UTC) FILETIME=[70FB1840:01CB97E5] X-Mailman-Approved-At: Mon, 03 Jan 2011 08:09:15 -0800 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Thu, 09 Dec 2010 21:08:32 -0000 X-Original-Date: Thu, 09 Dec 2010 13:10:10 -0800 X-List-Received-Date: Thu, 09 Dec 2010 21:08:32 -0000 Hello all, A new version of the quick failover draft (draft-nishida-tsvwg-sctp-failover-01) is now available at http://www.ietf.org/id/draft-nishida-tsvwg-sctp-failover-01.txt. The failover algorithm details have been updated in Section 4.3 based on feedback from TSVWG. Please let us know if you have questions/comments. Thanks, Preethi On 10/11/10 9:02 AM, "Preethi Natarajan" wrote: > Michael, >=20 > Thanks for the insightful comments/suggestions. Please see my responses b= elow. >=20 >=20 > On 10/9/10 5:34 AM, "Michael T=FCxen" wr= ote: >=20 >> On Oct 9, 2010, at 12:04 PM, Yoshifumi Nishida wrote: >>=20 >>> Hello Michael, >>>=20 >>> Thanks for your response. >>>=20 >>> 2010/10/8 Michael T=FCxen : >>>> Hello Nishida-san, >>>>=20 >>>> OK, I thought about this some time and think it would be good >>>> to specify a way for a quick failover which can be implemented >>>> at the sender only. >>>> I would like to see some extensions to you suggestion: >>>> * Introduce a threshold (call it PFMR for now). >>>> Then use >>>> if (error counter > PMR) >>>> the path is inactive. >>>> if (error counter <=3D PMR) && (error counter > PFMR) >>>> the path is potentially failed. >>>> Using PFMR =3D 0 is what you suggest, PFMR=3DPMR gives >>>> the old behavior. >>>=20 >>> I thought similar thing and I agree with providing a way to disable PF. >>> I tend to agree with this idea, but one thing I'm not very sure is how >>> PFMR !=3D 0 && PFMR < PMR can be useful. >> I could image someone wanting to call a path potentially failed >> after 2 consecutive timer based retransmission instead of 1. >> Just being a bit more conservative. This might help deploying >> such a feature in SIGTRAN networks where CMT is not deployed. >> For CMT traffic, PFMR=3D=3D0 is the right choice, I guess. >> But I think PF is also very helpful in non-CMT scenarios. >=20 > Preethi: Good point. What you are suggesting is a tunable PFMR threshold = while > the current draft always assumes PFMR=3D0, the most aggressive behavior. I = don't > see how conservative PFMR values can be helpful but it may be a good idea= to > have it just in case. >=20 >=20 >>>> * Specify that you start sending HBs when the path is >>>> PF. Explicitly allow PFHB.interval=3D0, which >>>> I think is a good choice. Maybe we can just remove PFHB.interval. >>>=20 >>> Hmm. Sorry. I might not quite follow this point. >>> Does PFHB.interval=3D0 mean suppress sending HB during PF state? >> No. I mean just to send them every RTO. >> Having a specific interval allows this by setting PFHB.interval=3D0. >> I was just thinking whether one can remove the parameter and send >> the HB every RTO (and doubling it)... The same as using PFHB.interval=3D0. >=20 > Preethi: I agree. I don't think we need a PFHB.interval. In PF state, HBs= are > sent once every RTO. >=20 >=20 >>>> * Make sure that the following works: The application disabled HBs. >>>> When a path enters PF (or failed) HB are sent to get the path >>>> active again. If it is active, no HB should be send (since >>>> the application disables them). >=20 > Preethi: Michael can you clarify this a bit? Looks like we want to confir= m the > following -- apps can control only those HBs that get sent (or not sent) > during path failure. Apps do not have control over PF HBs; i.e., apps can= not > enable/disable PF HBs. Is that right? >=20 >>>> * Provide a way that applications are not bothered with >>>> state change notification related to PF when not explicitly >>>> subscribed. >=20 > Preethi: Good point. To clarify: when PF is on, apps will be notified onl= y > about PF-to-failure and failure-to-active state changes. Apps will not be > notified about active-to-PF state change. >=20 >>>>=20 >>>> * Make clear what to do when all paths are PF. >>>>=20 >>>> * Make clear what to do when all paths are failed. >>>>=20 >=20 > Preethi: I agree with both points. We can clarify these in the draft. >=20 > Thanks, > Preethi From klensin@jck.com Sun Jan 2 10:22:33 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1EA13A69B8 for ; Sun, 2 Jan 2011 10:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2keUCGoPaVy for ; Sun, 2 Jan 2011 10:22:32 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 1EC953A6925 for ; Sun, 2 Jan 2011 10:22:32 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PZSbW-000FAg-PX; Sun, 02 Jan 2011 13:24:31 -0500 Date: Sun, 02 Jan 2011 13:24:29 -0500 From: John C Klensin To: Mykyta Yevstifeyev Subject: Re: draft-yevstifeyev-netblt-iana-00.txt Message-ID: In-Reply-To: <4D2048A5.8090106@gmail.com> References: <4D2048A5.8090106@gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Mon, 03 Jan 2011 08:09:15 -0800 Cc: John C C White , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 18:22:34 -0000 Mykyta, This is very encouraging. Thanks. best new year's wishes, john --On Sunday, January 02, 2011 11:43 +0200 Mykyta Yevstifeyev wrote: > John, all, > > I have read the document you mentioned (MIL-STD-.....). And > the only thing I found interesting on these 111 pages is that > the port number 1 is used for TACO2 and what mentioned in > section 6.2 of it. > > As for White's draft. If he could kindly allow me to be the > co-author of the document, I would like to work on this > document. > > So, as I have applied for adopting my drafts as WG items, I > ask to mention the corresponding port number (1) for TACO2 in > /draft-yevstifeyev-netblt-iana/ while publishing it as WG > draft (if that would be approved). > > All the best, > Mykyta Yevstifeyev > > 28.12.2010 18:54, John C Klensin wrote: >> Mykyta, >> >> Are you aware of NetBLT actually being in active use in the >> public Internet, in the form documented in RFC 998? I'm not, >> but that sort of transport protocol isn't something I've paid >> careful attention to in many years. >> >> John C C White's 1997 Internet-Draft, >> http://tools.ietf.org/html/draft-white-protocol-stack-00, >> suggests that, in its original form, NetBLT contained some >> defects that made it undesirable in practice. That draft also >> suggested an update that would align NetBLT with then-current >> practice in some private (in this case military) network >> applications. As far as I can tell, that update never went >> anywhere in the IETF, but that is (sadly) typical of such >> things if no one is pushing for it. >> >> Especially if there is not significant evidence of its being >> in active use in RFC 998 form on the public Internet, it >> might be worthwhile to combine your effort to get the IANA >> registry in order with some version or variation on John's >> draft so as to bring the protocol itself up-to-date. >> >> The information on the standard to which John referred is at >> http://www.gwg.nga.mil/ntb/baseline/docs/44500/index.html; it >> doesn't appear to have changed much since his draft was >> produced. >> >> Even if it isn't useful to try to publish an updated version >> of the specification, it would probably be desirable to get >> any non-998 values used by the military standard into the >> registry as well. >> >> I've copied John on this note. Since I don't know if he is >> still at MITRE, I've also copied what is possibly his current >> address based on a web search. I have no idea whether he >> would still be interested, but he should at least be aware >> that I'm suggesting another look at his 13+ year old work. >> >> best regards and best new year's wishes to both of you, >> john > From jccw@jccw.org Mon Jan 3 05:50:59 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A37F28C11B for ; Mon, 3 Jan 2011 05:50:59 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7FsPeOdb2BI for ; Mon, 3 Jan 2011 05:50:57 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 094BB28C103 for ; Mon, 3 Jan 2011 05:50:56 -0800 (PST) Received: by vws7 with SMTP id 7so5585378vws.31 for ; Mon, 03 Jan 2011 05:53:03 -0800 (PST) Received: by 10.220.175.132 with SMTP id ba4mr4905407vcb.187.1294062781716; Mon, 03 Jan 2011 05:53:01 -0800 (PST) Received: from [192.168.1.102] (pool-173-48-171-215.bstnma.fios.verizon.net [173.48.171.215]) by mx.google.com with ESMTPS id n13sm4148745vcr.41.2011.01.03.05.52.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 03 Jan 2011 05:53:00 -0800 (PST) Subject: Re: draft-yevstifeyev-netblt-iana-00.txt Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: John White In-Reply-To: Date: Mon, 3 Jan 2011 08:52:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5E0012FB-9095-44DD-B1B1-52A6045979AB@jccw.org> References: <4D2048A5.8090106@gmail.com> To: John C Klensin X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Mon, 03 Jan 2011 08:09:15 -0800 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 14:01:21 -0000 Hi John et al - Thanks for tracking me down. I retired 5+ years ago, and certainly never = expected to give NETBLT another serious thought. As you have figured out, my main interest in NETBLT was to use it as the = core of the TACO2 protocol stack, whose purpose was to move large = messages (images) over low-bandwidth, mostly slow-turnaround half-duplex = links. At least 3 independent implementations of TACO2 were built, and = they were extensively tested for interoperability, so I believe that the = specifications in the MIL-STD and the internet draft are pretty = complete. I don't know whether anyone is still using TACO2, but I'm = inclined to suspect not. Around the time of the internet draft, I had a conversation with Allison = Mankin, who was then something like director of the transport area for = the IESG. One concern she expressed was that NETBLT could be a bandwidth = hog, to the disadvantage of other protocol streams. For our application = that wasn't a problem (it was a feature, actually), and it's not clear = to me that it's a transport layer issue, but it certainly could be a = problem elsewhere and deserves some thought. I'd certainly be happy to see someone else take up NETBLT as a project, = and will gladly offer whatever support I can as long as it doesn't = require me to do any actual work! Regards, and happy new year to you all, -John- On Jan 2, 2011, at 1:24 PM, John C Klensin wrote: > Mykyta, >=20 > This is very encouraging. Thanks. >=20 > best new year's wishes, > john >=20 >=20 > --On Sunday, January 02, 2011 11:43 +0200 Mykyta Yevstifeyev > wrote: >=20 >> John, all, >>=20 >> I have read the document you mentioned (MIL-STD-.....). And >> the only thing I found interesting on these 111 pages is that >> the port number 1 is used for TACO2 and what mentioned in >> section 6.2 of it. >>=20 >> As for White's draft. If he could kindly allow me to be the >> co-author of the document, I would like to work on this >> document. >>=20 >> So, as I have applied for adopting my drafts as WG items, I >> ask to mention the corresponding port number (1) for TACO2 in >> /draft-yevstifeyev-netblt-iana/ while publishing it as WG >> draft (if that would be approved). >>=20 >> All the best, >> Mykyta Yevstifeyev >>=20 >> 28.12.2010 18:54, John C Klensin wrote: >>> Mykyta, >>>=20 >>> Are you aware of NetBLT actually being in active use in the >>> public Internet, in the form documented in RFC 998? I'm not, >>> but that sort of transport protocol isn't something I've paid >>> careful attention to in many years. >>>=20 >>> John C C White's 1997 Internet-Draft, >>> http://tools.ietf.org/html/draft-white-protocol-stack-00, >>> suggests that, in its original form, NetBLT contained some >>> defects that made it undesirable in practice. That draft also >>> suggested an update that would align NetBLT with then-current >>> practice in some private (in this case military) network >>> applications. As far as I can tell, that update never went >>> anywhere in the IETF, but that is (sadly) typical of such >>> things if no one is pushing for it. >>>=20 >>> Especially if there is not significant evidence of its being >>> in active use in RFC 998 form on the public Internet, it >>> might be worthwhile to combine your effort to get the IANA >>> registry in order with some version or variation on John's >>> draft so as to bring the protocol itself up-to-date. >>>=20 >>> The information on the standard to which John referred is at >>> http://www.gwg.nga.mil/ntb/baseline/docs/44500/index.html; it >>> doesn't appear to have changed much since his draft was >>> produced. >>>=20 >>> Even if it isn't useful to try to publish an updated version >>> of the specification, it would probably be desirable to get >>> any non-998 values used by the military standard into the >>> registry as well. >>>=20 >>> I've copied John on this note. Since I don't know if he is >>> still at MITRE, I've also copied what is possibly his current >>> address based on a web search. I have no idea whether he >>> would still be interested, but he should at least be aware >>> that I'm suggesting another look at his 13+ year old work. >>>=20 >>> best regards and best new year's wishes to both of you, >>> john >>=20 >=20 >=20 >=20 >=20 From klensin@jck.com Mon Jan 3 07:47:12 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E50A3A69C3 for ; Mon, 3 Jan 2011 07:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4AKWkiPjUy6 for ; Mon, 3 Jan 2011 07:47:11 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 29CF53A69B5 for ; Mon, 3 Jan 2011 07:47:08 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PZmem-000P6J-ET; Mon, 03 Jan 2011 10:49:12 -0500 Date: Mon, 03 Jan 2011 10:49:11 -0500 From: John C Klensin To: John White Subject: Re: draft-yevstifeyev-netblt-iana-00.txt Message-ID: In-Reply-To: <5E0012FB-9095-44DD-B1B1-52A6045979AB@jccw.org> References: <4D2048A5.8090106@gmail.com> <5E0012FB-9095-44DD-B1B1-52A6045979AB@jccw.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Mon, 03 Jan 2011 08:09:15 -0800 Cc: tsvwg@ietf.org, mankin@psg.com X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 15:47:12 -0000 --On Monday, January 03, 2011 08:52 -0500 John White wrote: > Hi John et al - > > Thanks for tracking me down. I retired 5+ years ago, and > certainly never expected to give NETBLT another serious > thought. Probably a special case of the principle that no good deed goes unpunished. :-) > As you have figured out, my main interest in NETBLT was to use > it as the core of the TACO2 protocol stack, whose purpose was > to move large messages (images) over low-bandwidth, mostly > slow-turnaround half-duplex links. At least 3 independent > implementations of TACO2 were built, and they were extensively > tested for interoperability, so I believe that the > specifications in the MIL-STD and the internet draft are > pretty complete. I don't know whether anyone is still using > TACO2, but I'm inclined to suspect not. > > Around the time of the internet draft, I had a conversation > with Allison Mankin, who was then something like director of > the transport area for the IESG. One concern she expressed was > that NETBLT could be a bandwidth hog, to the disadvantage of > other protocol streams. For our application that wasn't a > problem (it was a feature, actually), and it's not clear to me > that it's a transport layer issue, but it certainly could be a > problem elsewhere and deserves some thought. I assume Allison is following the TSVWG mailing list, but have copied her on this note just in case (and since I'm not on that list). > I'd certainly be happy to see someone else take up NETBLT as a > project, and will gladly offer whatever support I can as long > as it doesn't require me to do any actual work! Thanks. This sort of thing is very much not in my area of specialty, but I wanted to try to be sure that all possible connections were made if Mykyta is inclined to do the work to pursue this. In particular, it seemed to be that, if we were going to update the registries to reflect the protocol, we should know its current status and, if someone (presumably Mykyta) is willing to do the bulk of the work, to update the base document accordingly. Allison, given John White's description of the objectives of TACO2, would there be any advantage of passing this work by the Delay Tolerant RG? Has that been done already? Best new year's wishes, john From braden@isi.edu Mon Jan 3 10:20:13 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F8123A6A58 for ; Mon, 3 Jan 2011 10:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.724 X-Spam-Level: X-Spam-Status: No, score=-102.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHoxGd2Y93hB for ; Mon, 3 Jan 2011 10:20:11 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id B7D253A6A53 for ; Mon, 3 Jan 2011 10:20:11 -0800 (PST) Received: from [128.9.168.81] (rtb.isi.edu [128.9.168.81]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p03ILx3R022804; Mon, 3 Jan 2011 10:21:59 -0800 (PST) Message-ID: <4D221536.3050505@isi.edu> Date: Mon, 03 Jan 2011 10:28:06 -0800 From: Bob Braden User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: draft-yevstifeyev-netblt-iana-00.txt References: <4D2048A5.8090106@gmail.com> <5E0012FB-9095-44DD-B1B1-52A6045979AB@jccw.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 18:20:13 -0000 >> >> Around the time of the internet draft, I had a conversation >> with Allison Mankin, who was then something like director of >> the transport area for the IESG. One concern she expressed was >> that NETBLT could be a bandwidth hog, to the disadvantage of >> other protocol streams. For our application that wasn't a >> problem (it was a feature, actually), and it's not clear to me >> that it's a transport layer issue, but it certainly could be a >> problem elsewhere and deserves some thought. Astonishing discussion. Another of those ideas that never completely dies... Indeed. Netblt was developed purely as an experiment by Dave Clark, who has never encouraged its propagation outside the ivory towers of Computer Science. It was mulled over by the End2end Task Force (and it undoubtedly appears in E2E meeting minutes from that era). Put simply, netblt is about was TCP-unfriendly as you can get. Widely used, it would have made a DDoS attack on the entire Internet (at least as the Internet existed at that time). My advice is, leave the Genie in the bottle! Better to spend your time bringing T/TCP back from the dead ;-)) Bob Braden > > I assume Allison is following the TSVWG mailing list, but have > copied her on this note just in case (and since I'm not on that > list). > >> I'd certainly be happy to see someone else take up NETBLT as a >> project, and will gladly offer whatever support I can as long >> as it doesn't require me to do any actual work! > > Thanks. This sort of thing is very much not in my area of > specialty, but I wanted to try to be sure that all possible > connections were made if Mykyta is inclined to do the work to > pursue this. In particular, it seemed to be that, if we were > going to update the registries to reflect the protocol, we > should know its current status and, if someone (presumably > Mykyta) is willing to do the bulk of the work, to update the > base document accordingly. > > Allison, given John White's description of the objectives of > TACO2, would there be any advantage of passing this work by the > Delay Tolerant RG? Has that been done already? > > Best new year's wishes, > john > > > From david.black@emc.com Mon Jan 3 11:00:19 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 433FD3A6AD2 for ; Mon, 3 Jan 2011 11:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5Qkq+wAkDPG for ; Mon, 3 Jan 2011 11:00:17 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id B9E9E3A6AB0 for ; Mon, 3 Jan 2011 11:00:17 -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 p03J2OPZ013773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 3 Jan 2011 14:02:24 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Mon, 3 Jan 2011 14:02:13 -0500 Received: from mxhub20.corp.emc.com (mxhub20.corp.emc.com [10.254.93.49]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p03J1t7i023388 for ; Mon, 3 Jan 2011 14:01:56 -0500 Received: from mx14a.corp.emc.com ([169.254.1.169]) by mxhub20.corp.emc.com ([10.254.93.49]) with mapi; Mon, 3 Jan 2011 14:01:55 -0500 From: To: Date: Mon, 3 Jan 2011 14:01:54 -0500 Subject: RE: Deprecation of ICMP Source Quench messages (draft-gont-tsvwg-source-quench) Thread-Topic: Deprecation of ICMP Source Quench messages (draft-gont-tsvwg-source-quench) Thread-Index: AcurX/FNwE1palWzTeKyEr2f6RZpJQAFkMJA Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E03D7555E02@MX14A.corp.emc.com> References: <4D21F2FC.2090000@erg.abdn.ac.uk> In-Reply-To: <4D21F2FC.2090000@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 19:00:19 -0000 > We'd welcome feedback to the list on the question below: >=20 > "Does the WG believe this document effectively addresses > an existing problem, and should this draft form the basis for > a solution?" >=20 > Please email the chairs and/or list if you support this as a work item, > or have comments on the suitability of this draft as a TSVWG work item. The problem is that everyone here "knows" that Source Quench is deprecated = in "running code", but that knowledge is not documented. We really should = document it just in case someone who isn't in the "know" tries to use Sourc= e Quench. This draft does a reasonable job of that by specifying that Sour= ce Quench SHOULD NOT be sent and SHOULD be ignored on receipt. Proceeding to answer the questions: 1) There is an existing problem, although not a major one. 2) This draft effectively addresses that problem. 3) I support this draft as a tsvwg work item. A longer list of surveyed implementations in Appendix A would be a good ide= a (e.g., Windows and MacOS for starters). Thanks, --David > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of= Gorry Fairhurst > Sent: Monday, January 03, 2011 11:02 AM > To: tsvwg list; tsvwg-chairs@tools.ietf.org > Subject: Deprecation of ICMP Source Quench messages (draft-gont-tsvwg-sou= rce-quench) >=20 > There was discussion of the draft below on the TSVWG list and at the > last IETF meeting. >=20 > Deprecation of ICMP Source Quench messages > (draft-gont-tsvwg-source-quench) > http://tools.ietf.org/html/draft-gont-tsvwg-source-quench-01 >=20 > We'd welcome feedback to the list on the question below: >=20 > "Does the WG believe this document effectively addresses > an existing problem, and should this draft form the basis for > a solution?" >=20 > Please email the chairs and/or list if you support this as a work item, > or have comments on the suitability of this draft as a TSVWG work item. >=20 > Best wishes, >=20 > Gorry & James > (TSVWG Co-Chairs) From touch@isi.edu Mon Jan 3 11:29:19 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A4C93A6B18 for ; Mon, 3 Jan 2011 11:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.07 X-Spam-Level: X-Spam-Status: No, score=-102.07 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydNpeSUXzWkg for ; Mon, 3 Jan 2011 11:29:18 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 70CA93A6B12 for ; Mon, 3 Jan 2011 11:29:18 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p03JUjpw001096 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 3 Jan 2011 11:30:45 -0800 (PST) Message-ID: <4D2223E4.2040104@isi.edu> Date: Mon, 03 Jan 2011 11:30:44 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mykyta Yevstifeyev Subject: Re: Draft Review Request - IRTP IANA Considerations References: <4D1715BE.6040100@gmail.com> <4D199D89.4080508@gmail.com> <00eb01cba6a5$b5606840$4001a8c0@gateway.2wire.net> <4D1D6EB3.40803@gmail.com> In-Reply-To: <4D1D6EB3.40803@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p03JUjpw001096 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: gorry@erg.abdn.ac.uk, jccw@jccw.org, tsvwg@ietf.org, jmpolk@cisco.com X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 19:29:19 -0000 On 12/30/2010 9:48 PM, Mykyta Yevstifeyev wrote: > Hello all, > > Firstly, happy New Year to all. > > Find some comments below. > > 28.12.2010 17:41, John C Klesin wrote: >> Mykyta, >> >> Are you aware of NetBLT actually being in active use in the >> public Internet, in the form documented in RFC 998? I'm not, >> but that sort of transport protocol isn't something I've paid >> careful attention to in many years. >> > Nevertheless, if there /is/ a protocol that uses the IANA-assigned > values, there should be appropriate registries. That's the key. This (and the other protocols you wrote similar docs for, e.g., NETBLT and RDP) don't use IANA-assigned values. They have values, but there was not a need for a registry for several reasons, including the fact that they were experimental. At this point, they might be better moved to historic than anything else. There's no reason to have IANA track or manage their values. Joe From fernando.gont.netbook.win@gmail.com Mon Jan 3 12:16:49 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4FD53A6A34 for ; Mon, 3 Jan 2011 12:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.527 X-Spam-Level: X-Spam-Status: No, score=-3.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJtRTnbQQO60 for ; Mon, 3 Jan 2011 12:16:48 -0800 (PST) Received: from mail-yx0-f194.google.com (mail-yx0-f194.google.com [209.85.213.194]) by core3.amsl.com (Postfix) with ESMTP id B82D93A6A17 for ; Mon, 3 Jan 2011 12:16:48 -0800 (PST) Received: by yxd5 with SMTP id 5so3279630yxd.1 for ; Mon, 03 Jan 2011 12:18:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=2ET+oYWGUPGn8IhURDtnt+qDZWQhlY30N0mSt+W6OnI=; b=Kmis/2At9kepCDYCbJp1jSHi3rJwyk4tNHOfOxKktp9w+aGxFzhsONL8YIhFZn5N8m SCjlABtOlkd3aVeGw0LysFFZGrM+vlY955vHpPIID2Y8vd08Z+nZw/x4IaFA9lTAdKkU HD9G1pHYJGGD0+GYVMw0NdMEZQt4Hv7fmjnO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=tAoH9QytamzO8c0xkPF+tqnQE7beWhlqDiRJaIFywXFY1iv2ptg3hkmQcKi3yUGw8T KvYa1AY6DzaRDZ3RefeA4lb8ZvQBvv/DXU954mSgJQ7aa+pVs6g3scQfEvt2Ce1lJjlR vL2GnZXp3u+hBjgjPBRL0g/YIcJK3Tls8mESc= Received: by 10.236.102.171 with SMTP id d31mr40774281yhg.19.1294085935587; Mon, 03 Jan 2011 12:18:55 -0800 (PST) Received: from [192.168.0.120] (61-128-17-190.fibertel.com.ar [190.17.128.61]) by mx.google.com with ESMTPS id z5sm12525071yhc.31.2011.01.03.12.18.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 03 Jan 2011 12:18:54 -0800 (PST) Sender: Fernando Gont Message-ID: <4D222F21.7060206@gont.com.ar> Date: Mon, 03 Jan 2011 17:18:41 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: david.black@emc.com Subject: Re: Deprecation of ICMP Source Quench messages (draft-gont-tsvwg-source-quench) References: <4D21F2FC.2090000@erg.abdn.ac.uk> <7C4DFCE962635144B8FAE8CA11D0BF1E03D7555E02@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E03D7555E02@MX14A.corp.emc.com> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 20:16:49 -0000 Hi, David, Thanks so much for your comments and support! Please find my response inline... On 03/01/2011 04:01 p.m., david.black@emc.com wrote: > A longer list of surveyed implementations in Appendix A would be a > good idea (e.g., Windows and MacOS for starters). I will be including Solaris in the list in the next revision of the document (thanks to feedback by James Carlson). And will ping the Windows folks about the status of Windows -- however, I bet they ignore ICMP SQs. -- will also try to investigate the status of MacOS. Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From evnikita2@gmail.com Mon Jan 3 21:52:49 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37F633A6B32 for ; Mon, 3 Jan 2011 21:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=-0.622, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ig71lwBmTuSm for ; Mon, 3 Jan 2011 21:52:47 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 771833A6B30 for ; Mon, 3 Jan 2011 21:52:46 -0800 (PST) Received: by bwz12 with SMTP id 12so14135604bwz.31 for ; Mon, 03 Jan 2011 21:54:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type; bh=mUvE5VItQU9Fx2tzanwXoexVuGhFo43/co9A10l0BEk=; b=ZEfeoA/XS+u+BNwbW3vZK14NqtW0xvDxZa27NFmZy2U1e6YLd3n5UwzqDX4MuVMQsM bmRtqAiKMi2yEmf6xyQGUfJYTey/FjNSECwELw9a1JuFqVKiS2x94uMaVEg4XTKpRQvx xSVtQFkJ3RiksKmMJnm/DXxV6vMTybz8cjju0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; b=R/CdRcCatuTAfj1j1yZR2Ul3ZVpDXKUFQTTfWMSDNdB6KXo8y87hiKUtjcZeE8J57F keiGVeg14YP7M8wXlUlxNE4IJYPLBuQLWlMzd5J/rrfKshFNkdVkMGEAEUcNDNmHeW1o flchbcJ05s5hlsDI8cQodCWTs26wDZl78msLM= Received: by 10.204.140.147 with SMTP id i19mr466520bku.196.1294120492697; Mon, 03 Jan 2011 21:54:52 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id x38sm10602040bkj.13.2011.01.03.21.54.50 (version=SSLv3 cipher=RC4-MD5); Mon, 03 Jan 2011 21:54:51 -0800 (PST) Message-ID: <4D22B63C.6070807@gmail.com> Date: Tue, 04 Jan 2011 07:55:08 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: John White Subject: Re: draft-yevstifeyev-netblt-iana-00.txt and other issues References: <4D2048A5.8090106@gmail.com> <5E0012FB-9095-44DD-B1B1-52A6045979AB@jccw.org> In-Reply-To: <5E0012FB-9095-44DD-B1B1-52A6045979AB@jccw.org> Content-Type: multipart/alternative; boundary="------------080904030404000506080500" Cc: John C Klensin , tsvwg@ietf.org, draft-ietf-tsvwg-iana-ports@tools.ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 05:52:49 -0000 This is a multi-part message in MIME format. --------------080904030404000506080500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello all, Let me inform you about the issues connected with my drafts. Firstly, I have contacted the authors of draft-ietf-tsvwg-iana-ports to ask them to include the registration procedures for RDP, NetBLT and IRTP ports. Unfortunately, I have received the response mentioning that these protocols are not in use and are rather candidates for historic protocol . I may agree partly with this, only for IRTP. For the others, I insist on including corresponding entries in the document. As for NETBLT. We managed to contact John White, the author of NETBLT draft (as I remember, draft-white-protocol-stack) (you may see his message at the end), that supposed that he is interested somebody would take such work. as I mentioned before, I would like to work on this draft. As for this, I would inform you about these issues later. Nevertheless, we have received a number of messages supposing that NETBLT should be historic rather than standards track. One of such messages is below. I may disagree that specifying NETBLT will cause great harm to Internet. For more than 20 years it existed no harm has been noticed. Yes, it is not very wide-spread, but used in some circumstances that, I think, are quite weighty argument to make that specified (I mean MIL-STD-..., see on the list archive). And as for my drafts. I would ask to withdraw my draft related to IRTP, but make another one suggesting moving it to Historic. As for RDP, I suppose draft-ietf-tsvwg-iana-ports authors will kindly allow this (and NETBLT) protocol ports to be registered using the unique procedure and as soon as this issues will be covered by this draft, I will ask my draft to be marked as replaced by iana-ports one. And as for NETBLT draft, it will be replaced by new version of White's draft, for which, I think, he would allow me to be the co-author. And lastly, now I ask the authors of draft-ietf-tsvwg-iana-ports to address to draft-yevstifeyev-eudp in the way they do it for UDP-Lite to allow this protocol ports to be assigned in the same way with UDP-Lite. This draft is already in RFC Ed. Queue (currently in the ISR state), but if the authors mind this, I will ask it to be the AD-Sponsored one. All the best, Mykyta Yevstifeyev 03.01.2011 20:28, Bob Braden wrote: >>> >>> Around the time of the internet draft, I had a conversation >>> with Allison Mankin, who was then something like director of >>> the transport area for the IESG. One concern she expressed was >>> that NETBLT could be a bandwidth hog, to the disadvantage of >>> other protocol streams. For our application that wasn't a >>> problem (it was a feature, actually), and it's not clear to me >>> that it's a transport layer issue, but it certainly could be a >>> problem elsewhere and deserves some thought. > > Astonishing discussion. Another of those ideas that never completely > dies... > > Indeed. Netblt was developed purely as an experiment by Dave Clark, > who has never encouraged its propagation outside the ivory towers of > Computer Science. It was mulled over by the End2end Task Force (and it > undoubtedly appears in E2E meeting minutes from that era). > > Put simply, netblt is about was TCP-unfriendly as you can get. Widely > used, it would have made a DDoS attack on the entire Internet (at > least as the Internet existed at that time). My advice is, leave the > Genie in the bottle! Better to spend your time bringing T/TCP back > from the dead ;-)) > > Bob Braden > >> >> I assume Allison is following the TSVWG mailing list, but have >> copied her on this note just in case (and since I'm not on that >> list). >> >>> I'd certainly be happy to see someone else take up NETBLT as a >>> project, and will gladly offer whatever support I can as long >>> as it doesn't require me to do any actual work! >> >> Thanks. This sort of thing is very much not in my area of >> specialty, but I wanted to try to be sure that all possible >> connections were made if Mykyta is inclined to do the work to >> pursue this. In particular, it seemed to be that, if we were >> going to update the registries to reflect the protocol, we >> should know its current status and, if someone (presumably >> Mykyta) is willing to do the bulk of the work, to update the >> base document accordingly. >> >> Allison, given John White's description of the objectives of >> TACO2, would there be any advantage of passing this work by the >> Delay Tolerant RG? Has that been done already? >> >> Best new year's wishes, >> john >> 03.01.2011 15:52, John White wrote: > Hi John et al - > > Thanks for tracking me down. I retired 5+ years ago, and certainly never expected to give NETBLT another serious thought. > > As you have figured out, my main interest in NETBLT was to use it as the core of the TACO2 protocol stack, whose purpose was to move large messages (images) over low-bandwidth, mostly slow-turnaround half-duplex links. At least 3 independent implementations of TACO2 were built, and they were extensively tested for interoperability, so I believe that the specifications in the MIL-STD and the internet draft are pretty complete. I don't know whether anyone is still using TACO2, but I'm inclined to suspect not. > > Around the time of the internet draft, I had a conversation with Allison Mankin, who was then something like director of the transport area for the IESG. One concern she expressed was that NETBLT could be a bandwidth hog, to the disadvantage of other protocol streams. For our application that wasn't a problem (it was a feature, actually), and it's not clear to me that it's a transport layer issue, but it certainly could be a problem elsewhere and deserves some thought. > > I'd certainly be happy to see someone else take up NETBLT as a project, and will gladly offer whatever support I can as long as it doesn't require me to do any actual work! > > Regards, and happy new year to you all, > -John- > > On Jan 2, 2011, at 1:24 PM, John C Klensin wrote: > >> Mykyta, >> >> This is very encouraging. Thanks. >> >> best new year's wishes, >> john >> >> >> --On Sunday, January 02, 2011 11:43 +0200 Mykyta Yevstifeyev >> wrote: >> >>> John, all, >>> >>> I have read the document you mentioned (MIL-STD-.....). And >>> the only thing I found interesting on these 111 pages is that >>> the port number 1 is used for TACO2 and what mentioned in >>> section 6.2 of it. >>> >>> As for White's draft. If he could kindly allow me to be the >>> co-author of the document, I would like to work on this >>> document. >>> >>> So, as I have applied for adopting my drafts as WG items, I >>> ask to mention the corresponding port number (1) for TACO2 in >>> /draft-yevstifeyev-netblt-iana/ while publishing it as WG >>> draft (if that would be approved). >>> >>> All the best, >>> Mykyta Yevstifeyev >>> >>> 28.12.2010 18:54, John C Klensin wrote: >>>> Mykyta, >>>> >>>> Are you aware of NetBLT actually being in active use in the >>>> public Internet, in the form documented in RFC 998? I'm not, >>>> but that sort of transport protocol isn't something I've paid >>>> careful attention to in many years. >>>> >>>> John C C White's 1997 Internet-Draft, >>>> http://tools.ietf.org/html/draft-white-protocol-stack-00, >>>> suggests that, in its original form, NetBLT contained some >>>> defects that made it undesirable in practice. That draft also >>>> suggested an update that would align NetBLT with then-current >>>> practice in some private (in this case military) network >>>> applications. As far as I can tell, that update never went >>>> anywhere in the IETF, but that is (sadly) typical of such >>>> things if no one is pushing for it. >>>> >>>> Especially if there is not significant evidence of its being >>>> in active use in RFC 998 form on the public Internet, it >>>> might be worthwhile to combine your effort to get the IANA >>>> registry in order with some version or variation on John's >>>> draft so as to bring the protocol itself up-to-date. >>>> >>>> The information on the standard to which John referred is at >>>> http://www.gwg.nga.mil/ntb/baseline/docs/44500/index.html; it >>>> doesn't appear to have changed much since his draft was >>>> produced. >>>> >>>> Even if it isn't useful to try to publish an updated version >>>> of the specification, it would probably be desirable to get >>>> any non-998 values used by the military standard into the >>>> registry as well. >>>> >>>> I've copied John on this note. Since I don't know if he is >>>> still at MITRE, I've also copied what is possibly his current >>>> address based on a web search. I have no idea whether he >>>> would still be interested, but he should at least be aware >>>> that I'm suggesting another look at his 13+ year old work. >>>> >>>> best regards and best new year's wishes to both of you, >>>> john >> >> >> > --------------080904030404000506080500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello all,

Let me inform you about the issues connected with my drafts.

Firstly, I have contacted the authors of draft-ietf-tsvwg-iana-ports to ask them to include the registration procedures for RDP, NetBLT and IRTP ports. Unfortunately, I have received the response mentioning that these protocols are not in use and are rather candidates for historic protocol . I may agree partly with this, only for IRTP. For the others, I insist on including corresponding entries in the document.

As for NETBLT. We managed to contact John White, the author of NETBLT draft (as I remember, draft-white-protocol-stack) (you may see his message at the end), that supposed that he is interested somebody would take such work. as I mentioned before, I would like to work on this draft. As for this, I would inform you about these issues later. Nevertheless, we have received a number of messages supposing that NETBLT should be historic rather than standards track. One of such messages is below. I may disagree that specifying NETBLT will cause great harm to Internet. For more than 20 years it existed no harm has been noticed. Yes, it is not very wide-spread, but used in some circumstances that, I think, are quite weighty argument to make that specified (I mean MIL-STD-..., see on the list archive).

And as for my drafts. I would ask to withdraw my draft related to IRTP, but make another one suggesting moving it to Historic. As for RDP, I suppose draft-ietf-tsvwg-iana-ports authors will kindly allow this (and NETBLT) protocol ports to be registered using the unique procedure and as soon as this issues will be covered by this draft, I will ask my draft to be marked as replaced by iana-ports one. And as for NETBLT draft, it will be replaced by new version of White's draft, for which, I think, he would allow me to be the co-author.

And lastly, now I ask the authors of draft-ietf-tsvwg-iana-ports to address to draft-yevstifeyev-eudp in the way they do it for UDP-Lite to allow this protocol ports to be assigned in the same way with UDP-Lite. This draft is already in RFC Ed. Queue (currently in the ISR state), but if the authors mind this, I will ask it to be the AD-Sponsored one.

All the best,
Mykyta Yevstifeyev

03.01.2011 20:28, Bob Braden wrote:

Around the time of the internet draft, I had a conversation
with Allison Mankin, who was then something like director of
the transport area for the IESG. One concern she expressed was
that NETBLT could be a bandwidth hog, to the disadvantage of
other protocol streams. For our application that wasn't a
problem (it was a feature, actually), and it's not clear to me
that it's a transport layer issue, but it certainly could be a
problem elsewhere and deserves some thought.

Astonishing discussion.  Another of those ideas that never completely dies...

Indeed. Netblt was developed purely as an experiment by Dave Clark, who has never encouraged its propagation outside the ivory towers of Computer Science. It was mulled over by the End2end Task Force (and it undoubtedly appears in E2E meeting minutes from that era).

Put simply, netblt is about was TCP-unfriendly as you can get.  Widely used, it would have made a DDoS attack on the entire Internet (at least as the Internet existed at that time).  My advice is, leave the Genie in the bottle!  Better to spend your time bringing T/TCP back from the dead ;-))

Bob Braden


I assume Allison is following the TSVWG mailing list, but have
copied her on this note just in case (and since I'm not on that
list).

I'd certainly be happy to see someone else take up NETBLT as a
project, and will gladly offer whatever support I can as long
as it doesn't require me to do any actual work!

Thanks.  This sort of thing is very much not in my area of
specialty, but I wanted to try to be sure that all possible
connections were made if Mykyta is inclined to do the work to
pursue this.  In particular, it seemed to be that, if we were
going to update the registries to reflect the protocol, we
should know its current status and, if someone (presumably
Mykyta) is willing to do the bulk of the work, to update the
base document accordingly.

Allison, given John White's description of the objectives of
TACO2, would there be any advantage of passing this work by the
Delay Tolerant RG?   Has that been done already?

Best new year's wishes,
     john



03.01.2011 15:52, John White wrote:
Hi John et al -

Thanks for tracking me down. I retired 5+ years ago, and certainly never expected to give NETBLT another serious thought.

As you have figured out, my main interest in NETBLT was to use it as the core of the TACO2 protocol stack, whose purpose was to move large messages (images) over low-bandwidth, mostly slow-turnaround half-duplex links. At least 3 independent implementations of TACO2 were built, and they were extensively tested for interoperability, so I believe that the specifications in the MIL-STD and the internet draft are pretty complete. I don't know whether anyone is still using TACO2, but I'm inclined to suspect not.

Around the time of the internet draft, I had a conversation with Allison Mankin, who was then something like director of the transport area for the IESG. One concern she expressed was that NETBLT could be a bandwidth hog, to the disadvantage of other protocol streams. For our application that wasn't a problem (it was a feature, actually), and it's not clear to me that it's a transport layer issue, but it certainly could be a problem elsewhere and deserves some thought.

I'd certainly be happy to see someone else take up NETBLT as a project, and will gladly offer whatever support I can as long as it doesn't require me to do any actual work!

Regards, and happy new year to you all,
-John-

On Jan 2, 2011, at 1:24 PM, John C Klensin wrote:

Mykyta,

This is very encouraging.  Thanks.

best new year's wishes,
  john


--On Sunday, January 02, 2011 11:43 +0200 Mykyta Yevstifeyev
<evnikita2@gmail.com> wrote:

John, all,

I have read the document you mentioned (MIL-STD-.....). And
the only thing I found interesting on these 111 pages is that
the port number 1 is used for TACO2 and what mentioned in
section 6.2 of it.

As for White's draft. If he could kindly allow me to be the
co-author of the document, I would like to work on this
document.

So, as I have applied for adopting my drafts as WG items, I
ask to mention the corresponding port number (1) for TACO2 in
/draft-yevstifeyev-netblt-iana/ while publishing it as WG
draft (if that would be approved).

All the best,
Mykyta Yevstifeyev

28.12.2010 18:54, John C Klensin wrote:
Mykyta,

Are you aware of NetBLT actually being in active use in the
public Internet, in the form documented in RFC 998?  I'm not,
but that sort of transport protocol isn't something I've paid
careful attention to in many years.

John C C White's 1997 Internet-Draft,
http://tools.ietf.org/html/draft-white-protocol-stack-00,
suggests that, in its original form, NetBLT contained some
defects that made it undesirable in practice.  That draft also
suggested an update that would align NetBLT with then-current
practice in some private (in this case military) network
applications.  As far as I can tell, that update never went
anywhere in the IETF, but that is (sadly) typical of such
things if no one is pushing for it.

Especially if there is not significant evidence of its being
in active use in RFC 998 form on the public Internet, it
might be worthwhile to combine your effort to get the IANA
registry in order with some version or variation on John's
draft so as to bring the protocol itself up-to-date.

The information on the standard to which John referred is at
http://www.gwg.nga.mil/ntb/baseline/docs/44500/index.html; it
doesn't appear to have changed much since his draft was
produced.

Even if it isn't useful to try to publish an updated version
of the specification, it would probably be desirable to get
any non-998 values used by the military standard into the
registry as well.

I've copied John on this note.  Since I don't know if he is
still at MITRE, I've also copied what is possibly his current
address based on a web search.  I have no idea whether he
would still be interested, but he should at least be aware
that I'm suggesting another look at his 13+ year old work.

best regards and best new year's wishes to both of you,
    john

        





--------------080904030404000506080500-- From lars.eggert@nokia.com Tue Jan 4 03:00:16 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D7993A6B3F for ; Tue, 4 Jan 2011 03:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.116 X-Spam-Level: X-Spam-Status: No, score=-107.116 tagged_above=-999 required=5 tests=[AWL=2.684, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzqmwuki1aTU for ; Tue, 4 Jan 2011 03:00:13 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 59F1E3A698E for ; Tue, 4 Jan 2011 03:00:13 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p04B27wH026457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Jan 2011 13:02:09 +0200 Subject: Re: Draft Review Request - IRTP IANA Considerations X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-27-151552907; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4D2223E4.2040104@isi.edu> Date: Tue, 4 Jan 2011 13:00:48 +0200 Message-Id: References: <4D1715BE.6040100@gmail.com> <4D199D89.4080508@gmail.com> <00eb01cba6a5$b5606840$4001a8c0@gateway.2wire.net> <4D1D6EB3.40803@gmail.com> <4D2223E4.2040104@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Tue, 04 Jan 2011 13:02:04 +0200 (EET) X-Nokia-AV: Clean Cc: gorry@erg.abdn.ac.uk, jccw@jccw.org, tsvwg@ietf.org, jmpolk@cisco.com X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 11:00:16 -0000 --Apple-Mail-27-151552907 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2011-1-3, at 21:30, Joe Touch wrote: > At this point, they might be better moved to historic than anything = else. There's no reason to have IANA track or manage their values. As an individual WG participant, I fully agree with Joe. Lars= --Apple-Mail-27-151552907 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEwNDExMDA0OVowIwYJKoZIhvcNAQkE MRYEFHqq70aTHFMDAiWsshhLsTKNA1FoMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AK3jja6EKylzjLMzqsE2m77Dij+4dSxQxiBs1fT0sDIbWp/3wYhQM3i2dgdzxafNVsweKpids9vT pqrymm3Bwp3XSZuSP+JOJkAzEQ7a2SCEkS1x5MMyd0KYuvQMfFzsOZVBQkvUC2ZQ4Z3MtB6gRza7 jI7CAPXBjiRNeu11xb1MYFBJ0WsOdCrWGrN1fV3cwcbQmH+Jf4hUDlz9fiuQMqwheOlT3yYGKa81 dUsh/kKgsq4fVXsVljXgy2FkenunrRapmT52e002i41K36pidloHByMeaFWPcCCpdHFoP+AC/DiA fO3be9+XQVRfoj9JUrjKcHAe6VHdlCPRakYXZhMAAAAAAAA= --Apple-Mail-27-151552907-- From Internet-Drafts@ietf.org Tue Jan 4 04:00:05 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0C5C3A6B7A; Tue, 4 Jan 2011 04:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.336 X-Spam-Level: X-Spam-Status: No, score=-102.336 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, SARE_SUB_6CONS_WORD=0.356, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xwzie1X4TVGH; Tue, 4 Jan 2011 04:00:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95C153A6A44; Tue, 4 Jan 2011 04:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-tsvwg-sctp-strrst-09.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110104120001.28499.17270.idtracker@localhost> Date: Tue, 04 Jan 2011 04:00:01 -0800 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 12:00:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Stream Control Transmission Protocol (SCTP) Stream Reconfiguration Author(s) : R. Stewart, et al. Filename : draft-ietf-tsvwg-sctp-strrst-09.txt Pages : 32 Date : 2011-01-04 Many applications that use SCTP want the ability to "reset" a stream. The intention of resetting a stream is to set the numbering sequence of the stream back to 'zero' with a corresponding notification to the upper layer that this has been performed. The applications that want this feature want it so that they can "re-use" streams for different purposes but still utilize the stream sequence number so that the application can track the message flows. Thus, without this feature, a new use of an old stream would result in message numbers greater than expected unless there is a protocol mechanism to "reset the streams back to zero". This document also includes methods for resetting the transport sequence numbers, adding additional streams and resetting all stream sequence numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-strrst-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tsvwg-sctp-strrst-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-04035533.I-D@ietf.org> --NextPart-- From evnikita2@gmail.com Tue Jan 4 21:24:04 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDFEB3A67E6 for ; Tue, 4 Jan 2011 21:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=-0.998, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ra0vqdlh1aX8 for ; Tue, 4 Jan 2011 21:24:04 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id B89183A67A2 for ; Tue, 4 Jan 2011 21:24:03 -0800 (PST) Received: by bwz12 with SMTP id 12so15065003bwz.31 for ; Tue, 04 Jan 2011 21:26:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=kLkSpf/QWiBe5C5o6FSuz0UUybMf/hvszQHfDM+O2HY=; b=OBm6AqGaHGn5W3XAga+zwdj1LcDUU+JjRIhLMgi1FHdaWdwxcKDPqXymFuOyL2T8/v 0uDdI4auj1UZ3U+aeaz1CGTRWhfgcPWZRGOrk3k/vQTvAnsk2Q1lJ26i6JcWttCM5zVb bDsh3/13JAKsN/3Jp7d59/pqvEIbzHc7G/mo4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=F5Vsx31xvuR5InMsT4IjhIK8+gmpuxFB7BPVcmIZVOf8/m8U1pki43EQHEy+vQv62C yTFIbZD923Vqkd3Nj3nFJ5FtXhNitiPTNW93Yl62Xmqru2IPPvkcL7DNSR2+RZuc29XC y+xWvnW08YhVepBstZFbjflTPvRt4WgJCPxXc= Received: by 10.204.33.74 with SMTP id g10mr4264151bkd.131.1294205169667; Tue, 04 Jan 2011 21:26:09 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id v1sm12528351bkt.5.2011.01.04.21.26.07 (version=SSLv3 cipher=RC4-MD5); Tue, 04 Jan 2011 21:26:08 -0800 (PST) Message-ID: <4D240101.6090308@gmail.com> Date: Wed, 05 Jan 2011 07:26:25 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Lars Eggert Subject: Re: Draft Review Request - IRTP IANA Considerations References: <4D1715BE.6040100@gmail.com> <4D199D89.4080508@gmail.com> <00eb01cba6a5$b5606840$4001a8c0@gateway.2wire.net> <4D1D6EB3.40803@gmail.com> <4D2223E4.2040104@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gorry@erg.abdn.ac.uk, jmpolk@cisco.com, jccw@jccw.org, tsvwg@ietf.org, Joe Touch X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 05:24:04 -0000 04.01.2011 13:00, Lars Eggert wrote: > On 2011-1-3, at 21:30, Joe Touch wrote: >> At this point, they might be better moved to historic than anything else. There's no reason to have IANA track or manage their values. > As an individual WG participant, I fully agree with Joe. Lars As I have mentioned before, I can agree with this only for IRTP (and maybe for RDP), but not NETBLT. I have recently made a draft moving IRTP to historic - here is a link https://datatracker.ietf.org/doc/draft-yevstifeyev-tsvwg-irtp-to-historic/ Maybe there is no doubt that this protocol should be Historic - so could you please sponsor the publication of this document as RFC? Mykyta > Lars From touch@isi.edu Tue Jan 4 21:54:58 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 945793A6A5E for ; Tue, 4 Jan 2011 21:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.803 X-Spam-Level: X-Spam-Status: No, score=-100.803 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJYwxG-4i0fd for ; Tue, 4 Jan 2011 21:54:57 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 4CBD53A6A2C for ; Tue, 4 Jan 2011 21:54:57 -0800 (PST) Received: from [10.102.236.43] (166-205-136-206.mobile.mymmode.com [166.205.136.206] (may be forged)) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p055uchQ023790 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 4 Jan 2011 21:56:51 -0800 (PST) References: <4D1715BE.6040100@gmail.com> <4D199D89.4080508@gmail.com> <00eb01cba6a5$b5606840$4001a8c0@gateway.2wire.net> <4D1D6EB3.40803@gmail.com> <4D2223E4.2040104@isi.edu> <4D240101.6090308@gmail.com> In-Reply-To: <4D240101.6090308@gmail.com> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Type: text/plain; charset=us-ascii Message-Id: <5131531F-D1E6-44F1-8FC0-94CBCF6CC2A8@isi.edu> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8C148) From: Joe Touch Subject: Re: Draft Review Request - IRTP IANA Considerations Date: Tue, 4 Jan 2011 21:56:32 -0800 To: Mykyta Yevstifeyev X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "gorry@erg.abdn.ac.uk" , "jccw@jccw.org" , "tsvwg@ietf.org" , "jmpolk@cisco.com" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 05:54:58 -0000 On Jan 4, 2011, at 9:26 PM, Mykyta Yevstifeyev wrote: > 04.01.2011 13:00, Lars Eggert wrote: >> On 2011-1-3, at 21:30, Joe Touch wrote: >>> At this point, they might be better moved to historic than anything else= . There's no reason to have IANA track or manage their values. >> As an individual WG participant, I fully agree with Joe. > Lars >=20 > As I have mentioned before, I can agree with this only for IRTP (and maybe= for RDP), but not NETBLT. I have recently made a draft moving IRTP to histo= ric - here is a link >=20 > https://datatracker.ietf.org/doc/draft-yevstifeyev-tsvwg-irtp-to-historic/= >=20 > Maybe there is no doubt that this protocol should be Historic - so could y= ou please sponsor the publication of this document as RFC? There us also neither a need nor a utility. Is there some other reason you a= te trying so hard to get an RFC published? Joe= From ietfc@btconnect.com Wed Jan 5 04:45:43 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFA343A6E18 for ; Wed, 5 Jan 2011 04:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgWapbSGBHs6 for ; Wed, 5 Jan 2011 04:45:43 -0800 (PST) Received: from mail.btconnect.com (c2bthomr10.btconnect.com [213.123.20.128]) by core3.amsl.com (Postfix) with ESMTP id 8ACC03A6B6B for ; Wed, 5 Jan 2011 04:45:41 -0800 (PST) Received: from host86-141-17-73.range86-141.btcentralplus.com (HELO pc6) ([86.141.17.73]) by c2bthomr10.btconnect.com with SMTP id BGP52118; Wed, 05 Jan 2011 12:47:27 +0000 (GMT) Message-ID: <024801cbaccd$e347d580$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Joe Touch" References: <4D1715BE.6040100@gmail.com> <4D199D89.4080508@gmail.com><00eb01cba6a5$b5606840$4001a8c0@gateway.2wire.net><4D1D6EB3.40803@gmail.com> <4D2223E4.2040104@isi.edu><4D240101.6090308@gmail.com> <5131531F-D1E6-44F1-8FC0-94CBCF6CC2A8@isi.edu> Subject: Re: Draft Review Request - IRTP IANA Considerations Date: Wed, 5 Jan 2011 12:44:10 +0100 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-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0302.4D24685F.006A, actions=tag X-Junkmail-Status: score=10/50, host=c2bthomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020B.4D246862.0048,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 12:45:43 -0000 ----- Original Message ----- From: "Joe Touch" To: "Mykyta Yevstifeyev" Cc: ; ; ; Sent: Wednesday, January 05, 2011 6:56 AM On Jan 4, 2011, at 9:26 PM, Mykyta Yevstifeyev wrote: > 04.01.2011 13:00, Lars Eggert wrote: >> On 2011-1-3, at 21:30, Joe Touch wrote: >>> At this point, they might be better moved to historic than anything else. There's no reason to have IANA track or manage their values. >> As an individual WG participant, I fully agree with Joe. > Lars > > As I have mentioned before, I can agree with this only for IRTP (and maybe for RDP), but not NETBLT. I have recently made a draft moving IRTP to historic - here is a link > > https://datatracker.ietf.org/doc/draft-yevstifeyev-tsvwg-irtp-to-historic/ > > Maybe there is no doubt that this protocol should be Historic - so could you please sponsor the publication of this document as RFC? There us also neither a need nor a utility. Is there some other reason you ate trying so hard to get an RFC published? Joe You may have seen http://www.ietf.org/mail-archive/web/ietf/current/msg65008.html if not I suggest you take a look and respond. It is a forward of an IESG message for a Last Call. Tom Petch Joe= From touch@isi.edu Wed Jan 5 08:13:00 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A79A3A6B99 for ; Wed, 5 Jan 2011 08:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSqI070fyT1T for ; Wed, 5 Jan 2011 08:12:59 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 2CC653A6B90 for ; Wed, 5 Jan 2011 08:12:59 -0800 (PST) Received: from [192.168.1.90] (pool-71-105-94-39.lsanca.dsl-w.verizon.net [71.105.94.39]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p05GEbvF024253 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 5 Jan 2011 08:14:48 -0800 (PST) Message-ID: <4D2498ED.6000207@isi.edu> Date: Wed, 05 Jan 2011 08:14:37 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "t.petch" Subject: Re: Draft Review Request - IRTP IANA Considerations References: <4D1715BE.6040100@gmail.com> <4D199D89.4080508@gmail.com><00eb01cba6a5$b5606840$4001a8c0@gateway.2wire.net><4D1D6EB3.40803@gmail.com> <4D2223E4.2040104@isi.edu><4D240101.6090308@gmail.com> <5131531F-D1E6-44F1-8FC0-94CBCF6CC2A8@isi.edu> <024801cbaccd$e347d580$4001a8c0@gateway.2wire.net> In-Reply-To: <024801cbaccd$e347d580$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p05GEbvF024253 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 16:13:00 -0000 On 1/5/2011 3:44 AM, t.petch wrote: > You may have seen > http://www.ietf.org/mail-archive/web/ietf/current/msg65008.html > if not I suggest you take a look and respond. It is a forward of > an IESG message for a Last Call. > > Tom Petch I have not, but I'm also not available to monitor any one author's contributions. Others who are interested should take a look and respond. Joe From fred@cisco.com Wed Jan 5 10:13:23 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 980C13A6C17 for ; Wed, 5 Jan 2011 10:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.411 X-Spam-Level: X-Spam-Status: No, score=-110.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PNl6L9CFYh0 for ; Wed, 5 Jan 2011 10:13:22 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 667C13A6BE9 for ; Wed, 5 Jan 2011 10:13:22 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALZDJE2rRN+J/2dsb2JhbACkInOmY5gwhUwEhGiGIoMfiBU X-IronPort-AV: E=Sophos;i="4.60,278,1291593600"; d="scan'208";a="240903662" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 05 Jan 2011 18:15:29 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p05IFOOu006384; Wed, 5 Jan 2011 18:15:29 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Wed, 05 Jan 2011 10:15:29 -0800 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Wed, 05 Jan 2011 10:15:29 -0800 Subject: Re: Deprecation of ICMP Source Quench messages (draft-gont-tsvwg-source-quench) Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <4D21F2FC.2090000@erg.abdn.ac.uk> Date: Wed, 5 Jan 2011 10:15:14 -0800 Message-Id: References: <4D21F2FC.2090000@erg.abdn.ac.uk> To: Gorry Fairhurst X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "tsvwg-chairs@tools.ietf.org" , tsvwg list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 18:13:23 -0000 As we have discussed privately, I'm not sure I agree that the = deprecation of source quench is "undocumented", given RFC 1812's = comments on it, but the statements are at the MAY/SHOULD level, not = MUST. Given that we don't see source quench in use in the network and = source quench was not carried forward into IPv6 (which is where current = attention SHOULD be, IMHO), I don't think that a document changing = "SHOULD" to "MUST" accomplishes much. The document is probably a very = fine document, but I don't think the issue is a good use of the working = group's time. =46rom RFC 1812: 4.3.3.3 Source Quench A router SHOULD NOT originate ICMP Source Quench messages. As specified in Section [4.3.2], a router that does originate Source Quench messages MUST be able to limit the rate at which they are generated. DISCUSSION Research seems to suggest that Source Quench consumes network bandwidth but is an ineffective (and unfair) antidote to congestion. See, for example, [INTERNET:9] and [INTERNET:10]. Section [5.3.6] discusses the current thinking on how routers ought to deal with overload and network congestion. A router MAY ignore any ICMP Source Quench messages it receives. DISCUSSION A router itself may receive a Source Quench as the result of originating a packet sent to another router or host. Such datagrams might be, e.g., an EGP update sent to another router, or a telnet stream sent to a host. A mechanism has been proposed ([INTERNET:11], [INTERNET:12]) to make the IP layer respond directly to Source Quench by controlling the rate at which packets are sent, however, this proposal is currently experimental and not currently recommended. 5.3.6 Congestion Control ... As described in Section [4.3.3.3], this document recommends that a router SHOULD NOT send a Source Quench to the sender of the packet that it is discarding. ICMP Source Quench is a very weak mechanism, so it is not necessary for a router to send it, and host software should not use it exclusively as an indicator of congestion. On Jan 3, 2011, at 8:02 AM, Gorry Fairhurst wrote: > There was discussion of the draft below on the TSVWG list and at the = last IETF meeting. >=20 > Deprecation of ICMP Source Quench messages > (draft-gont-tsvwg-source-quench) > http://tools.ietf.org/html/draft-gont-tsvwg-source-quench-01 >=20 > We'd welcome feedback to the list on the question below: >=20 > "Does the WG believe this document effectively addresses > an existing problem, and should this draft form the basis for > a solution?" >=20 > Please email the chairs and/or list if you support this as a work = item, or have comments on the suitability of this draft as a TSVWG work = item. >=20 > Best wishes, >=20 > Gorry & James > (TSVWG Co-Chairs) From evnikita2@gmail.com Wed Jan 5 21:32:50 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D91A3A6D0A for ; Wed, 5 Jan 2011 21:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.526 X-Spam-Level: X-Spam-Status: No, score=-1.526 tagged_above=-999 required=5 tests=[AWL=-1.286, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPAiDqEKIUpW for ; Wed, 5 Jan 2011 21:32:48 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id EA18E3A6CE7 for ; Wed, 5 Jan 2011 21:32:47 -0800 (PST) Received: by bwz12 with SMTP id 12so16025444bwz.31 for ; Wed, 05 Jan 2011 21:34:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=tGc4/pwWNtJPA0KaDRmxYy4sxiVr86bc7lO+RiK90K0=; b=jIgmjsr/NFc1ucOocx398tzYpHXtkxFNZ697D+q+23XWfPPo6XHe1fsqtc3KiwTdn6 8HX5T7fzrqK2oNTaHa7zTvKWWhhyeexwQeFwiAEMBatWnGo81SOxxGxRFexFt0cbCB3Z vOWapigtoZRA9YbcCwUDa8WK6lCbZ6jJcbH50= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=OsRaOlXYPypE2KryXqqJWDzd2nMQmPrHghwrVV9YBCFfwJ/npqELIiuyW+fRJMfcrJ lmtAX+bC57a2KxMHzT1tIlF/mKAgnLH7ViK7PLFyRaZX2NF3KDcW06U9Mz9ajqE+SSBk t7EwUknACKcG8KXABKaUTDuadYI+l7Za9DbN4= Received: by 10.204.62.73 with SMTP id w9mr5741407bkh.11.1294292093420; Wed, 05 Jan 2011 21:34:53 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id v25sm13209255bkt.6.2011.01.05.21.34.50 (version=SSLv3 cipher=RC4-MD5); Wed, 05 Jan 2011 21:34:51 -0800 (PST) Message-ID: <4D25548C.5000800@gmail.com> Date: Thu, 06 Jan 2011 07:35:08 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "t.petch" Subject: Re: Draft Review Request - IRTP IANA Considerations References: <4D1715BE.6040100@gmail.com> <4D199D89.4080508@gmail.com><00eb01cba6a5$b5606840$4001a8c0@gateway.2wire.net><4D1D6EB3.40803@gmail.com> <4D2223E4.2040104@isi.edu><4D240101.6090308@gmail.com> <5131531F-D1E6-44F1-8FC0-94CBCF6CC2A8@isi.edu> <024801cbaccd$e347d580$4001a8c0@gateway.2wire.net> In-Reply-To: <024801cbaccd$e347d580$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, Joe Touch X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 05:32:50 -0000 05.01.2011 13:44, t.petch wrote: > ----- Original Message ----- > From: "Joe Touch" > To: "Mykyta Yevstifeyev" > Cc:;;; > > Sent: Wednesday, January 05, 2011 6:56 AM > On Jan 4, 2011, at 9:26 PM, Mykyta Yevstifeyev wrote: > >> 04.01.2011 13:00, Lars Eggert wrote: >>> On 2011-1-3, at 21:30, Joe Touch wrote: >>>> At this point, they might be better moved to historic than anything else. > There's no reason to have IANA track or manage their values. >>> As an individual WG participant, I fully agree with Joe. >> Lars >> >> As I have mentioned before, I can agree with this only for IRTP (and maybe for > RDP), but not NETBLT. I have recently made a draft moving IRTP to historic - > here is a link >> https://datatracker.ietf.org/doc/draft-yevstifeyev-tsvwg-irtp-to-historic/ >> >> Maybe there is no doubt that this protocol should be Historic - so could you > please sponsor the publication of this document as RFC? > > There us also neither a need nor a utility. Is there some other reason you ate > trying so hard to get an RFC published? If you mean IRTP IANA Considerations, I have asked to withdraw it. Now I propose tsvwg-irtp-to-historic-00. > Joe > > You may have seen > http://www.ietf.org/mail-archive/web/ietf/current/msg65008.html > if not I suggest you take a look and respond. It is a forward of > an IESG message for a Last Call. > > Tom Petch > > > > > Joe= > > From evnikita2@gmail.com Wed Jan 5 21:34:34 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D957E3A69CA for ; Wed, 5 Jan 2011 21:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[AWL=-1.271, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbbtHT+7kLuJ for ; Wed, 5 Jan 2011 21:34:34 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id C1DB93A694A for ; Wed, 5 Jan 2011 21:34:33 -0800 (PST) Received: by bwz12 with SMTP id 12so16026150bwz.31 for ; Wed, 05 Jan 2011 21:36:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=geOzp8WS3qL99cyoBzYozjP0fZ1yJ5WN3IBWDbIvd0s=; b=qLUQMJn+/xTEGagvCFb4GizBOCxFTSr8liGSjYZwzcNR3t7gPxYzgLzEBRrKGvprUO ysNyRN1ClYAF8C+9yjXx6ht5yvpewVBUrEQcRTcB5Tfeav6FVjXpIU/rG4B8G4Oz2ymh 6G9BL0DFK+Q4M57pCV7nxOxtAeikDZOcaCrIk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=hQCNYLPT5sZeglX9B/PF1wndNx2xGCiIYZTPtZpnNROIwM779IPQ0t1RhxfGdLVkPj SsRo8/nFHypGcuvXlOlg4kLP16fysLCl+oyZUDrougMNQxZHabeEMBecuiVr6MVvD/It qci0iOyQ9AaFaljShjIcsDlItT0AuZxGP1gaQ= Received: by 10.204.70.137 with SMTP id d9mr12064122bkj.141.1294292200076; Wed, 05 Jan 2011 21:36:40 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id f20sm10800224bkf.4.2011.01.05.21.36.38 (version=SSLv3 cipher=RC4-MD5); Wed, 05 Jan 2011 21:36:39 -0800 (PST) Message-ID: <4D2554F8.7060201@gmail.com> Date: Thu, 06 Jan 2011 07:36:56 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "t.petch" Subject: Re: Draft Review Request - IRTP IANA Considerations References: <4D1715BE.6040100@gmail.com> <4D199D89.4080508@gmail.com><00eb01cba6a5$b5606840$4001a8c0@gateway.2wire.net><4D1D6EB3.40803@gmail.com> <4D2223E4.2040104@isi.edu><4D240101.6090308@gmail.com> <5131531F-D1E6-44F1-8FC0-94CBCF6CC2A8@isi.edu> <024801cbaccd$e347d580$4001a8c0@gateway.2wire.net> In-Reply-To: <024801cbaccd$e347d580$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, Joe Touch X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 05:34:35 -0000 05.01.2011 13:44, t.petch wrote: > ----- Original Message ----- > From: "Joe Touch" > To: "Mykyta Yevstifeyev" > Cc:;;; > > Sent: Wednesday, January 05, 2011 6:56 AM > On Jan 4, 2011, at 9:26 PM, Mykyta Yevstifeyev wrote: > >> 04.01.2011 13:00, Lars Eggert wrote: >>> On 2011-1-3, at 21:30, Joe Touch wrote: >>>> At this point, they might be better moved to historic than anything else. > There's no reason to have IANA track or manage their values. >>> As an individual WG participant, I fully agree with Joe. >> Lars >> >> As I have mentioned before, I can agree with this only for IRTP (and maybe for > RDP), but not NETBLT. I have recently made a draft moving IRTP to historic - > here is a link >> https://datatracker.ietf.org/doc/draft-yevstifeyev-tsvwg-irtp-to-historic/ >> >> Maybe there is no doubt that this protocol should be Historic - so could you > please sponsor the publication of this document as RFC? > > There us also neither a need nor a utility. Is there some other reason you ate > trying so hard to get an RFC published? If you mean IRTP IANA Considerations, I have asked to withdraw it. Now I propose tsvwg-irtp-to-historic-00. Moreover, I think that would be OK for RDP too. > Joe > > You may have seen > http://www.ietf.org/mail-archive/web/ietf/current/msg65008.html > if not I suggest you take a look and respond. It is a forward of > an IESG message for a Last Call. > > Tom Petch > > > > > Joe= > > From fernando.gont.netbook@gmail.com Wed Jan 5 22:53:37 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C88043A6BF1 for ; Wed, 5 Jan 2011 22:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nymNDkjb3zA0 for ; Wed, 5 Jan 2011 22:53:21 -0800 (PST) Received: from mail-fx0-f66.google.com (mail-fx0-f66.google.com [209.85.161.66]) by core3.amsl.com (Postfix) with ESMTP id 241B93A6C77 for ; Wed, 5 Jan 2011 22:53:13 -0800 (PST) Received: by fxm14 with SMTP id 14so4816551fxm.1 for ; Wed, 05 Jan 2011 22:55:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=pmyw0It2+TryUVlVE3BpHRql6UPRO+yfG2k2EDUJEQk=; b=O9YnJGKyHaNmMqkP20nANO/z90v/6krN8KehpKh89yXrpvB1IHUHR0EfOHNVfY1P0i 1v6XyzB1MDEkRpqUWMkU9dAPWBrj1LM2TeUbHBiO2tnQ9vJulvyi3d7YCLuwBvMZxHi+ fzVdyEVEQeyuh3wczdETS+GV2elySBKWubQv8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=KU3mtcbRWBjqOu8vqpIa9veaG50Lw1DJk3hA8EHewle4KM3Zfvo9zY/iFnWNmxBlqs S+i9rczy4FtpeMZ39teBtS66vTh/QHTMPBvybC7J4owBV9QpD8FMvsIvxjGPIDjq8kGw 3lGaoIECV6qBxbaHeO7WA0UKpb6ExzbT0hjmg= MIME-Version: 1.0 Received: by 10.223.98.204 with SMTP id r12mr2644744fan.102.1294296907873; Wed, 05 Jan 2011 22:55:07 -0800 (PST) Sender: fernando.gont.netbook@gmail.com Received: by 10.223.74.3 with HTTP; Wed, 5 Jan 2011 22:55:07 -0800 (PST) In-Reply-To: References: <4D21F2FC.2090000@erg.abdn.ac.uk> Date: Thu, 6 Jan 2011 03:55:07 -0300 X-Google-Sender-Auth: 7rHKs-vAB4x1wCdCjnvVUJXWj3k Message-ID: Subject: Re: Deprecation of ICMP Source Quench messages (draft-gont-tsvwg-source-quench) From: Fernando Gont To: Fred Baker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Gorry Fairhurst , "tsvwg-chairs@tools.ietf.org" , tsvwg list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 06:53:37 -0000 Hi, Fred, Please take a look at the document. Among other things, it deprecates the *reaction* to ICMP SQ. -- Specs-wise, TCP is still required to slow down upon receipt of an ICMP SQ. Thanks! Best regards, Fernando On Wed, Jan 5, 2011 at 3:15 PM, Fred Baker wrote: > As we have discussed privately, I'm not sure I agree that the deprecation= of source quench is "undocumented", given RFC 1812's comments on it, but t= he statements are at the MAY/SHOULD level, not MUST. Given that we don't se= e source quench in use in the network and source quench was not carried for= ward into IPv6 (which is where current attention SHOULD be, IMHO), I don't = think that a document changing "SHOULD" to "MUST" accomplishes much. The do= cument is probably a very fine document, but I don't think the issue is a g= ood use of the working group's time. > > From RFC 1812: > > 4.3.3.3 Source Quench > > =A0 A router SHOULD NOT originate ICMP Source Quench messages. =A0As > =A0 specified in Section [4.3.2], a router that does originate Source > =A0 Quench messages MUST be able to limit the rate at which they are > =A0 generated. > > =A0 DISCUSSION > =A0 =A0 =A0Research seems to suggest that Source Quench consumes network > =A0 =A0 =A0bandwidth but is an ineffective (and unfair) antidote to > =A0 =A0 =A0congestion. =A0See, for example, [INTERNET:9] and [INTERNET:10= ]. > =A0 =A0 =A0Section [5.3.6] discusses the current thinking on how routers > =A0 =A0 =A0ought to deal with overload and network congestion. > > =A0 A router MAY ignore any ICMP Source Quench messages it receives. > > =A0 DISCUSSION > =A0 =A0 =A0A router itself may receive a Source Quench as the result of > =A0 =A0 =A0originating a packet sent to another router or host. =A0Such > =A0 =A0 =A0datagrams might be, e.g., an EGP update sent to another router= , or > =A0 =A0 =A0a telnet stream sent to a host. =A0A mechanism has been propos= ed > =A0 =A0 =A0([INTERNET:11], [INTERNET:12]) to make the IP layer respond > =A0 =A0 =A0directly to Source Quench by controlling the rate at which pac= kets > =A0 =A0 =A0are sent, however, this proposal is currently experimental and= not > =A0 =A0 =A0currently recommended. > > 5.3.6 Congestion Control > =A0 ... > =A0 As described in Section [4.3.3.3], this document recommends that a > =A0 router SHOULD NOT send a Source Quench to the sender of the packet > =A0 that it is discarding. =A0ICMP Source Quench is a very weak mechanism= , > =A0 so it is not necessary for a router to send it, and host software > =A0 should not use it exclusively as an indicator of congestion. > > On Jan 3, 2011, at 8:02 AM, Gorry Fairhurst wrote: > >> There was discussion of the draft below on the TSVWG list and at the las= t IETF meeting. >> >> Deprecation of ICMP Source Quench messages >> (draft-gont-tsvwg-source-quench) >> http://tools.ietf.org/html/draft-gont-tsvwg-source-quench-01 >> >> We'd welcome feedback to the list on the question below: >> >> =A0 "Does the WG believe this document effectively addresses >> =A0 an existing problem, and should this draft form the basis for >> =A0 a solution?" >> >> Please email the chairs and/or list if you support this as a work item, = or have comments on the suitability of this draft as a TSVWG work item. >> >> Best wishes, >> >> Gorry & James >> (TSVWG Co-Chairs) > > From fred@cisco.com Wed Jan 5 23:09:24 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD96B3A6EBC for ; Wed, 5 Jan 2011 23:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.419 X-Spam-Level: X-Spam-Status: No, score=-110.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHmHxuIdcUd7 for ; Wed, 5 Jan 2011 23:09:24 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 098443A6E5B for ; Wed, 5 Jan 2011 23:09:24 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGX5JE2rRN+J/2dsb2JhbACkIHOmHJg0hUwEhGeGIoMd X-IronPort-AV: E=Sophos;i="4.60,282,1291593600"; d="scan'208";a="254341172" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-3.cisco.com with ESMTP; 06 Jan 2011 07:11:31 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p067BP7Q025578; Thu, 6 Jan 2011 07:11:30 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Wed, 05 Jan 2011 23:11:31 -0800 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Wed, 05 Jan 2011 23:11:31 -0800 Subject: Re: Deprecation of ICMP Source Quench messages (draft-gont-tsvwg-source-quench) Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: Date: Wed, 5 Jan 2011 23:11:16 -0800 Message-Id: References: <4D21F2FC.2090000@erg.abdn.ac.uk> To: Fernando Gont X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Gorry Fairhurst , "tsvwg-chairs@tools.ietf.org" , tsvwg list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 07:09:24 -0000 On Jan 5, 2011, at 10:55 PM, Fernando Gont wrote: > Please take a look at the document. Among other things, it deprecates > the *reaction* to ICMP SQ. -- Specs-wise, TCP is still required to > slow down upon receipt of an ICMP SQ. Are there any Source Quenches out there? Do you know of any equipment = anywhere that is generating them?= From fernando.gont.netbook@gmail.com Wed Jan 5 23:29:33 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B2993A6EF8 for ; Wed, 5 Jan 2011 23:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.894 X-Spam-Level: X-Spam-Status: No, score=-2.894 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zo2lRzjNI-by for ; Wed, 5 Jan 2011 23:29:32 -0800 (PST) Received: from mail-fx0-f66.google.com (mail-fx0-f66.google.com [209.85.161.66]) by core3.amsl.com (Postfix) with ESMTP id 25E5D3A6EF7 for ; Wed, 5 Jan 2011 23:29:31 -0800 (PST) Received: by fxm14 with SMTP id 14so4821993fxm.1 for ; Wed, 05 Jan 2011 23:31:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=L1Jp3TxbQXKL+orRVh3Kr8k4cyvAbC33rsVHPGD9X3o=; b=ps5JCYokqbHJ1c5JIQ4gtFy7ODepNmp+gsthL5nMbKXlhBJzTuBwwhpyJMiKWSrFDA 1hgJk+O+DpVJxskH8kzjaSdJK4r7dl1bPJcomumAJXL5g7OzeJiloPTKWpsSlH8lXKbH h2SGnFF2GKUpw/jkrdavv68iRJmgkeX7cHqnk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=JoyE5BKvMfK+Bv0FUzVdQ1wKn6mnSrt+UAPj7a0juEbe1qIV9G00aqbcyEIVrGa7Lc SKlGrnOspUuu+kw0KvZpCybEi9HzWo4pwqxk76hMRwRFlO19yNuPyfETaWOimDOYdl22 0522f3W3DE7dU32eLxGxDeMT1fXkbeswRp3HU= MIME-Version: 1.0 Received: by 10.223.83.201 with SMTP id g9mr237407fal.140.1294299098360; Wed, 05 Jan 2011 23:31:38 -0800 (PST) Sender: fernando.gont.netbook@gmail.com Received: by 10.223.74.3 with HTTP; Wed, 5 Jan 2011 23:31:38 -0800 (PST) In-Reply-To: References: <4D21F2FC.2090000@erg.abdn.ac.uk> Date: Thu, 6 Jan 2011 04:31:38 -0300 X-Google-Sender-Auth: kQFbHOetEsOkPU8j7Aqa3-R_3Qs Message-ID: Subject: Re: Deprecation of ICMP Source Quench messages (draft-gont-tsvwg-source-quench) From: Fernando Gont To: Fred Baker Content-Type: text/plain; charset=ISO-8859-1 Cc: Gorry Fairhurst , "tsvwg-chairs@tools.ietf.org" , tsvwg list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 07:29:33 -0000 On Thu, Jan 6, 2011 at 4:11 AM, Fred Baker wrote: >> Please take a look at the document. Among other things, it deprecates >> the *reaction* to ICMP SQ. -- Specs-wise, TCP is still required to >> slow down upon receipt of an ICMP SQ. > > Are there any Source Quenches out there? Do you know of any equipment anywhere that is generating them? Isn't one of the IETF's responsibilities to maintain its specifications? Or has it become intentional for the specs to be disconnected with the "running code"? Thanks, Fernando From fred@cisco.com Wed Jan 5 23:33:18 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03D333A6BAD for ; Wed, 5 Jan 2011 23:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.423 X-Spam-Level: X-Spam-Status: No, score=-110.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvqyTLQNKiKe for ; Wed, 5 Jan 2011 23:33:16 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id C62F13A6EF6 for ; Wed, 5 Jan 2011 23:33:16 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADj/JE2rRN+J/2dsb2JhbACkH3OmD5g5hUwEhGeGIoMdiA4 X-IronPort-AV: E=Sophos;i="4.60,282,1291593600"; d="scan'208";a="241241909" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 06 Jan 2011 07:35:23 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p067ZI5J003786; Thu, 6 Jan 2011 07:35:23 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Wed, 05 Jan 2011 23:35:23 -0800 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Wed, 05 Jan 2011 23:35:23 -0800 Subject: Re: Deprecation of ICMP Source Quench messages (draft-gont-tsvwg-source-quench) Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: Date: Wed, 5 Jan 2011 23:35:09 -0800 Message-Id: <068B22BC-E1B4-4C7F-99C5-3B8B483EB057@cisco.com> References: <4D21F2FC.2090000@erg.abdn.ac.uk> To: Gorry Fairhurst X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "tsvwg-chairs@tools.ietf.org chair" , tsvwg list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 07:33:18 -0000 I think my view is clear. There is no operational problem. The working = group can decide what it wants to do. On Jan 5, 2011, at 10:15 AM, Fred Baker wrote: > As we have discussed privately, I'm not sure I agree that the = deprecation of source quench is "undocumented", given RFC 1812's = comments on it, but the statements are at the MAY/SHOULD level, not = MUST. Given that we don't see source quench in use in the network and = source quench was not carried forward into IPv6 (which is where current = attention SHOULD be, IMHO), I don't think that a document changing = "SHOULD" to "MUST" accomplishes much. The document is probably a very = fine document, but I don't think the issue is a good use of the working = group's time. >=20 > =46rom RFC 1812: >=20 > 4.3.3.3 Source Quench >=20 > A router SHOULD NOT originate ICMP Source Quench messages. As > specified in Section [4.3.2], a router that does originate Source > Quench messages MUST be able to limit the rate at which they are > generated. >=20 > DISCUSSION > Research seems to suggest that Source Quench consumes network > bandwidth but is an ineffective (and unfair) antidote to > congestion. See, for example, [INTERNET:9] and [INTERNET:10]. > Section [5.3.6] discusses the current thinking on how routers > ought to deal with overload and network congestion. >=20 > A router MAY ignore any ICMP Source Quench messages it receives. >=20 > DISCUSSION > A router itself may receive a Source Quench as the result of > originating a packet sent to another router or host. Such > datagrams might be, e.g., an EGP update sent to another router, = or > a telnet stream sent to a host. A mechanism has been proposed > ([INTERNET:11], [INTERNET:12]) to make the IP layer respond > directly to Source Quench by controlling the rate at which = packets > are sent, however, this proposal is currently experimental and = not > currently recommended. >=20 > 5.3.6 Congestion Control > ... > As described in Section [4.3.3.3], this document recommends that a > router SHOULD NOT send a Source Quench to the sender of the packet > that it is discarding. ICMP Source Quench is a very weak mechanism, > so it is not necessary for a router to send it, and host software > should not use it exclusively as an indicator of congestion. >=20 > On Jan 3, 2011, at 8:02 AM, Gorry Fairhurst wrote: >=20 >> There was discussion of the draft below on the TSVWG list and at the = last IETF meeting. >>=20 >> Deprecation of ICMP Source Quench messages >> (draft-gont-tsvwg-source-quench) >> http://tools.ietf.org/html/draft-gont-tsvwg-source-quench-01 >>=20 >> We'd welcome feedback to the list on the question below: >>=20 >> "Does the WG believe this document effectively addresses >> an existing problem, and should this draft form the basis for >> a solution?" >>=20 >> Please email the chairs and/or list if you support this as a work = item, or have comments on the suitability of this draft as a TSVWG work = item. >>=20 >> Best wishes, >>=20 >> Gorry & James >> (TSVWG Co-Chairs) >=20 From touch@isi.edu Thu Jan 6 00:00:59 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 859963A6EF6 for ; Thu, 6 Jan 2011 00:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.169 X-Spam-Level: X-Spam-Status: No, score=-102.169 tagged_above=-999 required=5 tests=[AWL=-0.369, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmFPiMuK0IlD for ; Thu, 6 Jan 2011 00:00:58 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id BA3EE3A6C5A for ; Thu, 6 Jan 2011 00:00:58 -0800 (PST) Received: from [192.168.1.90] (pool-71-105-94-39.lsanca.dsl-w.verizon.net [71.105.94.39]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p06821AD012936 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 6 Jan 2011 00:02:13 -0800 (PST) Message-ID: <4D2576F8.4060402@isi.edu> Date: Thu, 06 Jan 2011 00:02:00 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mykyta Yevstifeyev Subject: Re: Draft Review Request - IRTP IANA Considerations References: <4D1715BE.6040100@gmail.com> <4D199D89.4080508@gmail.com><00eb01cba6a5$b5606840$4001a8c0@gateway.2wire.net><4D1D6EB3.40803@gmail.com> <4D2223E4.2040104@isi.edu><4D240101.6090308@gmail.com> <5131531F-D1E6-44F1-8FC0-94CBCF6CC2A8@isi.edu> <024801cbaccd$e347d580$4001a8c0@gateway.2wire.net> <4D25548C.5000800@gmail.com> In-Reply-To: <4D25548C.5000800@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 08:00:59 -0000 On 1/5/2011 9:35 PM, Mykyta Yevstifeyev wrote: ... >>> Maybe there is no doubt that this protocol should be Historic - so >>> could you >> please sponsor the publication of this document as RFC? >> >> There us also neither a need nor a utility. Is there some other reason >> you ate >> trying so hard to get an RFC published? > > If you mean IRTP IANA Considerations, I have asked to withdraw it. Now I > propose tsvwg-irtp-to-historic-00. I mean moving any of these to historic as well. There is neither a need nor a utility to doing this. Joe From touch@isi.edu Thu Jan 6 00:02:36 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 236CB3A6B45 for ; Thu, 6 Jan 2011 00:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.155 X-Spam-Level: X-Spam-Status: No, score=-102.155 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqRvPD-yrbUK for ; Thu, 6 Jan 2011 00:02:35 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 810003A6B73 for ; Thu, 6 Jan 2011 00:02:35 -0800 (PST) Received: from [192.168.1.90] (pool-71-105-94-39.lsanca.dsl-w.verizon.net [71.105.94.39]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p0683rSU013057 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 6 Jan 2011 00:04:05 -0800 (PST) Message-ID: <4D257766.7060808@isi.edu> Date: Thu, 06 Jan 2011 00:03:50 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mykyta Yevstifeyev Subject: Re: Draft Review Request - IRTP IANA Considerations References: <4D1715BE.6040100@gmail.com> <4D199D89.4080508@gmail.com><00eb01cba6a5$b5606840$4001a8c0@gateway.2wire.net><4D1D6EB3.40803@gmail.com> <4D2223E4.2040104@isi.edu><4D240101.6090308@gmail.com> <5131531F-D1E6-44F1-8FC0-94CBCF6CC2A8@isi.edu> <024801cbaccd$e347d580$4001a8c0@gateway.2wire.net> <4D2554F8.7060201@gmail.com> In-Reply-To: <4D2554F8.7060201@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 08:02:36 -0000 On 1/5/2011 9:36 PM, Mykyta Yevstifeyev wrote: ... >>> Maybe there is no doubt that this protocol should be Historic - so >>> could you >> please sponsor the publication of this document as RFC? >> >> There us also neither a need nor a utility. Is there some other reason >> you ate >> trying so hard to get an RFC published? > > If you mean IRTP IANA Considerations, I have asked to withdraw it. Now I > propose tsvwg-irtp-to-historic-00. Moreover, I think that would be OK > for RDP too. This too has no need nor utility. They're experimental. They're outdated and not in use. They're not being replaced with anything. There's no point in doing *anything* associated with *any* of these protocols (IRTP, NETBLT, RDP). Joe From bidulock@openss7.org Thu Jan 6 01:20:24 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCD7C3A6C33 for ; Thu, 6 Jan 2011 01:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06Qnz71+kiUM for ; Thu, 6 Jan 2011 01:20:23 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 9049D3A6C19 for ; Thu, 6 Jan 2011 01:20:23 -0800 (PST) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p069KorK017145; Thu, 6 Jan 2011 02:20:50 -0700 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p069KnSC014603; Thu, 6 Jan 2011 02:20:49 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p069KmhS014602; Thu, 6 Jan 2011 02:20:48 -0700 Date: Thu, 6 Jan 2011 02:20:48 -0700 From: "Brian F. G. Bidulock" To: Fred Baker Subject: Re: Deprecation of ICMP Source Quench messages (draft-gont-tsvwg-source-quench) Message-ID: <20110106092048.GA14506@openss7.org> Mail-Followup-To: Fred Baker , Gorry Fairhurst , "tsvwg-chairs@tools.ietf.org chair" , tsvwg list References: <4D21F2FC.2090000@erg.abdn.ac.uk> <068B22BC-E1B4-4C7F-99C5-3B8B483EB057@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <068B22BC-E1B4-4C7F-99C5-3B8B483EB057@cisco.com> Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Gorry Fairhurst , "tsvwg-chairs@tools.ietf.org chair" , tsvwg list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 09:20:25 -0000 Fred, Fred Baker wrote: (Wed, 05 Jan 2011 23:35:09) > > I think my view is clear. There is no operational problem. The > working group can decide what it wants to do. > Well, I agree with you, Fred. It is even more wasteful of the WG's time arguing whether it is wasteful of the WG's time. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From evnikita2@gmail.com Thu Jan 6 02:57:51 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61C0C3A6B72 for ; Thu, 6 Jan 2011 02:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[AWL=-0.949, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9MhFU601sZY for ; Thu, 6 Jan 2011 02:57:50 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 60EDA3A6A1A for ; Thu, 6 Jan 2011 02:57:50 -0800 (PST) Received: by bwz12 with SMTP id 12so16179135bwz.31 for ; Thu, 06 Jan 2011 02:59:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=lEv7Ck8jaPq8JviKoXXt9gVLhvHDl8Js4fwsHHv1lhA=; b=H57ylSzGg5IuQOYiJAKU/rfa45kvxMR/LXqd5eTso9D28VOzUOpYMd0siV1N7ILEWc UTLrFeAldhbNrI3FHrWfo1NJbMQl2QEE3a75iaVi8wjBJBYmp/qw5lHtE2WU6CuLuQVO 9JPHKc+KWf3qVZK6vjhKfknnzMO6YBQ80wiJ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=JQP4Sn+gaW1dHSKOvZKvUoQjjgUnhgBecu09iga472LrbBv45Qm32Tz7aRKpWdmvsC Q3H1BW/RqSH1A4IzMrHpsRSRSlGxo0V1bBrCWbt1pR7/dwBWzK9HdxMIlcXRAcQ7XR1F usR8O9ZRoyqBzL7G8Rwp749nrYaMp9T0rXwx8= Received: by 10.204.23.66 with SMTP id q2mr2337238bkb.130.1294311596485; Thu, 06 Jan 2011 02:59:56 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id j11sm13479079bka.12.2011.01.06.02.59.54 (version=SSLv3 cipher=RC4-MD5); Thu, 06 Jan 2011 02:59:55 -0800 (PST) Message-ID: <4D25A0BC.9050505@gmail.com> Date: Thu, 06 Jan 2011 13:00:12 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Joe Touch Subject: Re: Draft Review Request - IRTP IANA Considerations References: <4D1715BE.6040100@gmail.com> <4D199D89.4080508@gmail.com><00eb01cba6a5$b5606840$4001a8c0@gateway.2wire.net><4D1D6EB3.40803@gmail.com> <4D2223E4.2040104@isi.edu><4D240101.6090308@gmail.com> <5131531F-D1E6-44F1-8FC0-94CBCF6CC2A8@isi.edu> <024801cbaccd$e347d580$4001a8c0@gateway.2wire.net> <4D2554F8.7060201@gmail.com> <4D257766.7060808@isi.edu> In-Reply-To: <4D257766.7060808@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 10:57:51 -0000 06.01.2011 10:03, Joe Touch wrote: > > > On 1/5/2011 9:36 PM, Mykyta Yevstifeyev wrote: > ... >>>> Maybe there is no doubt that this protocol should be Historic - so >>>> could you >>> please sponsor the publication of this document as RFC? >>> >>> There us also neither a need nor a utility. Is there some other reason >>> you ate >>> trying so hard to get an RFC published? > > >> If you mean IRTP IANA Considerations, I have asked to withdraw it. Now I >> propose tsvwg-irtp-to-historic-00. Moreover, I think that would be OK >> for RDP too. > > This too has no need nor utility. > > They're experimental. They're outdated and not in use. They're not > being replaced with anything. There's no point in doing *anything* > associated with *any* of these protocols (IRTP, NETBLT, RDP). But there will be no harm if we mark them as Historic. That would just indicate that they are deprecated. > > Joe > From antonio.desimone@jhuapl.edu Thu Jan 6 06:38:48 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 583953A6F1D for ; Thu, 6 Jan 2011 06:38:48 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeB4YbIX2Y0N for ; Thu, 6 Jan 2011 06:38:47 -0800 (PST) Received: from jhuapl.edu (piper.jhuapl.edu [128.244.251.37]) by core3.amsl.com (Postfix) with ESMTP id E91643A6F16 for ; Thu, 6 Jan 2011 06:38:45 -0800 (PST) Received: from ([128.244.198.91]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.99128113; Thu, 06 Jan 2011 09:40:36 -0500 Received: from aplesstripe.dom1.jhuapl.edu ([128.244.198.211]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Thu, 6 Jan 2011 09:40:36 -0500 From: "DeSimone, Antonio" To: "bidulock@openss7.org" , Fred Baker Date: Thu, 6 Jan 2011 09:40:28 -0500 Subject: Re: Deprecation of ICMP Source Quench messages (draft-gont-tsvwg-source-quench) Thread-Topic: Deprecation of ICMP Source Quench messages (draft-gont-tsvwg-source-quench) Thread-Index: Acutg0OmvIk1vQhtThuhiYEm4tX6fgALGWQu Message-ID: In-Reply-To: <20110106092048.GA14506@openss7.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3377151628_5501743" MIME-Version: 1.0 Cc: Gorry Fairhurst , "tsvwg-chairs@tools.ietf.org chair" , tsvwg list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 14:38:48 -0000 --B_3377151628_5501743 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit On 1/6/11 4:20 AM, "Brian F. G. Bidulock" wrote: > Fred, > > Fred Baker wrote: (Wed, 05 Jan 2011 23:35:09) >> >> I think my view is clear. There is no operational problem. The >> working group can decide what it wants to do. >> I agree with Fred on this. There is no operational problem, but there is are minor spec problems. At best that is bad form, but there are some people who care about the specs. The doc closes the identified spec problems, in particular by updating 792 and 1122, which contain statements inconsistent with running code and now-accepted good practices. I support this draft as a tsvwg work item. > Well, I agree with you, Fred. It is even more wasteful of the WG's > time arguing whether it is wasteful of the WG's time agree > --brian --B_3377151628_5501743 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIII5AYJKoZIhvcNAQcCoIII1TCCCNECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B3AwggO/MIIDKKADAgECAgQ/8ZWsMA0GCSqGSIb3DQEBBQUAMC8xCzAJBgNVBAYTAlVTMQ8w DQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RDQTAeFw0wOTA4MDcxOTQ5NDVaFw0xMjA4 MDcyMDE5NDVaMGIxCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBlBl b3BsZTExMBYGA1UECxMPVlBOR3JvdXAtQklTRENBMBcGA1UEAxMQQW50b25pbyBEZVNpbW9u ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0gf4Pt6vdEUvUFX1QW9H8KmOcFejTq4W YfIvkBB2ugacSwNtUiyN4xKkGe1E+ytTikpmUGhKaslNxgB8Bxf7HgK1gBOWOBLGDwacTKs2 TlQNmAEAirBRq00CCh7pnB4L4fvS/F91NprOjGW0E6rj+JaM04vAwVIhxE7WEMEhMnsCAwEA AaOCAbMwggGvMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDA5MDgwNzE5NDk0NVqBDzIw MTEwOTE0MDAxOTQ1WjAaBg0rBgEEAbMlCwMBAQEBBAkWB2Rlc2ltYTEwGwYNKwYBBAGzJQsD AQEBAgQKEggwMDEwMTkxMDBYBglghkgBhvprHgEESwxJVGhlIHByaXZhdGUga2V5IGNvcnJl c3BvbmRpbmcgdG8gdGhpcyBjZXJ0aWZpY2F0ZSBtYXkgaGF2ZSBiZWVuIGV4cG9ydGVkLjAm BgNVHREEHzAdgRtBbnRvbmlvLkRlU2ltb25lQGpodWFwbC5lZHUwUgYDVR0fBEswSTBHoEWg Q6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RDQTEO MAwGA1UEAxMFQ1JMNTAwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYDVR0O BBYEFJ3KmWEKRClEnPi8G0W6+5hG6klJMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAwwChsE VjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAGdchoL9M3UjWrPW29jz2TDDKOLB9jQaBVXaH dtMaqNUIXr5ZtXq8petMGd9KfhdFnlTtIPmElzmufd9zbGWKJG0cgejZMdf+ig5jBDbJXoly qyNYOxxtxuc1c/Kmpaa181dodQebVKAvzSrWgWJX6tlCxDBBoudJjVKMvy6Ec4kwggOpMIID EqADAgECAgQ/8V0/MA0GCSqGSIb3DQEBBQUAMC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZK SFVBUEwxDzANBgNVBAsTBkJJU0RDQTAeFw0wODA4MjIxODQ4NDFaFw0xMTA4MjIxOTE4NDFa MGIxCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBlBlb3BsZTExMBYG A1UECxMPVlBOR3JvdXAtQklTRENBMBcGA1UEAxMQQW50b25pbyBEZVNpbW9uZTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAqVmufNAdYWcZhIkyy5EXDz6VMVrrah7KW4ZC3NLuSvrP OQ7ceylcjO9vWpsILlhsSktglU/goMN7RQrNG8SqbWzKMqg8EQygZoFEMpalZrEgI3/p99mM b/NEeg0XmOruZShNP2D7Bp35kclBxbG24VaQwosCyFfThbmBTvvaQp0CAwEAAaOCAZ0wggGZ MAsGA1UdDwQEAwIFIDAVBgNVHSUEDjAMBgorBgEEAYI3CgMEMBoGDSsGAQQBsyULAwEBAQEE CRYHZGVzaW1hMTAbBg0rBgEEAbMlCwMBAQECBAoSCDAwMTAxOTEwMFgGCWCGSAGG+mseAQRL DElUaGUgcHJpdmF0ZSBrZXkgY29ycmVzcG9uZGluZyB0byB0aGlzIGNlcnRpZmljYXRlIG1h eSBoYXZlIGJlZW4gZXhwb3J0ZWQuMCYGA1UdEQQfMB2BG0FudG9uaW8uRGVTaW1vbmVAamh1 YXBsLmVkdTBSBgNVHR8ESzBJMEegRaBDpEEwPzELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpI VUFQTDEPMA0GA1UECxMGQklTRENBMQ4wDAYDVQQDEwVDUkw0MzAfBgNVHSMEGDAWgBQINSmb EfnYRTYLJaYXYQkwHXKp6zAdBgNVHQ4EFgQUHVhSWQJTcRo1gUCttpeg6nbzBYcwCQYDVR0T BAIwADAZBgkqhkiG9n0HQQAEDDAKGwRWNy4xAwIEkDANBgkqhkiG9w0BAQUFAAOBgQANiu9i YhWwJpF7LEAZ88DTL5FZwAmSN6Im2IiZYp13WLQQyzWBX9nCvRAbim9WXMMezg5pI2bjj0rO tU1+XbuQiqlScz6n1Wmfcm0Bvp7bASxqgsQcTDWP2bLXwhkiJC6VNIwCf99JVq0yvPjsmRqB bijXm/hLKZT+qQ6mLQ97IzGCATwwggE4AgEBMDcwLzELMAkGA1UEBhMCVVMxDzANBgNVBAoT BkpIVUFQTDEPMA0GA1UECxMGQklTRENBAgQ/8ZWsMAkGBSsOAwIaBQCgXTAjBgkqhkiG9w0B CQQxFgQUpSenZuNbG7CSaUM1jrgBKF0RNgcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTEwMTA2MTQ0MDI4WjANBgkqhkiG9w0BAQEFAASBgIjNeuG7xidA hY080KRV9HZCM0gUNVYQpRILT32HlrhOYR7FN94Y0t1nbmzkz3xaDIatW7I/TpcidgGp1KQz 2Cdwilbj6KBcaFT7rrnoX2srYG2GwWuwPws4Jvzo2+C1N3SbI+rdajIq2cp65xjne3JpVqBZ 6epzmFN02o94qpX3 --B_3377151628_5501743-- From touch@isi.edu Thu Jan 6 07:56:41 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F87A3A6E2B for ; Thu, 6 Jan 2011 07:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.443 X-Spam-Level: X-Spam-Status: No, score=-101.443 tagged_above=-999 required=5 tests=[AWL=-1.039, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skKj+n9B3BVc for ; Thu, 6 Jan 2011 07:56:40 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 796CC3A6E1A for ; Thu, 6 Jan 2011 07:56:40 -0800 (PST) Received: from [192.168.1.91] (pool-71-105-94-39.lsanca.dsl-w.verizon.net [71.105.94.39]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p06Fw77i003862 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 6 Jan 2011 07:58:18 -0800 (PST) References: <4D1715BE.6040100@gmail.com> <4D199D89.4080508@gmail.com> <00eb01cba6a5$b5606840$4001a8c0@gateway.2wire.net> <4D1D6EB3.40803@gmail.com> <4D2223E4.2040104@isi.edu> <4D240101.6090308@gmail.com> <5131531F-D1E6-44F1-8FC0-94CBCF6CC2A8@isi.edu> <024801cbaccd$e347d580$4001a8c0@gateway.2wire.net> <4D2554F8.7060201@gmail.com> <4D257766.7060808@isi.edu> <4D25A0BC.9050505@gmail.com> In-Reply-To: <4D25A0BC.9050505@gmail.com> Mime-Version: 1.0 (iPad Mail 8C148) Content-Type: text/plain; charset=us-ascii Message-Id: <84DCE00C-E6FE-4148-9ADB-A573672DC5F0@isi.edu> Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (8C148) From: Joe Touch Subject: Re: Draft Review Request - IRTP IANA Considerations Date: Thu, 6 Jan 2011 08:01:46 -0800 To: Mykyta Yevstifeyev X-MailScanner-ID: p06Fw77i003862 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 15:56:41 -0000 On Jan 6, 2011, at 3:00 AM, Mykyta Yevstifeyev wrote: > 06.01.2011 10:03, Joe Touch wrote: >>=20 >>=20 >> On 1/5/2011 9:36 PM, Mykyta Yevstifeyev wrote: >> ... >>>>> Maybe there is no doubt that this protocol should be Historic - so >>>>> could you >>>> please sponsor the publication of this document as RFC? >>>>=20 >>>> There us also neither a need nor a utility. Is there some other reason >>>> you ate >>>> trying so hard to get an RFC published? >> > >>> If you mean IRTP IANA Considerations, I have asked to withdraw it. Now I= >>> propose tsvwg-irtp-to-historic-00. Moreover, I think that would be OK >>> for RDP too. >>=20 >> This too has no need nor utility. >>=20 >> They're experimental. They're outdated and not in use. They're not being r= eplaced with anything. There's no point in doing *anything* associated with *= any* of these protocols (IRTP, NETBLT, RDP). > But there will be no harm if we mark them as Historic. That would just ind= icate that they are deprecated. The harm is the time and resources you're wasting on what really does look l= ike a desperate attempt to write an RFC - any RFC.=20 You need to explain why these protocols *need* to be deprecated, and why tha= t has to happen now, *except* as a way to stop you from chasing useless IANA= support for these protocols.=20 Joe >>=20 From touch@isi.edu Thu Jan 6 09:57:01 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C15D3A6C9B for ; Thu, 6 Jan 2011 09:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.472 X-Spam-Level: X-Spam-Status: No, score=-102.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GL-L-TXFpevQ for ; Thu, 6 Jan 2011 09:57:00 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 826553A68D5 for ; Thu, 6 Jan 2011 09:57:00 -0800 (PST) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p06Hwjht022592 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 6 Jan 2011 09:58:45 -0800 (PST) Message-ID: <4D2602D5.30608@isi.edu> Date: Thu, 06 Jan 2011 09:58:45 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fred Baker , Gorry Fairhurst , "tsvwg-chairs@tools.ietf.org chair" , tsvwg list Subject: Re: Deprecation of ICMP Source Quench messages (draft-gont-tsvwg-source-quench) References: <4D21F2FC.2090000@erg.abdn.ac.uk> <068B22BC-E1B4-4C7F-99C5-3B8B483EB057@cisco.com> <20110106092048.GA14506@openss7.org> In-Reply-To: <20110106092048.GA14506@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p06Hwjht022592 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 17:57:01 -0000 +1 on both counts (agree with Fred, agree the WG should consume resources carefully) Joe On 1/6/2011 1:20 AM, Brian F. G. Bidulock wrote: > Fred, > > Fred Baker wrote: (Wed, 05 Jan 2011 23:35:09) >> >> I think my view is clear. There is no operational problem. The >> working group can decide what it wants to do. >> > > Well, I agree with you, Fred. It is even more wasteful of the WG's > time arguing whether it is wasteful of the WG's time. > > --brian > From fernando.gont.netbook.win@gmail.com Thu Jan 6 10:07:33 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDE993A6F4D for ; Thu, 6 Jan 2011 10:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.225 X-Spam-Level: X-Spam-Status: No, score=-3.225 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGWSv8nGNGJK for ; Thu, 6 Jan 2011 10:07:33 -0800 (PST) Received: from mail-gy0-f194.google.com (mail-gy0-f194.google.com [209.85.160.194]) by core3.amsl.com (Postfix) with ESMTP id 0A15A3A6F4F for ; Thu, 6 Jan 2011 10:07:32 -0800 (PST) Received: by gyf1 with SMTP id 1so3621045gyf.1 for ; Thu, 06 Jan 2011 10:09:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=iaDEjA3mlHegbGx4c9HPNF8azc91tX4yygqjEez5ghg=; b=ch85LqKgfsbCe+2qQ2Vlpa3MjYTFoXS5lU3VT4RVkJQm5xK+pJHKD9F2SaTAnMVBGQ KQ88JORSWR66zNh2pucQLtb5vnI0L6xXzRBhfMx/Mm84hmrLMGX58swMn6PUzjYqDkMZ zOc0B8EKaM9rjc0rwQJbwbjGZXbmA4M6OJ6nI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=N/bHYzVroeUQBCb9ked+viRiQtae4OZVVQHWga7KUNCQO6r8xQgnVWIqYL9x6wF4md BVwcCZITccPAZMYltpwQV4kdaUPf2uMvC5xNcV9PcbLMlodKYIiPiMs4DgXCuKfgnXTY 80JtHjEJZ8Br3dJ9wb/lEzY/ul7b3VWOKHwG4= Received: by 10.150.203.7 with SMTP id a7mr18667387ybg.114.1294337379598; Thu, 06 Jan 2011 10:09:39 -0800 (PST) Received: from [192.168.2.11] (155-136-17-190.fibertel.com.ar [190.17.136.155]) by mx.google.com with ESMTPS id p2sm2413225ybh.3.2011.01.06.10.09.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 06 Jan 2011 10:09:37 -0800 (PST) Sender: Fernando Gont Message-ID: <4D260555.8050901@gont.com.ar> Date: Thu, 06 Jan 2011 15:09:25 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Joe Touch Subject: Re: Deprecation of ICMP Source Quench messages (draft-gont-tsvwg-source-quench) References: <4D21F2FC.2090000@erg.abdn.ac.uk> <068B22BC-E1B4-4C7F-99C5-3B8B483EB057@cisco.com> <20110106092048.GA14506@openss7.org> <4D2602D5.30608@isi.edu> In-Reply-To: <4D2602D5.30608@isi.edu> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Gorry Fairhurst , "tsvwg-chairs@tools.ietf.org chair" , Fred Baker , tsvwg list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 18:07:34 -0000 Joe, It is "surprising" that you don't support this document (if I read your view correctly), as you were one of the motivators of this I-D. During the last few years, and in many opportunities, you have insisted that "we should formally deprecate ICMP SQ", etc. Given that the I-D is already good enough, the height of irony is that more resources are being wasted discussing whether we're wasting energy, rather than adopting the doc, possibly rev'ing it once more, WGLC and publish. Sigh.. P.S.: It makes me wonder that we, at the IETF, do not care about our specs being outdated and irrelevant. Fernando On 06/01/2011 02:58 p.m., Joe Touch wrote: > +1 on both counts (agree with Fred, agree the WG should consume > resources carefully) > > Joe > > On 1/6/2011 1:20 AM, Brian F. G. Bidulock wrote: >> Fred, >> >> Fred Baker wrote: (Wed, 05 Jan 2011 23:35:09) >>> >>> I think my view is clear. There is no operational problem. The >>> working group can decide what it wants to do. >>> >> >> Well, I agree with you, Fred. It is even more wasteful of the WG's >> time arguing whether it is wasteful of the WG's time. >> >> --brian >> > -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@isi.edu Thu Jan 6 10:15:20 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E91283A6CD8 for ; Thu, 6 Jan 2011 10:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XpNuzM+lOL2 for ; Thu, 6 Jan 2011 10:15:19 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id AC04C3A6CD7 for ; Thu, 6 Jan 2011 10:15:19 -0800 (PST) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p06IH0J8021129 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 6 Jan 2011 10:17:00 -0800 (PST) Message-ID: <4D26071C.30303@isi.edu> Date: Thu, 06 Jan 2011 10:17:00 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fernando Gont Subject: Re: Deprecation of ICMP Source Quench messages (draft-gont-tsvwg-source-quench) References: <4D21F2FC.2090000@erg.abdn.ac.uk> <068B22BC-E1B4-4C7F-99C5-3B8B483EB057@cisco.com> <20110106092048.GA14506@openss7.org> <4D2602D5.30608@isi.edu> <4D260555.8050901@gont.com.ar> In-Reply-To: <4D260555.8050901@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Gorry Fairhurst , "tsvwg-chairs@tools.ietf.org chair" , Fred Baker , tsvwg list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 18:15:21 -0000 On 1/6/2011 10:09 AM, Fernando Gont wrote: > Joe, > > It is "surprising" that you don't support this document (if I read your > view correctly), as you were one of the motivators of this I-D. During > the last few years, and in many opportunities, you have insisted that > "we should formally deprecate ICMP SQ", etc. Yes. Does that mean we need to create a separate doc to do it? No. We can put it on queue for 1122-bis or 1812-bis, and *whenever* that happens should be sufficient for this particular issue. I'm getting a bit tired of separate docs for each individual issue. Joe From fernando.gont.netbook.win@gmail.com Thu Jan 6 10:32:39 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AA893A6F3D for ; Thu, 6 Jan 2011 10:32:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlBRHfds9Eht for ; Thu, 6 Jan 2011 10:32:37 -0800 (PST) Received: from mail-yw0-f66.google.com (mail-yw0-f66.google.com [209.85.213.66]) by core3.amsl.com (Postfix) with ESMTP id BCA9E3A6F39 for ; Thu, 6 Jan 2011 10:32:37 -0800 (PST) Received: by ywi6 with SMTP id 6so3778460ywi.1 for ; Thu, 06 Jan 2011 10:34:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=C6W4gvRrq/9028ySoQR0VX4rxMYTbeXQo6NG/Hve8lI=; b=qstrW+7ajJA24EG9KD/nWfz8Auk1JPd3J2Lx9ZRXbARw15DqYn62ZRURMrVLXne/YH W+fLU8Ln0lXaQWKf8fxyOfl/QeVy4yFVYdbiAuuZqTr9MHY57Nyh5yktvYOYuqrlu37c eA/aegWrFGcD6uuiku+9ZJEcnsW8yOEgfQ39A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=JqducfO/wmVfSOZqqed/dWgv7ZGzscKb92+j23RlS/8qLFWRcmds7KhBXJQv+rvvzv 8tCSdo9FyCwbN69sWi3U5i42oOTMol+Gm2Ciqjl/zTYrdRfat3dxzNDougTrxun1BMxO NX47aqccfS5lHERSyKXXxBcTJn+XzzJP8vLoc= Received: by 10.90.61.19 with SMTP id j19mr2303605aga.161.1294338884223; Thu, 06 Jan 2011 10:34:44 -0800 (PST) Received: from [192.168.2.11] (155-136-17-190.fibertel.com.ar [190.17.136.155]) by mx.google.com with ESMTPS id d15sm32501713ana.35.2011.01.06.10.34.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 06 Jan 2011 10:34:43 -0800 (PST) Sender: Fernando Gont Message-ID: <4D260B3A.1050804@gont.com.ar> Date: Thu, 06 Jan 2011 15:34:34 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Joe Touch Subject: Re: Deprecation of ICMP Source Quench messages (draft-gont-tsvwg-source-quench) References: <4D21F2FC.2090000@erg.abdn.ac.uk> <068B22BC-E1B4-4C7F-99C5-3B8B483EB057@cisco.com> <20110106092048.GA14506@openss7.org> <4D2602D5.30608@isi.edu> <4D260555.8050901@gont.com.ar> <4D26071C.30303@isi.edu> In-Reply-To: <4D26071C.30303@isi.edu> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Gorry Fairhurst , "tsvwg-chairs@tools.ietf.org chair" , Fred Baker , tsvwg list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 18:32:39 -0000 On 06/01/2011 03:17 p.m., Joe Touch wrote: > Yes. Does that mean we need to create a separate doc to do it? No. You proposed exactly this a number of times, on the tcpm list. -- Should I dig the archive? > We can put it on queue for 1122-bis or 1812-bis, and *whenever* that > happens should be sufficient for this particular issue. Please be realistic. I'm not going to continue wasting energy discussing about wasting energy. Nor am I going to get into yet another endless discussion on why you oppose to virtually every document you have not authored. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@isi.edu Thu Jan 6 10:36:27 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE3293A6F43 for ; Thu, 6 Jan 2011 10:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lA1YCdEC+mgD for ; Thu, 6 Jan 2011 10:36:27 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id E390E3A6F35 for ; Thu, 6 Jan 2011 10:36:26 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p06Ibi27025045 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 6 Jan 2011 10:37:44 -0800 (PST) Message-ID: <4D260BF9.3030509@isi.edu> Date: Thu, 06 Jan 2011 10:37:45 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "tsvwg-chairs@tools.ietf.org chair" Subject: Using our resources efficiently References: <4D21F2FC.2090000@erg.abdn.ac.uk> <068B22BC-E1B4-4C7F-99C5-3B8B483EB057@cisco.com> <20110106092048.GA14506@openss7.org> <4D2602D5.30608@isi.edu> <4D260555.8050901@gont.com.ar> <4D26071C.30303@isi.edu> In-Reply-To: <4D26071C.30303@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 18:36:27 -0000 As a followup to the note below, I'd like to raise a separate point of discussion. On 1/6/2011 10:17 AM, Joe Touch wrote: ... > I'm getting a bit tired of separate docs for each individual issue. I'd really like to see some time spent at each WG meeting, and periodically on the list (TSVWG and TCPM at least, but all WGs would benefit from this, IMO), addressing: - what CAN be done (vs what can't) - what SHOULD be done - HOW to do it, once decided - prioritization of WHEN to do it, given the above Right now, we tend to ask the first question only. What does that mean to this most recent discussion? - issues that are not related should be separated out an RFC is not an opportunity for a shopping list - separate issues should be considered independently - just because we agree on an issue does NOT mean an RFC is warranted Joe From touch@isi.edu Thu Jan 6 10:41:27 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 187623A6F43 for ; Thu, 6 Jan 2011 10:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMgyysm3N0qj for ; Thu, 6 Jan 2011 10:41:26 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 465F43A6F35 for ; Thu, 6 Jan 2011 10:41:26 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p06Igd8e025948 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 6 Jan 2011 10:42:39 -0800 (PST) Message-ID: <4D260D1F.3000809@isi.edu> Date: Thu, 06 Jan 2011 10:42:39 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fernando Gont Subject: Re: Deprecation of ICMP Source Quench messages (draft-gont-tsvwg-source-quench) References: <4D21F2FC.2090000@erg.abdn.ac.uk> <068B22BC-E1B4-4C7F-99C5-3B8B483EB057@cisco.com> <20110106092048.GA14506@openss7.org> <4D2602D5.30608@isi.edu> <4D260555.8050901@gont.com.ar> <4D26071C.30303@isi.edu> <4D260B3A.1050804@gont.com.ar> In-Reply-To: <4D260B3A.1050804@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Gorry Fairhurst , "tsvwg-chairs@tools.ietf.org chair" , Fred Baker , tsvwg list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 18:41:27 -0000 On 1/6/2011 10:34 AM, Fernando Gont wrote: > On 06/01/2011 03:17 p.m., Joe Touch wrote: > >> Yes. Does that mean we need to create a separate doc to do it? No. > > You proposed exactly this a number of times, on the tcpm list. -- Should > I dig the archive? Yes, I wanted the issue separate so we could decide on it *independently*. Once we decide what do do, we can then make a decision on how best to do it. In this case, there's no disagreement that SQ should be deprecated, or that (IMO) that issue should be decided independent of other ICMP or TCP issues. The question is whether *issuing* a separate doc is the best way to achieve that recommendation. IMO, this is one of the ones that can wait. that's what I'm hearing from others too. >> We can put it on queue for 1122-bis or 1812-bis, and *whenever* that >> happens should be sufficient for this particular issue. > > Please be realistic. We all are. Realistically, an RFC officially deprecating a feature that is already recommended against, and is already not being used (far as any of us can tell) serves no *urgent* purpose. Yes, that means this issue might wait on the shelf for a long time. So what? Joe From wes@mti-systems.com Thu Jan 6 18:49:05 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78E173A6E3B for ; Thu, 6 Jan 2011 18:49:05 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSFI6zb3fNi4 for ; Thu, 6 Jan 2011 18:49:04 -0800 (PST) Received: from omr6.networksolutionsemail.com (omr6.networksolutionsemail.com [205.178.146.56]) by core3.amsl.com (Postfix) with ESMTP id 5C0023A6DF7 for ; Thu, 6 Jan 2011 18:49:04 -0800 (PST) Received: from cm-omr6 (mail.networksolutionsemail.com [205.178.146.50]) by omr6.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p072pAnn017620 for ; Thu, 6 Jan 2011 21:51:10 -0500 Authentication-Results: cm-omr6 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [174.130.41.205] ([174.130.41.205:25813] helo=[192.168.1.104]) by cm-omr6 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 82/08-22185-E9F762D4; Thu, 06 Jan 2011 21:51:10 -0500 Message-ID: <4D267F98.6050508@mti-systems.com> Date: Thu, 06 Jan 2011 21:51:04 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Joe Touch , tsvwg@ietf.org Subject: Re: Deprecation of ICMP Source Quench messages (draft-gont-tsvwg-source-quench) References: <4D21F2FC.2090000@erg.abdn.ac.uk> <068B22BC-E1B4-4C7F-99C5-3B8B483EB057@cisco.com> <20110106092048.GA14506@openss7.org> <4D2602D5.30608@isi.edu> <4D260555.8050901@gont.com.ar> <4D26071C.30303@isi.edu> <4D260B3A.1050804@gont.com.ar> <4D260D1F.3000809@isi.edu> In-Reply-To: <4D260D1F.3000809@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 02:49:05 -0000 On 1/6/2011 1:42 PM, Joe Touch wrote: > > > On 1/6/2011 10:34 AM, Fernando Gont wrote: >> >> Please be realistic. > > We all are. Realistically, an RFC officially deprecating a feature that > is already recommended against, and is already not being used (far as > any of us can tell) serves no *urgent* purpose. > > Yes, that means this issue might wait on the shelf for a long time. So > what? > Realistically, if there isn't an RFC, 2 years from now someone will come and re-write Fernando's document and ask to have an RFC published and we'll waste more time on the same discussion, so I'm in favor of blasting this through the process and getting it published as long as there's rough consensus on it. We publish plenty of similarly useless book-keeping RFCs without controversy. -- Wes Eddy MTI Systems From evnikita2@gmail.com Thu Jan 6 22:06:19 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E37F33A67B7 for ; Thu, 6 Jan 2011 22:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.76 X-Spam-Level: X-Spam-Status: No, score=-2.76 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnZ8qEsLnlJT for ; Thu, 6 Jan 2011 22:06:18 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 4CFB63A67B1 for ; Thu, 6 Jan 2011 22:06:18 -0800 (PST) Received: by bwz12 with SMTP id 12so16950599bwz.31 for ; Thu, 06 Jan 2011 22:08:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type; bh=81rGhDVaks/3L9osXWeztvjif/N+4LbPRl0wdf3jY3I=; b=m6QwofpqjbHkEAp0/COXUJvPjkb7ZYu5US0O8Cu/r83gd/Xex8dPARIfHaTZcvjYSK lMpvSe4zDqTXe6VDQ2FbLdYpFgfuGOINGmBTja9/PBuR316BWiDfESFTn0uUFZING1XK v+KBargPRltmW0Sg8AJ76HWP2/onUC8WC9FZs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; b=GJCEF2dneHXNtgPAy++3/1skvBi/BbM85cXQP5QSt4X7HAGKhMJTH5Owhsqkmbmepd sKsGK6YFqqX7wFQMmbzzoCg9AlnFIZ9Gw5DHoklwVVqetcAEePu6holMpP7UkRI5L2fH 7BXhWt5e50reVsqaU9QBcYKGTtdMF2f2emCek= Received: by 10.204.53.148 with SMTP id m20mr3103413bkg.150.1294380504435; Thu, 06 Jan 2011 22:08:24 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id v25sm13843872bkt.6.2011.01.06.22.08.22 (version=SSLv3 cipher=RC4-MD5); Thu, 06 Jan 2011 22:08:23 -0800 (PST) Message-ID: <4D26ADE8.5080001@gmail.com> Date: Fri, 07 Jan 2011 08:08:40 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Joe Touch Subject: Re: Draft Review Request - IRTP IANA Considerations References: <4D1715BE.6040100@gmail.com> <4D199D89.4080508@gmail.com> <00eb01cba6a5$b5606840$4001a8c0@gateway.2wire.net> <4D1D6EB3.40803@gmail.com> <4D2223E4.2040104@isi.edu> <4D240101.6090308@gmail.com> <5131531F-D1E6-44F1-8FC0-94CBCF6CC2A8@isi.edu> <024801cbaccd$e347d580$4001a8c0@gateway.2wire.net> <4D2554F8.7060201@gmail.com> <4D257766.7060808@isi.edu> <4D25A0BC.9050505@gmail.com> <84DCE00C-E6FE-4148-9ADB-A573672DC5F0@isi.edu> In-Reply-To: <84DCE00C-E6FE-4148-9ADB-A573672DC5F0@isi.edu> Content-Type: multipart/alternative; boundary="------------060401030108000703070100" Cc: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 06:06:20 -0000 This is a multi-part message in MIME format. --------------060401030108000703070100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 06.01.2011 18:01, Joe Touch wrote: > On Jan 6, 2011, at 3:00 AM, Mykyta Yevstifeyev wrote: > >> 06.01.2011 10:03, Joe Touch wrote: >>> On 1/5/2011 9:36 PM, Mykyta Yevstifeyev wrote: >>> ... >>>>>> Maybe there is no doubt that this protocol should be Historic - so >>>>>> could you >>>>> please sponsor the publication of this document as RFC? >>>>> >>>>> There us also neither a need nor a utility. Is there some other reason >>>>> you ate >>>>> trying so hard to get an RFC published? >>>> If you mean IRTP IANA Considerations, I have asked to withdraw it. Now I >>>> propose tsvwg-irtp-to-historic-00. Moreover, I think that would be OK >>>> for RDP too. >>> This too has no need nor utility. >>> >>> They're experimental. They're outdated and not in use. They're not being replaced with anything. There's no point in doing *anything* associated with *any* of these protocols (IRTP, NETBLT, RDP). >> But there will be no harm if we mark them as Historic. That would just indicate that they are deprecated. > The harm is the time and resources you're wasting on what really does look like a desperate attempt to write an RFC - any RFC. > > You need to explain why these protocols *need* to be deprecated, and why that has to happen now, *except* as a way to stop you from chasing useless IANA support for these protocols. Dear Joe, Firstly, what draft we are speaking about? I consider the topic we are discussing to be 'moving old transport protocols to Historic'. So why you talk about IANA considerations for that? Moreover, let me cite your message I received before: > That's the key. This (and the other protocols you wrote similar docs > for, e.g., NETBLT and RDP) don't use IANA-assigned values. They have > values, but there was not a need for a registry for several reasons, > including the fact that they were experimental. > > At this point, they might be *better moved to historic* than anything > else. There's no reason to have IANA track or manage their values. > > Joe So on 3 January you say that they should be moved to Historic and now, after 3 days that there no need for this. Could you please claim your opinion clearly? Lastly, toy said: "You need to explain why these protocols *need* to be deprecated, and why that has to happen now". Let me explain this issues. They are *already* deprecated and my draft explains reasons that caused it clearly. Read it please carefully. All the best, Mykyta Yevstifeyev > Joe --------------060401030108000703070100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 06.01.2011 18:01, Joe Touch wrote:
On Jan 6, 2011, at 3:00 AM, Mykyta Yevstifeyev <evnikita2@gmail.com> wrote:

06.01.2011 10:03, Joe Touch wrote:
On 1/5/2011 9:36 PM, Mykyta Yevstifeyev wrote:
...
Maybe there is no doubt that this protocol should be Historic - so
could you
please sponsor the publication of this document as RFC?

There us also neither a need nor a utility. Is there some other reason
you ate
trying so hard to get an RFC published?
If you mean IRTP IANA Considerations, I have asked to withdraw it. Now I
propose tsvwg-irtp-to-historic-00. Moreover, I think that would be OK
for RDP too.
This too has no need nor utility.

They're experimental. They're outdated and not in use. They're not being replaced with anything. There's no point in doing *anything* associated with *any* of these protocols (IRTP, NETBLT, RDP).
But there will be no harm if we mark them as Historic. That would just indicate that they are deprecated.
The harm is the time and resources you're wasting on what really does look like a desperate attempt to write an RFC - any RFC. 

You need to explain why these protocols *need* to be deprecated, and why that has to happen now, *except* as a way to stop you from chasing useless IANA support for these protocols. 
Dear Joe,

Firstly, what draft we are speaking about? I consider the topic we are discussing to be 'moving old transport protocols to Historic'. So why you talk about IANA considerations for that?

Moreover, let me cite your message I received before:

That's the key. This (and the other protocols you wrote similar docs for, e.g., NETBLT and RDP) don't use IANA-assigned values. They have values, but there was not a need for a registry for several reasons, including the fact that they were experimental.

At this point, they might be better moved to historic than anything else. There's no reason to have IANA track or manage their values.

Joe
So on 3 January you say that they should be moved to Historic and now, after 3 days that there no need for this. Could you please claim your opinion clearly?

Lastly, toy said: "You need to explain why these protocols *need* to be deprecated, and why that has to happen now". Let me explain this issues. They are *already* deprecated and my draft explains reasons that caused it clearly. Read it please carefully.

All the best,
Mykyta Yevstifeyev
Joe

--------------060401030108000703070100-- From touch@isi.edu Thu Jan 6 22:34:42 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3A2B3A67C1 for ; Thu, 6 Jan 2011 22:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.106 X-Spam-Level: X-Spam-Status: No, score=-102.106 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYrC5FGYjPPP for ; Thu, 6 Jan 2011 22:34:39 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 836E53A67B4 for ; Thu, 6 Jan 2011 22:34:39 -0800 (PST) Received: from [192.168.1.90] (pool-71-105-94-39.lsanca.dsl-w.verizon.net [71.105.94.39]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p076aLxP007660 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 6 Jan 2011 22:36:31 -0800 (PST) Message-ID: <4D26B462.3040001@isi.edu> Date: Thu, 06 Jan 2011 22:36:18 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mykyta Yevstifeyev Subject: Re: Draft Review Request - IRTP IANA Considerations References: <4D1715BE.6040100@gmail.com> <4D199D89.4080508@gmail.com> <00eb01cba6a5$b5606840$4001a8c0@gateway.2wire.net> <4D1D6EB3.40803@gmail.com> <4D2223E4.2040104@isi.edu> <4D240101.6090308@gmail.com> <5131531F-D1E6-44F1-8FC0-94CBCF6CC2A8@isi.edu> <024801cbaccd$e347d580$4001a8c0@gateway.2wire.net> <4D2554F8.7060201@gmail.com> <4D257766.7060808@isi.edu> <4D25A0BC.9050505@gmail.com> <84DCE00C-E6FE-4148-9ADB-A573672DC5F0@isi.edu> <4D26ADE8.5080001@gmail.com> In-Reply-To: <4D26ADE8.5080001@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p076aLxP007660 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 06:34:42 -0000 Mykyta, On 1/6/2011 10:08 PM, Mykyta Yevstifeyev wrote: > Dear Joe, > > Firstly, what draft we are speaking about? I consider the topic we are > discussing to be 'moving old transport protocols to Historic'. So why > you talk about IANA considerations for that? Your first drafts focused on creating IANA registries for experimental protocols that are not in current use in the public Internet. > Moreover, let me cite your message I received before: > >> That's the key. This (and the other protocols you wrote similar docs >> for, e.g., NETBLT and RDP) don't use IANA-assigned values. They have >> values, but there was not a need for a registry for several reasons, >> including the fact that they were experimental. >> >> At this point, they might be *better moved to historic* than anything >> else. There's no reason to have IANA track or manage their values. >> >> Joe Just because I prefer moving these to historic to creating IANA registries does NOT mean I think that they *****NEED***** to be moved to historic. > Lastly, toy said: "You need to explain why these protocols *need* to be > deprecated, and why that has to happen now". Let me explain this issues. > They are *already* deprecated and my draft explains reasons that caused > it clearly. Read it please carefully. The protocols you cited are currently listed as Experimental. "Deprecated" is something we do to protocols in the IETF, typically by moving them to Historic. I did not use the term to mean "how the public informally views these protocols.". I.e., my statement above is equivalent to: "You need to explain why these protocols *need* to be moved to Historic". Such actions are typically reserved for protocols in current use that are dangerous, or protocols that are in current use that are being replaced by other protocols. Neither is the case here. There is no need to "move to Historic" (i.e., "deprecate", within the IETF process) such protocols. Joe From Internet-Drafts@ietf.org Fri Jan 7 03:15:02 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CFF93A681F; Fri, 7 Jan 2011 03:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.42 X-Spam-Level: X-Spam-Status: No, score=-102.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yToAbTCScesR; Fri, 7 Jan 2011 03:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE8D43A681D; Fri, 7 Jan 2011 03:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-tsvwg-sctpsocket-25.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110107111501.32039.4284.idtracker@localhost> Date: Fri, 07 Jan 2011 03:15:01 -0800 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 11:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Sockets API Extensions for Stream Control Transmission Protocol (SCTP) Author(s) : R. Stewart, et al. Filename : draft-ietf-tsvwg-sctpsocket-25.txt Pages : 111 Date : 2011-01-07 This document describes a mapping of the Stream Control Transmission Protocol (SCTP) into a sockets API. The benefits of this mapping include compatibility for TCP applications, access to new SCTP features and a consolidated error and event notification scheme. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-25.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tsvwg-sctpsocket-25.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-07031052.I-D@ietf.org> --NextPart-- From evnikita2@gmail.com Fri Jan 7 21:11:16 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 074913A6987; Fri, 7 Jan 2011 21:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.166 X-Spam-Level: X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZGV3PBuWUWk; Fri, 7 Jan 2011 21:11:14 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 6D3A33A6985; Fri, 7 Jan 2011 21:11:14 -0800 (PST) Received: by bwz12 with SMTP id 12so17774343bwz.31 for ; Fri, 07 Jan 2011 21:13:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=H1kv7eQomc9b6qILxdKMukAyEmCca6ZROH56uVGY5SM=; b=bdQRGddlERweisGS0RR9ZRevs347kBJztGeDF0vzhF02P8FhPMJLe5tOBnXozemFs1 wQfnxTod0Qf46S66pOr2hjmZCPQEuWbWIS4jGC9wiXkv/ZVIHeGvomitYXQa7z5Dns9a WrZxpYkZVNNmN+UAovT7KCPPnfdM/Ae6APA4k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=n9vSPUhtRibA9qZWR2g0iYyBfkGPuvrYGiN5j7VNBhN3OGr8tOyEjl1lgqx4ylxTp6 PQYPg9nw1Boz2oy7JTbD7LcoQ/PX6JsyphnTwU5DuWIK5aGXxxkD55l59365ulAFhMR8 Tk8ilA/N6yjcSpfoyhxDnXuWV3AFEe3SffXtM= Received: by 10.204.102.206 with SMTP id h14mr1301520bko.45.1294463599690; Fri, 07 Jan 2011 21:13:19 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id p22sm14414731bkp.9.2011.01.07.21.13.17 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 21:13:18 -0800 (PST) Message-ID: <4D27F280.1020205@gmail.com> Date: Sat, 08 Jan 2011 07:13:36 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Bob Hinden Subject: Re: Old transport-layer protocols to Historic? References: <4D2556C9.9020901@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org, IETF Discussion X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 05:11:16 -0000 07.01.2011 21:53, Bob Hinden wrote: > Mykyta, > > > On Jan 5, 2011, at 9:44 PM, Mykyta Yevstifeyev wrote: > >> Hello all, >> >> There have been a discussion on tsvwg mailing list about old transport layer protocols - exactly IRTP (RFC938), RDP (RFC908,1151) and NETBLT (RFC998). Initially there have been proposed to define IANA considerations for them. But after a discussion it was found out that it would be better to move them to Historic. I am writing to request more wider discussion on this topic. > I see little value even thinking about this. It's looks like a "make work" project to me. Just because something is "old", doesn't mean it is "historic" in the sense the label is used in the IETF. > > Regarding RDP (RFC908, RFC1151), of which I am one of the authors, both are currently labeled as Experimental. I do not see any reason to change that. > > Bob > > Dear all, RFC2026 mentions: > A specification that has been superseded by a more recent > specification or is for any other reason considered to be obsolete is > assigned to the "Historic" level. and gives 2 reasons for making the RFC Historic: 1) RFC is obsoleted (superseded) or 2) obsolete. Obsoleted = made obsolete. This is obvious. When one RFC replaces another, it obsoletes it, and second becomes obsolete. What is obsolete (adj.)? Obsolete = deprecated, outdated, out of use, non-current, etc. Moreover, RFC2026 does not set any other guidelines for setting the Historic status. That is why if the protocol is out of use, even specified by Experimental RFC, it is a reason to move its spec. to Historic, in accordance with RFC2026. All the best, Mykyta Yevstifeyev >> There is quite strong consensus that IRTP should be Historic. There is a registered draft on this topic: >> >> https://datatracker.ietf.org/doc/draft-yevstifeyev-tsvwg-irtp-to-historic/ >> >> But as for others it should be discussed. Moreover, maybe anyone knows some other old transport-layer protocols that are no longer in use? >> >> Please copy tour answer to tsvwg@ietf.org >> >> All the best, >> Mykyta Yevstifeyev >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From evnikita2@gmail.com Fri Jan 7 21:33:38 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 319EF3A6992; Fri, 7 Jan 2011 21:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.171 X-Spam-Level: X-Spam-Status: No, score=-3.171 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQCj+FAdBmZz; Fri, 7 Jan 2011 21:33:36 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id D0A383A697A; Fri, 7 Jan 2011 21:33:35 -0800 (PST) Received: by bwz12 with SMTP id 12so17780410bwz.31 for ; Fri, 07 Jan 2011 21:35:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=pDtC64Ekig9iTZc7ahH4rA3NTOcuFP9xdZmggC6Fm9s=; b=kHwWEOU1fx5gpfXaqFTOuHtjnAEIhH9cPSWhBhwlKiIIqwc3aOH028q8FYjYdct5Uf t0K7BjbCAeL7iFkSofV2VHwbuWtYXUsTvAmR1Uaq4J1XyTOSoGTDgq9M5ZvGCYgGMjSc +oyn6eCVAiSNe3YynnbQENSb4dIKYHS0eWK98= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=jH472DprZmCRtTI0318mvgrAljASZ2NZqM1sWKXSWezdTALym+NILo+vH636Va9s7q 6eVC3YM5WLTxTcDBQHKTZQBM8dJrU3he5tK3t0p2Py5Sscop/0sDQFucBkaN+RIaYTIR DF4bRgngJqt+hX4hRkTatfl9crRBe5KpzaDvw= Received: by 10.204.121.138 with SMTP id h10mr4700734bkr.40.1294464941985; Fri, 07 Jan 2011 21:35:41 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id j11sm14416180bka.0.2011.01.07.21.35.40 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 21:35:41 -0800 (PST) Message-ID: <4D27F7BE.3040800@gmail.com> Date: Sat, 08 Jan 2011 07:35:58 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dcrocker@bbiw.net Subject: Re: Old transport-layer protocols to Historic? References: <4D2556C9.9020901@gmail.com> <4D2628AB.3080003@isi.edu> <4D27F56A.8040605@dcrocker.net> In-Reply-To: <4D27F56A.8040605@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dave CROCKER , ietf@ietf.org, "tsvwg@ietf.org" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 05:33:38 -0000 08.01.2011 7:26, Dave CROCKER wrote: > > > On 1/6/2011 12:40 PM, Bob Braden wrote: >> Historic might imply that they were once in service, but have later been >> replaced/deprecated. > > > We assign labels to indicate the status of the specification, not the > status of a service that might use it. But the specification without service is nothing. We should look at the service using it, first of all. > > We say 'experimental' to mean that we thinks it's ok to play around > with the spec and maybe that we are hoping to get further information > about it. But it also means that we very much caution about use. > It's our "caveat emptor" label. > > We say 'historic' when we frankly think the spec should now not be > used, for whatever reason and no matter its prior status. > > These both are affirmative labels. I too do not think we should use > them for "housekeeping" and the mere fact that a specification is not > used does not mean that it shouldn't be used. > > To the extent that having a spec around -- especially one on standards > track -- might seem to conflict with another, preferred spec, then > it's worth considering making the one that is out of favor become > historic. The same holds for specifications that are now deemed > problematic. But it is the same what is with IRTP. RFC938 is obviously not acceptable to be used in the current Internet. In order it remains useful, it's needed to be rewritten or moved to Historic. And I really do not understand how did it become Experimental. The first notices of current classification system appeared in RFC1370, while this spec is RFC938. Mykyta Yevstifeyev > > But none of this is about propriety or neatness or a community OCD > neurosis. It needs to be about pragmatic guidance to the community. > > d/ > From evnikita2@gmail.com Sat Jan 8 08:17:10 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F97028C156; Sat, 8 Jan 2011 08:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.304 X-Spam-Level: X-Spam-Status: No, score=-3.304 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfVBVLaUK3kJ; Sat, 8 Jan 2011 08:17:09 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 706813A6975; Sat, 8 Jan 2011 08:17:05 -0800 (PST) Received: by bwz12 with SMTP id 12so17996019bwz.31 for ; Sat, 08 Jan 2011 08:19:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ogI3KzOanR4HQyhzcI6VdG7VVFhx59oeatkozyWRe8Q=; b=tUbmTqdJ7ut2odyCIh6NPgaPvL7Zlkzw2YUZ7AMUDJODmB9gdTXJMpzZvEZRhCa/JH w7VaCI8o4JjVj7CgDaXI672P8nqdxnnWfdGomcofdBU9vbStauI1ydvmmczQ6qnlNv4J kC5uPsZeuhgiAVVQ/4oQapaXS1rhdq6mf5ohM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ZS6OFCrZYJuiEE4fBpV+LqmatzJAUvBC9I4U9a1JxUoWB+u+XcGfk09+DgxzDnl1HB zfjLtu995EwR1FU5rXTov+eTL3u2gvb881SDmW5LAQnNco+i3PQHgJkj7hxsIAqmo29E 1TTVnIVkioO/MCEzeHKByUh3PJ8S59yhGW7+k= Received: by 10.204.59.72 with SMTP id k8mr489424bkh.84.1294503553112; Sat, 08 Jan 2011 08:19:13 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id d27sm14778534bkw.14.2011.01.08.08.19.11 (version=SSLv3 cipher=RC4-MD5); Sat, 08 Jan 2011 08:19:12 -0800 (PST) Message-ID: <4D288E91.9040700@gmail.com> Date: Sat, 08 Jan 2011 18:19:29 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Lixia Zhang Subject: Re: Old transport-layer protocols to Historic? References: <4D2556C9.9020901@gmail.com> <4D27F280.1020205@gmail.com> <4AE9FE30-47F2-4966-BDAF-B27B6437906F@cs.ucla.edu> In-Reply-To: <4AE9FE30-47F2-4966-BDAF-B27B6437906F@cs.ucla.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bob Hinden , tsvwg@ietf.org, IETF Discussion X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 16:17:10 -0000 08.01.2011 18:12, Lixia Zhang wrote: > On Jan 7, 2011, at 9:13 PM, Mykyta Yevstifeyev wrote: > >> 07.01.2011 21:53, Bob Hinden wrote: >>> Mykyta, >>> >>> >>> On Jan 5, 2011, at 9:44 PM, Mykyta Yevstifeyev wrote: >>> >>>> Hello all, >>>> >>>> There have been a discussion on tsvwg mailing list about old transport layer protocols - exactly IRTP (RFC938), RDP (RFC908,1151) and NETBLT (RFC998). Initially there have been proposed to define IANA considerations for them. But after a discussion it was found out that it would be better to move them to Historic. I am writing to request more wider discussion on this topic. >>> I see little value even thinking about this. It's looks like a "make work" project to me. Just because something is "old", doesn't mean it is "historic" in the sense the label is used in the IETF. >>> >>> Regarding RDP (RFC908, RFC1151), of which I am one of the authors, both are currently labeled as Experimental. I do not see any reason to change that. >>> >>> Bob >>> >>> >> Dear all, >> >> RFC2026 mentions: >> >>> A specification that has been superseded by a more recent >>> specification or is for any other reason considered to be obsolete is >>> assigned to the "Historic" level. >> and gives 2 reasons for making the RFC Historic: 1) RFC is obsoleted (superseded) or 2) obsolete. >> >> Obsoleted = made obsolete. This is obvious. When one RFC replaces another, it obsoletes it, and second becomes obsolete. >> >> What is obsolete (adj.)? Obsolete = deprecated, outdated, out of use, non-current, etc. >> >> Moreover, RFC2026 does not set any other guidelines for setting the Historic status. > that is because only standard track protocols need such guidelines Where is that, once more? >> That is why if the protocol is out of use, even specified by Experimental RFC, it is a reason to move its spec. to Historic, in accordance with RFC2026. > First, you said RFC2026 did *not* say anything on moving non-standard protocols to Historic status. > > Then you said Experimental RFCs need to move to Historic, in accordance with RFC2026. RFC2026 in Section 4.2.4. says nothing about this. It is indefinite, per this section. What you said 'first' was what do all think. And the second what I do. And maybe not need to move but may be moved. Mykyta Yevstifeyev > Doesn't this sound self-conflicting to you? > > Lixia > > From lixia@cs.ucla.edu Sat Jan 8 08:10:49 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A38828C120; Sat, 8 Jan 2011 08:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KC1vGZNqb6O0; Sat, 8 Jan 2011 08:10:48 -0800 (PST) Received: from smtp.cs.ucla.edu (smtp.cs.ucla.edu [131.179.128.62]) by core3.amsl.com (Postfix) with ESMTP id 5469128C11D; Sat, 8 Jan 2011 08:10:42 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 32CF939E80F0; Sat, 8 Jan 2011 08:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3F2mAThflSfq; Sat, 8 Jan 2011 08:12:49 -0800 (PST) Received: from [10.0.1.2] (cpe-76-174-94-219.socal.res.rr.com [76.174.94.219]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 4870F39E8083; Sat, 8 Jan 2011 08:12:49 -0800 (PST) Subject: Re: Old transport-layer protocols to Historic? Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Lixia Zhang In-Reply-To: <4D27F280.1020205@gmail.com> Date: Sat, 8 Jan 2011 08:12:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4AE9FE30-47F2-4966-BDAF-B27B6437906F@cs.ucla.edu> References: <4D2556C9.9020901@gmail.com> <4D27F280.1020205@gmail.com> To: Mykyta Yevstifeyev X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Sat, 08 Jan 2011 09:09:13 -0800 Cc: Bob Hinden , tsvwg@ietf.org, IETF Discussion X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 16:10:50 -0000 On Jan 7, 2011, at 9:13 PM, Mykyta Yevstifeyev wrote: > 07.01.2011 21:53, Bob Hinden wrote: >> Mykyta, >>=20 >>=20 >> On Jan 5, 2011, at 9:44 PM, Mykyta Yevstifeyev wrote: >>=20 >>> Hello all, >>>=20 >>> There have been a discussion on tsvwg mailing list about old = transport layer protocols - exactly IRTP (RFC938), RDP (RFC908,1151) and = NETBLT (RFC998). Initially there have been proposed to define IANA = considerations for them. But after a discussion it was found out that it = would be better to move them to Historic. I am writing to request more = wider discussion on this topic. >> I see little value even thinking about this. It's looks like a "make = work" project to me. Just because something is "old", doesn't mean it = is "historic" in the sense the label is used in the IETF. >>=20 >> Regarding RDP (RFC908, RFC1151), of which I am one of the authors, = both are currently labeled as Experimental. I do not see any reason to = change that. >>=20 >> Bob >>=20 >>=20 > Dear all, >=20 > RFC2026 mentions: >=20 >> A specification that has been superseded by a more recent >> specification or is for any other reason considered to be obsolete = is >> assigned to the "Historic" level. > and gives 2 reasons for making the RFC Historic: 1) RFC is obsoleted = (superseded) or 2) obsolete. >=20 > Obsoleted =3D made obsolete. This is obvious. When one RFC replaces = another, it obsoletes it, and second becomes obsolete. >=20 > What is obsolete (adj.)? Obsolete =3D deprecated, outdated, out of = use, non-current, etc. >=20 > Moreover, RFC2026 does not set any other guidelines for setting the = Historic status. that is because only standard track protocols need such guidelines > That is why if the protocol is out of use, even specified by = Experimental RFC, it is a reason to move its spec. to Historic, in = accordance with RFC2026. First, you said RFC2026 did *not* say anything on moving non-standard = protocols to Historic status. Then you said Experimental RFCs need to move to Historic, in accordance = with RFC2026. Doesn't this sound self-conflicting to you? Lixia From bob.hinden@gmail.com Fri Jan 7 11:51:07 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CB6C3A6953; Fri, 7 Jan 2011 11:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.282 X-Spam-Level: X-Spam-Status: No, score=-103.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Uj1kxq-BK4T; Fri, 7 Jan 2011 11:51:06 -0800 (PST) Received: from mail-pw0-f66.google.com (mail-pw0-f66.google.com [209.85.160.66]) by core3.amsl.com (Postfix) with ESMTP id 146B63A6940; Fri, 7 Jan 2011 11:51:06 -0800 (PST) Received: by pwj5 with SMTP id 5so1754009pwj.1 for ; Fri, 07 Jan 2011 11:53:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=5S1GhfYEzDXMe6dXR1JYHCOV0sWUmtDkYkxUTQhlExU=; b=cypgrnEfhwkD9O4geC2FNFYuLxAmjWI+fx7J3nilODl/WcSCmSSkSP6mrC3W+BXk/u VZB4PmpiLK54QOrJf492zZGTSILArobH6jub9EHdQE/PD/SDZ7/7krmoeCgkOtAYcnmN iEYoFdVKGm2Y1lWKvOD2JTGSmBSRQva9uE3Sc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=c+anb/Xp9LenzxlzPq4MIe2E3n2tPaW9M97whfanzO9cGeKubM/7qrMZaF/ItZrH7T kmzulyKfeBmfP42U2mo3Qfv5FCbSmPnnsSWJ6Bbxr0k8Uy43RsoHyAGVyFEw1l5QVlk2 IhvJDKg3Fbf4fpBeQZ13FViSDwvEMlC+OHFYY= Received: by 10.142.188.17 with SMTP id l17mr2036706wff.35.1294429992397; Fri, 07 Jan 2011 11:53:12 -0800 (PST) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id y42sm3072119wfd.10.2011.01.07.11.53.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 11:53:10 -0800 (PST) Subject: Re: Old transport-layer protocols to Historic? Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <4D2556C9.9020901@gmail.com> Date: Fri, 7 Jan 2011 11:53:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D2556C9.9020901@gmail.com> To: tsvwg@ietf.org, IETF Discussion X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Sat, 08 Jan 2011 09:09:24 -0800 Cc: Bob Hinden X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 19:51:07 -0000 Mykyta, On Jan 5, 2011, at 9:44 PM, Mykyta Yevstifeyev wrote: > Hello all, >=20 > There have been a discussion on tsvwg mailing list about old transport = layer protocols - exactly IRTP (RFC938), RDP (RFC908,1151) and NETBLT = (RFC998). Initially there have been proposed to define IANA = considerations for them. But after a discussion it was found out that it = would be better to move them to Historic. I am writing to request more = wider discussion on this topic.=20 I see little value even thinking about this. It's looks like a "make = work" project to me. Just because something is "old", doesn't mean it = is "historic" in the sense the label is used in the IETF. Regarding RDP (RFC908, RFC1151), of which I am one of the authors, both = are currently labeled as Experimental. I do not see any reason to = change that.=20 Bob > There is quite strong consensus that IRTP should be Historic. There is = a registered draft on this topic: >=20 > = https://datatracker.ietf.org/doc/draft-yevstifeyev-tsvwg-irtp-to-historic/= >=20 > But as for others it should be discussed. Moreover, maybe anyone knows = some other old transport-layer protocols that are no longer in use? >=20 > Please copy tour answer to tsvwg@ietf.org=20 >=20 > All the best, > Mykyta Yevstifeyev > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From braden@isi.edu Sat Jan 8 10:18:49 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E5AA3A67FC for ; Sat, 8 Jan 2011 10:18:49 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gYrKteJVdsj for ; Sat, 8 Jan 2011 10:18:48 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 8C34D3A677C for ; Sat, 8 Jan 2011 10:18:45 -0800 (PST) Received: from [127.0.0.1] (c1-vpn4.isi.edu [128.9.176.34]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p08IKBLm012105; Sat, 8 Jan 2011 10:20:35 -0800 (PST) Message-ID: <4D28A72E.6050402@isi.edu> Date: Sat, 08 Jan 2011 10:04:30 -0800 From: Bob Braden User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: Old transport-layer protocols to Historic? References: <4D2556C9.9020901@gmail.com> <4D2628AB.3080003@isi.edu> <4D27F56A.8040605@dcrocker.net> <4D27F7BE.3040800@gmail.com> In-Reply-To: <4D27F7BE.3040800@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 18:18:49 -0000 On 1/7/2011 9:35 PM, Mykyta Yevstifeyev wrote: > But it is the same what is with IRTP. RFC938 is obviously not > acceptable to be used in the current Internet. In order it remains > useful, it's needed to be rewritten or moved to Historic. And I really > do not understand how did it become Experimental. The first notices of > current classification system appeared in RFC1370, while this spec is > RFC938. > > Mykyta Yevstifeyev You don't know how it became Experimental? Because it *was* an experiment. The entire TCP/IP protocol suite was once upon a time an experiment. (You might note that those people who have written in opposition to your proposed reclassification -- Dave Crocker, Bob Hinden, Lixia Zhang, ...) were participants in that experiment). There was a significant population of people funded to do Internet research in the IETF until the early 1990s. (And the line between research and standards was sometimes a bit fuzzy as Internet technology evolved.) You are trying to imkpose a nice neat order on the rather chaotic history of early Internet protocol development. That is not appropriate, so please stop writing messages aboujt it. I for one believe that we should respect the untidy history of the early Internet and the RFC series proudly as part of the heritage of the IETF and the larger Internet technical community. Bob Braden From evnikita2@gmail.com Sat Jan 8 22:25:37 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04D3D3A6931; Sat, 8 Jan 2011 22:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[AWL=-0.714, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbZtrRl7Q4Dk; Sat, 8 Jan 2011 22:25:31 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 536AD3A6930; Sat, 8 Jan 2011 22:25:30 -0800 (PST) Received: by bwz12 with SMTP id 12so18269244bwz.31 for ; Sat, 08 Jan 2011 22:27:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type; bh=nPaYKDFudcUAte1fKjw9HUqBtT3+L0gNnd4LmvkEAWQ=; b=vIGV+ygifG67hlg4mXJSeLL5le5IBcYAzhumDjnnYj01OCwbVpWmvgW2skyCK2wOfN uCBuM98G7xhyRBKh4hxZ4EuNbDy93afm4c2vUhcbK2boZt5+AVRz7dGdDrP+tyoArowl Ga/mme0FW2dLzapfDLk1pNofai86qe7QsIpSA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; b=bf+VmxiJVGwObfrv9SZrMnoUy6z5EwBh99lQzRFTL9qTQaxKnbAzpjS2WjvI/TBtwN +u5XJSVBFl/i4Ibls9gbzV9qBGDBBs1LBV1Hzcx86+7LTb+/x35uMDF+gxKgdZuaTKP5 8YgYbwwWARf9mlUCNf2YlBZs/swPQGHq5Lacg= Received: by 10.204.114.81 with SMTP id d17mr13813030bkq.135.1294554458007; Sat, 08 Jan 2011 22:27:38 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id v25sm15051990bkt.18.2011.01.08.22.27.36 (version=SSLv3 cipher=RC4-MD5); Sat, 08 Jan 2011 22:27:37 -0800 (PST) Message-ID: <4D29556A.6060902@gmail.com> Date: Sun, 09 Jan 2011 08:27:54 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Bob Hinden Subject: Re: Old transport-layer protocols to Historic? References: <4D2556C9.9020901@gmail.com> <4D2842B8.7090100@gmail.com> In-Reply-To: <4D2842B8.7090100@gmail.com> Content-Type: multipart/alternative; boundary="------------080703050203060404030302" Cc: tsvwg@ietf.org, IETF Discussion X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 06:25:37 -0000 This is a multi-part message in MIME format. --------------080703050203060404030302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 08.01.2011 12:55, Mykyta Yevstifeyev ?????: > 07.01.2011 21:53, Bob Hinden wrote: >> Mykyta, >> >> >> On Jan 5, 2011, at 9:44 PM, Mykyta Yevstifeyev wrote: >> >>> Hello all, >>> >>> There have been a discussion on tsvwg mailing list about old transport layer protocols - exactly IRTP (RFC938), RDP (RFC908,1151) and NETBLT (RFC998). Initially there have been proposed to define IANA considerations for them. But after a discussion it was found out that it would be better to move them to Historic. I am writing to request more wider discussion on this topic. >> I see little value even thinking about this. It's looks like a "make work" project to me. Just because something is "old", doesn't mean it is "historic" in the sense the label is used in the IETF. >> >> Regarding RDP (RFC908, RFC1151), of which I am one of the authors, both are currently labeled as Experimental. I do not see any reason to change that. > Bob, all, Personally I don't support the idea to move the RDP to Historic. The initial idea was to defined IANA procedures for assignment RDP ports, that remains undefined. But when I presented the corresponding draft to tsvwg, many claimed that it would be better to move it ti Historic rather than specify IANA procedures for it. Currently, there is a draft on this topic: http://tools.ietf.org/html/draft-yevstifeyev-rdp-ports-registry-02 My initial idea was just that. And you, Bob, do you find this topic interesting (RDP ports assignment) as the developer of RDP? Mykyta Yevstifeyev >> Bob >> >> >>> There is quite strong consensus that IRTP should be Historic. There is a registered draft on this topic: >>> >>> https://datatracker.ietf.org/doc/draft-yevstifeyev-tsvwg-irtp-to-historic/ >>> >>> But as for others it should be discussed. Moreover, maybe anyone knows some other old transport-layer protocols that are no longer in use? >>> >>> Please copy tour answer totsvwg@ietf.org >>> >>> All the best, >>> Mykyta Yevstifeyev >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >> > --------------080703050203060404030302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 08.01.2011 12:55, Mykyta Yevstifeyev пишет:
07.01.2011 21:53, Bob Hinden wrote:
Mykyta,


On Jan 5, 2011, at 9:44 PM, Mykyta Yevstifeyev wrote:

Hello all,

There have been a discussion on tsvwg mailing list about old transport layer protocols - exactly IRTP (RFC938), RDP (RFC908,1151) and NETBLT (RFC998). Initially there have been proposed to define IANA considerations for them. But after a discussion it was found out that it would be better to move them to Historic. I am writing to request more wider discussion on this topic. 
I see little value even thinking about this.  It's looks like a "make work" project to me.  Just because something is "old", doesn't mean it is "historic" in the sense the label is used in the IETF.

Regarding RDP (RFC908, RFC1151), of which I am one of the authors, both are currently labeled as Experimental.  I do not see any reason to change that. 

Bob, all,

Personally I don't support the idea to move the RDP to Historic. The initial idea was to defined IANA procedures for assignment RDP ports, that remains undefined. But when I presented the corresponding draft to tsvwg, many claimed that it would be better to move it ti Historic rather than specify IANA procedures for it. Currently, there is a draft on this topic:

http://tools.ietf.org/html/draft-yevstifeyev-rdp-ports-registry-02

My initial idea was just that.  And you, Bob, do you find this topic interesting (RDP ports assignment) as the developer of RDP?

Mykyta Yevstifeyev


Bob


There is quite strong consensus that IRTP should be Historic. There is a registered draft on this topic:

https://datatracker.ietf.org/doc/draft-yevstifeyev-tsvwg-irtp-to-historic/

But as for others it should be discussed. Moreover, maybe anyone knows some other old transport-layer protocols that are no longer in use?

Please copy tour answer to tsvwg@ietf.org 

All the best,
Mykyta Yevstifeyev
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf



--------------080703050203060404030302-- From bidulock@openss7.org Sun Jan 9 00:04:05 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A722C3A6955; Sun, 9 Jan 2011 00:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GldLkzpxynx0; Sun, 9 Jan 2011 00:04:04 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id A1AA03A694F; Sun, 9 Jan 2011 00:04:04 -0800 (PST) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0986A4g024931; Sun, 9 Jan 2011 01:06:10 -0700 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0986AfW013001; Sun, 9 Jan 2011 01:06:10 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p0986AOS013000; Sun, 9 Jan 2011 01:06:10 -0700 Date: Sun, 9 Jan 2011 01:06:10 -0700 From: "Brian F. G. Bidulock" To: Mykyta Yevstifeyev Subject: Re: Old transport-layer protocols to Historic? Message-ID: <20110109080610.GA12782@openss7.org> Mail-Followup-To: Mykyta Yevstifeyev , Bob Hinden , tsvwg@ietf.org, IETF Discussion References: <4D2556C9.9020901@gmail.com> <4D2842B8.7090100@gmail.com> <4D29556A.6060902@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D29556A.6060902@gmail.com> Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Bob Hinden , tsvwg@ietf.org, IETF Discussion X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 08:04:05 -0000 Mykyta, RDP is still in use (I know of companies using it). It is used heavily as a transport for a "popular brand" of NAS for dial access call control and was a precursor to MEGACO/H.248. RDP was the initial transport used for gateway control (such as SGCP) until SCTP was developed. Many commercial gateways still support these older pre-standard (to MEGACO) control protocols. Some older devices still provisioned in the network only support the older protocols. Yah, I know it was EXPERIMENTAL, but we had nothing before SCTP that would fit the bill. Its limitations was one of the driving forces behind developing SCTP. One of the original protocol attempts abandonned before SCTP was based on RDP. Please leave RDP alone. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From magnus.westerlund@ericsson.com Mon Jan 10 07:55:41 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E25733A6973 for ; Mon, 10 Jan 2011 07:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BisL15iy15bP for ; Mon, 10 Jan 2011 07:55:40 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 418F43A67ED for ; Mon, 10 Jan 2011 07:55:40 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-c9-4d2b2c8161e1 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 4F.E3.13987.18C2B2D4; Mon, 10 Jan 2011 16:57:53 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Mon, 10 Jan 2011 16:57:52 +0100 Message-ID: <4D2B2C80.1040906@ericsson.com> Date: Mon, 10 Jan 2011 16:57:52 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mykyta Yevstifeyev Subject: Re: draft-yevstifeyev-netblt-iana-00.txt and other issues References: <4D2048A5.8090106@gmail.com> <5E0012FB-9095-44DD-B1B1-52A6045979AB@jccw.org> <4D22B63C.6070807@gmail.com> In-Reply-To: <4D22B63C.6070807@gmail.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: John White , John C Klensin , "tsvwg@ietf.org" , "draft-ietf-tsvwg-iana-ports@tools.ietf.org" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 15:55:42 -0000 Mykyta Yevstifeyev skrev 2011-01-04 06:55: > Hello all, > > Let me inform you about the issues connected with my drafts. > > Firstly, I have contacted the authors of draft-ietf-tsvwg-iana-ports to > ask them to include the registration procedures for RDP, NetBLT and IRTP > ports. Unfortunately, I have received the response mentioning that these > protocols are not in use and are rather candidates for historic protocol > . I may agree partly with this, only for IRTP. For the others, I insist > on including corresponding entries in the document. You also received from Joe Touch comments (in private) that it doesn't look appropriate to include any of these protocols in draft-ietf-tsvwg-iana-ports because they don't meet the criteria for being suitable. You also got the message that you shouldn't create registries unless they where clearly needed. You never responded to why these protocols needs registries. It appears to be an action in completeness that seems inappropriate. If you have a situation where not creating the registries would create an interoperability mess than explain that situation. > And as for my drafts. I would ask to withdraw my draft related to IRTP, > but make another one suggesting moving it to Historic. As for RDP, I > suppose draft-ietf-tsvwg-iana-ports authors will kindly allow this (and > NETBLT) protocol ports to be registered using the unique procedure and > as soon as this issues will be covered by this draft, I will ask my > draft to be marked as replaced by iana-ports one. And as for NETBLT > draft, it will be replaced by new version of White's draft, for which, I > think, he would allow me to be the co-author. > As I agree with Joe, having the service name and ports registry define the RDP registry does not seem to be appropriate. If there is need for a registry for this, then do it in an individual draft. But please show why it is appropriate. > And lastly, now I ask the authors of draft-ietf-tsvwg-iana-ports to > address to draft-yevstifeyev-eudp in the way they do it for UDP-Lite to > allow this protocol ports to be assigned in the same way with UDP-Lite. > This draft is already in RFC Ed. Queue (currently in the ISR state), but > if the authors mind this, I will ask it to be the AD-Sponsored one. First, I would like to point out that IP protocol numbers are under the registration rules of Standards Action or IESG approval. http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml Thus, just the RFC-editor publication are not going to get the protocol a IP protocol number. Going that road requires you to get IESG to approve the allocation. And I see giving EUDP a protocol number would be the wrong thing to do. As EUDP is UDP with an twist of having some option fields there is little gain with this approach and a lot of loss of functionality. You loose all the NAT and Firewall traversal capability UDP's IP protocol number gives you. At the same time you also do not address any of the issues that you create by adding the options. For example security or congestion control. If you want to use this it would be many times smarter to sell it as a standardize shim on top of UDP. Use regular UDP, after that you add a Service Code field followed by the data offset field. The serivice code (or secondary destiantion port) indicate the intended service at the receiver. Then you register one UDP port. That way you can provide the functionality without consuming any really valuable resources. So my opinion is that EUDP should not be published in its current form, either on the standards track or by the RFC-editor as an independent submission. I think it is great that you want to contribute, but I think you should listen to the feedback that is provided and find something that is more useful for the community, or a way to resolve the comments that you do receive. Cheers 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 braden@isi.edu Mon Jan 10 09:47:42 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCB2E3A6B07 for ; Mon, 10 Jan 2011 09:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.69 X-Spam-Level: X-Spam-Status: No, score=-102.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgcnsrjib7nw for ; Mon, 10 Jan 2011 09:47:42 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id DDCB83A67AB for ; Mon, 10 Jan 2011 09:47:41 -0800 (PST) Received: from [128.9.168.81] (rtb.isi.edu [128.9.168.81]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p0AHnM2f027014; Mon, 10 Jan 2011 09:49:22 -0800 (PST) Message-ID: <4D2B4825.5090807@isi.edu> Date: Mon, 10 Jan 2011 09:55:49 -0800 From: Bob Braden User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: Old transport-layer protocols to Historic? References: <4D2556C9.9020901@gmail.com> <4D2842B8.7090100@gmail.com> <4D29556A.6060902@gmail.com> In-Reply-To: <4D29556A.6060902@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 17:47:42 -0000 The Subject line of this discussion should read: "Experimental transport-layer protocols to Historic?" That might reduce some of the confusion. The questions under discussion seem to be: 1. What are the IANA rules for number assignments to new Experimental protocols? (Preumably the same rules would hold for old Experimental protocols). 2. Under what circumstances might (or should) the category of a Technical Spec be changed from Experimental to Historic? The traditional IETF view, which was handed down from the Internet Protocol Czar, has been "almost never", and only when wide use of the experimental protocol might pose real and present danger to the Internet. One could take that view about NETBLT, but personally I think that would be an over-reaction. Bob Braden From evnikita2@gmail.com Tue Jan 11 01:19:23 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1B0C3A69F8 for ; Tue, 11 Jan 2011 01:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.123 X-Spam-Level: X-Spam-Status: No, score=-4.123 tagged_above=-999 required=5 tests=[AWL=-0.524, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgAlmNjFQuj3 for ; Tue, 11 Jan 2011 01:19:22 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id BDF2A3A63EB for ; Tue, 11 Jan 2011 01:19:22 -0800 (PST) Received: by yie19 with SMTP id 19so6577935yie.31 for ; Tue, 11 Jan 2011 01:21:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=J89ePrRr4zZmA3cpYV3l8iIko0Kl1bRU4nYgFyPNKds=; b=wotHg21GSUGCvnvoBrFaqiLrkBehCMQ5J/RO/e0NdsvTJA/MIvUfct1qx4v4bMC/LP PTNhL0y6Fy/FX8j48ErHYCwd+u0VliqKOobaukRPc0XXhi6CQ6/aFNP+ClkU4F05jlF3 1J2fOTLZiHYmvC1ofYH2N99aJqH4eqISFppQM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ktsezkmRj/TLMKvDSE9dQWYLgMBa3COy/YQvIWjqF3mOyXjbJgXjp/IE6ICHe2+smd 34OA9NbgsxudQlNtJWUpC8jBGNdDqjXoWu18NMItq4S6jqnyeyc+OEUma1Ww6oEE1NTW KeBr+wgufTZLgNqwbw6j8b5Y+UKCywqampcys= MIME-Version: 1.0 Received: by 10.151.84.11 with SMTP id m11mr7296608ybl.212.1294737698688; Tue, 11 Jan 2011 01:21:38 -0800 (PST) Received: by 10.150.53.6 with HTTP; Tue, 11 Jan 2011 01:21:38 -0800 (PST) In-Reply-To: <4D2B4825.5090807@isi.edu> References: <4D2556C9.9020901@gmail.com> <4D2842B8.7090100@gmail.com> <4D29556A.6060902@gmail.com> <4D2B4825.5090807@isi.edu> Date: Tue, 11 Jan 2011 11:21:38 +0200 Message-ID: Subject: Re: Old transport-layer protocols to Historic? From: Mykyta Yevstifeyev To: Bob Braden Content-Type: text/plain; charset=ISO-8859-1 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 09:19:23 -0000 Bob, 2011/1/10, Bob Braden : > The Subject line of this discussion should read: "Experimental > transport-layer protocols to Historic?" That might reduce some of the > confusion. > > The questions under discussion seem to be: > 1. What are the IANA rules for number assignments to new > Experimental protocols? (Preumably the same rules would > hold for old Experimental protocols). Do you think there are some special rules for creation of new regsitries for experimental protocols? Could you please refer to any of documents on this topic? > > 2. Under what circumstances might (or should) the category of a > Technical Spec be changed from Experimental to Historic? The same as below. > > The traditional IETF view, which was handed down from the > Internet Protocol Czar, has been "almost never", and only > when wide use of the experimental protocol might > pose real and present danger to the Internet. One could > take that view about NETBLT, but personally I think that > would be an over-reaction. I personally think there is no useful way in moving NETBLT spec to historic, as well as RDP. I consider that useful only for IRTP. Do you think there is still a need in such protocol? what has it been made for? Mykyta. > > Bob Braden > > From ietfc@btconnect.com Tue Jan 11 04:34:02 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE32228C0EE for ; Tue, 11 Jan 2011 04:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7m62ptk5Gmpe for ; Tue, 11 Jan 2011 04:34:01 -0800 (PST) Received: from mail.btconnect.com (c2bthomr09.btconnect.com [213.123.20.127]) by core3.amsl.com (Postfix) with ESMTP id 3F00328C281 for ; Tue, 11 Jan 2011 04:34:00 -0800 (PST) Received: from host217-44-202-158.range217-44.btcentralplus.com (HELO pc6) ([217.44.202.158]) by c2bthomr09.btconnect.com with SMTP id BIL84803; Tue, 11 Jan 2011 12:36:02 +0000 (GMT) Message-ID: <034301cbb183$4307ae00$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Mykyta Yevstifeyev" , "Bob Braden" References: <4D2556C9.9020901@gmail.com><4D2842B8.7090100@gmail.com> <4D29556A.6060902@gmail.com><4D2B4825.5090807@isi.edu> Subject: Re: Old transport-layer protocols to Historic? Date: Tue, 11 Jan 2011 12:32:37 +0100 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-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0301.4D2C4EB0.00F8, actions=tag X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020C.4D2C4EB2.0300,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 12:34:02 -0000 ----- Original Message ----- From: "Mykyta Yevstifeyev" To: "Bob Braden" Cc: Sent: Tuesday, January 11, 2011 10:21 AM > Bob, > > 2011/1/10, Bob Braden : > > The Subject line of this discussion should read: "Experimental > > transport-layer protocols to Historic?" That might reduce some of the > > confusion. > > > > The questions under discussion seem to be: > > 1. What are the IANA rules for number assignments to new > > Experimental protocols? (Preumably the same rules would > > hold for old Experimental protocols). > Do you think there are some special rules for creation of new > regsitries for experimental protocols? Could you please refer to any > of documents on this topic? > > > > 2. Under what circumstances might (or should) the category of a > > Technical Spec be changed from Experimental to Historic? > The same as below. > > > > The traditional IETF view, which was handed down from the > > Internet Protocol Czar, has been "almost never", and only > > when wide use of the experimental protocol might > > pose real and present danger to the Internet. One could > > take that view about NETBLT, but personally I think that > > would be an over-reaction. > > > I personally think there is no useful way in moving NETBLT spec to > historic, as well as RDP. I consider that useful only for IRTP. Do you > think there is still a need in such protocol? what has it been made > for? So why have you posted to the ietf list that "There have been a discussion on tsvwg mailing list about old transport layer protocols - exactly IRTP (RFC938), RDP (RFC908,1151) and NETBLT (RFC998). Initially there have been proposed to define IANA considerations for them. But after a discussion it was found out that it would be better to move them to Historic. I am writing to request more wider discussion on this topic." Tom Petch > > Mykyta. > > > > Bob Brade From evnikita2@gmail.com Tue Jan 11 07:09:56 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD6F428C193; Tue, 11 Jan 2011 07:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.646 X-Spam-Level: X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[AWL=-1.406, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOg-sQ6BbQGC; Tue, 11 Jan 2011 07:09:55 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 4EA4828C152; Tue, 11 Jan 2011 07:09:55 -0800 (PST) Received: by ewy8 with SMTP id 8so9513177ewy.31 for ; Tue, 11 Jan 2011 07:12:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=SZOjYUA7s+Wverc+L5IyiOm5QG7fhwe4kVUv1U2qPfk=; b=SqiGNXx6WUFyz2r2Ku37h2uhqoyLhTKYkEzCqzIqvfL+8GxeH/MEwGNP/76gBFt+QF ++Z/rJZVFvtGNw1uadn25fv8TZ+5/SKWV6JJ1S5eYitqJvCXo796HncVnxtDZlOl5/we Pik/5di8zn/oBOPZLvXUjvotRzeVjsEPWkUSY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=XA5e6SfuS/Q3Q+ceJQuItedLxeCEnfLBQlXMdcTvO4stsPUxwn4HYiZRq3mvJEcOCy 8BF6FqDmL+tP7Fsb8GY5MPSD6I/o/eElszxjxz54hivR95yyPsQcD8uUa6yInw2S0OBm 135gzjJlU/6/Ml+7Af6hPT1CEpgvbPiKkmvfk= Received: by 10.204.120.3 with SMTP id b3mr4043894bkr.41.1294758731583; Tue, 11 Jan 2011 07:12:11 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id x38sm15155074bkj.1.2011.01.11.07.12.09 (version=SSLv3 cipher=RC4-MD5); Tue, 11 Jan 2011 07:12:10 -0800 (PST) Message-ID: <4D2C735C.7070302@gmail.com> Date: Tue, 11 Jan 2011 17:12:28 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "t.petch" Subject: Re: Draft Review Request - IRTP IANA Considerations References: <4D1715BE.6040100@gmail.com><4D199D89.4080508@gmail.com><00eb01cba6a5$b5606840$4001a8c0@gateway.2wire.net><4D1D6EB3.40803@gmail.com><4D2223E4.2040104@isi.edu><4D240101.6090308@gmail.com><5131531F-D1E6-44F1-8FC0-94CBCF6CC2A8@isi.edu><024801cbaccd$e347d580$4001a8c0@gateway.2wire.net><4D2554F8.7060201@gmail.com><4D257766.7060808@isi.edu><4D25A0BC.9050505@gmail.com><84DCE00C-E6FE-4148-9ADB-A573672DC5F0@isi.edu><4D26ADE8.5080001@gmail.com><4D26B462.3040001@isi.edu><4D27F316.2000607@gmail.com><4D2B4994.9080009@isi.edu> <034201cbb183$42ac2080$4001a8c0@gateway.2wire.net> In-Reply-To: <034201cbb183$42ac2080$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gorry@erg.abdn.ac.uk, "tsvwg@ietf.org" , IETF Discussion , Joe Touch X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 15:09:56 -0000 11.01.2011 13:28, t.petch wrote: > ----- Original Message ----- > From: "Mykyta Yevstifeyev" > To: "Joe Touch" > Cc: "t.petch"; > Sent: Tuesday, January 11, 2011 10:24 AM > >> Joe, >> >> 2011/1/10, Joe Touch: >>> >>> On 1/7/2011 9:16 PM, Mykyta Yevstifeyev wrote: >>> ... >>>>> "You need to explain why these protocols *need* to be moved to >>>>> Historic". Such actions are typically reserved for protocols in >>>>> current use that are dangerous, or protocols that are in current use >>>>> that are being replaced by other protocols. Neither is the case here. >>>>> There is no need to "move to Historic" (i.e., "deprecate", within the >>>>> IETF process) such protocols. >>> > >>>> See my message in IETF Discussion list. >>> For those not on that list: >>> >>> - there are many others who share my view that moving experimental >>> protocols to historic isn't useful per se, especially these protocols in >>> particular >> What 'these'? See that below. >>> - your argument appears to be "the definition of Historic is incorrect" >>> >> Maybe a bit. It is more narrow and unclear than incorrect. >>> Given your argument, it's difficult to appreciate why you claim it is >>> urgent to move these protocols to a status whose definition you >>> explicitly disagree with. >> What protocols? Curently I'm speaking only about one - IRTP. Joe, > Yes, and that is one of the three (IRTP, NETBLT, RDP) that you > raised on the ietf list under 'Old transport-layer protocols to Historic?' It was to request the discussion on topics related with all these protocols. > And as Joe has accurately pointed out, the ietf list has generated a lot > of responses, from names I know well and have a high regard for, > almost all of which say that this is a bad idea. It is true that for > NETBLT and for RDP concrete reasons have been given why this > is a very bad idea; doubtless we coud find similar reasons for IRTP. As well as I know, almost all responses concerned only RDP and NETBLT, and nearly nobody said anything about IRTP. So I want to ask that now - what was IRTP developed for? Is there any real reason it may be used? Mykyta > So you have proposed moving protocols to Historic and practically > no-one agrees with what you say. > > Tom Petch > >> Mykyta >>> Joe >>> From evnikita2@gmail.com Tue Jan 11 07:11:39 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C78F28C179 for ; Tue, 11 Jan 2011 07:11:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.033 X-Spam-Level: X-Spam-Status: No, score=-2.033 tagged_above=-999 required=5 tests=[AWL=-0.994, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILZ72b89++HV for ; Tue, 11 Jan 2011 07:11:33 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 0882A28C193 for ; Tue, 11 Jan 2011 07:11:31 -0800 (PST) Received: by bwz12 with SMTP id 12so20159988bwz.31 for ; Tue, 11 Jan 2011 07:13:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=j8yc4YcOIc8OLrtXyGakTm7w/xRX+7/KyHlBDfHSF8E=; b=Sc9r84DDSY03Wg0MX0/F1ZtK1Tiax12hfyal3o31ql8JfrcNaEsYJA0dtyqX+x98xL 91BYDXtt2pw5KTXLaIEI0V2nSLvf5PETBWDURsJ6kvgWUcnIro0pq9OKIez70nArK2dE z0h4/qcAPIlxpI3zlI3cLGs83Q4zChp15c2W4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Wdp9ltHvFzIDciuUubmDQC0uA4GntzkLEL38JjWGl7fR1oiccctJy41qsAIYSrJEPZ KYWjd3rjS1hJZ8wPOjw1hVWogtDLaKUtkQH2WugNMNvo9ak/DT57o1KPtQSLu3m3Dahp BqvdTAgfiOQmCGgMPP/heiQoN7PHBdRTbq2M8= Received: by 10.204.62.132 with SMTP id x4mr2604875bkh.30.1294758827380; Tue, 11 Jan 2011 07:13:47 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id b17sm16525439bku.20.2011.01.11.07.13.45 (version=SSLv3 cipher=RC4-MD5); Tue, 11 Jan 2011 07:13:46 -0800 (PST) Message-ID: <4D2C73BC.70208@gmail.com> Date: Tue, 11 Jan 2011 17:14:04 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "t.petch" Subject: Re: Old transport-layer protocols to Historic? References: <4D2556C9.9020901@gmail.com><4D2842B8.7090100@gmail.com> <4D29556A.6060902@gmail.com><4D2B4825.5090807@isi.edu> <034301cbb183$4307ae00$4001a8c0@gateway.2wire.net> In-Reply-To: <034301cbb183$4307ae00$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bob Braden , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 15:11:41 -0000 Hello, Please find some comments below. 11.01.2011 13:32, t.petch wrote: > ----- Original Message ----- > From: "Mykyta Yevstifeyev" > To: "Bob Braden" > Cc: > Sent: Tuesday, January 11, 2011 10:21 AM >> Bob, >> >> 2011/1/10, Bob Braden: >>> The Subject line of this discussion should read: "Experimental >>> transport-layer protocols to Historic?" That might reduce some of the >>> confusion. >>> >>> The questions under discussion seem to be: >>> 1. What are the IANA rules for number assignments to new >>> Experimental protocols? (Preumably the same rules would >>> hold for old Experimental protocols). >> Do you think there are some special rules for creation of new >> regsitries for experimental protocols? Could you please refer to any >> of documents on this topic? >>> 2. Under what circumstances might (or should) the category of a >>> Technical Spec be changed from Experimental to Historic? >> The same as below. >>> The traditional IETF view, which was handed down from the >>> Internet Protocol Czar, has been "almost never", and only >>> when wide use of the experimental protocol might >>> pose real and present danger to the Internet. One could >>> take that view about NETBLT, but personally I think that >>> would be an over-reaction. >> >> I personally think there is no useful way in moving NETBLT spec to >> historic, as well as RDP. I consider that useful only for IRTP. Do you >> think there is still a need in such protocol? what has it been made >> for? > So why have you posted to the ietf list that > > "There have been a discussion on tsvwg mailing list about old transport > layer protocols - exactly IRTP (RFC938), RDP (RFC908,1151) and NETBLT > (RFC998). Initially there have been proposed to define IANA > considerations for them. But after a discussion it was found out that it > would be better to move them to Historic. I am writing to request more > wider discussion on this topic." See my last sentence in the citation. I have written that to request more discussion on this topic. Mykyta > Tom Petch > >> Mykyta. >>> Bob Brade From evnikita2@gmail.com Tue Jan 11 08:15:50 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B515C3A698E for ; Tue, 11 Jan 2011 08:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=-0.694, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6pSFZTULSE1 for ; Tue, 11 Jan 2011 08:15:49 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 015CB3A6A3C for ; Tue, 11 Jan 2011 08:15:48 -0800 (PST) Received: by bwz12 with SMTP id 12so20224809bwz.31 for ; Tue, 11 Jan 2011 08:18:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=3y+jouVuNDLSFPyIvX/5O13e7Kao0Yv386KzKllUK0A=; b=ZpN4uGKHEtxq9MsT5VlaWL6Dkg1zex8jsaNXHK5hVpICnpD7Ab5NU4wbEgWrAcn7uy c4Qlne6mBL2+5CfdU/ABZPdrVqwD1+rPe4zj3RuChSGqSF7KWbZMGN3KdNOE6q8PnfvL f0gpC9PmaEvR9m2SlXj8wbujC0ke7qP08F0j0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ntwAbdPPqq4/Aira1Gq/V34Ti3WX9ZPyXHO6+xASfHDGFDxuo7kueVQL3PDzY6jcFb I60vhdTNY/EADoF7jvn8qZaM8+MwlkjwkC195qhGmw0nPi5+LsPnHvfDQrIUx8xQ+8UV u6zPAfAxUSvsE8mZL+Dgje7HEiLXdSxyQYe/8= Received: by 10.204.84.32 with SMTP id h32mr3234365bkl.181.1294762682977; Tue, 11 Jan 2011 08:18:02 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id v1sm16437469bkt.5.2011.01.11.08.18.01 (version=SSLv3 cipher=RC4-MD5); Tue, 11 Jan 2011 08:18:02 -0800 (PST) Message-ID: <4D2C82CB.6020709@gmail.com> Date: Tue, 11 Jan 2011 18:18:19 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: draft-yevstifeyev-netblt-iana-00.txt and other issues References: <4D2048A5.8090106@gmail.com> <5E0012FB-9095-44DD-B1B1-52A6045979AB@jccw.org> <4D22B63C.6070807@gmail.com> <4D2B2C80.1040906@ericsson.com> In-Reply-To: <4D2B2C80.1040906@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: John White , John C Klensin , "tsvwg@ietf.org" , "draft-ietf-tsvwg-iana-ports@tools.ietf.org" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 16:15:50 -0000 Magnus, Please find some comments below: 10.01.2011 17:57, Magnus Westerlund wrote: > > Mykyta Yevstifeyev skrev 2011-01-04 06:55: >> Hello all, >> >> Let me inform you about the issues connected with my drafts. >> >> Firstly, I have contacted the authors of draft-ietf-tsvwg-iana-ports to >> ask them to include the registration procedures for RDP, NetBLT and IRTP >> ports. Unfortunately, I have received the response mentioning that these >> protocols are not in use and are rather candidates for historic protocol >> . I may agree partly with this, only for IRTP. For the others, I insist >> on including corresponding entries in the document. > You also received from Joe Touch comments (in private) that it doesn't > look appropriate to include any of these protocols in > draft-ietf-tsvwg-iana-ports because they don't meet the criteria for > being suitable. > > You also got the message that you shouldn't create registries unless > they where clearly needed. You never responded to why these protocols > needs registries. It appears to be an action in completeness that seems > inappropriate. Currently I have refused my idea to create some registries for that protocols. My most current view is: IRTP - to Historic; NETBLT - respecify; RDP - do nothing. > If you have a situation where not creating the registries would create > an interoperability mess than explain that situation. > > >> And as for my drafts. I would ask to withdraw my draft related to IRTP, >> but make another one suggesting moving it to Historic. As for RDP, I >> suppose draft-ietf-tsvwg-iana-ports authors will kindly allow this (and >> NETBLT) protocol ports to be registered using the unique procedure and >> as soon as this issues will be covered by this draft, I will ask my >> draft to be marked as replaced by iana-ports one. And as for NETBLT >> draft, it will be replaced by new version of White's draft, for which, I >> think, he would allow me to be the co-author. >> > As I agree with Joe, having the service name and ports registry define > the RDP registry does not seem to be appropriate. If there is need for a > registry for this, then do it in an individual draft. But please show > why it is appropriate. Why is that appropriate? That is simple - how should RDP ports be assigned? And there is a draft on this topic: https://datatracker.ietf.org/doc/draft-yevstifeyev-rdp-ports-registry/ but it just augments the ietf-tsvwg-iana-ports 's action on RDP. >> And lastly, now I ask the authors of draft-ietf-tsvwg-iana-ports to >> address to draft-yevstifeyev-eudp in the way they do it for UDP-Lite to >> allow this protocol ports to be assigned in the same way with UDP-Lite. >> This draft is already in RFC Ed. Queue (currently in the ISR state), but >> if the authors mind this, I will ask it to be the AD-Sponsored one. > First, I would like to point out that IP protocol numbers are under the > registration rules of Standards Action or IESG approval. > http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml In this way the IESG approval is suitable. > Thus, just the RFC-editor publication are not going to get the protocol > a IP protocol number. Going that road requires you to get IESG to > approve the allocation. The RFC Ed. Indep. Subm. are reviewed by IESG. > And I see giving EUDP a protocol number would be the wrong thing to do. > As EUDP is UDP with an twist of having some option fields there is > little gain with this approach and a lot of loss of functionality. You > loose all the NAT and Firewall traversal capability UDP's IP protocol > number gives you. I have asked that before, but why do you think that everything with unknown IP protocol numbers will be just discarded by midle-boxes? > At the same time you also do not address any of the > issues that you create by adding the options. For example security or > congestion control. > > If you want to use this it would be many times smarter to sell it as a > standardize shim on top of UDP. Use regular UDP, after that you add a > Service Code field followed by the data offset field. The serivice code > (or secondary destiantion port) indicate the intended service at the > receiver. Then you register one UDP port. That way you can provide the > functionality without consuming any really valuable resources. That seems like an interesting idea for me so I'll think about this and answer later. All the best, Mykyta Yevstifeyev > So my opinion is that EUDP should not be published in its current form, > either on the standards track or by the RFC-editor as an independent > submission. > > I think it is great that you want to contribute, but I think you should > listen to the feedback that is provided and find something that is more > useful for the community, or a way to resolve the comments that you do > receive. > > Cheers > > 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 magnus.westerlund@ericsson.com Tue Jan 11 08:55:46 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C4F93A6A5A for ; Tue, 11 Jan 2011 08:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.518 X-Spam-Level: X-Spam-Status: No, score=-106.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzn+Xc7kGB6l for ; Tue, 11 Jan 2011 08:55:45 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 2F6403A6A58 for ; Tue, 11 Jan 2011 08:55:44 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-5d-4d2c8c199291 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 4B.FF.13987.91C8C2D4; Tue, 11 Jan 2011 17:58:01 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.2.234.1; Tue, 11 Jan 2011 17:58:00 +0100 Message-ID: <4D2C8C18.3070500@ericsson.com> Date: Tue, 11 Jan 2011 17:58:00 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mykyta Yevstifeyev Subject: Re: draft-yevstifeyev-netblt-iana-00.txt and other issues References: <4D2048A5.8090106@gmail.com> <5E0012FB-9095-44DD-B1B1-52A6045979AB@jccw.org> <4D22B63C.6070807@gmail.com> <4D2B2C80.1040906@ericsson.com> <4D2C82CB.6020709@gmail.com> In-Reply-To: <4D2C82CB.6020709@gmail.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: John White , John C Klensin , "tsvwg@ietf.org" , "draft-ietf-tsvwg-iana-ports@tools.ietf.org" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 16:55:46 -0000 Mykyta Yevstifeyev skrev 2011-01-11 17:18: >> If you have a situation where not creating the registries would create >> an interoperability mess than explain that situation. >> >> >>> And as for my drafts. I would ask to withdraw my draft related to IRTP, >>> but make another one suggesting moving it to Historic. As for RDP, I >>> suppose draft-ietf-tsvwg-iana-ports authors will kindly allow this (and >>> NETBLT) protocol ports to be registered using the unique procedure and >>> as soon as this issues will be covered by this draft, I will ask my >>> draft to be marked as replaced by iana-ports one. And as for NETBLT >>> draft, it will be replaced by new version of White's draft, for which, I >>> think, he would allow me to be the co-author. >>> >> As I agree with Joe, having the service name and ports registry define >> the RDP registry does not seem to be appropriate. If there is need for a >> registry for this, then do it in an individual draft. But please show >> why it is appropriate. > Why is that appropriate? That is simple - how should RDP ports be > assigned? And there is a draft on this topic: But, why does they need to be assigned. If this is an old protocol and in some limited use. What application(s) do you have that requires registered ports, rather than dynamically or resolved port numbers? > > but it just augments the ietf-tsvwg-iana-ports 's action on RDP. >>> And lastly, now I ask the authors of draft-ietf-tsvwg-iana-ports to >>> address to draft-yevstifeyev-eudp in the way they do it for UDP-Lite to >>> allow this protocol ports to be assigned in the same way with UDP-Lite. >>> This draft is already in RFC Ed. Queue (currently in the ISR state), but >>> if the authors mind this, I will ask it to be the AD-Sponsored one. >> First, I would like to point out that IP protocol numbers are under the >> registration rules of Standards Action or IESG approval. >> http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml > In this way the IESG approval is suitable. >> Thus, just the RFC-editor publication are not going to get the protocol >> a IP protocol number. Going that road requires you to get IESG to >> approve the allocation. > The RFC Ed. Indep. Subm. are reviewed by IESG. >> And I see giving EUDP a protocol number would be the wrong thing to do. >> As EUDP is UDP with an twist of having some option fields there is >> little gain with this approach and a lot of loss of functionality. You >> loose all the NAT and Firewall traversal capability UDP's IP protocol >> number gives you. > I have asked that before, but why do you think that everything with > unknown IP protocol numbers will be just discarded by midle-boxes? At least NATs will break your protocol. There are two major issues, on top of the question if they forward unknown protocol numbers at all. First the address translation breaks the checksum, and the checksum would need to be updated to reflect the address translation. Secondly, if an unknown protocol is translated, it can't be port translated, only address translated which is will in turn fail if more than two NAT internal hosts uses this protocol at the same time. cheers 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 mallman@icir.org Fri Jan 14 06:57:35 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29EEE3A6B93 for ; Fri, 14 Jan 2011 06:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.371 X-Spam-Level: X-Spam-Status: No, score=-106.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPt4ATm8+sv0 for ; Fri, 14 Jan 2011 06:57:33 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 64B803A6B91 for ; Fri, 14 Jan 2011 06:57:33 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p0EExwNZ007442; Fri, 14 Jan 2011 06:59:58 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 7EA1F2B76529; Fri, 14 Jan 2011 09:59:58 -0500 (EST) To: Wesley Eddy From: Mark Allman Subject: Re: Deprecation of ICMP Source Quench messages (draft-gont-tsvwg-source-quench) In-Reply-To: <4D267F98.6050508@mti-systems.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Cadillac Ranch MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma25836-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 14 Jan 2011 09:59:58 -0500 Sender: mallman@icir.org Message-Id: <20110114145958.7EA1F2B76529@lawyers.icir.org> Cc: tsvwg@ietf.org, Joe Touch X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 14:57:35 -0000 ----------ma25836-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Realistically, if there isn't an RFC, 2 years from now someone will > come and re-write Fernando's document and ask to have an RFC > published and we'll waste more time on the same discussion, so I'm > in favor of blasting this through the process and getting it > published as long as there's rough consensus on it. We publish > plenty of similarly useless book-keeping RFCs without controversy. I agree with this and with Fred's notion. It isn't a problem, but this document is completely benign and shouldn't "waste time". Nobody has brought up anything but process issues (i.e., nobody is arguing for reacting to SQ) so lets just call rough consensus and move on. allman ----------ma25836-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk0wZO4ACgkQWyrrWs4yIs4aYQCeMsI0d+FmVAAgiFv7Iy+R4hfJ 8qwAn2Rf+aurEqS3K5GMqAWpYooMUUdt =T30w -----END PGP SIGNATURE----- ----------ma25836-1-- From rs@netapp.com Fri Jan 14 12:46:00 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BFDD3A6C8C for ; Fri, 14 Jan 2011 12:46:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUvqvU5xfr2K for ; Fri, 14 Jan 2011 12:45:59 -0800 (PST) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id 251BB3A6C8F for ; Fri, 14 Jan 2011 12:45:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,324,1291622400"; d="scan'208";a="234336458" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 14 Jan 2011 12:48:24 -0800 Received: from ldcrsexc2-prd.hq.netapp.com (webmail.europe.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p0EKmJGi014914; Fri, 14 Jan 2011 12:48:22 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Jan 2011 20:48:20 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Deprecation of ICMP Source Quench messages(draft-gont-tsvwg-source-quench) Date: Fri, 14 Jan 2011 20:48:19 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0C5BB8C3@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <20110114145958.7EA1F2B76529@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Deprecation of ICMP Source Quench messages(draft-gont-tsvwg-source-quench) Thread-Index: Acuz+8LsArN/+vpVQDKeDs2hWvfRdgAGuEyQ References: <4D267F98.6050508@mti-systems.com> <20110114145958.7EA1F2B76529@lawyers.icir.org> From: "Scheffenegger, Richard" To: , "Wesley Eddy" X-OriginalArrivalTime: 14 Jan 2011 20:48:20.0347 (UTC) FILETIME=[60A974B0:01CBB42C] Cc: tsvwg@ietf.org, Joe Touch X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 20:46:00 -0000 +1 > -----Original Message----- > From: Mark Allman [mailto:mallman@icir.org] > Sent: Freitag, 14. J=E4nner 2011 16:00 > To: Wesley Eddy > Cc: tsvwg@ietf.org; Joe Touch > Subject: Re: Deprecation of ICMP Source Quench messages(draft-gont- > tsvwg-source-quench) >=20 >=20 > > Realistically, if there isn't an RFC, 2 years from now someone will > > come and re-write Fernando's document and ask to have an RFC > published > > and we'll waste more time on the same discussion, so I'm in favor of > > blasting this through the process and getting it published as long = as > > there's rough consensus on it. We publish plenty of similarly > useless > > book-keeping RFCs without controversy. >=20 > I agree with this and with Fred's notion. It isn't a problem, but = this > document is completely benign and shouldn't "waste time". Nobody has > brought up anything but process issues (i.e., nobody is arguing for > reacting to SQ) so lets just call rough consensus and move on. >=20 > allman >=20 >=20 From ietfc@btconnect.com Sat Jan 15 04:51:04 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A178E3A6B49 for ; Sat, 15 Jan 2011 04:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.553 X-Spam-Level: X-Spam-Status: No, score=-1.553 tagged_above=-999 required=5 tests=[AWL=-1.169, BAYES_20=-0.74, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXh2973ag1dx for ; Sat, 15 Jan 2011 04:51:03 -0800 (PST) Received: from mail.btconnect.com (c2bthomr09.btconnect.com [213.123.20.127]) by core3.amsl.com (Postfix) with ESMTP id 77EDC3A6AA9 for ; Sat, 15 Jan 2011 04:51:02 -0800 (PST) Received: from host86-134-205-117.range86-134.btcentralplus.com (HELO pc6) ([86.134.205.117]) by c2bthomr09.btconnect.com with SMTP id BJU11262; Sat, 15 Jan 2011 12:53:19 +0000 (GMT) Message-ID: <00a801cbb4aa$544a8140$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Randy Stewart" References: <20101129173002.3461.46301.idtracker@localhost> <005501cb9138$122c99a0$4001a8c0@gateway.2wire.net> <2BA83253-C026-4A93-92D7-64C0324CC421@lakerest.net> <017801cb917c$08d462e0$4001a8c0@gateway.2wire.net> <8C635E3F-12CA-4EA1-9C80-33D3FFB2E393@lakerest.net> <01c001cb9311$1a274760$4001a8c0@gateway.2wire.net> <971CDA6A-93A2-40D2-86E9-7956C5A7BCF3@lakerest.net> Subject: I-D Action:draft-ietf-tsvwg-sctp-strrst-09.txt Date: Sat, 15 Jan 2011 12:49:40 +0100 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-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4D3198B6.00BB, actions=tag X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0205.4D3198C1.013C,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: Michael Tuexen , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 12:51:04 -0000 I like the change to 5.2.3 but think that it needs to go further. -08 split out two cases, Incoming SSN Reset Request received but no response yet to the Outgoing request Incoming SSN Reset Request received after response to the Outgoing request assuming that the Incoming and Outgoing requests have overlapping stream numbers. -09 subdivides the first case into overlaps completely and overlaps partially but I think that the second case is also in need of subdivision in the same way. And, a point of clarification, in any of the four cases, is it required to send just the one response, ie you cannot send two responses in the partial overlap case, one saying no-op and the will do (or won't do!)? Tom Petch From lars.eggert@nokia.com Tue Jan 18 04:21:36 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 538743A6FB6; Tue, 18 Jan 2011 04:21:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.398 X-Spam-Level: X-Spam-Status: No, score=-104.398 tagged_above=-999 required=5 tests=[AWL=-0.799, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjVxvMpbSvzz; Tue, 18 Jan 2011 04:21:35 -0800 (PST) Received: from mgw-da01.nokia.com (mgw-da01.ext.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 4C1713A6FAD; Tue, 18 Jan 2011 04:21:35 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0ICO87U009245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 14:24:10 +0200 Subject: TSVAREA presentation slots for Prague X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-11--781339795; protocol="application/pkcs7-signature"; micalg=sha1 From: Eggert Lars (Nokia-NRC/Espoo) In-Reply-To: Date: Tue, 18 Jan 2011 14:23:59 +0200 Message-Id: <6FD9C643-2DBA-4D77-AEB4-7A5186AA8483@nokia.com> References: To: TSV Area X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Tue, 18 Jan 2011 14:24:06 +0200 (EET) X-Nokia-AV: Clean Cc: tsvwg WG , tsv-chairs@ietf.org, TSV Dir X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsv-ads@tools.ietf.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 12:21:36 -0000 --Apple-Mail-11--781339795 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, this is a call for presentations for the TSVAREA meeting in Prague. = We're sending this early, so we can request an agenda slot of suitable = length. Please send agenda requests for TSVAREA to tsv-ads@tools.ietf.org, = including: title/topic presenter requested time Reminder: The purpose of the TSVAREA meeting is to inform about and = discuss important issues, developments and work within the transport = area or outside work that impacts the transport area. In contrast to = TSVWG, TSVAREA does not produce any documents. TSVAREA can include = tutorial-style talks on transport topics, maybe based on related IRTF or = other research work. Another possibility is "elevator pitch" talks, = where interested people can get quick community feedback on ideas for = new work. Lars --Apple-Mail-11--781339795 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDExODEyMjM2MFowIwYJKoZIhvcNAQkE MRYEFINOv28/tH8VWsBXhhC4sqmqZIDGMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AD4uhPszEGwRn+Oj9FJSkssb4e4LlzZHDFEM1BANho5mkez0ISqh1SSUXdgSI9m/u3TL/KKSkcL2 7tOTUiPJItWgbSo1VuDOTJyMNxsBbsurdsqVaL3/FWm4V7s2IM3nHuPRtBCtZSqpJH8DpuwGGB8v EBoGO2tthpsaqb+btzWBVi+Nw3YNx8b93pFdhqim1Q54gwkUCftovw4Bo5gmCaRXYr6RO3XCGXu+ yyPBzsZ9oyEUMyTXerS9sbK4CXI9+3VGmyPN/1tn3KZdkTTG2OJ9WQRWaefm5ken9AIuqJxOR3Ij 1RDAsM5yq9SIE6RT46MFwlBWaSpFFV4XYH9ELskAAAAAAAA= --Apple-Mail-11--781339795-- From gorry@erg.abdn.ac.uk Tue Jan 18 09:58:39 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7163B3A7050 for ; Tue, 18 Jan 2011 09:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGfpYeCIvl8J for ; Tue, 18 Jan 2011 09:58:38 -0800 (PST) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id C82153A7035 for ; Tue, 18 Jan 2011 09:58:37 -0800 (PST) Received: from gorry-mac.erg.abdn.ac.uk ([IPv6:2001:630:241:207:21f:5bff:fe38:7354]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p0II17q7013479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 18 Jan 2011 18:01:07 GMT Message-ID: <4D35D564.9050704@erg.abdn.ac.uk> Date: Tue, 18 Jan 2011 18:01:08 +0000 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: tsvwg WG Subject: TSVWG Status Update (18th Jan 2011) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 17:58:39 -0000 The email below gives a brief snapshot of WG status for 18th Jan 2011. This also includes several corrections sent by people (thanks again). Please look at what needs to be done. Do send notes of any corrections to tsvwg-chairs@tools.ietf.org. Gorry James (TSVWG Chairs) ================================================================== RFC Published: draft-ietf-tsvwg-admitted-realtime-dscp-07 (RFC 5865) draft-ietf-tsvwg-rsvp-proxy-approaches-09 (RFC 5945) draft-ietf-tsvwg-rsvp-proxy-proto-11 (RFC 5946) draft-ietf-tsvwg-rsvp-l3vpn-07 (RFC 6016) draft-ietf-tsvwg-ecn-tunnel-10 (RFC6040) --- IDs in RFC Editor Queue: draft-ietf-tsvwg-emergency-rsvp-15 (MISREF) Norm. ref to router alert draft (in the INT-area WG) draft-ietf-tsvwg-port-randomization-09 (Auth-48) James is Shepherd. draft-ietf-tsvwg-sctp-chunk-flags-02 (RFC-Ed) was: draft-tuexen-tsvwg-sctp-chunk-flags. TSVWG supported adoption (6 people, concluded 3/6/2010). List of reviewers supplied by document editor. WGLC ended Sept 6th 2010. New revision 7th Sept 2010. Proto write-up sent by shepherd 22/9/2010. IETF Last Call ended 7/10/2010. With RFC-Ed Gorry is Shepherd. draft-ietf-tsvwg-dtls-for-sctp-06 Proto write-up sent by shepherd AUTH-48 (Auth-48: Awaiting E Rescorla) Gorry is Shepherd. ------------------------------------------------------------------- IDs in IESG processing: draft-ietf-tsvwg-rsvp-security-groupkeying WGLC of previous version completed. SECDIR review comments received, and updated as version -05. Short WGLC to confirm new text ended August 11th 2010. New version (-09) 22-10-2010. Proto write-up sent shepherd 14/02/2010. James is Shepherd. ------------------------------------------------------------------- WG Drafts with Chairs: draft-ietf-tsvwg-iana-ports New revision 25 Oct 2010. This will require a multi-working group LC. draft-ietf-tsvwg-iana-ports-08 was WGL'ed 30-10-2010 WGLC ended Friday, 26th November 2010 New version -09 02/12/2010. Discussion on list during Dec 2010. AD review received 21/12/2010. Proto Write-up sent to be sent to list 19/01/2011. Gorry is Shepherd. ------------------------------------------------------------------- WG Drafts: draft-ietf-tsvwg-sctpsocket New Rev -25, 07/01/2011. This will require an apps area review in WGLC. Due: Please volunteer to review this draft in WGLC. Due: Ready for WGLC by Chair. draft-ietf-tsvwg-sctp-strrst Dependency on this for IPFIX document with RFC-Ed. Benoit Claise to review for IPFIX New revision (-08) 25 Oct 2010. Text on race-condition to be updated before WGLC New text to address this in revision 04/01/2011. Due: Please volunteer to review this draft in WGLC. Due: Ready for WGLC by Chair. draft-ietf-tsvwg-byte-pkt-congest New editor added Jul 2010. New revision 25 Oct 2010. Comments needed before deciding if ready for WGLC. draft-ietf-tsvwg-sctp-udp-encap was: draft-tuexen-sctp-udp-encap Lars sent a note as AD agreeing to progress this work. Work to be coordinated with DCCP work on encaps. Adopted as a work item 21 Sept 2010 (Gorry). No WG -00 draft. New revision expected. draft-ietf-tsvwg-natsupp-tsvwg was: draft-stewart-natsupp-tsvwg. Dependency from BEHAVE WG. Adopted as a work item 21 Sept 2010 (Gorry). WG -00, 29/11/2010 New revision expected. ------------------------------------------------------------------- WG action required: draft-gont-tsvwg-source-quench-01.txt IETF-79 suggested there was interest in this topic. Comments to list in 2010 from: Fred Baker, Antonio DeSimone, James Polk, Gorry Fairhurst, Andrew Yourtchenko, and others. WG needs to assess if the new draft should be a work item. Please comment on list. draft-polk-tsvwg-rsvp-app-id-vv-profiles -01 Presented in Beijing. WG needs to assess if the new draft should be a work item. Please comment on list. ------------------------------------------------------------------- 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-stewart-tsvwg-sctp-nonce IETF-78 suggested there was interest in this topic. Please comment to list. Revised draft to be uploaded with new name. WG needs to assess if the new draft should be a work item. draft-polk-tsvwg-intserv-multiple-tspec RSVP directorate to be consulted. 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. New Version -05 (presented in Beijing) WG needs to assess if the new draft should be a work item. draft-lefaucheur-tsvwg-rsvp-multiple-preemption RSVP directorate to be consulted. - Reviewers: Bruce Davie (awaiting other reviews) WG needs to assess if this topic should be a work item. draft-wing-tsvwg-happy-eyeballs-sctp Please comment to list. draft-tuexen-tsvwg-sctp-multipath Please comment to list. draft-tuexen-tsvwg-sctp-sack-immediately Please comment to list. draft-lei-tsvwg-sctp-compr-requirements-profile Please comment to list. draft-wei-tsvwg-nested-header-compression Please comment to list. draft-nishida-tsvwg-sctp-failover Please comment to list. draft-narayanan-tsvwg-rsvp-resource-sharing Please comment to list. draft-nishida-natarajan-sctp-failover Please comment to list. draft-wei-tsvwg-nested-header-compression Please comment to list. ------------------------------------------------------------------- Related non-WG items: draft-fairhurst-tsvwg-6man-udpzero Draft was adopted by 6man, please discuss on the 6man list. This will be LC'ed in TSVWG also. draft-ietf-dccp-udpencap DCCP WG item linked to encaps (WGLC) draft-narayanan-tsvwg-rsvp-resource-sharing Authors will take this draft to CCAMP WG. draft-ietf-behave-sctpnat-03.txt BEHAVE WG item linked to SCTP encapsulation work. ------------------------------------------------------------------ Other news: RSVP Directorate (formed in May 2010) - Rules and guidelines to be formulated Charter to be updated to indicate procedure for adoption. ------------------------------------------------------------------ From wwwrun@rfc-editor.org Tue Jan 18 12:29:21 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50BB73A7078; Tue, 18 Jan 2011 12:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.279 X-Spam-Level: X-Spam-Status: No, score=-102.279 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AjIb4esTVGG; Tue, 18 Jan 2011 12:29:20 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 825D33A7069; Tue, 18 Jan 2011 12:29:20 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id CC471E06F2; Tue, 18 Jan 2011 12:31:58 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: BCP 156, RFC 6056 on Recommendations for Transport-Protocol Port Randomization From: rfc-editor@rfc-editor.org Message-Id: <20110118203158.CC471E06F2@rfc-editor.org> Date: Tue, 18 Jan 2011 12:31:58 -0800 (PST) Cc: tsvwg@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 20:29:21 -0000 A new Request for Comments is now available in online RFC libraries. BCP 156 RFC 6056 Title: Recommendations for Transport-Protocol Port Randomization Author: M. Larsen, F. Gont Status: Best Current Practice Stream: IETF Date: January 2011 Mailbox: michael.larsen@tieto.com, fernando@gont.com.ar Pages: 29 Characters: 63913 See Also: BCP0156 I-D Tag: draft-ietf-tsvwg-port-randomization-09.txt URL: http://www.rfc-editor.org/rfc/rfc6056.txt During the last few years, awareness has been raised about a number of "blind" attacks that can be performed against the Transmission Control Protocol (TCP) and similar protocols. The consequences of these attacks range from throughput reduction to broken connections or data corruption. These attacks rely on the attacker's ability to guess or know the five-tuple (Protocol, Source Address, Destination Address, Source Port, Destination Port) that identifies the transport protocol instance to be attacked. This document describes a number of simple and efficient methods for the selection of the client port number, such that the possibility of an attacker guessing the exact value is reduced. While this is not a replacement for cryptographic methods for protecting the transport-protocol instance, the aforementioned port selection algorithms provide improved security with very little effort and without any key management overhead. The algorithms described in this document are local policies that may be incrementally deployed and that do not violate the specifications of any of the transport protocols that may benefit from them, such as TCP, UDP, UDP-lite, Stream Control Transmission Protocol (SCTP), Datagram Congestion Control Protocol (DCCP), and RTP (provided that the RTP application explicitly signals the RTP and RTCP port numbers). This memo documents an Internet Best Current Practice. This document is a product of the Transport Area Working Group Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From iesg-secretary@ietf.org Tue Jan 18 13:26:04 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FE9728C0D7; Tue, 18 Jan 2011 13:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U821ktvKCSum; Tue, 18 Jan 2011 13:26:03 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3E493A6E57; Tue, 18 Jan 2011 13:26:03 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110118212603.5733.34489.idtracker@localhost> Date: Tue, 18 Jan 2011 13:26:03 -0800 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 21:26:04 -0000 The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry' as a BCP 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 2011-02-01. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/ No IPR declarations have been submitted directly on this I-D. From dlehmann@ulticom.com Wed Jan 19 11:36:47 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3CC628C0EB for ; Wed, 19 Jan 2011 11:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uK8AGQkD0RUs for ; Wed, 19 Jan 2011 11:36:45 -0800 (PST) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id BA45A28C0E7 for ; Wed, 19 Jan 2011 11:36:44 -0800 (PST) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id AD59824E89D1CE65 for ; Wed, 19 Jan 2011 14:39:18 -0500 (EST) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id p0JJd6GW027154 for ; Wed, 19 Jan 2011 14:39:18 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBB810.886F0B76" Subject: Quick Failover Algorithm in SCTP Date: Wed, 19 Jan 2011 14:39:05 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Quick Failover Algorithm in SCTP Thread-Index: Acu39psqXG8x+rvfR5ygzjerIA4HygAFr/pQ From: "David Lehmann" To: Received-SPF: pass X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 19:36:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBB810.886F0B76 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 What is the status of this I-D? draft-nishida-tsvwg-sctp-failover-02 =20 I would like to see this feature move forward. As you are aware, it is crucial in the telecom world that a failure is resolved quickly. Ulticom has had quick failover in its SCTP implementation for 10 years now. IMHO, each OS' native SCTP implementation should have quick failover. ...just my $.02=20 =20 What is the next step in the process? =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 ------_=_NextPart_001_01CBB810.886F0B76 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

What is the status of = this I-D?  draft-nishida-tsvwg-sctp-failover-02

=

 

I would like to see = this feature move forward.  As you are aware, it is crucial in the telecom world = that a failure is resolved quickly.  Ulticom has had quick failover in its = SCTP implementation for 10 years now.  IMHO, each OS’ native SCTP = implementation should have quick failover.   …just my $.02 =

 

What is the next step = in the process?

 

--

David = Lehmann

Ulticom, = Inc.

856-787-2952

 

------_=_NextPart_001_01CBB810.886F0B76-- From steffen.list.account@gmail.com Wed Jan 19 12:21:49 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0C453A708C for ; Wed, 19 Jan 2011 12:21:49 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnU3O0FTJsmI for ; Wed, 19 Jan 2011 12:21:49 -0800 (PST) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id ED73B3A6F18 for ; Wed, 19 Jan 2011 12:21:48 -0800 (PST) Received: by pxi6 with SMTP id 6so276477pxi.31 for ; Wed, 19 Jan 2011 12:24:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type:content-transfer-encoding; bh=wIGxOHaUe/SN3sOgcmPH3CX5yHH9NSQWD+2AaEhP6Vw=; b=u5z02HKgFXF1u4QNPS3U2UgSoZO4ZJOV/x93uLlF1aEhSVtwYv9Lehm1tLhA3NrOO+ 1yyI+0pLI0F0WutTGzIeFw9+wDIk9cElH2HMPDkXBCOZRyVz/+gYUCbrQldCpJybHI/9 BfX97MAacho/fdl5zCbdr47Ajf/lkFc+9viNQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=fNDb8t0T4FRExKULqC0Y2tlJTNGTNSdt/wj/GOwMhBd1ncXWJwVXiAenVcQCl3RvEE Lahon88UGjfW0srYw39X5xquQc2KL2TCmV9cjIiCD8zF2U+798sbDyx7TVYz1VAueTaz 56lvheYAkd24bV5BWHQXNZeiDwX1m96QWekOI= Received: by 10.142.116.4 with SMTP id o4mr1201315wfc.125.1295468669897; Wed, 19 Jan 2011 12:24:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.44.6 with HTTP; Wed, 19 Jan 2011 12:24:09 -0800 (PST) In-Reply-To: References: From: Thomas Steffen Date: Wed, 19 Jan 2011 20:24:09 +0000 Message-ID: Subject: Re: Quick Failover Algorithm in SCTP To: tsvwg@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 20:21:50 -0000 On Wed, Jan 19, 2011 at 7:39 PM, David Lehmann wrote= : > IMHO, > each OS=92 native SCTP implementation should have quick failover.=A0=A0 = =85just my > $.02 I didn't say much on this list recently, but to come out of hiding: I fully agree. Failover is pretty useless if it does not happen quickly. You can define quickly as roughly within normal transmission time (milliseconds) or within about a second. But the standard on OS level used to be around 30s, and that is bound to cause problems in most applications. Regards, Thomas From jmpolk@cisco.com Wed Jan 19 12:45:54 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 682943A71C5 for ; Wed, 19 Jan 2011 12:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.52 X-Spam-Level: X-Spam-Status: No, score=-110.52 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMsIrCvmdTXh for ; Wed, 19 Jan 2011 12:45:53 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id AF4873A71C4 for ; Wed, 19 Jan 2011 12:45:53 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAArdNk2rR7Ht/2dsb2JhbACkSHOkSpsLgxKCPgSEbw Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 19 Jan 2011 20:48:34 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8716.cisco.com [10.99.80.23]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0JKmYoO012572; Wed, 19 Jan 2011 20:48:34 GMT Message-Id: <201101192048.p0JKmYoO012572@sj-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 19 Jan 2011 14:48:33 -0600 To: "David Lehmann" , From: "James M. Polk" Subject: Re: Quick Failover Algorithm in SCTP In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 20:45:54 -0000 At 01:39 PM 1/19/2011, David Lehmann wrote: >Hello, > >What is the status of this I-D? draft-nishida-tsvwg-sctp-failover-02 > >I would like to see this feature move=20 >forward. As you are aware, it is crucial in the=20 >telecom world that a failure is resolved=20 >quickly. Ulticom has had quick failover in its=20 >SCTP implementation for 10 years now. IMHO,=20 >each OS=92 native SCTP implementation should have=20 >quick failover. =85just my $.02 > >What is the next step in the process? The status of this ID is that of an individual=20 submission, with a target WG of TSVWG. The chairs=20 currently believe there has been insufficient=20 review within the WG to date to warrant=20 progressing this document to the next level. Your=20 note obviously helps the chairs determine if=20 there is interest in this effort. We thank you=20 for the comment. More comments (that show there=20 was a review per comment, preferably) will nudge=20 us towards reviewing progression of this effort. Does this seem reasonable? James & Gorry TSVWG chairs > >-- >David Lehmann >Ulticom, Inc. >856-787-2952 > From dlehmann@ulticom.com Wed Jan 19 12:54:04 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05AD13A71C7 for ; Wed, 19 Jan 2011 12:54:04 -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=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkclo+N8MmEm for ; Wed, 19 Jan 2011 12:54:03 -0800 (PST) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id 249AF3A71BB for ; Wed, 19 Jan 2011 12:54:03 -0800 (PST) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id 6B3A907F85C3D063 for ; Wed, 19 Jan 2011 15:56:43 -0500 (EST) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id p0JKuhHs005833 for ; Wed, 19 Jan 2011 15:56:43 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Quick Failover Algorithm in SCTP Date: Wed, 19 Jan 2011 15:56:42 -0500 Message-ID: In-Reply-To: <201101192048.p0JKmYoO012572@sj-core-1.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Quick Failover Algorithm in SCTP Thread-Index: Acu4Gkvps1nGu1SBRMiHZOcBMwX5DAAAFvhw References: <201101192048.p0JKmYoO012572@sj-core-1.cisco.com> From: "David Lehmann" To: Received-SPF: pass X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 20:54:04 -0000 > >What is the next step in the process? >=20 > The status of this ID is that of an individual > submission, with a target WG of TSVWG. The chairs > currently believe there has been insufficient > review within the WG to date to warrant > progressing this document to the next level. Your > note obviously helps the chairs determine if > there is interest in this effort. We thank you > for the comment. More comments (that show there > was a review per comment, preferably) will nudge > us towards reviewing progression of this effort. >=20 > Does this seem reasonable? Yes. =20 Those in favor of this document, please speak up! =20 Thank you. -David From Michael.Tuexen@lurchi.franken.de Wed Jan 19 13:01:25 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D87123A71C9 for ; Wed, 19 Jan 2011 13:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KV4qF4QVJKu2 for ; Wed, 19 Jan 2011 13:01:25 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id B73D53A71C3 for ; Wed, 19 Jan 2011 13:01:24 -0800 (PST) Received: from [192.168.1.113] (p508F9B30.dip.t-dialin.net [80.143.155.48]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 086D71C0B4611; Wed, 19 Jan 2011 22:04:02 +0100 (CET) Subject: Re: Quick Failover Algorithm in SCTP Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Date: Wed, 19 Jan 2011 22:04:02 +0100 Content-Transfer-Encoding: 7bit Message-Id: <61E28A18-F920-457E-9310-67EC3AE9C107@lurchi.franken.de> References: <201101192048.p0JKmYoO012572@sj-core-1.cisco.com> To: David Lehmann X-Mailer: Apple Mail (2.1082) Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 21:01:25 -0000 On Jan 19, 2011, at 9:56 PM, David Lehmann wrote: >>> What is the next step in the process? >> >> The status of this ID is that of an individual >> submission, with a target WG of TSVWG. The chairs >> currently believe there has been insufficient >> review within the WG to date to warrant >> progressing this document to the next level. Your >> note obviously helps the chairs determine if >> there is interest in this effort. We thank you >> for the comment. More comments (that show there >> was a review per comment, preferably) will nudge >> us towards reviewing progression of this effort. >> >> Does this seem reasonable? > > Yes. > > Those in favor of this document, please speak up! > Thank you. Dear all, I do support this document (after initially being conservative). It should be noted that using PFMR = PMR, the behavior of RFC 4960 is used. Best regards Michael > > -David > > From randall@lakerest.net Wed Jan 19 14:57:29 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67C8428C0F1 for ; Wed, 19 Jan 2011 14:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHDip3tCUm2n for ; Wed, 19 Jan 2011 14:57:28 -0800 (PST) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by core3.amsl.com (Postfix) with ESMTP id 1295028C0E0 for ; Wed, 19 Jan 2011 14:57:27 -0800 (PST) Received: from [10.1.1.105] (bsd3.lakerest.net [70.155.160.101]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id p0JN0588033545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 19 Jan 2011 18:00:05 -0500 (EST) (envelope-from randall@lakerest.net) Subject: Re: Quick Failover Algorithm in SCTP Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Randy Stewart In-Reply-To: <61E28A18-F920-457E-9310-67EC3AE9C107@lurchi.franken.de> Date: Wed, 19 Jan 2011 18:00:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201101192048.p0JKmYoO012572@sj-core-1.cisco.com> <61E28A18-F920-457E-9310-67EC3AE9C107@lurchi.franken.de> To: =?iso-8859-1?Q?Michael_T=FCxen?= X-Mailer: Apple Mail (2.1082) Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 22:57:29 -0000 +1 I have often thought after my work with Armando that expanding the way we do failover in SCTP is a good thing.. This is a good start... and with a bit of WG help SHOULD become what we do in SCTP stacks ;-) R On Jan 19, 2011, at 4:04 PM, Michael T=FCxen wrote: > On Jan 19, 2011, at 9:56 PM, David Lehmann wrote: >=20 >>>> What is the next step in the process? >>>=20 >>> The status of this ID is that of an individual >>> submission, with a target WG of TSVWG. The chairs >>> currently believe there has been insufficient >>> review within the WG to date to warrant >>> progressing this document to the next level. Your >>> note obviously helps the chairs determine if >>> there is interest in this effort. We thank you >>> for the comment. More comments (that show there >>> was a review per comment, preferably) will nudge >>> us towards reviewing progression of this effort. >>>=20 >>> Does this seem reasonable? >>=20 >> Yes. =20 >>=20 >> Those in favor of this document, please speak up! =20 >> Thank you. > Dear all, >=20 > I do support this document (after initially being conservative). >=20 > It should be noted that using PFMR =3D PMR, the behavior of RFC 4960 > is used. >=20 > Best regards > Michael=20 >>=20 >> -David >>=20 >>=20 >=20 ----- Randall Stewart randall@lakerest.net From bidulock@openss7.org Wed Jan 19 16:41:31 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C6CF3A71FA for ; Wed, 19 Jan 2011 16:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETM+9ou+niuV for ; Wed, 19 Jan 2011 16:41:30 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 33A2D3A71F7 for ; Wed, 19 Jan 2011 16:41:29 -0800 (PST) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0K0iAGW030313; Wed, 19 Jan 2011 17:44:10 -0700 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0K0iAPL000567; Wed, 19 Jan 2011 17:44:10 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p0K0i9gd000566; Wed, 19 Jan 2011 17:44:09 -0700 Date: Wed, 19 Jan 2011 17:44:09 -0700 From: "Brian F. G. Bidulock" To: David Lehmann Subject: Re: Quick Failover Algorithm in SCTP Message-ID: <20110120004409.GA32615@openss7.org> Mail-Followup-To: David Lehmann , tsvwg@ietf.org References: <201101192048.p0JKmYoO012572@sj-core-1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 00:41:31 -0000 David, I'm not in favour of the document, but I'll speak up anyway. I do not support this document because CMT-based approaches are far superior and have been fielded by multiple commerical implementations for quite a few years. I would sum up this draft as too little too late. Progressing it would place pressure on implementations already using the superior approach to also implement this half-baked inferior one. OTOH, I would support (with comments, review and field experience) standardization of the full CMT-based approach. Note also that there are more individuals actively contributing to the WG that have significant experience with the CMT-based approaches. --brian David Lehmann wrote: (Wed, 19 Jan 2011 15:56:42) > > >What is the next step in the process? > > > > The status of this ID is that of an individual > > submission, with a target WG of TSVWG. The chairs > > currently believe there has been insufficient > > review within the WG to date to warrant > > progressing this document to the next level. Your > > note obviously helps the chairs determine if > > there is interest in this effort. We thank you > > for the comment. More comments (that show there > > was a review per comment, preferably) will nudge > > us towards reviewing progression of this effort. > > > > Does this seem reasonable? > > Yes. > > Those in favor of this document, please speak up! > Thank you. > > -David -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From wesley.m.eddy@nasa.gov Wed Jan 19 12:51:40 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27BD33A71C9; Wed, 19 Jan 2011 12:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.358 X-Spam-Level: X-Spam-Status: No, score=-106.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyyrNcLjJsJH; Wed, 19 Jan 2011 12:51:38 -0800 (PST) Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [198.117.1.123]) by core3.amsl.com (Postfix) with ESMTP id 39CAC3A7067; Wed, 19 Jan 2011 12:51:38 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 30B202D8556; Wed, 19 Jan 2011 14:54:19 -0600 (CST) Received: from ndjshub05.ndc.nasa.gov (ndjshub05.ndc.nasa.gov [198.117.4.164]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id p0JKsJss019943; Wed, 19 Jan 2011 14:54:19 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub05.ndc.nasa.gov ([198.117.4.164]) with mapi; Wed, 19 Jan 2011 14:54:19 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: TSV Dir , TSV Area Date: Wed, 19 Jan 2011 14:54:18 -0600 Subject: tsv-dir review of draft-ietf-tsvwg-iana-ports-09 Thread-Topic: tsv-dir review of draft-ietf-tsvwg-iana-ports-09 Thread-Index: Acu4GwoLc6l+m9QORjOgpPrBb3Pp7A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-01-19_08:2011-01-19, 2011-01-19, 1970-01-01 signatures=0 X-Mailman-Approved-At: Wed, 19 Jan 2011 17:21:45 -0800 Cc: tsvwg IETF list , "draft-ietf-tsvwg-iana-ports@tools.ietf.org" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 20:51:40 -0000 I've reviewed this document as part of the transport area directorate's ong= oing effort to review key IETF documents. These comments were written prima= rily for the transport area directors, but are copied to the document's aut= hors for their information and to allow them to address any issues raised. = The authors should consider this review together with any other last-call c= omments they receive. Please always CC tsv-dir@ietf.org if you reply to or = forward this review. This draft is ready for publication as a BCP RFC. A few small comments which I don't think should be blocking are: 1 - on page 11, in section 6, "near-infinite" is a bit of an exaggeration 2 - on page 16, there's a typo: "MUST accompanied" should be "MUST be accom= panied" 3 - on page 17, it may be a good idea to be clear whether the Assignee can = be an individual (not just an organization) 4 - on page 17, Contact is defined as a person, but using the IESG as the C= ontact makes it a group (not a "person"); it might be good to clarify Conta= ct as a person or group of people 5 - on page 17, in the Reference definition, it may be good to qualify the = description of broadcast/multicast/anycast use by the protocol as being IP-= layer broadcast/multicast/anycast to disambiguate from possible application= -layer mechanisms for these that might be used -- Wes Eddy MTI Systems From erosen@cisco.com Mon Jan 10 09:43:44 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D743B3A6AFE; Mon, 10 Jan 2011 09:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.542 X-Spam-Level: X-Spam-Status: No, score=-10.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvE3nwR1NE1W; Mon, 10 Jan 2011 09:43:44 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id CB5A93A6AFC; Mon, 10 Jan 2011 09:43:43 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 10 Jan 2011 17:45:58 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0AHjvdi025805; Mon, 10 Jan 2011 17:45:57 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id p0AHju44022832; Mon, 10 Jan 2011 12:45:57 -0500 To: bidulock@openss7.org Subject: Re: Old transport-layer protocols to Historic? In-reply-to: Your message of Sun, 09 Jan 2011 01:06:10 -0700. <20110109080610.GA12782@openss7.org> Date: Mon, 10 Jan 2011 12:45:56 -0500 Message-ID: <22831.1294681556@erosen-linux> From: Eric Rosen X-Mailman-Approved-At: Wed, 19 Jan 2011 17:21:54 -0800 Cc: Bob Hinden , tsvwg@ietf.org, IETF Discussion X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: erosen@cisco.com List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 17:43:44 -0000 > RDP is still in use > was the initial transport used for gateway control (such as SGCP) until > SCTP was developed. > Many commercial gateways still support these older pre-standard (to > MEGACO) control protocols. Some older devices still provisioned in the > network only support the older protocols. > but we had nothing before SCTP that would fit the bill. Its limitations > was one of the driving forces behind developing SCTP. So RDP is a useful and deployed pre-standards protocol that was one of the driving forces behind a successful standardization effort. But newer applications that need that kind of transport instead use the standard, SCTP. I don't know how one could possibly make a stronger case for classifying the RDP spec as Historic! However, I do agree with John Klensin's remark that reclassification is not worth the energy it takes. From cbenson@adax.com Wed Jan 19 17:33:02 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 676CD28C14A for ; Wed, 19 Jan 2011 17:33:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.055 X-Spam-Level: X-Spam-Status: No, score=-2.055 tagged_above=-999 required=5 tests=[AWL=0.544, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CioHRMwqIt08 for ; Wed, 19 Jan 2011 17:33:01 -0800 (PST) Received: from mail1.adax.com (mail1.adax.com [208.201.231.104]) by core3.amsl.com (Postfix) with ESMTP id 6A71228C14C for ; Wed, 19 Jan 2011 17:33:01 -0800 (PST) Received: from adax (adax [12.0.0.88]) by mail1.adax.com (Postfix) with ESMTP id 088E71209FB; Wed, 19 Jan 2011 17:35:43 -0800 (PST) Received: by adax (Postfix, from userid 243) id 1B6328ED2D; Wed, 19 Jan 2011 17:38:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by adax (Postfix) with ESMTP id 1232B8ED00; Wed, 19 Jan 2011 17:38:07 -0800 (PST) Date: Wed, 19 Jan 2011 17:38:07 -0800 (PST) From: Chris Benson X-X-Sender: cbenson@adax.adax To: David Lehmann Subject: RE: Quick Failover Algorithm in SCTP In-Reply-To: Message-ID: References: <201101192048.p0JKmYoO012572@sj-core-1.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 01:33:02 -0000 >> draft-nishida-tsvwg-sctp-failover-02 +1. This looks useful even in the presence of other extensions. Chris Benson. On Wed, 19 Jan 2011, David Lehmann wrote: >> Date: Wed, 19 Jan 2011 15:56:42 -0500 >> From: David Lehmann >> To: >> Subject: RE: Quick Failover Algorithm in SCTP >> >> > >What is the next step in the process? >> > >> > The status of this ID is that of an individual >> > submission, with a target WG of TSVWG. The chairs >> > currently believe there has been insufficient >> > review within the WG to date to warrant >> > progressing this document to the next level. Your >> > note obviously helps the chairs determine if >> > there is interest in this effort. We thank you >> > for the comment. More comments (that show there >> > was a review per comment, preferably) will nudge >> > us towards reviewing progression of this effort. >> > >> > Does this seem reasonable? >> >> Yes. >> Chris Benson, Software Engineer, Adax Inc., Berkeley, California, USA. cbenson@adax.com +1 510 548-7047 ext. 189 www.adax.com >> Those in favor of this document, please speak up! >> Thank you. >> >> -David >> From wwwrun@rfc-editor.org Thu Jan 20 09:49:09 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 482B828C0EE; Thu, 20 Jan 2011 09:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.997 X-Spam-Level: X-Spam-Status: No, score=-101.997 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWFHm1CGb43K; Thu, 20 Jan 2011 09:49:08 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 89A2D28C0D9; Thu, 20 Jan 2011 09:49:08 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 4CA4DE0732; Thu, 20 Jan 2011 09:51:51 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 6083 on Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP) From: rfc-editor@rfc-editor.org Message-Id: <20110120175152.4CA4DE0732@rfc-editor.org> Date: Thu, 20 Jan 2011 09:51:51 -0800 (PST) Cc: tsvwg@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 17:49:09 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6083 Title: Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP) Author: M. Tuexen, R. Seggelmann, E. Rescorla Status: Standards Track Stream: IETF Date: January 2011 Mailbox: tuexen@fh-muenster.de, seggelmann@fh-muenster.de, ekr@networkresonance.com Pages: 9 Characters: 16674 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tsvwg-dtls-for-sctp-06.txt URL: http://www.rfc-editor.org/rfc/rfc6083.txt This document describes the usage of the Datagram Transport Layer Security (DTLS) protocol over the Stream Control Transmission Protocol (SCTP). DTLS over SCTP provides communications privacy for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. Applications using DTLS over SCTP can use almost all transport features provided by SCTP and its extensions. [STANDARDS-TRACK] This document is a product of the Transport Area Working Group Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From dreibh@iem.uni-due.de Thu Jan 20 12:36:34 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B9A23A6810 for ; Thu, 20 Jan 2011 12:36:34 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9X8CA8qcfx0M for ; Thu, 20 Jan 2011 12:36:32 -0800 (PST) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by core3.amsl.com (Postfix) with ESMTP id 804C53A680D for ; Thu, 20 Jan 2011 12:36:32 -0800 (PST) Received: from lupo.localnet (p5086D399.dip.t-dialin.net [80.134.211.153]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id p0KKdAmP018730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Jan 2011 21:39:14 +0100 From: Thomas Dreibholz Organization: University of Duisburg-Essen, Institute for Experimental Mathematics To: tsvwg@ietf.org, bidulock@openss7.org Subject: Re: Quick Failover Algorithm in SCTP Date: Thu, 20 Jan 2011 20:51:43 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.37dreibholz; KDE/4.5.5; x86_64; ; ) References: <20110120004409.GA32615@openss7.org> In-Reply-To: <20110120004409.GA32615@openss7.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3675256.U2VVtOfEn2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201101202051.44800.dreibh@iem.uni-due.de> 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 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 20:36:34 -0000 --nextPart3675256.U2VVtOfEn2 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Donnerstag 20 Januar 2011, Brian F. G. Bidulock wrote: > David, >=20 > I'm not in favour of the document, but I'll speak up > anyway. I do not support this document because > CMT-based approaches are far superior and have been > fielded by multiple commerical implementations for > quite a few years. I would sum up this draft as too > little too late. Progressing it would place pressure > on implementations already using the superior approach > to also implement this half-baked inferior one. >=20 > OTOH, I would support (with comments, review and field > experience) standardization of the full CMT-based > approach. Note also that there are more individuals > actively contributing to the WG that have significant > experience with the CMT-based approaches. Dear all, quick failover will actually be part of the full CMT-based approach describ= ed=20 by the document draft-tuexen-tsvwg-sctp-multipath-01.txt. See section 4.3 o= f=20 this draft. Without quick failover, CMT-SCTP would try to send on not worki= ng=20 paths for a long time. This would significantly degrade performance. Best regards =2D-=20 =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 Dr. Thomas Dreibholz University of Duisburg-Essen, Room ES210 Inst. for Experimental Mathematics Ellernstra=DFe 29 Computer Networking Technology Group D-45326 Essen/Germany =2D---------------------------------------------------------------------- E-Mail: dreibh@iem.uni-due.de Homepage: http://www.iem.uni-due.de/~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 --nextPart3675256.U2VVtOfEn2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk04klAACgkQ32BbsHYPLWXFqwCg2Cgy63yfFnOuo3DBmYerxRao 570AoIVpz5l7AAJKX9Cu6Lm1y2lOtd0k =aI0h -----END PGP SIGNATURE----- --nextPart3675256.U2VVtOfEn2-- From dreibh@iem.uni-due.de Thu Jan 20 12:36:34 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BAEE3A6813 for ; Thu, 20 Jan 2011 12:36:34 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+cE9GDEnkKE for ; Thu, 20 Jan 2011 12:36:32 -0800 (PST) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by core3.amsl.com (Postfix) with ESMTP id 804793A67F3 for ; Thu, 20 Jan 2011 12:36:32 -0800 (PST) Received: from lupo.localnet (p5086D399.dip.t-dialin.net [80.134.211.153]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id p0KKdAmO018730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Jan 2011 21:39:13 +0100 From: Thomas Dreibholz Organization: University of Duisburg-Essen, Institute for Experimental Mathematics To: tsvwg@ietf.org Subject: Re: Quick Failover Algorithm in SCTP Date: Thu, 20 Jan 2011 20:43:06 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.37dreibholz; KDE/4.5.5; x86_64; ; ) References: <201101192048.p0JKmYoO012572@sj-core-1.cisco.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1989134.uS3rydOWtQ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201101202043.11228.dreibh@iem.uni-due.de> 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 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 20:36:34 -0000 --nextPart1989134.uS3rydOWtQ Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Mittwoch 19 Januar 2011, David Lehmann wrote: > > >What is the next step in the process? > >=20 > > The status of this ID is that of an individual > > submission, with a target WG of TSVWG. The chairs > > currently believe there has been insufficient > > review within the WG to date to warrant > > progressing this document to the next level. Your > > note obviously helps the chairs determine if > > there is interest in this effort. We thank you > > for the comment. More comments (that show there > > was a review per comment, preferably) will nudge > > us towards reviewing progression of this effort. > >=20 > > Does this seem reasonable? >=20 > Yes. >=20 > Those in favor of this document, please speak up! Dear all, quick SCTP failover is crucial for all time-critical multi-homed applicatio= ns.=20 Particularly, I deploy RSerPool-based SCTP applications in a multi-homed=20 environment. Improved SCTP failover speed reduces the number of expensive=20 session-level failovers in case of network problems. Therefore, I support this document. Best regards =2D-=20 =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 Dr. Thomas Dreibholz University of Duisburg-Essen, Room ES210 Inst. for Experimental Mathematics Ellernstra=DFe 29 Computer Networking Technology Group D-45326 Essen/Germany =2D---------------------------------------------------------------------- E-Mail: dreibh@iem.uni-due.de Homepage: http://www.iem.uni-due.de/~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 --nextPart1989134.uS3rydOWtQ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk04kEwACgkQ32BbsHYPLWU5lwCgmCpSttTYcCAN6oB54sKTEtpm JSUAnR523tHLbcrk9mp0y+t4nOQGuQMJ =YQD0 -----END PGP SIGNATURE----- --nextPart1989134.uS3rydOWtQ-- From lars.eggert@nokia.com Thu Jan 20 23:55:22 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCF523A68E7 for ; Thu, 20 Jan 2011 23:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.05 X-Spam-Level: X-Spam-Status: No, score=-104.05 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yA6K0A-olAh8 for ; Thu, 20 Jan 2011 23:55:22 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id DFE8F3A68D9 for ; Thu, 20 Jan 2011 23:55:21 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0L7w4HY022359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2011 09:58:06 +0200 Subject: Re: Quick Failover Algorithm in SCTP X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-20--538103651; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Fri, 21 Jan 2011 09:57:56 +0200 Message-Id: References: <201101192048.p0JKmYoO012572@sj-core-1.cisco.com> To: David Lehmann X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Fri, 21 Jan 2011 09:58:02 +0200 (EET) X-Nokia-AV: Clean Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 07:55:23 -0000 --Apple-Mail-20--538103651 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2011-1-19, at 22:56, David Lehmann wrote: > Those in favor of this document, please speak up! =20 as AD, let me point out that "speaking up" is not sufficient. If folks want to have the WG adopt it and move it along, *they* will = need to sign up for doing the editing and reviewing work on a continuous = basis. ("Vote by volunteering your own cycles.") Lars= --Apple-Mail-20--538103651 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEyMTA3NTc1NlowIwYJKoZIhvcNAQkE MRYEFGB2Ko3dwZ8AFC/vnkVAvVP9Fj+TMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AFQ1yBJ5sBfIYRuLYV3emCFfpgpuxGL1iD4k0WAYViC7NmTw32HLxw1YpvA+/edbdtWiAgkozAjK RTwQXafxCvf33OFF859qq4eenwlmWjkQoEj+4rL2fCefwmqgPfYjN+azbuhdIq8u8JtfPHDxdI7w tf3PdKcvQpHqJk58BVawgS7W+uFvHGPxiZUvGV9/OmBNRB1UY0y7OUv86wIKNA+4aYYXFrnysOoe mDyIq3dDFcphY9VCnTTKlEdr+TFchGcJG78HBd1JZEve/AP3R8LmtfGBltRwgQgjh9MEtBtrg2oG Q6np6rgX7iyRTmFV/iMEmXjIc5misWznE15gjSsAAAAAAAA= --Apple-Mail-20--538103651-- From randall@lakerest.net Fri Jan 21 02:16:42 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5D633A6902 for ; Fri, 21 Jan 2011 02:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+GbJ2MKeK3d for ; Fri, 21 Jan 2011 02:16:42 -0800 (PST) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by core3.amsl.com (Postfix) with ESMTP id 74C0F3A68F0 for ; Fri, 21 Jan 2011 02:16:41 -0800 (PST) Received: from [10.1.1.105] (bsd3.lakerest.net [70.155.160.101]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id p0LAJJHm029867 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 21 Jan 2011 05:19:24 -0500 (EST) (envelope-from randall@lakerest.net) Subject: Re: Quick Failover Algorithm in SCTP Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Randy Stewart In-Reply-To: Date: Fri, 21 Jan 2011 05:19:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <058D7C6F-10F0-4B95-8513-0D0FCD77E118@lakerest.net> References: <201101192048.p0JKmYoO012572@sj-core-1.cisco.com> To: Lars Eggert X-Mailer: Apple Mail (2.1082) Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 10:16:42 -0000 Lars: You can count on me to review the drafts and send text... in fact I will even one better that.. If adopted as a wg item I will put it into the = FreeBSD SCTP implementation ;-) R On Jan 21, 2011, at 2:57 AM, Lars Eggert wrote: > Hi, >=20 > On 2011-1-19, at 22:56, David Lehmann wrote: >> Those in favor of this document, please speak up! =20 >=20 > as AD, let me point out that "speaking up" is not sufficient. >=20 > If folks want to have the WG adopt it and move it along, *they* will = need to sign up for doing the editing and reviewing work on a continuous = basis. ("Vote by volunteering your own cycles.") >=20 > Lars ----- Randall Stewart randall@lakerest.net From dreibh@iem.uni-due.de Fri Jan 21 02:33:50 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E89CA3A6902 for ; Fri, 21 Jan 2011 02:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrlmZCQEAS8a for ; Fri, 21 Jan 2011 02:33:50 -0800 (PST) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by core3.amsl.com (Postfix) with ESMTP id 9A09E3A6916 for ; Fri, 21 Jan 2011 02:33:48 -0800 (PST) Received: from lupo.localnet ([132.252.151.81]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id p0LAaXbC015347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Jan 2011 11:36:33 +0100 From: Thomas Dreibholz Organization: University of Duisburg-Essen, Institute for Experimental Mathematics To: tsvwg@ietf.org Subject: Re: Quick Failover Algorithm in SCTP Date: Fri, 21 Jan 2011 11:36:27 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.37dreibholz; KDE/4.5.5; x86_64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6421680.tloHngghi3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201101211136.32591.dreibh@iem.uni-due.de> 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 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 10:33:51 -0000 --nextPart6421680.tloHngghi3 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable On Freitag 21 Januar 2011, Lars Eggert wrote: > Hi, >=20 > On 2011-1-19, at 22:56, David Lehmann wrote: > > Those in favor of this document, please speak up! >=20 > as AD, let me point out that "speaking up" is not sufficient. >=20 > If folks want to have the WG adopt it and move it along, *they* will need > to sign up for doing the editing and reviewing work on a continuous basis. > ("Vote by volunteering your own cycles.") Dear Lars, I am also going to review future versions of this document. Best regards =2D-=20 =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 Dr. Thomas Dreibholz University of Duisburg-Essen, Room ES210 Inst. for Experimental Mathematics Ellernstra=DFe 29 Computer Networking Technology Group D-45326 Essen/Germany =2D---------------------------------------------------------------------- E-Mail: dreibh@iem.uni-due.de Homepage: http://www.iem.uni-due.de/~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 --nextPart6421680.tloHngghi3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk05YawACgkQ32BbsHYPLWWVmgCgvMgzcWTGROUQs2jtHHeC5tC8 /UUAoKPwcB9k8g0kLxXF2/e4uD8cdI6S =n5hI -----END PGP SIGNATURE----- --nextPart6421680.tloHngghi3-- From bidulock@openss7.org Fri Jan 21 04:33:17 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8266B3A6955 for ; Fri, 21 Jan 2011 04:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PR9sCuavm1ZK for ; Fri, 21 Jan 2011 04:33:16 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 3DFC23A693C for ; Fri, 21 Jan 2011 04:33:15 -0800 (PST) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0LCZacl002194; Fri, 21 Jan 2011 05:35:37 -0700 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0LCZaHm000407; Fri, 21 Jan 2011 05:35:36 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p0LCZZBS000406; Fri, 21 Jan 2011 05:35:35 -0700 Date: Fri, 21 Jan 2011 05:35:35 -0700 From: "Brian F. G. Bidulock" To: Thomas Dreibholz Subject: Re: Quick Failover Algorithm in SCTP Message-ID: <20110121123535.GA31838@openss7.org> Mail-Followup-To: Thomas Dreibholz , tsvwg@ietf.org, David Lehmann References: <20110120004409.GA32615@openss7.org> <201101202051.44800.dreibh@iem.uni-due.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <201101202051.44800.dreibh@iem.uni-due.de> Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 12:33:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas, Thomas Dreibholz wrote: (Thu, 20 Jan 2011 20:51:43) > > quick failover will actually be part of the full CMT-based approach described > by the document draft-tuexen-tsvwg-sctp-multipath-01.txt. See section 4.3 of > this draft. Without quick failover, CMT-SCTP would try to send on not working > paths for a long time. This would significantly degrade performance. > Two comments: - - draft-nishida-tsvwg-sctp-failover-02 does not support loadsharing and cannot be used for CMT without modification (which was my point). - - under superior CMT approaches, it is the loadsharing algortihm itself that is adjusted based on a number of factors (retransmission peg counts only being one). So, I don't think that draft-nishida-tsvwg-sctp-failover-02 is necessary to proceed with draft-tuexen-tsvwg-sctp-multipath-01: a draft that I would support going forward without so-called non-CMT 'quick-failover' and using instead the superior approaches. To be fair, AFAIK it was never the intentions of draft-nishida-tsvwg- sctp-failover-02 to support CMT, nor to attempt to rival CMT failover approaches: I believe that it was originally intended just to document remedies for a little quicker failover for non-CMT implementations. This was discussed in the 'Quick Failover in SCTP' ladder on TSVWG from March 17-18, 2010. - --brian - -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFNOX2XMYOP2up1d2URAn1uAJ95gFHDRj9/Yvnd7A1icDAJWe5aBgCgt+KO D+Ofg1tg2rGFpJgIKidVqbc= =8IEI -----END PGP SIGNATURE----- From Michael.Tuexen@lurchi.franken.de Fri Jan 21 06:27:06 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ACB83A698F for ; Fri, 21 Jan 2011 06:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dL320PXi9gy9 for ; Fri, 21 Jan 2011 06:27:05 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id A998E3A6984 for ; Fri, 21 Jan 2011 06:27:04 -0800 (PST) Received: from [192.168.1.113] (p508FDBD1.dip.t-dialin.net [80.143.219.209]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 7EC801C0B4606; Fri, 21 Jan 2011 15:29:48 +0100 (CET) Subject: Re: Quick Failover Algorithm in SCTP Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Date: Fri, 21 Jan 2011 15:29:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <49B0136F-6F72-4365-AD42-B1BD4AE79FCB@lurchi.franken.de> References: <201101192048.p0JKmYoO012572@sj-core-1.cisco.com> To: Lars Eggert X-Mailer: Apple Mail (2.1082) Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 14:27:06 -0000 On Jan 21, 2011, at 8:57 AM, Lars Eggert wrote: > Hi, >=20 > On 2011-1-19, at 22:56, David Lehmann wrote: >> Those in favor of this document, please speak up! =20 >=20 > as AD, let me point out that "speaking up" is not sufficient. >=20 > If folks want to have the WG adopt it and move it along, *they* will = need to sign up for doing the editing and reviewing work on a continuous = basis. ("Vote by volunteering your own cycles.") Hi Lars, I already reviewed the document, comments from me were addressed, and = I'm willing to do this in the future. As Randy pointed out, we'll also implement it = in FreeBSD. So I'm willing to continue to work on the document. Best regards Michael >=20 > Lars From dlehmann@ulticom.com Fri Jan 21 14:08:44 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 527753A6803 for ; Fri, 21 Jan 2011 14:08:44 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDF118n+Kde8 for ; Fri, 21 Jan 2011 14:08:43 -0800 (PST) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id 9EAF63A67EC for ; Fri, 21 Jan 2011 14:08:43 -0800 (PST) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id C32F825C45D08246 for ; Fri, 21 Jan 2011 17:11:25 -0500 (EST) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id p0LMBCFI012229 for ; Fri, 21 Jan 2011 17:11:24 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Quick Failover Algorithm in SCTP Date: Fri, 21 Jan 2011 17:11:12 -0500 Message-ID: In-Reply-To: <20110121123535.GA31838@openss7.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Quick Failover Algorithm in SCTP Thread-Index: Acu5Z+BoCOnRhOogQ7i6dPgJlrljHQAT4aLg References: <20110120004409.GA32615@openss7.org> <201101202051.44800.dreibh@iem.uni-due.de> <20110121123535.GA31838@openss7.org> From: "David Lehmann" To: Received-SPF: pass X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 22:08:44 -0000 > To be fair, AFAIK it was never the intentions of draft-nishida-tsvwg- > sctp-failover-02 to support CMT, nor to attempt to rival CMT failover > approaches: I believe that it was originally intended just to document > remedies for a little quicker failover for non-CMT implementations. IMHO, the failover would be significantly quicker. -David From sob@harvard.edu Sat Jan 22 04:29:09 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8769C3A691D for ; Sat, 22 Jan 2011 04:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.156 X-Spam-Level: X-Spam-Status: No, score=-102.156 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Avh1AuCyBbJt for ; Sat, 22 Jan 2011 04:29:08 -0800 (PST) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id AC4C83A6917 for ; Sat, 22 Jan 2011 04:29:08 -0800 (PST) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 10AFB7F785F; Sat, 22 Jan 2011 07:31:56 -0500 (EST) To: tsvwg@ietf.org Subject: Re: Deprecation of ICMP Source Quench messages (draft-gont-tsvwg-source-quench) Message-Id: <20110122123156.10AFB7F785F@newdev.eecs.harvard.edu> Date: Sat, 22 Jan 2011 07:31:56 -0500 (EST) From: sob@harvard.edu (Scott O. Bradner) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 12:29:09 -0000 "Does the WG believe this document effectively addresses an existing problem, and should this draft form the basis for a solution?" yes & yes Scott From yoshifumi.nishida@gmail.com Mon Jan 24 01:51:51 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E62B3A6934 for ; Mon, 24 Jan 2011 01:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.608 X-Spam-Level: X-Spam-Status: No, score=-102.608 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdA+msUWzuqZ for ; Mon, 24 Jan 2011 01:51:49 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id 20F7F3A681B for ; Mon, 24 Jan 2011 01:51:48 -0800 (PST) Received: by wwi17 with SMTP id 17so2987302wwi.1 for ; Mon, 24 Jan 2011 01:54:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=4OcOogqVkVdRF1GaKE95/TGFBqdS3FeeYFPhjwdXS10=; b=O6P2iwdBm2cJq+pmeBf/HUPFiYiltgdtw79wOtXteBEao5cca37//8hv+oxDqPcG78 kSm910G+cCsbSHFgrDbzZPxsBFtxhxQQR6CC+ECeXFro28U2NDQyJ2H8coDO52WnVTXF dYTaojc2fe0nXUw3HYv5EPZwkIfbkdU4Igd08= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=RqvZlDtrvhenHD/xa9SMpXA18660jDbj1rx489D3puf2N7ndxlWR+AcgPUkMuBkBHP 3lTu+USag9oIEJDKiP45wI68CGS3p6TvaYDRycaYxBEm7ymSPmQGXrHrhJ+q3Ep9aw9R Zfr1QoXrHdz6Otw26sMaAF50dF1Q0RPz2xg0U= MIME-Version: 1.0 Received: by 10.216.18.83 with SMTP id k61mr3218592wek.91.1295862882749; Mon, 24 Jan 2011 01:54:42 -0800 (PST) Sender: yoshifumi.nishida@gmail.com Received: by 10.216.170.199 with HTTP; Mon, 24 Jan 2011 01:54:42 -0800 (PST) In-Reply-To: <20110121123535.GA31838@openss7.org> References: <20110120004409.GA32615@openss7.org> <201101202051.44800.dreibh@iem.uni-due.de> <20110121123535.GA31838@openss7.org> Date: Mon, 24 Jan 2011 01:54:42 -0800 X-Google-Sender-Auth: MrrohlqETi74pWLtjX_cP_y2BFk Message-ID: Subject: Re: Quick Failover Algorithm in SCTP From: Yoshifumi Nishida To: bidulock@openss7.org, tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 09:51:51 -0000 Hello Brian, I believe we both agree failover is an important issue. I guess the problem is how we solve it. You don't prefer this approach since you know better one, which is fine to me. However, I would like to understand what is superior approach so that I can think about it throughly. Also, I would like to know if it's going to be standardized. I would like to avoid leaving this issue without doing anything. I hope you'll agree this part. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/1/21 Brian F. G. Bidulock : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Thomas, > > Thomas Dreibholz wrote: =A0 =A0 =A0 =A0 =A0 =A0 =A0(Thu, 20 Jan 2011 20:5= 1:43) >> >> quick failover will actually be part of the full CMT-based approach desc= ribed >> by the document draft-tuexen-tsvwg-sctp-multipath-01.txt. See section 4.= 3 of >> this draft. Without quick failover, CMT-SCTP would try to send on not wo= rking >> paths for a long time. This would significantly degrade performance. >> > > Two comments: > > - - draft-nishida-tsvwg-sctp-failover-02 does not support loadsharing and > =A0cannot be used for CMT without modification (which was my point). > > - - under superior CMT approaches, it is the loadsharing algortihm itself > =A0that is adjusted based on a number of factors (retransmission peg > =A0counts only being one). > > So, I don't think that draft-nishida-tsvwg-sctp-failover-02 is necessary > to proceed with draft-tuexen-tsvwg-sctp-multipath-01: a draft that I > would support going forward without so-called non-CMT 'quick-failover' > and using instead the superior approaches. > > To be fair, AFAIK it was never the intentions of draft-nishida-tsvwg- > sctp-failover-02 to support CMT, nor to attempt to rival CMT failover > approaches: I believe that it was originally intended just to document > remedies for a little quicker failover for non-CMT implementations. > > This was discussed in the 'Quick Failover in SCTP' ladder on TSVWG > from March 17-18, 2010. > > - --brian > > - -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iD8DBQFNOX2XMYOP2up1d2URAn1uAJ95gFHDRj9/Yvnd7A1icDAJWe5aBgCgt+KO > D+Ofg1tg2rGFpJgIKidVqbc=3D > =3D8IEI > -----END PGP SIGNATURE----- > From bidulock@openss7.org Mon Jan 24 04:40:05 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAA1A3A684E for ; Mon, 24 Jan 2011 04:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCMt3On3wKmt for ; Mon, 24 Jan 2011 04:40:04 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 9CECC3A6839 for ; Mon, 24 Jan 2011 04:40:04 -0800 (PST) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0OCgvnu011677; Mon, 24 Jan 2011 05:42:58 -0700 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0OCgv3c004427; Mon, 24 Jan 2011 05:42:57 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p0OCgvrN004426; Mon, 24 Jan 2011 05:42:57 -0700 Date: Mon, 24 Jan 2011 05:42:57 -0700 From: "Brian F. G. Bidulock" To: Yoshifumi Nishida Subject: Re: Quick Failover Algorithm in SCTP Message-ID: <20110124124257.GA16311@openss7.org> Mail-Followup-To: Yoshifumi Nishida , tsvwg@ietf.org References: <20110120004409.GA32615@openss7.org> <201101202051.44800.dreibh@iem.uni-due.de> <20110121123535.GA31838@openss7.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 12:40:05 -0000 Yoshifumi, I believe we already had this discussion. See the thread starting with: http://www.ietf.org/mail-archive/web/tsvwg/current/msg09912.html If there is something you didn't understand from the previous discussion, please feel free to ask away. --brian Yoshifumi Nishida wrote: (Mon, 24 Jan 2011 01:54:42) > Hello Brian, > > I believe we both agree failover is an important issue. > I guess the problem is how we solve it. You don't prefer this approach > since you know better one, which is fine to me. However, I would like > to understand what is superior approach so that I can think about it > throughly. Also, I would like to know if it's going to be > standardized. > > I would like to avoid leaving this issue without doing anything. I > hope you'll agree this part. > > Thanks, > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From matt@linuxbox.com Mon Jan 24 11:03:03 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DE733A67AD for ; Mon, 24 Jan 2011 11:03:03 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48ecjuXcnWaD for ; Mon, 24 Jan 2011 11:03:02 -0800 (PST) Received: from aa.linuxbox.com (aa.linuxbox.com [134.215.213.37]) by core3.amsl.com (Postfix) with ESMTP id 393863A6B2A for ; Mon, 24 Jan 2011 11:03:02 -0800 (PST) Received: from thunderbeast.private.linuxbox.com (thunderbeast.private.linuxbox.com [10.1.1.55]) by aa.linuxbox.com (8.13.1/8.13.1/SuSE Linux 0.7) with ESMTP id p0OJ5tpd010733; Mon, 24 Jan 2011 14:05:55 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by thunderbeast.private.linuxbox.com (Postfix) with ESMTP id DB4013FC83AA; Mon, 24 Jan 2011 14:05:54 -0500 (EST) X-Virus-Scanned: amavisd-new at linuxbox.com Received: from thunderbeast.private.linuxbox.com ([127.0.0.1]) by localhost (thunderbeast.private.linuxbox.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuYhjgS2ZgnW; Mon, 24 Jan 2011 14:05:49 -0500 (EST) Received: from thunderbeast.private.linuxbox.com (thunderbeast.private.linuxbox.com [10.1.1.55]) by thunderbeast.private.linuxbox.com (Postfix) with ESMTP id A85C73FC83A9; Mon, 24 Jan 2011 14:05:49 -0500 (EST) Date: Mon, 24 Jan 2011 14:05:49 -0500 (EST) From: "Matt W. Benjamin" To: bidulock@openss7.org Message-ID: <1303619278.71.1295895949464.JavaMail.root@thunderbeast.private.linuxbox.com> In-Reply-To: <20110124124257.GA16311@openss7.org> Subject: Re: Quick Failover Algorithm in SCTP MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.52] X-Mailer: Zimbra 6.0.5_GA_2180.CentOS5_64 (ZimbraWebClient - FF3.0 (Linux)/6.0.5_GA_2180.CentOS5_64) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (aa.linuxbox.com [10.1.1.1]); Mon, 24 Jan 2011 14:05:56 -0500 (EST) Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 19:03:03 -0000 Hi, I'm completely an observer and not an SCTP protocol implementer. As a distributed file systems developer, I have been interested in SCTP and in particular, CMT, since 2007. I'm finding it difficult to track the discussion completely. Is it in fact the case that the openss7 CMT is not interoperable with that in FreeBSD? That now seems implied. What process of interop testing or mutual design review, if any, has been attempted on them thus far? Does the openss7 team presently have a research obligation (or opportunity)? Am I missing more context? Thanks, and sorry for any distraction. Matt ----- "Brian F. G. Bidulock" wrote: > Yoshifumi, > > I believe we already had this discussion. See the thread starting > with: > > http://www.ietf.org/mail-archive/web/tsvwg/current/msg09912.html > > If there is something you didn't understand from the previous > discussion, > please feel free to ask away. > > --brian > > Yoshifumi Nishida wrote: (Mon, 24 Jan 2011 > 01:54:42) > > Hello Brian, > > > > I believe we both agree failover is an important issue. > > I guess the problem is how we solve it. You don't prefer this > approach > > since you know better one, which is fine to me. However, I would > like > > to understand what is superior approach so that I can think about > it > > throughly. Also, I would like to know if it's going to be > > standardized. > > > > I would like to avoid leaving this issue without doing anything. I > > hope you'll agree this part. > > > > Thanks, > > -- > > Yoshifumi Nishida > > nishida@sfc.wide.ad.jp > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 From bidulock@openss7.org Mon Jan 24 13:51:37 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B1B63A699C for ; Mon, 24 Jan 2011 13:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNAitAVWUdxF for ; Mon, 24 Jan 2011 13:51:34 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 1110A3A68EE for ; Mon, 24 Jan 2011 13:51:33 -0800 (PST) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0OLsTPt021213; Mon, 24 Jan 2011 14:54:29 -0700 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0OLsRxa014618; Mon, 24 Jan 2011 14:54:28 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p0OLsPAK014617; Mon, 24 Jan 2011 14:54:25 -0700 Date: Mon, 24 Jan 2011 14:54:25 -0700 From: "Brian F. G. Bidulock" To: "Matt W. Benjamin" Subject: Re: Quick Failover Algorithm in SCTP Message-ID: <20110124215425.GC13744@openss7.org> Mail-Followup-To: "Matt W. Benjamin" , tsvwg@ietf.org, Yoshifumi Nishida References: <20110124124257.GA16311@openss7.org> <1303619278.71.1295895949464.JavaMail.root@thunderbeast.private.linuxbox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1303619278.71.1295895949464.JavaMail.root@thunderbeast.private.linuxbox.com> Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 21:51:37 -0000 Matt, Matt W. Benjamin wrote: (Mon, 24 Jan 2011 14:05:49) > Hi, > > I'm completely an observer and not an SCTP protocol implementer. As a > distributed file systems developer, I have been interested in SCTP and > in particular, CMT, since 2007. I'm finding it difficult to track the > discussion completely. Welcome to the wunnerful world of SCTP! If CMT is of interest to you Thomas' conference should be of special interest: http://www.tdr.wiwi.uni-due.de/en/workshops/pams-2001 > Is it in fact the case that the openss7 CMT is not interoperable with > that in FreeBSD? That now seems implied. Our implementation and many other implementations successfully interop tested with FreeBSD from the 2nd SCTP plugtest in 2001 in Sophia Antipolis through the 6th in Vancouver and beyond. Are you saying that FreeBSD implemented something recently that was not interoperable with other implementations? I wouldn't believe it. > What process of interop testing or mutual design review, if any, has > been attempted on them thus far? A wide range of SCTP implementations (many more than just FreeBSD and OpenSS7) have been tested at SCTP plugtests and interoperability events over the past 10 years. Many have also been the thesis of a number of post-graduate degrees and the subject of many research papers. > Does the openss7 team presently have a research obligation (or > opportunity)? You can contact me off-list if you have an opportunity to offer. > Am I missing more context? Probably. It is considered bad form to review or promote specific implementations on an IETF list. I cannot help you here with the process of software selection: I can only discuss techniques as they apply to the SCTP protocol. I am thinking that maybe you didn't intend to send this note to the WG list. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From matt@linuxbox.com Mon Jan 24 14:21:38 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CDD23A697B for ; Mon, 24 Jan 2011 14:21:38 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KG1h0-GnU8T for ; Mon, 24 Jan 2011 14:21:37 -0800 (PST) Received: from aa.linuxbox.com (aa.linuxbox.com [134.215.213.37]) by core3.amsl.com (Postfix) with ESMTP id 39A433A682C for ; Mon, 24 Jan 2011 14:21:37 -0800 (PST) Received: from thunderbeast.private.linuxbox.com (thunderbeast.private.linuxbox.com [10.1.1.55]) by aa.linuxbox.com (8.13.1/8.13.1/SuSE Linux 0.7) with ESMTP id p0OMOVIc012278; Mon, 24 Jan 2011 17:24:31 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by thunderbeast.private.linuxbox.com (Postfix) with ESMTP id 048883FC83AA; Mon, 24 Jan 2011 17:24:31 -0500 (EST) X-Virus-Scanned: amavisd-new at linuxbox.com Received: from thunderbeast.private.linuxbox.com ([127.0.0.1]) by localhost (thunderbeast.private.linuxbox.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eRebsRP1ba2; Mon, 24 Jan 2011 17:24:29 -0500 (EST) Received: from thunderbeast.private.linuxbox.com (thunderbeast.private.linuxbox.com [10.1.1.55]) by thunderbeast.private.linuxbox.com (Postfix) with ESMTP id C69A33FC83A9; Mon, 24 Jan 2011 17:24:29 -0500 (EST) Date: Mon, 24 Jan 2011 17:24:29 -0500 (EST) From: "Matt W. Benjamin" To: bidulock@openss7.org Message-ID: <175320877.159.1295907869519.JavaMail.root@thunderbeast.private.linuxbox.com> In-Reply-To: <20110124215425.GC13744@openss7.org> Subject: Re: Quick Failover Algorithm in SCTP MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.52] X-Mailer: Zimbra 6.0.5_GA_2180.CentOS5_64 (ZimbraWebClient - FF3.0 (Linux)/6.0.5_GA_2180.CentOS5_64) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (aa.linuxbox.com [10.1.1.1]); Mon, 24 Jan 2011 17:24:31 -0500 (EST) Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 22:21:38 -0000 Hi, Apologies, it was not my intention to compare implementations in this sense. I was not trying to discuss commercial opportunities either, just trying to better understand the discussion. I am certain that I still don't, but I'm making it worse. Thanks (and sorry), Matt ----- "Brian F. G. Bidulock" wrote: > > Probably. It is considered bad form to review or promote specific > implementations on an IETF list. I cannot help you here with the > process > of software selection: I can only discuss techniques as they apply to > the SCTP protocol. > > I am thinking that maybe you didn't intend to send this note to the > WG list. > > --brian > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 From jmpolk@cisco.com Mon Jan 24 17:28:15 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACDD13A6B46 for ; Mon, 24 Jan 2011 17:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.527 X-Spam-Level: X-Spam-Status: No, score=-110.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFUo4HWmKJ7R for ; Mon, 24 Jan 2011 17:28:15 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id F0F9E3A6847 for ; Mon, 24 Jan 2011 17:28:14 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKK2PU2rR7Ht/2dsb2JhbACka3OgIZsyhVAEhHA Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 25 Jan 2011 01:31:11 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8716.cisco.com [10.99.80.23]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0P1VA5A001374 for ; Tue, 25 Jan 2011 01:31:11 GMT Message-Id: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 24 Jan 2011 19:31:09 -0600 To: tsvwg From: "James M. Polk" Subject: Quick Failover Algorithm in SCTP - question for the WG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 01:28:15 -0000 (with my chair hat on) ISTM that the WG has to answer the following question before either this "-nishida-" ID or the "-tuexen-...-multipath-" ID progress (and if either does): Does the WG feel CMT needs to be accounted for (or involved) in whatever the solution is here? I'm posing this more informally to the WG, but how I, as chair, take the answer to this question can get more formal based on the answers given (including if no one answers this question). Why do I pose this? ITSM the "-nishida-" ID address the problem area, but "-tuexen-...-multipath-" ID addresses a superset of the problem area. If I've mischaracterized this - please correct me concisely. The WG doesn't need to be a book of an response, as that'll likely confuse more of the WG... James (again, with my chair hat on) From bidulock@openss7.org Mon Jan 24 19:34:57 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C8523A6B73 for ; Mon, 24 Jan 2011 19:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocYWoVLNsOid for ; Mon, 24 Jan 2011 19:34:56 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 0DDB73A6B6C for ; Mon, 24 Jan 2011 19:34:55 -0800 (PST) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0P3bnxO026912; Mon, 24 Jan 2011 20:37:49 -0700 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0P3bm8F019068; Mon, 24 Jan 2011 20:37:49 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p0P3bmG3019067; Mon, 24 Jan 2011 20:37:48 -0700 Date: Mon, 24 Jan 2011 20:37:48 -0700 From: "Brian F. G. Bidulock" To: "James M. Polk" Subject: Re: Quick Failover Algorithm in SCTP - question for the WG Message-ID: <20110125033748.GA12979@openss7.org> Mail-Followup-To: "James M. Polk" , tsvwg References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: tsvwg X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 03:34:57 -0000 James, IMHO the sctp-multipath draft addresses the problem area and the sctp-failover draft attempts to isolate one aspect that cannot be isolated. So, IMO, any solution needs to account for or involve loadsharing (CMT or otherwise). --brian James M. Polk wrote: (Mon, 24 Jan 2011 19:31:09) > (with my chair hat on) > > ISTM that the WG has to answer the following question before either this > "-nishida-" ID or the "-tuexen-...-multipath-" ID progress (and if either > does): > > Does the WG feel CMT needs to be accounted for (or involved) in > whatever the solution is here? > > I'm posing this more informally to the WG, but how I, as chair, take the > answer to this question can get more formal based on the answers given > (including if no one answers this question). > > Why do I pose this? > > ITSM the "-nishida-" ID address the problem area, but > "-tuexen-...-multipath-" ID addresses a superset of the problem area. > > If I've mischaracterized this - please correct me concisely. The WG > doesn't need to be a book of an response, as that'll likely confuse more > of the WG... > > James > (again, with my chair hat on) -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From yoshifumi.nishida@gmail.com Tue Jan 25 00:22:11 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 727553A6A30 for ; Tue, 25 Jan 2011 00:22:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.624 X-Spam-Level: X-Spam-Status: No, score=-102.624 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GC+CuZ6eYvGq for ; Tue, 25 Jan 2011 00:22:10 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 3B7023A6964 for ; Tue, 25 Jan 2011 00:22:10 -0800 (PST) Received: by wyf23 with SMTP id 23so5396789wyf.31 for ; Tue, 25 Jan 2011 00:25:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lZF/FNNV2s2H85X4DEraWqtsuT6zmlpfWdqrYijA0hI=; b=tIud0jHQFDxf/yXAcPSLQUuEqj3/FSy2QCACIr6H8KpAGrgQsRTmVEt7NqzHR1007Y ZgGj3UqA5twt4QQAzOJHpc3dQjuZZSwb4GwvAwJEsam/4NCN6+/+PAF0gYJz00T9gY79 HrHx3eD2wmlHlOGBBbCG8JkSCEnFt0IV9fa6w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=cNV99ZoHy8GwmB62JNUjHfndzck/lnTeReNsEmjND3KdoE9b044spzGa23JFvJyqtx fUPG5qKdZj5lxh2667eOAIyV5v0lP6Nl/mMeU5GSbZ2U38xyotOrYGVdBexsxiSxzPV0 W9YIEBvTmfFXx87S6Kap0+dE/iboZFvuKRwcE= MIME-Version: 1.0 Received: by 10.216.241.11 with SMTP id f11mr3295137wer.76.1295943906741; Tue, 25 Jan 2011 00:25:06 -0800 (PST) Sender: yoshifumi.nishida@gmail.com Received: by 10.216.170.199 with HTTP; Tue, 25 Jan 2011 00:25:06 -0800 (PST) In-Reply-To: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> Date: Tue, 25 Jan 2011 00:25:06 -0800 X-Google-Sender-Auth: Jjozn0igSiW5hMNhKLhBLWg2Ksg Message-ID: Subject: Re: Quick Failover Algorithm in SCTP - question for the WG From: Yoshifumi Nishida To: "James M. Polk" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tsvwg X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 08:22:11 -0000 Hello James, I think the slides Jana used in his presentation at Maastricht characterizes this well. (http://tools.ietf.org/agenda/78/slides/tsvwg-2.pdf) At least, it's my characterization for this one. Also, sctp-failover can be applied to RFC4960 in addition to CMT. (which might make things complicated? but I believe it's useful.) Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/1/24 James M. Polk : > (with my chair hat on) > > ISTM that the WG has to answer the following question before either this > "-nishida-" ID or the "-tuexen-...-multipath-" ID progress (and if either > does): > > =A0Does the WG feel CMT needs to be accounted for (or involved) in > =A0whatever the solution is here? > > I'm posing this more informally to the WG, but how I, as chair, take the > answer to this question can get more formal based on the answers given > (including if no one answers this question). > > Why do I pose this? > > ITSM the "-nishida-" ID address the problem area, but > "-tuexen-...-multipath-" ID addresses a superset of the problem area. > > If I've mischaracterized this - please correct me concisely. The WG doesn= 't > need to be a book of an response, as that'll likely confuse more of the > WG... > > James > (again, with my chair hat on) > > From dreibh@iem.uni-due.de Tue Jan 25 02:10:00 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 803B43A67D2 for ; Tue, 25 Jan 2011 02:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.382 X-Spam-Level: X-Spam-Status: No, score=-1.382 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lqBH1KRe8xw for ; Tue, 25 Jan 2011 02:09:59 -0800 (PST) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by core3.amsl.com (Postfix) with ESMTP id 583F73A6B8D for ; Tue, 25 Jan 2011 02:09:59 -0800 (PST) Received: from kappes.localnet ([132.252.151.80]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id p0PACsPq032623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Jan 2011 11:12:54 +0100 From: Thomas Dreibholz Organization: University of Duisburg-Essen, Institute for Experimental Mathematics To: tsvwg@ietf.org, bidulock@openss7.org Subject: Re: Quick Failover Algorithm in SCTP / SCTP Interops Date: Tue, 25 Jan 2011 11:12:49 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.35-24-generic; KDE/4.5.5; x86_64; ; ) References: <20110124124257.GA16311@openss7.org> <1303619278.71.1295895949464.JavaMail.root@thunderbeast.private.linuxbox.com> <20110124215425.GC13744@openss7.org> In-Reply-To: <20110124215425.GC13744@openss7.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1403776.CTqCvChZvU"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201101251112.54029.dreibh@iem.uni-due.de> 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 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 10:10:00 -0000 --nextPart1403776.CTqCvChZvU Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, On Montag 24 Januar 2011, Brian F. G. Bidulock wrote: > Matt, >=20 > Matt W. Benjamin wrote: (Mon, 24 Jan 2011 14:05:49) >=20 > > Hi, > >=20 > > I'm completely an observer and not an SCTP protocol implementer. As a > > distributed file systems developer, I have been interested in SCTP and > > in particular, CMT, since 2007. I'm finding it difficult to track the > > discussion completely. >=20 > Welcome to the wunnerful world of SCTP! If CMT is of interest to you > Thomas' conference should be of special interest: >=20 > http://www.tdr.wiwi.uni-due.de/en/workshops/pams-2001 The URL of the PAMS 2011 is http://www.tdr.wiwi.uni- due.de/en/workshops/pams-2011/ . > > Is it in fact the case that the openss7 CMT is not interoperable with > > that in FreeBSD? That now seems implied. >=20 > Our implementation and many other implementations successfully interop > tested with FreeBSD from the 2nd SCTP plugtest in 2001 in Sophia > Antipolis through the 6th in Vancouver and beyond. Are you saying that > FreeBSD implemented something recently that was not interoperable with > other implementations? I wouldn't believe it. >=20 > > What process of interop testing or mutual design review, if any, has > > been attempted on them thus far? >=20 > A wide range of SCTP implementations (many more than just FreeBSD and > OpenSS7) have been tested at SCTP plugtests and interoperability events > over the past 10 years. Many have also been the thesis of a number of > post-graduate degrees and the subject of many research papers. I have looked up the previous SCTP interops. There have been 9 SCTP interop= s=20 to far: 1. Munich, June 2000 2. Research Triangle Park, October 2000 3. Sophia Antilopis, April 2001 4. San Jose, February 2002 5. Essen, September 2002 6. Newark, June 2003 7. M=FCnster, July 2004 8. Vancouver, July 2006 9. Kyoto, August 2007 That is, the last interop has been organized 3.5 years ago.=20 Is there any interest in another interop meeting, in order to test up to da= te=20 features? Particularly, newer things like CMT-SCTP, NR-SACK, SACK Immediate= ly,=20 Stream Reset, PKTDROP, UDP Encapsulation, NAT Traversal, etc. could be test= ed. As already offered at the last interop, a further interop could again be=20 organized at the University of Essen. Best regards =2D-=20 =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 Dr. Thomas Dreibholz University of Duisburg-Essen, Room ES210 Inst. for Experimental Mathematics Ellernstra=DFe 29 Computer Networking Technology Group D-45326 Essen/Germany =2D---------------------------------------------------------------------- E-Mail: dreibh@iem.uni-due.de Homepage: http://www.iem.uni-due.de/~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 --nextPart1403776.CTqCvChZvU Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk0+oiIACgkQ32BbsHYPLWWTuwCg24AAEU8ACRnNmikx1z6nBB8C 5N8AoIfKj2Ax2V5G+srsBR87jvW6IHs0 =0NAK -----END PGP SIGNATURE----- --nextPart1403776.CTqCvChZvU-- From evnikita2@gmail.com Tue Jan 25 03:04:40 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D32443A6BA2 for ; Tue, 25 Jan 2011 03:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQ-X4UYF9AlB for ; Tue, 25 Jan 2011 03:04:40 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id B7E973A6B9F for ; Tue, 25 Jan 2011 03:04:39 -0800 (PST) Received: by fxm9 with SMTP id 9so5583006fxm.31 for ; Tue, 25 Jan 2011 03:07:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type; bh=Cqxuvp2CBpl/gRm1xPB/dvPJjA5RBMIM4dEjcOJorpI=; b=Cmok4jjMaSrvEiw4DjaYL6T/3ZEYg+izrghV/dtu/MxoGJ9TY920dol5cko98Lswov 3u+8phGIMsxul98/9FXPbW7o7uBuWleVe79QHOMWJQ6C9wVtjVXOaI1pS73cbwRkflKI KKh6ZW+dgZVdAd+fTV+AfGavlKay48cgDsms4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; b=sCeskL3tVJSGXjVMxypwiyp2BxdOF/bxnTl+s+Vf9Mc+cDAuXvfYPcWyx/WwuhSBkh U7gWjZLX4BMkZkAc3gfp4qGPo3Wb8K7VVqDxDHRjZBbBWaoxZBjtAwW5/VJKj7f9jgdF soe3fICr8G/IE28nTvM1lZ1ALx2+KB2JtBC+0= Received: by 10.223.85.204 with SMTP id p12mr5638192fal.146.1295953656012; Tue, 25 Jan 2011 03:07:36 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id n15sm4978256fam.12.2011.01.25.03.07.34 (version=SSLv3 cipher=RC4-MD5); Tue, 25 Jan 2011 03:07:35 -0800 (PST) Message-ID: <4D3EAF0D.5080800@gmail.com> Date: Tue, 25 Jan 2011 13:07:57 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "tsvwg@ietf.org" Subject: New version of draft-yevstifeyev-eudp Content-Type: multipart/alternative; boundary="------------060106070904060706010704" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 11:04:40 -0000 This is a multi-part message in MIME format. --------------060106070904060706010704 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello all, If you may remember, nearly at the beginning of December I introduces the /draft-yevstifeyev-eudp/ defining a new protocol - EUDP. However during the discussion a number of issues were raised by WG members. The new version I've just submitted - 05 - is considered by me to resolve most of these issues. The list of diffs are available here: http://tools.ietf.org/rfcdiff?url2=draft-yevstifeyev-eudp-05. Among other, added the possibility to negotiate the use of options, that I was pointed to at the same start of discussion. Secondly, I added the possibility to request the acknowledgment of single packet. But the most significant change is that now EUDP is not a separate protocol, but an addition to UDP. You may find more information in Section 2 of /draft-yevstifeyev-eudp. /You may feel free to submit any further comments as well as any other propositions. All the best, Mykyta Yevstifeyev P.S. The link to the draft is http://tools.ietf.org/html/draft-yevstifeyev-eudp-05. Mykyta. --------------060106070904060706010704 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello all,

If you may remember, nearly at the beginning of December I introduces the draft-yevstifeyev-eudp defining a new protocol - EUDP.  However during the discussion a number of issues were raised by WG members.  The new version I've just submitted - 05 - is considered by me to resolve most of these issues.

The list of diffs are available here: http://tools.ietf.org/rfcdiff?url2=draft-yevstifeyev-eudp-05.  Among other, added the possibility to negotiate the use of options, that I was pointed to at the same start of discussion.  Secondly, I added the possibility to request the acknowledgment of single packet.  But the most significant change is that now EUDP is not a separate protocol, but an addition to UDP.  You may find more information in Section 2 of
draft-yevstifeyev-eudp.

You may feel free to submit any further comments as well as any other propositions.

All the best,
Mykyta Yevstifeyev

P.S. The link to the draft is http://tools.ietf.org/html/draft-yevstifeyev-eudp-05. Mykyta.
--------------060106070904060706010704-- From ka-cheong.poon@oracle.com Tue Jan 25 03:05:43 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90D643A6BA7 for ; Tue, 25 Jan 2011 03:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.321 X-Spam-Level: X-Spam-Status: No, score=-6.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSvcpct5stKH for ; Tue, 25 Jan 2011 03:05:42 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 8B40C3A6BA5 for ; Tue, 25 Jan 2011 03:05:42 -0800 (PST) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p0PB8cDb022532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 25 Jan 2011 11:08:39 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p0P9PQLv027374 for ; Tue, 25 Jan 2011 11:08:38 GMT Received: from abhmt016.oracle.com by acsmt354.oracle.com with ESMTP id 989802951295953686; Tue, 25 Jan 2011 03:08:06 -0800 Received: from [10.7.251.223] (/10.7.251.223) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 Jan 2011 03:08:06 -0800 Message-ID: <4D3EAF12.4050100@oracle.com> Date: Tue, 25 Jan 2011 19:08:02 +0800 From: Kacheong Poon User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.13) Gecko/20101209 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: Quick Failover Algorithm in SCTP - question for the WG References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> In-Reply-To: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 11:05:43 -0000 On 01/25/11 09:31 AM, James M. Polk wrote: > (with my chair hat on) > > ISTM that the WG has to answer the following question before either this > "-nishida-" ID or the "-tuexen-...-multipath-" ID progress (and if > either does): > > Does the WG feel CMT needs to be accounted for (or involved) in > whatever the solution is here? I think the ID "-nishida-" can be considered as "implementation details." The reason is that RFC 4960 does not prohibit a stack from doing quick failover. And as David pointed out before, there are existing stacks which do it already. Doing it does not require co-operation from the receiver side. There is not much side effect (should not introduce congestion for example) on the network as communication between the end points is still on one path. Hence it is not necessary for the WG to standardize a mechanism. Note that I am not objecting to such as effort, just that it is not necessary IMHO. OTHO, doing CMT properly and efficiently probably requires co- operation from the receiver side. As mentioned in the "-tuexen-... -multipath-" ID, there are a couple obvious issues in doing CMT in "standard" SCTP impl. While things like avoiding false fast retransmission may be mitigated on the sender side alone (albeit a little bit inefficiently), things like delaying SACK require receiver side changes. It is a good idea if there are new protocol features to facilitate CMT on both sides. And since CMT can have side effect on the network, it is important for this WG to evaluate it. Hence IMHO it is necessary to standardize CMT by this WG. > I'm posing this more informally to the WG, but how I, as chair, take the > answer to this question can get more formal based on the answers given > (including if no one answers this question). > > Why do I pose this? > > ITSM the "-nishida-" ID address the problem area, but > "-tuexen-...-multipath-" ID addresses a superset of the problem area. > > If I've mischaracterized this - please correct me concisely. The WG > doesn't need to be a book of an response, as that'll likely confuse more > of the WG... I think they can be separated. Ideally, an app can choose how an SCTP stack utilizes the different paths. If an app just wants to use one path (say because alternate paths are expensive to use), quick failover is applicable. If an app wants to utilizes all paths simultaneously, CMT is used and how to do retransmission becomes part of the CMT algorithm. -- K. Poon. ka-cheong.poon@oracle.com From lars.eggert@nokia.com Tue Jan 25 03:10:11 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21BB43A6BA4; Tue, 25 Jan 2011 03:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.974 X-Spam-Level: X-Spam-Status: No, score=-103.974 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeyEVTm3AcEp; Tue, 25 Jan 2011 03:10:10 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 560233A6B9D; Tue, 25 Jan 2011 03:10:10 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0PBD5Hs008482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jan 2011 13:13:06 +0200 Subject: Re: tsv-dir review of draft-ietf-tsvwg-iana-ports-09 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-25--180802301; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Tue, 25 Jan 2011 13:12:57 +0200 Message-Id: References: To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Tue, 25 Jan 2011 13:13:02 +0200 (EET) X-Nokia-AV: Clean Cc: TSV Area , tsvwg IETF list , "draft-ietf-tsvwg-iana-ports@tools.ietf.org" , TSV Dir X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 11:10:11 -0000 --Apple-Mail-25--180802301 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I'm updating the working copy in response to the LC reviews. See below = for how I'm addressing things. On 2011-1-19, at 22:54, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] = wrote: > A few small comments which I don't think should be blocking are: >=20 > 1 - on page 11, in section 6, "near-infinite" is a bit of an = exaggeration Changed to "very many". > 2 - on page 16, there's a typo: "MUST accompanied" should be "MUST be = accompanied" Was already fixed in our working copy. > 3 - on page 17, it may be a good idea to be clear whether the Assignee = can be an individual (not just an organization) Fixed. (Alexey had commented on that, too.) > 4 - on page 17, Contact is defined as a person, but using the IESG as = the Contact makes it a group (not a "person"); it might be good to = clarify Contact as a person or group of people I actually think we want the contact to be *one* person. I propose to = fix this by making the IETF Chair the contact person for IETF = registrations assigned to the IESG. > 5 - on page 17, in the Reference definition, it may be good to qualify = the description of broadcast/multicast/anycast use by the protocol as = being IP-layer broadcast/multicast/anycast to disambiguate from possible = application-layer mechanisms for these that might be used Fixed. Thanks, Lars= --Apple-Mail-25--180802301 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEyNTExMTI1N1owIwYJKoZIhvcNAQkE MRYEFDXLTKQZTmYSLTTm2Se3qiTZ1vRlMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AGF5G/fzlniI+HPIKTk4olq8ZDRD7PhdOSqlsJL5hsteXwV4ohiACq2FdEr1Uz9Ttrq511WDX3++ DAt9Ks8ZZjRsbZJE8/WrC5WDN5S7D53hK2I+Y2mOs1AssQlk7BFTWgx7MYzrKStuByhXy4WsqTvX HqqJX931ugfGxwJKRNRuVzD4/qhJreYx++mf07WOStyoKN5fwMZGWAQaMHtrEbHHroneX9tVH0eX VjT8bnJaiKHXkoZMQz8Cmmsxay9i2R98iGqEHmX49C9j5te0IYUVE7DvZ4XSNhusaZd6maMmwswG kwIY/q4uwjmwdzOb3QBxv2Dde/WqCkDEeWm9dhEAAAAAAAA= --Apple-Mail-25--180802301-- From jmpolk@cisco.com Tue Jan 25 11:13:51 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 851133A6859 for ; Tue, 25 Jan 2011 11:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.51 X-Spam-Level: X-Spam-Status: No, score=-110.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iav-1Q58uaJ for ; Tue, 25 Jan 2011 11:13:50 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id B0E093A6876 for ; Tue, 25 Jan 2011 11:13:50 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD+wPk2rRN+J/2dsb2JhbACkcnOgdJtHhU8EhRc Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 25 Jan 2011 19:16:49 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8716.cisco.com [10.99.80.23]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p0PJGm76021999; Tue, 25 Jan 2011 19:16:48 GMT Message-Id: <201101251916.p0PJGm76021999@sj-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 25 Jan 2011 13:16:35 -0600 To: Kacheong Poon , tsvwg@ietf.org From: "James M. Polk" Subject: Re: Quick Failover Algorithm in SCTP - question for the WG In-Reply-To: <4D3EAF12.4050100@oracle.com> References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <4D3EAF12.4050100@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 19:13:51 -0000 in-line below At 05:08 AM 1/25/2011, Kacheong Poon wrote: >On 01/25/11 09:31 AM, James M. Polk wrote: >>(with my chair hat on) >> >>ISTM that the WG has to answer the following question before either this >>"-nishida-" ID or the "-tuexen-...-multipath-" ID progress (and if >>either does): >> >>Does the WG feel CMT needs to be accounted for (or involved) in >>whatever the solution is here? > > >I think the ID "-nishida-" can be considered as "implementation >details." The reason is that RFC 4960 does not prohibit a stack >from doing quick failover. And as David pointed out before, there >are existing stacks which do it already. Doing it does not require >co-operation from the receiver side. There is not much side effect >(should not introduce congestion for example) on the network as >communication between the end points is still on one path. Hence >it is not necessary for the WG to standardize a mechanism. Note >that I am not objecting to such as effort, just that it is not >necessary IMHO. > >OTHO, doing CMT properly and efficiently probably requires co- >operation from the receiver side. As mentioned in the "-tuexen-... >-multipath-" ID, there are a couple obvious issues in doing CMT >in "standard" SCTP impl. While things like avoiding false fast >retransmission may be mitigated on the sender side alone (albeit >a little bit inefficiently), things like delaying SACK require >receiver side changes. It is a good idea if there are new protocol >features to facilitate CMT on both sides. And since CMT can have >side effect on the network, it is important for this WG to evaluate >it. Hence IMHO it is necessary to standardize CMT by this WG. > > >>I'm posing this more informally to the WG, but how I, as chair, take the >>answer to this question can get more formal based on the answers given >>(including if no one answers this question). >> >>Why do I pose this? >> >>ITSM the "-nishida-" ID address the problem area, but >>"-tuexen-...-multipath-" ID addresses a superset of the problem area. >> >>If I've mischaracterized this - please correct me concisely. The WG >>doesn't need to be a book of an response, as that'll likely confuse more >>of the WG... > > >I think they can be separated. Ideally, an app can choose how >an SCTP stack utilizes the different paths. If an app just wants >to use one path (say because alternate paths are expensive to use), >quick failover is applicable. If an app wants to utilizes all paths >simultaneously, CMT is used and how to do retransmission becomes part >of the CMT algorithm. I think I'm gathering that if these are separate efforts, they must align (i.e., one is the super-set of the other). That makes me question whether the use-case for the subset doc is worth doing if the super-set doc can be done effectively and in a timely manner. Or am I oversimplifying things? Are these two sufficiently different problem-spaces? Obviously, if these two efforts are covering separate problem spaces, however close they are to each other, it appears we want to address both if we can. I need to understand if we need two efforts to cover problem spaces that are real close to each other, or can the efforts be combined into one effort? James (with my chair hat on) >-- > > K. Poon. > ka-cheong.poon@oracle.com From dlehmann@ulticom.com Tue Jan 25 11:53:59 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99FBC3A687C for ; Tue, 25 Jan 2011 11:53:59 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ilkdefFZHHv for ; Tue, 25 Jan 2011 11:53:58 -0800 (PST) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id 99AFE3A6860 for ; Tue, 25 Jan 2011 11:53:58 -0800 (PST) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id 846BB26EC5E3CD8B; Tue, 25 Jan 2011 14:56:56 -0500 (EST) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id p0PJutKx017637; Tue, 25 Jan 2011 14:56:55 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Quick Failover Algorithm in SCTP - question for the WG Date: Tue, 25 Jan 2011 14:56:55 -0500 Message-ID: In-Reply-To: <201101251916.p0PJGm76021999@sj-core-3.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Quick Failover Algorithm in SCTP - question for the WG Thread-Index: Acu8xH+LW5QZDVZZQqeeMElSrQJeJQAAdQHw References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com><4D3EAF12.4050100@oracle.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> From: "David Lehmann" To: "James M. Polk" , "Kacheong Poon" , Received-SPF: pass X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 19:53:59 -0000 IMHO, there are a few reasons to move forward with Quick Failover. (1) Quick Failover seems to be less complex, which will allow more timely approval/implementation. As Kacheong pointed out, "Doing it does not require co-operation from the receiver side. There is not much side effect (should not introduce congestion for example)...". (2) Although the current spec may allow quick failover, it implies an unacceptably long wait time before failover. I don't think Solaris or Linux has quick failover. Let's say that one does implement it. Now we have two major implementations with quite noticeable behavior differences. IMHO, users should expect consistent behavior across all SCTP implementations. (3) As Dr. Dreibholz noted, CMT will also benefit from Quick Failover. The CMT spec can reference Quick Failover. -- David Lehmann Ulticom, Inc. 856-787-2952 From wwwrun@rfc-editor.org Tue Jan 25 17:41:17 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 770EF3A6906; Tue, 25 Jan 2011 17:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.006 X-Spam-Level: X-Spam-Status: No, score=-102.006 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yy251nLgtjl9; Tue, 25 Jan 2011 17:41:16 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id CD9B93A68CC; Tue, 25 Jan 2011 17:41:16 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0F445E06FD; Tue, 25 Jan 2011 17:44:16 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 6096 on Stream Control Transmission Protocol (SCTP) Chunk Flags Registration From: rfc-editor@rfc-editor.org Message-Id: <20110126014416.0F445E06FD@rfc-editor.org> Date: Tue, 25 Jan 2011 17:44:16 -0800 (PST) Cc: tsvwg@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 01:41:17 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6096 Title: Stream Control Transmission Protocol (SCTP) Chunk Flags Registration Author: M. Tuexen, R. Stewart Status: Standards Track Stream: IETF Date: January 2011 Mailbox: tuexen@fh-muenster.de, randall@lakerest.net Pages: 8 Characters: 15368 Updates: RFC4960 I-D Tag: draft-ietf-tsvwg-sctp-chunk-flags-02.txt URL: http://www.rfc-editor.org/rfc/rfc6096.txt This document defines the procedure for registering chunk flags with the Internet Assigned Numbers Authority (IANA) for the Stream Control Transmission Protocol (SCTP). It updates RFC 4960 and also defines the IANA registry for contents for currently defined chunk types. It does not change SCTP in any other way. [STANDARDS-TRACK] This document is a product of the Transport Area Working Group Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From gorry@erg.abdn.ac.uk Wed Jan 26 00:09:15 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 161DE3A695F for ; Wed, 26 Jan 2011 00:09:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNLIFRtc6uBH for ; Wed, 26 Jan 2011 00:08:57 -0800 (PST) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 81A903A6951 for ; Wed, 26 Jan 2011 00:08:55 -0800 (PST) Received: from Gorry-Fairhursts-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p0Q8BiZT006523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 Jan 2011 08:11:45 GMT Message-ID: <4D3FD73F.4030609@erg.abdn.ac.uk> Date: Wed, 26 Jan 2011 08:11:43 +0000 From: Gorry Fairhurst User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "tsvwg-chairs@tools.ietf.org" , tsvwg list Subject: New TSVWG Work Item: Deprecation of ICMP Source Quench messages Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 08:09:15 -0000 This email concludes the WG call for adoption for: "Deprecation of ICMP Source Quench messages" The decision was to adopt this as a TSVWG work item. In deciding to adopt this, the Chairs considered although this was already common practice, it seemed to be a topic where the existing guidance in STD-track documents is not clear enough. We therefore conclude the IETF should make a strong recommendation on this topic. We think the current draft demonstrates that it should be possible to quickly complete this work without much real working group effort, since the expected outcome should be concise and easily reviewed. Gorry From gorry@erg.abdn.ac.uk Wed Jan 26 11:35:38 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC4393A684F for ; Wed, 26 Jan 2011 11:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wL2XhC3ieuWY for ; Wed, 26 Jan 2011 11:35:38 -0800 (PST) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 8D5813A6822 for ; Wed, 26 Jan 2011 11:35:37 -0800 (PST) Received: from ra-gorry.erg.abdn.ac.uk (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p0QJcUk8012540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 Jan 2011 19:38:31 GMT Message-ID: <4D407837.2070900@erg.abdn.ac.uk> Date: Wed, 26 Jan 2011 19:38:31 +0000 From: Gorry Fairhurst User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: tsvwg list Subject: Source Quench NiTs : (draft-gont-tsvwg-source-quench-01) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: Fernando Gont X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 19:35:39 -0000 As a TSVWG list member, I enclose some comments on this draft to help prepare draft-ietf-tsvwg-source-quench-00. Best wishes, Gorry ----- Abstract: I recommend you add more detail here, saying what documents are updated. Introduction: /The ICMP specification [RFC0792] defines the ICMPv4 Source Quench message (type 4, code 0), which is / ^^ - change to "was", since we now declare this as historic? /for a long time/ - perhaps we should just say the year - i.e. 1995. / This document formally deprecates reaction to ICMP Source Quench messages by transport protocols such as TCP./ - Should we consider deprecating it for all IPv4 nodes? I think it effectively does this, including endpoints that do not constitute transports. Section 3: /We hereby/ - Could we say "This document hereby"... /message (type 4, code 0), which is / - see note on intro. /[RFC1812] notes that research suggests/.../and formally deprecates/ - 'noted', 'suggested', and 'deprecated'? /If Source Quench message is received,/ ^ - insert 'a'. /the IP layer MAY silently discard it./ - I support Fred Baker's comment, in "IMHO, any IP system SHOULD ignore a source quench that it receives." Section 6.: - My first thoughts are also that it is good to make this "memo" historic (RFC1016). See what others think. References: - I'm not sure that [RFC4443] is normative. Please check. - Neither RFC 5681 nor RFC3136 mention SQ - do these have to be a normative reference? From fernando.gont.netbook.win@gmail.com Wed Jan 26 12:08:25 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 955823A6960 for ; Wed, 26 Jan 2011 12:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pX5lhH0jcf96 for ; Wed, 26 Jan 2011 12:08:20 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 6DDDC3A6920 for ; Wed, 26 Jan 2011 12:08:20 -0800 (PST) Received: by gyd12 with SMTP id 12so347092gyd.31 for ; Wed, 26 Jan 2011 12:11:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=Fg6ESDvztVG8L+7DzlBUe0TvAyA5o6s4/RoV7Bt2z1U=; b=K1PoEMZZ90M/pNrnJg+cMzEOJasNxIbeNQuKMoFgj9ZojwJFGknr8IRJjOElmMcCqb OC2Dr4ftoS1EYVlbvAq3wlmEgRh9qmmioGP4rPb+Wcrq39a/KkuATGdTuNVS7wdqIhZA p5vFdfDqI+NPyp8u7GCESONPW+ZKWrEpMrmGA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=B25VTnbrGEccuGwp3AzkqcfBS5rnq9vOrCJxEGO8vqmhD7zomzUcb85a8IBp/spSbp gPaX7Un+v4xx9E1asUMnaAWxzLgkY2qkG7h7WV7Agjk2fbzqNFa3XvX9rJz7COaZ0ArB Guk0WmOhHcEhQGNjfKKrxEtg3RpWgIW7AKCJM= Received: by 10.100.164.1 with SMTP id m1mr5247055ane.269.1296072681601; Wed, 26 Jan 2011 12:11:21 -0800 (PST) Received: from [192.168.2.2] (122-172-17-190.fibertel.com.ar [190.17.172.122]) by mx.google.com with ESMTPS id x36sm19440128anx.14.2011.01.26.12.11.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 26 Jan 2011 12:11:20 -0800 (PST) Sender: Fernando Gont Message-ID: <4D407FE1.2050004@gont.com.ar> Date: Wed, 26 Jan 2011 17:11:13 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Gorry Fairhurst Subject: Re: Source Quench NiTs : (draft-gont-tsvwg-source-quench-01) References: <4D407837.2070900@erg.abdn.ac.uk> In-Reply-To: <4D407837.2070900@erg.abdn.ac.uk> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tsvwg list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 20:08:25 -0000 Hi, Gorry, Thanks so much for your feedback. Should I resubmit as draft-ietf once I address these? Please find my comments inline... On 26/01/2011 04:38 p.m., Gorry Fairhurst wrote: > Abstract: > > I recommend you add more detail here, saying what documents are updated. Ok, will do. > Introduction: > > /The ICMP specification [RFC0792] defines the ICMPv4 Source Quench > message (type 4, code 0), which is / > ^^ > - change to "was", since we now declare this as historic? Should I put the whole sentence in past tense? i.e. "defined... which was"? > > /for a long time/ > - perhaps we should just say the year - i.e. 1995. Will do. > / This document formally deprecates reaction to ICMP Source Quench > messages by transport protocols such as TCP./ > - Should we consider deprecating it for all IPv4 nodes? I think it > effectively does this, including endpoints that do not constitute > transports. Well, the point is that other than the minor updates to RFC1812, this document formally deprecates the reaction to SQ by TCP -- right now, e.g. TCP is still required to slow down upon receipt of ICMP SQ. If others weigh in, and agree on that, I could s/deprecates reaction to ICMP Source Quench messages by transport protocols such as TCP/deprecates the use of ICMP Source Quench messages by all IPv4 nodes/. > Section 3: > > /We hereby/ > - Could we say "This document hereby"... Will do. > /message (type 4, code 0), which is / > - see note on intro. Ditto -- past tense for the whole thing? > /[RFC1812] notes that research suggests/.../and formally deprecates/ > - 'noted', 'suggested', and 'deprecated'? Depending on what's your take for the other instances... but yes, I think that would sound good to me. > /the IP layer MAY silently discard it./ > - I support Fred Baker's comment, in "IMHO, any IP system SHOULD ignore > a source quench that it receives." The point is that this is a specific update to RFC 1122, which talks about hosts, not routers. Thoughts? > Section 6.: > > - My first thoughts are also that it is good to make this > "memo" historic (RFC1016). See what others think. So no changes here, right? -- FWIW, what's in the current version of the I-D is what I've sensed as consensus as a result of the discussions on ICMP SQ on this mailing-list. > References: > > - I'm not sure that [RFC4443] is normative. Please check. Yes, I think that in this case it could be informative. Will do. > - Neither RFC 5681 nor RFC3136 mention SQ - do these have to be a > normative reference? I think "these are important to understand this document", which would make them "normative"... Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From jmpolk@cisco.com Wed Jan 26 12:32:23 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A50F13A69A2 for ; Wed, 26 Jan 2011 12:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.529 X-Spam-Level: X-Spam-Status: No, score=-110.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SLjyXP0qzoU for ; Wed, 26 Jan 2011 12:32:22 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 665163A6895 for ; Wed, 26 Jan 2011 12:32:22 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 26 Jan 2011 20:35:23 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8716.cisco.com [10.99.80.23]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0QKZNZF021356; Wed, 26 Jan 2011 20:35:23 GMT Message-Id: <201101262035.p0QKZNZF021356@sj-core-5.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 26 Jan 2011 14:35:22 -0600 To: "David Lehmann" , "James M. Polk" , "Kacheong Poon" , From: "James M. Polk" Subject: RE: Quick Failover Algorithm in SCTP - question for the WG In-Reply-To: References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <4D3EAF12.4050100@oracle.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 20:32:23 -0000 At 01:56 PM 1/25/2011, David Lehmann wrote: >IMHO, there are a few reasons to move forward with Quick Failover. >(1) Quick Failover seems to be less complex, which will allow more >timely approval/implementation. As Kacheong pointed out, "Doing it does >not require co-operation from the receiver side. There is not much side >effect (should not introduce congestion for example)...". >(2) Although the current spec may allow quick failover, it implies an >unacceptably long wait time before failover. I don't think Solaris or >Linux has quick failover. Let's say that one does implement it. Now we >have two major implementations with quite noticeable behavior >differences. IMHO, users should expect consistent behavior across all >SCTP implementations. >(3) As Dr. Dreibholz noted, CMT will also benefit from Quick Failover. >The CMT spec can reference Quick Failover. Do others agree with this position, with the caveat that anything within the multipath ID regarding Quick Failover has to be in line with the Quick Failover ID (i.e., they need to be in sync)? I want to hear from many on this before proceeding with anything. James TSVWG chair >-- >David Lehmann >Ulticom, Inc. >856-787-2952 From gorry@erg.abdn.ac.uk Wed Jan 26 12:55:38 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89E1B3A69D2 for ; Wed, 26 Jan 2011 12:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcLiKzhEkTZM for ; Wed, 26 Jan 2011 12:55:37 -0800 (PST) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id A1D3B3A6895 for ; Wed, 26 Jan 2011 12:55:36 -0800 (PST) Received: from ra-gorry.erg.abdn.ac.uk (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p0QKwSCe014212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 Jan 2011 20:58:29 GMT Message-ID: <4D408AF5.4090302@erg.abdn.ac.uk> Date: Wed, 26 Jan 2011 20:58:29 +0000 From: Gorry Fairhurst User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Fernando Gont Subject: Re: Source Quench NiTs : (draft-gont-tsvwg-source-quench-01) References: <4D407837.2070900@erg.abdn.ac.uk> <4D407FE1.2050004@gont.com.ar> In-Reply-To: <4D407FE1.2050004@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: tsvwg list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 20:55:38 -0000 See in-line... On 26/01/2011 20:11, Fernando Gont wrote: > Hi, Gorry, > > Thanks so much for your feedback. Should I resubmit as draft-ietf once I > address these? > > Please find my comments inline... > > On 26/01/2011 04:38 p.m., Gorry Fairhurst wrote: >> Abstract: >> >> I recommend you add more detail here, saying what documents are updated. > > Ok, will do. > > > >> Introduction: >> >> /The ICMP specification [RFC0792] defines the ICMPv4 Source Quench >> message (type 4, code 0), which is / >> ^^ >> - change to "was", since we now declare this as historic? > > Should I put the whole sentence in past tense? i.e. "defined... which was"? > I'd suggest so. > >> >> /for a long time/ >> - perhaps we should just say the year - i.e. 1995. > > Will do. > > > >> / This document formally deprecates reaction to ICMP Source Quench >> messages by transport protocols such as TCP./ >> - Should we consider deprecating it for all IPv4 nodes? I think it >> effectively does this, including endpoints that do not constitute >> transports. > > Well, the point is that other than the minor updates to RFC1812, this > document formally deprecates the reaction to SQ by TCP -- right now, > e.g. TCP is still required to slow down upon receipt of ICMP SQ. > > If others weigh in, and agree on that, I could s/deprecates reaction to > ICMP Source Quench messages by transport protocols such as > TCP/deprecates the use of ICMP Source Quench messages by all IPv4 nodes/. > Let's discuss that one on the list! > > >> Section 3: >> >> /We hereby/ >> - Could we say "This document hereby"... > > Will do. > > > >> /message (type 4, code 0), which is / >> - see note on intro. > > Ditto -- past tense for the whole thing? > > > >> /[RFC1812] notes that research suggests/.../and formally deprecates/ >> - 'noted', 'suggested', and 'deprecated'? > > Depending on what's your take for the other instances... but yes, I > think that would sound good to me. > > > >> /the IP layer MAY silently discard it./ >> - I support Fred Baker's comment, in "IMHO, any IP system SHOULD ignore >> a source quench that it receives." > > The point is that this is a specific update to RFC 1122, which talks > about hosts, not routers. > > Thoughts? > We could update router behaviour too, if TSVWG wants. It's a transport signal. > > >> Section 6.: >> >> - My first thoughts are also that it is good to make this >> "memo" historic (RFC1016). See what others think. > > So no changes here, right? > That's my "non-chair" position too :-) > -- FWIW, what's in the current version of the I-D is what I've sensed as > consensus as a result of the discussions on ICMP SQ on this mailing-list. > OK > >> References: >> >> - I'm not sure that [RFC4443] is normative. Please check. > > Yes, I think that in this case it could be informative. Will do. > > > >> - Neither RFC 5681 nor RFC3136 mention SQ - do these have to be a >> normative reference? > I meant ECN, not 3136. > I think "these are important to understand this document", which would > make them "normative"... > Although you need to understand them, the changes you are making do not modify these documents, so I'd still say they are not normative - but we can handle later in LC. > Thanks! > > Best regards, > I'd suggest you do all the changes you feel confident with, and we can discuss any remaining issues on the list. Can you summarise any remaining points you recall? Finally, with my "Chair" hat on: You may upload the next version as a WG I-D. Gorry From david.black@emc.com Wed Jan 26 16:04:50 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 408DC3A6A0E for ; Wed, 26 Jan 2011 16:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zwt-e6Oz06X5 for ; Wed, 26 Jan 2011 16:04:49 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 0FE0F3A6899 for ; Wed, 26 Jan 2011 16:04:48 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0R07hOw024218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Jan 2011 19:07:43 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 26 Jan 2011 19:07:35 -0500 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0R073SA003596; Wed, 26 Jan 2011 19:07:03 -0500 Received: from mx14a.corp.emc.com ([169.254.1.169]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Wed, 26 Jan 2011 19:07:03 -0500 From: To: Date: Wed, 26 Jan 2011 19:07:01 -0500 Subject: RE: Source Quench NiTs : (draft-gont-tsvwg-source-quench-01) Thread-Topic: Source Quench NiTs : (draft-gont-tsvwg-source-quench-01) Thread-Index: Acu9m/uHlFhPjUovSDiw77LYzNqyGgAGcfbQ Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E03D771E3D8@MX14A.corp.emc.com> References: <4D407837.2070900@erg.abdn.ac.uk> <4D407FE1.2050004@gont.com.ar> <4D408AF5.4090302@erg.abdn.ac.uk> In-Reply-To: <4D408AF5.4090302@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 00:04:50 -0000 > > If others weigh in, and agree on that, I could s/deprecates reaction to > > ICMP Source Quench messages by transport protocols such as > > TCP/deprecates the use of ICMP Source Quench messages by all IPv4 nodes= /. > > > Let's discuss that one on the list! > >> /the IP layer MAY silently discard it./ > >> - I support Fred Baker's comment, in "IMHO, any IP system SHOULD ignor= e > >> a source quench that it receives." > > > > The point is that this is a specific update to RFC 1122, which talks > > about hosts, not routers. > > > > Thoughts? > > > We could update router behaviour too, if TSVWG wants. It's a transport > signal. I strongly suggest doing this once and deprecating Source Quench everywhere= . If that means updating additional RFCs, I have no problem with doing so. Thanks, --David > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of= Gorry Fairhurst > Sent: Wednesday, January 26, 2011 3:58 PM > To: Fernando Gont > Cc: tsvwg list > Subject: Re: Source Quench NiTs : (draft-gont-tsvwg-source-quench-01) >=20 > See in-line... >=20 > On 26/01/2011 20:11, Fernando Gont wrote: > > Hi, Gorry, > > > > Thanks so much for your feedback. Should I resubmit as draft-ietf once = I > > address these? > > > > Please find my comments inline... > > > > On 26/01/2011 04:38 p.m., Gorry Fairhurst wrote: > >> Abstract: > >> > >> I recommend you add more detail here, saying what documents are update= d. > > > > Ok, will do. > > > > > > > >> Introduction: > >> > >> /The ICMP specification [RFC0792] defines the ICMPv4 Source Quench > >> message (type 4, code 0), which is / > >> ^^ > >> - change to "was", since we now declare this as historic? > > > > Should I put the whole sentence in past tense? i.e. "defined... which w= as"? > > > I'd suggest so. > > > >> > >> /for a long time/ > >> - perhaps we should just say the year - i.e. 1995. > > > > Will do. > > > > > > > >> / This document formally deprecates reaction to ICMP Source Quench > >> messages by transport protocols such as TCP./ > >> - Should we consider deprecating it for all IPv4 nodes? I think it > >> effectively does this, including endpoints that do not constitute > >> transports. > > > > Well, the point is that other than the minor updates to RFC1812, this > > document formally deprecates the reaction to SQ by TCP -- right now, > > e.g. TCP is still required to slow down upon receipt of ICMP SQ. > > > > If others weigh in, and agree on that, I could s/deprecates reaction to > > ICMP Source Quench messages by transport protocols such as > > TCP/deprecates the use of ICMP Source Quench messages by all IPv4 nodes= /. > > > Let's discuss that one on the list! > > > > > >> Section 3: > >> > >> /We hereby/ > >> - Could we say "This document hereby"... > > > > Will do. > > > > > > > >> /message (type 4, code 0), which is / > >> - see note on intro. > > > > Ditto -- past tense for the whole thing? > > > > > > > >> /[RFC1812] notes that research suggests/.../and formally deprecates/ > >> - 'noted', 'suggested', and 'deprecated'? > > > > Depending on what's your take for the other instances... but yes, I > > think that would sound good to me. > > > > > > > >> /the IP layer MAY silently discard it./ > >> - I support Fred Baker's comment, in "IMHO, any IP system SHOULD ignor= e > >> a source quench that it receives." > > > > The point is that this is a specific update to RFC 1122, which talks > > about hosts, not routers. > > > > Thoughts? > > > We could update router behaviour too, if TSVWG wants. It's a transport > signal. > > > > > >> Section 6.: > >> > >> - My first thoughts are also that it is good to make this > >> "memo" historic (RFC1016). See what others think. > > > > So no changes here, right? > > > That's my "non-chair" position too :-) >=20 > > -- FWIW, what's in the current version of the I-D is what I've sensed a= s > > consensus as a result of the discussions on ICMP SQ on this mailing-lis= t. > > > OK > > > >> References: > >> > >> - I'm not sure that [RFC4443] is normative. Please check. > > > > Yes, I think that in this case it could be informative. Will do. > > > > > > > >> - Neither RFC 5681 nor RFC3136 mention SQ - do these have to be a > >> normative reference? > > > I meant ECN, not 3136. >=20 > > I think "these are important to understand this document", which would > > make them "normative"... > > > Although you need to understand them, the changes you are making do not > modify these documents, so I'd still say they are not normative - but we > can handle later in LC. >=20 > > Thanks! > > > > Best regards, > > > I'd suggest you do all the changes you feel confident with, and we can > discuss any remaining issues on the list. Can you summarise any > remaining points you recall? >=20 >=20 > Finally, with my "Chair" hat on: >=20 > You may upload the next version as a WG I-D. >=20 > Gorry >=20 From fluffy@cisco.com Wed Jan 26 16:09:44 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAE003A69FF; Wed, 26 Jan 2011 16:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.584 X-Spam-Level: X-Spam-Status: No, score=-110.584 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pr2NCZ+T8RRw; Wed, 26 Jan 2011 16:09:43 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 4CD033A69F3; Wed, 26 Jan 2011 16:09:43 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFtHQE2rRN+J/2dsb2JhbACke3OhAptJhU8EhReHEg Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-3.cisco.com with ESMTP; 27 Jan 2011 00:12:45 +0000 Received: from sjc-vpn5-670.cisco.com (sjc-vpn5-670.cisco.com [10.21.90.158]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p0R0Cj4r028934; Thu, 27 Jan 2011 00:12:45 GMT Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <20110118212603.5733.34489.idtracker@localhost> Date: Wed, 26 Jan 2011 17:12:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110118212603.5733.34489.idtracker@localhost> To: IETF discussion list X-Mailer: Apple Mail (2.1082) Cc: tsvwg@ietf.org, IESG IESG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 00:09:45 -0000 I'm really glad to see this draft in LC at long last and it is a great = improvement to the current situation - thank you to all the people that = put work into this. I have two significant problems with it that I think = should be resolved before being published=20 Big Issues 1: I don't like mandating one port for secure and not secure = versions of a protocol=20 I don't think this reflects IETF consensus given the number of protocols = that deliberately choses to use two ports. I also don't think that it is = a good idea in all cases. I believe the decision should be left to the = people designing the protocol if they want one port or two. Let me give = some examples Imagine a client server protocol that runs over UDP and uses DTLS for = security. The server will simultaneously serve requests over both DTLS = and UDP. When the server receives a packet, it needs to be able to demux = if it is a UDP packet or a DTLS packet. The obvious demux code point is = the port. Yes, one might be able to reinvent a concept of a stream along = with a 5 tuple and something like STARTTLS but this has many other = problems. It means the client needs to use a different SRC port for each = different "session" to the same server. This uses up NAT ports and = complicates NAT traversal. It also adds additional latency to set up a = small session. People just aren't going to do it. The other approach is = demux based on the first byte inside the UDP packet. The CoAP protocol = being developed in the CORE WG has taken that approach. The CORE WG = proposed to the TLS chairs that over half the remaining code space for = the TLS code point in the first byte be assigned to CoAP. The TLS = chairs, more or less told the CORE guys to get stuffed (politely of = course). Two ports is the obvious answer.=20 Lets consider another example. As the draft mentions, firewalls help = apply policy, and catch configuration errors. Take an organization (like = my house) that has a policy of no email over unencrypted protocols. It's = really easy to set up a firewall policy that allows the encrypted ports = and blocks the non encrypted ports that are typically used for email and = does not require the firewall to do DPI. No doubt my daughter could = figure out to circumvent this and sent unencrypted email via an VPN = tunneled over DNS or ICMP or something but thats not the point - the = point is to catch accidental misconfiguration, like the type that happen = during software upgrades. You can agree or disagree about using = firewalls this way but the fact remains, lots of people do use firewalls = this way.=20 I strongly urge this draft not to take on mandating one port - leave the = decision with the designers of the protocol. If draft does mandate one = port, you will end up with a port registered for protocol foo and a port = for a proprietary protocol with no description called foo-secure. As I = mentioned before, I also do not believe there is IETF consensus for one = port.=20 Big Issue #2: The draft has close to no review advice for the expert = reviewer.=20 I have been involved with several port registrations and they all left = me grumpy and irritated and very frustrated at the expert review = process. I'm sure the expert reviewer involved felt the same way and I = know others have had similar experiences. We need concrete actionable = advice for when the review says yes or no.=20 This draft provides no guidance on what the expert review would approve = or deny. If all they are doing is checking the requirements of this = draft have been satisfied, then I am fine with that but the draft needs = to say that something like any denial by an expert review should include = which MUST in this draft was not complied with.=20 I would like the draft to say that when IANA sends a response from an = expert review to the applicant, the name of the reviewer (and perhaps = email address) should be included.=20 Lets take some specific points of never ending confusion about what is = "good enough" to say yes.=20 The reference to the doc describing the protocol. Is this a one line = description? Is it a overview of the high level way this works, deals = with congestion, security etc? Is it a full protocol specification. I = have no idea. I also have no idea on what grounds the expert reviews can = say no based on this.=20 What protocols use Anycast. Does STUN? Does ping? what about DNS? Who = knows - who cares. I do not believe discussion of if a protocol uses = anycast or not has much relevance to deciding to allocate a port.=20 Next lets talk about the whole topic of what is or is not appropriate = for dynamic range. Let's take web browsing for example. You start with a = URL like www.example.com but the protocol could have required a port = like www.example.com:55123 in the URL and only used dynamic ports. Is = http a protocol that should be forced into the dynamic range? Clearly = the answer is no but if not http, then what protocol should? This draft = offers no advice to the expert reviewer on what to do. Next lets = consider a protocol like FTP data transport - first FTP does some = signaling and it can pass the ports to be used for the data transport = connection so you might think the dynamic range is fine for the = transport part - but policy on firewalls has resulted in people wanting = to have a well known port for that FTP uses for the data connection. = Most FTP now supports PASV and things like that to meet this well known = port requirement. You need to do this to make NAT port forwarding work.=20= I think this draft need specific actionable advice on what grounds the = expert review can say No. Obviously violating any of the MUST in this = draft is fine reason to say no - but beyond that it is just too vague.=20= Next we come to the issue of if a new protocols is allowed or not. Cisco = developed a new protocol - the retransmission and flow control part of = it was stollen from another protocol that is an RFC. I viewed this as a = good thing as it ensured that we did not reinvent something new that was = broken. The IANA expert review felt that we should not make a new = protocol and should instead extend the old one and would not approve the = port. Eventually sanity prevailed and the port was allocated but it = worth noting that when the port was approved, the product had already = shipped and the port was fixed. Had IANA not allocated the port, Cisco = would have just kept using the port anyways. I'll note most other = vendors feel about the same way - if they need to build a product that = needs a port, they will take a port, or more than one, if one is not = allocated. This does not make me happy but I think we need to be = realistic about what our grounds are for saying no and the probable = result of saying no.=20 Along these lines, I have no idea what review guidelines the expert = would use to decide if something was OK to be in the System port range = instead of User. What would be an appropriate argument for System = instead of User?=20 Along these lines, I think the draft should contain an example = registration for a protocol in the port range where the description of = the protocol is not a reference to a document but is provided in this = example - using an existing protocol such as HTTP might make it easier = for everyone to read. Similarly be nice to have example for something in = the System range.=20 Anyways, my meta point is the draft need to give enough advice to the = expert review that they know what to do. Of course the expert applies = human intelligence but the review and applicants have to be on the same = page about what is expected here.=20 Small Issue #3: I object to anonymous review The current review is anonymous and this draft does not seem to change = that. I don't like anonymous review - it's not how we do things at IETF = and it encourages really bad behavior. I have several emails with an = expert reviewer relayed via IANA where the conversation was going no = where - once I knew the name of the reviewer, the whole conversation = changed and stuff quickly came back to the realm of sane. I'm not = willing to forward these emails to the list as that would just not be = kind to anyone but I am happy to forward them to the IESG if they think = looking at them is really critical.=20 On Jan 18, 2011, at 14:26 , The IESG wrote: >=20 > The IESG has received a request from the Transport Area Working Group = WG > (tsvwg) to consider the following document: > - 'Internet Assigned Numbers Authority (IANA) Procedures for the > Management of the Service Name and Transport Protocol Port Number > Registry' > as a BCP >=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 2011-02-01. 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 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From Internet-Drafts@ietf.org Wed Jan 26 21:30:03 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30FAD28C0FE; Wed, 26 Jan 2011 21:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e60NmVwnAQ05; Wed, 26 Jan 2011 21:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5EE13A6A85; Wed, 26 Jan 2011 21:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-tsvwg-source-quench-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110127053001.9380.81287.idtracker@localhost> Date: Wed, 26 Jan 2011 21:30:01 -0800 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 05:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Deprecation of ICMP Source Quench messages Author(s) : F. Gont Filename : draft-ietf-tsvwg-source-quench-00.txt Pages : 7 Date : 2011-01-26 This document formally deprecates the use of ICMP Source Quench messages by transport protocols, formally updating RFC 792, RFC 1122, and RFC 1812. Additionally, it requests that the status of RFC 1016 be changed to "Historic". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-source-quench-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tsvwg-source-quench-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-26211651.I-D@ietf.org> --NextPart-- From lars.eggert@nokia.com Thu Jan 27 00:38:31 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C0953A6973 for ; Thu, 27 Jan 2011 00:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.391 X-Spam-Level: X-Spam-Status: No, score=-103.391 tagged_above=-999 required=5 tests=[AWL=-0.792, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPokNp-iJhOz for ; Thu, 27 Jan 2011 00:38:30 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 5DD0D3A6959 for ; Thu, 27 Jan 2011 00:38:30 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0R8fMt6016509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jan 2011 10:41:23 +0200 Subject: Re: Source Quench NiTs : (draft-gont-tsvwg-source-quench-01) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-14--17101229; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E03D771E3D8@MX14A.corp.emc.com> Date: Thu, 27 Jan 2011 10:41:18 +0200 Message-Id: <56C69F09-D88C-4B6B-9094-5C86DA3F4EE8@nokia.com> References: <4D407837.2070900@erg.abdn.ac.uk> <4D407FE1.2050004@gont.com.ar> <4D408AF5.4090302@erg.abdn.ac.uk> <7C4DFCE962635144B8FAE8CA11D0BF1E03D771E3D8@MX14A.corp.emc.com> To: david.black@emc.com X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Thu, 27 Jan 2011 10:41:18 +0200 (EET) X-Nokia-AV: Clean Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 08:38:31 -0000 --Apple-Mail-14--17101229 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2011-1-27, at 2:07, david.black@emc.com wrote: > I strongly suggest doing this once and deprecating Source Quench = everywhere. > If that means updating additional RFCs, I have no problem with doing = so. +1 It probably means that we need to joint last-call this with INT and RTG, = but that is not a problem. Lars= --Apple-Mail-14--17101229 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEyNzA4NDExOVowIwYJKoZIhvcNAQkE MRYEFHmWIT54iDgTDzPRY991WjRGRxzRMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AKpAjeYchi4/rUY+ifqkZw0ql/5UF3odE/70QUnVcKDoZRVKZ0hp0pcw7ioRUUNTcXGX7xINwFMQ WLrC77YNTc/zbjpVVPkhADE7xqNlEITDIG5+S8TnLU9XTN3AyYgWvRpJZPgD5G3S7ho2tpfanT8Q 5vui1xYMOc74u5/f82bAHGT1SjxEm2dnsKfdxo7f7qFVjAlQxSJ2e/bT5INiTzDGz1HtFt7Sb3Ck jq7FsMalwjWsMinGMhJ0oWbuNRuzO/ds3cYEJJL3VUGfPjHGuH2mk7MBiRvJWU48FJKrr3cr1loX R8qb7o1zQ98DsW17PZxqHtq0j5XnjSMtPP2otx8AAAAAAAA= --Apple-Mail-14--17101229-- From lars.eggert@nokia.com Thu Jan 27 00:50:00 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BA7B3A6959; Thu, 27 Jan 2011 00:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.883 X-Spam-Level: X-Spam-Status: No, score=-103.883 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsID7qUB0wc4; Thu, 27 Jan 2011 00:49:59 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 442243A6939; Thu, 27 Jan 2011 00:49:59 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0R8qx67016593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jan 2011 10:53:00 +0200 Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-15--16404008; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Thu, 27 Jan 2011 10:52:55 +0200 Message-Id: References: <20110118212603.5733.34489.idtracker@localhost> To: Cullen Jennings , Paul Hoffman X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Thu, 27 Jan 2011 10:52:56 +0200 (EET) X-Nokia-AV: Clean Cc: IESG IESG , IETF discussion list , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 08:50:00 -0000 --Apple-Mail-15--16404008 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi On 2011-1-27, at 2:12, Cullen Jennings wrote: > Big Issues 1: I don't like mandating one port for secure and not = secure versions of a protocol >=20 > I don't think this reflects IETF consensus given the number of = protocols that deliberately choses to use two ports. I also don't think = that it is a good idea in all cases. I believe the decision should be = left to the people designing the protocol if they want one port or two. = Let me give some examples Paul Hoffman raised this issue as well (email from Nov 4 to this list.) There was some discussion that lead to Paul suggesting specific edit to = this document. (Which are not reflected in -09; us editors may have = dropped the ball here). I'm attaching Paul's proposed changes below, = could you check if you'd agree with them? > Big Issue #2: The draft has close to no review advice for the expert = reviewer. Joe Touch (who leads the expert review team for ports) is working on a = separate document (draft-touch-tsvwg-port-use). The first version of = that draft was issued on the same day as the -09 version of iana-ports, = which is why we don't refer to it.=20 Does draft-touch-tsvwg-port-use have the content you are looking for? If = so, we should refer to it. (We should probably refer to it anyway, in a = "you may also want to read this" kind-of way.) > Small Issue #3: I object to anonymous review >=20 > The current review is anonymous and this draft does not seem to change = that. I don't like anonymous review - it's not how we do things at IETF = and it encourages really bad behavior. I have several emails with an = expert reviewer relayed via IANA where the conversation was going no = where - once I knew the name of the reviewer, the whole conversation = changed and stuff quickly came back to the realm of sane. I'm not = willing to forward these emails to the list as that would just not be = kind to anyone but I am happy to forward them to the IESG if they think = looking at them is really critical. I can see your point, and I personally have no problem with disclosing = the reviewer identity. What do others think? Lars PS: Paul's proposed changes re item #1: Begin forwarded message: > From: Paul Hoffman > Date: November 15, 2010 21:44:24 GMT+02:00 > To: > Subject: Proposed resolution for security issues with = draft-ietf-tsvwg-iana-ports-08 >=20 > As this list and the TLS has seen, there is a wide variety of views on = how to deal with fallback-to-insecure in protocols. I believe that the = security community has no consensus on what this means, much less how to = do it. My earlier proposal (continue to allow registration of two ports) = was popular with some, unpopular with others; similarly, so was "force = all protocols to use one port". >=20 > Therefore, I retract my proposal to allow two-port registrations for = fallback-to-insecure. However, I still recommend some changes to the = text to reflect the view that STARTTLS is not the only way to have such = a feature on one port. >=20 > This will be an interesting IETF Last Call discussion. >=20 > I propose the following changes to draft-ietf-tsvwg-iana-ports: >=20 > Section 7.2 current: > o IANA will allocate only one assigned port number for all versions > of a service (e.g., running the service with or without a security > mechanism, or for updated variants of a service) >=20 > Section 7.2 current: [in the line above s/current/proposed/, I think] > o IANA will normally allocate only one assigned port number for all = versions > of a service (e.g., running the service with or without a security > mechanism, or for updated variants of a service). This policy can > be overridden by the expert reviewer. >=20 > Section 7.2 current: > Further, > previous separation of protocol variants based on security > capabilities (e.g., HTTP on TCP port 80 vs. HTTPS on TCP port 443) = is > not recommended for new protocols, because all new protocols should > be security-capable and capable of negotiating the use of security > in-band. >=20 > Section 7.2 proposed: > Further, > previous separation of protocol variants based on security > capabilities (e.g., HTTP on TCP port 80 vs. HTTPS on TCP port 443) = is > not recommended for new protocols, because all new protocols should > be security-capable. >=20 > --Paul Hoffman, Director > --VPN Consortium --Apple-Mail-15--16404008 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEyNzA4NTI1NlowIwYJKoZIhvcNAQkE MRYEFM/N0pkgulvbzfI8SVXLC8wn1bZyMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AEc6AzQhlzIgVfkf5rZKPPP2NfI1YxivUkkh+OxY+3ppysvemDH6ozG3Qqi4+raG4Kmb5JEAW6y9 8Vv5zBI5CyPAsc56LqZose8sSQh6+goi9m6SxrT9r3zyn94TuTCeQCrlnmXopBa6MFaLThAvb96/ 1sAF49RTqCMMLYcoEPn/P0P6DOHwiy1x9Se0hZg9htYHfy13Ks4kqv+9KGI7L5h0w0AMFKSrmSzL LkVBY2fEt7vbG+wKgVD2Uz4dLufHw2tJz5tzo8hbwAGuvvO6RcucgmPoxI78WGhxbxEMVZvjiPoh m3EfwzBDS1gg3IIzxhk/amFeS2S6pZDATXZt2OsAAAAAAAA= --Apple-Mail-15--16404008-- From magnus.westerlund@ericsson.com Thu Jan 27 01:14:26 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA67828C10E; Thu, 27 Jan 2011 01:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.494 X-Spam-Level: X-Spam-Status: No, score=-106.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YE748kOMQvr5; Thu, 27 Jan 2011 01:14:25 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 4261528C0D6; Thu, 27 Jan 2011 01:14:25 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-a1-4d413827ae71 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E7.62.13987.728314D4; Thu, 27 Jan 2011 10:17:27 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.2.234.1; Thu, 27 Jan 2011 10:17:26 +0100 Message-ID: <4D413827.7040407@ericsson.com> Date: Thu, 27 Jan 2011 10:17:27 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Cullen Jennings Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: IESG IESG , IETF discussion list , "tsvwg@ietf.org" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 09:14:26 -0000 Cullen Jennings skrev 2011-01-27 01:12: > > I'm really glad to see this draft in LC at long last and it is a great improvement to the current situation - thank you to all the people that put work into this. I have two significant problems with it that I think should be resolved before being published > > > > Big Issues 1: I don't like mandating one port for secure and not secure versions of a protocol > > I don't think this reflects IETF consensus given the number of protocols that deliberately choses to use two ports. I also don't think that it is a good idea in all cases. I believe the decision should be left to the people designing the protocol if they want one port or two. Let me give some examples > We have extensive discussion on this in the WG last call. There was no consensus for having two ports. At the same time we did also have no consensus on mandating one port for any future protocol. Thus we adjusted the text to say in Section 7.2: IANA strives to assign only one assigned port number per service or application To my knowledge "strive" is not a binding RFC2119 term. I also think it is a good trade-off with the intention of preserving the space as well as possible with only assigning one port, and still allow for more than one if it really is needed. Is it the above text that triggered your comment or some other text? Cheers 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 lars.eggert@nokia.com Thu Jan 27 01:23:21 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFA2528C119; Thu, 27 Jan 2011 01:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.38 X-Spam-Level: X-Spam-Status: No, score=-103.38 tagged_above=-999 required=5 tests=[AWL=-0.781, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceESe2PqaKYo; Thu, 27 Jan 2011 01:23:20 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 75B0428C10D; Thu, 27 Jan 2011 01:23:20 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0R9QJcC000941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jan 2011 11:26:21 +0200 Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-19--14408218; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Thu, 27 Jan 2011 11:26:11 +0200 Message-Id: References: <20110118212603.5733.34489.idtracker@localhost> To: Carsten Bormann X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Thu, 27 Jan 2011 11:26:16 +0200 (EET) X-Nokia-AV: Clean Cc: tsvwg@ietf.org, IETF discussion list , Paul Hoffman , IESG IESG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 09:23:21 -0000 --Apple-Mail-19--14408218 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2011-1-27, at 11:20, Carsten Bormann wrote: > With UDP-based protocols, it is harder to do this. > Please look at section 7.3 of >=20 > = http://tools.ietf.org/html/draft-ietf-core-coap-04.html#section-7.3 >=20 > and tell us whether this is how you would like this to be handled for = UDP-based protocols in the future. > If not, we may want to add to the guidance in the (tsvwg) draft. This looks like a totally reasonable way to to this in-band using a = single port. Lars= --Apple-Mail-19--14408218 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEyNzA5MjYxMlowIwYJKoZIhvcNAQkE MRYEFCPoCX0jwUP+ShAaM9wCn8If3RIYMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AHnlY3oYbhRIBZA5XWOANs3VsVb/7avJN2U+mVjgmpjmMYNGRfKgYptsHPPrCWO3DL/5RXn1PEUU oO9CrsC4GmLeHmuaofDVl3F7GbhnWxyvWzYdRt7DNyr+wnsH34KXlqVmEc7WgHdf7VVrV/hU+FpL 17n5iPEICQbSAPaFw2pjRX/VTpOLff/Bw1kcFFWNiANigPoNIBAgDDLY7ZVnsINSNygR1Pjf1mYQ cJfmH0r2D9S63JzmrxSCYEFrtElRQmrX2QM7/qnOxEbSMKjYslXvJwpoapmNVX8k38hlCnF4sSXs v5KtbP+JkoysBamZe065nfZioLwEfjbTFLiXv+AAAAAAAAA= --Apple-Mail-19--14408218-- From ka-cheong.poon@oracle.com Thu Jan 27 01:55:53 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3FD83A6977 for ; Thu, 27 Jan 2011 01:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.367 X-Spam-Level: X-Spam-Status: No, score=-6.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kwxeiUeeWuW for ; Thu, 27 Jan 2011 01:55:53 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id DB3543A68A6 for ; Thu, 27 Jan 2011 01:55:52 -0800 (PST) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p0R9wr1G013356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Jan 2011 09:58:55 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p0R9bH0f011064; Thu, 27 Jan 2011 09:58:53 GMT Received: from abhmt006.oracle.com by acsmt354.oracle.com with ESMTP id 997586891296122331; Thu, 27 Jan 2011 01:58:51 -0800 Received: from [10.7.251.223] (/10.7.251.223) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 27 Jan 2011 01:58:50 -0800 Message-ID: <4D4141CF.1050808@oracle.com> Date: Thu, 27 Jan 2011 17:58:39 +0800 From: Kacheong Poon Organization: Oracle Corporation User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.13) Gecko/20101209 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "James M. Polk" Subject: Re: Quick Failover Algorithm in SCTP - question for the WG References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <4D3EAF12.4050100@oracle.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> <201101262035.p0QKZNZF021356@sj-core-5.cisco.com> In-Reply-To: <201101262035.p0QKZNZF021356@sj-core-5.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 09:55:53 -0000 On 01/27/11 04:35 AM, James M. Polk wrote: > Do others agree with this position, with the caveat that anything within > the multipath ID regarding Quick Failover has to be in line with the > Quick Failover ID (i.e., they need to be in sync)? No. IMHO, quick failover does not need to be align with how CMT chooses a path to do retransmission and vice versa. -- K. Poon. ka-cheong.poon@oracle.com From alcortesm.uc3m@gmail.com Thu Jan 27 02:27:47 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6DF3A6AC7 for ; Thu, 27 Jan 2011 02:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkpYYmLnX99Q for ; Thu, 27 Jan 2011 02:27:46 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id CCC5C3A6962 for ; Thu, 27 Jan 2011 02:27:45 -0800 (PST) Received: by fxm9 with SMTP id 9so2141516fxm.31 for ; Thu, 27 Jan 2011 02:30:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=75Z4ETu2Zo2/rHh7yxNjM9b1klbLKUdlkc2VSlliQZI=; b=EXlj5EaP6UwUt20GcxefvyjdvAmlndBDOa7nBShorf3cnF3rQiBVP0V24KIpWZ+dJ7 HcNiAz3j2rpsXHE1fPaDFsr/mqZY/Gq+fR1ZKKzxifFJVgE9Hadf1UVdZLmfvRqX9zfm vqAQsNLhVvJmfpDV0jUDhhFeyThkL2g3O3xGE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=Ce7RPIL+XOxAp17jWhip5LQO0FamRcbNfnKQ5ADdKrBDzSX4iL1NhrX2AlvjUVx8cb d8x92dKJq0fiEPT7VhJOwQpjv3jeRYTO5XNbY1XPmxeCiB9qQqTgYzh4kEjW/sXx1c5R jaGw/o+QB4bPsHr3LjG7Aotgxr3ZiECjLjQPs= Received: by 10.223.74.200 with SMTP id v8mr685847faj.144.1296124247097; Thu, 27 Jan 2011 02:30:47 -0800 (PST) MIME-Version: 1.0 Sender: alcortesm.uc3m@gmail.com Received: by 10.223.110.135 with HTTP; Thu, 27 Jan 2011 02:30:27 -0800 (PST) In-Reply-To: <201101262035.p0QKZNZF021356@sj-core-5.cisco.com> References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <4D3EAF12.4050100@oracle.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> <201101262035.p0QKZNZF021356@sj-core-5.cisco.com> From: =?UTF-8?Q?Alberto_Cort=C3=A9s?= Date: Thu, 27 Jan 2011 11:30:27 +0100 X-Google-Sender-Auth: hp2ZDQsJ2Tz7Zz4DU1T97iLQYp8 Message-ID: Subject: Re: Quick Failover Algorithm in SCTP - question for the WG To: "James M. Polk" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org, Kacheong Poon X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 10:27:47 -0000 On Wed, Jan 26, 2011 at 9:35 PM, James M. Polk wrote: > Do others agree with this position, with the caveat that anything within = the > multipath ID regarding Quick Failover has to be in line with the Quick > Failover ID (i.e., they need to be in sync)? > > I want to hear from many on this before proceeding with anything. I=C2=B4m not sure: Does it makes sense to use CMT and Quick Failover *together*? If true, then they must be in sync, else they don=C2=B4t need to be in sync. Example: Is there any scenario where an association is using CMT over 3 paths, and then (quick) failover to another 3 different new paths (or any combination of new and old paths). --=20 Alberto Cort=C3=A9s-Mart=C3=ADn Telematic Engineering Dept. at UC3M http://www.it.uc3m.es/alcortes/index.html From Karen.Nielsen@tieto.com Thu Jan 20 04:58:46 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 760F43A7108 for ; Thu, 20 Jan 2011 04:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytmgJMA5d3IG for ; Thu, 20 Jan 2011 04:58:39 -0800 (PST) Received: from ebb06.tieto.com (ebb06.tieto.com [131.207.168.38]) by core3.amsl.com (Postfix) with ESMTP id DA1CA3A70FD for ; Thu, 20 Jan 2011 04:58:38 -0800 (PST) X-AuditID: 83cfa826-b7b8cae0000042cc-7a-4d3832202423 Received: from FIHGA-EXHUB01.eu.tieto.com ( [131.207.136.34]) by ebb06.tieto.com (SMTP Mailer) with SMTP id 3B.C1.17100.022383D4; Thu, 20 Jan 2011 15:01:21 +0200 (EET) Received: from EXMB03.eu.tieto.com ([131.207.136.30]) by FIHGA-EXHUB01.eu.tieto.com ([131.207.136.34]) with mapi; Thu, 20 Jan 2011 15:01:20 +0200 From: To: Date: Thu, 20 Jan 2011 15:01:19 +0200 Subject: FW: multipath congestion control and RFC 2861 Thread-Topic: multipath congestion control and RFC 2861 Thread-Index: Acu4n5MaZobdsoAHS1KIkcenzzvUWwAAgc+w Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CF340E42AED0874C81947E18863DE77B0A52F0F0E5EXMB03eutieto_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAARci5Uo= X-Mailman-Approved-At: Thu, 27 Jan 2011 04:49:56 -0800 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 12:58:47 -0000 --_000_CF340E42AED0874C81947E18863DE77B0A52F0F0E5EXMB03eutieto_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Equally relevant for the work on CMT-SCTP - draft-tuexen-tsvwg-sctp-multipa= th-01.txt Therefore forwarded here as well. BR, Karen _____________________________________________ From: Nielsen Karen Sent: 20. januar 2011 13:43 To: multipathtcp Subject: multipath congestion control and RFC 2861 Hi, In the context of multipath TCP and coupled congestion control, I am wonder= ing what the thoughts are in respect to the limitation put on growth of not fully utilized congestion windows by RF= C 2861 - as exemplified by the following text from RFC 2861. "For the separate issue of the increase of the congestion window in response to an acknowledgement, we believe the correct behavior is for the sender to increase the congestion window only if the window was full when the acknowledgment arrived." The question seems relevant in connection with multipath TCP as it impacts = to willingness (and possibility) of TCP to "instantly" redistribute traffic from one failed path to other pa= ths - or perhaps more strictly speaking: to have n-1 paths absorb the traffic previously distributed on n paths. Also the issue becomes very relevant when discussing the applicability of t= he multipath congestion control to SCTP (CMT-SCTP) as SCTP (RFC 4960) in text at least (not sure about all implementations) i= ncorporates the RFC 2861 constrains on growth of not utilized CWNDs. Thanks. BR, Karen ***************************************************************************= ************** Karen Egede Nielsen Software Architect, Ph.D. Tieto Denmark A/S IP Solutions, Telecom & Media Skanderborgvej 232, 8260 Viby J, DK-Denmark Direct Phone / Mobile +45 25134336 E-mail: karen.nielsen@tieto.com ***************************************************************************= ************** www.tieto.com Please note: The information contained in this message may be legally privi= leged and confidential and protected from disclosure. If the reader of this= message is not the intended recipient, you are hereby notified that any un= authorised use, distribution or copying of this communication is strictly p= rohibited. If you have received this communication in error, please notify = us immediately by replying to the message and deleting it from your compute= r. Thank You. --_000_CF340E42AED0874C81947E18863DE77B0A52F0F0E5EXMB03eutieto_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Equally relevant = for the work on CMT-SCTP – draft-tuexen-tsvwg-sctp-multipath-01.txt
Therefore forward= ed here as well.
 
BR, Karen<= /div>
 
_________________________= ____________________
From: Nielsen Karen
Sent: 20. januar 2011 13:43
To: multipathtcp
Subject: multipath congestion control and RFC 2861
 
 
Hi,
 
In the context of multipath TCP and coupled congestion control, I am w= ondering what the thoughts are in respect to
the limitation put on growth of not fully utilized congestion windows = by RFC 2861 – as exemplified by the following text from RFC 2861.
 
  "For the sep= arate issue of the increase of the congestion window in
   response to= an acknowledgement, we believe the correct behavior is
   for the sen= der to increase the congestion window only if the window
   was full wh= en the acknowledgment arrived."
 
The question seems relevant in connection with multipath TCP as it imp= acts to willingness (and possibility)
of TCP to “instantly” redistribute traffic from one failed= path to other paths – or perhaps more strictly speaking: to have n-1= paths absorb
the traffic previously distributed on n paths.
 
Also the issue becomes very relevant when discussing the applicability= of the multipath congestion control to SCTP (CMT-SCTP)
as SCTP (RFC 4960)  in text at least (not sure about all implemen= tations) incorporates the RFC 2861 constrains on growth of not utilized CWN= Ds.
 
Thanks.
 
BR, Karen
 
 
***********************= ******************************************************************
Karen Egede Nielsen=
Software Architect, Ph.D.<= /font>
 
Tieto Denmark A/S
IP Solutions, Telecom &= ; Media
Skanderborgvej 232, 8260 V= iby J, DK-Denmark
Direct Phone / Mobile += ;45 25134336
E-mail: karen.nielsen@tiet= o.com
**************************= ***************************************************************
 
Please note: The inform= ation contained in this message may be legally privileged and confidential = and protected from disclosure. If the reader of this message is not the int= ended recipient, you are hereby notified that any unauthorised use, distribution or copying of this communication is= strictly prohibited. If you have received this communication in error, ple= ase notify us immediately by replying to the message and deleting it from y= our computer. Thank You.
 
 
 
 
 
--_000_CF340E42AED0874C81947E18863DE77B0A52F0F0E5EXMB03eutieto_-- From cabo@tzi.org Thu Jan 27 01:17:10 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 757CF28C123; Thu, 27 Jan 2011 01:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.307 X-Spam-Level: X-Spam-Status: No, score=-106.307 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUpGDrwDF7FN; Thu, 27 Jan 2011 01:17:09 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by core3.amsl.com (Postfix) with ESMTP id 89A0E28C10E; Thu, 27 Jan 2011 01:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p0R9K1IM005984; Thu, 27 Jan 2011 10:20:01 +0100 (CET) Received: from [192.168.10.52] (christoph.dagstuhl.de [192.76.146.51]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F37BE40E; Thu, 27 Jan 2011 10:19:59 +0100 (CET) Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Thu, 27 Jan 2011 10:20:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110118212603.5733.34489.idtracker@localhost> To: Lars Eggert X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Thu, 27 Jan 2011 04:49:56 -0800 Cc: tsvwg@ietf.org, IETF discussion list , Paul Hoffman , IESG IESG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 09:17:10 -0000 On Jan 27, 2011, at 09:52, Lars Eggert wrote: >> all new protocols should >> be security-capable Sure. How is this relevant? In some protocols, there is value to use them without communication = security (think TLS) for some applications, and with communication = security for others. We used to distinguish these two cases using two ports, now we use a = single port plus per-connection negotiation like STARTLS. I think the draft is trying to encourage this conversion, and I agree = with this, at least where latency is less relevant. With UDP-based protocols, it is harder to do this. Please look at section 7.3 of = http://tools.ietf.org/html/draft-ietf-core-coap-04.html#section-7.3 and tell us whether this is how you would like this to be handled for = UDP-based protocols in the future. If not, we may want to add to the guidance in the (tsvwg) draft. Gruesse, Carsten From Karen.Nielsen@tieto.com Thu Jan 27 03:17:06 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB3F628C125 for ; Thu, 27 Jan 2011 03:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMgl1wDh-6uH for ; Thu, 27 Jan 2011 03:17:06 -0800 (PST) Received: from ebb06.tieto.com (ebb06.tieto.com [131.207.168.38]) by core3.amsl.com (Postfix) with ESMTP id 9BE803A688E for ; Thu, 27 Jan 2011 03:17:05 -0800 (PST) X-AuditID: 83cfa826-b7ca6ae000000a25-a2-4d4154e74b4d Received: from FIHGA-EXHUB01.eu.tieto.com ( [131.207.136.34]) by ebb06.tieto.com (SMTP Mailer) with SMTP id BA.5F.02597.7E4514D4; Thu, 27 Jan 2011 13:20:07 +0200 (EET) Received: from EXMB03.eu.tieto.com ([131.207.136.30]) by FIHGA-EXHUB01.eu.tieto.com ([131.207.136.34]) with mapi; Thu, 27 Jan 2011 13:20:07 +0200 From: To: , Date: Thu, 27 Jan 2011 13:20:06 +0200 Subject: RE: Quick Failover Algorithm in SCTP Thread-Topic: Quick Failover Algorithm in SCTP Thread-Index: Acu4Gkvps1nGu1SBRMiHZOcBMwX5DAAAFvhwAX4tNdA= Message-ID: References: <201101192048.p0JKmYoO012572@sj-core-1.cisco.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Thu, 27 Jan 2011 04:49:56 -0800 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 11:17:06 -0000 Our STCP stack implementation, used in high end Telecom signaling nodes, im= plements the potentially failed feature and has done it since the=20 beginning of deployment 3-4 years back. We think the feature is equally imp= ortant for CMT-SCTP as for standard (non-CMT) 4960 SCTP. We have not deploy= ed an CMT STP setting (yet). Until recently we have operated with a PFMR thres= hold of about PMR/2, but recently we have changed this threshold to 0,=20 meaning failover after one retransmission timeout. BR, Karen ***************************************************************************= ************** Karen Egede Nielsen Software Architect, Ph.D. Tieto Denmark A/S IP Solutions, Telecom & Media Skanderborgvej 232, 8260 Viby J, DK-Denmark Direct Phone / Mobile +45 25134336 E-mail: karen.nielsen@tieto.com ***************************************************************************= ************** -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of D= avid Lehmann Sent: 19. januar 2011 21:57 To: tsvwg@ietf.org Subject: RE: Quick Failover Algorithm in SCTP > >What is the next step in the process? >=20 > The status of this ID is that of an individual > submission, with a target WG of TSVWG. The chairs > currently believe there has been insufficient > review within the WG to date to warrant > progressing this document to the next level. Your > note obviously helps the chairs determine if > there is interest in this effort. We thank you > for the comment. More comments (that show there > was a review per comment, preferably) will nudge > us towards reviewing progression of this effort. >=20 > Does this seem reasonable? Yes. =20 Those in favor of this document, please speak up! =20 Thank you. -David From Karen.Nielsen@tieto.com Thu Jan 27 03:47:57 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EC4B3A698D for ; Thu, 27 Jan 2011 03:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlyTfIHZy6e6 for ; Thu, 27 Jan 2011 03:47:56 -0800 (PST) Received: from ebb05.tieto.com (ebb05.tieto.com [131.207.168.36]) by core3.amsl.com (Postfix) with ESMTP id 7D74A28C13B for ; Thu, 27 Jan 2011 03:47:55 -0800 (PST) X-AuditID: 83cfa824-b7c66ae000000a29-4b-4d415c21f966 Received: from FIVLA-EXHUB02.eu.tieto.com ( [131.207.136.42]) by ebb05.tieto.com (SMTP Mailer) with SMTP id F9.D7.02601.12C514D4; Thu, 27 Jan 2011 13:50:58 +0200 (EET) Received: from EXMB03.eu.tieto.com ([131.207.136.30]) by FIVLA-EXHUB02.eu.tieto.com ([131.207.136.42]) with mapi; Thu, 27 Jan 2011 13:50:57 +0200 From: To: , Date: Thu, 27 Jan 2011 13:50:57 +0200 Subject: Transmission of DATA Chunks - question on CMT SCTP Thread-Topic: Transmission of DATA Chunks - question on CMT SCTP Thread-Index: Acu+GHWnvdq0027TR82egdLIA61OHw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CF340E42AED0874C81947E18863DE77B0A52FB6D22EXMB03eutieto_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAARci5Uo= X-Mailman-Approved-At: Thu, 27 Jan 2011 04:49:56 -0800 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 11:47:57 -0000 --_000_CF340E42AED0874C81947E18863DE77B0A52FB6D22EXMB03eutieto_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In RFC 4960 Section 6.1 it is stated that transmission of new data should a= wait retransmissions. That is: C) When the time comes for the sender to transmit, before sending new DATA chunks, the sender MUST first transmit any outstanding DATA chunks that are marked for retransmission (limited by the current cwnd). In our SCTP implementation we have followed this rule literally on a per as= sociation basis. That is, we do not send new data on any path of the associ= ation, if there is data marked for retransmission which is awaiting transmittal. But I also= know of SCTP implementations where this rule is obeyed only on an path bas= is. I.e. data for retransmission is somehow locked to a particular path and new data may flow out on other p= aths even if there is data waiting to be retransmitted on a per association= basis. I would like to know if anybody knows what is the chosen approach in the CM= T setting in this respect - ? Also I am interesting in knowing if there is any clear consensus on how th= e RFC 4690 should be interpreted in the non CMT case - ? Thanks ! BR, Karen ***************************************************************************= ************** Karen Egede Nielsen Software Architect, Ph.D. Tieto Denmark A/S IP Solutions, Telecom & Media Skanderborgvej 232, 8260 Viby J, DK-Denmark Direct Phone / Mobile +45 25134336 E-mail: karen.nielsen@tieto.com ***************************************************************************= ************** www.tieto.com --_000_CF340E42AED0874C81947E18863DE77B0A52FB6D22EXMB03eutieto_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
In RFC 4960 Section 6.1 it is stated that transmission of new data sho= uld await retransmissions.
That is:
 
   C) When = the time comes for the sender to transmit, before sending new
   &nb= sp;  DATA chunks, the sender MUST first transmit any outstanding DATA<= /font>
   &nb= sp;  chunks that are marked for retransmission (limited by the current=
   &nb= sp;  cwnd).
 
In our SCTP implementation we have followed this rule literally on a p= er association basis. That is, we do not send new data on any path of the a= ssociation, if there
is data marked for retransmission which is awaiting transmittal. But I= also know of SCTP implementations where this rule is obeyed only on an pat= h basis. I.e. data for retransmission
is somehow locked to a particular path and new data may flow out on ot= her paths even if there is data waiting to be retransmitted on a per associ= ation basis.
 
I would like to know if anybody knows what is the chosen approach in t= he CMT setting in this respect  - ?
 
Also I am interesting in knowing  if there is any clear consensus= on how the RFC 4690 should be interpreted in the non CMT case - ?
 
Thanks !
 
BR, Karen
 
 
***********************= ******************************************************************
Karen Egede Nielsen=
Software Architect, Ph.D.<= /font>
 
Tieto Denmark A/S
IP Solutions, Telecom &= ; Media
Skanderborgvej 232, 8260 V= iby J, DK-Denmark
Direct Phone / Mobile += ;45 25134336
E-mail: karen.nielsen@tiet= o.com
**************************= ***************************************************************
 
 
 
--_000_CF340E42AED0874C81947E18863DE77B0A52FB6D22EXMB03eutieto_-- From Michael.Tuexen@lurchi.franken.de Thu Jan 27 05:29:14 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFF553A67B3 for ; Thu, 27 Jan 2011 05:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdyfCMREPraz for ; Thu, 27 Jan 2011 05:29:13 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 6C0A43A6452 for ; Thu, 27 Jan 2011 05:29:13 -0800 (PST) Received: from [192.168.1.113] (p508FCC98.dip.t-dialin.net [80.143.204.152]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 32DF41C0C0BCC; Thu, 27 Jan 2011 14:32:14 +0100 (CET) Subject: Re: Quick Failover Algorithm in SCTP - question for the WG Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <201101262035.p0QKZNZF021356@sj-core-5.cisco.com> Date: Thu, 27 Jan 2011 14:32:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5F833010-36E7-4863-86D5-29D9B4E8DA19@lurchi.franken.de> References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <4D3EAF12.4050100@oracle.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> <201101262035.p0QKZNZF021356@sj-core-5.cisco.com> To: James M. Polk X-Mailer: Apple Mail (2.1082) Cc: tsvwg@ietf.org, Kacheong Poon X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 13:29:14 -0000 On Jan 26, 2011, at 9:35 PM, James M. Polk wrote: > At 01:56 PM 1/25/2011, David Lehmann wrote: >> IMHO, there are a few reasons to move forward with Quick Failover. >> (1) Quick Failover seems to be less complex, which will allow more >> timely approval/implementation. As Kacheong pointed out, "Doing it = does >> not require co-operation from the receiver side. There is not much = side >> effect (should not introduce congestion for example)...". >> (2) Although the current spec may allow quick failover, it implies an >> unacceptably long wait time before failover. I don't think Solaris = or >> Linux has quick failover. Let's say that one does implement it. Now = we >> have two major implementations with quite noticeable behavior >> differences. IMHO, users should expect consistent behavior across = all >> SCTP implementations. >> (3) As Dr. Dreibholz noted, CMT will also benefit from Quick = Failover. >> The CMT spec can reference Quick Failover. >=20 > Do others agree with this position, with the caveat that anything = within the multipath ID regarding Quick Failover has to be in line with = the Quick Failover ID (i.e., they need to be in sync)? Hi James, I think the Quick Failover makes sense for scenarios where CMT is = currently not deployed yet. These implementations focus on standards track = protocols and having a documented method for this, being a standards track = document does make sense. It can easily be deployed since it is a sender side = only thing. We already have the situation that FreeBSD, Linux and Solaris = show different behavior for detecting path failures. For writing portable applications this is not useful. Originally I was hesitating to support quick failover, as indicated in a discussion at an IETF, but changed my mind. It would be helpful to have a standardized method for this. CMT also needs to detect a path failure. We could just refer the Quick Failover ID for this. So we would avoid duplicating the work. Please note the the intended status for the CMT ID is experimental. Only have a failure detection in an experimental document does not seem to be optimal to me. I'm willing to continue contributing to the Quick Failover ID by providing review comments and even text if it is applicable. The Quick Failover ID needs a section for the socket API, for example. Best regards Michael >=20 > I want to hear from many on this before proceeding with anything. >=20 > James > TSVWG chair >=20 >=20 >> -- >> David Lehmann >> Ulticom, Inc. >> 856-787-2952 >=20 >=20 From dreibh@iem.uni-due.de Thu Jan 27 07:23:12 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F6E83A68DE for ; Thu, 27 Jan 2011 07:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UC0WOAE6Mhm0 for ; Thu, 27 Jan 2011 07:23:11 -0800 (PST) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by core3.amsl.com (Postfix) with ESMTP id D33483A68C5 for ; Thu, 27 Jan 2011 07:23:09 -0800 (PST) Received: from lupo.localnet ([132.252.151.81]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id p0RFPr0V026453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Jan 2011 16:26:08 +0100 From: Thomas Dreibholz Organization: University of Duisburg-Essen, Institute for Experimental Mathematics To: tsvwg@ietf.org Subject: Re: Quick Failover Algorithm in SCTP - question for the WG Date: Thu, 27 Jan 2011 14:15:47 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.37dreibholz; KDE/4.5.5; x86_64; ; ) References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1475654.vXBnV1JxHL"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201101271415.52688.dreibh@iem.uni-due.de> 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: "James M. Polk" , Kacheong Poon X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 15:23:12 -0000 --nextPart1475654.vXBnV1JxHL Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, On Dienstag 25 Januar 2011, David Lehmann wrote: > IMHO, there are a few reasons to move forward with Quick Failover. > (1) Quick Failover seems to be less complex, which will allow more > timely approval/implementation. As Kacheong pointed out, "Doing it does > not require co-operation from the receiver side. There is not much side > effect (should not introduce congestion for example)...". > (2) Although the current spec may allow quick failover, it implies an > unacceptably long wait time before failover. I don't think Solaris or > Linux has quick failover. Let's say that one does implement it. Now we > have two major implementations with quite noticeable behavior > differences. IMHO, users should expect consistent behavior across all > SCTP implementations. Significant difference in implementation behaviour is a very bad thing. The= =20 experience from RSPLIB (i.e. the RSerPool implementation, see=20 http://tdrwww.exp-math.uni-essen.de/dreibholz/rserpool/), which supports=20 multiple operating systems and therefore different SCTP stacks, is that=20 actually the application has to detect that there is no real transmission=20 progress in case of a path failure -- and either wait for SCTP to switch th= e=20 primary path (which takes unacceptably long for this kind of application) o= r=20 trigger a session failover (expensive). From the application writer's=20 perspective, a consistent behaviour of the underlying SCTP implementations= =20 would make things a lot easier. > (3) As Dr. Dreibholz noted, CMT will also benefit from Quick Failover. > The CMT spec can reference Quick Failover. This is currently done in draft-tuexen-tsvwg-multipath-sctp-01. Best regards =2D-=20 =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 Dr. Thomas Dreibholz University of Duisburg-Essen, Room ES210 Inst. for Experimental Mathematics Ellernstra=DFe 29 Computer Networking Technology Group D-45326 Essen/Germany =2D---------------------------------------------------------------------- E-Mail: dreibh@iem.uni-due.de Homepage: http://www.iem.uni-due.de/~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 --nextPart1475654.vXBnV1JxHL Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1BcAUACgkQ32BbsHYPLWXOywCeOFHw5jXZNPJiQVqHDb/tjtTe EioAoKcB4w7sKyiAXrOMcZP+L54kooWH =SD31 -----END PGP SIGNATURE----- --nextPart1475654.vXBnV1JxHL-- From acaro@bbn.com Thu Jan 27 08:40:52 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47F913A690E for ; Thu, 27 Jan 2011 08:40:52 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZS2MqO9z2jM for ; Thu, 27 Jan 2011 08:40:51 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 8A9FD3A681B for ; Thu, 27 Jan 2011 08:40:51 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:42149 helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PiUwt-000369-3u for tsvwg@ietf.org; Thu, 27 Jan 2011 11:43:55 -0500 Message-ID: <4D41A0CB.9080009@bbn.com> Date: Thu, 27 Jan 2011 11:43:55 -0500 From: Armando Caro User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: Quick Failover Algorithm in SCTP - question for the WG References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> <201101271415.52688.dreibh@iem.uni-due.de> In-Reply-To: <201101271415.52688.dreibh@iem.uni-due.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 16:40:52 -0000 On 01/27/2011 08:15 AM, Thomas Dreibholz wrote: > Significant difference in implementation behaviour is a very bad thing. I think it's not ideal, but it may not be a very bad thing. It depends on how the application is written. > From the application writer's > perspective, a consistent behaviour of the underlying SCTP implementations > would make things a lot easier. It might, but I don't think applications should optimize on assumptions about the parameter settings of the network stack. With that said, I do think that the quick failover algorithm makes sense to adopt as a WG item. Research results (and I'm guessing practical experience) have shown little (any?) downsides to using this algorithm, and the advantages are clear. Armando From Michael.Tuexen@lurchi.franken.de Thu Jan 27 10:08:23 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88B0A28C145 for ; Thu, 27 Jan 2011 10:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaEScZJVymG1 for ; Thu, 27 Jan 2011 10:08:22 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 51F623A681F for ; Thu, 27 Jan 2011 10:08:22 -0800 (PST) Received: from [192.168.1.113] (p508FCC98.dip.t-dialin.net [80.143.204.152]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 5FD461C0B4626; Thu, 27 Jan 2011 19:11:24 +0100 (CET) Subject: Re: Quick Failover Algorithm in SCTP - question for the WG Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <4D41A0CB.9080009@bbn.com> Date: Thu, 27 Jan 2011 19:11:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <38E19B53-7098-4204-A9DB-C05D3B97211F@lurchi.franken.de> References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> <201101271415.52688.dreibh@iem.uni-due.de> <4D41A0CB.9080009@bbn.com> To: Armando Caro X-Mailer: Apple Mail (2.1082) Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 18:08:23 -0000 On Jan 27, 2011, at 5:43 PM, Armando Caro wrote: > On 01/27/2011 08:15 AM, Thomas Dreibholz wrote: >> Significant difference in implementation behaviour is a very bad = thing. >=20 > I think it's not ideal, but it may not be a very bad thing. It depends = on how the application is written. >=20 >> =46rom the application writer's >> perspective, a consistent behaviour of the underlying SCTP = implementations >> would make things a lot easier. >=20 > It might, but I don't think applications should optimize on = assumptions about the parameter settings of the network stack. Hi Armando, when writing an application using SCTP which has to fulfill some = requirements on failover time I have to tweak the transport parameters to get that = feature. Currently I have to do that very platform specific. Even the same = parameter means different things on different platforms. So having a portable way to get some predefined failover behavior makes = sense to me... Best regards Michael >=20 > With that said, I do think that the quick failover algorithm makes = sense to adopt as a WG item. Research results (and I'm guessing = practical experience) have shown little (any?) downsides to using this = algorithm, and the advantages are clear. >=20 > Armando >=20 >=20 >=20 From bidulock@openss7.org Thu Jan 27 10:17:21 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD0CA3A681F for ; Thu, 27 Jan 2011 10:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.378 X-Spam-Level: X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEZu0d89k-r3 for ; Thu, 27 Jan 2011 10:17:20 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id B037E3A65A5 for ; Thu, 27 Jan 2011 10:17:20 -0800 (PST) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0RIKKi4030834; Thu, 27 Jan 2011 11:20:20 -0700 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0RIKKQr011123; Thu, 27 Jan 2011 11:20:20 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p0RIKJ5R011122; Thu, 27 Jan 2011 11:20:19 -0700 Date: Thu, 27 Jan 2011 11:20:19 -0700 From: "Brian F. G. Bidulock" To: Michael =?iso-8859-1?Q?T=FCxen?= Subject: Re: Quick Failover Algorithm in SCTP - question for the WG Message-ID: <20110127182019.GA9885@openss7.org> Mail-Followup-To: Michael =?iso-8859-1?Q?T=FCxen?= , "James M. Polk" , tsvwg@ietf.org, Kacheong Poon References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <4D3EAF12.4050100@oracle.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> <201101262035.p0QKZNZF021356@sj-core-5.cisco.com> <5F833010-36E7-4863-86D5-29D9B4E8DA19@lurchi.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5F833010-36E7-4863-86D5-29D9B4E8DA19@lurchi.franken.de> Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Kacheong Poon , "James M. Polk" , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 18:17:21 -0000 Michael, Michael Tüxen wrote: (Thu, 27 Jan 2011 14:32:13) > Please note the the intended status for the CMT ID is experimental. > Only have a failure detection in an experimental document does not > seem to be optimal to me. That brings up another point: I think that the failover ID should be INFORMATIONAL (if anything) and the CMT ID should be Standards Track. I see little point in making the CMT ID EXPERIMENTAL as there are many implementations that have been running in the wild for over a decade; and, particularly where some approaches have been identified by some as harmful to the Internet (i.e. CMT through a shared bottleneck). OTOH, the failover ID should be INFORMATIONAL because it is entirely optional, is only one of many approaches for doing such a thing (none of which have been identified as harmful); and, is a performance-only related "implementation detail". I agree with Kacheong's characterization of these IDs, and I believe the change in intended status is consistent with that characterization. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From Michael.Tuexen@lurchi.franken.de Thu Jan 27 11:17:13 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26D8E28C152 for ; Thu, 27 Jan 2011 11:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMS07FSNTl8B for ; Thu, 27 Jan 2011 11:17:12 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id BD7663A69FB for ; Thu, 27 Jan 2011 11:17:11 -0800 (PST) Received: from [192.168.1.113] (p508FCC98.dip.t-dialin.net [80.143.204.152]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id D22D41C0C0BCA; Thu, 27 Jan 2011 20:20:14 +0100 (CET) Subject: Re: Quick Failover Algorithm in SCTP - question for the WG Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <20110127182019.GA9885@openss7.org> Date: Thu, 27 Jan 2011 20:20:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <080A142D-0E58-4CB2-A109-3C902EBC7CAF@lurchi.franken.de> References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <4D3EAF12.4050100@oracle.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> <201101262035.p0QKZNZF021356@sj-core-5.cisco.com> <5F833010-36E7-4863-86D5-29D9B4E8DA19@lurchi.franken.de> <20110127182019.GA9885@openss7.org> To: bidulock@openss7.org X-Mailer: Apple Mail (2.1082) Cc: Kacheong Poon , "James M. Polk" , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 19:17:13 -0000 On Jan 27, 2011, at 7:20 PM, Brian F. G. Bidulock wrote: > Michael, >=20 > Michael T=FCxen wrote: (Thu, 27 Jan 2011 = 14:32:13) >=20 >> Please note the the intended status for the CMT ID is experimental. >> Only have a failure detection in an experimental document does not >> seem to be optimal to me. >=20 > That brings up another point: I think that the failover ID should > be INFORMATIONAL (if anything) and the CMT ID should be Standards > Track. I would vote for Proposed Standard for the failover ID and Experimental for CMT. >=20 > I see little point in making the CMT ID EXPERIMENTAL as there are many > implementations that have been running in the wild for over a decade; > and, particularly where some approaches have been identified by some > as harmful to the Internet (i.e. CMT through a shared bottleneck). We would use the coupled congestion control from the MPTCP WG, which is experimental. So I would see, at least initially, SCTP loadsharing also as Experimental. >=20 > OTOH, the failover ID should be INFORMATIONAL because it is entirely > optional, is only one of many approaches for doing such a thing (none > of which have been identified as harmful); and, is a performance-only > related "implementation detail". Only because it is PS doesn't mean that you have to implement it. Supporting it is not mandatory. Best regards Michael >=20 > I agree with Kacheong's characterization of these IDs, and I believe > the change in intended status is consistent with that = characterization. >=20 > --brian >=20 > --=20 > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ >=20 From jeff.morriss.ws@gmail.com Thu Jan 27 11:20:34 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78D3B3A69A2 for ; Thu, 27 Jan 2011 11:20:34 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQOIbF04ALU9 for ; Thu, 27 Jan 2011 11:20:32 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 4E19728C160 for ; Thu, 27 Jan 2011 11:20:32 -0800 (PST) Received: by vws7 with SMTP id 7so931861vws.31 for ; Thu, 27 Jan 2011 11:23:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=o02Rt5vnj6mrUPKpGPri/adlZNzvV0doYGbI886DmD4=; b=DYAZHb/xDcvBL3h0nquCp/A3HzVEYjUaSc5ZFhnztCJo+TIJsT8fuNOE1zqhp5ntMQ 8BFiZR+gb0gMhCIgAI05rNZxXeeZq0DS7bciV9lGgsckfpZed7iJcc6ISl5AKKZHG09E BuMZlGTGc0dsv1Wf8xLRKOS/xlzZ+0ly9aUTY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=s+X9FWKuSHW5YwNiBcLZVOekCNDWCiT0osJgWmbXqaUzmxse7RGTshcdv/ljN+AsaC BL+Vyz32BAD64UI7rbGLav3ZUMoBG0KBHIS1chGMVCojh+n/U7dRdD7zTmHL0xXW+iLS eR5AgQcgocFf6kugZSZRHWwQjtplwaBkfpIhM= Received: by 10.220.183.4 with SMTP id ce4mr365910vcb.132.1296156216148; Thu, 27 Jan 2011 11:23:36 -0800 (PST) Received: from nj-morriss-test.ulticom.com (208-255-121-30.ulticom.com [208.255.121.30]) by mx.google.com with ESMTPS id u6sm10470427vby.17.2011.01.27.11.23.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 27 Jan 2011 11:23:34 -0800 (PST) Message-ID: <4D41C635.4070305@gmail.com> Date: Thu, 27 Jan 2011 14:23:33 -0500 From: Jeff Morriss User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: tsvwg@ietf.org Subject: Re: Quick Failover Algorithm in SCTP - question for the WG References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <4D3EAF12.4050100@oracle.com> In-Reply-To: <4D3EAF12.4050100@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kacheong Poon X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 19:20:34 -0000 Kacheong Poon wrote: > On 01/25/11 09:31 AM, James M. Polk wrote: >> (with my chair hat on) >> >> ISTM that the WG has to answer the following question before either this >> "-nishida-" ID or the "-tuexen-...-multipath-" ID progress (and if >> either does): >> >> Does the WG feel CMT needs to be accounted for (or involved) in >> whatever the solution is here? > > > I think the ID "-nishida-" can be considered as "implementation > details." The reason is that RFC 4960 does not prohibit a stack > from doing quick failover. And as David pointed out before, there > are existing stacks which do it already. Doing it does not require > co-operation from the receiver side. There is not much side effect > (should not introduce congestion for example) on the network as > communication between the end points is still on one path. Hence > it is not necessary for the WG to standardize a mechanism. Note > that I am not objecting to such as effort, just that it is not > necessary IMHO. If there are many implementations already doing it then clearly there is a need. (I know first hand of several such needs.) As an SCTP user, I don't want my choice (if/when I have one) of which SCTP to use to be dictated by which implementations have gone beyond what is standardized to give me what I need. And I don't want to be put in a difficult situation (well described in sections 4.1 and 4.2 of the I-D) when I don't have a choice of which SCTP to use. In other words, I have the opposite conclusion: if several/many implementations have found it necessary then it _should_ be standardized. > I think they can be separated. Ideally, an app can choose how > an SCTP stack utilizes the different paths. If an app just wants > to use one path (say because alternate paths are expensive to use), > quick failover is applicable. If an app wants to utilizes all paths > simultaneously, CMT is used and how to do retransmission becomes part > of the CMT algorithm. My $.02 as a user: basically every project where I've seen SCTP used has needed fast path failover. Some could benefit from CMT, but it is (from my point of view from those projects) only an optimization. It would be nice to have but I can live without it. I have found that life without quick failover... Is painful at best but is sometimes impossible (requirements cannot be met). From jana.iyengar@gmail.com Thu Jan 27 11:28:42 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3BDD28C16C for ; Thu, 27 Jan 2011 11:28:42 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3Mq96cv9d22 for ; Thu, 27 Jan 2011 11:28:41 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 7FD0E28C167 for ; Thu, 27 Jan 2011 11:28:41 -0800 (PST) Received: by vws7 with SMTP id 7so935033vws.31 for ; Thu, 27 Jan 2011 11:31:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:reply-to:organization :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=2LWy5VllpkuY41UF9Mq3UBg9uFpffz3ELu+29f5EkLY=; b=bpEvmDUt8nv/XzwOkAyG302fc+J/xcIJLQ+v9PZeev9E6wxKnSSWnXEG6rZPUIJUT3 +eJK11DnkJ/qhHiUNQvnhGjXcXGEElslDnNeGvuHuO3km2n8w7Ame4cPmy4Z9QA08AFs Bi37Jww+VtPe5Wbv0MwyDryJUHiMXv0oSkg4M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:subject:references:in-reply-to:content-type :content-transfer-encoding; b=Nl092UZ5RO++ZZvnbctZjeymaPEj7Uirzo//rowOInqB89SAhHsEE1As9I0/1BHbLn F4RRmAjxy006QBjpc9xi5ow7qHeo70weFyVPS9jeoYn3ETmcgL/nTvAvR33D02amUmF3 THj+6OiEEcK7enw1htNy/rr35vi3b8RJr+YFc= Received: by 10.220.159.67 with SMTP id i3mr363348vcx.246.1296156704079; Thu, 27 Jan 2011 11:31:44 -0800 (PST) Received: from surutti.fandm.edu (dhcp-155-68-162-85.fandm.edu [155.68.162.85]) by mx.google.com with ESMTPS id q5sm5723229vcr.39.2011.01.27.11.31.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 27 Jan 2011 11:31:40 -0800 (PST) Message-ID: <4D41C818.3050607@fandm.edu> Date: Thu, 27 Jan 2011 14:31:36 -0500 From: Janardhan Iyengar Organization: Franklin & Marshall College User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "James M. Polk" , TSWG Subject: Re: Quick Failover Algorithm in SCTP - question for the WG References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <4D3EAF12.4050100@oracle.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> In-Reply-To: <201101251916.p0PJGm76021999@sj-core-3.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: janardhan.iyengar@fandm.edu List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 19:28:42 -0000 James, [I can review draft-nishida and contrib text.] Some of these points have been said, but I'm simply adding my opinion to the pool. In my presentation in Maastricht, I proposed that if CMT (draft-tuexen) was to be adopted, then draft-nishida could be brought in under that umbrella. The PF-state may have performance impact in SCTP, but it has significant impact on CMT performance when path failure occurs. And so... >>> ITSM the "-nishida-" ID address the problem area, but >>> "-tuexen-...-multipath-" ID addresses a superset of the problem area. ... I wouldn't consider draft-tuexen as addressing a superset of draft-nishida, but as a significant use case of draft-nishida. Without draft-nishida, the PF mechanism would have to be defined in draft-tuexen. draft-nishida can exist on its own, and if so, the mechanism will be used by CMT as well. > I think I'm gathering that if these are separate efforts, they must align (i.e., one is the super-set of the other). That makes me question whether the use-case for the subset doc is worth doing if the super-set doc can be done effectively and in a timely manner. They need to be "loosely aligned". While I suspect it will not be necessary, the CMT authors can ensure that we consider any impact of draft-nishida on draft-tuexen, and raise them for consideration. We can then simply cite draft-nishida, and not redefine the same mechanisms in draft-tuexen. > Are these two sufficiently different problem-spaces? > Obviously, if these two efforts are covering separate problem spaces, however close they are to each other, it appears we want to address both if we can. I need to understand if we need two efforts to cover problem spaces that are real close to each other, or can the efforts be combined into one effort? There are at least two reasons to consider two separate efforts: (i) draft-nishida is useful for SCTP, even without draft-tuexen. (ii) Practically, draft-nishida is simpler and thus likely to move faster through the wg than draft-tuexen. - jana -- Janardhan Iyengar Assistant Professor, Computer Science Franklin & Marshall College http://www.fandm.edu/jiyengar From bidulock@openss7.org Thu Jan 27 11:34:51 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8FDE28C172 for ; Thu, 27 Jan 2011 11:34:51 -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.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QMo1yoMamh1 for ; Thu, 27 Jan 2011 11:34:51 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id B654C28C160 for ; Thu, 27 Jan 2011 11:34:50 -0800 (PST) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0RJbb9k032098; Thu, 27 Jan 2011 12:37:37 -0700 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0RJba4F012272; Thu, 27 Jan 2011 12:37:36 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p0RJbagF012271; Thu, 27 Jan 2011 12:37:36 -0700 Date: Thu, 27 Jan 2011 12:37:36 -0700 From: "Brian F. G. Bidulock" To: Michael =?iso-8859-1?Q?T=FCxen?= Subject: Re: Quick Failover Algorithm in SCTP - question for the WG Message-ID: <20110127193736.GB9885@openss7.org> Mail-Followup-To: Michael =?iso-8859-1?Q?T=FCxen?= , Armando Caro , tsvwg@ietf.org References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> <201101271415.52688.dreibh@iem.uni-due.de> <4D41A0CB.9080009@bbn.com> <38E19B53-7098-4204-A9DB-C05D3B97211F@lurchi.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <38E19B53-7098-4204-A9DB-C05D3B97211F@lurchi.franken.de> Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 19:34:52 -0000 Michael, Michael Tüxen wrote: (Thu, 27 Jan 2011 19:11:23) > when writing an application using SCTP which has to fulfill some requirements > on failover time I have to tweak the transport parameters to get that feature. > > Currently I have to do that very platform specific. Even the same parameter > means different things on different platforms. > > So having a portable way to get some predefined failover behavior makes sense > to me... Your problem appears to be more of an API issue than a standardization of "implementation details". An API feature that indicates that the application wants 'quickest failover' would appear to provide what you need without unnecessarily constraining how the implementation achieves that. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From bidulock@openss7.org Thu Jan 27 11:52:04 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28A683A6A1F for ; Thu, 27 Jan 2011 11:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.37 X-Spam-Level: X-Spam-Status: No, score=-1.37 tagged_above=-999 required=5 tests=[AWL=-1.071, BAYES_00=-2.599, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tn5jR+QeDtMW for ; Thu, 27 Jan 2011 11:52:03 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id BC4C73A683D for ; Thu, 27 Jan 2011 11:52:02 -0800 (PST) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0RJt0ko032400; Thu, 27 Jan 2011 12:55:00 -0700 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0RJt0RB012570; Thu, 27 Jan 2011 12:55:00 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p0RJt0Ek012569; Thu, 27 Jan 2011 12:55:00 -0700 Date: Thu, 27 Jan 2011 12:55:00 -0700 From: "Brian F. G. Bidulock" To: Janardhan Iyengar Subject: Re: Quick Failover Algorithm in SCTP - question for the WG Message-ID: <20110127195500.GC9885@openss7.org> Mail-Followup-To: Janardhan Iyengar , "James M. Polk" , TSWG References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <4D3EAF12.4050100@oracle.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> <4D41C818.3050607@fandm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D41C818.3050607@fandm.edu> Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "James M. Polk" , TSWG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 19:52:04 -0000 Janardhan, Janardhan Iyengar wrote: (Thu, 27 Jan 2011 14:31:36) > (i) draft-nishida is useful for SCTP, even without draft-tuexen. > (ii) Practically, draft-nishida is simpler and thus likely to move faster > through the wg than draft-tuexen. To date I don't think that anyone has identified the advantages of PF over just setting PMR to 0/1. Simply setting PMR to 0/1 appears to deliver the same advantages in reducing failover times as PF without any implementation changes. This is true for both RFC and CMT SCTP. In particular the ID as it stands states that no data is sent to a PF destination (just as in the RFC4960 PMR case), only HEARTBEATS (just as in the RFC4960 PMR case). So why is PF necessary at all? Michael, why are you not just setting PMR to 0 on all implementations when you need quick failover? --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From Michael.Tuexen@lurchi.franken.de Thu Jan 27 11:56:14 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A323C3A6A32 for ; Thu, 27 Jan 2011 11:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3d0Kw1eCS0Z for ; Thu, 27 Jan 2011 11:56:13 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 38C8F3A6A1D for ; Thu, 27 Jan 2011 11:56:13 -0800 (PST) Received: from [192.168.1.113] (p508FCC98.dip.t-dialin.net [80.143.204.152]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 6F4F91C0C0BD6; Thu, 27 Jan 2011 20:59:16 +0100 (CET) Subject: Re: Quick Failover Algorithm in SCTP - question for the WG Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <20110127193736.GB9885@openss7.org> Date: Thu, 27 Jan 2011 20:59:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> <201101271415.52688.dreibh@iem.uni-due.de> <4D41A0CB.9080009@bbn.com> <38E19B53-7098-4204-A9DB-C05D3B97211F@lurchi.franken.de> <20110127193736.GB9885@openss7.org> To: bidulock@openss7.org X-Mailer: Apple Mail (2.1082) Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 19:56:14 -0000 On Jan 27, 2011, at 8:37 PM, Brian F. G. Bidulock wrote: > Michael, >=20 > Michael T=FCxen wrote: (Thu, 27 Jan 2011 = 19:11:23) >=20 >> when writing an application using SCTP which has to fulfill some = requirements >> on failover time I have to tweak the transport parameters to get that = feature. >>=20 >> Currently I have to do that very platform specific. Even the same = parameter >> means different things on different platforms. >>=20 >> So having a portable way to get some predefined failover behavior = makes sense >> to me... >=20 > Your problem appears to be more of an API issue than a standardization > of "implementation details". An API feature that indicates that the > application wants 'quickest failover' would appear to provide what you > need without unnecessarily constraining how the implementation = achieves > that. Brian, the point is that sometimes I not only want what the implementation considers 'quickest failover', but I want some time limits to be satisfied. I agree, I do not care how this is done in detail, but when we were investigating FreeBSD, Linux and Solaris, we had to figure out how these implementations do path supervision and how specific parameters in the API influence that. Based on that we could write code which can achieve the performance constraints. Part of the problem was API, this is smoothed out in the current version of the socket API ID, but another part was just different behavior. Solaris has some sort of fast path failure detection. Having a document describing such a mechanism would possibly result in having such a mechanism available on several implementations. I can speak for the FreeBSD implementation: We would provide such an implementation pretty soon such a document is on track for PS. Some sort of it is already implemented, but it needs some adoption. I would guess, it would also be implemented in Linux. I can't talk about other implementations. But every implementation is free to implement it or to implement even mechanisms which behave better in some metric in specific situation. This is the nice feature of the suggested method. It is sender side only... Best regards Michael >=20 > --brian >=20 > --=20 > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ >=20 From bidulock@openss7.org Thu Jan 27 12:18:16 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAF5B3A6A40 for ; Thu, 27 Jan 2011 12:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mugrPoQtDKN4 for ; Thu, 27 Jan 2011 12:18:16 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id DA3F93A6A16 for ; Thu, 27 Jan 2011 12:18:15 -0800 (PST) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0RKLJBd000382; Thu, 27 Jan 2011 13:21:19 -0700 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0RKLJ0d013011; Thu, 27 Jan 2011 13:21:19 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p0RKLJsh013010; Thu, 27 Jan 2011 13:21:19 -0700 Date: Thu, 27 Jan 2011 13:21:19 -0700 From: "Brian F. G. Bidulock" To: Michael =?iso-8859-1?Q?T=FCxen?= Subject: Re: Quick Failover Algorithm in SCTP - question for the WG Message-ID: <20110127202119.GD9885@openss7.org> Mail-Followup-To: Michael =?iso-8859-1?Q?T=FCxen?= , tsvwg@ietf.org References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> <201101271415.52688.dreibh@iem.uni-due.de> <4D41A0CB.9080009@bbn.com> <38E19B53-7098-4204-A9DB-C05D3B97211F@lurchi.franken.de> <20110127193736.GB9885@openss7.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 20:18:17 -0000 Michael, Michael Tüxen wrote: (Thu, 27 Jan 2011 20:59:15) > But every implementation is free to implement it or to implement even > mechanisms which behave better in some metric in specific situation. > This is the nice feature of the suggested method. It is sender side > only... If it is "just a suggestion" why does it need to be Standards Track? --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From Michael.Tuexen@lurchi.franken.de Thu Jan 27 12:21:37 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0902F3A6A16 for ; Thu, 27 Jan 2011 12:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_TOOL=2.3, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Emk9KQxRxLwq for ; Thu, 27 Jan 2011 12:21:36 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 957623A6A46 for ; Thu, 27 Jan 2011 12:21:35 -0800 (PST) Received: from [192.168.1.113] (p508FCC98.dip.t-dialin.net [80.143.204.152]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id BCAD21C0C0BD6; Thu, 27 Jan 2011 21:24:38 +0100 (CET) Subject: Re: Quick Failover Algorithm in SCTP - question for the WG Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <20110127195500.GC9885@openss7.org> Date: Thu, 27 Jan 2011 21:24:37 +0100 Content-Transfer-Encoding: 7bit Message-Id: <978A96E9-D1C5-4C14-A5B5-97019DE25F52@lurchi.franken.de> References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <4D3EAF12.4050100@oracle.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> <4D41C818.3050607@fandm.edu> <20110127195500.GC9885@openss7.org> To: bidulock@openss7.org X-Mailer: Apple Mail (2.1082) Cc: Janardhan Iyengar , "James M. Polk" , TSWG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 20:21:37 -0000 On Jan 27, 2011, at 8:55 PM, Brian F. G. Bidulock wrote: > Janardhan, > > Janardhan Iyengar wrote: (Thu, 27 Jan 2011 14:31:36) >> (i) draft-nishida is useful for SCTP, even without draft-tuexen. >> (ii) Practically, draft-nishida is simpler and thus likely to move faster >> through the wg than draft-tuexen. > > To date I don't think that anyone has identified the advantages of > PF over just setting PMR to 0/1. Simply setting PMR to 0/1 appears > to deliver the same advantages in reducing failover times as PF > without any implementation changes. This is true for both RFC and > CMT SCTP. > > In particular the ID as it stands states that no data is sent to a > PF destination (just as in the RFC4960 PMR case), only HEARTBEATS > (just as in the RFC4960 PMR case). > > So why is PF necessary at all? > > Michael, why are you not just setting PMR to 0 on all implementations > when you need quick failover? When using PMR == 0 I would do a failover on a single timeout and report the path as failed to the upper layer. Using the PF state I can use a small value to move the traffic away without having a lot of false alarms that a path is broken. Another thing I can not get by setting PMR=0 is that if I saw some errors on an idle path, I send the HEARTBEATs without taking HB.Interval into account. This is something already done by Solaris, I think. But it helps. Best regards Michael > > --brian > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > From Michael.Tuexen@lurchi.franken.de Thu Jan 27 12:23:45 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C4473A6A4A for ; Thu, 27 Jan 2011 12:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-xR6uLjCFFE for ; Thu, 27 Jan 2011 12:23:44 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 8A67A3A6A4B for ; Thu, 27 Jan 2011 12:23:44 -0800 (PST) Received: from [192.168.1.113] (p508FCC98.dip.t-dialin.net [80.143.204.152]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 047641C0C0BCA; Thu, 27 Jan 2011 21:26:47 +0100 (CET) Subject: Re: Quick Failover Algorithm in SCTP - question for the WG Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <20110127202119.GD9885@openss7.org> Date: Thu, 27 Jan 2011 21:26:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> <201101271415.52688.dreibh@iem.uni-due.de> <4D41A0CB.9080009@bbn.com> <38E19B53-7098-4204-A9DB-C05D3B97211F@lurchi.franken.de> <20110127193736.GB9885@openss7.org> <20110127202119.GD9885@openss7.org> To: bidulock@openss7.org X-Mailer: Apple Mail (2.1082) Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 20:23:45 -0000 On Jan 27, 2011, at 9:21 PM, Brian F. G. Bidulock wrote: > Michael, >=20 > Michael T=FCxen wrote: (Thu, 27 Jan 2011 20:59:15) >> But every implementation is free to implement it or to implement even >> mechanisms which behave better in some metric in specific situation. >> This is the nice feature of the suggested method. It is sender side >> only... >=20 > If it is "just a suggestion" why does it need to be Standards Track? I consider everything described in an ID as a suggestion... Maybe I should have used "of the method described in the ID". It is what I meant. Best regards Michael >=20 > --brian >=20 > --=20 > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ >=20 From bidulock@openss7.org Thu Jan 27 12:34:56 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 332D53A689F for ; Thu, 27 Jan 2011 12:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inf-1fSeHoDj for ; Thu, 27 Jan 2011 12:34:55 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 069DA3A6868 for ; Thu, 27 Jan 2011 12:34:54 -0800 (PST) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0RKbsPK000644; Thu, 27 Jan 2011 13:37:54 -0700 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0RKbsEt013304; Thu, 27 Jan 2011 13:37:54 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p0RKbsBI013303; Thu, 27 Jan 2011 13:37:54 -0700 Date: Thu, 27 Jan 2011 13:37:54 -0700 From: "Brian F. G. Bidulock" To: Michael =?iso-8859-1?Q?T=FCxen?= Subject: Re: Quick Failover Algorithm in SCTP - question for the WG Message-ID: <20110127203754.GE9885@openss7.org> Mail-Followup-To: Michael =?iso-8859-1?Q?T=FCxen?= , Janardhan Iyengar , "James M. Polk" , TSWG References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <4D3EAF12.4050100@oracle.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> <4D41C818.3050607@fandm.edu> <20110127195500.GC9885@openss7.org> <978A96E9-D1C5-4C14-A5B5-97019DE25F52@lurchi.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <978A96E9-D1C5-4C14-A5B5-97019DE25F52@lurchi.franken.de> Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Janardhan Iyengar , "James M. Polk" , TSWG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 20:34:56 -0000 Michael, Michael Tüxen wrote: (Thu, 27 Jan 2011 21:24:37) > When using PMR == 0 I would do a failover on a single timeout > and report the path as failed to the upper layer. > Using the PF state I can use a small value to move the traffic away > without having a lot of false alarms that a path is broken. Well PF "suggests" a similar indication anyway. Really, when setting PMR = 0 the path failure indication is not an indication of a broken destination: it is an indication that the destination has been moved to the inactive state (no longer offered traffic). PF as "suggested" does the same thing. > Another thing I can not get by setting PMR=0 is that if I saw > some errors on an idle path, I send the HEARTBEATs without > taking HB.Interval into account. This is something already > done by Solaris, I think. But it helps. I don't this this should be advised. If the endpoint figures that the destination is in temporary congestion, it should never _increase_ the rate at which it sends messages to that destination. Is that all the advantages of this "suggestion"? --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From bidulock@openss7.org Thu Jan 27 12:37:50 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 047E628C15D for ; Thu, 27 Jan 2011 12:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.315 X-Spam-Level: X-Spam-Status: No, score=-2.315 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkJB7y6OOxV7 for ; Thu, 27 Jan 2011 12:37:49 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id F3C6328C170 for ; Thu, 27 Jan 2011 12:37:48 -0800 (PST) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0RKer89000714; Thu, 27 Jan 2011 13:40:53 -0700 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0RKer9A013428; Thu, 27 Jan 2011 13:40:53 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p0RKerM1013427; Thu, 27 Jan 2011 13:40:53 -0700 Date: Thu, 27 Jan 2011 13:40:52 -0700 From: "Brian F. G. Bidulock" To: Michael =?iso-8859-1?Q?T=FCxen?= Subject: Re: Quick Failover Algorithm in SCTP - question for the WG Message-ID: <20110127204052.GF9885@openss7.org> Mail-Followup-To: Michael =?iso-8859-1?Q?T=FCxen?= , tsvwg@ietf.org References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> <201101271415.52688.dreibh@iem.uni-due.de> <4D41A0CB.9080009@bbn.com> <38E19B53-7098-4204-A9DB-C05D3B97211F@lurchi.franken.de> <20110127193736.GB9885@openss7.org> <20110127202119.GD9885@openss7.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 20:37:50 -0000 Michael, Michael Tüxen wrote: (Thu, 27 Jan 2011 21:26:47) > On Jan 27, 2011, at 9:21 PM, Brian F. G. Bidulock wrote: > > > Michael, > > > > Michael Tüxen wrote: (Thu, 27 Jan 2011 20:59:15) > >> But every implementation is free to implement it or to implement even > >> mechanisms which behave better in some metric in specific situation. > >> This is the nice feature of the suggested method. It is sender side > >> only... > > > > If it is "just a suggestion" why does it need to be Standards Track? > I consider everything described in an ID as a suggestion... > Maybe I should have used "of the method described in the ID". It is what > I meant. Buf if "every implementation is free to implement it", or not, or better ones, how is it more than a suggestion or "implementation detail"? --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From Michael.Tuexen@lurchi.franken.de Thu Jan 27 12:44:11 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFDF53A68A7 for ; Thu, 27 Jan 2011 12:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXNMx+Qxw+Ac for ; Thu, 27 Jan 2011 12:44:11 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 885CA3A687A for ; Thu, 27 Jan 2011 12:44:10 -0800 (PST) Received: from [192.168.1.113] (p508FCC98.dip.t-dialin.net [80.143.204.152]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id F3FCA1C0C0BCA; Thu, 27 Jan 2011 21:47:13 +0100 (CET) Subject: Re: Quick Failover Algorithm in SCTP - question for the WG Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <20110127204052.GF9885@openss7.org> Date: Thu, 27 Jan 2011 21:47:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <80E316B9-6749-4C6C-ADD0-5C81DE17F975@lurchi.franken.de> References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> <201101271415.52688.dreibh@iem.uni-due.de> <4D41A0CB.9080009@bbn.com> <38E19B53-7098-4204-A9DB-C05D3B97211F@lurchi.franken.de> <20110127193736.GB9885@openss7.org> <20110127202119.GD9885@openss7.org> <20110127204052.GF9885@openss7.org> To: bidulock@openss7.org X-Mailer: Apple Mail (2.1082) Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 20:44:12 -0000 On Jan 27, 2011, at 9:40 PM, Brian F. G. Bidulock wrote: > Michael, >=20 > Michael T=FCxen wrote: = (Thu, 27 Jan 2011 21:26:47) >> On Jan 27, 2011, at 9:21 PM, Brian F. G. Bidulock wrote: >>=20 >>> Michael, >>>=20 >>> Michael T=FCxen wrote: (Thu, 27 Jan 2011 = 20:59:15) >>>> But every implementation is free to implement it or to implement = even >>>> mechanisms which behave better in some metric in specific = situation. >>>> This is the nice feature of the suggested method. It is sender side >>>> only... >>>=20 >>> If it is "just a suggestion" why does it need to be Standards Track? >> I consider everything described in an ID as a suggestion... >> Maybe I should have used "of the method described in the ID". It is = what >> I meant. >=20 > Buf if "every implementation is free to implement it", or not, or = better > ones, how is it more than a suggestion or "implementation detail"? Yes. An SCTP implementation is free to implement RFC 4895 (SCTP-AUTH) or RFC 5061 (ADD-IP) or not, both a proposed standard. Same for RFC 3758 (PR-SCTP). Best regards Michael >=20 > --brian >=20 > --=20 > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ >=20 From Michael.Tuexen@lurchi.franken.de Thu Jan 27 12:47:06 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCD703A68A7 for ; Thu, 27 Jan 2011 12:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYwvQIdZFbLU for ; Thu, 27 Jan 2011 12:47:06 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id B62CA3A687A for ; Thu, 27 Jan 2011 12:47:05 -0800 (PST) Received: from [192.168.1.113] (p508FCC98.dip.t-dialin.net [80.143.204.152]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id EB69A1C0C0BD6; Thu, 27 Jan 2011 21:50:08 +0100 (CET) Subject: Re: Quick Failover Algorithm in SCTP - question for the WG Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <20110127203754.GE9885@openss7.org> Date: Thu, 27 Jan 2011 21:50:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <4D3EAF12.4050100@oracle.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> <4D41C818.3050607@fandm.edu> <20110127195500.GC9885@openss7.org> <978A96E9-D1C5-4C14-A5B5-97019DE25F52@lurchi.franken.de> <20110127203754.GE9885@openss7.org> To: bidulock@openss7.org X-Mailer: Apple Mail (2.1082) Cc: Janardhan Iyengar , "James M. Polk" , TSWG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 20:47:07 -0000 On Jan 27, 2011, at 9:37 PM, Brian F. G. Bidulock wrote: > Michael, >=20 > Michael T=FCxen wrote: (Thu, 27 Jan 2011 21:24:37) >> When using PMR =3D=3D 0 I would do a failover on a single timeout >> and report the path as failed to the upper layer. >> Using the PF state I can use a small value to move the traffic away >> without having a lot of false alarms that a path is broken. >=20 > Well PF "suggests" a similar indication anyway. Really, when setting > PMR =3D 0 the path failure indication is not an indication of a broken > destination: it is an indication that the destination has been moved > to the inactive state (no longer offered traffic). PF as "suggested" > does the same thing. But currently the notifications are defined as such... >=20 >> Another thing I can not get by setting PMR=3D0 is that if I saw >> some errors on an idle path, I send the HEARTBEATs without >> taking HB.Interval into account. This is something already >> done by Solaris, I think. But it helps. >=20 > I don't this this should be advised. If the endpoint figures that > the destination is in temporary congestion, it should never _increase_ > the rate at which it sends messages to that destination. Why? It used the standards RTO based mechanism and behaves as aggressive as it would we when using DATA chunks instead of HEARTBEAT chunks. >=20 > Is that all the advantages of this "suggestion"? The ID does not describe anything complicated. But it is useful. CMT is *much* more complex. Best regards Michael >=20 > --brian >=20 > --=20 > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ >=20 From bidulock@openss7.org Thu Jan 27 12:57:57 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05AF628C17B for ; Thu, 27 Jan 2011 12:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nQkr3Atzhkt for ; Thu, 27 Jan 2011 12:57:56 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id C9FA328C178 for ; Thu, 27 Jan 2011 12:57:55 -0800 (PST) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0RL0vdu001052; Thu, 27 Jan 2011 14:00:57 -0700 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0RL0vDv013759; Thu, 27 Jan 2011 14:00:57 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p0RL0vM6013758; Thu, 27 Jan 2011 14:00:57 -0700 Date: Thu, 27 Jan 2011 14:00:57 -0700 From: "Brian F. G. Bidulock" To: Michael =?iso-8859-1?Q?T=FCxen?= Subject: Re: Quick Failover Algorithm in SCTP - question for the WG Message-ID: <20110127210057.GG9885@openss7.org> Mail-Followup-To: Michael =?iso-8859-1?Q?T=FCxen?= , Janardhan Iyengar , "James M. Polk" , TSWG References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <4D3EAF12.4050100@oracle.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> <4D41C818.3050607@fandm.edu> <20110127195500.GC9885@openss7.org> <978A96E9-D1C5-4C14-A5B5-97019DE25F52@lurchi.franken.de> <20110127203754.GE9885@openss7.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Janardhan Iyengar , "James M. Polk" , TSWG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 20:57:57 -0000 Michael, Michael Tüxen wrote: (Thu, 27 Jan 2011 21:50:08) > On Jan 27, 2011, at 9:37 PM, Brian F. G. Bidulock wrote: > > Michael Tüxen wrote: (Thu, 27 Jan 2011 21:24:37) > > Well PF "suggests" a similar indication anyway. Really, when setting > > PMR = 0 the path failure indication is not an indication of a broken > > destination: it is an indication that the destination has been moved > > to the inactive state (no longer offered traffic). PF as "suggested" > > does the same thing. > But currently the notifications are defined as such... Yes, they are defined in RFC4960 as: When a destination transport address is marked inactive (e.g., when SCTP detects a failure) or marked active (e.g., when SCTP detects a recovery), SCTP shall invoke this notification on the ULP. So, it does just indicate whether the destination is active or inactive. (Offered traffic or not). Under RFC4960 an application can be sure that if the primary is active, it is the only destination receiving traffic. PF breaks that contract. Setting PMR = 0 does not. I view this as an advantage of setting PMR = 0 over PF, not visa versa. > > I don't this this should be advised. If the endpoint figures that > > the destination is in temporary congestion, it should never _increase_ > > the rate at which it sends messages to that destination. > Why? It used the standards RTO based mechanism and behaves as > aggressive as it would we when using DATA chunks instead of > HEARTBEAT chunks. But you are doing it while sending DATA aggressively to an alternate destination. You have the initial cwnd overgrowth of the changeover (possibly through a shared bottleneck) plus the increase in HEARTBEAT traffic. This in fact increases the traffic sent into a network suspected of experiencing congestion. This is unnecessary. Sending _one_ HEARTBEAT immediately serves to restore destinations quickly that are experiencing very brief congestion without significant traffic increase. > > Is that all the advantages of this "suggestion"? > The ID does not describe anything complicated. But it is useful. > > CMT is *much* more complex. I meant advantages of PF over PMR = 0. I suppose there are no others. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From bidulock@openss7.org Thu Jan 27 13:00:31 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15BAE3A6A72 for ; Thu, 27 Jan 2011 13:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYOiZ27NfC6I for ; Thu, 27 Jan 2011 13:00:30 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id ED3EA3A6A51 for ; Thu, 27 Jan 2011 13:00:29 -0800 (PST) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0RL3YRj001095; Thu, 27 Jan 2011 14:03:34 -0700 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0RL3YCx013798; Thu, 27 Jan 2011 14:03:34 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p0RL3Ytn013797; Thu, 27 Jan 2011 14:03:34 -0700 Date: Thu, 27 Jan 2011 14:03:34 -0700 From: "Brian F. G. Bidulock" To: Michael =?iso-8859-1?Q?T=FCxen?= Subject: Re: Quick Failover Algorithm in SCTP - question for the WG Message-ID: <20110127210334.GH9885@openss7.org> Mail-Followup-To: Michael =?iso-8859-1?Q?T=FCxen?= , tsvwg@ietf.org References: <201101271415.52688.dreibh@iem.uni-due.de> <4D41A0CB.9080009@bbn.com> <38E19B53-7098-4204-A9DB-C05D3B97211F@lurchi.franken.de> <20110127193736.GB9885@openss7.org> <20110127202119.GD9885@openss7.org> <20110127204052.GF9885@openss7.org> <80E316B9-6749-4C6C-ADD0-5C81DE17F975@lurchi.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <80E316B9-6749-4C6C-ADD0-5C81DE17F975@lurchi.franken.de> Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 21:00:31 -0000 Michael, Michael Tüxen wrote: (Thu, 27 Jan 2011 21:47:13) > > Buf if "every implementation is free to implement it", or not, or better > > ones, how is it more than a suggestion or "implementation detail"? > Yes. An SCTP implementation is free to implement RFC 4895 (SCTP-AUTH) > or RFC 5061 (ADD-IP) or not, both a proposed standard. > Same for RFC 3758 (PR-SCTP). Yes, but of course, all of those change the on-the-wire protocol and require IANA assignments and so must be Standards Track. The PF ID does neither. So, what is the reason that you believe that the PF ID needs to be standards track? --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From yoshifumi.nishida@gmail.com Thu Jan 27 13:37:41 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A01B53A69D4 for ; Thu, 27 Jan 2011 13:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.489 X-Spam-Level: X-Spam-Status: No, score=-101.489 tagged_above=-999 required=5 tests=[AWL=-0.812, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDuacVjkYLTc for ; Thu, 27 Jan 2011 13:37:40 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 6354628C185 for ; Thu, 27 Jan 2011 13:37:40 -0800 (PST) Received: by wwa36 with SMTP id 36so2945615wwa.13 for ; Thu, 27 Jan 2011 13:40:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=+jBEMbwcYXmMa8r+UThi7mGEAWq2M8/KpFkcnIoocZw=; b=K815/1dLdgER0/G2Ipf+84YCTzpl9qvXqHtSGRXv9+g+emfa8LJeMWK9bhMsI1n8Qn SmBeSpkHij3lPPo1k8tBigESKsqgxfi/UVxCsiwzBpmDy4f4dHkKsCXbPXyBb9UGVc06 0hua6ysdzmAJ6pvSe13S0LOAvuEZJIx1IGmDs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=WDdW15Pf/vqhz7HcJA2x/nrCpoD11SsYRHoryGmUPYCmDgLL9VWjGCVGQgVD1SD1CH tfjNoqxUFZvrWcAWtFhN8oSHBoXCVDRYYftc/NT1y2gVQ/TO63scSxx4aafPj47ZGaAT 9TAiNLlMnO89yo5CbSHScbTQaGAhwwVVOENtE= MIME-Version: 1.0 Received: by 10.216.24.132 with SMTP id x4mr7290748wex.81.1296164444196; Thu, 27 Jan 2011 13:40:44 -0800 (PST) Sender: yoshifumi.nishida@gmail.com Received: by 10.216.89.11 with HTTP; Thu, 27 Jan 2011 13:40:44 -0800 (PST) In-Reply-To: <20110127195500.GC9885@openss7.org> References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <4D3EAF12.4050100@oracle.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> <4D41C818.3050607@fandm.edu> <20110127195500.GC9885@openss7.org> Date: Thu, 27 Jan 2011 13:40:44 -0800 X-Google-Sender-Auth: bfA-pxysh3OlPzRnBBYAjegwXVc Message-ID: Subject: Re: Quick Failover Algorithm in SCTP - question for the WG From: Yoshifumi Nishida To: bidulock@openss7.org, Janardhan Iyengar , "James M. Polk" , TSWG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 21:37:41 -0000 Hello Brain, In the quick-failover draft, we addressed setting PMR to 0/1. (please see section 4.1 if you're interested) As we wrote in the draft, setting PMR to 0/1 would have some potential issues. You'll need to think about AMR value, dormant status behavior, keep-alive..I mean, you'll need to ignore some part of RFC4960 and need to think about undocumented functions in the spec to get good performance. You might say smart implementers can properly address these issues and solve them by their own way. That might be true. But, I'm wondering why SCTP has to rely on the wisdom of the implementors and why IETF cannot produce a simple and easy-to-understand solution even though we already know the is= sue. I think you could standardize PMR=3D0/1 solution if you want, but just setting 0/1 would not be enough. Thanks, --- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/1/27 Brian F. G. Bidulock : > Janardhan, > > Janardhan Iyengar wrote: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(Thu,= 27 Jan 2011 14:31:36) >> (i) draft-nishida is useful for SCTP, even without draft-tuexen. >> (ii) Practically, draft-nishida is simpler and thus likely to move faste= r >> =A0 =A0through the wg than draft-tuexen. > > To date I don't think that anyone has identified the advantages of > PF over just setting PMR to 0/1. =A0Simply setting PMR to 0/1 appears > to deliver the same advantages in reducing failover times as PF > without any implementation changes. =A0This is true for both RFC and > CMT SCTP. > > In particular the ID as it stands states that no data is sent to a > PF destination (just as in the RFC4960 PMR case), only HEARTBEATS > (just as in the RFC4960 PMR case). > > So why is PF necessary at all? > > Michael, why are you not just setting PMR to 0 on all implementations > when you need quick failover? > > --brian > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ > From bidulock@openss7.org Thu Jan 27 14:04:06 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 095C63A6A91 for ; Thu, 27 Jan 2011 14:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.313 X-Spam-Level: X-Spam-Status: No, score=-1.313 tagged_above=-999 required=5 tests=[AWL=-1.014, BAYES_00=-2.599, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SKwhz00t4qM for ; Thu, 27 Jan 2011 14:04:05 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id DF3DD3A69E0 for ; Thu, 27 Jan 2011 14:04:04 -0800 (PST) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0RM76Kq002146; Thu, 27 Jan 2011 15:07:06 -0700 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0RM75QS014832; Thu, 27 Jan 2011 15:07:05 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p0RM75Rm014831; Thu, 27 Jan 2011 15:07:05 -0700 Date: Thu, 27 Jan 2011 15:07:05 -0700 From: "Brian F. G. Bidulock" To: Yoshifumi Nishida Subject: Re: Quick Failover Algorithm in SCTP - question for the WG Message-ID: <20110127220705.GA14667@openss7.org> Mail-Followup-To: Yoshifumi Nishida , Janardhan Iyengar , "James M. Polk" , TSWG References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <4D3EAF12.4050100@oracle.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> <4D41C818.3050607@fandm.edu> <20110127195500.GC9885@openss7.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Janardhan Iyengar , "James M. Polk" , TSWG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 22:04:06 -0000 Yoshifumi, Yoshifumi Nishida wrote: (Thu, 27 Jan 2011 13:40:44) > Hello Brain, > > In the quick-failover draft, we addressed setting PMR to 0/1. (please > see section 4.1 if you're interested) > As we wrote in the draft, setting PMR to 0/1 would have some potential > issues. You'll need to think about AMR value, > dormant status behavior, keep-alive..I mean, you'll need to ignore > some part of RFC4960 and need to think about undocumented functions in > the spec to get good performance. I read the ID. It discusses issues associated with setting PMR=0, but it does not identify how PF is superior in any of those regards. And, in particular, as the same underlying mechanisms are used (just a different named counter and a questionable each-RTO HEARBEAT procedure) it cannot provide better performance than PMR = 0. > You might say smart implementers can properly address these issues and > solve them by their own way. That might be true. > But, I'm wondering why SCTP has to rely on the wisdom of the > implementors and why IETF cannot produce > a simple and easy-to-understand solution even though we already know the issue. No, but I will say that Applications can solve these problems easily by tuning the existing RFC4960 protocol parameters. > I think you could standardize PMR=0/1 solution if you want, but just > setting 0/1 would not be enough. Other protocol parameters can be tuned as well to ahieve even better performance than PF; however, it does not need to be standardized because it already is: RFC 4960. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From jana.iyengar@gmail.com Thu Jan 27 14:59:20 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 934773A69E1 for ; Thu, 27 Jan 2011 14:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKS6kmlC6bS8 for ; Thu, 27 Jan 2011 14:59:14 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 474843A69DB for ; Thu, 27 Jan 2011 14:59:13 -0800 (PST) Received: by qyk34 with SMTP id 34so175088qyk.10 for ; Thu, 27 Jan 2011 15:02:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=+pDewLh2fHGIlVnVzbsK2E53ZriYcmjZptwHDgK13N4=; b=vXymzAm/d7hKbu9fejVXkxTIfc3OhniXPvJZxJhlkkcYm3CZD/TLQC2RNDQFiSDulf 4jak7GxYAzy4yAfYsAY7JNgzrQbTvjO8+ECziCtiOK/HuqScJPSB6QiR6/KNJHBsFirk GKxuiudf5M98rRZ+/ABGPZo0s4PhBKZ0Q88Vc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; b=q8DaHAx+giJXs7rVFH9HLdl3hSJx+E8zsVJWoGut4B8FhLUS+xKJwFWuZJUYbouQ9G yBTwcHZv/INq+WWvPmquHsnxzs5kGxjEGV4QxHDUBpjk27LrUU6tRdIwE/iOs2jTjQrW ubk59W82c6ataE6XKVfvKq4W9yd06KHpxMT+k= Received: by 10.229.193.204 with SMTP id dv12mr247167qcb.274.1296169338455; Thu, 27 Jan 2011 15:02:18 -0800 (PST) Received: from surutti.fandm.edu (dhcp-155-68-162-85.fandm.edu [155.68.162.85]) by mx.google.com with ESMTPS id h20sm12160586qck.0.2011.01.27.15.02.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 27 Jan 2011 15:02:16 -0800 (PST) Message-ID: <4D41F977.7090205@fandm.edu> Date: Thu, 27 Jan 2011 18:02:15 -0500 From: Janardhan Iyengar Organization: Franklin & Marshall College User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_T=FCxen?= Subject: Re: Quick Failover Algorithm in SCTP - question for the WG References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <4D3EAF12.4050100@oracle.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> <4D41C818.3050607@fandm.edu> <20110127195500.GC9885@openss7.org> <978A96E9-D1C5-4C14-A5B5-97019DE25F52@lurchi.franken.de> In-Reply-To: <978A96E9-D1C5-4C14-A5B5-97019DE25F52@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Janardhan Iyengar , bidulock@openss7.org, "James M. Polk" , TSWG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: janardhan.iyengar@fandm.edu List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 22:59:20 -0000 Brian, >> So why is PF necessary at all? In addition to what Michael just said about the semantic difference between a PF state and a Failed state to both SCTP and to the application, a subtle point of difference follows. The PF state drives heartbeats using the data-timer to the PF destination, which is exponentially backing off, as against driven by the HB-timer, which is very slow. This matters because simply setting PMR to 0 is aggressive, and on paths that experience timeouts periodically, setting PMR to 0 results in recovery using the slow HB-timer. - jana -- Janardhan Iyengar Assistant Professor, Computer Science Franklin & Marshall College http://www.fandm.edu/jiyengar From jana.iyengar@gmail.com Thu Jan 27 15:19:36 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10D473A68AA for ; Thu, 27 Jan 2011 15:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.374 X-Spam-Level: X-Spam-Status: No, score=-3.374 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDD-vsN1tvrL for ; Thu, 27 Jan 2011 15:19:34 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 4CEE13A6890 for ; Thu, 27 Jan 2011 15:19:31 -0800 (PST) Received: by vws7 with SMTP id 7so1005789vws.31 for ; Thu, 27 Jan 2011 15:22:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:reply-to:organization :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=0KzSDZTSe22JYf2E7iIRYBYFIIN27zuoBlqtZHnWA1E=; b=Po4thds8c2hxL+wif2sgVG158tMz6HDNx7Eh8+fq83kxY/Ir/WxKXPxbNC4d9GBxn8 X4SUbWC+/OpuLcYdBjVi57TD+VsEVLZqWHxGsai5x+6hLWlpH00W8NxPUag/uvrTe9Ci TBitQuQ5mJPHK+BTNyPrAJQl3sP07Vd0FYM3w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:subject:references:in-reply-to:content-type :content-transfer-encoding; b=okJrd4U0PB0m6Zo21IijMD+SAztlTv+L+CAAVsIQePWHoFzLHbWqmu6YnXkYUc4Bak SbYVHxCuj5ObqEZRzCDm3cCAFXTpQl3BD4+vRVCwZ6JIJlv0RIPRd5CVBVKPxFYSgJ26 P2QhqDsK/7kxXPoBbedNi/tkbGc7vsUT3x6PE= Received: by 10.220.180.10 with SMTP id bs10mr412988vcb.90.1296170553783; Thu, 27 Jan 2011 15:22:33 -0800 (PST) Received: from surutti.fandm.edu (dhcp-155-68-162-85.fandm.edu [155.68.162.85]) by mx.google.com with ESMTPS id b5sm3698682vcx.28.2011.01.27.15.22.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 27 Jan 2011 15:22:33 -0800 (PST) Message-ID: <4D41FE37.7070304@fandm.edu> Date: Thu, 27 Jan 2011 18:22:31 -0500 From: Janardhan Iyengar Organization: Franklin & Marshall College User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_T=FCxen?= , Janardhan Iyengar , "James M. Polk" , TSWG Subject: Re: Quick Failover Algorithm in SCTP - question for the WG References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <4D3EAF12.4050100@oracle.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> <4D41C818.3050607@fandm.edu> <20110127195500.GC9885@openss7.org> <978A96E9-D1C5-4C14-A5B5-97019DE25F52@lurchi.franken.de> <20110127203754.GE9885@openss7.org> <20110127210057.GG9885@openss7.org> In-Reply-To: <20110127210057.GG9885@openss7.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: janardhan.iyengar@fandm.edu List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 23:19:36 -0000 Brian, > Yes, they are defined in RFC4960 as: > > When a destination transport address is marked inactive (e.g., when > SCTP detects a failure) or marked active (e.g., when SCTP detects a > recovery), SCTP shall invoke this notification on the ULP. > > So, it does just indicate whether the destination is active or inactive. > (Offered traffic or not). But that is precisely the point: with PF, the path is NOT marked inactive; traffic may be offered soon. A single timeout is not a big deal on many Internet-like paths, and it is definitely not an indication of path failure. In such a case, the notification to the ULP about path failure becomes too noisy. There are two things going on here: what should an SCTP sender do on timeout, and when should a path failure be indicated. The first one is a performance question, and the second one is a semantic question. > Under RFC4960 an application can be sure that > if the primary is active, it is the only destination receiving traffic. > PF breaks that contract. Setting PMR = 0 does not. I view this as > an advantage of setting PMR = 0 over PF, not visa versa. There is no such contract under RFC4960, since retransmissions can still go to alternate destinations. > But you are doing it while sending DATA aggressively to an alternate > destination. You have the initial cwnd overgrowth of the changeover > (possibly through a shared bottleneck) plus the increase in HEARTBEAT > traffic. This in fact increases the traffic sent into a network > suspected of experiencing congestion. Cwnd overgrowth happens only if there was a fairly large window oustanding on the old path when the "changeover" is initiated. No cwnd overgrowth will happen here because there was probably a long pause in sending due to the timeout on the old path. > This is unnecessary. Sending _one_ HEARTBEAT immediately serves to > restore destinations quickly that are experiencing very brief congestion > without significant traffic increase. Yes, sending one HB immediately is important. All PF does is use the RTO timer to send more HBs following this first HB. - jana -- Janardhan Iyengar Assistant Professor, Computer Science Franklin & Marshall College http://www.fandm.edu/jiyengar From bidulock@openss7.org Thu Jan 27 15:44:17 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E0AA3A6ACF for ; Thu, 27 Jan 2011 15:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, J_CHICKENPOX_28=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgwVrWE+EwDI for ; Thu, 27 Jan 2011 15:44:16 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 5AE053A6AC2 for ; Thu, 27 Jan 2011 15:44:16 -0800 (PST) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0RNlFB0004002; Thu, 27 Jan 2011 16:47:15 -0700 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0RNlFx4016363; Thu, 27 Jan 2011 16:47:15 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p0RNlEnZ016362; Thu, 27 Jan 2011 16:47:14 -0700 Date: Thu, 27 Jan 2011 16:47:14 -0700 From: "Brian F. G. Bidulock" To: Janardhan Iyengar Subject: Re: Quick Failover Algorithm in SCTP - question for the WG Message-ID: <20110127234714.GA16174@openss7.org> Mail-Followup-To: Janardhan Iyengar , Michael =?iso-8859-1?Q?T=FCxen?= , "James M. Polk" , TSWG References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <4D3EAF12.4050100@oracle.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> <4D41C818.3050607@fandm.edu> <20110127195500.GC9885@openss7.org> <978A96E9-D1C5-4C14-A5B5-97019DE25F52@lurchi.franken.de> <4D41F977.7090205@fandm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D41F977.7090205@fandm.edu> Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Michael =?iso-8859-1?Q?T=FCxen?= , "James M. Polk" , TSWG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 23:44:17 -0000 Janardhan, Janardhan Iyengar wrote: (Thu, 27 Jan 2011 18:02:15) > Brian, > >>> So why is PF necessary at all? > > In addition to what Michael just said about the semantic difference > between a PF state and a Failed state to both SCTP and to the > application, a subtle point of difference follows. > > The PF state drives heartbeats using the data-timer to the PF > destination, which is exponentially backing off, as against driven by > the HB-timer, which is very slow. This matters because simply setting > PMR to 0 is aggressive, and on paths that experience timeouts > periodically, setting PMR to 0 results in recovery using the slow > HB-timer. With PMR=0 this is simple: When the application receives the NETWORK STATUS CHANGE indication that the destination is inactive, it simply uses the "Change Heartbeat" request (RFC4960/10(I)) to change HB.interval for that destination to 0. It can also use the "Request HeartBeat" request (RFC4960/10(J)) to request an immediate heartbeat. When it receives the NETWORK STATUS CHANGE indication that the destination is active, it simply uses the "Change Heartbeat" request (RFC4960/10(I)) to set the heartbeat interval back to its previous value. Anything else? --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From bidulock@openss7.org Thu Jan 27 15:46:41 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9031A3A6AD5 for ; Thu, 27 Jan 2011 15:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_28=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxQlW3GI4dWe for ; Thu, 27 Jan 2011 15:46:40 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id A69EE3A68AF for ; Thu, 27 Jan 2011 15:46:40 -0800 (PST) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0RNnfFB004042; Thu, 27 Jan 2011 16:49:41 -0700 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0RNnfJ8016409; Thu, 27 Jan 2011 16:49:41 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p0RNne7E016408; Thu, 27 Jan 2011 16:49:40 -0700 Date: Thu, 27 Jan 2011 16:49:40 -0700 From: "Brian F. G. Bidulock" To: Michael =?iso-8859-1?Q?T=FCxen?= Subject: Re: Quick Failover Algorithm in SCTP - question for the WG Message-ID: <20110127234940.GB16174@openss7.org> Mail-Followup-To: Michael =?iso-8859-1?Q?T=FCxen?= , Janardhan Iyengar , "James M. Polk" , TSWG References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <4D3EAF12.4050100@oracle.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> <4D41C818.3050607@fandm.edu> <20110127195500.GC9885@openss7.org> <978A96E9-D1C5-4C14-A5B5-97019DE25F52@lurchi.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <978A96E9-D1C5-4C14-A5B5-97019DE25F52@lurchi.franken.de> Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Janardhan Iyengar , "James M. Polk" , TSWG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 23:46:41 -0000 Michael, Michael Tüxen wrote: (Thu, 27 Jan 2011 21:24:37) > On Jan 27, 2011, at 8:55 PM, Brian F. G. Bidulock wrote: > When using PMR == 0 I would do a failover on a single timeout > and report the path as failed to the upper layer. > Using the PF state I can use a small value to move the traffic away > without having a lot of false alarms that a path is broken. > > Another thing I can not get by setting PMR=0 is that if I saw > some errors on an idle path, I send the HEARTBEATs without > taking HB.Interval into account. This is something already > done by Solaris, I think. But it helps. But you will have to notify PFMR events anyway. Simply use those pesky NETWORK STATUS CHANGE indications to set the HB.interval to zero when the destination is inactive. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From bidulock@openss7.org Thu Jan 27 16:02:13 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E0613A6ADC for ; Thu, 27 Jan 2011 16:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, J_CHICKENPOX_28=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGySMzReVn3A for ; Thu, 27 Jan 2011 16:02:12 -0800 (PST) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id DF0D43A6ADB for ; Thu, 27 Jan 2011 16:02:11 -0800 (PST) Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0S03ljV004283; Thu, 27 Jan 2011 17:03:47 -0700 Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0S03lUc016807; Thu, 27 Jan 2011 17:03:47 -0700 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id p0S03lMu016806; Thu, 27 Jan 2011 17:03:47 -0700 Date: Thu, 27 Jan 2011 17:03:47 -0700 From: "Brian F. G. Bidulock" To: Janardhan Iyengar Subject: Re: Quick Failover Algorithm in SCTP - question for the WG Message-ID: <20110128000347.GC16174@openss7.org> Mail-Followup-To: Janardhan Iyengar , Michael =?iso-8859-1?Q?T=FCxen?= , "James M. Polk" , TSWG References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <4D3EAF12.4050100@oracle.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> <4D41C818.3050607@fandm.edu> <20110127195500.GC9885@openss7.org> <978A96E9-D1C5-4C14-A5B5-97019DE25F52@lurchi.franken.de> <20110127203754.GE9885@openss7.org> <20110127210057.GG9885@openss7.org> <4D41FE37.7070304@fandm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D41FE37.7070304@fandm.edu> Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Michael =?iso-8859-1?Q?T=FCxen?= , "James M. Polk" , TSWG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bidulock@openss7.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 00:02:13 -0000 Janardhan, Please see comments below... Janardhan Iyengar wrote: (Thu, 27 Jan 2011 18:22:31) > Brian, > >> Yes, they are defined in RFC4960 as: >> >> When a destination transport address is marked inactive (e.g., when >> SCTP detects a failure) or marked active (e.g., when SCTP detects a >> recovery), SCTP shall invoke this notification on the ULP. >> >> So, it does just indicate whether the destination is active or inactive. >> (Offered traffic or not). > > But that is precisely the point: with PF, the path is NOT marked > inactive; traffic may be offered soon. There is no difference with PMR = 0, the destination is marked inactive, but traffic may still be offerred soon (on the next ack). > A single timeout is not a big deal on many Internet-like paths, and it > is definitely not an indication of path failure. No amount of timeouts is definitive indication of a path failure. Timeouts can always be caused simply by delay. > In such a case, the notification to the ULP about path failure becomes > too noisy. Subjective. The notifications can be used to set the HB.interval to what PF would, even issue an immediate HB. PF the way it is proposed provides for a ULP indication on PFMR anyway. PMR = 0 is less noisy because the PFMR indications are not followed up by PMR indications. > There are two things going on here: what should an SCTP sender do on > timeout, and when should a path failure be indicated. The first one > is a performance question, and the second one is a semantic question. What an SCTP sender does on a timeout is really no different for PMR=0 than PF. The semantic question is purely local and API related. >> Under RFC4960 an application can be sure that >> if the primary is active, it is the only destination receiving traffic. >> PF breaks that contract. Setting PMR = 0 does not. I view this as >> an advantage of setting PMR = 0 over PF, not visa versa. > > There is no such contract under RFC4960, since retransmissions can > still go to alternate destinations. When PMR is set to 0 there is: because all RTO retransmissions cause the primary to go inactive. >> But you are doing it while sending DATA aggressively to an alternate >> destination. You have the initial cwnd overgrowth of the changeover >> (possibly through a shared bottleneck) plus the increase in HEARTBEAT >> traffic. This in fact increases the traffic sent into a network >> suspected of experiencing congestion. > > Cwnd overgrowth happens only if there was a fairly large window > oustanding on the old path when the "changeover" is initiated. No > cwnd overgrowth will happen here because there was probably a long > pause in sending due to the timeout on the old path. Yes. I may have used the alternate path recently and its usability is over 30 seconds old because my HB.interval is set to 30 seconds. The path to all destinations is a shared bottleneck and there will be a cwnd overgrowth. Under PF as it stands, I also increase HB traffic to the old destination (on the same path) just to kick the network while its down. >> This is unnecessary. Sending _one_ HEARTBEAT immediately serves to >> restore destinations quickly that are experiencing very brief congestion >> without significant traffic increase. > > Yes, sending one HB immediately is important. All PF does is use the > RTO timer to send more HBs following this first HB. With PMR = 0, the application can use NETWORK STATUS CHANGE indication to issue a "Request Heartbeat". --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From yoshifumi.nishida@gmail.com Thu Jan 27 16:50:16 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A7223A6B36 for ; Thu, 27 Jan 2011 16:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.606 X-Spam-Level: X-Spam-Status: No, score=-102.606 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFU5yXITu6S5 for ; Thu, 27 Jan 2011 16:50:14 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 691053A6B12 for ; Thu, 27 Jan 2011 16:50:12 -0800 (PST) Received: by wwa36 with SMTP id 36so3123931wwa.13 for ; Thu, 27 Jan 2011 16:53:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=N3j8q0wt+1X/oRFZkIRs4Qgykp9R5Sf4BTpTbxR35FI=; b=IJ7VvlQLft/7fYINUAjKLYDEyQuIPQGIx8V7gojF7qsR7NM5z0nFLqfsecUMwps8U3 LqB7xsP8sDh9jDVnX0HUu7dLlVi93/8fNY3skjQKHT10/vvPXG7ANv0M9CvFw/zfQ5MN Th1bLQKeasU5tKyx68r08AoGmklhUSYUkRfj0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=hZfMSKqgqsi58rQYuVE0Y/LrZjDjjj1jNC72ILa88fNNE2WclWxQWFYn3nkkFo0lPS fNtAAxbGzd9HW9VFauA4kfbW8G+o/HlwrLv4DFcXCLlMsrkiaGqaBxymBFX8SGfosBa4 jxKn6CACEM4snebEZ2E5GU8toWyae/DyZORAA= MIME-Version: 1.0 Received: by 10.216.157.68 with SMTP id n46mr7604595wek.111.1296175992564; Thu, 27 Jan 2011 16:53:12 -0800 (PST) Sender: yoshifumi.nishida@gmail.com Received: by 10.216.89.11 with HTTP; Thu, 27 Jan 2011 16:53:12 -0800 (PST) In-Reply-To: <20110127220705.GA14667@openss7.org> References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <4D3EAF12.4050100@oracle.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> <4D41C818.3050607@fandm.edu> <20110127195500.GC9885@openss7.org> <20110127220705.GA14667@openss7.org> Date: Thu, 27 Jan 2011 16:53:12 -0800 X-Google-Sender-Auth: Md_OCKOoF4swub2jBOJlyPfkLYs Message-ID: Subject: Re: Quick Failover Algorithm in SCTP - question for the WG From: Yoshifumi Nishida To: bidulock@openss7.org, TSWG Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 00:50:16 -0000 Hi, 2011/1/27 Brian F. G. Bidulock : > >> I think you could standardize PMR=0/1 solution if you want, but just >> setting 0/1 would not be enough. > > Other protocol parameters can be tuned as well to ahieve even better > performance than PF; however, it does not need to be standardized because > it already is: RFC 4960. I personally prefer to say "this is vanilla SCTP and it works well" rather than "Please don't forget tuning before use it" (also, I'm not very sure just tuning parameters can get good performance...but, we can discuss later.) Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From touch@isi.edu Thu Jan 27 17:08:01 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 924693A6A38; Thu, 27 Jan 2011 17:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddb6J4L32OqN; Thu, 27 Jan 2011 17:08:00 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 946223A6A0D; Thu, 27 Jan 2011 17:08:00 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p0S1AjEM007742 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 27 Jan 2011 17:10:45 -0800 (PST) Message-ID: <4D421795.70505@isi.edu> Date: Thu, 27 Jan 2011 17:10:45 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Lars Eggert Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p0S1AjEM007742 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg@ietf.org, IETF discussion list , Paul Hoffman , IESG IESG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 01:08:01 -0000 On 1/27/2011 12:52 AM, Lars Eggert wrote: ... >> Small Issue #3: I object to anonymous review >> >> The current review is anonymous and this draft does not seem to change that. I don't like anonymous review - it's not how we do things at IETF and it encourages really bad behavior. I have several emails with an expert reviewer relayed via IANA where the conversation was going no where - once I knew the name of the reviewer, the whole conversation changed and stuff quickly came back to the realm of sane. I'm not willing to forward these emails to the list as that would just not be kind to anyone but I am happy to forward them to the IESG if they think looking at them is really critical. > > I can see your point, and I personally have no problem with disclosing the reviewer identity. What do others think? AFAICT, the experts team reports to IANA. We make recommendations to them. They are the ones who have the conversation with the applicant. They can take our advice or not - that's their decision. I.e., we are advisors to IANA. Further, many requests are handled my multiple reviewers. Many of us do have specific conversations with applicants, and identify ourselves when that happens, but it doesn't seem important to codify that in this doc. Again, this doc is about the unification of the registries. It is NOT about all the other policies that govern them. The info that's there is advisory ONLY (it is not binding to IANA). Joe From michelle.cotton@icann.org Thu Jan 27 17:26:34 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF8C83A68FC; Thu, 27 Jan 2011 17:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.461 X-Spam-Level: X-Spam-Status: No, score=-106.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApVSkWZSX-7L; Thu, 27 Jan 2011 17:26:32 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 986173A6B47; Thu, 27 Jan 2011 17:26:31 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Thu, 27 Jan 2011 17:29:36 -0800 From: Michelle Cotton To: Joe Touch , Lars Eggert Date: Thu, 27 Jan 2011 17:29:34 -0800 Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Thread-Topic: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Thread-Index: Acu+iEzAJ7ZkWDlMTVmmf9FwyJMukAAAoTBe Message-ID: In-Reply-To: <4D421795.70505@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Paul Hoffman , The IESG , "tsvwg@ietf.org" , IETF discussion list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 01:26:34 -0000 We are changing that process right now. We have begun to report the reviewer (with the review) in the email to the requester. We just need to make sure this small change is communicated to those expert= s that are part of review "teams" as their individual names are not published on the main list of registries. I don't think it needs to go in this document as this is already in progress. Let me know if you have any questions. --Michelle On 1/27/11 5:10 PM, "Joe Touch" wrote: >=20 >=20 > On 1/27/2011 12:52 AM, Lars Eggert wrote: > ... >>> Small Issue #3: I object to anonymous review >>>=20 >>> The current review is anonymous and this draft does not seem to change = that. >>> I don't like anonymous review - it's not how we do things at IETF and i= t >>> encourages really bad behavior. I have several emails with an expert >>> reviewer relayed via IANA where the conversation was going no where - o= nce I >>> knew the name of the reviewer, the whole conversation changed and stuff >>> quickly came back to the realm of sane. I'm not willing to forward thes= e >>> emails to the list as that would just not be kind to anyone but I am ha= ppy >>> to forward them to the IESG if they think looking at them is really >>> critical. >>=20 >> I can see your point, and I personally have no problem with disclosing t= he >> reviewer identity. What do others think? >=20 > AFAICT, the experts team reports to IANA. We make recommendations to > them. They are the ones who have the conversation with the applicant. > They can take our advice or not - that's their decision. >=20 > I.e., we are advisors to IANA. >=20 > Further, many requests are handled my multiple reviewers. >=20 > Many of us do have specific conversations with applicants, and identify > ourselves when that happens, but it doesn't seem important to codify > that in this doc. >=20 > Again, this doc is about the unification of the registries. It is NOT > about all the other policies that govern them. The info that's there is > advisory ONLY (it is not binding to IANA). >=20 > Joe From randall@lakerest.net Fri Jan 28 04:52:52 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 818AD3A6859 for ; Fri, 28 Jan 2011 04:52:52 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCk7cMChIbG3 for ; Fri, 28 Jan 2011 04:52:49 -0800 (PST) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by core3.amsl.com (Postfix) with ESMTP id 302BF3A6851 for ; Fri, 28 Jan 2011 04:52:48 -0800 (PST) Received: from [10.1.1.53] ([10.1.1.53]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id p0SCtpJd093044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 28 Jan 2011 07:55:51 -0500 (EST) (envelope-from randall@lakerest.net) Subject: Re: multipath congestion control and RFC 2861 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Randy Stewart In-Reply-To: Date: Fri, 28 Jan 2011 07:55:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <33866B34-4D2F-4BD5-8316-9092D4299A00@lakerest.net> References: To: "" X-Mailer: Apple Mail (2.1082) Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 12:52:52 -0000 Karen: Has you note, SCTP does in-force RFC2861 in its cc.. and I know that in FreeBSD-SCTP we do just that... Now that being said, the cwnd is kept on a per destination basis... so = each destination in CMT would grow with the same thought.. i.e. only if the destination was using the full cwnd.. I am not sure how that plays with the resource pooling... which is implemented in FreeBSD SCTP = now but I am not sure if they applied the use-it-or-loose or not... I guess I need to go peek at the code and see what they did ;-) R On Jan 20, 2011, at 8:01 AM, = wrote: > =20 > Equally relevant for the work on CMT-SCTP =96 = draft-tuexen-tsvwg-sctp-multipath-01.txt > Therefore forwarded here as well. > =20 > BR, Karen > =20 > _____________________________________________ > From: Nielsen Karen=20 > Sent: 20. januar 2011 13:43 > To: multipathtcp > Subject: multipath congestion control and RFC 2861 > =20 > =20 > Hi, > =20 > In the context of multipath TCP and coupled congestion control, I am = wondering what the thoughts are in respect to > the limitation put on growth of not fully utilized congestion windows = by RFC 2861 =96 as exemplified by the following text from RFC 2861. > =20 > "For the separate issue of the increase of the congestion window in > response to an acknowledgement, we believe the correct behavior is > for the sender to increase the congestion window only if the window > was full when the acknowledgment arrived." > =20 > The question seems relevant in connection with multipath TCP as it = impacts to willingness (and possibility) > of TCP to =93instantly=94 redistribute traffic from one failed path to = other paths =96 or perhaps more strictly speaking: to have n-1 paths = absorb > the traffic previously distributed on n paths. > =20 > Also the issue becomes very relevant when discussing the applicability = of the multipath congestion control to SCTP (CMT-SCTP) > as SCTP (RFC 4960) in text at least (not sure about all = implementations) incorporates the RFC 2861 constrains on growth of not = utilized CWNDs. > =20 > Thanks. > =20 > BR, Karen > =20 > =20 > = **************************************************************************= *************** > Karen Egede Nielsen > Software Architect, Ph.D. > =20 > Tieto Denmark A/S > IP Solutions, Telecom & Media > Skanderborgvej 232, 8260 Viby J, DK-Denmark > Direct Phone / Mobile +45 25134336 > E-mail: karen.nielsen@tieto.com > = **************************************************************************= *************** > www.tieto.com=20 > =20 > Please note: The information contained in this message may be legally = privileged and confidential and protected from disclosure. If the reader = of this message is not the intended recipient, you are hereby notified = that any unauthorised use, distribution or copying of this communication = is strictly prohibited. If you have received this communication in = error, please notify us immediately by replying to the message and = deleting it from your computer. Thank You. > =20 > =20 > =20 > =20 > =20 ----- Randall Stewart randall@lakerest.net From randall@lakerest.net Fri Jan 28 04:58:24 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4745A3A688E for ; Fri, 28 Jan 2011 04:58:24 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOjYkOZKA0rc for ; Fri, 28 Jan 2011 04:58:22 -0800 (PST) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by core3.amsl.com (Postfix) with ESMTP id 2E58B3A688C for ; Fri, 28 Jan 2011 04:58:21 -0800 (PST) Received: from [10.1.1.53] ([10.1.1.53]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id p0SD19ID093267 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 28 Jan 2011 08:01:10 -0500 (EST) (envelope-from randall@lakerest.net) Subject: Re: Transmission of DATA Chunks - question on CMT SCTP Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Randy Stewart In-Reply-To: Date: Fri, 28 Jan 2011 08:01:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8A38BF50-8846-42A4-9E8C-ED6F4F276668@lakerest.net> References: To: "" X-Mailer: Apple Mail (2.1082) Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 12:58:24 -0000 On Jan 27, 2011, at 6:50 AM, = wrote: > Hi, > =20 > In RFC 4960 Section 6.1 it is stated that transmission of new data = should await retransmissions. > That is: > =20 > C) When the time comes for the sender to transmit, before sending = new > DATA chunks, the sender MUST first transmit any outstanding DATA > chunks that are marked for retransmission (limited by the = current > cwnd). > =20 > In our SCTP implementation we have followed this rule literally on a = per association basis. That is, we do not send new data on any path of = the association, if there > is data marked for retransmission which is awaiting transmittal. But I = also know of SCTP implementations where this rule is obeyed only on an = path basis. I.e. data for retransmission > is somehow locked to a particular path and new data may flow out on = other paths even if there is data waiting to be retransmitted on a per = association basis. > =20 > I would like to know if anybody knows what is the chosen approach in = the CMT setting in this respect - ? > =20 > Also I am interesting in knowing if there is any clear consensus on = how the RFC 4690 should be interpreted in the non CMT case - ? I personally do not feel that you have to block sending new data to a = path if some other path has outstanding data marked for retransmission. As long as the = sender is obeying the cwnd for each path I see no issue here...=20 I tend to like to lock a chunk to a path and only allow it to change to = a different path if a T3-rxt happens. I like to keep any FR set so that you FR to = the=20 destination it was sent to... this allows multiple-fr of the same = chunk.. until=20 you finally hit a T3 on a chunk and move it to another path... CMT is a bit different but may benefit by the same rule.. I can't, off = the top of my head, remember how Jana and I implemented it in FreeBSD.. I guess I need to get a cup = of coffee and go take a look ;-) R R > =20 > Thanks ! > =20 > BR, Karen > =20 > =20 > = **************************************************************************= *************** > Karen Egede Nielsen > Software Architect, Ph.D. > =20 > Tieto Denmark A/S > IP Solutions, Telecom & Media > Skanderborgvej 232, 8260 Viby J, DK-Denmark > Direct Phone / Mobile +45 25134336 > E-mail: karen.nielsen@tieto.com > = **************************************************************************= *************** > www.tieto.com=20 > =20 > =20 > =20 ----- Randall Stewart randall@lakerest.net From Internet-Drafts@ietf.org Fri Jan 28 07:00:04 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01DD43A68A2; Fri, 28 Jan 2011 07:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meP5l-C7Bold; Fri, 28 Jan 2011 07:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7072B3A688F; Fri, 28 Jan 2011 07:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-tsvwg-sctpsocket-26.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110128150002.8003.4386.idtracker@localhost> Date: Fri, 28 Jan 2011 07:00:02 -0800 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 15:00:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Sockets API Extensions for Stream Control Transmission Protocol (SCTP) Author(s) : R. Stewart, et al. Filename : draft-ietf-tsvwg-sctpsocket-26.txt Pages : 111 Date : 2011-01-28 This document describes a mapping of the Stream Control Transmission Protocol (SCTP) into a sockets API. The benefits of this mapping include compatibility for TCP applications, access to new SCTP features and a consolidated error and event notification scheme. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-26.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tsvwg-sctpsocket-26.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-28065428.I-D@ietf.org> --NextPart-- From fluffy@cisco.com Fri Jan 28 09:43:37 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 610AA3A68D2; Fri, 28 Jan 2011 09:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.581 X-Spam-Level: X-Spam-Status: No, score=-110.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnV7lPa44ivD; Fri, 28 Jan 2011 09:43:36 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 9285F3A68F8; Fri, 28 Jan 2011 09:43:36 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKePQk2rR7Hu/2dsb2JhbAClAHOfY5tVhU8EhRiHDw Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 28 Jan 2011 17:46:43 +0000 Received: from sjc-vpn5-2007.cisco.com (sjc-vpn5-2007.cisco.com [10.21.95.215]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0SHkgUr002935; Fri, 28 Jan 2011 17:46:42 GMT Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Fri, 28 Jan 2011 09:46:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110118212603.5733.34489.idtracker@localhost> To: Lars Eggert X-Mailer: Apple Mail (2.1082) Cc: Carsten Bormann , IETF discussion list , Paul Hoffman , tsvwg@ietf.org, IESG IESG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 17:43:37 -0000 On Jan 27, 2011, at 1:26 , Lars Eggert wrote: > On 2011-1-27, at 11:20, Carsten Bormann wrote: >> With UDP-based protocols, it is harder to do this. >> Please look at section 7.3 of >>=20 >> = http://tools.ietf.org/html/draft-ietf-core-coap-04.html#section-7.3 >>=20 >> and tell us whether this is how you would like this to be handled for = UDP-based protocols in the future. >> If not, we may want to add to the guidance in the (tsvwg) draft. >=20 > This looks like a totally reasonable way to to this in-band using a = single port. How is the COAP working stepping on top of TLS code points any different = that the ITU-T stepping on MPLS code points? From iesg@ietf.org Thu Jan 27 08:09:36 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50CDE3A67ED; Thu, 27 Jan 2011 08:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLFE2cTEtCDU; Thu, 27 Jan 2011 08:09:35 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [64.170.98.20]) by core3.amsl.com (Postfix) with ESMTP id 2FF823A682A; Thu, 27 Jan 2011 08:09:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c1a.amsl.com (Postfix) with ESMTP id 4D43FE086B; Thu, 27 Jan 2011 08:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c1a.amsl.com ([127.0.0.1]) by localhost (c1a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCXyyJwRhwHa; Thu, 27 Jan 2011 08:12:39 -0800 (PST) Received: from [192.168.2.100] (pool-96-255-13-194.washdc.fios.verizon.net [96.255.13.194]) by c1a.amsl.com (Postfix) with ESMTPSA id AFE65E0809; Thu, 27 Jan 2011 08:12:38 -0800 (PST) Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: IETF Chair In-Reply-To: Date: Thu, 27 Jan 2011 11:12:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <37255E32-37F1-4907-8A5A-6AB7B590562F@ietf.org> References: <20110118212603.5733.34489.idtracker@localhost> To: Cullen Jennings X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Sat, 29 Jan 2011 08:43:09 -0800 Cc: IETF discussion list , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 16:09:36 -0000 Cullen: > Big Issues 1: I don't like mandating one port for secure and not = secure versions of a protocol=20 >=20 > I don't think this reflects IETF consensus given the number of = protocols that deliberately choses to use two ports. I also don't think = that it is a good idea in all cases. I believe the decision should be = left to the people designing the protocol if they want one port or two. = Let me give some examples >=20 > Imagine a client server protocol that runs over UDP and uses DTLS for = security. The server will simultaneously serve requests over both DTLS = and UDP. When the server receives a packet, it needs to be able to demux = if it is a UDP packet or a DTLS packet. The obvious demux code point is = the port. Yes, one might be able to reinvent a concept of a stream along = with a 5 tuple and something like STARTTLS but this has many other = problems. It means the client needs to use a different SRC port for each = different "session" to the same server. This uses up NAT ports and = complicates NAT traversal. It also adds additional latency to set up a = small session. People just aren't going to do it. The other approach is = demux based on the first byte inside the UDP packet. The CoAP protocol = being developed in the CORE WG has taken that approach. The CORE WG = proposed to the TLS chairs that over half the remaining code space for = the TLS code point in the first byte be assigned to CoAP. The TLS = chairs, more or less told the CORE guys to get stuffed (politely of = course). Two ports is the obvious answer.=20 >=20 > Lets consider another example. As the draft mentions, firewalls help = apply policy, and catch configuration errors. Take an organization (like = my house) that has a policy of no email over unencrypted protocols. It's = really easy to set up a firewall policy that allows the encrypted ports = and blocks the non encrypted ports that are typically used for email and = does not require the firewall to do DPI. No doubt my daughter could = figure out to circumvent this and sent unencrypted email via an VPN = tunneled over DNS or ICMP or something but thats not the point - the = point is to catch accidental misconfiguration, like the type that happen = during software upgrades. You can agree or disagree about using = firewalls this way but the fact remains, lots of people do use firewalls = this way.=20 >=20 > I strongly urge this draft not to take on mandating one port - leave = the decision with the designers of the protocol. If draft does mandate = one port, you will end up with a port registered for protocol foo and a = port for a proprietary protocol with no description called foo-secure. = As I mentioned before, I also do not believe there is IETF consensus for = one port.=20 Originally, two ports were assigned for plain and over-TLS, which for = HTTP mapped to two different URL schemes: http and https. Many people thought that this was a waste of a port, and the STARTTLS = approach was developed. You say that it does not work in some cases, = and you seem to be suggesting that we go back to the original way. Maybe it works in some cases and not others. Can we say which is which? Russ From ned.freed@mrochek.com Thu Jan 27 18:00:57 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C01BE3A6B65; Thu, 27 Jan 2011 18:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPJKe8Lu6YU4; Thu, 27 Jan 2011 18:00:55 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id A110B3A6B61; Thu, 27 Jan 2011 18:00:55 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NX4L8O4CLC00GKUB@mauve.mrochek.com>; Thu, 27 Jan 2011 18:03:58 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NWP1MZKQSW007FL5@mauve.mrochek.com>; Thu, 27 Jan 2011 18:03:55 -0800 (PST) Message-id: <01NX4L8MKNFI007FL5@mauve.mrochek.com> Date: Thu, 27 Jan 2011 17:43:16 -0800 (PST) From: Ned Freed Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP In-reply-to: "Your message dated Wed, 26 Jan 2011 17:12:44 -0700" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20110118212603.5733.34489.idtracker@localhost> To: Cullen Jennings DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1296177158; bh=2UvZsLUE4WQwheIgZQeu/cFZZsl3RnTbF9QyBalfjFc=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=flc0c6SXMeuuAlID1UA4GFD1sXpOwj6hUHkNJagOsmcFLxwJaPrz7XyAldiNB8r+V hh5TkTaZafjtII/AbUZaNwi5msuqylDbx4qYUtI9piPWRXlyYdxe1TSChE9OT5ka1c ENP322L5RFCwzPqNsZA1sRP/FdH8mRqUDwDchBZs= X-Mailman-Approved-At: Sat, 29 Jan 2011 08:43:09 -0800 Cc: IESG IESG , IETF discussion list , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 02:00:57 -0000 > Big Issues 1: I don't like mandating one port for secure and not secure > versions of a protocol I don't either, so it's good that the document doesn't do that. It says: Services are expected to include support for security, either as default or dynamically negotiated in-band. The use of separate service name or port number assignments for secure and insecure variants of the same service is to be avoided in order to discourage the deployment of insecure services. "is to be avoided" != "forbidden". There are legitimate use-cases for two port approaches - not many, but some - so they should be avoided but not banned. And the main reason for this isn't to encourage optional use of negotiated in-band security, but rather because deployment of insecure service variants no matter what the protocol details are bad idea. > I don't think this reflects IETF consensus given the number of protocols that > deliberately choses to use two ports. I also don't think that it is a good idea > in all cases. I believe the decision should be left to the people designing the > protocol if they want one port or two. Let me give some examples > Imagine a client server protocol that runs over UDP and uses DTLS for > security. The server will simultaneously serve requests over both DTLS and UDP. > When the server receives a packet, it needs to be able to demux if it is a UDP > packet or a DTLS packet. The obvious demux code point is the port. Yes, one > might be able to reinvent a concept of a stream along with a 5 tuple and > something like STARTTLS but this has many other problems. It means the client > needs to use a different SRC port for each different "session" to the same > server. This uses up NAT ports and complicates NAT traversal. It also adds > additional latency to set up a small session. People just aren't going to do > it. The other approach is demux based on the first byte inside the UDP packet. > The CoAP protocol being developed in the CORE WG has taken that approach. The > CORE WG proposed to the TLS chairs that over half the remaining code space for > the TLS code point in the first byte be assigned to CoAP. The TLS chairs, > more or less told the CORE guys to get stuffed (politely of course). Two > ports is the obvious answer. And nothing in this document would prevent such an assignment from being made as long as there are compelling reasons to do so. > Lets consider another example. As the draft mentions, firewalls help apply > policy, and catch configuration errors. Take an organization (like my house) > that has a policy of no email over unencrypted protocols. I have to say that that policy must be pretty tricky to implement given the widespread lack of encryption support in SMTP relay scenarios. > It's really easy to set up a firewall policy that allows the encrypted ports > and blocks the non encrypted ports that are typically used for email and does > not require the firewall to do DPI. But this doesn't address the bad configuration problem at all - all it does is change the location where the problem would have to be, from the mail server configuration (which, if it was compliant with the relevant email standards, should have been fairly secure by default) to the firewall (which doesn't really have a means of being secure by default without DPI). Now, perhaps you'll argue that firewalls configs are less likely to be grinched than those of an email server. If so, all I can say is that doesn't jibe with my experience. > No doubt my daughter could figure out to circumvent this and sent unencrypted > email via an VPN tunneled over DNS or ICMP or something but thats not the point > - the point is to catch accidental misconfiguration, like the type that happen > during software upgrades. You can agree or disagree about using firewalls this > way but the fact remains, lots of people do use firewalls this way. And lots of people screw up their firewall configurations in the process. > I strongly urge this draft not to take on mandating one port - leave the > decision with the designers of the protocol. If draft does mandate one port, > you will end up with a port registered for protocol foo and a port for a > proprietary protocol with no description called foo-secure. As I mentioned > before, I also do not believe there is IETF consensus for one port. Actually, I suspect there is rough consensus on the one port approach, in the TCP space at least. A few exceptions don't invalidate that. As for two registrations versus one, I would not object for there to be some cleaner mechanism for two port assignments. But any such mechanism needs to jibe with the reality that the best solution for production services is not to have an insecure variant at all, either on a separate port or negotiated in-band. Ned From fluffy@cisco.com Sat Jan 29 20:50:49 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B49B3A6AE3; Sat, 29 Jan 2011 20:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.581 X-Spam-Level: X-Spam-Status: No, score=-110.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q07txgfZ4Tbc; Sat, 29 Jan 2011 20:50:46 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6C9F33A6A6B; Sat, 29 Jan 2011 20:50:46 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD59RE2rR7Ht/2dsb2JhbACkenOgapoehU4EhROHDoNF Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 30 Jan 2011 04:53:57 +0000 Received: from [192.168.4.3] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0U4rUUN015483; Sun, 30 Jan 2011 04:53:55 GMT Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Sat, 29 Jan 2011 20:53:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Michelle Cotton X-Mailer: Apple Mail (2.1082) Cc: IETF discussion list , Joe Touch , Paul Hoffman , The IESG , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 04:50:49 -0000 On Jan 27, 2011, at 17:29 , Michelle Cotton wrote: > We are changing that process right now. We have begun to report the > reviewer (with the review) in the email to the requester. >=20 > We just need to make sure this small change is communicated to those = experts > that are part of review "teams" as their individual names are not = published > on the main list of registries. >=20 > I don't think it needs to go in this document as this is already in > progress. >=20 > Let me know if you have any questions. As long as we agree that is the process, it's not a big deal to me if it = is in or out of the document but I don't see any reason not to put it = into the document.=20 From fluffy@cisco.com Sat Jan 29 20:51:26 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC1563A6AA9; Sat, 29 Jan 2011 20:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.582 X-Spam-Level: X-Spam-Status: No, score=-110.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EX8RjcEeuyof; Sat, 29 Jan 2011 20:51:26 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D7D3A3A6A6C; Sat, 29 Jan 2011 20:51:25 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGt+RE2rR7Ht/2dsb2JhbACkeXOgbZoegniCVgSFE4cOg0WITA Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 30 Jan 2011 04:54:21 +0000 Received: from [192.168.4.3] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0U4rUUO015483; Sun, 30 Jan 2011 04:54:20 GMT Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4D421795.70505@isi.edu> Date: Sat, 29 Jan 2011 20:54:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1082) Cc: tsvwg@ietf.org, IETF discussion list , Paul Hoffman , IESG IESG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 04:51:27 -0000 On Jan 27, 2011, at 17:10 , Joe Touch wrote: > On 1/27/2011 12:52 AM, Lars Eggert wrote: > ... > >> Small Issue #3: I object to anonymous review > >> > >> The current review is anonymous and this draft does not seem to = change that. I don't like anonymous review - it's not how we do things = at IETF and it encourages really bad behavior. I have several emails = with an expert reviewer relayed via IANA where the conversation was = going no where - once I knew the name of the reviewer, the whole = conversation changed and stuff quickly came back to the realm of sane. = I'm not willing to forward these emails to the list as that would just = not be kind to anyone but I am happy to forward them to the IESG if they = think looking at them is really critical. > > > > I can see your point, and I personally have no problem with = disclosing the reviewer identity. What do others think? >=20 > AFAICT, the experts team reports to IANA. We make recommendations to > them. They are the ones who have the conversation with the applicant. > They can take our advice or not - that's their decision. I think you are pretty misrepresenting the situation. My impression of = the reality of the situation is that if the IANA did not like the advice = of the expert reviewer, they might ask the AD to override but short of = that they pretty much do whatever the expert says.=20 From fluffy@cisco.com Sat Jan 29 20:52:28 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02F8D3A6A6C; Sat, 29 Jan 2011 20:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.582 X-Spam-Level: X-Spam-Status: No, score=-110.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f71hJYJ5X5Nz; Sat, 29 Jan 2011 20:52:27 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 253AD3A6A6B; Sat, 29 Jan 2011 20:52:27 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGt+RE2rR7Ht/2dsb2JhbACkeXOgbZoehU4EhROHDoNF Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 30 Jan 2011 04:55:37 +0000 Received: from [192.168.4.3] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0U4ta2q016095; Sun, 30 Jan 2011 04:55:37 GMT Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <37255E32-37F1-4907-8A5A-6AB7B590562F@ietf.org> Date: Sat, 29 Jan 2011 20:55:36 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110118212603.5733.34489.idtracker@localhost> <37255E32-37F1-4907-8A5A-6AB7B590562F@ietf.org> To: IETF Chair X-Mailer: Apple Mail (2.1082) Cc: IETF discussion list , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 04:52:28 -0000 On Jan 27, 2011, at 8:12 , IETF Chair wrote: >=20 > Originally, two ports were assigned for plain and over-TLS, which for = HTTP mapped to two different URL schemes: http and https. >=20 > Many people thought that this was a waste of a port, and the STARTTLS = approach was developed. You say that it does not work in some cases, = and you seem to be suggesting that we go back to the original way. >=20 > Maybe it works in some cases and not others. Can we say which is = which? I did misread the draft as saying that 2 ports were not allowed when = clearly that was not what people meant but ... I'm mostly concerned about cases where latency or bandwidth are an issue = - basically protocols for real time protocols for internet of things. = For things like email I'm less concerned. However, I think we can make = some observation about which works best. Consider some of the most = successful protocols on the internet http, 2 ports email, pop, imap, and smtp, - more use on multi ports than STARTLS = though many deployment support both=20 sip, 2 ports=20 From fluffy@cisco.com Sat Jan 29 20:53:01 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33B543A6B0B; Sat, 29 Jan 2011 20:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.582 X-Spam-Level: X-Spam-Status: No, score=-110.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWT64mZnkPwc; Sat, 29 Jan 2011 20:52:59 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6046B3A6B07; Sat, 29 Jan 2011 20:52:59 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGt+RE2rR7Ht/2dsb2JhbACkeXOgbZoehU4EhROHDoNF Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 30 Jan 2011 04:56:10 +0000 Received: from [192.168.4.3] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0U4ta2r016095; Sun, 30 Jan 2011 04:56:08 GMT Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4D413827.7040407@ericsson.com> Date: Sat, 29 Jan 2011 20:56:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110118212603.5733.34489.idtracker@localhost> <4D413827.7040407@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1082) Cc: IESG IESG , IETF discussion list , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 04:53:01 -0000 I read the draft to say that there would only be one port allocated - I = took strive to mean that Joe would deny my port requests for two ports. = If the intention is actually for the draft to say that it strives for = one port but allows assignment of two where the that is what the = protocol design desire, then I have no problem. Perhaps we just need to = clarify what "strive" means. This definition of "strive" leads into = exactly my other complain that this draft provides no guidance on what = the expert will or will not approve.=20 We probably need to adjust text like=20 o IANA strives to encourage the deployment of secure protocols, and so strives to avoid separate assignments for non-secure variants and=20 The use of separate service name or port number assignments for secure and insecure variants of the same service is to be avoided in order to discourage the deployment of insecure services. and=20 Services are expected to include support for security, either as default or dynamically negotiated in-band. In band negotiation of security is applicable for some cases, but it = adds latency, bandwidth, and complicated multiplexing in non session = based transports. I think this is a bad idea in many cases. I also view = separation even for stream based protocols as something that helps = management and debugging as well as policy.=20 On Jan 27, 2011, at 1:17 , Magnus Westerlund wrote: >=20 > We have extensive discussion on this in the WG last call. There was no > consensus for having two ports. At the same time we did also have no > consensus on mandating one port for any future protocol. Thus we > adjusted the text to say in Section 7.2: >=20 > IANA strives to assign only one assigned port number per service or > application >=20 > To my knowledge "strive" is not a binding RFC2119 term. I also think = it > is a good trade-off with the intention of preserving the space as well > as possible with only assigning one port, and still allow for more = than > one if it really is needed. >=20 > Is it the above text that triggered your comment or some other text? >=20 > Cheers >=20 > Magnus Westerlund Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From touch@isi.edu Sat Jan 29 21:28:36 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 229163A6B06; Sat, 29 Jan 2011 21:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcJGS-75Ki95; Sat, 29 Jan 2011 21:28:35 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 2CF263A6B05; Sat, 29 Jan 2011 21:28:35 -0800 (PST) Received: from [128.9.176.217] (c2-vpn05.isi.edu [128.9.176.217]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p0U5VDtA000211 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sat, 29 Jan 2011 21:31:14 -0800 (PST) Message-ID: <4D44F7A1.9090608@isi.edu> Date: Sat, 29 Jan 2011 21:31:13 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Cullen Jennings Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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, Paul Hoffman , The IESG , Michelle Cotton , IETF discussion list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 05:28:36 -0000 On 1/29/2011 8:53 PM, Cullen Jennings wrote: > > On Jan 27, 2011, at 17:29 , Michelle Cotton wrote: > >> We are changing that process right now. We have begun to report the >> reviewer (with the review) in the email to the requester. >> >> We just need to make sure this small change is communicated to those experts >> that are part of review "teams" as their individual names are not published >> on the main list of registries. >> >> I don't think it needs to go in this document as this is already in >> progress. >> >> Let me know if you have any questions. > > As long as we agree that is the process, it's not a big deal to me if > it is in or out of the document but I don't see any reason not to put > it into the document. The reason is that this document isn't about the IANA process for reviewing ports; it's about unifying the port registries. RFC2780 specifies Expert Review as *one* of the viable means by which IANA can decide on transport protocol port assignments: Both the Source and Destination Port fields use the same namespace. Values in this namespace are assigned following a Specification Required, Expert Review, IESG Approval, IETF Consensus, or Standards Action process. The term "Expert Review" is defined in RFC 2434. Neither document mandates that IANA either act on the advice such a review, nor that the reviewer identity be disclosed as part of that process. Further, the list of such experts is known by IANA and the IESG: Designated experts are appointed by the relevant Area Director of the IESG. They are typically named at the time a document that creates a new numbering space is published as an RFC, but as experts originally appointed may later become unavailable, the relevant Area Director will appoint replacements if necessary. If you want to codify this process further, you would need to revise RFC2434 - e.g., to require the disclosure of the expert reviewer. However, that is not in the scope of this document. Joe From touch@isi.edu Sat Jan 29 21:31:54 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D6683A6876; Sat, 29 Jan 2011 21:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5Hxk0lhYFlN; Sat, 29 Jan 2011 21:31:47 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 1ADB53A6B06; Sat, 29 Jan 2011 21:31:47 -0800 (PST) Received: from [128.9.176.217] (c2-vpn05.isi.edu [128.9.176.217]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p0U5YLrh000739 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sat, 29 Jan 2011 21:34:21 -0800 (PST) Message-ID: <4D44F85D.5030407@isi.edu> Date: Sat, 29 Jan 2011 21:34:21 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Cullen Jennings Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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, IETF discussion list , Paul Hoffman , IESG IESG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 05:31:55 -0000 On 1/29/2011 8:54 PM, Cullen Jennings wrote: > > On Jan 27, 2011, at 17:10 , Joe Touch wrote: ... >> AFAICT, the experts team reports to IANA. We make recommendations to >> them. They are the ones who have the conversation with the applicant. >> They can take our advice or not - that's their decision. > > I think you are pretty misrepresenting the situation. My impression > of the reality of the situation is that if the IANA did not like the > advice of the expert reviewer, they might ask the AD to override but > short of that they pretty much do whatever the expert says. As per my other note: RFC2780 specifies Expert Review as *one* of the viable means by which IANA can decide on transport protocol port assignments. The term "Expert Review" is defined in RFC 2434. Neither document binds IANA to use the advice of a reviewer. Further, there is no single reviewer - we have a team, consulting each other on occasion, and all decisions are seen by multiple reviewers. However, none of that is worth codifying. If IANA or the IESG doesn't like how we serve them, they can replace us - at any time, for any reason, and there is an appeals process for decisions of the expert team: Any decisions made by the designated expert can be appealed using the normal IETF appeals process as outlined in Section 6.5 of [IETF- PROCESS]. Joe From touch@isi.edu Sun Jan 30 09:31:15 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 863DA3A6AF1; Sun, 30 Jan 2011 09:31:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LK2u4Kuh5rO6; Sun, 30 Jan 2011 09:31:14 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 23BBF3A6ABD; Sun, 30 Jan 2011 09:31:14 -0800 (PST) Received: from [192.168.1.93] (pool-71-105-81-169.lsanca.dsl-w.verizon.net [71.105.81.169]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p0UHY2IY008760 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sun, 30 Jan 2011 09:34:13 -0800 (PST) Message-ID: <4D45A105.1020102@isi.edu> Date: Sun, 30 Jan 2011 09:33:57 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Paul Hoffman Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> In-Reply-To: <4D457FD9.5030905@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IESG IESG , tsvwg@ietf.org, IETF discussion list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 17:31:15 -0000 Paul (et al.), See below. Note that IANA can't just make its own decisions either and ignore IETF process *AND* expert review. I wasn't trying to imply that, but it appears to have been inferred from my claim that "neither document binds IANA to the advice of a reviewer". IANA is bound by the "OR" of basic IETF process and Expert Review. The former can override the latter (or vice versa), but there is an appeal process - through the IETF - as well. If you have issue with these processes, then RFC 2434 and RFC 2780 are your targets, not this doc. Joe On 1/30/2011 7:12 AM, Paul Hoffman wrote: > On 1/29/11 9:34 PM, Joe Touch wrote: ... >> As per my other note: >> RFC2780 specifies Expert Review as *one* of the viable means by which >> IANA can decide on transport protocol port assignments. The term "Expert >> Review" is defined in RFC 2434. >> >> Neither document binds IANA to use the advice of a reviewer. >> >> Further, there is no single reviewer - we have a team, consulting each >> other on occasion, and all decisions are seen by multiple reviewers. >> However, none of that is worth codifying. If IANA or the IESG doesn't >> like how we serve them, they can replace us - at any time, for any >> reason, and there is an appeals process for decisions of the expert team: >> >> Any decisions made by the designated expert can be appealed using the >> normal IETF appeals process as outlined in Section 6.5 of [IETF- >> PROCESS]. > > Now that this has been made clear to me, I am *much* more worried about > the wording in the current draft. The above emphatic statements means > that IANA can reject a request for an IETF-approved protocol that needs > two ports without recourse. Repeating myself: a) this document is NOT proscribing IANA processes for expert review of port requests b) RFC 2790 describes MANY ways IANA decides how to allocate ports: Values in this namespace are assigned following a Specification Required, Expert Review, IESG Approval, IETF Consensus, or Standards Action. Note the word *OR* above. Expert review doesn't override IETF process here. > The document should be amended to say that protocols with IETF > consensus should get as many ports as it needs, regardless of what > IANA or the expert reviewer thinks. The above section already allows for that. > This makes it the responsibility > of the IETF consensus process to follow the guidelines in this > document. This document says, quite clearly, at the front of Section 7.2: This section summarizes the current principles by which IANA handles the Service Name and Transport Protocol Port Number Registry and attempts to conserve the port number space. This description is intended to inform applicants requesting service names and port numbers. IANA has flexibility beyond these principles when handling assignment requests; other factors may come into play, and exceptions may be made to best serve the needs of the Internet. It never says that this is a process that the IESG or IETF is required to follow. The language of the section has wiggle words throughout, and does not use RFC 2119 language. Thus nobody anywhere is bound by it. c) RFC 2434 notes how expert reviewers are selected: Designated experts are appointed by the relevant Area Director of the IESG. They are typically named at the time a document that creates a new numbering space is published as an RFC, but as experts originally appointed may later become unavailable, the relevant Area Director will appoint replacements if necessary. d) there is already a process to appeal decisions that are based on Expert Review: Any decisions made by the designated expert can be appealed using the normal IETF appeals process as outlined in Section 6.5 of [IETF- PROCESS]. Since the designated experts are appointed by the IESG, they may be removed by the IESG. ------ From michelle.cotton@icann.org Sun Jan 30 11:07:16 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E4963A6851; Sun, 30 Jan 2011 11:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.465 X-Spam-Level: X-Spam-Status: No, score=-106.465 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tid-NTBZefCg; Sun, 30 Jan 2011 11:06:45 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 762D43A6849; Sun, 30 Jan 2011 11:06:45 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Sun, 30 Jan 2011 11:09:57 -0800 From: Michelle Cotton To: David Conrad , Cullen Jennings Date: Sun, 30 Jan 2011 11:09:54 -0800 Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Thread-Topic: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Thread-Index: AcvAruKab6Aanz9fQse61B69W+wxdgAAmQ2x Message-ID: In-Reply-To: <2E96E191-26AD-41CA-A0BA-099276312814@virtualized.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF, "tsvwg@ietf.org" , discussion list , The IESG , Paul Hoffman X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 19:07:16 -0000 David has said this well. Thank you. Please let me know if there are any other questions. --Michelle On 1/30/11 10:52 AM, "David Conrad" wrote: > Cullen, >=20 > On Jan 29, 2011, at 8:54 PM, Cullen Jennings wrote: >>> AFAICT, the experts team reports to IANA. We make recommendations to >>> them. They are the ones who have the conversation with the applicant. >>> They can take our advice or not - that's their decision. >>=20 >> I think you are pretty misrepresenting the situation. My impression of t= he >> reality of the situation is that if the IANA did not like the advice of = the >> expert reviewer, they might ask the AD to override but short of that the= y >> pretty much do whatever the expert says. >=20 >=20 > Joe is closer. =20 >=20 > In general, IANA staff are not technical experts in any of the wide varie= ty of > areas for which they are asked to provide registry services. As such, th= ey > rely on technical experts to provide input/advice/recommendations. In th= e > past, there were some very rare cases in which the advice provided by the > technical experts was deemed insufficient and IANA staff looked to the AD= s or > the IESG for additional input. However, at least historically, IANA staf= f > viewed the maintenance of the registries as their responsibility (at the > direction of the IESG), not the technical experts' responsibility. I woul= d be > surprised if this had changed. >=20 > Regards, > -drc >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From lars.eggert@nokia.com Mon Jan 31 00:20:46 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFC4C3A6BB1; Mon, 31 Jan 2011 00:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.796 X-Spam-Level: X-Spam-Status: No, score=-103.796 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xP14HQYMOJzK; Mon, 31 Jan 2011 00:20:46 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id DB3093A6BB9; Mon, 31 Jan 2011 00:20:45 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0V8NuQ1012118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Jan 2011 10:23:57 +0200 Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-14-327443728; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4D457FD9.5030905@vpnc.org> Date: Mon, 31 Jan 2011 10:23:43 +0200 Message-Id: References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Mon, 31 Jan 2011 10:23:48 +0200 (EET) X-Nokia-AV: Clean Cc: tsvwg@ietf.org, IETF discussion list , IESG IESG , Joe Touch X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 08:20:47 -0000 --Apple-Mail-14-327443728 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2011-1-30, at 17:12, Paul Hoffman wrote: > The above emphatic statements means that IANA can reject a request for = an IETF-approved protocol that needs two ports without recourse. I don't follow. Assignments through IETF-stream documents do not go = through expert review. And I've never witnessed IANA rejecting requests = coming through the IETF. But even if they did, there is an appeals = procedure. Lars=20= --Apple-Mail-14-327443728 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEzMTA4MjM0M1owIwYJKoZIhvcNAQkE MRYEFKCf303LMvmzDao+W1UcPtMq7sZRMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB ABiqSyROzEOw5SRI713JGRYAsMc4G2NALek56P185xuS7Y1CNPT9WBc5cfiqhbGl+Mkynwhp6ou7 XJibylFC4hcZaAU0+8HnxMn+2ieruqFf449Suqa7K9jIb7Yn9sLmgJSjsAodhadtBa4XsLEicPhQ xUBVkK4PfWkcfFFNaQqNvxJ+d8UFdK5HjGLARmzCZ7tu4OeGDjQkJUCeT2vW+LHlCFGcqo4TVYL7 e4vwTLoaaHxQBzE2g6gk/koNBg4kgm0p/aTtlz0Sd557zHxtRycboSjZnnexa5S/Ihh7+14Lq3Xp mZ7lj1utAEEvrVm/DgXr3DVRCUm3Nncxw714uDMAAAAAAAA= --Apple-Mail-14-327443728-- From magnus.westerlund@ericsson.com Mon Jan 31 05:02:50 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 799573A694A; Mon, 31 Jan 2011 05:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.485 X-Spam-Level: X-Spam-Status: No, score=-106.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEKf-Fcv7j44; Mon, 31 Jan 2011 05:02:49 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id D08B33A6BEC; Mon, 31 Jan 2011 05:02:48 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-93-4d46b3baadd5 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 77.AC.23694.AB3B64D4; Mon, 31 Jan 2011 14:06:02 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.2.234.1; Mon, 31 Jan 2011 14:06:01 +0100 Message-ID: <4D46B3B9.4050804@ericsson.com> Date: Mon, 31 Jan 2011 14:06:01 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Cullen Jennings Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D413827.7040407@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: IESG IESG , IETF discussion list , "tsvwg@ietf.org" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 13:02:50 -0000 Cullen Jennings skrev 2011-01-30 05:56: > > I read the draft to say that there would only be one port allocated - I took strive to mean that Joe would deny my port requests for two ports. If the intention is actually for the draft to say that it strives for one port but allows assignment of two where the that is what the protocol design desire, then I have no problem. Perhaps we just need to clarify what "strive" means. This definition of "strive" leads into exactly my other complain that this draft provides no guidance on what the expert will or will not approve. > > We probably need to adjust text like > > o IANA strives to encourage the deployment of secure protocols, and > so strives to avoid separate assignments for non-secure variants > > and > > The use of separate > service name or port number assignments for secure and insecure > variants of the same service is to be avoided in order to discourage > the deployment of insecure services. > > and > > Services are expected to include support for security, either as > default or dynamically negotiated in-band. > > > In band negotiation of security is applicable for some cases, but it adds latency, bandwidth, and complicated multiplexing in non session based transports. I think this is a bad idea in many cases. I also view separation even for stream based protocols as something that helps management and debugging as well as policy. > Well, the high level goal is to preserve a limited resource. We can't do that without making the preference clear. But I think you have forgotten to consider those statements trying to make clear that this is up to review. The review criterias can be expected to change overtime. They are also hard to codify. Especially for this case, how do we measure architectural uncleanness, implementation issues, and performance impact to make a rule that judges if one or more port is allowed? We clearly can't, this will be up to human judgment. I also think it is important that we separate the basic registry rules from the review guidelines, as they will change. Thus this is a separate document. One that we should make clear is going to exist. And as pointed out in other parts of this discussion there are several ways of challenging the reviewers recommendation resulting in an IANA decision. First of all is the appeal process. Secondly, is to take it through the IETF approval process where IETF makes the decision, not IANA. As I see it, we either leave these high level goals in this document, or we remove the completely and put everything in a separate document. I rather leave them in, because I don't seem them changing. Only be acted up in varying ways over the coming years. Cheers 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 paul.hoffman@vpnc.org Sun Jan 30 07:09:15 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B3F23A699E; Sun, 30 Jan 2011 07:09:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.75 X-Spam-Level: X-Spam-Status: No, score=-101.75 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzelg3HlWQRr; Sun, 30 Jan 2011 07:09:14 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id B14723A67B4; Sun, 30 Jan 2011 07:09:14 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0UFCOd5016644 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 30 Jan 2011 08:12:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D457FD9.5030905@vpnc.org> Date: Sun, 30 Jan 2011 07:12:25 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Joe Touch Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> In-Reply-To: <4D44F85D.5030407@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 31 Jan 2011 06:54:05 -0800 Cc: IESG IESG , tsvwg@ietf.org, IETF discussion list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 15:09:15 -0000 On 1/29/11 9:34 PM, Joe Touch wrote: > > > On 1/29/2011 8:54 PM, Cullen Jennings wrote: >> >> On Jan 27, 2011, at 17:10 , Joe Touch wrote: > ... >>> AFAICT, the experts team reports to IANA. We make recommendations to >>> them. They are the ones who have the conversation with the applicant. >>> They can take our advice or not - that's their decision. >> >> I think you are pretty misrepresenting the situation. My impression >> of the reality of the situation is that if the IANA did not like the >> advice of the expert reviewer, they might ask the AD to override but >> short of that they pretty much do whatever the expert says. > > As per my other note: > RFC2780 specifies Expert Review as *one* of the viable means by which > IANA can decide on transport protocol port assignments. The term "Expert > Review" is defined in RFC 2434. > > Neither document binds IANA to use the advice of a reviewer. > > Further, there is no single reviewer - we have a team, consulting each > other on occasion, and all decisions are seen by multiple reviewers. > However, none of that is worth codifying. If IANA or the IESG doesn't > like how we serve them, they can replace us - at any time, for any > reason, and there is an appeals process for decisions of the expert team: > > Any decisions made by the designated expert can be appealed using the > normal IETF appeals process as outlined in Section 6.5 of [IETF- > PROCESS]. Now that this has been made clear to me, I am *much* more worried about the wording in the current draft. The above emphatic statements means that IANA can reject a request for an IETF-approved protocol that needs two ports without recourse. As Cullen and others have pointed out, there are sometimes very good technical reasons for a particular protocol to need to have two ports. The document should be amended to say that protocols with IETF consensus should get as many ports as it needs, regardless of what IANA or the expert reviewer thinks. This makes it the responsibility of the IETF consensus process to follow the guidelines in this document. From drc@virtualized.org Sun Jan 30 10:49:05 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C24F83A6AD2; Sun, 30 Jan 2011 10:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxhCxWIgUzfT; Sun, 30 Jan 2011 10:49:04 -0800 (PST) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id CAD513A684E; Sun, 30 Jan 2011 10:49:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 328B3106F259; Sun, 30 Jan 2011 10:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cDctRJsvFv0; Sun, 30 Jan 2011 10:52:15 -0800 (PST) Received: from [10.0.1.9] (c-24-130-212-17.hsd1.ca.comcast.net [24.130.212.17]) by virtualized.org (Postfix) with ESMTP id 1D212106F24B; Sun, 30 Jan 2011 10:52:15 -0800 (PST) Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: Date: Sun, 30 Jan 2011 10:52:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2E96E191-26AD-41CA-A0BA-099276312814@virtualized.org> References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> To: Cullen Jennings X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Mon, 31 Jan 2011 06:54:05 -0800 Cc: IESG IESG , Paul Hoffman , IETF discussion list , tsvwg@ietf.org, Joe Touch X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 18:49:05 -0000 Cullen, On Jan 29, 2011, at 8:54 PM, Cullen Jennings wrote: >> AFAICT, the experts team reports to IANA. We make recommendations to >> them. They are the ones who have the conversation with the applicant. >> They can take our advice or not - that's their decision. >=20 > I think you are pretty misrepresenting the situation. My impression of = the reality of the situation is that if the IANA did not like the advice = of the expert reviewer, they might ask the AD to override but short of = that they pretty much do whatever the expert says.=20 Joe is closer. =20 In general, IANA staff are not technical experts in any of the wide = variety of areas for which they are asked to provide registry services. = As such, they rely on technical experts to provide = input/advice/recommendations. In the past, there were some very rare = cases in which the advice provided by the technical experts was deemed = insufficient and IANA staff looked to the ADs or the IESG for additional = input. However, at least historically, IANA staff viewed the = maintenance of the registries as their responsibility (at the direction = of the IESG), not the technical experts' responsibility. I would be = surprised if this had changed. Regards, -drc From paul.hoffman@vpnc.org Mon Jan 31 06:48:01 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F8073A6BFF; Mon, 31 Jan 2011 06:48:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.754 X-Spam-Level: X-Spam-Status: No, score=-101.754 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkn6KIkn7r4Y; Mon, 31 Jan 2011 06:48:00 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id AD2353A67F9; Mon, 31 Jan 2011 06:48:00 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0VEpCcl065541 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 31 Jan 2011 07:51:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D46CC62.1040006@vpnc.org> Date: Mon, 31 Jan 2011 06:51:14 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Lars Eggert Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 31 Jan 2011 06:54:05 -0800 Cc: tsvwg@ietf.org, IETF discussion list , IESG IESG , Joe Touch X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 14:48:01 -0000 On 1/31/11 12:23 AM, Lars Eggert wrote: > On 2011-1-30, at 17:12, Paul Hoffman wrote: >> The above emphatic statements means that IANA can reject a request for an IETF-approved protocol that needs two ports without recourse. > > I don't follow. Assignments through IETF-stream documents do not go > through expert review. Then this should be made *much* clearer in the document. In fact, the document says: A key element of the procedural streamlining specified in this document is to establish identical assignment procedures for all IETF transport protocols. I assumed that "all" meant "all", not "all except those through IETF-stream documents"; others might have read it the same way I did. Further, the wording throughout the template description in 8.1 makes it sound like that the restrictions in this document apply to everything that needs a template, which clearly includes IETF-stream documents. > And I've never witnessed IANA rejecting requests coming through the > IETF. This document is about new restrictions for the future, not what has happened in the past. > But even if they did, there is an appeals procedure. That is slim comfort to a WG that has designed a protocol that has good design reasons for needing two ports and, at the last minute is told that they either have to re-design from scratch or go through an appeals process to justify their design to IANA. It's fine that they have to justify it to the IESG (well, fine to me; other greybeards seem to not like that so much these days), but there should be no way that IANA can say "you cannot get ports assigned because this new RFC says that you designed your protocol wrong". If what you say above about "Assignments through IETF-stream documents do not go through expert review." is true, it should be plainly stated in the introduction to the document. From lars.eggert@nokia.com Mon Jan 31 07:03:21 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86CFE3A6C0C; Mon, 31 Jan 2011 07:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.768 X-Spam-Level: X-Spam-Status: No, score=-103.768 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3HHYGNYih1W; Mon, 31 Jan 2011 07:03:20 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 684753A6C07; Mon, 31 Jan 2011 07:03:20 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0VF6VWf028591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Jan 2011 17:06:33 +0200 Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-18-351603736; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4D46CC62.1040006@vpnc.org> Date: Mon, 31 Jan 2011 17:06:23 +0200 Message-Id: <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <4D46CC62.1040006@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Mon, 31 Jan 2011 17:06:28 +0200 (EET) X-Nokia-AV: Clean Cc: tsvwg@ietf.org, IETF discussion list , IESG IESG , Joe Touch X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 15:03:21 -0000 --Apple-Mail-18-351603736 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2011-1-31, at 16:51, Paul Hoffman wrote: > On 1/31/11 12:23 AM, Lars Eggert wrote: >> On 2011-1-30, at 17:12, Paul Hoffman wrote: >>> The above emphatic statements means that IANA can reject a request = for an IETF-approved protocol that needs two ports without recourse. >>=20 >> I don't follow. Assignments through IETF-stream documents do not go >> through expert review. >=20 > Then this should be made *much* clearer in the document. In fact, the = document says: >=20 > A key element of the procedural streamlining specified in this > document is to establish identical assignment procedures for all = IETF > transport protocols. >=20 > I assumed that "all" meant "all", not "all except those through = IETF-stream documents"; others might have read it the same way I did. The sentence you quote isn't related to the issue we're discussing. It = is intended to say "a goal is that the procedures to get ports and = service names are the same for UDP, TCP, DCCP and SCTP." (Maybe it would = be clearer by explicitly naming these protocols in the document.) But I see the point you're raising. The document should somewhere say = that "Expert Review" is the procedure used for assignment requests made = directly to IANA, whereas for documents on the IETF Stream, "IETF = Consensus" is sufficient to make the assignment. In other words, no = expert review doesn't really need to happen for those, since IETF Review = and IESG Approval are at least equivalent. Did I get that right? >> But even if they did, there is an appeals procedure. >=20 > That is slim comfort to a WG that has designed a protocol that has = good design reasons for needing two ports and, at the last minute is = told that they either have to re-design from scratch or go through an = appeals process to justify their design to IANA. It's fine that they = have to justify it to the IESG (well, fine to me; other greybeards seem = to not like that so much these days), but there should be no way that = IANA can say "you cannot get ports assigned because this new RFC says = that you designed your protocol wrong". If what you say above about = "Assignments through IETF-stream documents do not go through expert = review." is true, it should be plainly stated in the introduction to the = document. Right. I think the change I outlined above would address this. Thanks! Lars= --Apple-Mail-18-351603736 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEzMTE1MDYyM1owIwYJKoZIhvcNAQkE MRYEFOhp46BHP6QFd08yJ/ZKjcTrVErZMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AAAG/Y2RNHh1DdpBUp4+okYG7AwzBGQmN1+do76U0jdwqlgMfMyB/RwpYTO+3zQh79uR2uLtuOOX htPWKE3mKBduR0WhPSueV+y3aYu+19NWD+YoKg8VAIbbFVop7ZcSX+JDpksGFBICK9OpzUE7y6rG X9+10FrUtekb/4g+L9eSgR+riCrEJXMwSYm3/RmrO98VG7s0dHq6LP3zsBCxDkIBnNL19KEID4bq NKuggsKKPdOmEcYWmp5PyY1XDkmfKC2kGcg9uK0+huIGg/TbXuyA9et5KjLyH5PdYV83lP365noA fNcbzaGWBDUZwem7Bf4ww+2lS7xrsVY22TSHFycAAAAAAAA= --Apple-Mail-18-351603736-- From fluffy@cisco.com Mon Jan 31 08:10:53 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C17D33A6C3F; Mon, 31 Jan 2011 08:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.582 X-Spam-Level: X-Spam-Status: No, score=-110.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Op4uPkcF4THd; Mon, 31 Jan 2011 08:10:45 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 554D83A6C39; Mon, 31 Jan 2011 08:10:45 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFtuRk2rR7Ht/2dsb2JhbACkeXOiNJp7hU4EhROHDoNF Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 31 Jan 2011 16:14:00 +0000 Received: from [192.168.4.3] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0VGDwuU011891; Mon, 31 Jan 2011 16:13:58 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP From: Cullen Jennings In-Reply-To: <4D46D1D3.10701@vpnc.org> Date: Mon, 31 Jan 2011 09:13:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> <4D46D1D3.10701@vpnc.org> To: Paul Hoffman , Lars Eggert , tsvwg@ietf.org, IETF discussion list , IESG IESG X-Mailer: Apple Mail (2.1082) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 16:10:53 -0000 On Jan 31, 2011, at 8:14 , Paul Hoffman wrote: > On 1/31/11 7:06 AM, Lars Eggert wrote: > > But I see the point you're raising. The document should somewhere = say > > that "Expert Review" is the procedure used for assignment requests > > made directly to IANA, whereas for documents on the IETF Stream, > > "IETF Consensus" is sufficient to make the assignment. In other > > words, no expert review doesn't really need to happen for those, > > since IETF Review and IESG Approval are at least equivalent. > > > > Did I get that right? >=20 > Yes, that would greatly reduce the concern about where and when (and = how > often!) the review would happen. >=20 Hmm ... I don't agree that solves the issue.=20 Well lets say the request was coming from 3GPP for a protocol they = designed - why should IANA be able to tell them no but IETF yes.=20 I think the policy issue here is fairly clear. We do not have consensus = that in all cases that one should not have a second port for security = (I'm basing this assertion on Magnus read of WG consensus and my read of = IETF LC consensus). Therefore that should not be a ground for the expert = reviewer (or IANA) to reject the registration. The document needs to be = updated to make that clear or it does not reflect consensus. If the = authors of the draft want to propose text for conditions when it would = be ok to reject a second port for security purposes and see if they can = get consensus for that text, that seems perfectly reasonable.=20 I'm sure that some people believe the draft, by using the word = "strives", actually means that this is not a grounds for rejection but = given the push back from Lars and Joe, I believe that "strives" means = that the decision is up to Joe. Given things could be read either ways, = I think it's fair to ask for the draft to clarify this.=20 From lear@cisco.com Mon Jan 31 08:24:42 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6628A3A6827; Mon, 31 Jan 2011 08:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.22 X-Spam-Level: X-Spam-Status: No, score=-110.22 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aym9kKrf6bTe; Mon, 31 Jan 2011 08:24:41 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E29003A67B6; Mon, 31 Jan 2011 08:24:40 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 31 Jan 2011 16:27:55 +0000 Received: from dhcp-10-61-100-10.cisco.com (dhcp-10-61-100-10.cisco.com [10.61.100.10]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p0VGRsC0015449; Mon, 31 Jan 2011 16:27:54 GMT Message-ID: <4D46E2FF.7010203@cisco.com> Date: Mon, 31 Jan 2011 17:27:43 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Cullen Jennings Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> <4D46D1D3.10701@vpnc.org> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IESG IESG , IETF discussion list , Paul Hoffman , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 16:24:42 -0000 On 1/31/11 5:13 PM, Cullen Jennings wrote: > Hmm ... I don't agree that solves the issue. > > Well lets say the request was coming from 3GPP for a protocol they designed - why should IANA be able to tell them no but IETF yes. Who, ultimately, is the steward of this precious resource? If it is not the IANA and it is not the IETF, then who? To say that it is everyone's responsibility is to avoid responsibility entirely. Who gets to say which standards organizations are stewards and which are not? > I think the policy issue here is fairly clear. We do not have consensus that in all cases that one should not have a second port for security (I'm basing this assertion on Magnus read of WG consensus and my read of IETF LC consensus). Therefore that should not be a ground for the expert reviewer (or IANA) to reject the registration. The document needs to be updated to make that clear or it does not reflect consensus. If the authors of the draft want to propose text for conditions when it would be ok to reject a second port for security purposes and see if they can get consensus for that text, that seems perfectly reasonable. This is a VERY VERY dangerous approach you propose, Cullen. It is akin to saying, "you can think about security later, because we'll have to give you a port for it later." We don't want to be saying that. From fluffy@cisco.com Mon Jan 31 08:30:05 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50FE63A6C3E; Mon, 31 Jan 2011 08:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.583 X-Spam-Level: X-Spam-Status: No, score=-110.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4UTNZ+BFXKH; Mon, 31 Jan 2011 08:30:03 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id DCC863A6C21; Mon, 31 Jan 2011 08:30:02 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAtzRk2rR7Hu/2dsb2JhbACkeXOiOpsBhU4EhROHDoNF Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 31 Jan 2011 16:33:17 +0000 Received: from [192.168.4.3] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0VGXFgj000531; Mon, 31 Jan 2011 16:33:16 GMT Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Mon, 31 Jan 2011 09:33:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Michelle Cotton X-Mailer: Apple Mail (2.1082) Cc: Paul Hoffman , IETF discussion list , David Conrad , "tsvwg@ietf.org" , The IESG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 16:30:05 -0000 So IANA has a huge amount of technical expertise and takes maintaing the = registries very seriously. I've seen them catch technical mistakes that = made all the way through WG and IESG review. I've got huge respect for = technical competence of IANA and in particular Michelle. So I'm not = questions that but I don't recall seeing them override an expert on a = technical issue. I'd be happy to hear of examples but lets consider the = example I am actually concerned about here.=20 =20 I put in a request for a latency sensitive protocol that uses DTLS and = request a different port for the secure version. Joe as expert review = says we should redesign the protocol to use something like STARTLS and = run on one port. I assert, with very little evidence, that will not meet = the latency goals of the protocol. Joe does not agree.=20 So Michelle, in that case, would you be willing to override Joe? I'm = sure you would be willing to help facilitate any conversations, bring in = other people such as ADs that can help etc. I was sort of working on the = assumption that you would not override Joe in this case and the the only = path forward would be an appeal to Lars but perhaps that is just a bad = assumption on my part. Appeals are really the worst way possible to = resolve things. I have a hard time imagining that IANA would want to = engage in a technical discussion to resolve this and instead relies on = the expert reviewer. I'll note that the expert review may report to IANA = but they are selected by and replaced by the IESG.=20 The important point here is that I really don't care if it is Joe or = IANA that is saying no - I think this document should be clear that this = BCP can not be used as grounds for rejecting the request for a second = port for security.=20 On Jan 30, 2011, at 12:09 , Michelle Cotton wrote: > David has said this well. Thank you. >=20 > Please let me know if there are any other questions. >=20 > --Michelle >=20 >=20 >=20 > On 1/30/11 10:52 AM, "David Conrad" wrote: >=20 >> Cullen, >>=20 >> On Jan 29, 2011, at 8:54 PM, Cullen Jennings wrote: >>>> AFAICT, the experts team reports to IANA. We make recommendations = to >>>> them. They are the ones who have the conversation with the = applicant. >>>> They can take our advice or not - that's their decision. >>>=20 >>> I think you are pretty misrepresenting the situation. My impression = of the >>> reality of the situation is that if the IANA did not like the advice = of the >>> expert reviewer, they might ask the AD to override but short of that = they >>> pretty much do whatever the expert says. >>=20 >>=20 >> Joe is closer. =20 >>=20 >> In general, IANA staff are not technical experts in any of the wide = variety of >> areas for which they are asked to provide registry services. As = such, they >> rely on technical experts to provide input/advice/recommendations. = In the >> past, there were some very rare cases in which the advice provided by = the >> technical experts was deemed insufficient and IANA staff looked to = the ADs or >> the IESG for additional input. However, at least historically, IANA = staff >> viewed the maintenance of the registries as their responsibility (at = the >> direction of the IESG), not the technical experts' responsibility. I = would be >> surprised if this had changed. >>=20 >> Regards, >> -drc >>=20 >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From magnus.westerlund@ericsson.com Mon Jan 31 08:37:55 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98D873A6C40; Mon, 31 Jan 2011 08:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.487 X-Spam-Level: X-Spam-Status: No, score=-106.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LTpZ94nDruT; Mon, 31 Jan 2011 08:37:54 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 05A883A6C43; Mon, 31 Jan 2011 08:37:53 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-42-4d46e623e149 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A1.49.23694.326E64D4; Mon, 31 Jan 2011 17:41:08 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.2.234.1; Mon, 31 Jan 2011 17:41:07 +0100 Message-ID: <4D46E623.3080602@ericsson.com> Date: Mon, 31 Jan 2011 17:41:07 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Cullen Jennings Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> <4D46D1D3.10701@vpnc.org> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: IESG IESG , IETF discussion list , Paul Hoffman , "tsvwg@ietf.org" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 16:37:55 -0000 Cullen Jennings skrev 2011-01-31 17:13: > Well lets say the request was coming from 3GPP for a protocol they designed - why should IANA be able to tell them no but IETF yes. I am not certain I understand what your issue is here. Is it that they can come to different conclusions, and that IETF can decided to override the expert review team? I think that is the logical conclusion, as the IETF's decision will have gone through a consensus process. One which the expert can provide their view into this. > > I think the policy issue here is fairly clear. We do not have consensus that in all cases that one should not have a second port for security (I'm basing this assertion on Magnus read of WG consensus and my read of IETF LC consensus). Therefore that should not be a ground for the expert reviewer (or IANA) to reject the registration. The document needs to be updated to make that clear or it does not reflect consensus. If the authors of the draft want to propose text for conditions when it would be ok to reject a second port for security purposes and see if they can get consensus for that text, that seems perfectly reasonable. My reading of the WG last call consensus is that nobody is disagreeing with the goal of trying minimize the port consumption. My interpretation is that we do need to state that goal in the document. And the only way of achieving this is to try to minimize the consumption by each protocol that requires a registration. That includes trying to get all multiplexing into that single socket, or at least use it for agreeing on dynamic range port for this protocol. > > I'm sure that some people believe the draft, by using the word "strives", actually means that this is not a grounds for rejection but given the push back from Lars and Joe, I believe that "strives" means that the decision is up to Joe. Given things could be read either ways, I think it's fair to ask for the draft to clarify this. It is a high level goal to minimize the port space consumption. I do believe there is strong consensus for this. And I believe that the only way of ensuring that this goal is meet is to take a pretty hard stance against frivolous use of ports. Thus, I still think there is clear grounds for rejecting requests for multiple ports based on not sufficiently motivating why it is impossible to not use one port. I do agree that these guidelines should be documented, and that is the plans as far as I know. Cheers 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 michelle.cotton@icann.org Mon Jan 31 08:52:47 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F4453A6C48; Mon, 31 Jan 2011 08:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.468 X-Spam-Level: X-Spam-Status: No, score=-106.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVc7bqBDTW-P; Mon, 31 Jan 2011 08:52:42 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 261133A67B4; Mon, 31 Jan 2011 08:52:42 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Mon, 31 Jan 2011 08:55:56 -0800 From: Michelle Cotton To: Cullen Jennings Date: Mon, 31 Jan 2011 08:55:53 -0800 Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Thread-Topic: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Thread-Index: AcvBZJ9mWsU96xX0SG+vL8gbuhiBkgAAxkG5 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Paul Hoffman , IETF discussion list , David Conrad , "tsvwg@ietf.org" , The IESG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 16:52:47 -0000 Cullen, We do have some technical expertise within the IANA staff, however our expertise is more aligned with the process of creating and maintaining registries. Part of that includes relying on the experts that the IESG designates to make the decisions for requests that utilize the "Expert Review" policy in RFC 5226. In the past, if there is strong disagreement from an expert and the requester disagrees, we have brought the Transport Area Directors into the communications to see if all parties can come to an agreement. In almost all cases, this is where a final decision is made. If that set of folks ca= n not come to a conclusion, we then would default to going to the IESG. With all requests, if there is any uncertainty as to what decision should be made, we go to the IESG for guidance. We do rely on the technical expertise of the appointed experts for all registries, but we ALWAYS have the possibility to seek guidance form the IESG. I don't believe we have ever had an official appeals with ports (Knocking o= n wood really hard!). Does that help? --Michelle On 1/31/11 8:33 AM, "Cullen Jennings" wrote: >=20 > So IANA has a huge amount of technical expertise and takes maintaing the > registries very seriously. I've seen them catch technical mistakes that m= ade > all the way through WG and IESG review. I've got huge respect for technic= al > competence of IANA and in particular Michelle. So I'm not questions that = but > I don't recall seeing them override an expert on a technical issue. I'd b= e > happy to hear of examples but lets consider the example I am actually > concerned about here. > =20 > I put in a request for a latency sensitive protocol that uses DTLS and re= quest > a different port for the secure version. Joe as expert review says we sho= uld > redesign the protocol to use something like STARTLS and run on one port. = I > assert, with very little evidence, that will not meet the latency goals o= f the > protocol. Joe does not agree. >=20 > So Michelle, in that case, would you be willing to override Joe? I'm sure= you > would be willing to help facilitate any conversations, bring in other peo= ple > such as ADs that can help etc. I was sort of working on the assumption th= at > you would not override Joe in this case and the the only path forward wou= ld be > an appeal to Lars but perhaps that is just a bad assumption on my part. > Appeals are really the worst way possible to resolve things. I have a har= d > time imagining that IANA would want to engage in a technical discussion t= o > resolve this and instead relies on the expert reviewer. I'll note that th= e > expert review may report to IANA but they are selected by and replaced by= the > IESG.=20 >=20 > The important point here is that I really don't care if it is Joe or IANA= that > is saying no - I think this document should be clear that this BCP can no= t be > used as grounds for rejecting the request for a second port for security. >=20 >=20 >=20 > On Jan 30, 2011, at 12:09 , Michelle Cotton wrote: >=20 >> David has said this well. Thank you. >>=20 >> Please let me know if there are any other questions. >>=20 >> --Michelle >>=20 >>=20 >>=20 >> On 1/30/11 10:52 AM, "David Conrad" wrote: >>=20 >>> Cullen, >>>=20 >>> On Jan 29, 2011, at 8:54 PM, Cullen Jennings wrote: >>>>> AFAICT, the experts team reports to IANA. We make recommendations to >>>>> them. They are the ones who have the conversation with the applicant. >>>>> They can take our advice or not - that's their decision. >>>>=20 >>>> I think you are pretty misrepresenting the situation. My impression of= the >>>> reality of the situation is that if the IANA did not like the advice o= f the >>>> expert reviewer, they might ask the AD to override but short of that t= hey >>>> pretty much do whatever the expert says. >>>=20 >>>=20 >>> Joe is closer.=20 >>>=20 >>> In general, IANA staff are not technical experts in any of the wide var= iety >>> of >>> areas for which they are asked to provide registry services. As such, = they >>> rely on technical experts to provide input/advice/recommendations. In = the >>> past, there were some very rare cases in which the advice provided by t= he >>> technical experts was deemed insufficient and IANA staff looked to the = ADs >>> or >>> the IESG for additional input. However, at least historically, IANA st= aff >>> viewed the maintenance of the registries as their responsibility (at th= e >>> direction of the IESG), not the technical experts' responsibility. I wo= uld >>> be >>> surprised if this had changed. >>>=20 >>> Regards, >>> -drc >>>=20 >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >>=20 >=20 >=20 > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 From touch@isi.edu Mon Jan 31 09:15:00 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9A623A67B7; Mon, 31 Jan 2011 09:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5xxmejejXri; Mon, 31 Jan 2011 09:15:00 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id EEC0A3A67B4; Mon, 31 Jan 2011 09:14:59 -0800 (PST) Received: from [192.168.1.93] (pool-71-105-81-169.lsanca.dsl-w.verizon.net [71.105.81.169]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p0VHGmQX014839 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 31 Jan 2011 09:16:58 -0800 (PST) Message-ID: <4D46EE80.8090906@isi.edu> Date: Mon, 31 Jan 2011 09:16:48 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Lars Eggert Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> In-Reply-To: <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; 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, IETF discussion list , Paul Hoffman , IESG IESG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 17:15:00 -0000 Lars, On 1/31/2011 7:06 AM, Lars Eggert wrote: > Hi, > > On 2011-1-31, at 16:51, Paul Hoffman wrote: >> On 1/31/11 12:23 AM, Lars Eggert wrote: >>> On 2011-1-30, at 17:12, Paul Hoffman wrote: >>>> The above emphatic statements means that IANA can reject a request for an IETF-approved protocol that needs two ports without recourse. >>> >>> I don't follow. Assignments through IETF-stream documents do not go >>> through expert review. >> >> Then this should be made *much* clearer in the document. In fact, the document says: >> >> A key element of the procedural streamlining specified in this >> document is to establish identical assignment procedures for all IETF >> transport protocols. >> >> I assumed that "all" meant "all", not "all except those through IETF-stream documents"; others might have read it the same way I did. > > The sentence you quote isn't related to the issue we're discussing. It is intended to say "a goal is that the procedures to get ports and service names are the same for UDP, TCP, DCCP and SCTP." (Maybe it would be clearer by explicitly naming these protocols in the document.) > > But I see the point you're raising. The document should somewhere say that "Expert Review" is the procedure used for assignment requests made directly to IANA, whereas for documents on the IETF Stream, "IETF Consensus" is sufficient to make the assignment. In other words, no expert review doesn't really need to happen for those, since IETF Review and IESG Approval are at least equivalent. RFC2434 already gives IANA these options. Perhaps - at best - we should include a ref to that. However, this document is not focused at changing what RFC2434 says, and the above statement, IMO, does. That's another can of worms, and should be reserved for a different document. Joe From touch@isi.edu Mon Jan 31 09:16:14 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4EDD3A69A9; Mon, 31 Jan 2011 09:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1hV47zPBtZW; Mon, 31 Jan 2011 09:16:13 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E167C3A6844; Mon, 31 Jan 2011 09:16:13 -0800 (PST) Received: from [192.168.1.93] (pool-71-105-81-169.lsanca.dsl-w.verizon.net [71.105.81.169]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p0VHIkLs015329 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 31 Jan 2011 09:18:56 -0800 (PST) Message-ID: <4D46EEF6.9010209@isi.edu> Date: Mon, 31 Jan 2011 09:18:46 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Paul Hoffman Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <4D46CC62.1040006@vpnc.org> In-Reply-To: <4D46CC62.1040006@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: IETF discussion list , IESG IESG , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 17:16:14 -0000 The procedures that are specified - for ALL assignments - are the PROCEDURES - the word itself is used specifically in the heading of section 8. That does not refer to the "principles" - again for which there are more than sufficient wiggle words, and which already cite existing RFCs that have provisions that already limit the role of Expert Review and allow for appeals. Again - this document is NOT focused on those principles. IANA - and more specifically its review team - is NOT required to publish any such principles (as per RFC 5226). If they continue to be a source of contention, then section 7 should be removed. Joe On 1/31/2011 6:51 AM, Paul Hoffman wrote: > On 1/31/11 12:23 AM, Lars Eggert wrote: >> On 2011-1-30, at 17:12, Paul Hoffman wrote: >>> The above emphatic statements means that IANA can reject a request >>> for an IETF-approved protocol that needs two ports without recourse. >> >> I don't follow. Assignments through IETF-stream documents do not go >> through expert review. > > Then this should be made *much* clearer in the document. In fact, the > document says: > > A key element of the procedural streamlining specified in this > document is to establish identical assignment procedures for all IETF > transport protocols. > > I assumed that "all" meant "all", not "all except those through > IETF-stream documents"; others might have read it the same way I did. > Further, the wording throughout the template description in 8.1 makes it > sound like that the restrictions in this document apply to everything > that needs a template, which clearly includes IETF-stream documents. > >> And I've never witnessed IANA rejecting requests coming through the >> IETF. > > This document is about new restrictions for the future, not what has > happened in the past. > >> But even if they did, there is an appeals procedure. > > That is slim comfort to a WG that has designed a protocol that has good > design reasons for needing two ports and, at the last minute is told > that they either have to re-design from scratch or go through an appeals > process to justify their design to IANA. It's fine that they have to > justify it to the IESG (well, fine to me; other greybeards seem to not > like that so much these days), but there should be no way that IANA can > say "you cannot get ports assigned because this new RFC says that you > designed your protocol wrong". If what you say above about "Assignments > through IETF-stream documents do not go through expert review." is true, > it should be plainly stated in the introduction to the document. From touch@isi.edu Mon Jan 31 09:23:11 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81ED03A67F0; Mon, 31 Jan 2011 09:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68YUQNe9SPOR; Mon, 31 Jan 2011 09:23:09 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id D8CCD3A699E; Mon, 31 Jan 2011 09:23:09 -0800 (PST) Received: from [192.168.1.93] (pool-71-105-81-169.lsanca.dsl-w.verizon.net [71.105.81.169]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p0VHPNh1016357 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 31 Jan 2011 09:25:33 -0800 (PST) Message-ID: <4D46F083.9090500@isi.edu> Date: Mon, 31 Jan 2011 09:25:23 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Lars Eggert Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> <4D46EE80.8090906@isi.edu> In-Reply-To: <4D46EE80.8090906@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; 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, IETF discussion list , Paul Hoffman , IESG IESG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 17:23:11 -0000 On 1/31/2011 9:16 AM, Joe Touch wrote: > Lars, > > On 1/31/2011 7:06 AM, Lars Eggert wrote: >> Hi, >> >> On 2011-1-31, at 16:51, Paul Hoffman wrote: >>> On 1/31/11 12:23 AM, Lars Eggert wrote: >>>> On 2011-1-30, at 17:12, Paul Hoffman wrote: >>>>> The above emphatic statements means that IANA can reject a request >>>>> for an IETF-approved protocol that needs two ports without recourse. >>>> >>>> I don't follow. Assignments through IETF-stream documents do not go >>>> through expert review. >>> >>> Then this should be made *much* clearer in the document. In fact, the >>> document says: >>> >>> A key element of the procedural streamlining specified in this >>> document is to establish identical assignment procedures for all IETF >>> transport protocols. >>> >>> I assumed that "all" meant "all", not "all except those through >>> IETF-stream documents"; others might have read it the same way I did. >> >> The sentence you quote isn't related to the issue we're discussing. It >> is intended to say "a goal is that the procedures to get ports and >> service names are the same for UDP, TCP, DCCP and SCTP." (Maybe it >> would be clearer by explicitly naming these protocols in the document.) >> >> But I see the point you're raising. The document should somewhere say >> that "Expert Review" is the procedure used for assignment requests >> made directly to IANA, whereas for documents on the IETF Stream, "IETF >> Consensus" is sufficient to make the assignment. In other words, no >> expert review doesn't really need to happen for those, since IETF >> Review and IESG Approval are at least equivalent. > > RFC2434 already gives IANA these options. As does RFC 5226 - its update (there is no substantive change between the two in this regard, FWIW). > Perhaps - at best - we should include a ref to that. And 5226 is already clearly cited. No further action should be required. Joe > However, this document is not focused at changing what RFC2434 says, and > the above statement, IMO, does. > > That's another can of worms, and should be reserved for a different > document. > > Joe From fluffy@cisco.com Mon Jan 31 09:36:51 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03D193A6977; Mon, 31 Jan 2011 09:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.583 X-Spam-Level: X-Spam-Status: No, score=-110.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+HgLik5gDUG; Mon, 31 Jan 2011 09:36:49 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 256033A67B6; Mon, 31 Jan 2011 09:36:49 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADeDRk2rR7H+/2dsb2JhbACkeXOiOpsQhU4EhROHDoNF Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 31 Jan 2011 17:39:50 +0000 Received: from [192.168.4.3] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0VHdmgZ020743; Mon, 31 Jan 2011 17:39:49 GMT Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Mon, 31 Jan 2011 10:39:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2DF650F5-A5DA-4AB6-9553-40FE38CE6175@cisco.com> References: To: Michelle Cotton X-Mailer: Apple Mail (2.1082) Cc: Paul Hoffman , IETF discussion list , David Conrad , "tsvwg@ietf.org" , The IESG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 17:36:51 -0000 Thanks - yes that makes it clear and I like the way IANA handles all of = this. On Jan 31, 2011, at 9:55 , Michelle Cotton wrote: > Cullen, >=20 > We do have some technical expertise within the IANA staff, however our > expertise is more aligned with the process of creating and maintaining > registries. Part of that includes relying on the experts that the = IESG > designates to make the decisions for requests that utilize the "Expert > Review" policy in RFC 5226. >=20 > In the past, if there is strong disagreement from an expert and the > requester disagrees, we have brought the Transport Area Directors into = the > communications to see if all parties can come to an agreement. In = almost > all cases, this is where a final decision is made. If that set of = folks can > not come to a conclusion, we then would default to going to the IESG. = With > all requests, if there is any uncertainty as to what decision should = be > made, we go to the IESG for guidance. >=20 > We do rely on the technical expertise of the appointed experts for all > registries, but we ALWAYS have the possibility to seek guidance form = the > IESG. >=20 > I don't believe we have ever had an official appeals with ports = (Knocking on > wood really hard!). >=20 > Does that help? >=20 > --Michelle >=20 >=20 >=20 > On 1/31/11 8:33 AM, "Cullen Jennings" wrote: >=20 >>=20 >> So IANA has a huge amount of technical expertise and takes maintaing = the >> registries very seriously. I've seen them catch technical mistakes = that made >> all the way through WG and IESG review. I've got huge respect for = technical >> competence of IANA and in particular Michelle. So I'm not questions = that but >> I don't recall seeing them override an expert on a technical issue. = I'd be >> happy to hear of examples but lets consider the example I am actually >> concerned about here. >>=20 >> I put in a request for a latency sensitive protocol that uses DTLS = and request >> a different port for the secure version. Joe as expert review says we = should >> redesign the protocol to use something like STARTLS and run on one = port. I >> assert, with very little evidence, that will not meet the latency = goals of the >> protocol. Joe does not agree. >>=20 >> So Michelle, in that case, would you be willing to override Joe? I'm = sure you >> would be willing to help facilitate any conversations, bring in other = people >> such as ADs that can help etc. I was sort of working on the = assumption that >> you would not override Joe in this case and the the only path forward = would be >> an appeal to Lars but perhaps that is just a bad assumption on my = part. >> Appeals are really the worst way possible to resolve things. I have a = hard >> time imagining that IANA would want to engage in a technical = discussion to >> resolve this and instead relies on the expert reviewer. I'll note = that the >> expert review may report to IANA but they are selected by and = replaced by the >> IESG.=20 >>=20 >> The important point here is that I really don't care if it is Joe or = IANA that >> is saying no - I think this document should be clear that this BCP = can not be >> used as grounds for rejecting the request for a second port for = security. >>=20 >>=20 >>=20 >> On Jan 30, 2011, at 12:09 , Michelle Cotton wrote: >>=20 >>> David has said this well. Thank you. >>>=20 >>> Please let me know if there are any other questions. >>>=20 >>> --Michelle >>>=20 >>>=20 >>>=20 >>> On 1/30/11 10:52 AM, "David Conrad" wrote: >>>=20 >>>> Cullen, >>>>=20 >>>> On Jan 29, 2011, at 8:54 PM, Cullen Jennings wrote: >>>>>> AFAICT, the experts team reports to IANA. We make recommendations = to >>>>>> them. They are the ones who have the conversation with the = applicant. >>>>>> They can take our advice or not - that's their decision. >>>>>=20 >>>>> I think you are pretty misrepresenting the situation. My = impression of the >>>>> reality of the situation is that if the IANA did not like the = advice of the >>>>> expert reviewer, they might ask the AD to override but short of = that they >>>>> pretty much do whatever the expert says. >>>>=20 >>>>=20 >>>> Joe is closer.=20 >>>>=20 >>>> In general, IANA staff are not technical experts in any of the wide = variety >>>> of >>>> areas for which they are asked to provide registry services. As = such, they >>>> rely on technical experts to provide input/advice/recommendations. = In the >>>> past, there were some very rare cases in which the advice provided = by the >>>> technical experts was deemed insufficient and IANA staff looked to = the ADs >>>> or >>>> the IESG for additional input. However, at least historically, = IANA staff >>>> viewed the maintenance of the registries as their responsibility = (at the >>>> direction of the IESG), not the technical experts' responsibility. = I would >>>> be >>>> surprised if this had changed. >>>>=20 >>>> Regards, >>>> -drc >>>>=20 >>>> _______________________________________________ >>>> Ietf mailing list >>>> Ietf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf >>>=20 >>=20 >>=20 >> Cullen Jennings >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>=20 >>=20 >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Mon Jan 31 09:41:16 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90C213A6977; Mon, 31 Jan 2011 09:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.583 X-Spam-Level: X-Spam-Status: No, score=-110.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yJszrRVSqii; Mon, 31 Jan 2011 09:41:15 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id BDFA33A6807; Mon, 31 Jan 2011 09:41:15 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAISDRk2rR7Hu/2dsb2JhbACkeXOiPJsQhU4EhROHDoNF Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 31 Jan 2011 17:44:30 +0000 Received: from [192.168.4.3] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0VHiSJH013208; Mon, 31 Jan 2011 17:44:29 GMT Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4D46E623.3080602@ericsson.com> Date: Mon, 31 Jan 2011 10:44:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9E89C43A-EB2A-4DAB-9B12-A740612783E8@cisco.com> References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> <4D46D1D3.10701@vpnc.org> <4D46E623.3080602@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1082) Cc: IESG IESG , IETF discussion list , Paul Hoffman , "tsvwg@ietf.org" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 17:41:16 -0000 On Jan 31, 2011, at 9:41 , Magnus Westerlund wrote: > Cullen Jennings skrev 2011-01-31 17:13: >=20 >> Well lets say the request was coming from 3GPP for a protocol they = designed - why should IANA be able to tell them no but IETF yes.=20 >=20 > I am not certain I understand what your issue is here. Is it that they > can come to different conclusions, and that IETF can decided to = override > the expert review team? I think that is the logical conclusion, as the > IETF's decision will have gone through a consensus process. One which > the expert can provide their view into this. >=20 >>=20 >> I think the policy issue here is fairly clear. We do not have = consensus that in all cases that one should not have a second port for = security (I'm basing this assertion on Magnus read of WG consensus and = my read of IETF LC consensus). Therefore that should not be a ground for = the expert reviewer (or IANA) to reject the registration. The document = needs to be updated to make that clear or it does not reflect consensus. = If the authors of the draft want to propose text for conditions when it = would be ok to reject a second port for security purposes and see if = they can get consensus for that text, that seems perfectly reasonable.=20= >=20 >=20 > My reading of the WG last call consensus is that nobody is disagreeing > with the goal of trying minimize the port consumption. My = interpretation > is that we do need to state that goal in the document. And the only = way > of achieving this is to try to minimize the consumption by each = protocol > that requires a registration. That includes trying to get all > multiplexing into that single socket, or at least use it for agreeing = on > dynamic range port for this protocol. >=20 >>=20 >> I'm sure that some people believe the draft, by using the word = "strives", actually means that this is not a grounds for rejection but = given the push back from Lars and Joe, I believe that "strives" means = that the decision is up to Joe. Given things could be read either ways, = I think it's fair to ask for the draft to clarify this.=20 >=20 > It is a high level goal to minimize the port space consumption. I do > believe there is strong consensus for this. And I believe that the = only > way of ensuring that this goal is meet is to take a pretty hard stance > against frivolous use of ports. >=20 > Thus, I still think there is clear grounds for rejecting requests for > multiple ports based on not sufficiently motivating why it is = impossible > to not use one port. I do agree that these guidelines should be > documented, and that is the plans as far as I know. Magnus, I agree with what you are saying here but you are avoiding the = issue I am concerned with. Is allocating a second port for the secure = version of a document a frivolous use case or not? I read this draft as = saying it is. Others read the draft as saying it is not and that type of = allocation is fine. This seems fairly easy to deal with - first lets = agree if particular 2nd port for secure version is a reason to reject = requests or not then see if any text needs to be adjusted in the draft = to reflect that.=20 From fluffy@cisco.com Mon Jan 31 09:48:39 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3F03A6ADF; Mon, 31 Jan 2011 09:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.583 X-Spam-Level: X-Spam-Status: No, score=-110.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqZjDtSro0qH; Mon, 31 Jan 2011 09:48:38 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 450043A6844; Mon, 31 Jan 2011 09:48:38 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 31 Jan 2011 17:51:53 +0000 Received: from [192.168.4.3] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0VHppL7003932; Mon, 31 Jan 2011 17:51:52 GMT Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4D46E2FF.7010203@cisco.com> Date: Mon, 31 Jan 2011 10:51:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <768DE9F6-FC0B-49B0-8244-0D97CD7BD2DA@cisco.com> References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> <4D46D1D3.10701@vpnc.org> <4D46E2FF.7010203@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1082) Cc: IESG IESG , IETF discussion list , Paul Hoffman , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 17:48:39 -0000 So first, we already have a BCP that says more or less all protocols = must implement a secure version but deployment is optional. This is a = good BCP, and it comes from the right area to say that - security. It's = probably impacts design work in working groups more than any other BCP. = It has IETF consensus. The IESG holds protocols to this.=20 Now - I am at loss to see why forcing people to use one port will make = it more likely to have secure protocols. This seems crazy. Please do = enlighten me. And on the topic, I'm still looking forward to an explanation of how the = current CoAP design stomping all over the TLS code points would be an = acceptable design.=20 On Jan 31, 2011, at 9:27 , Eliot Lear wrote: >=20 >=20 > On 1/31/11 5:13 PM, Cullen Jennings wrote: >> Hmm ... I don't agree that solves the issue.=20 >>=20 >> Well lets say the request was coming from 3GPP for a protocol they = designed - why should IANA be able to tell them no but IETF yes.=20 >=20 > Who, ultimately, is the steward of this precious resource? If it is = not > the IANA and it is not the IETF, then who? To say that it is = everyone's > responsibility is to avoid responsibility entirely. Who gets to say > which standards organizations are stewards and which are not? >=20 >> I think the policy issue here is fairly clear. We do not have = consensus that in all cases that one should not have a second port for = security (I'm basing this assertion on Magnus read of WG consensus and = my read of IETF LC consensus). Therefore that should not be a ground for = the expert reviewer (or IANA) to reject the registration. The document = needs to be updated to make that clear or it does not reflect consensus. = If the authors of the draft want to propose text for conditions when it = would be ok to reject a second port for security purposes and see if = they can get consensus for that text, that seems perfectly reasonable.=20= >=20 > This is a VERY VERY dangerous approach you propose, Cullen. It is = akin > to saying, "you can think about security later, because we'll have to > give you a port for it later." We don't want to be saying that. >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From lear@cisco.com Mon Jan 31 09:53:50 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70FCB3A69A9; Mon, 31 Jan 2011 09:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.226 X-Spam-Level: X-Spam-Status: No, score=-110.226 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31HQryoJ+70J; Mon, 31 Jan 2011 09:53:48 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 14F993A6844; Mon, 31 Jan 2011 09:53:46 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 31 Jan 2011 17:57:01 +0000 Received: from dhcp-10-61-100-10.cisco.com (dhcp-10-61-100-10.cisco.com [10.61.100.10]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p0VHv0of006773; Mon, 31 Jan 2011 17:57:00 GMT Message-ID: <4D46F7E1.8040601@cisco.com> Date: Mon, 31 Jan 2011 18:56:49 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Cullen Jennings Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> <4D46D1D3.10701@vpnc.org> <4D46E2FF.7010203@cisco.com> <768DE9F6-FC0B-49B0-8244-0D97CD7BD2DA@cisco.com> In-Reply-To: <768DE9F6-FC0B-49B0-8244-0D97CD7BD2DA@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IESG IESG , IETF discussion list , Paul Hoffman , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 17:53:50 -0000 On 1/31/11 6:51 PM, Cullen Jennings wrote: > So first, we already have a BCP that says more or less all protocols must implement a secure version but deployment is optional. This is a good BCP, and it comes from the right area to say that - security. It's probably impacts design work in working groups more than any other BCP. It has IETF consensus. The IESG holds protocols to this. But this isn't only about IETF process. You just asked about why the IETF is special and why 3GPP shouldn't be treated on equal footing. Well, then what about ITU, ISO, W3C, and Joe's Standards Body? > Now - I am at loss to see why forcing people to use one port will make it more likely to have secure protocols. This seems crazy. Please do enlighten me. The vast majority of the requests I see have 0 security built in until I ask the question. A few come back with a plan. Take away that lever and I don't even get to ask the question. > And on the topic, I'm still looking forward to an explanation of how the current CoAP design stomping all over the TLS code points would be an acceptable design. I missed a step there? CoAP? From touch@isi.edu Mon Jan 31 10:39:15 2011 Return-Path: X-Original-To: tsvwg@core3.amsl.com Delivered-To: tsvwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45F313A6B01; Mon, 31 Jan 2011 10:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.815 X-Spam-Level: X-Spam-Status: No, score=-101.815 tagged_above=-999 required=5 tests=[AWL=-0.612, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9B+Oj9YXroE; Mon, 31 Jan 2011 10:39:14 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 791933A6ABC; Mon, 31 Jan 2011 10:39:14 -0800 (PST) Received: from [192.168.1.91] (pool-71-105-81-169.lsanca.dsl-w.verizon.net [71.105.81.169]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p0VIfjQj000932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 31 Jan 2011 10:41:55 -0800 (PST) References: <20110118212603.5733.34489.idtracker@localhost> <4D421795.70505@isi.edu> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> <4D46EE80.8090906@isi.edu> <4D46F083.9090500@isi.edu> In-Reply-To: <4D46F083.9090500@isi.edu> Mime-Version: 1.0 (iPad Mail 8C148) Content-Type: text/plain; charset=us-ascii Message-Id: <86B08EA1-476E-487A-BDB3-655A60680254@isi.edu> Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (8C148) From: Joe Touch Subject: Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Date: Mon, 31 Jan 2011 10:42:03 -0800 To: Joe Touch X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tsvwg@ietf.org" , Paul Hoffman , IESG IESG , IETF discussion list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 18:39:15 -0000 Fwiw please see sec 8.1 of our doc which states which procedures of RFC 5226= are specified for each range, and already allows IESG approval as a path fo= r user ports.=20 Joe On Jan 31, 2011, at 9:25 AM, Joe Touch wrote: >=20 >=20 > On 1/31/2011 9:16 AM, Joe Touch wrote: >> Lars, >>=20 >> On 1/31/2011 7:06 AM, Lars Eggert wrote: >>> Hi, >>>=20 >>> On 2011-1-31, at 16:51, Paul Hoffman wrote: >>>> On 1/31/11 12:23 AM, Lars Eggert wrote: >>>>> On 2011-1-30, at 17:12, Paul Hoffman wrote: >>>>>> The above emphatic statements means that IANA can reject a request >>>>>> for an IETF-approved protocol that needs two ports without recourse. >>>>>=20 >>>>> I don't follow. Assignments through IETF-stream documents do not go >>>>> through expert review. >>>>=20 >>>> Then this should be made *much* clearer in the document. In fact, the >>>> document says: >>>>=20 >>>> A key element of the procedural streamlining specified in this >>>> document is to establish identical assignment procedures for all IETF >>>> transport protocols. >>>>=20 >>>> I assumed that "all" meant "all", not "all except those through >>>> IETF-stream documents"; others might have read it the same way I did. >>>=20 >>> The sentence you quote isn't related to the issue we're discussing. It >>> is intended to say "a goal is that the procedures to get ports and >>> service names are the same for UDP, TCP, DCCP and SCTP." (Maybe it >>> would be clearer by explicitly naming these protocols in the document.) >>>=20 >>> But I see the point you're raising. The document should somewhere say >>> that "Expert Review" is the procedure used for assignment requests >>> made directly to IANA, whereas for documents on the IETF Stream, "IETF >>> Consensus" is sufficient to make the assignment. In other words, no >>> expert review doesn't really need to happen for those, since IETF >>> Review and IESG Approval are at least equivalent. >>=20 >> RFC2434 already gives IANA these options. >=20 > As does RFC 5226 - its update (there is no substantive change between the t= wo in this regard, FWIW). >=20 >> Perhaps - at best - we should include a ref to that. >=20 > And 5226 is already clearly cited. >=20 > No further action should be required. >=20 > Joe >=20 >> However, this document is not focused at changing what RFC2434 says, and >> the above statement, IMO, does. >>=20 >> That's another can of worms, and should be reserved for a different >> document. >>=20 >> Joe