From sm@elandsys.com Fri Nov 9 11:17:56 2012 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF11521F86DC for ; Fri, 9 Nov 2012 11:17:56 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8j5hZVIzBPG for ; Fri, 9 Nov 2012 11:17:48 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C16221F86D2 for ; Fri, 9 Nov 2012 11:17:47 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.152.230]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qA9JHTAp020772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Nov 2012 11:17:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1352488665; bh=4PqrpSG8n+Mf/FOZH+0OIYuvQ6ffBmtndeSIRjg3K6g=; h=Date:To:From:Subject:Cc; b=Etio1kuHAgXr19CcVsda63FmDt6bzUL0iNyu9ZROiOQ4JKj5VS6wqadVZDvoWGpof MII6pyEQa3Fn00GH1KEtUvmHQ4HVQu0cW340EURl0EuLRJBZsErsbgjLIy4rGT0Drt LlJtX2o/9li+pxhk/h22YAW63xxyP6GXEMG1Uc7Q= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1352488665; i=@elandsys.com; bh=4PqrpSG8n+Mf/FOZH+0OIYuvQ6ffBmtndeSIRjg3K6g=; h=Date:To:From:Subject:Cc; b=4brh7ai3j44kyqvmzLtSfbNBOZfDUTTdQyZb+5CgJae4K1p9zBzEs5B5lL0ya4Qsy iuWW5sVWEJHzCEgTuSn2ijVjW+4rNXVjiSsaLpcqRDaV5VS1tQYTnG3qi+WJJ3mIv+ F8q41fg8BU2YC1hkhE+hkGz/Uz7lgfo/DQ18YeMk= Message-Id: <6.2.5.6.2.20121109111050.0bf25928@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 09 Nov 2012 11:17:19 -0800 To: Julian Reschke , Mark Nottingham From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: appsdir@ietf.org Subject: [appsdir] Request for review: draft-ietf-pkix-est-03 X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 19:17:57 -0000 Hi Julian, Mark, There was a request from a Sec AD for an early review draft-ietf-pkix-est-03. Could one of you please review the draft? Let me know which one of you can do it. I'll set the deadline for 19 November. Sean mentioned s3.2 of the draft, which is titled HTTP Layer Design and other sections that also address HTTP response codes. Best regards, -sm From julian.reschke@gmx.de Fri Nov 9 11:19:39 2012 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C18F21F86D0 for ; Fri, 9 Nov 2012 11:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.557 X-Spam-Level: X-Spam-Status: No, score=-103.557 tagged_above=-999 required=5 tests=[AWL=-0.958, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noTEd4G2XFvD for ; Fri, 9 Nov 2012 11:19:39 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 63F4D21F8676 for ; Fri, 9 Nov 2012 11:19:38 -0800 (PST) Received: (qmail invoked by alias); 09 Nov 2012 19:19:31 -0000 Received: from p5DD95B3C.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.91.60] by mail.gmx.net (mp071) with SMTP; 09 Nov 2012 20:19:31 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18PJmVGPg4PTuk+6QQyW5YNL2FhA1AJWwpK6Xla7U IwkhRzbtHHhcZi Message-ID: <509D5741.50208@gmx.de> Date: Fri, 09 Nov 2012 20:19:29 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: SM References: <6.2.5.6.2.20121109111050.0bf25928@elandnews.com> In-Reply-To: <6.2.5.6.2.20121109111050.0bf25928@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Mark Nottingham , appsdir@ietf.org Subject: Re: [appsdir] Request for review: draft-ietf-pkix-est-03 X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 19:19:39 -0000 On 2012-11-09 20:17, SM wrote: > Hi Julian, Mark, > > There was a request from a Sec AD for an early review > draft-ietf-pkix-est-03. Could one of you please review the draft? Let > me know which one of you can do it. I'll set the deadline for 19 November. > > Sean mentioned s3.2 of the draft, which is titled HTTP Layer Design and > other sections that also address HTTP response codes. > > Best regards, > -sm Sorry, no bandwidth left right now. Best regards, Julian From julian.reschke@gmx.de Sun Nov 11 09:18:07 2012 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAD121F860D for ; Sun, 11 Nov 2012 09:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.623 X-Spam-Level: X-Spam-Status: No, score=-103.623 tagged_above=-999 required=5 tests=[AWL=-1.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0hLDs7YArX6 for ; Sun, 11 Nov 2012 09:18:06 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 278A621F85C4 for ; Sun, 11 Nov 2012 09:18:05 -0800 (PST) Received: (qmail invoked by alias); 11 Nov 2012 17:18:04 -0000 Received: from p54BB257A.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.37.122] by mail.gmx.net (mp069) with SMTP; 11 Nov 2012 18:18:04 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+Jy98WG8mJW4ES0bkbiXjQkk+dkw2XjNK3UPj9av ewKPxY7MJcV9hV Message-ID: <509FDDC8.7000604@gmx.de> Date: Sun, 11 Nov 2012 18:18:00 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: SM References: <6.2.5.6.2.20121109111050.0bf25928@elandnews.com> In-Reply-To: <6.2.5.6.2.20121109111050.0bf25928@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Mark Nottingham , appsdir@ietf.org, draft-ietf-pkix-est@tools.ietf.org Subject: Re: [appsdir] Request for review: draft-ietf-pkix-est-03 X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 17:18:07 -0000 On 2012-11-09 20:17, SM wrote: > Hi Julian, Mark, > > There was a request from a Sec AD for an early review > draft-ietf-pkix-est-03. Could one of you please review the draft? Let > me know which one of you can do it. I'll set the deadline for 19 November. > > Sean mentioned s3.2 of the draft, which is titled HTTP Layer Design and > other sections that also address HTTP response codes. > > Best regards, > -sm I can't do a complete review, but here's some editorial feedback on the HTTP related bits: > 3.2. HTTP Layer Design > > > HTTP is used to transfer EST messages. URIs are provisioned for > handling each media type (i.e., message type) as described in > Section 3.2.2. HTTP is also used for client authentication services > when TLS client authentication is not available due to lack of a > client certificate suitable for use by TLS, as detailed in Section > Section 3.2.3. Registered media types are used to convey EST > messages as specified in Figure 5. > > HTTP 1.1 [RFC2616] and above support persistent connections. As > given in Section 8.1 of that RFC persistent connections may be used > to reduce network and processing load associated with multiple HTTP > requests. EST does not require or preclude persistent HTTP > connections and their use is out of scope of this specification. I think the paragraph above isn't needed here. > 3.2.1. HTTP headers for control s/header/header fields/ (throughout) > This document profiles the HTTP content-type header (as defined in > [RFC2046], but see Figure 5 for specific values) to indicate the The HTTP Content-Type header field is defined in RFC 2616, Section 14.17. > media type for EST messages and to specify control messages for EST. > The HTTP Status value is used to communicate success or failure of > EST functions Support for the HTTP authentication methods is > available for a client that does not have a certificate. > > CMC uses the same messages for certificate renewal and certificate > rekey. This specification defines the renewal and rekey behavior of > both the client and server. It does so by using the HTTP control > mechanisms employed by the client and server as opposed to using CMC. > > Various media types as indicated in the HTTP content-type header are > used to transfer EST messages. Media types used by EST are specified > in Section 3.2.4. > > 3.2.2. HTTP URIs for control > > > This profile supports six operations indicated by specific URIs: > > Operations and their corresponding URIs: > +------------------------+-----------------+-------------------+ > | Operation |Operation Path | Details | > +========================+=================+===================+ > | Distribution of CA | /CACerts | Section 4.3 | > | certificates (MUST) | | | > +------------------------+-----------------+-------------------+ > | Enrollment of new | /simpleEnroll | Section 4.4 | > | clients (MUST) | | | > +------------------------+-----------------+-------------------+ > | Re-Enrollment of | /simpleReEnroll | Section 4.4.1 | > | existing clients (MUST)| | | > +------------------------+-----------------+-------------------+ > | Full CMC (OPTIONAL) | /fullCMC | Section 4.5 | > +------------------------+-----------------+-------------------+ > | Server-side Key | /serverKeyGen | Section 4.6 | > | Generation (OPTIONAL) | | | > +------------------------+-----------------+-------------------+ > | Request CSR attributes | /CSRAttrs | Section 4.7 | > | (OPTIONAL) | | | > +------------------------+-----------------+-------------------+ > > Figure 4 > > An HTTP base path common for all of an EST server's requests is > defined in the form of an path-absolute ([RFC3986], section 3.3). > The operation path (Figure 4 is appended to the base path to form the > URI used with HTTP GET or POST to perform the desired EST operation. > > An example: > > With a base path of "/arbitrary/path" and an operation path of > "/CACerts", the EST client would combine them to form an absolute > path of "/arbitrary/path/CACerts". Thus, to retrieve the CA's > certificates, the EST client would use the following HTTP request: > > GET /arbitrary/path/CACerts HTTP/1.1 > > Likewise, to request a new certificate in this example scheme, the > EST client would use the following request: > > POST /arbitrary/path/simpleEnroll HTTP/1.1 > > The mechanisms by which the EST server interacts with an HTTPS server > to handle GET and POST operations at these URIs is outside the scope > of this document. The use of distinct operation paths simplifies > implementation for servers that do not perform client authentication > when distributing /CACerts responses. > > EST clients are provided with the base path URI of the EST server. > Potential methods of distributing the URI are discussed within the > Security Considerations (see Section 6 and Section 4.1). > > An EST server MAY provide additional, services using other URIs. > > An EST server MAY use multiple base paths in order to provide service > for multiple CAs. Each CA would use a distinct base path, but > operations are otherwise the same as specified for an EST server > operating on behalf of only one CA. > > 3.2.3. HTTP-Based Client Authentication > > > An EST server that has authenticated itself to the client MAY request > HTTP-based client authentication. This request can be in addition to > successful TLS client authentication (Section 3.3.1.2) if EST server > policy requires additional authentication (for example the EST server > wishes to confirm the EST client "knows" a password in addition to > "having" an existing client certificate). Or HTTP-based client > authentication can be an EST server policy specified fallback in > situations where the EST client did not successfully complete the TLS > client authentication (for example if the EST client is enrolling for > the first time or the existing EST client certificates can not be > used for TLS client authentication). > > HTTP Basic and Digest authentication MUST only be performed over TLS > 1.1 [RFC4346] (or later). As specified in CMC: Transport Protocols > [RFC5273] the server "MUST NOT assume client support for any type of > HTTP authentication such as cookies, Basic authentication, or Digest > authentication". Clients intended for deployments where password > authentication is advantageous SHOULD support the Basic and Digest > authentication mechanism. Servers MAY provide configuration ...be careful with BCP14 keywords where they are not needed... > mechanisms for administrators to enable Basic and Digest > authentication methods. > > Servers that wish to use Basic and Digest authentication reject the > HTTP request using the HTTP defined WWW-Authenticate response-header > ([RFC2616], Section 14.47). At that point the client SHOULD repeat No, by the 401 status code. > the request, including the appropriate Authorization Request Header > ([RFC2617], Section 3.2.2) if the client is capable of using the > Basic or Digest authentication. If the client is not capable then > the client MUST terminate the connection. > > Clients MAY set the username to the empty string ("") if they wish to > present a "one-time password" or "PIN" that is not associated with a > username. > > Support for HTTP-based client authentication has security > ramifications as discussed in Section 6. The client MUST NOT respond > to the server's HTTP authentication request unless the client has > authenticated the EST server (as per Section 4.1). > > 3.2.4. Message types > > > This document uses existing media types for the messages as specified > by [RFC2585], [RFC5967], and CMC [RFC5272]. To support distribution > of multiple certificates for the CA certificate chain, the [RFC2046] > multipart/mixed media type is used. > > The message type is specified in the HTTP Content-Type header with a > media type. The use herein is consistent with [RFC5273]. > > For reference the messages and their corresponding media types are: > > +--------------------+--------------------------+-------------------+ > | Message type |Request media type | Request section | > | |Response media type | Response section | > | |Source(s) of types | | > +====================+==========================+===================+ > | CA certificate | N/A | Section 4.3 | > | request | application/pkcs7-mime | Section 4.3.1 | > | | [RFC5751] | | > +--------------------+--------------------------+-------------------+ > | Cert enroll/renew/ | application/pkcs10 | Section 4.4/4.4.1 | > | rekey | application/pkcs7-mime | Section 4.4.2 | > | | [RFC5967] [RFC5751] | | > +--------------------+--------------------------+-------------------+ > | Full CMC | application/pkcs7-mime | Section 4.5.1 | > | | application/pkcs7-mime | Section 4.5.2 | > | | [RFC5751] | | > +--------------------+--------------------------+-------------------+ > | Server-side Key | application/pkcs10 | Section 4.6.1 | > | Generation | multipart/mixed | Section 4.6.2 | > | | (application/pkcs7-mime &| | > | | application/pkcs8) | | > | | [RFC5967] [RFC5751] | | > +--------------------+--------------------------+-------------------+ > | Request CSR | N/A | Section 4.7.1 | > | attributes | application/csrattrs | Section 4.7.2 | > | | This RFC | | > +--------------------+--------------------------+-------------------+ > Finally, you may want to update the references to use HTTPbis instead of RFC 2616. Best regards, Julian From sm@elandsys.com Sun Nov 11 09:45:10 2012 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7947921F8564 for ; Sun, 11 Nov 2012 09:45:09 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rri46n16lAdK for ; Sun, 11 Nov 2012 09:45:04 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D096421F8555 for ; Sun, 11 Nov 2012 09:45:03 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.152.105]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qABHiki3008667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Nov 2012 09:44:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1352655899; bh=Z55AkmsPg3vKym6yz7jGOnI+r1Gbr5m2M6NPou/yWL8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=CvW25JLUxr3aasuudLL1cN+SWlj0Nh8TRrdsH+uC8kCNUp7eC5qQvzzVEJh2ysPWJ QUbCNCLlBLwKMBvXu72FfqgDH8jiVurEXQDuI08FEifWODSMqdhSPgPP3JaUP95TpQ Al4aaL3QJoN9AoRTBl4UMgSyAurxoRb8SLSD9koY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1352655899; i=@elandsys.com; bh=Z55AkmsPg3vKym6yz7jGOnI+r1Gbr5m2M6NPou/yWL8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=B3ACvKpbo8/2NisYZzBjibOQEw4gZ2YaS2ZzQUW1J8WSyQqHXl4ThQg8RzR22UnWa nSnyBmTX0PNZVbJFg3gU5YbTJcA3DfHpVnIyxQc91rN1hTAYDSIlf8HHfqGNfFBEaT LYX//TuEsYq5s8r2iDLfEUyIQ5tjm0+VbF9AY4sQ= Message-Id: <6.2.5.6.2.20121111092640.0b566118@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 11 Nov 2012 09:29:04 -0800 To: Julian Reschke From: SM In-Reply-To: <509FDDC8.7000604@gmx.de> References: <6.2.5.6.2.20121109111050.0bf25928@elandnews.com> <509FDDC8.7000604@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Mark Nottingham , appsdir@ietf.org, draft-ietf-pkix-est@tools.ietf.org Subject: Re: [appsdir] Request for review: draft-ietf-pkix-est-03 X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 17:45:10 -0000 Hi Julian, At 09:18 11-11-2012, Julian Reschke wrote: >I can't do a complete review, but here's some editorial feedback on >the HTTP related bits: Thanks for taking a look at the draft. I am waiting for Mark to get back to me. Best regards, -sm From pritikin@cisco.com Sun Nov 11 09:41:31 2012 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C5321F855B for ; Sun, 11 Nov 2012 09:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wigq1xtG-JQn for ; Sun, 11 Nov 2012 09:41:30 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2045E21F8531 for ; Sun, 11 Nov 2012 09:41:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11711; q=dns/txt; s=iport; t=1352655690; x=1353865290; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TgoruJJ/mL7HPB7z2g/1jnyPiIlnVrgLdqw1mrfyeak=; b=Wpc58cEJIGHL2Snj6uv+IuDdVFIRdRcUWzP9O9HSEILUS+cTi/VzRkq0 ZE3f3VinTrJxY60Cz/lJPz46wmLSznBKBRt9/XceEthqyMfRZfFX2XxE+ Ehw+P6xq1hTBE6tfQ1NcQ07RZeGOEAMJ6OCwkKJobcopf0/iidm0m8Zok w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKfin1CtJXG//2dsb2JhbABEw1aBCIIeAQEBAwESAWYFCwIBCBgKDhYyJQIECgQFCBqHVgMJBpsynweLLGmDJYJEYQOIJYolkgqBa4Jvghk X-IronPort-AV: E=McAfee;i="5400,1158,6892"; a="141062859" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 11 Nov 2012 17:41:29 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qABHfTH2012443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 11 Nov 2012 17:41:29 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.215]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.001; Sun, 11 Nov 2012 11:41:29 -0600 From: "Max Pritikin (pritikin)" To: Julian Reschke Thread-Topic: [appsdir] Request for review: draft-ietf-pkix-est-03 Thread-Index: AQHNwDCPljxy2eFVI06G7cxLo1Q8HZflS8cA Date: Sun, 11 Nov 2012 17:41:28 +0000 Message-ID: <53EA47528D6ACF4486AA152F92C2B6982C5F8D@xmb-rcd-x03.cisco.com> References: <6.2.5.6.2.20121109111050.0bf25928@elandnews.com> <509FDDC8.7000604@gmx.de> In-Reply-To: <509FDDC8.7000604@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.0.213] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19354.005 x-tm-as-result: No--52.705800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <27F6591990C42544B15F38AFBBFE57F8@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 11 Nov 2012 09:46:44 -0800 Cc: Mark Nottingham , "" , SM , "" Subject: Re: [appsdir] Request for review: draft-ietf-pkix-est-03 X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 17:41:31 -0000 Thank for the time Julian, we'll update the references and tighten the lang= uage as you suggest.=20 - max On Nov 11, 2012, at 10:18 AM, Julian Reschke wrote: > On 2012-11-09 20:17, SM wrote: >> Hi Julian, Mark, >>=20 >> There was a request from a Sec AD for an early review >> draft-ietf-pkix-est-03. Could one of you please review the draft? Let >> me know which one of you can do it. I'll set the deadline for 19 Novemb= er. >>=20 >> Sean mentioned s3.2 of the draft, which is titled HTTP Layer Design and >> other sections that also address HTTP response codes. >>=20 >> Best regards, >> -sm >=20 > I can't do a complete review, but here's some editorial feedback on the H= TTP related bits: >=20 >> 3.2. HTTP Layer Design >>=20 >>=20 >> HTTP is used to transfer EST messages. URIs are provisioned for >> handling each media type (i.e., message type) as described in >> Section 3.2.2. HTTP is also used for client authentication services >> when TLS client authentication is not available due to lack of a >> client certificate suitable for use by TLS, as detailed in Section >> Section 3.2.3. Registered media types are used to convey EST >> messages as specified in Figure 5. >>=20 >> HTTP 1.1 [RFC2616] and above support persistent connections. As >> given in Section 8.1 of that RFC persistent connections may be used >> to reduce network and processing load associated with multiple HTTP >> requests. EST does not require or preclude persistent HTTP >> connections and their use is out of scope of this specification. >=20 > I think the paragraph above isn't needed here. >=20 >> 3.2.1. HTTP headers for control >=20 > s/header/header fields/ (throughout) >=20 >> This document profiles the HTTP content-type header (as defined in >> [RFC2046], but see Figure 5 for specific values) to indicate the >=20 > The HTTP Content-Type header field is defined in RFC 2616, Section 14.17. >=20 >> media type for EST messages and to specify control messages for EST. >> The HTTP Status value is used to communicate success or failure of >> EST functions Support for the HTTP authentication methods is >> available for a client that does not have a certificate. >>=20 >> CMC uses the same messages for certificate renewal and certificate >> rekey. This specification defines the renewal and rekey behavior of >> both the client and server. It does so by using the HTTP control >> mechanisms employed by the client and server as opposed to using CMC. >>=20 >> Various media types as indicated in the HTTP content-type header are >> used to transfer EST messages. Media types used by EST are specified >> in Section 3.2.4. >>=20 >> 3.2.2. HTTP URIs for control >>=20 >>=20 >> This profile supports six operations indicated by specific URIs: >>=20 >> Operations and their corresponding URIs: >> +------------------------+-----------------+-------------------+ >> | Operation |Operation Path | Details | >> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >> | Distribution of CA | /CACerts | Section 4.3 | >> | certificates (MUST) | | | >> +------------------------+-----------------+-------------------+ >> | Enrollment of new | /simpleEnroll | Section 4.4 | >> | clients (MUST) | | | >> +------------------------+-----------------+-------------------+ >> | Re-Enrollment of | /simpleReEnroll | Section 4.4.1 | >> | existing clients (MUST)| | | >> +------------------------+-----------------+-------------------+ >> | Full CMC (OPTIONAL) | /fullCMC | Section 4.5 | >> +------------------------+-----------------+-------------------+ >> | Server-side Key | /serverKeyGen | Section 4.6 | >> | Generation (OPTIONAL) | | | >> +------------------------+-----------------+-------------------+ >> | Request CSR attributes | /CSRAttrs | Section 4.7 | >> | (OPTIONAL) | | | >> +------------------------+-----------------+-------------------+ >>=20 >> Figure 4 >>=20 >> An HTTP base path common for all of an EST server's requests is >> defined in the form of an path-absolute ([RFC3986], section 3.3). >> The operation path (Figure 4 is appended to the base path to form the >> URI used with HTTP GET or POST to perform the desired EST operation. >>=20 >> An example: >>=20 >> With a base path of "/arbitrary/path" and an operation path of >> "/CACerts", the EST client would combine them to form an absolute >> path of "/arbitrary/path/CACerts". Thus, to retrieve the CA's >> certificates, the EST client would use the following HTTP request: >>=20 >> GET /arbitrary/path/CACerts HTTP/1.1 >>=20 >> Likewise, to request a new certificate in this example scheme, the >> EST client would use the following request: >>=20 >> POST /arbitrary/path/simpleEnroll HTTP/1.1 >>=20 >> The mechanisms by which the EST server interacts with an HTTPS server >> to handle GET and POST operations at these URIs is outside the scope >> of this document. The use of distinct operation paths simplifies >> implementation for servers that do not perform client authentication >> when distributing /CACerts responses. >>=20 >> EST clients are provided with the base path URI of the EST server. >> Potential methods of distributing the URI are discussed within the >> Security Considerations (see Section 6 and Section 4.1). >>=20 >> An EST server MAY provide additional, services using other URIs. >>=20 >> An EST server MAY use multiple base paths in order to provide service >> for multiple CAs. Each CA would use a distinct base path, but >> operations are otherwise the same as specified for an EST server >> operating on behalf of only one CA. >>=20 >> 3.2.3. HTTP-Based Client Authentication >>=20 >>=20 >> An EST server that has authenticated itself to the client MAY request >> HTTP-based client authentication. This request can be in addition to >> successful TLS client authentication (Section 3.3.1.2) if EST server >> policy requires additional authentication (for example the EST server >> wishes to confirm the EST client "knows" a password in addition to >> "having" an existing client certificate). Or HTTP-based client >> authentication can be an EST server policy specified fallback in >> situations where the EST client did not successfully complete the TLS >> client authentication (for example if the EST client is enrolling for >> the first time or the existing EST client certificates can not be >> used for TLS client authentication). >>=20 >> HTTP Basic and Digest authentication MUST only be performed over TLS >> 1.1 [RFC4346] (or later). As specified in CMC: Transport Protocols >> [RFC5273] the server "MUST NOT assume client support for any type of >> HTTP authentication such as cookies, Basic authentication, or Digest >> authentication". Clients intended for deployments where password >> authentication is advantageous SHOULD support the Basic and Digest >> authentication mechanism. Servers MAY provide configuration >=20 > ...be careful with BCP14 keywords where they are not needed... >=20 >> mechanisms for administrators to enable Basic and Digest >> authentication methods. >>=20 >> Servers that wish to use Basic and Digest authentication reject the >> HTTP request using the HTTP defined WWW-Authenticate response-header >> ([RFC2616], Section 14.47). At that point the client SHOULD repeat >=20 > No, by the 401 status code. >=20 >> the request, including the appropriate Authorization Request Header >> ([RFC2617], Section 3.2.2) if the client is capable of using the >> Basic or Digest authentication. If the client is not capable then >> the client MUST terminate the connection. >>=20 >> Clients MAY set the username to the empty string ("") if they wish to >> present a "one-time password" or "PIN" that is not associated with a >> username. >>=20 >> Support for HTTP-based client authentication has security >> ramifications as discussed in Section 6. The client MUST NOT respond >> to the server's HTTP authentication request unless the client has >> authenticated the EST server (as per Section 4.1). >>=20 >> 3.2.4. Message types >>=20 >>=20 >> This document uses existing media types for the messages as specified >> by [RFC2585], [RFC5967], and CMC [RFC5272]. To support distribution >> of multiple certificates for the CA certificate chain, the [RFC2046] >> multipart/mixed media type is used. >>=20 >> The message type is specified in the HTTP Content-Type header with a >> media type. The use herein is consistent with [RFC5273]. >>=20 >> For reference the messages and their corresponding media types are: >>=20 >> +--------------------+--------------------------+-------------------+ >> | Message type |Request media type | Request section | >> | |Response media type | Response section | >> | |Source(s) of types | | >> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >> | CA certificate | N/A | Section 4.3 | >> | request | application/pkcs7-mime | Section 4.3.1 | >> | | [RFC5751] | | >> +--------------------+--------------------------+-------------------+ >> | Cert enroll/renew/ | application/pkcs10 | Section 4.4/4.4.1 | >> | rekey | application/pkcs7-mime | Section 4.4.2 | >> | | [RFC5967] [RFC5751] | | >> +--------------------+--------------------------+-------------------+ >> | Full CMC | application/pkcs7-mime | Section 4.5.1 | >> | | application/pkcs7-mime | Section 4.5.2 | >> | | [RFC5751] | | >> +--------------------+--------------------------+-------------------+ >> | Server-side Key | application/pkcs10 | Section 4.6.1 | >> | Generation | multipart/mixed | Section 4.6.2 | >> | | (application/pkcs7-mime &| | >> | | application/pkcs8) | | >> | | [RFC5967] [RFC5751] | | >> +--------------------+--------------------------+-------------------+ >> | Request CSR | N/A | Section 4.7.1 | >> | attributes | application/csrattrs | Section 4.7.2 | >> | | This RFC | | >> +--------------------+--------------------------+-------------------+ >>=20 >=20 > Finally, you may want to update the references to use HTTPbis instead of = RFC 2616. >=20 > Best regards, Julian >=20 From barryleiba.mailing.lists@gmail.com Sun Nov 11 14:29:34 2012 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C275721F8505 for ; Sun, 11 Nov 2012 14:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.788 X-Spam-Level: X-Spam-Status: No, score=-102.788 tagged_above=-999 required=5 tests=[AWL=0.189, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8uuaKq-Uu7T for ; Sun, 11 Nov 2012 14:29:33 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id DC30721F84E8 for ; Sun, 11 Nov 2012 14:29:28 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so513510lah.31 for ; Sun, 11 Nov 2012 14:29:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=KZKzMFjKHxHVmeDuIDb22T/+dSo4JGYGkOw5VnzBYBo=; b=XlAW+kVBp4R8BXP3nr4TLpNacsyzWz1Rg03SD2uFiac1+NnDS8mtUEJlnCjGWXQojP 64DWNCaCVOf2bTMFbr6daQfO4ijozvySstBkETZAbWMf1lCdSIHum/3J3JFiI9EYAwdZ I3OlrBlgDWv7A7lgmMez0NIm9xLGBeVXJ54E7ijeG0/XsDmVlY98vvnqjNOF0ai3IOJk UmiYEAGrhFemuOCUTuL3JcBaaRJwTJ5fjipzJDQHXPovrD1OmsIUp8J2QDdkBhMYKm+D EA0sxEfGX++zXXZuLRRupmeEiFM7piKi/hUJlVyZg35X5Diev9d5Qse4z/rEAySBLUuF FGBQ== MIME-Version: 1.0 Received: by 10.152.103.100 with SMTP id fv4mr16298619lab.39.1352672967756; Sun, 11 Nov 2012 14:29:27 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.12.166 with HTTP; Sun, 11 Nov 2012 14:29:27 -0800 (PST) In-Reply-To: <53EA47528D6ACF4486AA152F92C2B6982C5F8D@xmb-rcd-x03.cisco.com> References: <6.2.5.6.2.20121109111050.0bf25928@elandnews.com> <509FDDC8.7000604@gmx.de> <53EA47528D6ACF4486AA152F92C2B6982C5F8D@xmb-rcd-x03.cisco.com> Date: Sun, 11 Nov 2012 17:29:27 -0500 X-Google-Sender-Auth: PzGnPNyCGXNeB5bqWcM9jsMdgqw Message-ID: From: Barry Leiba To: "Max Pritikin (pritikin)" Content-Type: text/plain; charset=ISO-8859-1 Cc: Julian Reschke , Mark Nottingham , "" , SM , "" Subject: Re: [appsdir] Request for review: draft-ietf-pkix-est-03 X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 22:29:34 -0000 >> Finally, you may want to update the references to use HTTPbis instead of RFC 2616. > > Thank for the time Julian, we'll update the references and tighten the language as you suggest. Note that you should discuss this with your AD first, before switching to the HTTPbis references. While it's the best approach in principle, it may cause delays in the RFC Editor queue: the HTTPbis documents are still a few months from IESG approval, I think, and they're building up quite a cluster for the RFC Editor to deal with. If you don't mind that, you should convert the references (the conversion will involve figuring out which of the six HTTPbis documents each 2616 reference maps to). If you want to get the PKIX documents through to RFC quickly, it might not be worth it. Sean can advise. Barry From sm@elandsys.com Wed Nov 14 14:55:54 2012 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4EC21F8721 for ; Wed, 14 Nov 2012 14:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3mw2ezNRISR for ; Wed, 14 Nov 2012 14:55:53 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0F421F854D for ; Wed, 14 Nov 2012 14:55:53 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.141.41]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qAEMriLZ014217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Nov 2012 14:53:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1352933638; bh=bYIMk0DIWRuD8KPHqAIPhR+S5QMwp5tDd2luoBu/I3c=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=iNWSScTg1R39XCKtpLXfPd7xDs0OkIqtxWQHKcyEuGcolXFkBwM8QDoVlDwgGGBxz q6f6+TlQYzVHi62130b7BQfpnKecHCeRZ3OHvImaQE5dPFpCu7NJ3dRFeYFwdLRsR2 5iXzXVkPF3cuVHvoWsSd9BYDUacEL6Ewafu63ksc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1352933638; i=@elandsys.com; bh=bYIMk0DIWRuD8KPHqAIPhR+S5QMwp5tDd2luoBu/I3c=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=m0//xKmSZlhA16/i20TB5zyJHIQv77G96v/tZY5SEz46W0GIvCBLJEgmj9wkpF8Wt CIlMHg5Yz4XBOKd+iI+gSSTRR8DPwTAIEiBItk2aw8uad3dzvWaa0P0FZfjASo/Km3 71AxvVae+4mFllEZLHBVF/LxcEYfWotGlXMpRjcw= Message-Id: <6.2.5.6.2.20121114144510.090d2ad0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 14 Nov 2012 14:53:29 -0800 To: Enrico Marocco , Claudio Allocchio , "Vijay K. Gurbani" From: SM In-Reply-To: <50A411A3.6060600@qti.qualcomm.com> References: <50A411A3.6060600@qti.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Pete Resnick , appsdir@ietf.org Subject: Re: [appsdir] [apps-discuss] AD Fail - MPTCP API X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 22:55:54 -0000 At 13:48 14-11-2012, Pete Resnick wrote: >If I were a good AD, I'd have been monitoring this all along and >would have given a long heads up, before IETF Last Call. If I were a >good AD, I would have asked for an Apps Directorate review. Now, >Last Call complete and less than 19 hours before an IESG Telechat, I >come to you, head hung in shame. Bad Pete. Apologies to Pete for not catching this. Claudio, Enrico, Vijay, or anyone else, could you please take a quick look at this and comment? Thanks, -sm >https://datatracker.ietf.org/doc/draft-ietf-mptcp-api/ is on >tomorrow's telechat. I love MPTCP and think it is exactly the right >way to deal with multiple interfaces, but some of the stuff in this >particular document makes me nervous. Unfortunately, I have not >written any code to a sockets API in too long. I have already bugged >two people for comments (thanks Chris and Cyrus), but I wouldn't >mind more people looking at this document. It's only Informational, >but I am quite sure people will start coding this stuff. I'm >personally more worried about the legacy API interactions (see >section 4.2.2 in particular), but if you have thoughts on the new >APIs as well, they would be welcome. > >I'm going to be writing up my comments, but at this point I'm not >planning on asking to DISCUSS it. But if anyone has concerns where >you think, "Holy crap! You can't let people start coding that, even >if it is just experimental!", you've got not much time to let me know. > >Begging your forgiveness, > >pr > >-- >Pete Resnick >Qualcomm Technologies, Inc. - +1 (858)651-4478 From superuser@gmail.com Wed Nov 14 14:59:10 2012 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B28A21F884F for ; Wed, 14 Nov 2012 14:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=-0.708, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfi4aejj0oFo for ; Wed, 14 Nov 2012 14:59:09 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE1A21F881B for ; Wed, 14 Nov 2012 14:59:08 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so918474lbk.31 for ; Wed, 14 Nov 2012 14:59:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rpWl3zaYha2y3nNF9lsujvy0gIJvJld+VUxT+Tpk1Qc=; b=farBpZ3nHRPR0FGVDVJ6uu72giV4N7hNv3Slkgce3QxT/+L6upy4JuXDYTzNJuaCZ2 5cY52am97NCPl/xxt66keaOVEPQlAApoe4gsYxiAZnpa8ikdEesxm3PiCmgoswaypDX7 +cJ8rkte9hRa9H1FJftq/XHQUwSE+t1bqj1JoPdLKc+HiaabbzXCv/y4JKo59YM94SSH h86SZ2OXQmS4zztbGGwdtu/dHnFhpTEaOZOXIqfvfWOe6qxZEHxKsv4H8SS2zGVY1xZZ xHykgbXC5s5IdOr4udl26LX6SE9s/LhKUCipEu0ms/qmEBiJ2En8ikKIMALh2VvRg/PM bO+w== MIME-Version: 1.0 Received: by 10.112.42.34 with SMTP id k2mr3838335lbl.26.1352933947958; Wed, 14 Nov 2012 14:59:07 -0800 (PST) Received: by 10.112.80.234 with HTTP; Wed, 14 Nov 2012 14:59:07 -0800 (PST) In-Reply-To: <6.2.5.6.2.20121114144510.090d2ad0@resistor.net> References: <50A411A3.6060600@qti.qualcomm.com> <6.2.5.6.2.20121114144510.090d2ad0@resistor.net> Date: Wed, 14 Nov 2012 14:59:07 -0800 Message-ID: From: "Murray S. Kucherawy" To: SM Content-Type: multipart/alternative; boundary=485b390f7dae5f67fb04ce7c7bfd Cc: Pete Resnick , Enrico Marocco , "Vijay K. Gurbani" , Claudio Allocchio , appsdir@ietf.org Subject: Re: [appsdir] [apps-discuss] AD Fail - MPTCP API X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 22:59:10 -0000 --485b390f7dae5f67fb04ce7c7bfd Content-Type: text/plain; charset=ISO-8859-1 I'll look at it this evening. On Wed, Nov 14, 2012 at 2:53 PM, SM wrote: > At 13:48 14-11-2012, Pete Resnick wrote: > >> If I were a good AD, I'd have been monitoring this all along and would >> have given a long heads up, before IETF Last Call. If I were a good AD, I >> would have asked for an Apps Directorate review. Now, Last Call complete >> and less than 19 hours before an IESG Telechat, I come to you, head hung in >> shame. Bad Pete. >> > > Apologies to Pete for not catching this. > > Claudio, Enrico, Vijay, or anyone else, could you please take a quick look > at this and comment? > > Thanks, > -sm > > > https://datatracker.ietf.org/**doc/draft-ietf-mptcp-api/is on tomorrow's telechat. I love MPTCP and think it is exactly the right >> way to deal with multiple interfaces, but some of the stuff in this >> particular document makes me nervous. Unfortunately, I have not written any >> code to a sockets API in too long. I have already bugged two people for >> comments (thanks Chris and Cyrus), but I wouldn't mind more people looking >> at this document. It's only Informational, but I am quite sure people will >> start coding this stuff. I'm personally more worried about the legacy API >> interactions (see section 4.2.2 in particular), but if you have thoughts on >> the new APIs as well, they would be welcome. >> >> I'm going to be writing up my comments, but at this point I'm not >> planning on asking to DISCUSS it. But if anyone has concerns where you >> think, "Holy crap! You can't let people start coding that, even if it is >> just experimental!", you've got not much time to let me know. >> >> Begging your forgiveness, >> >> pr >> >> -- >> Pete Resnick >> > >> Qualcomm Technologies, Inc. - +1 (858)651-4478 >> > > ______________________________**_________________ > appsdir mailing list > appsdir@ietf.org > https://www.ietf.org/mailman/**listinfo/appsdir > --485b390f7dae5f67fb04ce7c7bfd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'll look at it this evening.


On Wed, Nov 14, 2012 at 2:53 PM, SM <sm+ietf@el= andsys.com> wrote:
At 13:48 14-11-2012, Pete = Resnick wrote:
If I were a good AD, I'd have been monitoring this all along and would = have given a long heads up, before IETF Last Call. If I were a good AD, I w= ould have asked for an Apps Directorate review. Now, Last Call complete and= less than 19 hours before an IESG Telechat, I come to you, head hung in sh= ame. Bad Pete.

Apologies to Pete for not catching this.

Claudio, Enrico, Vijay, or anyone else, could you please take a quick look = at this and comment?

Thanks,
-sm


https://datatracker.ietf.org/doc/draft-ietf-mptcp-api/ is on tomorrow's telechat. I love MPTCP and think it is exactly the = right way to deal with multiple interfaces, but some of the stuff in this p= articular document makes me nervous. Unfortunately, I have not written any = code to a sockets API in too long. I have already bugged two people for com= ments (thanks Chris and Cyrus), but I wouldn't mind more people looking= at this document. It's only Informational, but I am quite sure people = will start coding this stuff. I'm personally more worried about the leg= acy API interactions (see section 4.2.2 in particular), but if you have tho= ughts on the new APIs as well, they would be welcome.

I'm going to be writing up my comments, but at this point I'm not p= lanning on asking to DISCUSS it. But if anyone has concerns where you think= , "Holy crap! You can't let people start coding that, even if it i= s just experimental!", you've got not much time to let me know.
Begging your forgiveness,

pr

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

_______________________________________________
appsdir mailing list
appsdir@ietf.org<= br> https://www.ietf.org/mailman/listinfo/appsdir

--485b390f7dae5f67fb04ce7c7bfd-- From presnick@qti.qualcomm.com Wed Nov 14 19:38:56 2012 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 500CE1F041A for ; Wed, 14 Nov 2012 19:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBrRF346MUlh for ; Wed, 14 Nov 2012 19:38:55 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id B1E8421F8466 for ; Wed, 14 Nov 2012 19:38:55 -0800 (PST) X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="6956693" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 14 Nov 2012 19:23:53 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="1735431" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 14 Nov 2012 19:38:54 -0800 Received: from presnick-mac.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 14 Nov 2012 19:38:54 -0800 Message-ID: <50A463CC.8080507@qti.qualcomm.com> Date: Wed, 14 Nov 2012 21:38:52 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: SM References: <50A411A3.6060600@qti.qualcomm.com> <6.2.5.6.2.20121114144510.090d2ad0@resistor.net> In-Reply-To: <6.2.5.6.2.20121114144510.090d2ad0@resistor.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: Enrico Marocco , "Vijay K. Gurbani" , Claudio Allocchio , appsdir@ietf.org Subject: Re: [appsdir] [apps-discuss] AD Fail - MPTCP API X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 03:38:56 -0000 On 11/14/12 4:53 PM, SM wrote: > At 13:48 14-11-2012, Pete Resnick wrote: >> If I were a good AD, I'd have been monitoring this all along and >> would have given a long heads up, before IETF Last Call. If I were a >> good AD, I would have asked for an Apps Directorate review. Now, Last >> Call complete and less than 19 hours before an IESG Telechat, I come >> to you, head hung in shame. Bad Pete. > > Apologies to Pete for not catching this. No apology necessary. I didn't catch it either (obviously). Thanks. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From Claudio.Allocchio@garr.it Wed Nov 14 23:35:16 2012 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBA521F851C for ; Wed, 14 Nov 2012 23:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sjRUSYz2gdG for ; Wed, 14 Nov 2012 23:35:15 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id D311B21F8500 for ; Wed, 14 Nov 2012 23:35:14 -0800 (PST) Received: internal info suppressed Date: Thu, 15 Nov 2012 08:34:45 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@webcam1-all.garrtest.units.it To: SM In-Reply-To: <6.2.5.6.2.20121114144510.090d2ad0@resistor.net> Message-ID: References: <50A411A3.6060600@qti.qualcomm.com> <6.2.5.6.2.20121114144510.090d2ad0@resistor.net> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1352964889; bh=zP9ZCRJzvWu8N1JadzB3vyPN7nPE0lAPKORXjE3KSvw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=mkXcY/fpyzaGzujksVZI85q/qpJShARqQPFLK434HxGK9QR4Fh7E41IEotFXoxzDw AqIQq1ZJgmQJAexEcnE4zYxZCuXJ1pdpssIeFtwJl8oDa7an47/nnBWeskyKnfHSJ6 mN6BIkTE0wTb5nLP4w1bpO3iDEOwfOAE/elawa/M= Cc: Pete Resnick , Enrico Marocco , "Vijay K. Gurbani" , Claudio Allocchio , appsdir@ietf.org Subject: Re: [appsdir] [apps-discuss] AD Fail - MPTCP API X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 07:35:16 -0000 On Wed, 14 Nov 2012, SM wrote: > At 13:48 14-11-2012, Pete Resnick wrote: >> If I were a good AD, I'd have been monitoring this all along and would have >> given a long heads up, before IETF Last Call. If I were a good AD, I would >> have asked for an Apps Directorate review. Now, Last Call complete and less >> than 19 hours before an IESG Telechat, I come to you, head hung in shame. >> Bad Pete. > > Apologies to Pete for not catching this. > > Claudio, Enrico, Vijay, or anyone else, could you please take a quick look at > this and comment? OK, will to today! > > Thanks, > -sm > >> https://datatracker.ietf.org/doc/draft-ietf-mptcp-api/ is on tomorrow's >> telechat. I love MPTCP and think it is exactly the right way to deal with >> multiple interfaces, but some of the stuff in this particular document >> makes me nervous. Unfortunately, I have not written any code to a sockets >> API in too long. I have already bugged two people for comments (thanks >> Chris and Cyrus), but I wouldn't mind more people looking at this document. >> It's only Informational, but I am quite sure people will start coding this >> stuff. I'm personally more worried about the legacy API interactions (see >> section 4.2.2 in particular), but if you have thoughts on the new APIs as >> well, they would be welcome. >> >> I'm going to be writing up my comments, but at this point I'm not planning >> on asking to DISCUSS it. But if anyone has concerns where you think, "Holy >> crap! You can't let people start coding that, even if it is just >> experimental!", you've got not much time to let me know. >> >> Begging your forgiveness, >> >> pr >> >> -- >> Pete Resnick >> Qualcomm Technologies, Inc. - +1 (858)651-4478 > > _______________________________________________ > appsdir mailing list > appsdir@ietf.org > https://www.ietf.org/mailman/listinfo/appsdir > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From mnot@mnot.net Wed Nov 14 23:44:24 2012 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4128821F87A3 for ; Wed, 14 Nov 2012 23:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.256 X-Spam-Level: X-Spam-Status: No, score=-105.256 tagged_above=-999 required=5 tests=[AWL=-2.657, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eX4apmg43KC1 for ; Wed, 14 Nov 2012 23:44:23 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id C7D6021F85CD for ; Wed, 14 Nov 2012 23:44:23 -0800 (PST) Received: from [192.168.1.64] (unknown [118.209.81.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0C73A509BA; Thu, 15 Nov 2012 02:44:21 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <6.2.5.6.2.20121111092640.0b566118@elandnews.com> Date: Thu, 15 Nov 2012 18:44:40 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <6512ECC0-0C9A-471A-9A33-DF991F9F1445@mnot.net> References: <6.2.5.6.2.20121109111050.0bf25928@elandnews.com> <509FDDC8.7000604@gmx.de> <6.2.5.6.2.20121111092640.0b566118@elandnews.com> To: SM X-Mailer: Apple Mail (2.1499) Cc: "Julian F. Reschke" , appsdir@ietf.org Subject: Re: [appsdir] Request for review: draft-ietf-pkix-est-03 X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 07:44:24 -0000 Done. Let's see how that goes down. On 12/11/2012, at 4:29 AM, SM wrote: > Hi Julian, > At 09:18 11-11-2012, Julian Reschke wrote: >> I can't do a complete review, but here's some editorial feedback on = the HTTP related bits: >=20 > Thanks for taking a look at the draft. I am waiting for Mark to get = back to me. >=20 > Best regards, > -sm=20 -- Mark Nottingham http://www.mnot.net/ From sm@elandsys.com Thu Nov 15 00:08:04 2012 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA47E21F8772 for ; Thu, 15 Nov 2012 00:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36qxx-LC6gBj for ; Thu, 15 Nov 2012 00:08:03 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF5A21F875E for ; Thu, 15 Nov 2012 00:08:03 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.141.41]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qAF87lhI004837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 15 Nov 2012 00:08:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1352966881; bh=/391RMnvS0PrGktpXN2zwkXmfrTak6Bf3+J3sLGSEXc=; h=Date:To:From:Subject:Cc; b=DokP+4C3V2zKQpzctvlW12TnEC3qRDO9Wk2Jj1Bz62rMn41FFm6jobC4X4niQINYZ f3R4MeATOecxRBwY3XLACaWLV1Kq4VE7FKheLw06y8vI2f3o991Be/d6lXsEq+IKCW STIOz/KGbwpyL09nUIXgi7d54VNMFT+8Bd9n2jhY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1352966881; i=@elandsys.com; bh=/391RMnvS0PrGktpXN2zwkXmfrTak6Bf3+J3sLGSEXc=; h=Date:To:From:Subject:Cc; b=RuRlrYJnrTrjmuQRpKhpZHP4j+NMKkoN5HTZK+ED0fzS4b66CJeLAFoDkmNsPRKo8 ul+3SxQJ9LomtJ6P3X0TrbanNbbk4hMwi9k/Ys23b+ZIovJ+kUT+N/OczMX0RLikJt 6xhwNpEpIfkIPoHkTFNYOZ+HgkX5pJfhx9Hqdg8I= Message-Id: <6.2.5.6.2.20121114233206.0cbf0478@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 15 Nov 2012 00:07:06 -0800 To: appsdir@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [appsdir] List of drafts for review X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 08:08:05 -0000 Hello, There are a few drafts which would benefit from=20 an APPSDIR review. I'll list the draft name and=20 the reviewer. I'll set the deadline to November 21 to be on the safe side. draft-ietf-6man-uri-zoneid-05 - Yves Lafon draft-ietf-appsawg-json-patch-06 - Henry S. Thompson draft-ietf-appsawg-json-pointer-05 - Martin D=FCrst draft-ietf-ppsp-problem-statement-11 - Salvatore Loreto draft-ietf-imapmove-command-02 - Murray Kucherawy draft-ietf-paws-problem-stmt-usecases-rqmts-08 - Carsten Bormann draft-ietf-tcpm-experimental-options-02 - Eliot Lear draft-arkko-iesg-crossarea-02 - Peter Saint-Andre draft-ietf-v6ops-icp-guidance-04 - Jiankang Yao draft-ietf-6renum-static-problem-02 - Dave Cridland draft-ietf-sipcore-sip-websocket-06 - Alexey Mekinov draft-ietf-v6ops-464xlat-08 - Ted Hardie draft-salgueiro-vcarddav-kind-device-03 - Larry Masinter Best regards, -sm From duerst@it.aoyama.ac.jp Thu Nov 15 00:31:31 2012 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC5E21F88CD for ; Thu, 15 Nov 2012 00:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.617 X-Spam-Level: X-Spam-Status: No, score=-100.617 tagged_above=-999 required=5 tests=[AWL=-0.827, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbU5V3Q8tODJ for ; Thu, 15 Nov 2012 00:31:30 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 905C821F86E4 for ; Thu, 15 Nov 2012 00:31:30 -0800 (PST) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id qAF8VG2G009084 for ; Thu, 15 Nov 2012 17:31:17 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 0632_a77b_d2ab44cc_2efe_11e2_85b7_001d096c566a; Thu, 15 Nov 2012 17:31:16 +0900 Received: from [IPv6:::1] ([133.2.210.1]:57668) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 15 Nov 2012 17:31:18 +0900 Message-ID: <50A4A84F.4040908@it.aoyama.ac.jp> Date: Thu, 15 Nov 2012 17:31:11 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: SM References: <6.2.5.6.2.20121114233206.0cbf0478@elandnews.com> In-Reply-To: <6.2.5.6.2.20121114233206.0cbf0478@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: appsdir@ietf.org Subject: Re: [appsdir] List of drafts for review X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 08:31:31 -0000 On 2012/11/15 17:07, SM wrote: > Hello, > > There are a few drafts which would benefit from an APPSDIR review. I'll > list the draft name and the reviewer. I'll set the deadline to November > 21 to be on the safe side. > > draft-ietf-6man-uri-zoneid-05 - Yves Lafon > > draft-ietf-appsawg-json-patch-06 - Henry S. Thompson > > draft-ietf-appsawg-json-pointer-05 - Martin Dürst My name is already listed in the Ack section, so I'm not sure I'm the right person to do it, but I will give it a try. It's short enough, and I should be able to it by the deadline. I promise that I will not invest as much energy in this review as I did in the last one :-). Regards, Martin. > draft-ietf-ppsp-problem-statement-11 - Salvatore Loreto > > draft-ietf-imapmove-command-02 - Murray Kucherawy > > draft-ietf-paws-problem-stmt-usecases-rqmts-08 - Carsten Bormann > > draft-ietf-tcpm-experimental-options-02 - Eliot Lear > > draft-arkko-iesg-crossarea-02 - Peter Saint-Andre > > draft-ietf-v6ops-icp-guidance-04 - Jiankang Yao > > draft-ietf-6renum-static-problem-02 - Dave Cridland > > draft-ietf-sipcore-sip-websocket-06 - Alexey Mekinov > > draft-ietf-v6ops-464xlat-08 - Ted Hardie > > draft-salgueiro-vcarddav-kind-device-03 - Larry Masinter > > Best regards, > -sm > > _______________________________________________ > appsdir mailing list > appsdir@ietf.org > https://www.ietf.org/mailman/listinfo/appsdir > From sm@elandsys.com Thu Nov 15 00:44:06 2012 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C633F21F8800 for ; Thu, 15 Nov 2012 00:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.334 X-Spam-Level: X-Spam-Status: No, score=-102.334 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKL2FKjb2uZ0 for ; Thu, 15 Nov 2012 00:44:06 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 485A021F87E7 for ; Thu, 15 Nov 2012 00:44:05 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.141.41]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qAF8hq6x010125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Nov 2012 00:44:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1352969044; bh=inztaQK2c8jKtmPmrZIjwySlfcPr1HczBZI/H3psvy0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=0tK+nuVnU9SJ5jm5bupnzl1UuxkrpjUwXUCNLAF8kUoSzqh6yCzLblFOL7gBONgDi C/oGCfjeUPeXQeppIP3+InCONXTPA6fXP6lLtij9CgD8Jf0TJeNF9M7FWrh0/WUjol rx6dg+LhJJkeZ50NKSU4SGR02dEa7K4MkqSi3r/c= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1352969044; i=@elandsys.com; bh=inztaQK2c8jKtmPmrZIjwySlfcPr1HczBZI/H3psvy0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=HR6y2lDxBSfbUURRRkUh7+Brs0/x8kex2kCtEIE8NOWfOGCgKblz0fVOkJE9E7qvx Cz/wxBMpuvLg4r0Imua5sPe4hv1z357b6N4o2tN7nuXR4vnfzxoStBnveQ/G5FjWjc cLNTNqBs0zD7CqGBgCg/PsmGaHA4JuJq6KEDVu+0= Message-Id: <6.2.5.6.2.20121115003407.0bb8a5b8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 15 Nov 2012 00:43:36 -0800 To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= , William Mills From: SM In-Reply-To: <50A4A84F.4040908@it.aoyama.ac.jp> References: <6.2.5.6.2.20121114233206.0cbf0478@elandnews.com> <50A4A84F.4040908@it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: appsdir@ietf.org Subject: Re: [appsdir] List of drafts for review X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 08:44:06 -0000 Hi Martin, At 00:31 15-11-2012, Martin J. D=FCrst wrote: >My name is already listed in the Ack section, so=20 >I'm not sure I'm the right person to do it, but=20 >I will give it a try. It's short enough, and I=20 >should be able to it by the deadline. I promise=20 >that I will not invest as much energy in this=20 >review as I did in the last one :-). Oops, I should not have assigned this one to=20 you. Let's save that energy for another draft. :-) I'll reassign the review of=20 draft-ietf-appsawg-json-pointer-05 to William Mills. Best regards, -sm=20 From ht@inf.ed.ac.uk Thu Nov 15 09:07:00 2012 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E142A21F8940; Thu, 15 Nov 2012 09:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvAsai8XmsrO; Thu, 15 Nov 2012 09:06:59 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 783BC21F8939; Thu, 15 Nov 2012 09:06:58 -0800 (PST) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id qAFH6en0001415; Thu, 15 Nov 2012 17:06:45 GMT Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id qAFH6eqH011163; Thu, 15 Nov 2012 17:06:40 GMT Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id qAFH6dMW031713; Thu, 15 Nov 2012 17:06:39 GMT Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id qAFH6djs031709; Thu, 15 Nov 2012 17:06:39 GMT X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: apps-discuss@ietf.org, draft-ietf-appsawg-json-patch.all@tools.ietf.org References: <6.2.5.6.2.20121114233206.0cbf0478@elandnews.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 15 Nov 2012 17:06:39 +0000 In-Reply-To: <6.2.5.6.2.20121114233206.0cbf0478@elandnews.com> (SM's message of "Thu\, 15 Nov 2012 00\:07\:06 -0800") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b32 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Cc: appsdir@ietf.org, iesg@ietf.org Subject: [appsdir] Appsdir review of draft-ietf-appsawg-json-patch-06 X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 17:07:01 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-appsawg-json-patch-06 Title: JSON Patch Reviewer: Henry S. Thompson Review Date: 15 November 2012 IETF Last Call Date: 2012-11-23 Summary: This draft is almost ready for publication as an Proposed Standard but has a related set of issues that should be fixed before publication Note that I have not read previous drafts of or comments on this document -- I presume I was asked to review as a fresh pair of eyes. If the result is to repeat some previously-expressed comments, so be it. Major Issues: 4.1 This operation ('add') seems underspecified in several respects. 1) I would have expected a short statement of the actual effect under each bullet, e.g. "The specified value becomes the entire contents of the document"; 2) I would have expected error conditions to be specified under each bullet. I assume it is an error for "path" to be empty and the document to have content. The discussion of index errors wrt arrays could/should move, and the "common use" 'note', which isn't a note at all, should be specific to objects. 3) I take it you also need to say that if an _existing_ member of an object is referenced, that's not an error (note that it _is_ a JSON Pointer error), and the result is to increase the number of such members by one, with the new value. 4) I don't see any basis in the JSON Pointer spec. for "[using the] '-' character ... to index the end of the array" -- as I read the JSON Pointer spec. "/a/b/-" is an error if "/a/b" addresses an array. Similarly, "/a/b/5" is an error if "/a/b" addresses an array and the array is of length 5, which is not consistent with the implication of "The specified index MUST NOT be greater than the number of elements in the array", i.e. that "/a/b/5" is not ruled out in this case. If the intent is that a value of n, where n is the size of the array, or a -, is allowed to end a path which has gotten to an array, and results in an append operation, this should be stated explicitly. [Ah, subsequent information reveal that wrt '-', the bug is in the references, not the text -- the addition of '-' to JSON Pointer is in a subsequent draft to the one referenced here! I have to say that if '-' was added purely for use by JSON patch, I'd much prefer that you take my suggestion immediately below and revert the '-' addition to JSON Pointer.] I think in fact you might be better off to handle this by cases and avoid all 'intentional' JSON Pointer errors, along the lines of a) If the "path" is "" and the document is empty then the "value" becomes the document; b) If the path excluding its last step identifies an object, then "value" is added at the end of that object, with the name given by the decoded reference token of the last step; c) If the path excluding its last step identifies an array then i) If the last step's reference token encodes an integer i with 0 <= i < |array|, then . . . ii) If the last step's reference token is '-' or encodes |array|, then . . . Otherwise, the operation raises an error. 4.2, 4.3 Nothing is said about the case where a path which identifies a multiply-valued object member is given, which per JSON Pointer is a pointer error. 4.4 Given the real complexity of both 'remove' and 'add', 'move' really should be defined by reference to those operations, rather than repeating (imperfectly at the moment) their definitions. This would have the additional benefit of removing the necessity for the side conditions, all of which will now follow from the definitions of 'remove' and 'add' (except the invalidity of replacing the root, which should as far as I can see be allowed - { "op": "move", "path": "/a/b", "to": "" } seems perfectly reasonable to me). 4.5 Again, although the first side condition would have to remain, this should be defined by reference to 'add'. See below under Minor Issues wrt the second side condition. Minor Issues: 1. This is perfectly clear, but I still missed it: This spec. (and JSON Pointer) are about _documents_ and not Javascript objects. It's very easy to slip into thinking about objects, and indeed the spec. itself talks about the target as if it consisted of objects and arrays! It would of course be obnoxious to require you to say "JSON encoding of an object" every time, instead of just "object", but I wonder if it wouldn't be a good idea to say, here in the introduction, precisely that -- that you will (mostly) talk about the target as if it had a root, consisted of arrays and objects with members and values, etc., but what you will always _mean_ is being pointed to, tested, changed, etc. is the _JSON encoding_ of those things. 3. In a similar vein, wrt the patch document itself, I think it would be better to say e.g. "A JSON Patch document is a JSON [RFC4627] document which [represents/encodes/whatever] an array of objects." 4.5 I don't understand the reason for barring copying to an existing member. The rest of the spec. seems content to allow multiple identically-named members to be specified. . . You would, I guess, need to say that where it goes, but if you defined by reference to "add" as I've given it above, that would be taken care of. 4.6 When you get to string-string equality the object / encoding duality discussed above at 1. becomes a problem -- you have treated the patch as an object up until now, in which case any escaping will already have been dealt with. If one took the words in this case literally, the following test would succeed: Target { "a":"\b" } Patch [ { "op": "test", "path": "/a", "value":"\\b" } ] which is presumably not what you meant. It's clear from the wording you've used in this case that you _meant_ to refer here (and only here) to the _encoding_ of the value of the "value" property of the patch, not its value. Phew! Nits: [none] ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From mnot@mnot.net Thu Nov 15 15:16:44 2012 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9180F21F86A2; Thu, 15 Nov 2012 15:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.864 X-Spam-Level: X-Spam-Status: No, score=-104.864 tagged_above=-999 required=5 tests=[AWL=-2.265, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxFVms+JBfof; Thu, 15 Nov 2012 15:16:41 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 4947321F8669; Thu, 15 Nov 2012 15:16:41 -0800 (PST) Received: from [192.168.1.64] (unknown [118.209.81.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5DD11509B7; Thu, 15 Nov 2012 18:16:37 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: Date: Fri, 16 Nov 2012 10:16:37 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <95605F61-E530-4985-B385-0DA3D1E6084F@mnot.net> References: <6.2.5.6.2.20121114233206.0cbf0478@elandnews.com> To: Henry S. Thompson X-Mailer: Apple Mail (2.1499) Cc: draft-ietf-appsawg-json-patch.all@tools.ietf.org, appsdir@ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [appsdir] Appsdir review of draft-ietf-appsawg-json-patch-06 X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 23:16:44 -0000 Hi Henry, Thanks for the review. Responses below. On 16/11/2012, at 4:06 AM, Henry S. Thompson wrote: > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on appsdir, please see > = http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate)= . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. >=20 > Document: draft-ietf-appsawg-json-patch-06 > Title: JSON Patch > Reviewer: Henry S. Thompson > Review Date: 15 November 2012 > IETF Last Call Date: 2012-11-23 >=20 > Summary: This draft is almost ready for publication as an Proposed > Standard but has a related set of issues that should be fixed > before publication >=20 > Note that I have not read previous drafts of or comments on this > document -- I presume I was asked to review as a fresh pair of eyes. > If the result is to repeat some previously-expressed comments, so be > it. >=20 > Major Issues:=20 >=20 > 4.1 This operation ('add') seems underspecified in several respects. >=20 > 1) I would have expected a short statement of the actual effect > under each bullet, e.g. "The specified value becomes the entire > contents of the document"; I'll add these. > 2) I would have expected error conditions to be specified under each > bullet. I assume it is an error for "path" to be empty and the > document to have content. The discussion of index errors wrt > arrays could/should move, and the "common use" 'note', which > isn't a note at all, should be specific to objects. I'll look at reorganising these (is this really a *major* issue?). > 3) I take it you also need to say that if an _existing_ member of an > object is referenced, that's not an error (note that it _is_ a > JSON Pointer error), and the result is to increase the number of > such members by one, with the new value. I think that'll be the outcome of #1 above, yes. > I think in fact you might be better off to handle this by cases and > avoid all 'intentional' JSON Pointer errors, along the lines of >=20 > a) If the "path" is "" and the document is empty then the "value" > becomes the document; >=20 > b) If the path excluding its last step identifies an object, then > "value" is added at the end of that object, with the name given = by > the decoded reference token of the last step; >=20 > c) If the path excluding its last step identifies an array then >=20 > i) If the last step's reference token encodes an integer i with > 0 <=3D i < |array|, then . . . > ii) If the last step's reference token is '-' or encodes > |array|, then . . . >=20 > Otherwise, the operation raises an error. The "excluding its last step" is awkward. The error conditions in json = pointer were put there for exactly this kind of use; is it the word = 'error' that's causing you concern? > 4.2, 4.3 Nothing is said about the case where a path which identifies = a > multiply-valued object member is given, which per JSON Pointer is > a pointer error. To be clear - are you saying that we should handle the case where an = error in the underlying JSON bubbles up through JSON Pointer? E.g., { "foo": "bar", "foo": "baz" } ? > 4.4 Given the real complexity of both 'remove' and 'add', 'move' > really should be defined by reference to those operations, rather > than repeating (imperfectly at the moment) their definitions. > This would have the additional benefit of removing the necessity > for the side conditions, all of which will now follow from the > definitions of 'remove' and 'add' (except the invalidity of > replacing the root, which should as far as I can see be allowed - > { "op": "move", "path": "/a/b", "to": "" } seems perfectly > reasonable to me). To do that, I think we'd need to change "to" to "from", as the semantics = of "path" are so different.=20 I'm not averse to doing so, as long as we can get to agreement about it = quickly. Anyone object? > 4.5 Again, although the first side condition would have to remain, > this should be defined by reference to 'add'. See below under Minor > Issues wrt the second side condition To do that, I think we'd need to change "to" to "from", as the semantics = of "path" are so different.=20 I'm not averse to doing so, as long as we can get to agreement about it = quickly. Anyone object? > Minor Issues:=20 >=20 > 1. This is perfectly clear, but I still missed it: This spec. (and > JSON Pointer) are about _documents_ and not Javascript objects. > It's very easy to slip into thinking about objects, and indeed the > spec. itself talks about the target as if it consisted of objects > and arrays! It would of course be obnoxious to require you to say > "JSON encoding of an object" every time, instead of just "object", > but I wonder if it wouldn't be a good idea to say, here in the > introduction, precisely that -- that you will (mostly) talk about > the target as if it had a root, consisted of arrays and objects > with members and values, etc., but what you will always _mean_ is > being pointed to, tested, changed, etc. is the _JSON encoding_ of > those things. It *can* be about JavaScript objects; that was a use case for some = people, resulting in a bit of the dancing that we do. > 3. In a similar vein, wrt the patch document itself, I think it would > be better to say e.g. "A JSON Patch document is a JSON [RFC4627] > document which [represents/encodes/whatever] an array of objects." OK. > 4.5 I don't understand the reason for barring copying to an existing > member. The rest of the spec. seems content to allow multiple > identically-named members to be specified. . . You would, I > guess, need to say that where it goes, but if you defined by > reference to "add" as I've given it above, that would be taken > care of. We took similar language out of add (see thread 'json-patch: "op": = "insert" and "op": "put"'). I think it's reasonably to take it out of = copy as well -- others? > 4.6 When you get to string-string equality the object / encoding > duality discussed above at 1. becomes a problem -- you have > treated the patch as an object up until now, in which case any > escaping will already have been dealt with. If one took the words > in this case literally, the following test would succeed: >=20 > Target { "a":"\b" } >=20 > Patch [ { "op": "test", "path": "/a", "value":"\\b" } ] >=20 > which is presumably not what you meant. It's clear from the > wording you've used in this case that you _meant_ to refer here > (and only here) to the _encoding_ of the value of the "value" > property of the patch, not its value. Phew! I think we can address this by making it clear that all of the = operations are specified in term of JSON primitives (i.e., after = escaping), but examples are JSON documents, and giving a few more = examples to illustrate the corner cases. Make sense? Cheers, -- Mark Nottingham http://www.mnot.net/ From Claudio.Allocchio@garr.it Thu Nov 15 15:25:27 2012 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878EE21F8472; Thu, 15 Nov 2012 15:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.619 X-Spam-Level: X-Spam-Status: No, score=-0.619 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfYsU5hi1MtI; Thu, 15 Nov 2012 15:25:26 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE9721F8473; Thu, 15 Nov 2012 15:25:26 -0800 (PST) Received: internal info suppressed Date: Fri, 16 Nov 2012 00:25:02 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: SM In-Reply-To: <6.2.5.6.2.20121114144510.090d2ad0@resistor.net> Message-ID: References: <50A411A3.6060600@qti.qualcomm.com> <6.2.5.6.2.20121114144510.090d2ad0@resistor.net> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1353021904; bh=Bqzl4fxcVsb9oLCg3P5dm7lv3/kxqk8CB1rPHpflehE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=FzfwobpRPBfOTEjZNBvhFbgDgqNGi8m06/dN0ybJFLFEgfuTkYE1H1/VSmFj8e3SE /c6uDo4Yq6+V+UdiCY/nr/2xfIbmU+Kmu/9aIhlWJjoo2LI2Ty3ER2rVjVC21CNfrI jfVfrT4rYcASqET+yNijEvw91ngXX8QyX5faTTUw= Cc: Pete Resnick , appsdir@ietf.org, Claudio Allocchio , iesg@ietf.org Subject: [appsdir] APPSDIR review of draft-ietf-mptcp-api-06 X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 23:25:27 -0000 Hello all, I have been selected as the Applications Area Directorate co-reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-mptcp-api-06 Title: MPTCP Application Interface Considerations Reviewer: Claudio Allocchio Review Date: November 15th 2012 IETF Last Call Date: n/a IESG Telechat Date: November 15th2012 Summary: Given the arelady given comments on the apps-discuss ML on many parts of this informaiton documents (and I agree with them) I focused my review on the effects that MPTCP can have on esisting applications and deployment. I think the doument is anyhow very well written and ready for publication. However there a few minor issues that shall be fixed. Major Issues: none. Minor Issues: 3.1.2. Delay "Since burstiness is commonplace on the Internet today, it is unlikely that applications will suffer from such an impact on the traffic profile, but application authors may wish to consider this in future development." well, even it is true the burstiness is common on most of the Internet, this is not the case in many other circumstances, and there are, maybe a few, applications which do expect the jitter to be low and the packet delivery rate to be stable to work correctly (being the developer of one of them... "LOLA - Low latency A/V system" I did expericend already a number of cases where MPTCP did a disaster work just because of its presence on multiple parallel 10G links). Thus I would at least be not to optimistic in the above sentence. It is just not for future work. I just suggest changing it reportig that "this might be a problem" instead of "it is unlikely". In the same 3.1.2 section, again there are some application (already now) they deeply rely for correct functiong on an accurate estimate of RTT (for example those dealing with audio echo cancellation, or those triggering large scale instrumentation synchronization (for example EVLBI radio telescopes). Thus it not just "new" applications, but what my happen to existing applications shall be mentioned. in 3.2.1: "An MPTCP implementation can learn the rate of MPTCP connection attempt successes or failures to particular hosts or networks, and on particular interfaces, and could therefore learn heuristics of when and when not to use MPTCP." Well... are we sure this is a good suggestion? If it is a suggestion, then, what happens when network condition changes dynamically (for example because an application running as a client on a mobile host is moving about?) A.2. MPTCP Usage Scenarios and Application Requirements There are also application which requires bulk data traffic (in the range 1G and above) AND anre higly interactive, thus ask for low latency and jitter. What should be the choice in this (already existing) case? SOm guidance should be added also for them. Nits: 3.1. Performance Impact --> Effects on Performanc 5.2. "This can be implicit in many cases, since MPTCP must BE disabled by the use of binding to a specific address. ^^^" ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From ylafon@w3.org Mon Nov 26 06:56:46 2012 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222EC21F8452; Mon, 26 Nov 2012 06:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZsZWde227ym; Mon, 26 Nov 2012 06:56:45 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 786D421F843F; Mon, 26 Nov 2012 06:56:45 -0800 (PST) Received: from ylafon by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1Td070-0005OG-GL; Mon, 26 Nov 2012 09:56:42 -0500 Date: Mon, 26 Nov 2012 09:56:42 -0500 (EST) From: Yves Lafon To: apps-discuss@ietf.org, draft-ietf-6man-uri-zoneid@tools.ietf.org Message-ID: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: appsdir@ietf.org, iesg@ietf.org Subject: [appsdir] Review of draft-ietf-6man-uri-zoneid-05 X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 14:56:46 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-6man-uri-zoneid-05 Title: IPv6 Zone Identifiers in Address Literals and Uniform Resource=20 Identifiers Reviewer: Yves Lafon Review Date: 26 November 2012 IETF Last Call Date: 2012-11-23 Summary: The document is almost ready to progress, but some clarifications= =20 are needed on two points explicited below. In section 3: << This document implies that all browsers should recognise a ZoneID preceded by an escaped "%". In the spirit of "be liberal with what you accept", we also recommend that URI parsers accept bare "%" signs (i.e., a "%" not followed by two valid hexadecimal characters). This makes it easy for a user to copy and paste a string such as "fe80::a%en1" from the output of a "ping" command and have it work. >> Does it mean that such URIs can be present in an HTML document or that=20 they MAY allow bare "%" signs when the URI is pasted in the address bar?=20 (Those are two different use cases, and browsers may have different code=20 paths for both). In section 4: It says << An HTTP server or proxy MUST ignore any ZoneID attached to an incoming URI, as it only has local significance at the sending host. >> A proxy can be considered as a sending host, so does it mean that a the=20 receiving end MUST strip all ZoneID before processing the request? (and it= =20 would be a significant change to implementations), or could this be=20 resolved by mandating Web browser to strip ZoneID prior to sending the=20 request as it is only significant for the sending host and as it is the=20 implementation that needs to be updated to recognize the new syntax? --=20 Baroula que barouleras, au ti=E9u toujou t'entourneras. ~~Yves From brian.e.carpenter@gmail.com Mon Nov 26 08:19:20 2012 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF7A21F862E; Mon, 26 Nov 2012 08:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.691 X-Spam-Level: X-Spam-Status: No, score=-101.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpt3v7y6gzQ9; Mon, 26 Nov 2012 08:19:19 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7C17221F8567; Mon, 26 Nov 2012 08:19:12 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so7147209eek.31 for ; Mon, 26 Nov 2012 08:19:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=l0RMlPxHJIZ1/pfwsofLWyAVxLxGzeZ10Cg690edR+Y=; b=IRMbz7cXkpjF/ghFEmHm9AU4tD1YXHQ3XXjkxLQ8KzPx4OMuAMdKpWv1pBbkAHfeDj 2JeGTW4/XIbMJ/jj9SgSZOs+rr1ATtXSco6fE0RnTmYSHpSbM5klRxv606HrwMmmYcwI RsCD/koMdMT75buz1Rl1MCBChFZad/3eVziIJBUD9icj7sFLv5Zt/sR9sMuGI77YPyn4 AvbftPrpogtLrdSKEWM3aynETF1D48HPlN+dpJBHdVUGJYEEL0Ne8PjVgWCkrqW9I9w5 wHm86K9mWZ01Jsy3gK6nu4J/m8YASjbKH8BLB4ZICDlCQsRH3p1hbS6LIjc8IIW5aW3j fA7g== Received: by 10.14.176.68 with SMTP id a44mr47585425eem.1.1353946751669; Mon, 26 Nov 2012 08:19:11 -0800 (PST) Received: from [192.168.1.65] (host-2-102-218-115.as13285.net. [2.102.218.115]) by mx.google.com with ESMTPS id a45sm34391733eep.16.2012.11.26.08.19.09 (version=SSLv3 cipher=OTHER); Mon, 26 Nov 2012 08:19:10 -0800 (PST) Message-ID: <50B3967F.7040205@gmail.com> Date: Mon, 26 Nov 2012 16:19:11 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Yves Lafon References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 26 Nov 2012 08:28:44 -0800 Cc: draft-ietf-6man-uri-zoneid@tools.ietf.org, appsdir@ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [appsdir] [apps-discuss] Review of draft-ietf-6man-uri-zoneid-05 X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 16:19:20 -0000 Yves, On 26/11/2012 14:56, Yves Lafon wrote: > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on appsdir, please see > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). > > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-6man-uri-zoneid-05 > Title: IPv6 Zone Identifiers in Address Literals and Uniform Resource > Identifiers > Reviewer: Yves Lafon > Review Date: 26 November 2012 > IETF Last Call Date: 2012-11-23 > > Summary: The document is almost ready to progress, but some > clarifications are needed on two points explicited below. > > In section 3: > << > This document implies that all browsers should recognise a ZoneID > preceded by an escaped "%". In the spirit of "be liberal with what > you accept", we also recommend that URI parsers accept bare "%" signs > (i.e., a "%" not followed by two valid hexadecimal characters). This > makes it easy for a user to copy and paste a string such as > "fe80::a%en1" from the output of a "ping" command and have it work. >>> > > Does it mean that such URIs can be present in an HTML document or that > they MAY allow bare "%" signs when the URI is pasted in the address bar? > (Those are two different use cases, and browsers may have different code > paths for both). This is exactly why I suggested in the "New URL Standard..." thread on the IETF list that we need a formal distinction between URI syntax and the permitted "syntax" for user input strings. Without that distinction, we are obliged to specify them both as if they were the same thing. I really don't know how to capture this in the current draft. Since we do say that URIs with ZoneIDs are meaningless outside the originating host, that would mean they shouldn't be included in HTML documents IMHO. But I think somebody needs to rewrite RFC 3986. > In section 4: > It says > << > An HTTP server or proxy MUST ignore any ZoneID attached to an > incoming URI, as it only has local significance at the sending host. >>> > > A proxy can be considered as a sending host, so does it mean that a the > receiving end MUST strip all ZoneID before processing the request? (and > it would be a significant change to implementations), or could this be > resolved by mandating Web browser to strip ZoneID prior to sending the > request as it is only significant for the sending host and as it is the > implementation that needs to be updated to recognize the new syntax? IMHO it would be safest if the sending host strips it. We could certainly suggest that. However, as the draft is on the IESG agenda this week, we won't update it until we get all the IESG comments. Thanks Brian From barryleiba.mailing.lists@gmail.com Mon Nov 26 09:00:25 2012 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9819A21F8460; Mon, 26 Nov 2012 09:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwhWB6jtemZU; Mon, 26 Nov 2012 09:00:25 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 685A921F86D2; Mon, 26 Nov 2012 09:00:23 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so4167317eaa.31 for ; Mon, 26 Nov 2012 09:00:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ODUETJxyeaDn9BpGQbVxKPTjnUlit+3BXBLQpcQTY0Q=; b=otiP1y+swYjulrr44CHe2IU2VkV6n+bfJ9pE8h9SefcFqy//i3eGAX7sEA3wbSpJ+T gt9iux8688wBDzwglLZauO3yGtymTOQGMLM1kPHk1sFVW6gzxvEXTVVVwcsMrilAlsEV HCz3KPeCmc16JRDFLQbXzrP3dgMLxwjA2kCWGhfV9hVZorSFVPR8sJFUnAji05VwlB49 thQn9OJ9JyK0ySwKWKnysDtdZ+MmS/puthgEyfnnYnd5OepD8MdNUquJLFfQcVWUYXzW Vlrh7W6Vy7PwWpd8WONxOBUtRF+oFIcZjA77GxWaVMRGfgijm7+8BgGr1kDruMYzCAev SYEA== MIME-Version: 1.0 Received: by 10.14.179.69 with SMTP id g45mr47511195eem.42.1353949222324; Mon, 26 Nov 2012 09:00:22 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.14.100.202 with HTTP; Mon, 26 Nov 2012 09:00:22 -0800 (PST) In-Reply-To: <50B3967F.7040205@gmail.com> References: <50B3967F.7040205@gmail.com> Date: Mon, 26 Nov 2012 12:00:22 -0500 X-Google-Sender-Auth: CduW589RYRssA7KjeETzT_sljM0 Message-ID: From: Barry Leiba To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Cc: Yves Lafon , draft-ietf-6man-uri-zoneid@tools.ietf.org, "appsdir@ietf.org" , IESG , "apps-discuss@ietf.org" Subject: Re: [appsdir] [apps-discuss] Review of draft-ietf-6man-uri-zoneid-05 X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 17:00:25 -0000 >> << >> This document implies that all browsers should recognise a ZoneID >> preceded by an escaped "%". In the spirit of "be liberal with what >> you accept", we also recommend that URI parsers accept bare "%" signs >> (i.e., a "%" not followed by two valid hexadecimal characters). This >> makes it easy for a user to copy and paste a string such as >> "fe80::a%en1" from the output of a "ping" command and have it work. >>>> >> >> Does it mean that such URIs can be present in an HTML document or that >> they MAY allow bare "%" signs when the URI is pasted in the address bar? >> (Those are two different use cases, and browsers may have different code >> paths for both). > > This is exactly why I suggested in the "New URL Standard..." thread > on the IETF list that we need a formal distinction between URI syntax > and the permitted "syntax" for user input strings. Without that > distinction, we are obliged to specify them both as if they were > the same thing. I really don't know how to capture this in the current > draft. Perhaps it could be captured with something like this added to the quoted paragraph?: Such bare "%" signs are for user interface convenience, and must be turned into properly escaped characters ("%25" encodes "%" in URIs) before the URI is used in any protocol. > Since we do say that URIs with ZoneIDs are meaningless outside the > originating host, that would mean they shouldn't be included in HTML > documents IMHO. But I think somebody needs to rewrite RFC 3986. There's been some noise about that, both within and without the IETF. Barry