From acmorton@att.com Sat May 2 06:54:19 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 597723A68B2 for ; Sat, 2 May 2009 06:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.614 X-Spam-Level: X-Spam-Status: No, score=-105.614 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, 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 wKoK00R4jQQ6 for ; Sat, 2 May 2009 06:54:18 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 62FB63A689B for ; Sat, 2 May 2009 06:54:18 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-13.tower-120.messagelabs.com!1241272541!29131578!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.128.141] Received: (qmail 31076 invoked from network); 2 May 2009 13:55:42 -0000 Received: from sbcsmtp9.sbc.com (HELO flph161.enaf.ffdc.sbc.com) (144.160.128.141) by server-13.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2009 13:55:42 -0000 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n42Dtfj8023942 for ; Sat, 2 May 2009 06:55:41 -0700 Received: from klph001.kcdc.att.com (klph001.kcdc.att.com [135.188.3.11]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n42DtbWt023919 for ; Sat, 2 May 2009 06:55:38 -0700 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n42DtbT2031017 for ; Sat, 2 May 2009 08:55:37 -0500 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n42DtWsY030983 for ; Sat, 2 May 2009 08:55:33 -0500 Message-Id: <200905021355.n42DtWsY030983@klph001.kcdc.att.com> Received: from acmt.att.com (vpn-135-70-219-174.vpn.east.att.com[135.70.219.174](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20090502135527gw1000u6hce>; Sat, 2 May 2009 13:55:32 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 02 May 2009 09:55:22 -0400 To: Matthew J Zekauskas , "Hedayat, Kaynam" , roman.krzanowski@verizon.com, kyum@juniper.net, babiarz@nortel.com From: Al Morton In-Reply-To: <49C7C95E.204@internet2.edu> References: <49C7C95E.204@internet2.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: tsv-ads@tools.ietf.org, IETF IPPM WG Subject: Re: [ippm] Clearing RFC 5357 errata X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 13:54:19 -0000 Matt, I'm a bit late getting to this, but better late than never... Here's my take on the nine Errata by number, with short description. Al 1587 tech (Server is not at the Control-Client) o Approved - The erratum is appropriate under the criteria below and should be available to implementors or people deploying the RFC. 1589 tech (Plain text) o Approved - The erratum is appropriate under the criteria below and should be available to implementors or people deploying the RFC. 1590 tech (Seq numbers are within-Session) o Approved - The erratum is appropriate under the criteria below and should be available to implementors or people deploying the RFC. 1591 tech (Count (2**32-1) max) o Hold for Document Update - The erratum is not a necessary update to the RFC. However, any future update of the document might consider this erratum, and determine whether it is correct and merits including in the update. 1593 tech (IANA Registry size should be 256) This is the most important of all the Errata findings! o Approved - The erratum is appropriate under the criteria below and should be available to implementors or people deploying the RFC. 1594 tech (single*-*block HMAC) o Hold for Document Update - The erratum is not a necessary update to the RFC. However, any future update of the document might consider this erratum, and determine whether it is correct and merits including in the update. 1586 editorial (connection to TWAMP w.k.port) o HOLD 1588 editorial (missing "the") o HOLD 1592 editorial (delete # IANA comment line) o HOLD At 01:39 PM 3/23/2009, Matthew J Zekauskas wrote: >Hi, > >Henk and I have been asked to work on clearing out the RFC Editor Errata >queue for IPPM RFCs. There were a bunch submitted for RFC 5357. > >You can see them here: > > >What we need to do is have you (as authors) look at them, and decide if >you think they are > - in the correct catagory (technical or editorial) > - Verified (an interoperability issue that needs to change) > (we can suggest alternate wording or solution) > - Rejected (not applicable) > - Hold for document update (something that should be considered the >next time the document is updated, but isn't important enough to make a >statement about now). > >Guidelines for making these decisions are at > > >and more information on what the catagories and states represent are at > . > >Would you look and give us your opinions by close of business Friday, >April 24? > >Thanks, > >--Matt >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www.ietf.org/mailman/listinfo/ippm From acmorton@att.com Sat May 2 09:31:40 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EA8D28C125 for ; Sat, 2 May 2009 09:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.619 X-Spam-Level: X-Spam-Status: No, score=-105.619 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, 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 1PRNDcrCfmnT for ; Sat, 2 May 2009 09:31:39 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 6222528C102 for ; Sat, 2 May 2009 09:31:23 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-4.tower-129.messagelabs.com!1241281966!26095015!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 3393 invoked from network); 2 May 2009 16:32:47 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-4.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2009 16:32:47 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n42GWkmM010984 for ; Sat, 2 May 2009 12:32:46 -0400 Received: from alph001.aldc.att.com (alph001.aldc.att.com [135.53.7.26]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n42GWf1P010962 for ; Sat, 2 May 2009 12:32:42 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alph001.aldc.att.com (8.14.0/8.14.0) with ESMTP id n42GWfLO012472 for ; Sat, 2 May 2009 12:32:41 -0400 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alph001.aldc.att.com (8.14.0/8.14.0) with ESMTP id n42GWc5M012451 for ; Sat, 2 May 2009 12:32:38 -0400 Message-Id: <200905021632.n42GWc5M012451@alph001.aldc.att.com> Received: from acmt.att.com (vpn-135-70-219-174.vpn.east.att.com[135.70.219.174](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20090502163233gw1000u6hje>; Sat, 2 May 2009 16:32:33 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 02 May 2009 12:32:26 -0400 To: Matthew J Zekauskas , IETF IPPM WG From: Al Morton In-Reply-To: <49CC219B.3040107@internet2.edu> References: <49CC219B.3040107@internet2.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Matt Zekauskas Subject: Re: [ippm] Clearing errata 1528, RFC 2680, A One-way Packet Loss Metric for IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 16:31:40 -0000 Matt, late again, but you can consider this Errata 1528 verified, and I agree with your text on 397 and 398. Al At 08:45 PM 3/26/2009, Matthew J Zekauskas wrote: >...I recommend the Errata be 'Verified', and the correction can stand as-is. > > >----- > >RFC2680, "A One-way Packet Loss Metric for IPPM", September 1999 > >Source of RFC: Legacy > >Errata ID: 1528 > >Status: Reported >Type: Editorial > >Reported By: Wenxia Dong >Date Reported: 2008-09-24 > >Section 2.7 says: > >The first two sources are interrelated and could result in a test >packet with finite delay being reported as lost. Type-P-One-way- >Packet-Loss is 0 if the test packet does not arrive, or if it does >arrive and the difference between Src timestamp and Dst timestamp is >greater than the "reasonable period of time", or loss threshold. > >It should say: > >The first two sources are interrelated and could result in a test >packet with finite delay being reported as lost. Type-P-One-way- >Packet-Loss is 1 if the test packet does not arrive, or if it does >arrive and the difference between Src timestamp and Dst timestamp is >greater than the "reasonable period of time", or loss threshold. > >Notes: > >Type-P-One-way-Packet-Loss is 1 if the test packet does not arrive, >according to section 2.4 Definition in RFC2680. From acmorton@att.com Sat May 2 11:46:08 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18D6B3A67EA for ; Sat, 2 May 2009 11:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.624 X-Spam-Level: X-Spam-Status: No, score=-105.624 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, 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 Fq3OxZMdzmTe for ; Sat, 2 May 2009 11:46:07 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 6A8903A6B1D for ; Sat, 2 May 2009 11:45:56 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-2.tower-120.messagelabs.com!1241290040!23128587!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.128.141] Received: (qmail 23794 invoked from network); 2 May 2009 18:47:20 -0000 Received: from sbcsmtp9.sbc.com (HELO flph161.enaf.ffdc.sbc.com) (144.160.128.141) by server-2.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2009 18:47:20 -0000 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n42IlJtN024282 for ; Sat, 2 May 2009 11:47:19 -0700 Received: from klph001.kcdc.att.com (klph001.kcdc.att.com [135.188.3.11]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n42IlH85024264 for ; Sat, 2 May 2009 11:47:18 -0700 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n42IlH6R001430 for ; Sat, 2 May 2009 13:47:17 -0500 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n42IlC6b001410 for ; Sat, 2 May 2009 13:47:13 -0500 Message-Id: <200905021847.n42IlC6b001410@klph001.kcdc.att.com> Received: from acmt.att.com (vpn-135-70-219-174.vpn.east.att.com[135.70.219.174](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20090502184712gw1000u6hme>; Sat, 2 May 2009 18:47:12 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 02 May 2009 14:47:06 -0400 To: Lars Eggert , IETF IPPM WG From: Al Morton In-Reply-To: <62431212-93A8-44E3-91F3-0E943899EC4A@nokia.com> References: <62431212-93A8-44E3-91F3-0E943899EC4A@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [ippm] AD review: draft-ietf-ippm-more-twamp X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 18:46:08 -0000 Hi Lars, Thanks for your comments. The final wording might benefit from an exchange on this one in particular: At 03:58 PM 4/27/2009, Lars Eggert wrote: >...Section 4.1., paragraph 1: > > This section describes REQUIRED extensions to the behavior of the > > TWAMP Sender. > > Section 2 said that this entire draft specifies OPTIONAL > functionality. This section says that the following extensions are > REQUIRED. That's a bit of a mismatch. Either this entire document is > now required to implement TWAMP, or the extensions are OPTIONAL, but > implementations that chose to implement them need to do these. Please > make this more clear. This mode of operation is OPTIONAL of course. But, once the Server and Control-Client have agreed to use this mode, then the Session-Sender and the Session-Reflector MUST conform to the provisions of this mode (operate using the Unauthenticated packet format). What seems to be missing in RFC 2119 is a "CONDITIONALLY REQUIRED" term. So, here's a paragraph I suggest to add to section 4: This section describes OPTIONAL extensions. When the Server has identified the ability to support the mixed security mode, the Control-Client has selected the mixed security mode in its Set-Up-Response, and the Server responds with a zero Accept field in the Server-Start message, then these extensions are conditionally REQUIRED. It will be good to sort this out, because we'll need this wording in other TWAMP features. Al From lars.eggert@nokia.com Sun May 3 23:29:59 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CB933A6A0D for ; Sun, 3 May 2009 23:29:59 -0700 (PDT) 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 5kBmvR2BgbDJ for ; Sun, 3 May 2009 23:29:58 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 8D7DE3A67D1 for ; Sun, 3 May 2009 23:29:56 -0700 (PDT) Received: from [10.180.41.11] ([192.100.124.156]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n446VEbV029434 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 May 2009 09:31:14 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <2387E579-AB08-4494-83EE-D8E8CD36B658@nokia.com> From: Lars Eggert To: Al Morton In-Reply-To: <200905021847.n42IlCta001409@klph001.kcdc.att.com> Content-Type: multipart/signed; boundary=Apple-Mail-11--1029019400; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 4 May 2009 09:31:09 +0300 References: <62431212-93A8-44E3-91F3-0E943899EC4A@nokia.com> <200905021847.n42IlCta001409@klph001.kcdc.att.com> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [212.213.221.39]); Mon, 04 May 2009 09:31:15 +0300 (EEST) Cc: IETF IPPM WG Subject: Re: [ippm] AD review: draft-ietf-ippm-more-twamp X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 06:29:59 -0000 --Apple-Mail-11--1029019400 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, the explanation below make sense - could you add a few words along these lines to the introduction? Thanks, Lars On 2009-5-2, at 21:47, Al Morton wrote: > Hi Lars, > > Thanks for your comments. > > The final wording might benefit from > an exchange on this one in particular: > > At 03:58 PM 4/27/2009, Lars Eggert wrote: >> ...Section 4.1., paragraph 1: >>> This section describes REQUIRED extensions to the behavior of the >>> TWAMP Sender. >> >> Section 2 said that this entire draft specifies OPTIONAL >> functionality. This section says that the following extensions are >> REQUIRED. That's a bit of a mismatch. Either this entire document is >> now required to implement TWAMP, or the extensions are OPTIONAL, but >> implementations that chose to implement them need to do these. >> Please >> make this more clear. > > This mode of operation is OPTIONAL of course. But, once the > Server and Control-Client have agreed to use this mode, > then the Session-Sender and the Session-Reflector MUST > conform to the provisions of this mode (operate using the > Unauthenticated packet format). What seems to be missing > in RFC 2119 is a "CONDITIONALLY REQUIRED" term. > > So, here's a paragraph I suggest to add to section 4: > > This section describes OPTIONAL extensions. When the Server > has identified the ability to support the mixed security mode, > the Control-Client has selected the mixed security mode in its Set- > Up-Response, > and the Server responds with a zero Accept field in the Server-Start > message, > then these extensions are conditionally REQUIRED. > > It will be good to sort this out, because we'll need this > wording in other TWAMP features. > > Al > > > > --Apple-Mail-11--1029019400 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA1MDQwNjMxMDlaMCMGCSqGSIb3DQEJBDEWBBR902zkPZCfflf2 ufqiOBsh7xboTDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAeYCBed1SvTR6Hs4EOKIHxjfCjiHoHJlrISwdeMdVkqIVG0Gak9Ux 0Rof8Iohn7jkYxSW03CW/B51G3rLlg6gFy8sPSiTtepfjAYtxrFCY/uuRqFRPCbzu+3/Gpbe70pf fBNNQtNipalqSc5Wrr8UwJffcJ4ZS0iS26f2hYSALXuLNfQxVuhKyNDXXyOL71IbY0tjPmNx6xjv tSbFQ0LLaC89iJbwTzhiLnX9EICqL4YJxbPZt26z0c595zmEWftwton9Kov6AUVwL4A5XgmggH1c tgPQX2l3H9yLvPVPz2d0ep0h0TaCwYIiACcqay4yo7WX+x5eACQcujzM92kIywAAAAAAAA== --Apple-Mail-11--1029019400-- From root@core3.amsl.com Tue May 5 06:45:01 2009 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 29EEB3A6887; Tue, 5 May 2009 06:45:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090505134501.29EEB3A6887@core3.amsl.com> Date: Tue, 5 May 2009 06:45:01 -0700 (PDT) Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-more-twamp-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 13:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : More Features for the Two-Way Active Measurement Protocol - TWAMP Author(s) : A. Morton, K. Hedayat Filename : draft-ietf-ippm-more-twamp-01.txt Pages : 10 Date : 2009-05-05 This memo describes a simple extension to TWAMP - the Two-Way Active Measurement Protocol. The extension adds the option to use different security modes in the TWAMP-Control and TWAMP-Test protocols simultaneously. The memo also requests that IANA establish a registry for additional new features, called the TWAMP-Modes registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-more-twamp-01.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-ippm-more-twamp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-05063020.I-D@ietf.org> --NextPart-- From acmorton@att.com Tue May 5 06:54:36 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64F993A6EAB for ; Tue, 5 May 2009 06:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.642 X-Spam-Level: X-Spam-Status: No, score=-105.642 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, 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 dPnpJlIG6wJF for ; Tue, 5 May 2009 06:54:35 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 8861028C171 for ; Tue, 5 May 2009 06:54:35 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-14.tower-120.messagelabs.com!1241531761!34155804!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.128.141] Received: (qmail 14445 invoked from network); 5 May 2009 13:56:01 -0000 Received: from sbcsmtp9.sbc.com (HELO flph161.enaf.ffdc.sbc.com) (144.160.128.141) by server-14.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 May 2009 13:56:01 -0000 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n45Du0eT007043 for ; Tue, 5 May 2009 06:56:01 -0700 Received: from klph001.kcdc.att.com (klph001.kcdc.att.com [135.188.3.11]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n45DtuoO006958 for ; Tue, 5 May 2009 06:55:57 -0700 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n45DttF3004902 for ; Tue, 5 May 2009 08:55:56 -0500 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n45DtpWO004789 for ; Tue, 5 May 2009 08:55:51 -0500 Message-Id: <200905051355.n45DtpWO004789@klph001.kcdc.att.com> Received: from acmt.att.com (martym.mt.att.com[135.16.251.71](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20090505135551gw1000u6s4e>; Tue, 5 May 2009 13:55:51 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 05 May 2009 09:55:51 -0400 To: Lars Eggert From: Al Morton In-Reply-To: <2387E579-AB08-4494-83EE-D8E8CD36B658@nokia.com> References: <62431212-93A8-44E3-91F3-0E943899EC4A@nokia.com> <200905021847.n42IlCta001409@klph001.kcdc.att.com> <2387E579-AB08-4494-83EE-D8E8CD36B658@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: IETF IPPM WG Subject: Re: [ippm] AD review: draft-ietf-ippm-more-twamp X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 13:54:36 -0000 At 02:31 AM 5/4/2009, Lars Eggert wrote: >the explanation below make sense - could you add a few words along >these lines to the introduction? > >Thanks, >Lars I've addressed all of Lars' comments, and added a few additional clarifications (to address possible Alfred Hoenes-class Errata before we get to that stage of development). http://www.ietf.org/internet-drafts/draft-ietf-ippm-more-twamp-01.txt This should move us to the next step. thanks and regards, Al >On 2009-5-2, at 21:47, Al Morton wrote: > >>Hi Lars, >> >>Thanks for your comments. >> >>The final wording might benefit from >>an exchange on this one in particular: >> >>At 03:58 PM 4/27/2009, Lars Eggert wrote: >>>...Section 4.1., paragraph 1: >>>> This section describes REQUIRED extensions to the behavior of the >>>> TWAMP Sender. >>> >>> Section 2 said that this entire draft specifies OPTIONAL >>> functionality. This section says that the following extensions are >>> REQUIRED. That's a bit of a mismatch. Either this entire document is >>> now required to implement TWAMP, or the extensions are OPTIONAL, but >>> implementations that chose to implement them need to do these. >>>Please >>> make this more clear. >> >>This mode of operation is OPTIONAL of course. But, once the >>Server and Control-Client have agreed to use this mode, >>then the Session-Sender and the Session-Reflector MUST >>conform to the provisions of this mode (operate using the >>Unauthenticated packet format). What seems to be missing >>in RFC 2119 is a "CONDITIONALLY REQUIRED" term. >> >>So, here's a paragraph I suggest to add to section 4: >> >>This section describes OPTIONAL extensions. When the Server >>has identified the ability to support the mixed security mode, >>the Control-Client has selected the mixed security mode in its Set- >>Up-Response, >>and the Server responds with a zero Accept field in the Server-Start >>message, >>then these extensions are conditionally REQUIRED. >> >>It will be good to sort this out, because we'll need this >>wording in other TWAMP features. >> >>Al >> >> >> > > > From wwwrun@core3.amsl.com Tue May 5 09:29:11 2009 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 2ADB13A6F81; Tue, 5 May 2009 09:29:11 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090505162911.2ADB13A6F81@core3.amsl.com> Date: Tue, 5 May 2009 09:29:11 -0700 (PDT) Cc: ippm@ietf.org Subject: [ippm] Last Call: draft-ietf-ippm-more-twamp (More Features for the Two-Way Active Measurement Protocol - TWAMP) to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 16:29:11 -0000 The IESG has received a request from the IP Performance Metrics WG (ippm) to consider the following document: - 'More Features for the Two-Way Active Measurement Protocol - TWAMP ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-05-19. 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://www.ietf.org/internet-drafts/draft-ietf-ippm-more-twamp-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17788&rfc_flag=0 From Maha.Abdallah@lip6.fr Tue May 5 11:48:44 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F17D3A6CAD for ; Tue, 5 May 2009 11:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=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 IzO9FwJIbj6H for ; Tue, 5 May 2009 11:48:43 -0700 (PDT) Received: from osiris.lip6.fr (osiris.lip6.fr [132.227.60.30]) by core3.amsl.com (Postfix) with ESMTP id 09F173A6A50 for ; Tue, 5 May 2009 11:48:42 -0700 (PDT) Received: from poleia.lip6.fr (mailtwo.desir.lip6.fr [132.227.205.24]) by osiris.lip6.fr (8.13.5.20060614/lip6) with ESMTP id n45Invew012594 for ; Tue, 5 May 2009 20:50:02 +0200 (CEST) X-pt: osiris.lip6.fr Received: from [198.18.119.125] (unknown [201.229.38.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by poleia.lip6.fr (Postfix) with ESMTPSA id 7284C3FDBED for ; Tue, 5 May 2009 20:49:57 +0200 (CEST) Message-ID: <4A008A47.9030806@lip6.fr> Date: Tue, 05 May 2009 20:49:43 +0200 From: Maha Abdallah User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: ippm@ietf.org Content-Type: multipart/mixed; boundary="------------050303090206010207050602" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (osiris.lip6.fr [132.227.60.30]); Tue, 05 May 2009 20:50:02 +0200 (CEST) X-Scanned-By: MIMEDefang 2.63 on 132.227.60.30 Subject: [ippm] NetGames 2009 CFP X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 19:03:15 -0000 This is a multi-part message in MIME format. --------------050303090206010207050602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit -- Maha Abdallah LIP6 Laboratory University of Paris VI 104, avenue du Président Kennedy 75016 Paris, France Tel: +33-1-44.27.87.93 Fax: +33-1-44.27.70.00 Web: http://www-poleia.lip6.fr/~abdallah/ --------------050303090206010207050602 Content-Type: text/plain; name="NetGames_CFP_Final.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="NetGames_CFP_Final.txt" +++++++++++++++++++++[ Netgames 2009 Call for Papers ]+++++++++++++++++++++++ The 8th International Workshop on Network and Systems Support for Games November 23 and 24, 2009 Paris, France http://netgames2009.lip6.fr/ In co-operation with ACM SIGCOMM/SIGMM (Pending) Technically sponsored by IEEE Communications Society (Pending) OVERVIEW ======== The 8th Annual Workshop on Network and Systems Support for Games (NetGames 2009) will be held in Paris, France, on November 23-24, 2009. The NetGames workshop brings together researchers and developers from academia and industry to present new research in understanding networked games of today and in enabling the next generation of future networked games. Submissions are sought in any area related to networked games. In particular, topics of interest include (but are not limited to): - Network measurement and traffic modeling - System benchmarking, performance evaluation, and provisioning - Latency issues and lag compensation techniques - Operating system enhancements, service platforms, and middleware - Impact of online game growth on network infrastructure - P2P & Scalable system architectures - Network protocol design - Mobile and resource-constrained systems - Augmented physical systems - Networks of sensors and actuators - Input devices, haptics and accessibility - User and usability studies, group dynamics - Quality of service and content adaptation - User-generated content management - Content authoring and sharing - Artificial intelligence - Security, authentication, accounting and digital rights management - Cheat detection and prevention - Messaging and conferencing in games - Results that reproduce (or refute) previous published results SUBMISSIONS =========== NetGames 2009 welcomes submissions of full papers, as well as extended abstracts reporting work-in-progress. Full papers must be no longer than 6 pages (inclusive of all figures, references and appendices). Extended abstracts must be no longer than 2 pages, and will be presented as Posters in an interactive setting. In addition to papers, technical demonstrations showing original research prototypes are also solicited. Demonstration papers must be no more than 2 pages in length, and should provide a short description of the system and the features that are to be demonstrated. Authors must submit their papers in PDF and use single-spaced, double column ACM conference format. Detailed paper submission guidelines are available at http://netgames2009.lip6.fr/SUBMIT.html. Reviews will be single-blind, authors must include their names and affiliations on the first page. Papers will be judged on their relevance, technical content and correctness, and the clarity of presentation of the research. Papers should not be under review at another venue nor previously published elsewhere. All accepted papers of NetGames 2009 will be archived in the ACM Digital Library (pending ACM in-cooperation approval) and published in the workshop proceedings. Submission of a paper for review will be considered your agreement that at least one author will register and attend if your paper is accepted. Authors of selected, top quality papers from NetGames 2009 will be invited to submit an extended version of their papers to a special issue of the International Journal of Advanced Media and Communication (IJAMC). COMMITTEE ========= WORKSHOP CHAIR: Maha Abdallah (University of Paris 6, France) PROGRAM COMMITTEE (additional members to be confirmed): Maha Abdallah (University of Paris 6, France) Grenville Armitage (Swinburne University of Technology, Australia) Bharat Bhargava (Purdue University, USA) Khaled Boussetta (University of Paris 13, France) Mark Claypool (Worcester Polytechnic Institute, USA) Christophe Diot (Thomson, France) Wu-chang Feng (Portland State University, USA) Wu-Chi Feng (Portland State University, USA) Carsten Griwodz (University of Oslo, Norway) Pĺl Halvorsen (University of Oslo, Norway) Tristan Henderson (University of St Andrews,UK) Jehn-Ruey Jiang (National Central University, Taiwan) Yoshihiro Kawahara (University of Tokyo, Japan) JongWon Kim (GIST, Korea) Ben Leong (National University of Singapore) John Miller (Microsoft Research, UK) Madjid Merabti (Liverpool John Moores University) Wei Tsang Ooi (National University of Singapore) Marius Preda (Institut TELECOM, France) Farzad Safaei (University of Wollongong, Australia) Shervin Shirmohammadi (University of Ottawa, Canada) Joel Wein (Polytechnic Institute of NYU, USA) Lars Wolf (TU Braunschweig, Germany) Roger Zimmermann (National University of Singapore) Important DATES =============== Paper registration: July 24, 2009 Paper submission: July 31, 2009 Author notification: September 27, 2009 Camera ready manuscript: October 25, 2009 Workshop Dates: November 23-24, 2009 +++++++++++++++++++++[ Netgames 2009 Call for Papers ]+++++++++++++++++++++++ --------------050303090206010207050602-- From lars.eggert@nokia.com Thu May 14 03:39:32 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 221A63A6904 for ; Thu, 14 May 2009 03:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.754 X-Spam-Level: X-Spam-Status: No, score=-2.754 tagged_above=-999 required=5 tests=[AWL=-0.155, 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 J5VlXfozbU0b for ; Thu, 14 May 2009 03:39:31 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id B92863A688C for ; Thu, 14 May 2009 03:39:30 -0700 (PDT) Received: from [192.168.0.199] (wlan.fit.nokia.com [195.148.124.254]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n4EAemsi017261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 May 2009 13:40:49 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: Al Morton In-Reply-To: <200905021355.n42DtWYA030982@klph001.kcdc.att.com> Content-Type: multipart/signed; boundary=Apple-Mail-22--150045314; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 14 May 2009 13:40:43 +0300 References: <49C7C95E.204@internet2.edu> <200905021355.n42DtWYA030982@klph001.kcdc.att.com> X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Thu, 14 May 2009 13:40:49 +0300 (EEST) Cc: IETF IPPM WG , "tsv-ads@tools.ietf.org" , "babiarz@nortel.com" , "roman.krzanowski@verizon.com" , "kyum@juniper.net" , Matthew J Zekauskas Subject: Re: [ippm] Clearing RFC 5357 errata X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 10:39:32 -0000 --Apple-Mail-22--150045314 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Thanks - I processed all of these. Lars On 2009-5-2, at 16:55, Al Morton wrote: > Matt, > > I'm a bit late getting to this, but better late than never... > > Here's my take on the nine Errata by number, with short description. > > Al > > > 1587 tech (Server is not at the Control-Client) > o Approved - The erratum is appropriate under the criteria below and > should be available to implementors or people deploying the RFC. > > 1589 tech (Plain text) > o Approved - The erratum is appropriate under the criteria below and > should be available to implementors or people deploying the RFC. > > 1590 tech (Seq numbers are within-Session) > o Approved - The erratum is appropriate under the criteria below and > should be available to implementors or people deploying the RFC. > > 1591 tech (Count (2**32-1) max) > o Hold for Document Update - The erratum is not a necessary update > to the RFC. However, any future update of the document might > consider this erratum, and determine whether it is correct and > merits including in the update. > > 1593 tech (IANA Registry size should be 256) > This is the most important of all the Errata findings! > o Approved - The erratum is appropriate under the criteria below and > should be available to implementors or people deploying the RFC. > > 1594 tech (single*-*block HMAC) > o Hold for Document Update - The erratum is not a necessary update > to the RFC. However, any future update of the document might > consider this erratum, and determine whether it is correct and > merits including in the update. > > 1586 editorial (connection to TWAMP w.k.port) > o HOLD > > 1588 editorial (missing "the") > o HOLD > > 1592 editorial (delete # IANA comment line) > o HOLD > > At 01:39 PM 3/23/2009, Matthew J Zekauskas wrote: >> Hi, >> >> Henk and I have been asked to work on clearing out the RFC Editor >> Errata >> queue for IPPM RFCs. There were a bunch submitted for RFC 5357. >> >> You can see them here: >> >> >> What we need to do is have you (as authors) look at them, and >> decide if >> you think they are >> - in the correct catagory (technical or editorial) >> - Verified (an interoperability issue that needs to change) >> (we can suggest alternate wording or solution) >> - Rejected (not applicable) >> - Hold for document update (something that should be considered the >> next time the document is updated, but isn't important enough to >> make a >> statement about now). >> >> Guidelines for making these decisions are at >> >> >> and more information on what the catagories and states represent >> are at >> . >> >> Would you look and give us your opinions by close of business Friday, >> April 24? >> >> Thanks, >> >> --Matt >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm > --Apple-Mail-22--150045314 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA1MTQxMDQwNDNaMCMGCSqGSIb3DQEJBDEWBBSikE3WU98S1eJV d5SzmVMyAzoFdzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAZUt4yhwrut1aoVCXs/kTAg31/UuyyrmnqpRkann9ZlT4LA8yTzy+ Ei9AguNH8n5rmsuqBMDLnBcwOdrX4tRCaktn2E2EpouKeyeo1d8+aUhb9MeQHlOyVS9yrImXleVZ T8MNaKKbGY7GowdVjJV1FDEPuioZGztj//QLi8X4xSyCQOJ7cOoOy1ssgLEkV9HRIC8l8lOUYUJY kA6jGeU5g3WpxdrPZjkVUOhsztEEyLbXEQM/CqBLrdLS9BYWZ4Eome9fD8iemMkhNSphAm56E58s XlJEtTubDpp6mBiIAqCA+8y1HIuUCqydbFvuofjbTWQr/XI3IX0Za5mlrI3dGAAAAAAAAA== --Apple-Mail-22--150045314-- From dromasca@avaya.com Sun May 17 02:23:05 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 190B33A6C67 for ; Sun, 17 May 2009 02:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 BjeUaBpDQPfr for ; Sun, 17 May 2009 02:22:59 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 32DD53A6C5D for ; Sun, 17 May 2009 02:22:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,207,1241409600"; d="scan'208";a="146027699" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 17 May 2009 05:24:32 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 May 2009 05:24:30 -0400 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 Date: Sun, 17 May 2009 11:24:25 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: Last Call: draft-ietf-ippm-more-twamp (More Features for the Two-Way Active Measurement Protocol - TWAMP) to Proposed Standard Thread-Index: AcnWytvmXQ4Df2nsQ3y9j7/1/UIWvQABWF4w From: "Romascanu, Dan (Dan)" To: , Cc: Joel Jaeggli , ippm@ietf.org Subject: Re: [ippm] Last Call: draft-ietf-ippm-more-twamp (More Features for the Two-Way Active Measurement Protocol - TWAMP) to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 09:23:05 -0000 Please find below the OPS-DIR review for draft-ietf-ippm-more-twamp performed by Joel Jaeggli.=20 Please consider these comments together with the other IETF LC comments. Regards, Dan -----Original Message----- From: ops-dir-bounces@ietf.org [mailto:ops-dir-bounces@ietf.org] On Behalf Of Joel Jaeggli Sent: Sunday, May 17, 2009 11:37 AM To: ops-dir@ietf.org Subject: [OPS-DIR] Review of draft-ietf-ippm-more-twamp-01 review for opsdir of: http://tools.ietf.org/html/draft-ietf-ippm-more-twamp-01 section 4 - "This section describes OPTIONAL extensions. When the Server has identified the ability to support the mixed security mode, the Control-Client has selected the mixed security mode in its Set-Up- Response, and the Server responds with a zero Accept field in the Server-Start message, then these extensions are conditionally REQUIRED." When I read the introduction to section 4 the following statement, it sent me scrambling for the other conditions that would make the above statement required. It should be sufficient to say: When the Server has identified the ability to support the mixed =09 security mode, the Control-Client has selected the mixed security mode in its Set-Up-Response, and the Server responds with a zero Accept field in the Server-Start message, these extensions are REQUIRED. regarding 6.1 and 6.2 registry specification and management, 6.1 states: "Thus, this registry can contain a total of 32 possible bit positions and corresponding values." Certainly while there are 32 bits in the field, each has two states (e.g. 64) and the sum of the possible positions is significantly greater than 32 e.g. 2^32 6.2 states: For the TWAMP-Modes registry, we expect that new features will be assigned using monotonically increasing bit positions and in the range [0-31] and the corresponding values, unless there is a good reason to do otherwise. at some future date values in the registry for some bit positions might be encoded in some more complex fashion. From acmorton@att.com Sun May 17 10:04:41 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BB993A6A99 for ; Sun, 17 May 2009 10:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.641 X-Spam-Level: X-Spam-Status: No, score=-105.641 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, 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 PLPwxF1HuxAN for ; Sun, 17 May 2009 10:04:35 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 9D1A93A6C0F for ; Sun, 17 May 2009 10:04:35 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-9.tower-120.messagelabs.com!1242579969!47476956!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.128.141] Received: (qmail 343 invoked from network); 17 May 2009 17:06:10 -0000 Received: from sbcsmtp9.sbc.com (HELO flph161.enaf.ffdc.sbc.com) (144.160.128.141) by server-9.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 May 2009 17:06:10 -0000 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n4HH69rY011067 for ; Sun, 17 May 2009 10:06:09 -0700 Received: from klph001.kcdc.att.com (klph001.kcdc.att.com [135.188.3.11]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n4HH64oA011049 for ; Sun, 17 May 2009 10:06:05 -0700 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n4HH64vd016201 for ; Sun, 17 May 2009 12:06:04 -0500 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n4HH5tCV016151 for ; Sun, 17 May 2009 12:05:56 -0500 Message-Id: <200905171705.n4HH5tCV016151@klph001.kcdc.att.com> Received: from acmt.att.com (vpn-135-70-228-158.vpn.east.att.com[135.70.228.158](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20090517170550gw1000u62ke>; Sun, 17 May 2009 17:05:51 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 17 May 2009 13:05:44 -0400 To: Joel Jaeggli , "Romascanu, Dan (Dan)" , From: Al Morton In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: amanda.baber@icann.org, ippm@ietf.org Subject: Re: [ippm] Last Call: draft-ietf-ippm-more-twamp (More Features for the Two-Way Active Measurement Protocol - TWAMP) to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 17:04:41 -0000 Joel, thanks for your Sunday-morning comments, please see proposed resolutions in-line. Al At 05:24 AM 5/17/2009, Romascanu, Dan (Dan) wrote: >Please find below the OPS-DIR review for draft-ietf-ippm-more-twamp >performed by Joel Jaeggli. > >Please consider these comments together with the other IETF LC comments. >... >From: ops-dir-bounces@ietf.org [mailto:ops-dir-bounces@ietf.org] On >Behalf Of Joel Jaeggli >Sent: Sunday, May 17, 2009 11:37 AM > >review for opsdir of: > >http://tools.ietf.org/html/draft-ietf-ippm-more-twamp-01 > >section 4 - > > "This section describes OPTIONAL extensions. When the Server has > identified the ability to support the mixed security mode, the > Control-Client has selected the mixed security mode in its Set-Up- > Response, and the Server responds with a zero Accept field in the > Server-Start message, then these extensions are conditionally > REQUIRED." > >When I read the introduction to section 4 the following statement, it >sent me scrambling for the other conditions that would make the above >statement required. > >It should be sufficient to say: > > When the Server has identified the ability to support the mixed > security mode, the Control-Client has selected the mixed security > mode in its Set-Up-Response, and the Server responds with a zero > Accept field in the Server-Start message, these extensions are > REQUIRED. When the Server has identified the ability to support the mixed security mode, the Control-Client has selected the mixed security mode in its Set-Up-Response, and the Server responds with a zero Accept field in the Server-Start message, then these extensions are conditionally REQUIRED. ^^^^ ^^^^^^^^^^^^^ So, we would delete the first sentence and the words marked in the paragraph above. This tightens-up some text that we recently added to the draft. We would be depending on the OPTIONAL designation of this feature in section 2 (Scope) to cover the entire memo. Your revisions work for me, does anyone else see a problem with Joel's paragraph above? -------------------------------------------------------------------- >regarding 6.1 and 6.2 registry specification and management, 6.1 states: > "Thus, this registry can contain a total of 32 possible bit > positions and corresponding values." > >Certainly while there are 32 bits in the field, each has two states >(e.g. 64) and the sum of the possible positions is significantly greater >than 32 e.g. 2^32 TWAMP has inherited a partial set of bit position assignments, and this memo assigns what is likely to be that "last" mutually exclusive Mode/bit position (as a command from the Control-Client). But Future Modes/bit positions will designate features that WILL be used in combination with one of the four Security Modes. And, if we start to run out of bit positions, the likely strategy would be to use an octet or more in combinations. >6.2 states: > > For the TWAMP-Modes registry, we expect that new features will be > assigned using monotonically increasing bit positions and in the > range [0-31] and the corresponding values, unless there is a good > reason to do otherwise. > >at some future date values in the registry for some bit positions might >be encoded in some more complex fashion. Right. So let's allow that from the start. 6.1 OLD ... Modes are indicated by setting bits in the 32-bit Modes Field. Thus, this registry can contain a total of 32 possible bit positions and corresponding values. 6.1 NEW ... Modes are currently indicated by setting single bits in the 32-bit Modes Field. However, more complex encoding may be used in the future. Thus, this registry can contain a total of 2^32 possible assignments. --------------------------------- (the revision below also addresses Amanda Barber's LC-comment, representing IANA) 6.2 OLD Because the TWAMP-Modes registry can contain only thirty-two values, and because TWAMP is an IETF protocol, this registry must be updated only by "IETF Consensus" as specified in RFC5226 (an RFC documenting registry use that is approved by the IESG). For the TWAMP-Modes registry, we expect that new features will be assigned using monotonically increasing bit positions and in the range [0-31] and the corresponding values, unless there is a good reason to do otherwise. 6.2 NEW Because the TWAMP-Modes registry can contain a maximum of 2^32 values, and because TWAMP is an IETF protocol, this registry must be updated only by "IETF Review" as specified in RFC5226 (an RFC documenting registry use that is approved by the IESG). For the TWAMP-Modes registry, we expect that new features will be assigned using monotonically increasing single bit positions and in the range [0-31], unless there is a good reason to do otherwise (more complex encoding than single bit positions may be used in the future, to access the 2^32 value space). From joelja@bogus.com Sun May 17 10:31:41 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 128963A68F4 for ; Sun, 17 May 2009 10:31:41 -0700 (PDT) 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 vSlcxWlpcFl8 for ; Sun, 17 May 2009 10:31:40 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 9420A3A68C1 for ; Sun, 17 May 2009 10:31:39 -0700 (PDT) Received: from [192.168.1.233] ([84.205.97.124]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n4HHV9bp088015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 17 May 2009 17:31:15 GMT (envelope-from joelja@bogus.com) Message-ID: <4A1049DC.3070002@bogus.com> Date: Sun, 17 May 2009 10:31:08 -0700 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Al Morton References: <200905171705.n4HH5t4G016149@klph001.kcdc.att.com> In-Reply-To: <200905171705.n4HH5t4G016149@klph001.kcdc.att.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/9365/Sat May 16 12:41:29 2009 on nagasaki.bogus.com X-Virus-Status: Clean X-Mailman-Approved-At: Sun, 17 May 2009 11:17:01 -0700 Cc: amanda.baber@icann.org, "Romascanu, Dan \(Dan\)" , khedayat@exfo.com, ippm@ietf.org Subject: Re: [ippm] Last Call: draft-ietf-ippm-more-twamp (More Features for the Two-Way Active Measurement Protocol - TWAMP) to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 17:31:41 -0000 Your proposed changes capture my observations. joel Al Morton wrote: > Joel, > thanks for your Sunday-morning comments, > please see proposed resolutions in-line. > Al > > At 05:24 AM 5/17/2009, Romascanu, Dan (Dan) wrote: >> Please find below the OPS-DIR review for draft-ietf-ippm-more-twamp >> performed by Joel Jaeggli. >> >> Please consider these comments together with the other IETF LC comments. >> ... >> From: ops-dir-bounces@ietf.org [mailto:ops-dir-bounces@ietf.org] On >> Behalf Of Joel Jaeggli >> Sent: Sunday, May 17, 2009 11:37 AM >> >> review for opsdir of: >> >> http://tools.ietf.org/html/draft-ietf-ippm-more-twamp-01 >> >> section 4 - >> >> "This section describes OPTIONAL extensions. When the Server has >> identified the ability to support the mixed security mode, the >> Control-Client has selected the mixed security mode in its Set-Up- >> Response, and the Server responds with a zero Accept field in the >> Server-Start message, then these extensions are conditionally >> REQUIRED." >> >> When I read the introduction to section 4 the following statement, it >> sent me scrambling for the other conditions that would make the above >> statement required. >> >> It should be sufficient to say: >> >> When the Server has identified the ability to support the mixed >> security mode, the Control-Client has selected the mixed security >> mode in its Set-Up-Response, and the Server responds with a zero >> Accept field in the Server-Start message, these extensions are >> REQUIRED. > > When the Server has identified the ability to support the mixed > security mode, the Control-Client has selected the mixed security > mode in its Set-Up-Response, and the Server responds with a zero > Accept field in the Server-Start message, then these extensions are > conditionally REQUIRED. ^^^^ > ^^^^^^^^^^^^^ > So, we would delete the first sentence and the words marked in the > paragraph above. > > This tightens-up some text that we recently added to the draft. > We would be depending on the OPTIONAL designation of this > feature in section 2 (Scope) to cover the entire memo. > > Your revisions work for me, does anyone else see a problem > with Joel's paragraph above? > > -------------------------------------------------------------------- > >> regarding 6.1 and 6.2 registry specification and management, 6.1 states: >> "Thus, this registry can contain a total of 32 possible bit >> positions and corresponding values." >> >> Certainly while there are 32 bits in the field, each has two states >> (e.g. 64) and the sum of the possible positions is significantly greater >> than 32 e.g. 2^32 > > TWAMP has inherited a partial set of bit position assignments, > and this memo assigns what is likely to be that "last" mutually > exclusive Mode/bit position (as a command from the Control-Client). > > But Future Modes/bit positions will designate features that > WILL be used in combination with one of the four Security Modes. > And, if we start to run out of bit positions, the likely strategy > would be to use an octet or more in combinations. > > >> 6.2 states: >> >> For the TWAMP-Modes registry, we expect that new features will be >> assigned using monotonically increasing bit positions and in the >> range [0-31] and the corresponding values, unless there is a good >> reason to do otherwise. >> >> at some future date values in the registry for some bit positions might >> be encoded in some more complex fashion. > > Right. So let's allow that from the start. > > 6.1 OLD > ... Modes are indicated by setting bits in the 32-bit Modes Field. > Thus, this registry can contain a total of 32 possible bit > positions and corresponding values. > > 6.1 NEW > ... Modes are currently indicated by setting single bits in the > 32-bit Modes Field. However, more complex encoding may be used in the > future. Thus, this registry can contain a total of 2^32 possible > assignments. > > --------------------------------- > (the revision below also addresses Amanda Barber's LC-comment, > representing IANA) > > 6.2 OLD > > Because the TWAMP-Modes registry can contain only thirty-two values, and > because TWAMP is an IETF protocol, this registry must be updated only by > "IETF Consensus" as specified in RFC5226 (an RFC documenting registry > use that is approved by the IESG). For the TWAMP-Modes registry, we > expect that new features will be assigned using monotonically increasing > bit positions and in the range [0-31] and the corresponding values, > unless there is a good reason to do otherwise. > > 6.2 NEW > > Because the TWAMP-Modes registry can contain a maximum of 2^32 values, > and because TWAMP is an IETF protocol, this registry must be updated > only by "IETF Review" as specified in RFC5226 (an RFC documenting > registry use that is approved by the IESG). For the TWAMP-Modes > registry, we expect that new features will be assigned using > monotonically increasing single bit positions and in the range [0-31], > unless there is a good reason to do otherwise > (more complex encoding than single bit positions may be used in the > future, to access the 2^32 value space). > From root@core3.amsl.com Wed May 20 06:00:02 2009 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 008A23A6CC1; Wed, 20 May 2009 06:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090520130002.008A23A6CC1@core3.amsl.com> Date: Wed, 20 May 2009 06:00:01 -0700 (PDT) Cc: ippm@ietf.org Subject: [ippm] I-D Action:draft-ietf-ippm-more-twamp-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 13:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : More Features for the Two-Way Active Measurement Protocol - TWAMP Author(s) : A. Morton, K. Hedayat Filename : draft-ietf-ippm-more-twamp-02.txt Pages : 10 Date : 2009-05-20 This memo describes a simple extension to TWAMP - the Two-Way Active Measurement Protocol. The extension adds the option to use different security modes in the TWAMP-Control and TWAMP-Test protocols simultaneously. The memo also requests that IANA establish a registry for additional new features, called the TWAMP-Modes registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-more-twamp-02.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-ippm-more-twamp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-20055558.I-D@ietf.org> --NextPart-- From acmorton@att.com Wed May 20 06:02:44 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 306523A6CBF for ; Wed, 20 May 2009 06:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.673 X-Spam-Level: X-Spam-Status: No, score=-105.673 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, 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 fl9HYEGkL4zj for ; Wed, 20 May 2009 06:02:43 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 82CE63A6CEF for ; Wed, 20 May 2009 06:00:44 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-11.tower-129.messagelabs.com!1242824541!4934526!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.128.141] Received: (qmail 1314 invoked from network); 20 May 2009 13:02:21 -0000 Received: from sbcsmtp9.sbc.com (HELO flph161.enaf.ffdc.sbc.com) (144.160.128.141) by server-11.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 May 2009 13:02:21 -0000 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n4KD2KoV026000 for ; Wed, 20 May 2009 06:02:20 -0700 Received: from klph001.kcdc.att.com (klph001.kcdc.att.com [135.188.3.11]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n4KD2ISU025991 for ; Wed, 20 May 2009 06:02:19 -0700 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n4KD2I4F031660 for ; Wed, 20 May 2009 08:02:18 -0500 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n4KD2HZg031655 for ; Wed, 20 May 2009 08:02:17 -0500 Message-Id: <200905201302.n4KD2HZg031655@klph001.kcdc.att.com> Received: from acmt.att.com (martym.mt.att.com[135.16.251.71](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20090520130217gw1000u6m0e>; Wed, 20 May 2009 13:02:17 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 20 May 2009 09:02:17 -0400 To: ippm@ietf.org From: Al Morton Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ippm] Fwd: New Version Notification for draft-ietf-ippm-more-twamp-02 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 13:02:44 -0000 This version addresses IETF Last Call Comments >From: IETF I-D Submission Tool >To: acmorton@att.com >Cc: kaynam.hedayat@exfo.com >Subject: New Version Notification for draft-ietf-ippm-more-twamp-02 >Date: Wed, 20 May 2009 05:55:58 -0700 (PDT) > > >A new version of I-D, draft-ietf-ippm-more-twamp-02.txt has been >successfuly submitted by Al Morton and posted to the IETF repository. > >Filename: draft-ietf-ippm-more-twamp >Revision: 02 >Title: More Features for the Two-Way Active Measurement >Protocol - TWAMP >Creation_date: 2009-05-20 >WG ID: ippm >Number_of_pages: 10 > >Abstract: >This memo describes a simple extension to TWAMP - the Two-Way Active >Measurement Protocol. The extension adds the option to use different >security modes in the TWAMP-Control and TWAMP-Test protocols >simultaneously. The memo also requests that IANA establish a >registry for additional new features, called the TWAMP-Modes >registry. > > >The IETF Secretariat. From rfc-editor@rfc-editor.org Fri May 29 15:38:05 2009 Return-Path: X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E5E23A6AE4; Fri, 29 May 2009 15:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.949 X-Spam-Level: X-Spam-Status: No, score=-16.949 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] 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 9HxVtZiAx-Vn; Fri, 29 May 2009 15:38:04 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 5CAA33A7013; Fri, 29 May 2009 15:37:37 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id F026B2BBC25; Fri, 29 May 2009 15:38:11 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090529223811.F026B2BBC25@bosco.isi.edu> Date: Fri, 29 May 2009 15:38:11 -0700 (PDT) Cc: ippm@ietf.org, rfc-editor@rfc-editor.org Subject: [ippm] RFC 5560 on A One-Way Packet Duplication Metric X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2009 22:38:05 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5560 Title: A One-Way Packet Duplication Metric Author: H. Uijterwaal Status: Standards Track Date: May 2009 Mailbox: henk@ripe.net Pages: 14 Characters: 25304 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ippm-duplicate-08.txt URL: http://www.rfc-editor.org/rfc/rfc5560.txt When a packet is sent from one host to the other, one normally expects that exactly one copy of the packet that was sent arrives at the destination. It is, however, possible that a packet is either lost or that multiple copies arrive. In earlier work, a metric for packet loss was defined. This metric quantifies the case where a packet that is sent does not arrive at its destination within a reasonable time. In this memo, a metric for another case is defined: a packet is sent, but multiple copies arrive. The document also discusses streams and methods to summarize the results of streams. [STANDARDS TRACK] This document is a product of the IP Performance Metrics 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 USC/Information Sciences Institute