Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBA3130E3C for ; Tue, 26 Jun 2018 14:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.081 X-Spam-Level: X-Spam-Status: No, score=0.081 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 SC4G1UED2_uE for ; Tue, 26 Jun 2018 14:25:51 -0700 (PDT) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (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 32393130E40 for ; Tue, 26 Jun 2018 14:25:48 -0700 (PDT) Received: by mail-yb0-x230.google.com with SMTP id x15-v6so3902823ybm.2 for ; Tue, 26 Jun 2018 14:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eZ+shD6W2hfgrBNJlP4V4eT6FLHRwWuCc/WEv1aTZJs=; b=qHSTtOlhWChtzzMcxiL29+X5OPgJoIx5xPZxOL9waTK7Vi0jyh4xstPJgpYoQjwvmT bOfF+QjrLyk+7LWfWco4qdZNYZAsl2wfgvoYSRB3xIZ4oS65yoDpuQdRsoorVVUqCP8O KeA/fWyAML8G7Jo/J8PQSQookGjgdV7MnVbO9/M918cuzywl+ny4qmcyDFAmZHIXtrjs WGi2WodRugr3KeSo3N+4PPfzOjQoSbBMzFnex16RfIOL/e+8HT48GobL6UuZOtb0+6uN Lkb3zUdCEjVLJEGnVhGOWVqJGqcjrtM9zUYx/h+U6vqqw5clo6Q3XRrzymPShBdgEtFf 6goA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eZ+shD6W2hfgrBNJlP4V4eT6FLHRwWuCc/WEv1aTZJs=; b=rrSKrkgP2GieSJmyVH8BhUDyF+B0ss8k4pDp0m9i/mP0mtINE8Sr9U7ET343GnFbj8 Za2L4nBWHegKxe7/xt+lycEWbtdBYqvdJCvNXiLjxn0Wskrm+0jfN3oyRU6c+la7RyJu ChbQj+FgpPEhN6Z38/wMaQUwdDj+isNjsSX9wWM00oxrSlhHEVAAb6K60JhSXhPd7LzS 5SKsR4xyZCnSQqQwNf7oX0vm6eU8qLUefIFMobKVAspIR9+oBI/hObNb40Pc8Tzw/8kN zlcahPEm6InZ59zhZvryL/LjPw6WryuJqEIrr33z7vjUFYAPeDmNh8LTMWG52vcHPGFj CV/Q== X-Gm-Message-State: APt69E2DlSF37VWs4ZHBRfjDiwQfhjhnoMOQZB5VMa5H2IZNKoxfnmtb BXQqCvMozM9dKHO+sDde3cN1liHEBgb+y8W5HBbTCA== X-Google-Smtp-Source: ADUXVKJjbLoShFjDqq7bvOy/G5aJ2Ppwpp52bFaU1TYuShngXTeILEuyoabMSsAjp/g5tyrnCszb0NKvGP7IO0dK50c= X-Received: by 2002:a25:7c4:: with SMTP id 187-v6mr1798957ybh.73.1530048347313; Tue, 26 Jun 2018 14:25:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:613:0:0:0:0:0 with HTTP; Tue, 26 Jun 2018 14:25:06 -0700 (PDT) In-Reply-To: References: <152589833077.4037.7403393365772291429.idtracker@ietfa.amsl.com> <94E6261D-7920-4C65-BDB3-A0B3144323C5@nostrum.com> <097D19CC-EAB7-4F9F-98C4-B4030B838464@nostrum.com> From: Eric Rescorla Date: Tue, 26 Jun 2018 14:25:06 -0700 Message-ID: To: Andrei Popov Cc: John Bradley , Ben Campbell , Dirk Balfanz , "draft-ietf-tokbind-https@ietf.org" , Tokbind WG , IESG , "tokbind-chairs@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003b2f85056f922497" Archived-At: Subject: Re: [Unbearable] Ben Campbell's Discuss on draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 21:25:55 -0000 --0000000000003b2f85056f922497 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Should be, I need to do a double check to make sure other comments were dealt with, but assuming so, then yes. Should be able to do this tomorrow -Ekr On Tue, Jun 26, 2018 at 2:19 PM, Andrei Popov wrote: > Done: https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/. > > > > *From:* John Bradley > *Sent:* Tuesday, June 26, 2018 2:14 PM > *To:* Ben Campbell > *Cc:* Andrei Popov ; Eric Rescorla < > ekr@rtfm.com>; Dirk Balfanz ; > draft-ietf-tokbind-https@ietf.org; Tokbind WG ; IESG > ; tokbind-chairs@ietf.org > > *Subject:* Re: [Unbearable] Ben Campbell's Discuss on > draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT) > > > > PS I suppose we need DIRK OR Andre to push a version with the changes. > > > > John B. > > On Tue, Jun 26, 2018, 5:12 PM John Bradley wrote: > > Thanks Ben. > > > > EKR once this Discuss is cleared are we good to move on to the final > embrace of the RFC editor? > > > > Regards > > John B. > > > > On Tue, Jun 26, 2018, 2:58 PM Ben Campbell wrote: > > > > > On Jun 26, 2018, at 1:54 PM, Andrei Popov > wrote: > > > > Hi Ben, > > > > Thanks for the review. > > > >> Are the =E2=80=9Capplications=E2=80=9D from paragraph 3 the same as th= ose from > paragraph 2? > > > > Yes, the same throughout paragraphs 1, 2 and 3. > > > >> It seems like paragraph 2 is talking more about local APIs (at least, = I > see that was mentioned in the text in version 17 but not in 18), but > paragraph 3 uses an example of a signal from a server. (I can accept that > the difference in control may be weak enough for web applications that th= e > distinction does not matter.) > > > > The APIs provided by the TB implementation and called by the applicatio= n > are local APIs. > > The application needs to make a decision whether to request that the TB > implementation include a Referred binding in the TB message or not. > > In the example, the server provides a signal to the application using > the Include-Referred-Token-Binding-ID HTTP response header. > > The signal could be different, or an application may have out-of-band > ways to determine this (e.g. a local database of RP->IDP associations). > > I just re-read the 3rd paragraph, and I think I missed the =E2=80=9Cthen= =E2=80=9D in > =E2=80=9Cwhich then signals=E2=80=9D on the first reading. It=E2=80=99s f= ine as is. > > Thanks! > > Ben. > > > > > Cheers, > > > > Andrei > > > > -----Original Message----- > > From: Ben Campbell > > Sent: Tuesday, June 26, 2018 11:41 AM > > To: Eric Rescorla > > Cc: Dirk Balfanz ; > draft-ietf-tokbind-https@ietf.org; Tokbind WG ; The > IESG ; John Bradley ; > tokbind-chairs@ietf.org > > Subject: Re: [Unbearable] Ben Campbell's Discuss on > draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT) > > > > Hi, thanks for the pointer. > > > > The text in version 18 is sufficient to clear my discuss. I have one > remaining (or maybe new) non-blocking question for section 6: > > > > Are the =E2=80=9Capplications=E2=80=9D from paragraph 3 the same as tho= se from paragraph > 2? It seems like paragraph 2 is talking more about local APIs (at least, = I > see that was mentioned in the text in version 17 but not in 18), but > paragraph 3 uses an example of a signal from a server. (I can accept that > the difference in control may be weak enough for web applications that th= e > distinction does not matter.) > > > > I did not check my editorial comments. > > > > Thanks! > > > > Ben. > > > >> On Jun 25, 2018, at 6:30 PM, Eric Rescorla wrote: > >> > >> Ben, > >> > >> Does the following new text address your concern: > >> https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?modeAsFormat=3Dhtml= /a > > >> scii&url=3Dhttps://raw.githubusercontent.com/TokenBinding/Internet-Dra= ft > > >> s/master/draft-ietf-tokbind-https-18.xml > >> > >> > >> On Mon, Jun 4, 2018 at 1:26 PM, Dirk Balfanz 40google..com@dmarc.ietf.org> wrote: > >> Hi Ben, > >> > >> thanks for the feedback. Most of it is addressed in the new draft ( > https://tools.ietf.org/html/draft-ietf-tokbind-https-16 > ). > See below (inline) for details. > >> > >> On Wed, May 9, 2018 at 1:38 PM Ben Campbell wrote: > >> Ben Campbell has entered the following ballot position for > >> draft-ietf-tokbind-https-14: Discuss > >> > >> When responding, please keep the subject line intact and reply to all > >> email addresses included in the To and CC lines. (Feel free to cut > >> this introductory paragraph, however.) > >> > >> > >> Please refer to > >> https://www.ietf.org/iesg/statement/discuss-criteria.html > > >> for more information about IESG DISCUSS and COMMENT positions. > >> > >> > >> The document, along with other ballot positions, can be found here: > >> https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ > > >> > >> > >> > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> I plan to ballot "YES", but I want to clear up once concern first: > >> > >> After reading section 6 several times, I don't know what it means. I > >> think it's [...] > >> > >> Addressed in new draft. > >> > >> > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> Substantive Comments: > >> > >> =C2=A71.1: Please consider using the boilerplate from 8174 across the > >> cluster. Both this and the protocol draft have lower case keyword > instances. > >> > >> Addressed in new draft. > >> > >> > >> =C2=A78.2: > >> - Does it really make sense to wait for a user to request the keys be > expired? > >> I suspect the average user does this about never. Did the working > >> group discuss possibly making the keys default to expiring after some > period of time? > >> > >> Yes, we did discuss it. This was chosen consciously to be in sync with > cookies and their expirations / manual user-initiated purges. > >> > >> - Why > >> is the SHOULD in paragraph 2 not a MUST? > >> > >> Addressed in new draft. > >> > >> > >> Editorial Comments: > >> > >> =C2=A72: > >> - Paragraph 1: "The ABNF of the Sec-Token-Binding header field is (in > >> [RFC7230] style, see also Section 8.3 of [RFC7231]):" The open > parenthesis before "in" > >> seems misplaced. Also, as written the comma after "style" creates a > >> comma splice. (Note that this pattern occurs elsewhere in the > >> document.) > >> > >> - Paragraph 3: The paragraph is a single hard-to-parse sentence. > >> Please consider breaking into simpler sentences. > >> > >> Addressed in new draft. > >> > >> > >> - example: Am I correct to assume the backslashes are just for print > >> purposes and are not in the actual message? If so, please mention that= . > >> > >> Addressed in new draft. > >> > >> > >> =C2=A7 2.1: > >> - first paragraph, "Within the latter context...": There was no former > context. > >> I suggest "Within that context..." > >> > >> Addressed in new draft. > >> > >> - 2nd paragraph: The first sentence is hard to parse. I suggest > >> breaking it into separate paragraphs, or restructure without the > >> center-imbedding. > >> > >> Addressed in new draft. > >> > >> - 2nd to last paragraph: Does "SHOULD generally" > >> mean the same as just "SHOULD"? > >> > >> Addressed in new draft. > >> > >> > >> =C2=A75.1: 2nd paragraph: Unneeded comma in "... itself, to another > server..." > >> > >> Addressed in new draft. > >> > >> > >> =C2=A75.2, > >> - last bullet: " (between client and Token Consumer)" seems more than > >> parenthetical. Please consider removing the parentheses. > >> > >> Addressed in new draft. > >> > >> - paragraph after last > >> bullet: The parenthetical phrase starting with "(proving > >> possession...) is quite long and makes the sentence hard to parse. > >> Given that the concept is covered in the immediately preceding > paragraph, can it be removed? > >> > >> Addressed in new draft. > >> > >> > >> =C2=A77.1 and =C2=A77.2: These sections seem to be copied from (or res= tate > >> requirements > >> in) the protocol and negotiation drafts. Can they be included by > >> reference instead, or at least attributed? > >> > >> Addressed in new draft. > >> > >> > >> =C2=A77.2, 2nd paragraph: This seams like a restatement of =C2=A77.1. > >> > >> Addressed in new draft. > >> > >> > >> =C2=A78.3: Unneeded comma in first sentence. > >> > >> Addressed in new draft. > >> > >> Thanks again for the thoughtful comments! > >> > >> Dirk. > >> > >> _______________________________________________ > >> Unbearable mailing list > >> Unbearable@ietf.org > >> https://www.ietf.org/mailman/listinfo/unbearable > > >> > >> > > > > --0000000000003b2f85056f922497 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Should be, I need to do a double check to make sure o= ther comments were dealt with, but assuming so, then yes. Should be able to= do this tomorrow

-Ekr


On Tue, Jun 26= , 2018 at 2:19 PM, Andrei Popov <Andrei.Popov@microsoft.com&g= t; wrote:

Done: https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/.=

=C2=A0

From: John Bradley <ve7jtb@ve7jtb.com>
Sent: Tuesday, June 26, 2018 2:14 PM
To: Ben Campbell <ben@nostrum.com>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>; Eric Rescorla <ekr@rtfm.com>; Dirk Ba= lfanz <balfanz=3D40google.com@dmarc.ietf.org>; draft-ietf-tokbind-https@= ietf.org; Tokbind WG <unbearable@ietf.org>; IESG <iesg@ietf.org>; tokbind-chairs@ietf.org

=

Subject: Re: [Unbearable] Ben Campbell's Discuss on draft-ietf-t= okbind-https-14: (with DISCUSS and COMMENT)

=C2=A0

PS I suppose we need DIRK OR Andre to push a version= with the changes.

=C2=A0

John B.=C2=A0<= u>

On Tue, Jun 26, 2018, 5:12 PM John Bradley <ve7jtb@ve7jtb.com>= wrote:

Thanks Ben.

=C2=A0

EKR once this Discuss is cleared are we good to move= on to the final embrace of the RFC editor?

=C2=A0

Regards=C2=A0

John B.=C2=A0=C2=A0

=C2=A0

On Tue, Jun 26, 2018, 2:58 PM Ben Campbell <ben@nostrum.com> wro= te:



> On Jun 26, 2018, at 1:54 PM, Andrei Popov <Andrei.Popov@microsoft.com> = wrote:
>
> Hi Ben,
>
> Thanks for the review.
>
>> Are the =E2=80=9Capplications=E2=80=9D from paragraph 3 the same a= s those from paragraph 2?
>
> Yes, the same throughout paragraphs 1, 2 and 3.
>
>> It seems like paragraph 2 is talking more about local APIs (at lea= st, I see that was mentioned in the text in version 17 but not in 18), but = paragraph 3 uses an example of a signal from a server. (I can accept that t= he difference in control may be weak enough for web applications that the distinction does not matter.)
>
> The APIs provided by the TB implementation and called by the applicati= on are local APIs.
> The application needs to make a decision whether to request that the T= B implementation include a Referred binding in the TB message or not.
> In the example, the server provides a signal to the application using = the Include-Referred-Token-Binding-ID HTTP response header.
> The signal could be different, or an application may have out-of-band = ways to determine this (e.g. a local database of RP->IDP associations).<= br>
I just re-read the 3rd paragraph, and I think I missed the =E2=80=9Cthen=E2= =80=9D in =E2=80=9Cwhich then signals=E2=80=9D on the first reading. It=E2= =80=99s fine as is.

Thanks!

Ben.

>
> Cheers,
>
> Andrei
>
> -----Original Message-----
> From: Ben Campbell <ben@nostrum.com>
> Sent: Tuesday, June 26, 2018 11:41 AM
> To: Eric Rescorla <ekr@rtfm.com>
> Cc: Dirk Balfanz <balfanz=3D40google.com@dmarc.ietf.org>; draf= t-ietf-tokbind-https@ietf.org; Tokbind WG <unbearable@ietf.org>; The IESG = <iesg@ietf.org>= ;; John Bradley <ve= 7jtb@ve7jtb.com>; tokbind-chairs= @ietf.org
> Subject: Re: [Unbearable] Ben Campbell's Discuss on draft-ietf-tok= bind-https-14: (with DISCUSS and COMMENT)
>
> Hi, thanks for the pointer.
>
> The text in version 18 is sufficient to clear my discuss. I have one r= emaining (or maybe new) non-blocking question for section 6:
>
> Are the =E2=80=9Capplications=E2=80=9D from paragraph 3 the same as th= ose from paragraph 2? It seems like paragraph 2 is talking more about local= APIs (at least, I see that was mentioned in the text in version 17 but not= in 18), but paragraph 3 uses an example of a signal from a server. (I can accept that the difference in control may be weak en= ough for web applications that the distinction does not matter.)
>
> I did not check my editorial comments.
>
> Thanks!
>
> Ben.
>
>> On Jun 25, 2018, at 6:30 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>> Ben,
>>
>> Does the following new text address your concern:
>> https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?modeAsFormat= =3Dhtml/a
>> scii&url=3Dhttps://raw.githubusercontent.com/To= kenBinding/Internet-Draft
>> s/master/draft-ietf-tokbind-https-18.xml
>>
>>
>> On Mon, Jun 4, 2018 at 1:26 PM, Dirk Balfanz <balfanz=3D40google..com@dm= arc.ietf.org> wrote:
>> Hi Ben,
>>
>> thanks for the feedback. Most of it is addressed in the new draft = (https://tools.ietf.org/html/draft-ietf-tokbind-https-16). See below (inline) for details.
>>
>> On Wed, May 9, 2018 at 1:38 PM Ben Campbell <ben@nostrum.com> wrote:
>> Ben Campbell has entered the following ballot position for
>> draft-ietf-tokbind-https-14: Discuss
>>
>> When responding, please keep the subject line intact and reply to = all
>> email addresses included in the To and CC lines. (Feel free to cut=
>> this introductory paragraph, however.)
>>
>>
>> Please refer to
>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here= :
>> https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/
>>
>>
>>
>> ------------------------------------------------------------<= wbr>----------
>> DISCUSS:
>> ------------------------------------------------------------<= wbr>----------
>>
>> I plan to ballot "YES", but I want to clear up once conc= ern first:
>>
>> After reading section 6 several times, I don't know what it me= ans. I
>> think it's [...]
>>
>> Addressed in new draft.
>>
>>
>> ------------------------------------------------------------<= wbr>----------
>> COMMENT:
>> ------------------------------------------------------------<= wbr>----------
>>
>> Substantive Comments:
>>
>> =C2=A71.1: Please consider using the boilerplate from 8174 across = the
>> cluster. Both this and the protocol draft have lower case keyword = instances.
>>
>> Addressed in new draft.
>>
>>
>> =C2=A78.2:
>> - Does it really make sense to wait for a user to request the keys= be expired?
>> I suspect the average user does this about never. Did the working<= br> >> group discuss possibly making the keys default to expiring after s= ome period of time?
>>
>> Yes, we did discuss it. This was chosen consciously to be in sync = with cookies and their expirations / manual user-initiated purges.
>>
>> - Why
>> is the SHOULD in paragraph 2 not a MUST?
>>
>> Addressed in new draft.
>>
>>
>> Editorial Comments:
>>
>> =C2=A72:
>> - Paragraph 1: "The ABNF of the Sec-Token-Binding header fiel= d is (in
>> [RFC7230] style, see also Section 8.3 of [RFC7231]):" The ope= n parenthesis before "in"
>> seems misplaced. Also, as written the comma after "style"= ; creates a
>> comma splice. (Note that this pattern occurs elsewhere in the
>> document.)
>>
>> - Paragraph 3: The paragraph is a single hard-to-parse sentence. >> Please consider breaking into simpler sentences.
>>
>> Addressed in new draft.
>>
>>
>> - example: Am I correct to assume the backslashes are just for pri= nt
>> purposes and are not in the actual message? If so, please mention = that.
>>
>> Addressed in new draft.
>>
>>
>> =C2=A7 2.1:
>> - first paragraph, "Within the latter context...": There= was no former context.
>> I suggest "Within that context..."
>>
>> Addressed in new draft.
>>
>> - 2nd paragraph: The first sentence is hard to parse. I suggest >> breaking it into separate paragraphs, or restructure without the >> center-imbedding.
>>
>> Addressed in new draft.
>>
>> - 2nd to last paragraph: Does "SHOULD generally"
>> mean the same as just "SHOULD"?
>>
>> Addressed in new draft.
>>
>>
>> =C2=A75.1: 2nd paragraph: Unneeded comma in "... itself, to a= nother server..."
>>
>> Addressed in new draft.
>>
>>
>> =C2=A75.2,
>> - last bullet: " (between client and Token Consumer)" se= ems more than
>> parenthetical. Please consider removing the parentheses.
>>
>> Addressed in new draft.
>>
>> - paragraph after last
>> bullet: The parenthetical phrase starting with "(proving
>> possession...) is quite long and makes the sentence hard to parse.=
>> Given that the concept is covered in the immediately preceding par= agraph, can it be removed?
>>
>> Addressed in new draft.
>>
>>
>> =C2=A77.1 and =C2=A77.2: These sections seem to be copied from (or= restate
>> requirements
>> in) the protocol and negotiation drafts. Can they be included by >> reference instead, or at least attributed?
>>
>> Addressed in new draft.
>>
>>
>> =C2=A77.2, 2nd paragraph: This seams like a restatement of =C2=A77= .1.
>>
>> Addressed in new draft.
>>
>>
>> =C2=A78.3: Unneeded comma in first sentence.
>>
>> Addressed in new draft.
>>
>> Thanks again for the thoughtful comments!
>>
>> Dirk.
>>
>> _______________________________________________
>> Unbearable mailing list
>> Unbearabl= e@ietf.org
>> https://www.ietf.org/mailman/listinfo/unbearable
>>
>>
>


--0000000000003b2f85056f922497--