From nobody Thu Jul 23 13:59:34 2020 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524F63A0D9C; Thu, 23 Jul 2020 13:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYksdYqRzn7M; Thu, 23 Jul 2020 13:59:29 -0700 (PDT) Received: from mail-io1-f51.google.com (mail-io1-f51.google.com [209.85.166.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7C623A0D9B; Thu, 23 Jul 2020 13:59:26 -0700 (PDT) Received: by mail-io1-f51.google.com with SMTP id d18so7755481ion.0; Thu, 23 Jul 2020 13:59:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=6gSISFNiAdy0FzyY9J1WkOH6vbajVv8I2CTcTVzaANA=; b=ju2e0eOL6bjC5kijQVAIlCOhDfrDEse7qxbv/CA7NHyESdQ2z9LjSU0/7KtQqk+nK/ G8z6dmHofhC2dBoskJwMqUZJu87bPGQIstthfw4K0Yrqod7vTPeNxyzCAz26yla16tUi 1Tgk5LEwtKm2znWDNbr2EaW3XHXEyauXGKijdQPDrpdXB9frZPZ3v/zmA9WwMc7nhPGV jgtbR/ar4sAmKFoBAFEE9l/X6fmzZSRGWxQpEkxy6pQz3tcbIE0MXLTZB5WdUXBZrtpY UFU5Ucz6I9fctRxkb0cyfGwjbDnGCl+bU32Bqvh81wDOzOY+PsQVgAGNo0JbsrRzPIla maFA== X-Gm-Message-State: AOAM531Htzb0eKqu91LSrNmt5wKqs2l8hcmHYnAmvZzHTf7gFmKQK+wk tuAsqgQUQK5BAgqnFJkjMMj/tt5LuDPgLBo3Sh1/4w== X-Google-Smtp-Source: ABdhPJwFaIlDSiE7AzoBEsBc1lyQjHVIrYzYuG5mbt1qr74Hh3c7rnzOugEJIJoe2BgzybHV1+r4MkINDqAWFZZ9U9A= X-Received: by 2002:a5e:8f4b:: with SMTP id x11mr6564716iop.90.1595537965473; Thu, 23 Jul 2020 13:59:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Barry Leiba Date: Thu, 23 Jul 2020 16:59:14 -0400 Message-ID: To: "draft-ietf-cdni-uri-signing.all@ietf.org" Cc: "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [CDNi] AD review of draft-ietf-cdni-uri-signing-19 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2020 20:59:32 -0000 What's the status of this document? It's been about four months since my AD review, in "revised I-D needed" substate. Barry On Fri, Mar 13, 2020 at 1:05 AM Barry Leiba wrote= : > > Here is my AD review of draft-ietf-cdni-uri-signing-19. My apologies for= taking a couple of weeks to get to this: the IESG has, as you can imagine,= been swamped with both heavy telechat schedules because of the impending A= D changeover and unexpected craziness with IETF 107 planning and decisions = related to the meeting cancellation. > > Kevin, thanks so much for a very thorough and excellent shepherd writeup! > > A couple of these comments are substantive, so I would like to discuss an= d resolve them before last call. I=E2=80=99m going to set the draft=E2=80= =99s substate to =E2=80=9Crevised I-D needed=E2=80=9D. > > Please expand =E2=80=9CCDNI=E2=80=9D in the abstract... and possibly in t= he title as well, though you could wait for the RPC to do that if you prefe= r. Please also fully expand =E2=80=9CCDN=E2=80=9D on its first use in the = introduction. > > Please replace =E2=80=9CUA=E2=80=9D in the abstract with =E2=80=9Cuser ag= ent=E2=80=9D. > > This document uses the terminology defined in the CDNI Problem > Statement [RFC6707]. > > I believe that terminology definitions are normative references, so I bel= ieve this makes 6707 normative. Happily, normative downrefs such as this a= re accepted now, so please make the reference normative and I will make sur= e it=E2=80=99s called out in the last call notice. > > =E2=80=94 Section 1.3 =E2=80=94 > > With symmetric keys, the same key is > used by both the signing entity for signing the URI as well as by the > verifying entity for verifying the Signed URI. > > Nit: Think of =E2=80=9Cboth=E2=80=9D as an open parenthesis (and the end = of he sentence as the closing one here). The first =E2=80=9Cby=E2=80=9D is= outside the parens (before =E2=80=9Cboth=E2=80=9D), but the second is insi= de, and that=E2=80=99s not parallel. Make it either =E2=80=9Cby both the s= igning entity [...] and the verifying entity=E2=80=9D or =E2=80=9Cboth by t= he signing entity [...] and by the verifying entity=E2=80=9D. > > distributed openly (because they cannot be used to sign URIs) and > private keys are kept secret by the URI signer. > > I would say =E2=80=9Cand the corresponding private keys=E2=80=9D. > > =E2=80=94 Section 1.4 =E2=80=94 > > While the URI signing method defined in this document was primarily > created for the purpose of allowing URI Signing in CDNI scenarios, > i.e., between a uCDN and a dCDN, there is nothing in the defined URI > Signing method that precludes it from being used in a non-CDNI > > As you see here, you capitalize =E2=80=9CURI Signing=E2=80=9D inconsisten= tly,even in this one paragraph. Please check the document for consistency = in the capitalization: pick one and use it throughout. > > =E2=80=94 Section 2 =E2=80=94 > > HTTP or HTTPS URI [RFC7230] (Section 2.7). > > This is a quirk of the tools and not a fault in the draft, but this resul= ts in the html version having a clickable link to RFC 7230, and then anothe= r clickable link to Section 2.7 of this document (which, of course, isn=E2= =80=99t there). I think if you change this to =E2=80=9CHTTP or HTTPS URI (= see [RFC7230] Section 2.7)=E2=80=9D the generated link will work better. > > o a reserved character (as defined in [RFC3986] Section 2.2), > > Any reserved character? And the three reserved characters in bullets 1, = 3, and 5 can be any three different ones? I think I know what you mean, bu= t it seems that an implementer who doesn=E2=80=99t could go quite wrong. M= aybe some more words along with these bullets would be better? > > [For example, in the URI < http://example.com/content?sign=3Djwtdatahere&= other >, I think that if I strictly implement what you have here I would in= terpret =E2=80=9Cexample.com/=E2=80=9D as the attribute name (because =E2= =80=9C/=E2=80=9C is a reserved character), =E2=80=9Ccontent=E2=80=9D as the= JWT package, and =E2=80=9C?=E2=80=9D as the terminating special character.= But you=E2=80=99re looking for something more like =E2=80=9Csign=E2=80=9D= as the attribute name and =E2=80=9Cjwtdatahere=E2=80=9D as the JWT package= , yes?] > > Also, I don=E2=80=99t see any examples in the draft of a Signed URI, and = I think an example or two here of a couple of variations would also help. > > =E2=80=94 Section 2.1 =E2=80=94 > Several of the subsections that deal with time values repeat this text ex= actly: > > Note: The time > on the entities that generate and verify the signed URI SHOULD be in > sync. In the CDNI case, this means that CSP, uCDN, and dCDN servers > need to be time-synchronized. It is RECOMMENDED to use NTP [RFC5905] > for time synchronization. > > I suggest cleaning this up by moving that note up here to the end of Sect= ion 2.1, saying, =E2=80=9CNote: When claims related to time are used, the t= ime on the entities...=E2=80=9D > > =E2=80=94 Section 2.1.7 =E2=80=94 > > previously seen the nonce used in a request for the same content > > This is the only spot where you don=E2=80=99t capitalize =E2=80=9CNonce= =E2=80=9D. > > =E2=80=94 Section 2.1.9 =E2=80=94 > > This claim MUST be understood and processed by > all implementations. > > Section 2.1 already said this about all claims, so why say it here about = this one in particular? > > =E2=80=94 Section 2.1.10 =E2=80=94 > > Client IP (cdniip) [optional] - The Client IP (cdniip) claim hold an > > Nit: =E2=80=9Cholds=E2=80=9D > > =E2=80=94 Section 2.1.15 =E2=80=94 > > The URI Container (cdniuc) claim takes one of the following forms > > This is the only claim definition that doesn=E2=80=99t say =E2=80=9C[opti= onal]=E2=80=9D. Should it? > > =E2=80=94 Section 3.2 =E2=80=94 > > the following section defines a mechanism using HTTP Cookies > > Please use a specific section xref instead. > > =E2=80=94 Section 6.7 =E2=80=94 > Thanks for including advice to the experts. > > Expert Reviewers should be empowered to pass judgements > as they see fit > > This is very vague and, to me, implies more capriciousness than I think y= ou really intend. Can you come up with another way to word this that gives= a bit more guidance? What sorts of judgments are they likely to make? > > =E2=80=94 Section 7 =E2=80=94 > > seconds to prevent a sudden network issues from denying legitimate > > Nit: either remove =E2=80=9Ca=E2=80=9D or make it =E2=80=9Cissue=E2=80=9D= . > > =E2=80=94 > Barry > From nobody Thu Jul 23 14:02:47 2020 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77EDB3A0DE3; Thu, 23 Jul 2020 14:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMfHt95QUxS5; Thu, 23 Jul 2020 14:02:38 -0700 (PDT) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C92C3A0DE4; Thu, 23 Jul 2020 14:02:37 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 06NKrV8Y059247; Thu, 23 Jul 2020 14:02:36 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=XVSxGTrWTIMzH+tATcbKnd/uVsK9LuplhNI1I7Sls0Y=; b=mgNJ2wG4Nnt9Syu/9nWZEZm6deG+8qmeFk+1f0U5udCHxsz7/y330LC5QNuNFtmOAqI2 xPY5+ttri/pVwy+1AbkGi3yuk1KsicR4oUmEeibzsWo8jlHLjD5YYoXPz/gH0b3cdo1+ v6sqqAL320u1fdEP9wmO597MJNq+Dn0BD9hvMDqcxyPXFwnjAtTQm92VG0H2CfxYJ8Wr ZNVZVL9bjkZ/9HA1IJ2QwbuH9t8yU1WpaTwuBoxt3QM9TIQk503IrgepnXcBIsHfJOUd YjIsuxOJefXVcmZPGJxHWwmb1FwZ0r7owXdSugeSB8fiQa4FKeOOzQwwltI9jlmsbtJl cQ== Received: from ma-mailsvcp-mta-lapp01.corp.apple.com (ma-mailsvcp-mta-lapp01.corp.apple.com [10.226.18.133]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 32byr43b8e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 23 Jul 2020 14:02:36 -0700 Received: from ma-mailsvcp-mmp-lapp02.apple.com (ma-mailsvcp-mmp-lapp02.apple.com [17.32.222.15]) by ma-mailsvcp-mta-lapp01.corp.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QDX00ZGLX4C8B20@ma-mailsvcp-mta-lapp01.corp.apple.com>; Thu, 23 Jul 2020 14:02:36 -0700 (PDT) Received: from process_milters-daemon.ma-mailsvcp-mmp-lapp02.apple.com by ma-mailsvcp-mmp-lapp02.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QDX00700WRFS500@ma-mailsvcp-mmp-lapp02.apple.com>; Thu, 23 Jul 2020 14:02:36 -0700 (PDT) X-Va-A: X-Va-T-CD: 5e0758ac758adaea6a44b8b32ea89e72 X-Va-E-CD: 996e75b414d13ba3b8e0002b1fe3be0d X-Va-R-CD: 4e45050f1583f837acc5d0335f88301e X-Va-CD: 0 X-Va-ID: c62fd9b7-02c1-4a24-b248-dea19ce8bb0f X-V-A: X-V-T-CD: 5e0758ac758adaea6a44b8b32ea89e72 X-V-E-CD: 996e75b414d13ba3b8e0002b1fe3be0d X-V-R-CD: 4e45050f1583f837acc5d0335f88301e X-V-CD: 0 X-V-ID: 6adc24ed-d551-438b-9acf-7040b73e3435 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-23_09:2020-07-23, 2020-07-23 signatures=0 Received: from [17.235.117.76] (unknown [17.235.117.76]) by ma-mailsvcp-mmp-lapp02.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QDX00C6CX4A6A00@ma-mailsvcp-mmp-lapp02.apple.com>; Thu, 23 Jul 2020 14:02:36 -0700 (PDT) From: Phil Sorber Message-id: <22DF373A-A2C4-447B-AD47-30CD04476245@apple.com> Content-type: multipart/signed; boundary="Apple-Mail=_811DC638-8631-4EFB-B4C9-E4282B1DC540"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 23 Jul 2020 15:02:33 -0600 In-reply-to: Cc: "draft-ietf-cdni-uri-signing.all@ietf.org" , "" To: Barry Leiba References: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-23_09:2020-07-23, 2020-07-23 signatures=0 Archived-At: Subject: Re: [CDNi] AD review of draft-ietf-cdni-uri-signing-19 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2020 21:02:46 -0000 --Apple-Mail=_811DC638-8631-4EFB-B4C9-E4282B1DC540 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Sorry for the long delay. I started working through your requested = changes, but haven=E2=80=99t had time to finish. Things have been a = little weird=E2=80=A6 Thank you for following up. I will try to get back to this very shortly. Thanks. > On Jul 23, 2020, at 14:59, Barry Leiba = wrote: >=20 > What's the status of this document? It's been about four months since > my AD review, in "revised I-D needed" substate. >=20 > Barry >=20 > On Fri, Mar 13, 2020 at 1:05 AM Barry Leiba = wrote: >>=20 >> Here is my AD review of draft-ietf-cdni-uri-signing-19. My apologies = for taking a couple of weeks to get to this: the IESG has, as you can = imagine, been swamped with both heavy telechat schedules because of the = impending AD changeover and unexpected craziness with IETF 107 planning = and decisions related to the meeting cancellation. >>=20 >> Kevin, thanks so much for a very thorough and excellent shepherd = writeup! >>=20 >> A couple of these comments are substantive, so I would like to = discuss and resolve them before last call. I=E2=80=99m going to set the = draft=E2=80=99s substate to =E2=80=9Crevised I-D needed=E2=80=9D. >>=20 >> Please expand =E2=80=9CCDNI=E2=80=9D in the abstract... and possibly = in the title as well, though you could wait for the RPC to do that if = you prefer. Please also fully expand =E2=80=9CCDN=E2=80=9D on its first = use in the introduction. >>=20 >> Please replace =E2=80=9CUA=E2=80=9D in the abstract with =E2=80=9Cuser = agent=E2=80=9D. >>=20 >> This document uses the terminology defined in the CDNI Problem >> Statement [RFC6707]. >>=20 >> I believe that terminology definitions are normative references, so I = believe this makes 6707 normative. Happily, normative downrefs such as = this are accepted now, so please make the reference normative and I will = make sure it=E2=80=99s called out in the last call notice. >>=20 >> =E2=80=94 Section 1.3 =E2=80=94 >>=20 >> With symmetric keys, the same key is >> used by both the signing entity for signing the URI as well as by = the >> verifying entity for verifying the Signed URI. >>=20 >> Nit: Think of =E2=80=9Cboth=E2=80=9D as an open parenthesis (and the = end of he sentence as the closing one here). The first =E2=80=9Cby=E2=80=9D= is outside the parens (before =E2=80=9Cboth=E2=80=9D), but the second = is inside, and that=E2=80=99s not parallel. Make it either =E2=80=9Cby = both the signing entity [...] and the verifying entity=E2=80=9D or = =E2=80=9Cboth by the signing entity [...] and by the verifying = entity=E2=80=9D. >>=20 >> distributed openly (because they cannot be used to sign URIs) and >> private keys are kept secret by the URI signer. >>=20 >> I would say =E2=80=9Cand the corresponding private keys=E2=80=9D. >>=20 >> =E2=80=94 Section 1.4 =E2=80=94 >>=20 >> While the URI signing method defined in this document was primarily >> created for the purpose of allowing URI Signing in CDNI scenarios, >> i.e., between a uCDN and a dCDN, there is nothing in the defined = URI >> Signing method that precludes it from being used in a non-CDNI >>=20 >> As you see here, you capitalize =E2=80=9CURI Signing=E2=80=9D = inconsistently,even in this one paragraph. Please check the document = for consistency in the capitalization: pick one and use it throughout. >>=20 >> =E2=80=94 Section 2 =E2=80=94 >>=20 >> HTTP or HTTPS URI [RFC7230] (Section 2.7). >>=20 >> This is a quirk of the tools and not a fault in the draft, but this = results in the html version having a clickable link to RFC 7230, and = then another clickable link to Section 2.7 of this document (which, of = course, isn=E2=80=99t there). I think if you change this to =E2=80=9CHTTP= or HTTPS URI (see [RFC7230] Section 2.7)=E2=80=9D the generated link = will work better. >>=20 >> o a reserved character (as defined in [RFC3986] Section 2.2), >>=20 >> Any reserved character? And the three reserved characters in bullets = 1, 3, and 5 can be any three different ones? I think I know what you = mean, but it seems that an implementer who doesn=E2=80=99t could go = quite wrong. Maybe some more words along with these bullets would be = better? >>=20 >> [For example, in the URI < = http://example.com/content?sign=3Djwtdatahere&other >, I think that if I = strictly implement what you have here I would interpret = =E2=80=9Cexample.com/=E2=80=9D as the attribute name (because =E2=80=9C/=E2= =80=9C is a reserved character), =E2=80=9Ccontent=E2=80=9D as the JWT = package, and =E2=80=9C?=E2=80=9D as the terminating special character. = But you=E2=80=99re looking for something more like =E2=80=9Csign=E2=80=9D = as the attribute name and =E2=80=9Cjwtdatahere=E2=80=9D as the JWT = package, yes?] >>=20 >> Also, I don=E2=80=99t see any examples in the draft of a Signed URI, = and I think an example or two here of a couple of variations would also = help. >>=20 >> =E2=80=94 Section 2.1 =E2=80=94 >> Several of the subsections that deal with time values repeat this = text exactly: >>=20 >> Note: The time >> on the entities that generate and verify the signed URI SHOULD be = in >> sync. In the CDNI case, this means that CSP, uCDN, and dCDN = servers >> need to be time-synchronized. It is RECOMMENDED to use NTP = [RFC5905] >> for time synchronization. >>=20 >> I suggest cleaning this up by moving that note up here to the end of = Section 2.1, saying, =E2=80=9CNote: When claims related to time are = used, the time on the entities...=E2=80=9D >>=20 >> =E2=80=94 Section 2.1.7 =E2=80=94 >>=20 >> previously seen the nonce used in a request for the same content >>=20 >> This is the only spot where you don=E2=80=99t capitalize =E2=80=9CNonce= =E2=80=9D. >>=20 >> =E2=80=94 Section 2.1.9 =E2=80=94 >>=20 >> This claim MUST be understood and processed by >> all implementations. >>=20 >> Section 2.1 already said this about all claims, so why say it here = about this one in particular? >>=20 >> =E2=80=94 Section 2.1.10 =E2=80=94 >>=20 >> Client IP (cdniip) [optional] - The Client IP (cdniip) claim hold = an >>=20 >> Nit: =E2=80=9Cholds=E2=80=9D >>=20 >> =E2=80=94 Section 2.1.15 =E2=80=94 >>=20 >> The URI Container (cdniuc) claim takes one of the following forms >>=20 >> This is the only claim definition that doesn=E2=80=99t say = =E2=80=9C[optional]=E2=80=9D. Should it? >>=20 >> =E2=80=94 Section 3.2 =E2=80=94 >>=20 >> the following section defines a mechanism using HTTP Cookies >>=20 >> Please use a specific section xref instead. >>=20 >> =E2=80=94 Section 6.7 =E2=80=94 >> Thanks for including advice to the experts. >>=20 >> Expert Reviewers should be empowered to pass judgements >> as they see fit >>=20 >> This is very vague and, to me, implies more capriciousness than I = think you really intend. Can you come up with another way to word this = that gives a bit more guidance? What sorts of judgments are they likely = to make? >>=20 >> =E2=80=94 Section 7 =E2=80=94 >>=20 >> seconds to prevent a sudden network issues from denying = legitimate >>=20 >> Nit: either remove =E2=80=9Ca=E2=80=9D or make it =E2=80=9Cissue=E2=80=9D= --Apple-Mail=_811DC638-8631-4EFB-B4C9-E4282B1DC540 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCr0w ggUDMIID66ADAgECAhEAy3lRP99aQbfro7UBLGZXYjANBgkqhkiG9w0BAQsFADB7MQswCQYDVQQG EwJHQjEbMBkGA1UECAwSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHDAdTYWxmb3JkMRowGAYD VQQKDBFDb21vZG8gQ0EgTGltaXRlZDEhMB8GA1UEAwwYQUFBIENlcnRpZmljYXRlIFNlcnZpY2Vz MB4XDTE5MDYxOTAwMDAwMFoXDTI4MTIwNjIzNTk1OVowZDErMCkGA1UEAxMiQXBwbGUgUHVibGlj IENsaWVudCBSU0EgQ0EgMTIgLSBHMTETMBEGA1UEChMKQXBwbGUgSW5jLjETMBEGA1UECBMKQ2Fs aWZvcm5pYTELMAkGA1UEBhMCVVMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCbf0jn uJGzhprmtORPy/bloyljfCVgmgRD5LZ/8VYe5NUAYPdxlVCKdUsQ+ehzxvc/6F+sXPHSMOXocLLt BrRrp6mu5d85FdAPT9DZjQx0ZhojAmo3YKU+xr2ogK0npEoUWOdL2IzMOirzR8nSwKdjwcUGVMnX 4EkKwvYUfuSogNU+5Eah1wTyq/94hH5RLAcRjSKHq9ZYezX/7BcXfnB3ANr+YOiy2HGv3Lecr/bw Gccv4H8odWTx1GuKbVzmKg7+Dyy3rL1/PceB6n6wSkyHnU2RQVfChWWy7dpk6WP3Qy/Kc+r5dkP5 t+5zpInAEfxGTUzFAGXlo8yuQcidQ/XbAgMBAAGjggGXMIIBkzAfBgNVHSMEGDAWgBSgEQojPpbx B+zirynvgqV/0DCktDAdBgNVHQ4EFgQUygbwkhI9ewBa6ShHqCUb8NCAQswwDgYDVR0PAQH/BAQD AgGGMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3 Y2QFCwUBMA0GCyqGSIb3Y2QFCwUCMA0GCyqGSIb3Y2QFCwUDMA0GCyqGSIb3Y2QFCwUEMA0GCyqG SIb3Y2QFCwUFMA0GCyqGSIb3Y2QFCwUGMA0GCyqGSIb3Y2QFCwUHMA0GCyqGSIb3Y2QFCwUIMA0G CyqGSIb3Y2QFCwUJMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDov L2NybC5jb21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNAYIKwYBBQUHAQEE KDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQELBQAD ggEBAFW7Jbmf/YBRe14h6FNx8D8AQ0ownBmm9+K1PAg4+KfaLLLCjFj966VPuUSnx4mjemqws3x1 rGo6N0L5z+zAwo3r91w9Uq1R+CG3fGArN+7M7CVDcBUkC0K1rmyEKjlKDjPEp2C5DmhpS/LomA2t DMsCjj6nTdh82kl0PuJ6clDWB8w/WBdWKZE0ADtCFGpmELAtV2Ky7d70DuRFhp+uMrg/n+38bMy7 ViYSgwOBnOPXKGZ7A2+o6p+iuZ+P34vL5PD4qZtYLL+3LpnpsPB3FhygbCAILm+/XQefC6yKp/u0 htu9KvCQ+V2FlnzEQN8gvA4tQfF3OegrSZl7SUL5qsowggWyMIIEmqADAgECAhB49rvzdbQNpLGp IJ9G80i4MA0GCSqGSIb3DQEBCwUAMGQxKzApBgNVBAMTIkFwcGxlIFB1YmxpYyBDbGllbnQgUlNB IENBIDEyIC0gRzExEzARBgNVBAoTCkFwcGxlIEluYy4xEzARBgNVBAgTCkNhbGlmb3JuaWExCzAJ BgNVBAYTAlVTMB4XDTE5MTEwMTE2MjMxNVoXDTIyMTEzMDE2MjMxNVowUjEZMBcGA1UEAwwQc29y YmVyQGFwcGxlLmNvbTETMBEGA1UEChMKQXBwbGUgSW5jLjETMBEGA1UECBMKQ2FsaWZvcm5pYTEL MAkGA1UEBhMCVVMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC/TGOX6yMa9+iBGWtB 3jflg656S5evO8YudZqxKgoOhgGHOGfHVEmVNKoVQhaX3jZR3ROnVcaRYlDYc0IJ2l6FB3e0bP1c 4mwkZ+LaDanTj9BPspI09StsXy+0CtuKz50piSzveL/FgqyPtnvUZYIOXLRUJoasAJZaFZ3gtjjE O0sGs6UcfJnr+orAZGVAmMmL9itoTq8lAnI/shU48YRkt2Xn6D+jpooDAf23AXObBDnG2E8VRFFP xLe1aCQfndpyxYEFmuC8GzVMbecXowBDwGC3W0D64oHXeVLFccFZKowWDJoFBHR9YNDQnMtABMWp zJ0LUAsw1aZlT9hGJgujAgMBAAGjggJwMIICbDAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaAFMoG 8JISPXsAWukoR6glG/DQgELMMHgGCCsGAQUFBwEBBGwwajAxBggrBgEFBQcwAoYlaHR0cDovL2Nl cnRzLmFwcGxlLmNvbS9hcGNyc2ExMmcxLmRlcjA1BggrBgEFBQcwAYYpaHR0cDovL29jc3AuYXBw bGUuY29tL29jc3AwMy1hcGNyc2ExMmcxMDEwGwYDVR0RBBQwEoEQc29yYmVyQGFwcGxlLmNvbTCC ASgGA1UdIASCAR8wggEbMIIBFwYLKoZIhvdjZAULBQEwggEGMDcGCCsGAQUFBwIBFitodHRwczov L3d3dy5hcHBsZS5jb20vY2VydGlmaWNhdGVhdXRob3JpdHkvMIHKBggrBgEFBQcCAjCBvQyBulJl bGlhbmNlIG9uIHRoaXMgY2VydGlmaWNhdGUgYXNzdW1lcyBhY2NlcHRhbmNlIG9mIGFueSBhcHBs aWNhYmxlIHRlcm1zIG9mIHVzZSBhbmQgY2VydGlmaWNhdGlvbiBwcmFjdGljZSBzdGF0ZW1lbnRz LiBUaGlzIGNlcnRpZmljYXRlIHNoYWxsIG5vdCBzZXJ2ZSBhcywgb3IgcmVwbGFjZSBhIHdyaXR0 ZW4gc2lnbmF0dXJlLjATBgNVHSUEDDAKBggrBgEFBQcDBDA0BgNVHR8ELTArMCmgJ6AlhiNodHRw Oi8vY3JsLmFwcGxlLmNvbS9hcGNyc2ExMmcxLmNybDAdBgNVHQ4EFgQUMxxwc4gpE6zCrtnlAgDr ojqZsAswDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4IBAQA9HIkV1sBJpMXauHMA8jHq i8VkeKHKkRrpQZpwkpppO1ybvm2QZTU1mFsVt+ZMqiDp7Y/HIPeW4dwb9sfpkUNRwAkxSbSyJl4O wQuG/JKf0FSPNX49/VOaFvbcLexWtUuY/xyEbirnlcgougZylGvwi3+wdqMKoHh4oytZ/gbA78Dp 6ZY/pLgamW/lHl+HhBVWVkHKMzMC/xDn1Vin/B6JU/U/Vvk5JK7wOEBgtcxz3KNnPVX1Zfdia6Gz MQqDIeSoS+LV0XT01XAMDtsnjgF02xfsmCh67gDPcBQ0SFakMyI5BL3qdLNkWVP92rS00pcOT2DX Q6pNR1hbCFliqh/sMYIDJjCCAyICAQEweDBkMSswKQYDVQQDEyJBcHBsZSBQdWJsaWMgQ2xpZW50 IFJTQSBDQSAxMiAtIEcxMRMwEQYDVQQKEwpBcHBsZSBJbmMuMRMwEQYDVQQIEwpDYWxpZm9ybmlh MQswCQYDVQQGEwJVUwIQePa783W0DaSxqSCfRvNIuDANBglghkgBZQMEAgEFAKCCAX8wGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNzIzMjEwMjMzWjAvBgkqhkiG 9w0BCQQxIgQgJ4Rxjc/wMeD8PIbNMQGVjNfnK2mDsOFxQ9msWjgmuwwwgYcGCSsGAQQBgjcQBDF6 MHgwZDErMCkGA1UEAxMiQXBwbGUgUHVibGljIENsaWVudCBSU0EgQ0EgMTIgLSBHMTETMBEGA1UE ChMKQXBwbGUgSW5jLjETMBEGA1UECBMKQ2FsaWZvcm5pYTELMAkGA1UEBhMCVVMCEHj2u/N1tA2k sakgn0bzSLgwgYkGCyqGSIb3DQEJEAILMXqgeDBkMSswKQYDVQQDEyJBcHBsZSBQdWJsaWMgQ2xp ZW50IFJTQSBDQSAxMiAtIEcxMRMwEQYDVQQKEwpBcHBsZSBJbmMuMRMwEQYDVQQIEwpDYWxpZm9y bmlhMQswCQYDVQQGEwJVUwIQePa783W0DaSxqSCfRvNIuDANBgkqhkiG9w0BAQEFAASCAQAK1XyO RY9ePE3Ak5ihVtgkWeXP33fnOa/fb2STwKOyPm2kk08qqHgpNLiEjfCsyfBefDdbOKnCINZdrPDB zhUPuaPRwmb3gEVRKaV/Pg1p8wZhdz6G3vPMNDzqHGRxlTxlsBE/pu6fuC3WYCPhZLx19UtctAUv lRkrXnb8kFqd6eFk22+1h9Y5aYqUynqEh0II93R4sjGROAlKPzJznws/RTfG5YZbqDXfvq/WXgbB VVhbsRtfOteP3/X6/XFsAHrdKXTgH+9d33aOSl6NgBlBgGQsSdBN/r8ZEqNcer9jhN6W9U5/KlV+ LozX+ITKkhdNMLMJx4+crkoIAM863F50AAAAAAAA --Apple-Mail=_811DC638-8631-4EFB-B4C9-E4282B1DC540--