From nobody Thu Mar 19 09:21:41 2015 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7FA1ACE2B for ; Thu, 19 Mar 2015 09:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 IHHIKhoEFZUG for ; Thu, 19 Mar 2015 09:21:34 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (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 CEE351ACE2C for ; Thu, 19 Mar 2015 09:21:33 -0700 (PDT) Received: by lbcgn8 with SMTP id gn8so56576062lbc.2 for ; Thu, 19 Mar 2015 09:21:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yibhOS+aGVCNb0W6K4hqPMCndoio7UWozhD1ofJjDUc=; b=aw9inOmYe0mS3oG8dwqqpkK8CO28tNI4MBwne07jRELpRKMjX/5yndoc1089EYoIy8 IJrpG+UTbzNcT7IJegfRgQruv568BxTto1mUAeu4ZTFZvY2Jnvhlx9fe/ytv4Y/27pWY 8EHV9SC/zphiC3sfOO95rd9BbjtR5irdVyJ4qlCfucXYVNWOCivYcd0a8L8RlZpM9jDI jJfGGtaf9qlth/+x+cUF4qvbIgrLxaetXw94Hzec5k3kyqHJDcIWGcvFCSg1ZPiGevdT mbLv3tqhevb1FAWLykRxDSr/a32Awus4ieI8fS1itw9O+TMfRYvi+Idb20LizioyoJH3 Lnng== X-Gm-Message-State: ALoCoQnPoSJlvh953932pg7NnHzXcV0LBPqt13rFvIceQIAjwmLBu2WcMVX0tT8RerOfr0jYUgzZ MIME-Version: 1.0 X-Received: by 10.152.87.46 with SMTP id u14mr48956217laz.82.1426782092157; Thu, 19 Mar 2015 09:21:32 -0700 (PDT) Received: by 10.25.135.4 with HTTP; Thu, 19 Mar 2015 09:21:32 -0700 (PDT) In-Reply-To: <20150205143342.20868.94024.idtracker@ietfa.amsl.com> References: <20150205143342.20868.94024.idtracker@ietfa.amsl.com> Date: Thu, 19 Mar 2015 12:21:32 -0400 Message-ID: From: Richard Barnes To: Stephen Farrell , draft-ietf-drinks-spp-protocol-over-soap.all@ietf.org Content-Type: multipart/alternative; boundary=001a11c2afd0c6805b0511a69793 Archived-At: Cc: "drinks@ietf.org" , drinks-chairs@ietf.org, The IESG Subject: Re: [drinks] Stephen Farrell's Discuss on draft-ietf-drinks-spp-protocol-over-soap-07: (with DISCUSS and COMMENT) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 16:21:37 -0000 --001a11c2afd0c6805b0511a69793 Content-Type: text/plain; charset=UTF-8 Authors: Any response to Stephen on this? For my part: Stephen, are you seeing some risk associated with a MUST for Digest? It doesn't preclude implementations from *also* using TLS client authentication, and it seems to agree with the general direction of having a required minimum level of security. --Richard On Thu, Feb 5, 2015 at 9:33 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-drinks-spp-protocol-over-soap-07: 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 http://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: > http://datatracker.ietf.org/doc/draft-ietf-drinks-spp-protocol-over-soap/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > I just want to check one thing... > > Section 5: why is there a MUST for Digest auth? What'd be > wrong with TLS client auth here? I do wish the WG had > considered some alternative to passwords, which don't make so > much sense in this use-case. (BTW: You could chose HOBA here > I guess, but that's still in the RFC editor queue and not > supported by libraries so perhaps doesn't suit. But it'd work. > I'm an author of the HOBA spec though, so I'm biased:-) Anyway > - can you tell me if the WG considered dropping passwords > entirely and mandating TLS client auth be implemented? If the > WG seriously considered TLS client auth already, I'll just > clear. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - General: why would one want to ever run this protocol > without TLS? Did the WG consider saying that TLS MUST be used? > Again, if you tell me you thought about it, I'll just clear. > > - 7.1.2: The framework uses "Identifier" but here you use > "Identity" - it'd be better to be consistent I think and > "Identifier" is a lot better. > > - section 11 is weaker than the corresponding section in the > framework draft. Two things: 1) why not point back to the > framework here? 2) shouldn't you say which of the > vulns/mitigations called out in the framework are relevant or > mitigated here? > > > --001a11c2afd0c6805b0511a69793 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Authors: Any response to Stephen on this?
For my part: Stephen, are you seeing some risk associated with a MUS= T for Digest?=C2=A0 It doesn't preclude implementations from *also* usi= ng TLS client authentication, and it seems to agree with the general direct= ion of having a required minimum level of security.

--Richard<= br>


On Thu, Feb 5, 2015 at 9:33 AM, Stephen Farrell <<= a href=3D"mailto:stephen.farrell@cs.tcd.ie" target=3D"_blank">stephen.farre= ll@cs.tcd.ie> wrote:
Stephe= n Farrell has entered the following ballot position for
draft-ietf-drinks-spp-protocol-over-soap-07: 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 http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-dri= nks-spp-protocol-over-soap/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


I just want to check one thing...

Section 5: why is there a MUST for Digest auth?=C2=A0 What'd be
wrong with TLS client auth here?=C2=A0 I do wish the WG had
considered some alternative to passwords, which don't make so
much sense in this use-case.=C2=A0 (BTW: You could chose HOBA here
I guess, but that's still in the RFC editor queue and not
supported by libraries so perhaps doesn't suit. But it'd work.
I'm an author of the HOBA spec though, so I'm biased:-) Anyway
- can you tell me if the WG considered dropping passwords
entirely and mandating TLS client auth be implemented?=C2=A0 If the
WG seriously considered TLS client auth already, I'll just
clear.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


- General: why would one want to ever run this protocol
without TLS? Did the WG consider saying that TLS MUST be used?
Again, if you tell me you thought about it, I'll just clear.

- 7.1.2: The framework uses "Identifier" but here you use
"Identity" - it'd be better to be consistent I think and
"Identifier" is a lot better.

- section 11 is weaker than the corresponding section in the
framework draft. Two things: 1) why not point back to the
framework here? 2) shouldn't you say which of the
vulns/mitigations called out in the framework are relevant or
mitigated here?



--001a11c2afd0c6805b0511a69793-- From nobody Thu Mar 19 09:21:42 2015 Return-Path: X-Original-To: expand-draft-ietf-drinks-spp-protocol-over-soap.all@virtual.ietf.org Delivered-To: drinks@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 50AD61ACE3B; Thu, 19 Mar 2015 09:21:40 -0700 (PDT) X-Original-To: xfilter-draft-ietf-drinks-spp-protocol-over-soap.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-drinks-spp-protocol-over-soap.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096CB1ACE38 for ; Thu, 19 Mar 2015 09:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 4DW1XYXfEFXr for ; Thu, 19 Mar 2015 09:21:37 -0700 (PDT) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (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 A61FC1ACE28 for ; Thu, 19 Mar 2015 09:21:33 -0700 (PDT) Received: by lbcgn8 with SMTP id gn8so56576045lbc.2 for ; Thu, 19 Mar 2015 09:21:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yibhOS+aGVCNb0W6K4hqPMCndoio7UWozhD1ofJjDUc=; b=KqOC59AOT00JgLGEaQG1bkheRHVhID8DVmxV9VcqyODl40W3DbKc/YsZw4ScJh2yGg zzAJRwB3SFZqt8YhzZ1kOY4WyaXM6pLfsa9RM+T+GgxVUKAFHkRu+7RWOj++YB4aWEtC TSd47aAxGiSaBedgsHRi0vqWHJ0sTX044+NFP4HajS/tw4kfjdSNwHyjkj5H+HHZLFNo SIwhddLF27X+BFiveq0A8TuaSnCaujAV0eWZr0AouO2/is3l7STSK351fJduI6MmgejJ pB/VE4anFjFAvUP7C36X4YM0I+gCoAN+EhPiHbaXMlB0rAF0ZAaJbuXcEMB7574p49VC BEdg== X-Gm-Message-State: ALoCoQlHdQ1MBG5DdLyR9EdnJicUegkKZQd5PWmSpUp9Va7NF3jI8N4dkxtybrntOMpCL6uywcDu MIME-Version: 1.0 X-Received: by 10.152.87.46 with SMTP id u14mr48956217laz.82.1426782092157; Thu, 19 Mar 2015 09:21:32 -0700 (PDT) Received: by 10.25.135.4 with HTTP; Thu, 19 Mar 2015 09:21:32 -0700 (PDT) In-Reply-To: <20150205143342.20868.94024.idtracker@ietfa.amsl.com> References: <20150205143342.20868.94024.idtracker@ietfa.amsl.com> Date: Thu, 19 Mar 2015 12:21:32 -0400 Message-ID: From: Richard Barnes To: Stephen Farrell , draft-ietf-drinks-spp-protocol-over-soap.all@ietf.org Content-Type: multipart/alternative; boundary=001a11c2afd0c6805b0511a69793 Archived-At: Cc: "drinks@ietf.org" , drinks-chairs@ietf.org, The IESG Subject: Re: [drinks] Stephen Farrell's Discuss on draft-ietf-drinks-spp-protocol-over-soap-07: (with DISCUSS and COMMENT) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 16:21:40 -0000 --001a11c2afd0c6805b0511a69793 Content-Type: text/plain; charset=UTF-8 Authors: Any response to Stephen on this? For my part: Stephen, are you seeing some risk associated with a MUST for Digest? It doesn't preclude implementations from *also* using TLS client authentication, and it seems to agree with the general direction of having a required minimum level of security. --Richard On Thu, Feb 5, 2015 at 9:33 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-drinks-spp-protocol-over-soap-07: 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 http://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: > http://datatracker.ietf.org/doc/draft-ietf-drinks-spp-protocol-over-soap/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > I just want to check one thing... > > Section 5: why is there a MUST for Digest auth? What'd be > wrong with TLS client auth here? I do wish the WG had > considered some alternative to passwords, which don't make so > much sense in this use-case. (BTW: You could chose HOBA here > I guess, but that's still in the RFC editor queue and not > supported by libraries so perhaps doesn't suit. But it'd work. > I'm an author of the HOBA spec though, so I'm biased:-) Anyway > - can you tell me if the WG considered dropping passwords > entirely and mandating TLS client auth be implemented? If the > WG seriously considered TLS client auth already, I'll just > clear. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - General: why would one want to ever run this protocol > without TLS? Did the WG consider saying that TLS MUST be used? > Again, if you tell me you thought about it, I'll just clear. > > - 7.1.2: The framework uses "Identifier" but here you use > "Identity" - it'd be better to be consistent I think and > "Identifier" is a lot better. > > - section 11 is weaker than the corresponding section in the > framework draft. Two things: 1) why not point back to the > framework here? 2) shouldn't you say which of the > vulns/mitigations called out in the framework are relevant or > mitigated here? > > > --001a11c2afd0c6805b0511a69793 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Authors: Any response to Stephen on this?
For my part: Stephen, are you seeing some risk associated with a MUS= T for Digest?=C2=A0 It doesn't preclude implementations from *also* usi= ng TLS client authentication, and it seems to agree with the general direct= ion of having a required minimum level of security.

--Richard<= br>


On Thu, Feb 5, 2015 at 9:33 AM, Stephen Farrell <<= a href=3D"mailto:stephen.farrell@cs.tcd.ie" target=3D"_blank">stephen.farre= ll@cs.tcd.ie> wrote:
Stephe= n Farrell has entered the following ballot position for
draft-ietf-drinks-spp-protocol-over-soap-07: 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 http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-dri= nks-spp-protocol-over-soap/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


I just want to check one thing...

Section 5: why is there a MUST for Digest auth?=C2=A0 What'd be
wrong with TLS client auth here?=C2=A0 I do wish the WG had
considered some alternative to passwords, which don't make so
much sense in this use-case.=C2=A0 (BTW: You could chose HOBA here
I guess, but that's still in the RFC editor queue and not
supported by libraries so perhaps doesn't suit. But it'd work.
I'm an author of the HOBA spec though, so I'm biased:-) Anyway
- can you tell me if the WG considered dropping passwords
entirely and mandating TLS client auth be implemented?=C2=A0 If the
WG seriously considered TLS client auth already, I'll just
clear.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


- General: why would one want to ever run this protocol
without TLS? Did the WG consider saying that TLS MUST be used?
Again, if you tell me you thought about it, I'll just clear.

- 7.1.2: The framework uses "Identifier" but here you use
"Identity" - it'd be better to be consistent I think and
"Identifier" is a lot better.

- section 11 is weaker than the corresponding section in the
framework draft. Two things: 1) why not point back to the
framework here? 2) shouldn't you say which of the
vulns/mitigations called out in the framework are relevant or
mitigated here?



--001a11c2afd0c6805b0511a69793-- From nobody Thu Mar 19 09:24:49 2015 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9E71ACE37; Thu, 19 Mar 2015 09:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham 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 SOMixu-ssN41; Thu, 19 Mar 2015 09:24:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE281ACE30; Thu, 19 Mar 2015 09:24:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150319162446.4963.81619.idtracker@ietfa.amsl.com> Date: Thu, 19 Mar 2015 09:24:46 -0700 From: IETF Secretariat Archived-At: Subject: [drinks] ID Tracker State Update Notice: X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 16:24:48 -0000 IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation - Defer::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-drinks-spp-protocol-over-soap/ From nobody Thu Mar 19 09:24:56 2015 Return-Path: X-Original-To: expand-draft-ietf-drinks-spp-protocol-over-soap.all@virtual.ietf.org Delivered-To: drinks@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 02B831ACE39; Thu, 19 Mar 2015 09:24:54 -0700 (PDT) X-Original-To: xfilter-draft-ietf-drinks-spp-protocol-over-soap.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-drinks-spp-protocol-over-soap.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D662E1ACE31 for ; Thu, 19 Mar 2015 09:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 BAtaVysNS7h4 for ; Thu, 19 Mar 2015 09:24:54 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 C9B631ACE38 for ; Thu, 19 Mar 2015 09:24:53 -0700 (PDT) Received: from mail.ietf.org ([4.31.198.44]:38977) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YYdFd-0007xq-D2 for draft-ietf-drinks-spp-protocol-over-soap.all@tools.ietf.org; Thu, 19 Mar 2015 09:24:53 -0700 Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F461ACE38; Thu, 19 Mar 2015 09:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.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 SOMixu-ssN41; Thu, 19 Mar 2015 09:24:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE281ACE30; Thu, 19 Mar 2015 09:24:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150319162446.4963.81619.idtracker@ietfa.amsl.com> Date: Thu, 19 Mar 2015 09:24:46 -0700 From: IETF Secretariat X-SA-Exim-Connect-IP: 4.31.198.44 X-SA-Exim-Rcpt-To: draft-ietf-drinks-spp-protocol-over-soap.all@tools.ietf.org X-SA-Exim-Mail-From: ietf-secretariat-reply@ietf.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-drinks-spp-protocol-over-soap.all@ietf.org Resent-Message-Id: <20150319162453.C9B631ACE38@ietfa.amsl.com> Resent-Date: Thu, 19 Mar 2015 09:24:53 -0700 (PDT) Resent-From: ietf-secretariat-reply@ietf.org Archived-At: Archived-At: Subject: [drinks] ID Tracker State Update Notice: X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 16:24:55 -0000 IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation - Defer::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-drinks-spp-protocol-over-soap/ From nobody Thu Mar 19 09:25:14 2015 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2541ACE39; Thu, 19 Mar 2015 09:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 JhedmqeX9Fma; Thu, 19 Mar 2015 09:25:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E8E1A7005; Thu, 19 Mar 2015 09:25:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150319162511.4695.60567.idtracker@ietfa.amsl.com> Date: Thu, 19 Mar 2015 09:25:11 -0700 From: IETF Secretariat Archived-At: Subject: [drinks] ID Tracker State Update Notice: X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 16:25:13 -0000 IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation - Defer::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-drinks-spp-framework/ From nobody Thu Mar 19 09:25:25 2015 Return-Path: X-Original-To: expand-draft-ietf-drinks-spp-framework.all@virtual.ietf.org Delivered-To: drinks@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 10CA21ACE36; Thu, 19 Mar 2015 09:25:24 -0700 (PDT) X-Original-To: xfilter-draft-ietf-drinks-spp-framework.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-drinks-spp-framework.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50E61A1B48 for ; Thu, 19 Mar 2015 09:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 BIeKuXucI0Nw for ; Thu, 19 Mar 2015 09:25:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 7E2811ACE38 for ; Thu, 19 Mar 2015 09:25:18 -0700 (PDT) Received: from mail.ietf.org ([4.31.198.44]:46431) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YYdG2-0001N1-2G for draft-ietf-drinks-spp-framework.all@tools.ietf.org; Thu, 19 Mar 2015 09:25:18 -0700 Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F3E1ACE38; Thu, 19 Mar 2015 09:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.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 JhedmqeX9Fma; Thu, 19 Mar 2015 09:25:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E8E1A7005; Thu, 19 Mar 2015 09:25:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150319162511.4695.60567.idtracker@ietfa.amsl.com> Date: Thu, 19 Mar 2015 09:25:11 -0700 From: IETF Secretariat X-SA-Exim-Connect-IP: 4.31.198.44 X-SA-Exim-Rcpt-To: draft-ietf-drinks-spp-framework.all@tools.ietf.org X-SA-Exim-Mail-From: ietf-secretariat-reply@ietf.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-drinks-spp-framework.all@ietf.org Resent-Message-Id: <20150319162521.7E2811ACE38@ietfa.amsl.com> Resent-Date: Thu, 19 Mar 2015 09:25:18 -0700 (PDT) Resent-From: ietf-secretariat-reply@ietf.org Archived-At: Archived-At: Subject: [drinks] ID Tracker State Update Notice: X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 16:25:24 -0000 IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation - Defer::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-drinks-spp-framework/ From nobody Thu Mar 19 11:55:12 2015 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED711A6EFE; Thu, 19 Mar 2015 11:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 8bqCNErkhx7H; Thu, 19 Mar 2015 11:55:05 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B1C71A005C; Thu, 19 Mar 2015 11:55:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3F97DBEC4; Thu, 19 Mar 2015 18:55:03 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NhDEwYtW4dK; Thu, 19 Mar 2015 18:55:01 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.20.71]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 94813BEB5; Thu, 19 Mar 2015 18:55:01 +0000 (GMT) Message-ID: <550B1B85.1040501@cs.tcd.ie> Date: Thu, 19 Mar 2015 18:55:01 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Richard Barnes , draft-ietf-drinks-spp-protocol-over-soap.all@ietf.org References: <20150205143342.20868.94024.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "drinks@ietf.org" , drinks-chairs@ietf.org, The IESG Subject: Re: [drinks] Stephen Farrell's Discuss on draft-ietf-drinks-spp-protocol-over-soap-07: (with DISCUSS and COMMENT) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 18:55:08 -0000 Hiya, On 19/03/15 16:21, Richard Barnes wrote: > Authors: Any response to Stephen on this? > > For my part: Stephen, are you seeing some risk associated with a MUST for > Digest? I'd have to go re-read, but no I think I just wanted to check in case that triggered a light bulb moment I think. (And of course because digest is a POS;-) S. > It doesn't preclude implementations from *also* using TLS client > authentication, and it seems to agree with the general direction of having > a required minimum level of security. > > --Richard > > > > On Thu, Feb 5, 2015 at 9:33 AM, Stephen Farrell > wrote: > >> Stephen Farrell has entered the following ballot position for >> draft-ietf-drinks-spp-protocol-over-soap-07: 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 http://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: >> http://datatracker.ietf.org/doc/draft-ietf-drinks-spp-protocol-over-soap/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> I just want to check one thing... >> >> Section 5: why is there a MUST for Digest auth? What'd be >> wrong with TLS client auth here? I do wish the WG had >> considered some alternative to passwords, which don't make so >> much sense in this use-case. (BTW: You could chose HOBA here >> I guess, but that's still in the RFC editor queue and not >> supported by libraries so perhaps doesn't suit. But it'd work. >> I'm an author of the HOBA spec though, so I'm biased:-) Anyway >> - can you tell me if the WG considered dropping passwords >> entirely and mandating TLS client auth be implemented? If the >> WG seriously considered TLS client auth already, I'll just >> clear. >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> - General: why would one want to ever run this protocol >> without TLS? Did the WG consider saying that TLS MUST be used? >> Again, if you tell me you thought about it, I'll just clear. >> >> - 7.1.2: The framework uses "Identifier" but here you use >> "Identity" - it'd be better to be consistent I think and >> "Identifier" is a lot better. >> >> - section 11 is weaker than the corresponding section in the >> framework draft. Two things: 1) why not point back to the >> framework here? 2) shouldn't you say which of the >> vulns/mitigations called out in the framework are relevant or >> mitigated here? >> >> >> > From nobody Thu Mar 19 11:55:14 2015 Return-Path: X-Original-To: expand-draft-ietf-drinks-spp-protocol-over-soap.all@virtual.ietf.org Delivered-To: drinks@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 3EE551A8792; Thu, 19 Mar 2015 11:55:08 -0700 (PDT) X-Original-To: xfilter-draft-ietf-drinks-spp-protocol-over-soap.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-drinks-spp-protocol-over-soap.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED711A6EFE; Thu, 19 Mar 2015 11:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 8bqCNErkhx7H; Thu, 19 Mar 2015 11:55:05 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B1C71A005C; Thu, 19 Mar 2015 11:55:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3F97DBEC4; Thu, 19 Mar 2015 18:55:03 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NhDEwYtW4dK; Thu, 19 Mar 2015 18:55:01 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.20.71]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 94813BEB5; Thu, 19 Mar 2015 18:55:01 +0000 (GMT) Message-ID: <550B1B85.1040501@cs.tcd.ie> Date: Thu, 19 Mar 2015 18:55:01 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Richard Barnes , draft-ietf-drinks-spp-protocol-over-soap.all@ietf.org References: <20150205143342.20868.94024.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "drinks@ietf.org" , drinks-chairs@ietf.org, The IESG Subject: Re: [drinks] Stephen Farrell's Discuss on draft-ietf-drinks-spp-protocol-over-soap-07: (with DISCUSS and COMMENT) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 18:55:08 -0000 Hiya, On 19/03/15 16:21, Richard Barnes wrote: > Authors: Any response to Stephen on this? > > For my part: Stephen, are you seeing some risk associated with a MUST for > Digest? I'd have to go re-read, but no I think I just wanted to check in case that triggered a light bulb moment I think. (And of course because digest is a POS;-) S. > It doesn't preclude implementations from *also* using TLS client > authentication, and it seems to agree with the general direction of having > a required minimum level of security. > > --Richard > > > > On Thu, Feb 5, 2015 at 9:33 AM, Stephen Farrell > wrote: > >> Stephen Farrell has entered the following ballot position for >> draft-ietf-drinks-spp-protocol-over-soap-07: 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 http://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: >> http://datatracker.ietf.org/doc/draft-ietf-drinks-spp-protocol-over-soap/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> I just want to check one thing... >> >> Section 5: why is there a MUST for Digest auth? What'd be >> wrong with TLS client auth here? I do wish the WG had >> considered some alternative to passwords, which don't make so >> much sense in this use-case. (BTW: You could chose HOBA here >> I guess, but that's still in the RFC editor queue and not >> supported by libraries so perhaps doesn't suit. But it'd work. >> I'm an author of the HOBA spec though, so I'm biased:-) Anyway >> - can you tell me if the WG considered dropping passwords >> entirely and mandating TLS client auth be implemented? If the >> WG seriously considered TLS client auth already, I'll just >> clear. >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> - General: why would one want to ever run this protocol >> without TLS? Did the WG consider saying that TLS MUST be used? >> Again, if you tell me you thought about it, I'll just clear. >> >> - 7.1.2: The framework uses "Identifier" but here you use >> "Identity" - it'd be better to be consistent I think and >> "Identifier" is a lot better. >> >> - section 11 is weaker than the corresponding section in the >> framework draft. Two things: 1) why not point back to the >> framework here? 2) shouldn't you say which of the >> vulns/mitigations called out in the framework are relevant or >> mitigated here? >> >> >> > From nobody Mon Mar 23 08:13:04 2015 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CA11A8A09 for ; Mon, 23 Mar 2015 08:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.741 X-Spam-Level: X-Spam-Status: No, score=-5.741 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 yQUL8T-AjrkJ for ; Mon, 23 Mar 2015 08:13:00 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (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 D414E1A89AE for ; Mon, 23 Mar 2015 08:12:59 -0700 (PDT) Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.50 ; Mon, 23 Mar 2015 16:12:58 +0100 Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0224.002; Mon, 23 Mar 2015 16:12:54 +0100 From: Alexander Mayrhofer To: "stephen.farrell@cs.tcd.ie" Thread-Topic: Your DISCUSS on draft-ietf-drinks-spp-protocol-over-soap Thread-Index: AdBlearalYCS87AcQ0eGC/oL2ITwYg== Date: Mon, 23 Mar 2015 15:12:53 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE075467854F5@NICS-EXCH2.sbg.nic.at> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.3.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Archived-At: Cc: "drinks@ietf.org" Subject: [drinks] Your DISCUSS on draft-ietf-drinks-spp-protocol-over-soap X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 15:13:02 -0000 Hello Stephen, You raised a DISCUSS around the use of Digest Authentication in the DRINKS = SOAP transport (https://datatracker.ietf.org/doc/draft-ietf-drinks-spp-protocol-over-soap/= ) Specifically, you asked whether the WG considered client certificates as th= e authentication method.=20 The WG had extensive "design team" discussions since 2009, and from what i = remember (i couldn't find=20 it in the minutes), the discussions about client certificates mostly based = on experience with EPP (the=20 Extensible Provisioning Protocol). EPP "sort of" requires client certificat= es (See Section 6 of RFC 5734),=20 but in practical, almost none of the deployments of EPP in the field requir= e a client to present a=20 certificate.=20 We wanted to avoid a similar situation with SPPP, and - with the practical = experience from EPP - therefore didn't want to require client certificate based authentication. Furthermore= , we wanted to reduce the variety=20 of authentication methods a client / server needs to implement to foster in= teropability (we were fearing a=20 "mandatory to implement" style discussion, and hence agreed to used Digest = only). The text that is now in the document was based on feedback of the document'= s WGLC in 2012: https://www.ietf.org/mail-archive/web/drinks/current/msg01233.html If the explanation above doesn't address your concerns, would adding text = that allows "authentication methods with similar security properties" (I'm = not sure whether that is too vague, and it also wouldn't address the concer= n of interopability) address that issue? Also, i'm around in Dallas until Friday noon - so i'm more than happy to di= scuss this in person, if you have time? It would be great if we could resol= ve this over the next days, because we want to finally get the documents "= out of the door" so that Richard can shut down the WG :) thanks, Alex Mayrhofer From nobody Mon Mar 23 08:31:32 2015 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB8D1A9043 for ; Mon, 23 Mar 2015 08:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.741 X-Spam-Level: X-Spam-Status: No, score=-5.741 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 U3tGpXTmkTaN for ; Mon, 23 Mar 2015 08:31:26 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (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 9808A1A90D2 for ; Mon, 23 Mar 2015 08:31:25 -0700 (PDT) Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.50 ; Mon, 23 Mar 2015 16:31:23 +0100 Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0224.002; Mon, 23 Mar 2015 16:31:22 +0100 From: Alexander Mayrhofer To: "drinks@ietf.org" Thread-Topic: Shutting down the WG Thread-Index: AdBlcwDJ9pfiAQkoRzW3UyUUVJRUsA== Date: Mon, 23 Mar 2015 15:31:21 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE0754678556A@NICS-EXCH2.sbg.nic.at> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.3.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Archived-At: Subject: [drinks] Shutting down the WG X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 15:31:29 -0000 All, i have had a short conversation with Richard Barnes yesterday, and we discu= ssed two things: a) We agreed to shut the WG down (yay!), likely during this week. b) He urged me to clear the DISCUSSes on our two documents until Wednesday. The DISCUSSes can be seen here: - https://datatracker.ietf.org/doc/draft-ietf-drinks-spp-framework/ballot/ = (2 DISCUSS, with various points) - https://datatracker.ietf.org/doc/draft-ietf-drinks-spp-protocol-over-soap= /ballot/ (1 DISCUSS around the use of authentication) I've already started the discussion with Stephen regarding his DISCUSS on t= he SOAP document, and will look into the Framework DISCUSSes later today, a= nd provide a suggestion to authors. thanks, Alex From nobody Mon Mar 23 13:29:13 2015 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E441B29EB; Mon, 23 Mar 2015 13:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 qp4P7ygn2iPH; Mon, 23 Mar 2015 13:29:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B1D1B29E4; Mon, 23 Mar 2015 13:29:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150323202910.25572.11652.idtracker@ietfa.amsl.com> Date: Mon, 23 Mar 2015 13:29:10 -0700 Archived-At: Cc: drinks@ietf.org, drinks-chairs@ietf.org Subject: [drinks] Stephen Farrell's No Objection on draft-ietf-drinks-spp-protocol-over-soap-07: (with COMMENT) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 20:29:11 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-drinks-spp-protocol-over-soap-07: No Objection 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 http://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: http://datatracker.ietf.org/doc/draft-ietf-drinks-spp-protocol-over-soap/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the response to my discuss, since the WG did think it through, I've cleared. ----- OLD COMMENTS below - General: why would one want to ever run this protocol without TLS? Did the WG consider saying that TLS MUST be used? Again, if you tell me you thought about it, I'll just clear. - 7.1.2: The framework uses "Identifier" but here you use "Identity" - it'd be better to be consistent I think and "Identifier" is a lot better. - section 11 is weaker than the corresponding section in the framework draft. Two things: 1) why not point back to the framework here? 2) shouldn't you say which of the vulns/mitigations called out in the framework are relevant or mitigated here? From nobody Tue Mar 24 08:54:33 2015 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326111A8AD6 for ; Tue, 24 Mar 2015 08:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.741 X-Spam-Level: X-Spam-Status: No, score=-5.741 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 4E_ltw7qiBMv for ; Tue, 24 Mar 2015 08:54:25 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (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 0620D1A8BBE for ; Tue, 24 Mar 2015 08:54:24 -0700 (PDT) Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.50 ; Tue, 24 Mar 2015 16:54:22 +0100 Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0224.002; Tue, 24 Mar 2015 16:54:17 +0100 From: Alexander Mayrhofer To: "Alissa Cooper (alissa@cooperw.in)" Thread-Topic: Your DISCUSS on draft-ietf-drinks-spp-framework Thread-Index: AdBmSWiBAI4E5ppeSrC1mWbCaE5n8Q== Date: Tue, 24 Mar 2015 15:54:16 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE07546785F25@NICS-EXCH2.sbg.nic.at> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.3.15] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Archived-At: Cc: "drinks@ietf.org" Subject: [drinks] Your DISCUSS on draft-ietf-drinks-spp-framework X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 15:54:27 -0000 Hello Alissa, You raised a DISCUSS on draft-ietf-drinks-spp-framework during the IESG rev= iew (https://datatracker.ietf.org/doc/draft-ietf-drinks-spp-framework/ballo= t/#alissa-cooper), as well as some other comments: Regarding the DISCUSS: You are of course right - we had originally the "Create" as well as the "Mo= dify" operation, and found out over the course of the development of the pr= otocol that a "modify" would be much easier implemented if the "Add" operat= ion would simply allow for overwriting / replacing the currently existing o= bject. We will change the document as follows: - Change all instances of "Create" operation to "Add" operation - Remove all instances of "Modify" operation - Add text to the draft that clarifies in a single sentence that objects ca= n by modified by simply overwriting them with an "Add" operation. Does this address your DISCUSS so that you can clear? Regarding your other comments: =3D Section 3.3 =3D What does "RFC level document" mean? RFC? Or perhaps you want to use the "permanent and readily available" standard from RFC 5226? -> The intention was that such extensions shall be RFCs. We will change the= text accordingly.=20 =3D Section 5.2.1 =3D s/SPPF object that/SPPF object/ -> Will change accordingly, thanks for spotting this. =3D Section 5.2.2 =3D s/Refer the "Framework Data Model Objects"/Refer to the "Framework Data Mod= el Objects"/ -> Thanks, will change that. =3D Section 6 =3D s/refer the "Framework Operations"/refer to the "Framework Operations"/ -> same, will change in text. We will probably roll those changes into a new revision of the document, an= d i hope to submit this asap. However, does the information above suffice s= o that you can clear your DISCUSS? We're in the process of shutting down th= e WG, so this would be highly appreciated. thanks, [and i hope all is well with you !! ] Alex From nobody Tue Mar 24 09:37:41 2015 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B9A1A8A0E for ; Tue, 24 Mar 2015 09:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.741 X-Spam-Level: X-Spam-Status: No, score=-5.741 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 HTODzpU6H6PX for ; Tue, 24 Mar 2015 09:37:35 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (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 C2C3A1A914B for ; Tue, 24 Mar 2015 09:36:54 -0700 (PDT) Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.50 ; Tue, 24 Mar 2015 17:36:53 +0100 Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0224.002; Tue, 24 Mar 2015 17:36:51 +0100 From: Alexander Mayrhofer To: "barryleiba@computer.org" Thread-Topic: Your DISCUSS on draft-ietf-drinks-spp-framework Thread-Index: AdBmSxoMKabb2hlvReK7JRvOurLuUg== Date: Tue, 24 Mar 2015 16:36:51 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE07546785F7F@NICS-EXCH2.sbg.nic.at> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.3.15] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Archived-At: Cc: "drinks@ietf.org" Subject: [drinks] Your DISCUSS on draft-ietf-drinks-spp-framework X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 16:37:39 -0000 Hello Barry, you raised a DISCUSS on draft-ietf-drinks-spp-framework (https://datatracke= r.ietf.org/doc/draft-ietf-drinks-spp-framework/ballot/#barry-leiba). Please= find our response below (I've quoted your DISCUSS text below, my comments = are prefixed with "->" -- Section 2 -- This document reuses terms from [RFC3261], [RFC5486], use cases and requirements documented in [RFC6461] and the ENUM Validation Architecture [RFC4725]. These are all listed as informative references. If you use terminology def= ined elsewhere, those references (3261 and 5486) need to be normative (they're required in order to understand the terms used in this doument). -> RFC 5486 is an Informative document, adding it as normative reference wo= uld create a downref, so i think we can't change that to normative.. I find= this a general problem with documents that specify Terminology, since thes= e are typically Informational. Also, since SPPP itself is a provisioning p= rotocol, i think that the Terminology of the underlying protocol for which = information is provisioned is not necessarily normative, as long as the def= initions of the provisioning protocol itself are fine. -> How shall we proceed with that one? I'm here until Friday noon, if you h= appen to have time to discuss this in person? We would appreciate advice on= this.. -- Section 4.11 -- At the time of this writing, a choice of transport protocol has been provided in SPP Protocol over SOAP document. This would be a good place for a reference to that draft. I think the reference is important, as you've made it MTI; I think it's a normative one= . I don't think "At the time of this writing" is necessary, though if you reall= y like it I don't object. It's also missing a "the" and some quotes, as thus= : NEW One choice of transport protocol has been provided in the document "SPP Protocol over SOAP" [reference]. END -> Will change accordingly in the text, thanks for spotting that. -- Section 11.2 -- Why does the policy need to be RFC Required? Why not Expert Review? For t= hat matter, why not FCFS? You can either point me at mailing list archives whe= re this was discussed, or explain the necessity in response to this comment. -> https://www.ietf.org/mail-archive/web/drinks/current/msg01232.html was m= y original message on the IANA registration policy. There was consensus in = a design team call that this was the right policy.=20 While we're talking about OrgIdType, I don't think the document makes it cl= ear what this is, and why new ones would be registered in the first place. Why would we ever need an OrgIdType Namespace other than "iana-en"? Shouldn't = the document say something about that? -> There was a long-standing discussion about something called "SPID" ("Ser= vice Provider ID"), even to the point where a draft was dedicated to this, = and heavily discussed: https://tools.ietf.org/html/draft-pfautz-service-pro= vider-identifier-urn-01 -> However, because of various problems (mostly du to issues on layer 8 and= beyond - eg. local regulator competences on assigning these Identifiers),= this work was not completed. Also, it was unclear what a "service provider= " would be - even individuals could operator a "service" on someone's behal= f - would they be entitled such an identifier? -> Subsequently, we came to the conclusion that re-using Enterprise numbers= was the best was to go, and also that the addition of another type of iden= tifer to the SPPP protocol shouldn't be too lightweight. -> However, *if* the industry ever agreed on using another form of identifi= er for service providers, we still wanted to leave the option available. I = can add respective text, such adding=20 NEW Such assignments will typically be requested when a new namespace for ident= ification of service providers is defined. END -> We will roll and updated revision of the document before it goes to the = RFC editor. Does our response above clarify the issues enough so that you c= an clear the DISCUSS?=20 I've also copied your "comments" into this message, and - again - our respo= nse inline: -- Section 1 -- 1. A resolution system returns a Look-Up Function (LUF) that comprises the target domain to assist in call routing (as described in [RFC5486]). I don't know that it means for a LUF to "comprise the target domain"; perha= ps its a meaning of "comprise" with which I'm unfamiliar. (Similarly for bull= et 2.) Also, where in 5486 is this described? Is it Section 4.3.3? It'd be helpf= ul to include that. -> Yes, correct, Section 4.3.3 is the correct definition. We will change th= e reference accordingly. -> We will also change "comprises" to "identifies". -- Section 2 -- In addition, this document specifies the following additional terms: You can get rid of "In addition," (my preference) or "additional"; you don'= t need both. (I would also use "defines" rather than "specifies".) -> Right, thanks for spotting that. Will change text accordingly. Server: In the context of SPPF, this is an application that receives a provisioning request and responds accordingly. It is sometimes referred to as a Registry. Registry: The Registry operates a master database of Session Establishment Data for one or more Registrants. The latter sentence in the first definition seems to say that "Server" and "Registry" are synonymous. How does it, then, make sense to have separate definitions that are different? And if they're not synonymous, perhaps it'= s unwise to sometimes refer to a Server as a Registry. -> Thanks for spotting that. A server is typically a component of a Registr= y, so, i will simply remove the second sentence of "Server" In the definition of Registrant: Within the confines of a Registry, a Registrant is uniquely identified by a well-known ID. What is a "well-known ID"? What is well known about it? I ask because the term isn't otherwise used in this document. -> We will change that to "is uniquely identified by the 'rant' element". -- Section 4 subsections -- These subsections are inconsistent in how they refer to the transport proto= col (and see Martin's comments about that). Some of those differences don't matter, but I think some do, and I think we'd be better off making the terminology consistent. 4.1, 4.2, 4.10: "a transport protocol for SPPF" 4.3= : "a protocol suitable for SPPF" [is the word "suitable" significant here?] 4.4: "the SPPF transport protocol" 4.6: "the transport protocol" [doesn't mentio= n SPPF] 4.7: "a DRINKS transport protocol" [DRINKS, as opposed to SPPF?] 4.8:= "a suitable transport protocol for SPPF" 4.9: "a transport protocol suitable f= or SPPF" You're in a maze of little twisting passages, all different. I suggest picking one phrasing and using it in all nine subsections. -> We will unify that to "a SPPF transport protocol", which is the most sen= sible term, and change text accordingly. Thanks for spotting, this draft ha= s quite a long history... -- Section 5.2 -- "Name" attributes that are used as components of object key types MUST be treated case insensitive, more specifically, comparison operations MUST use the toCasefold() function, as specified in Section 3.13 of [Unicode6.1]. It's a small point, but I think it would be better to lead with the more specific requirement, which makes the other unnecessary except by way of explanation: NEW "Name" attributes that are used as components of object key types MUST be compared using the toCasefold() function, as specified in Section 3.13 of [Unicode6.1]. That function performs case-insensitive comparisons. END -> Thanks, will change text accordingly. -- Section 11.2 -- The ABNF allows an OrgIdType Namespace identifier to end with "-"; is that intentional? -> The only intention was that the string should not start with a dash. Sin= ce the policy of the Registry is pretty heavyweight, i think we can leave i= t that way, as any request that contains a string ending with a "-" would b= e reviewed extensively. If you're concerned about that, we can change the A= BNF to disallow the "-" in the end. Again, it would be great if we could get the DISCUSS cleared today or tomor= row, since we'd rather shut the WG down sooner than later.. I'm happy to di= scuss all of that in person here, too.. thanks, Alex Mayrhofer From nobody Tue Mar 24 11:27:26 2015 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4299D1A89A3 for ; Tue, 24 Mar 2015 11:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 6a2vjD9c1aIl for ; Tue, 24 Mar 2015 11:27:23 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (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 B55B81A1B71 for ; Tue, 24 Mar 2015 11:27:23 -0700 (PDT) Received: by igcau2 with SMTP id au2so56903822igc.1 for ; Tue, 24 Mar 2015 11:27:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=eIkOiItnjr4eY0Awu9LHH2NNMMLg8Mn1DPdkCIUK4Xs=; b=Gp12zMtKEYkteu0PAS/3fZ8BE9/w4Ku5d11QZDBARzxw2SnUkeTxQ3uKeBSjpRH60O KLw+IUgwERO7yGmeChMIFp73Kf/OqRX++6D9rIrq/3oSi+EZzbIGi0rGidt6lJVOmM3C uMuQLtHRSpKmtdD410ZAvukwn55mJOY2yu47yjcQi5gZ+I5dflIePejCabdGyfLmKnbr WsZamP8X8BfVLGYlBAwLxHui8zwh3k0DRRDNfwJKF7EpBpYuebhexplNHVq8mLlyB/jQ Fo2Kd0tPR/i+rxJFuqKay6FwWnRxtMFx0FiUJ+DGIFrHwa2yUKTZayc5Nvs3bMAQ6R2z zDVg== MIME-Version: 1.0 X-Received: by 10.50.66.235 with SMTP id i11mr24483826igt.40.1427221643187; Tue, 24 Mar 2015 11:27:23 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.17.26 with HTTP; Tue, 24 Mar 2015 11:27:22 -0700 (PDT) In-Reply-To: <19F54F2956911544A32543B8A9BDE07546785F7F@NICS-EXCH2.sbg.nic.at> References: <19F54F2956911544A32543B8A9BDE07546785F7F@NICS-EXCH2.sbg.nic.at> Date: Tue, 24 Mar 2015 13:27:22 -0500 X-Google-Sender-Auth: qKZXkfdSpEBqhZ6f3A3ctiY2_h0 Message-ID: From: Barry Leiba To: Alexander Mayrhofer Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: "drinks@ietf.org" Subject: Re: [drinks] Your DISCUSS on draft-ietf-drinks-spp-framework X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 18:27:25 -0000 Hi, Alex. Thanks for the response. > This document reuses terms from [RFC3261], [RFC5486], use cases and > requirements documented in [RFC6461] and the ENUM Validation > Architecture [RFC4725]. > > These are all listed as informative references. If you use terminology defined > elsewhere, those references (3261 and 5486) need to be normative (they're > required in order to understand the terms used in this doument). > > -> RFC 5486 is an Informative document, adding it as normative > reference would create a downref, so i think we can't change that to > normative.. I find this a general problem with documents that specify > Terminology, since these are typically Informational. Also, since > SPPP itself is a provisioning protocol, i think that the Terminology > of the underlying protocol for which information is provisioned is not > necessarily normative, as long as the definitions of the provisioning > protocol itself are fine. Downrefs are allowed these days, and are no longer a big problem. The only requirement is that they be identified in the last call message so that the community is made aware of them. Of course, that wasn't done in this case, so if we were to change the reference to 5486 to normative, we'd have to have a two-week last call on that change. As to whether it *should* be normative, I understand your response, and at this point I'm happy to leave this to the judgment of the working group and your AD. Thanks for discussing this with me, and I see no reason that I need to be in the loop now. > At the time of this writing, a choice of transport protocol has been > provided in SPP Protocol over SOAP document. > > This would be a good place for a reference to that draft. I think the > reference is important, as you've made it MTI; I think it's a normative one. I > don't think "At the time of this writing" is necessary, though if you really > like it I don't object. It's also missing a "the" and some quotes, as thus: > > NEW > One choice of transport protocol has been provided in the document > "SPP Protocol over SOAP" [reference]. > END > > -> Will change accordingly in the text, thanks for spotting that. Thanks. Again, I trust you folks to handle this appropriately. > Why does the policy need to be RFC Required? Why not Expert Review? For that > matter, why not FCFS? You can either point me at mailing list archives where > this was discussed, or explain the necessity in response to this comment. > > -> https://www.ietf.org/mail-archive/web/drinks/current/msg01232.html was my > original message on the IANA registration policy. There was consensus in a > design team call that this was the right policy. Thank you; that's enough for me. I wanted to make sure you folks made an informed decision, and it's clear that you did. > -> However, *if* the industry ever agreed on using another form of identifier for > service providers, we still wanted to leave the option available. I can add > respective text, such adding > > NEW > Such assignments will typically be requested when a new namespace for > identification of service providers is defined. > END Again, thanks for the explanation, which makes sense. And again, I'll leave it to you to add a little explanation, and our discussion is done. So I think we've covered all the discussion I wanted, and it's all left to "I trust the authors and the AD to do the right thing." I'll go update my ballot after I send this. And thanks, also, for addressing my non-blocking comments. Barry From nobody Tue Mar 24 11:32:33 2015 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9AED1A8835; Tue, 24 Mar 2015 11:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 pUxCwFKoNfVr; Tue, 24 Mar 2015 11:32:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F771A6EFB; Tue, 24 Mar 2015 11:32:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150324183228.27478.45837.idtracker@ietfa.amsl.com> Date: Tue, 24 Mar 2015 11:32:28 -0700 Archived-At: Cc: drinks@ietf.org, drinks-chairs@ietf.org Subject: [drinks] Barry Leiba's No Objection on draft-ietf-drinks-spp-framework-09: (with COMMENT) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 18:32:31 -0000 Barry Leiba has entered the following ballot position for draft-ietf-drinks-spp-framework-09: No Objection 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 http://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: http://datatracker.ietf.org/doc/draft-ietf-drinks-spp-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Former DISCUSS points, which are now left in "I trust the authors and AD to do the right thing" state: -- Section 2 -- This document reuses terms from [RFC3261], [RFC5486], use cases and requirements documented in [RFC6461] and the ENUM Validation Architecture [RFC4725]. These are all listed as informative references. If this terminology is required in order to understand the terms used in this document, those references (3261 and 5486) need to be normative. Left to judgment to decide. -- Section 4.11 -- At the time of this writing, a choice of transport protocol has been provided in SPP Protocol over SOAP document. This would be a good place for a reference to that draft. I think the reference is important, as you've made it MTI; I think it's a normative one. I don't think "At the time of this writing" is necessary, though if you really like it I don't object. It's also missing a "the" and some quotes, as thus: NEW One choice of transport protocol has been provided in the document "SPP Protocol over SOAP" [reference]. END About OrgIdType, I don't think the document makes it clear what this is, and why new ones would be registered in the first place. Why would we ever need an OrgIdType Namespace other than "iana-en"? Maybe add a sentence or two about that? The rest of these have already been reviewed and accepted by the authors; thanks for taking the time to consider them: -- Section 1 -- 1. A resolution system returns a Look-Up Function (LUF) that comprises the target domain to assist in call routing (as described in [RFC5486]). I don't know that it means for a LUF to "comprise the target domain"; perhaps its a meaning of "comprise" with which I'm unfamiliar. (Similarly for bullet 2.) Also, where in 5486 is this described? Is it Section 4.3.3? It'd be helpful to include that. -- Section 2 -- In addition, this document specifies the following additional terms: You can get rid of "In addition," (my preference) or "additional"; you don't need both. (I would also use "defines" rather than "specifies".) Server: In the context of SPPF, this is an application that receives a provisioning request and responds accordingly. It is sometimes referred to as a Registry. Registry: The Registry operates a master database of Session Establishment Data for one or more Registrants. The latter sentence in the first definition seems to say that "Server" and "Registry" are synonymous. How does it, then, make sense to have separate definitions that are different? And if they're not synonymous, perhaps it's unwise to sometimes refer to a Server as a Registry. In the definition of Registrant: Within the confines of a Registry, a Registrant is uniquely identified by a well-known ID. What is a "well-known ID"? What is well known about it? I ask because the term isn't otherwise used in this document. -- Section 4 subsections -- These subsections are inconsistent in how they refer to the transport protocol (and see Martin's comments about that). Some of those differences don't matter, but I think some do, and I think we'd be better off making the terminology consistent. 4.1, 4.2, 4.10: "a transport protocol for SPPF" 4.3: "a protocol suitable for SPPF" [is the word "suitable" significant here?] 4.4: "the SPPF transport protocol" 4.6: "the transport protocol" [doesn't mention SPPF] 4.7: "a DRINKS transport protocol" [DRINKS, as opposed to SPPF?] 4.8: "a suitable transport protocol for SPPF" 4.9: "a transport protocol suitable for SPPF" You're in a maze of little twisting passages, all different. I suggest picking one phrasing and using it in all nine subsections. -- Section 5.2 -- "Name" attributes that are used as components of object key types MUST be treated case insensitive, more specifically, comparison operations MUST use the toCasefold() function, as specified in Section 3.13 of [Unicode6.1]. It's a small point, but I think it would be better to lead with the more specific requirement, which makes the other unnecessary except by way of explanation: NEW "Name" attributes that are used as components of object key types MUST be compared using the toCasefold() function, as specified in Section 3.13 of [Unicode6.1]. That function performs case-insensitive comparisons. END From nobody Wed Mar 25 15:56:14 2015 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917121ACE7F; Wed, 25 Mar 2015 15:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham 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 nsG09KyAHSGo; Wed, 25 Mar 2015 15:56:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 154521A1B2E; Wed, 25 Mar 2015 15:56:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150325225609.21500.47354.idtracker@ietfa.amsl.com> Date: Wed, 25 Mar 2015 15:56:09 -0700 From: IETF Secretariat Archived-At: Subject: [drinks] ID Tracker State Update Notice: X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 22:56:12 -0000 IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-drinks-spp-protocol-over-soap/ From nobody Wed Mar 25 16:11:24 2015 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A5D1AC430 for ; Wed, 25 Mar 2015 16:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 Kbq5DhbiMxfb for ; Wed, 25 Mar 2015 16:11:21 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (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 22A9B1A8A92 for ; Wed, 25 Mar 2015 16:11:21 -0700 (PDT) Received: by lbcmq2 with SMTP id mq2so29023221lbc.0 for ; Wed, 25 Mar 2015 16:11:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=G7brIs1LwwmFJ5lN7wFfESoXyAh+e+H5ie+fvoIFgfE=; b=OsiaesIJIPtoNDeEGGE9uSVwkUhS60eS+p3zUpMqbe+KsvqzHGoVPQNANt1JLLpKRe DmcG8k9mRG8+9tL6OtmtzmCCZt+ChSl9RB1t7GR6zwqZeFYWP2fdEknKINrLf1eMI7N+ 1ZCWZ3lQKE6N757k2TNdXluTN1cl4nfejGffDVhyHr49ct0nT1nqWd5kfv1AcJNn99MU p8Zt+e9oNPlrSXs9+P+X9Luh+Vcmz2p24LjZMLDodnsMiHtQDmhWU/ZQeyivo9Axq+1b 1O9rkTFqgPF78nL1jeegKOntcwHPiBPgk8u+Pe2SRs9Of5ha5UhJx7SSr+tk65dbxYMQ anAw== X-Gm-Message-State: ALoCoQnUKPNswUdDNNWYeKekEymB4B1n4/h8VC6wTwztIUSPQat+/sMLr+zoMdyOPjESCWCzCF9e MIME-Version: 1.0 X-Received: by 10.152.27.39 with SMTP id q7mr10360769lag.49.1427325079711; Wed, 25 Mar 2015 16:11:19 -0700 (PDT) Received: by 10.25.135.139 with HTTP; Wed, 25 Mar 2015 16:11:19 -0700 (PDT) Date: Wed, 25 Mar 2015 18:11:19 -0500 Message-ID: From: Richard Barnes To: "drinks@ietf.org" Content-Type: multipart/alternative; boundary=089e0160aca45afdb20512250478 Archived-At: Subject: [drinks] Closing DRINKS X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 23:11:23 -0000 --089e0160aca45afdb20512250478 Content-Type: text/plain; charset=UTF-8 Dear DRINKS WG, As my one of my last official act as AD, I've asked the secretariat to the DRINKS WG. Thanks for all your work in getting the group's milestones completed. --Richard --089e0160aca45afdb20512250478 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear DRINKS WG,

As my one of my las= t official act as AD, I've asked the secretariat to the DRINKS WG.=C2= =A0 Thanks for all your work in getting the group's milestones complete= d.

--Richard
--089e0160aca45afdb20512250478-- From nobody Wed Mar 25 20:36:05 2015 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734631A7021; Wed, 25 Mar 2015 20:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 qbBHIvYqMrPE; Wed, 25 Mar 2015 20:36:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAA91A6FF7; Wed, 25 Mar 2015 20:36:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150326033603.22260.1990.idtracker@ietfa.amsl.com> Date: Wed, 25 Mar 2015 20:36:03 -0700 Archived-At: Cc: drinks@ietf.org Subject: [drinks] I-D Action: draft-ietf-drinks-spp-framework-10.txt X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 03:36:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Data for Reachability of Inter/tra-NetworK SIP Working Group of the IETF. Title : Session Peering Provisioning Framework (SPPF) Authors : Kenneth Cartwright Vikas Bhatia Syed Wasim Ali David Schwartz Filename : draft-ietf-drinks-spp-framework-10.txt Pages : 55 Date : 2015-03-25 Abstract: This document specifies the data model and the overall structure for a framework to provision session establishment data into Session Data Registries and SIP Service Provider data stores. The framework is called the Session Peering Provisioning Framework (SPPF). The provisioned data is typically used by network elements for session establishment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-drinks-spp-framework/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-drinks-spp-framework-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-drinks-spp-framework-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 25 20:36:15 2015 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9CBF1A88F0; Wed, 25 Mar 2015 20:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 j_7FVCMlNBwl; Wed, 25 Mar 2015 20:36:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDAF1A7009; Wed, 25 Mar 2015 20:36:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150326033603.22260.19665.idtracker@ietfa.amsl.com> Date: Wed, 25 Mar 2015 20:36:03 -0700 Archived-At: Subject: [drinks] New Version Notification - draft-ietf-drinks-spp-framework-10.txt X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 03:36:07 -0000 A new version (-10) has been submitted for draft-ietf-drinks-spp-framework: http://www.ietf.org/internet-drafts/draft-ietf-drinks-spp-framework-10.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-drinks-spp-framework/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-drinks-spp-framework-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Fri Mar 27 10:06:33 2015 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22C41A87A6 for ; Fri, 27 Mar 2015 10:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 pvk3c2l0QmPi for ; Fri, 27 Mar 2015 10:06:28 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 501741B29B9 for ; Fri, 27 Mar 2015 10:06:28 -0700 (PDT) Received: from [31.133.176.150] (dhcp-b096.meeting.ietf.org [31.133.176.150]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t2RH6QFw030749 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Mar 2015 12:06:27 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host dhcp-b096.meeting.ietf.org [31.133.176.150] claimed to be [31.133.176.150] From: "Ben Campbell" To: "Richard Barnes" Date: Fri, 27 Mar 2015 12:06:20 -0500 Message-ID: <02CC32C3-4430-4F6C-A6E8-7803BA58D0E5@nostrum.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9r5078) Archived-At: Cc: "drinks@ietf.org" Subject: Re: [drinks] Closing DRINKS X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 17:06:32 -0000 On 25 Mar 2015, at 18:11, Richard Barnes wrote: > Dear DRINKS WG, > > As my one of my last official act as AD, I've asked the secretariat to > the > DRINKS WG. Thanks for all your work in getting the group's milestones > completed. > I assume s/"... to the DRINKS... "/"... to close the DRINKS ..." (Unless Richard meant to invite the secretariat for beverages, which would also be reasonable :-) ) /Ben From nobody Fri Mar 27 10:48:40 2015 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0538F1A8729 for ; Fri, 27 Mar 2015 10:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 54Y8-hpd7DTB for ; Fri, 27 Mar 2015 10:48:37 -0700 (PDT) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (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 F1F101A7D80 for ; Fri, 27 Mar 2015 10:48:36 -0700 (PDT) Received: by lagg8 with SMTP id g8so76201408lag.1 for ; Fri, 27 Mar 2015 10:48:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cf6T1Ft+4EHDzItAIbmg8NMIEsLg/A2HtIFDy0a8a78=; b=UJQ1wJWxt8B4V+mzO5eIb0aJWWpjzsJmNffmRCV3vvrgiXcy0FUeYf//hCjRnU7XID 1UoKLsXD2q/sk0GCSpb0VhGPLRydAX3WbArV4hS6amX9hEUdGlzcZYQE2HOQblZPgP/1 gD3mnwHZZyrzfVx+1TxoBGLBxDuYXYs7lztAHr3nbITqTAedAz3Bu/yPZ3wNufrO2rq8 /WueUXgKnsK4LDqwdKMAxTjsBqUNOM4nPPMLMRmQZSUig5dEMtpuMcblLMeNV2lTT6Fl ysO5+xpjGNaSjEpZ7FlypZZpbBAfRa+lQSOX9y7dPQV4Y7alfdV5n54Ib/r90D9oBenB fK3A== X-Gm-Message-State: ALoCoQmXBaxUuQEoZU7A2OmqWvF9OolnS1rV5YCetxEmR7uTKwpIM3Fh8cstJjEpM12Kolr6hSPr MIME-Version: 1.0 X-Received: by 10.152.205.1 with SMTP id lc1mr18519017lac.51.1427478515410; Fri, 27 Mar 2015 10:48:35 -0700 (PDT) Received: by 10.25.135.139 with HTTP; Fri, 27 Mar 2015 10:48:35 -0700 (PDT) In-Reply-To: <02CC32C3-4430-4F6C-A6E8-7803BA58D0E5@nostrum.com> References: <02CC32C3-4430-4F6C-A6E8-7803BA58D0E5@nostrum.com> Date: Fri, 27 Mar 2015 12:48:35 -0500 Message-ID: From: Richard Barnes To: Ben Campbell Content-Type: multipart/alternative; boundary=001a113369e8d5fee3051248bdf4 Archived-At: Cc: "drinks@ietf.org" Subject: Re: [drinks] Closing DRINKS X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 17:48:39 -0000 --001a113369e8d5fee3051248bdf4 Content-Type: text/plain; charset=UTF-8 Also, it didn't work, because there are docs still pending. On Friday, March 27, 2015, Ben Campbell wrote: > On 25 Mar 2015, at 18:11, Richard Barnes wrote: > > Dear DRINKS WG, >> >> As my one of my last official act as AD, I've asked the secretariat to the >> DRINKS WG. Thanks for all your work in getting the group's milestones >> completed. >> >> > I assume s/"... to the DRINKS... "/"... to close the DRINKS ..." > > (Unless Richard meant to invite the secretariat for beverages, which would > also be reasonable :-) ) > > /Ben > --001a113369e8d5fee3051248bdf4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Also, it didn't work, because there are docs still pending.=C2=A0=

On Friday, March 27, 2015, Ben Campbell <ben@nostrum.com> wrote:
On 25 Mar 2015, at 18:11, Richard Barnes wrote:

Dear DRINKS WG,

As my one of my last official act as AD, I've asked the secretariat to = the
DRINKS WG.=C2=A0 Thanks for all your work in getting the group's milest= ones
completed.


I assume s/"... to the DRINKS... "/"... to close the DRINKS = ..."

(Unless Richard meant to invite the secretariat for beverages, which would = also be reasonable :-)=C2=A0 )

/Ben
--001a113369e8d5fee3051248bdf4--