From nobody Mon Aug 3 16:31:26 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11891B31F8 for ; Mon, 3 Aug 2015 16:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 02CLmsu2yZ_x for ; Mon, 3 Aug 2015 16:31:21 -0700 (PDT) Received: from mail-io0-f176.google.com (mail-io0-f176.google.com [209.85.223.176]) (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 319681B29BD for ; Mon, 3 Aug 2015 16:31:19 -0700 (PDT) Received: by iodd187 with SMTP id d187so809472iod.2 for ; Mon, 03 Aug 2015 16:31:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=WTVRVQ9/DchYM09j+zlL3+hJ6HrXhg55toa+Hrt9Abg=; b=QBMiVzZPKOqDBiUf3wGfmKUva3NOYxMTzPGG8ViL3d+sBKfijC2qpZdnqeSGmK6hCr 8S1INKV4dNi0J7Hqthxi6XRCHv9DNz5yJwDIY8a+E6iGvcNh+KuBVlByGTxCpl9Tdcmi VHgt3oHIO1R8+UeoVClb4kw0gYSV4i/16nLjfNEG47WKuZIu+XMudygsxl69ADtKAhdl 1/UtGesWL0PEGTpbccL3gDNkBaIvWC49HzhE/TxcAWAgLi3Nd+aLXUAzym/HsjbHAXQt uWWaihc1e/NhNvvor+F74irKx9eOqLT4ekOBb/XCLaSbm0bS1s/IIrMxYXWq1Y1ZYfBm I81Q== X-Gm-Message-State: ALoCoQkTcrelxyWoBuujv1gW5GFeuYfGl9c4cw8fG5kow98FtPSdZMigsXT3C1nm8r0QqH1n/7M8 X-Received: by 10.107.132.19 with SMTP id g19mr528786iod.3.1438644678608; Mon, 03 Aug 2015 16:31:18 -0700 (PDT) Received: from aither.local ([2601:282:4201:ef5b:5181:be11:62dd:5bb8]) by smtp.googlemail.com with ESMTPSA id fv2sm6829684igb.22.2015.08.03.16.31.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Aug 2015 16:31:17 -0700 (PDT) To: Barry Leiba , Mark Nottingham References: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> <55BACBBF.3060301@andyet.net> <55BBA4C1.6040404@andyet.net> From: Peter Saint-Andre - &yet Message-ID: <55BFF9C3.2090203@andyet.net> Date: Mon, 3 Aug 2015 17:31:15 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, The IESG , draft-ietf-xmpp-posh@ietf.org Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 23:31:23 -0000 Adding Mark to this thread, with pointers to get him up to speed... On 7/31/15 7:50 PM, Barry Leiba wrote: >>> If you like, it could even do POSH service names and POSH format >>> names, and specify ".well-known/posh//", >> >> Currently it's the field that we're most interested in. > > Right... and that's what I'm suggesting an FCFS registry for. You > register "posh" in .well-known, and you create your own FCFS registry > for service names, and if you don't care about the format as a > separate thing, you just register "spice.json" (and so on) in your > FCFS registry. That way, Mark doesn't get involved in approving > "posh.x" and "posh.y" and "posh.z", when Mark has no idea of what to > say about posh service names (or seedy ones, for that matter). > >> Perhaps it makes sense to talk about it again with Mark? > > Sounds like a plan. Hi Mark, During IESG review of draft-ietf-xmpp-posh, Barry raised a question about the .well-known registration, which you and Matt Miller and I talked about ages ago. Here are some relevant readings: https://tools.ietf.org/html/draft-ietf-xmpp-posh-04#section-8 https://mailarchive.ietf.org/arch/msg/xmpp/Vcikwhh1Fln6Z7WfKlb0mCarFDw https://mailarchive.ietf.org/arch/msg/xmpp/5bRV3Ob2ugDkL2E7XFrCL-eKLFE https://mailarchive.ietf.org/arch/msg/xmpp/xw_-TOVxkQJWqquZe4UH2yDJKAg Barry's proposed approach is more elegant. However, my feeling is that POSH is essentially a one-off workaround for use in XMPP until DNSSEC and DANE are more widely deployed. Although we've tried to design it in such a way that it *could* be used by other application protocols, I doubt that folks in those communities will use POSH unless Matt and I start actively promoting it (and even that is only a necessary condition, not a sufficent one). Because I don't think that we'll see additional .well-known registrations related to POSH, setting up a separate POSH registry to supplement a "posh" entry in the well-known URIs registry feels like overkill to me given the burden on IANA (I'm not a fan of one-entry registries). That said, people have been wrong before about the popularity of technologies defined in RFCs and it's possible that POSH could become more popular, in which case I'd lean more strongly toward the approach that Barry has outlined. As the designated expert for the well-known URIs registry, do you have any suggestions or preferences on how to proceed? Thanks! Peter From nobody Mon Aug 3 20:17:26 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6711B33F6 for ; Mon, 3 Aug 2015 20:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 fi8dqr_-w_jw for ; Mon, 3 Aug 2015 20:17:23 -0700 (PDT) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) (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 519A41B33F2 for ; Mon, 3 Aug 2015 20:17:23 -0700 (PDT) Received: by igr7 with SMTP id 7so66638844igr.0 for ; Mon, 03 Aug 2015 20:17:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=dtZdk+Qe+mxUIKcjbTCIncC0PtVgvtCNayS+Vut09+g=; b=a5gtzsnwPHZ314qcHu2nEyOT+hti8TD9rj9XOuXTgdy9jccAEmJBMybg761Sq1g4Zx RGvht0tvJ6aSD/1s4tmhW3BaQibjaDtwh8K6qi3J4KKkDQQO5YNxw78pasrO5DNsJmB1 pwsvU2S72/gDWwk8B7UR8pFvkqxlymhgAb7TJQ2/dcPixTUaPshbvRL+HjugWK3CsGVc ph66teNBxsNRcMMouq1ILxbCyQ1K8roGU2Z2bBJfggmWys5X8i3akw2u+eNj5oedidIh eU77eu/XC7HQ/aLW/jySC+M0psa/khjzLrBY6egH7Jw42AnKyWS/zfBmguos/kS620qq tiJA== X-Gm-Message-State: ALoCoQkCup0R2KM7KlNmcIpWTLL9TIoRpSdncdu0FBpRoqY4zoNGx4v+2rTLwigSTvLVMJBfALFx X-Received: by 10.50.122.41 with SMTP id lp9mr1364689igb.56.1438658242659; Mon, 03 Aug 2015 20:17:22 -0700 (PDT) Received: from [10.0.0.12] (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.gmail.com with ESMTPSA id d8sm470390igl.19.2015.08.03.20.17.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Aug 2015 20:17:21 -0700 (PDT) References: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> <55BACBBF.3060301@andyet.net> <55BBA4C1.6040404@andyet.net> <55BFF9C3.2090203@andyet.net> <471F2CED-DDAE-496B-8673-2CE882B7066A@mnot.net> Mime-Version: 1.0 (1.0) In-Reply-To: <471F2CED-DDAE-496B-8673-2CE882B7066A@mnot.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12H143) From: Peter Saint-Andre Date: Mon, 3 Aug 2015 21:17:19 -0600 To: Mark Nottingham Archived-At: Cc: "draft-ietf-xmpp-posh.shepherd@ietf.org" , "xmpp-chairs@ietf.org" , "xmpp@ietf.org" , "draft-ietf-xmpp-posh.ad@ietf.org" , Barry Leiba , "draft-ietf-xmpp-posh@ietf.org" , The IESG Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 03:17:25 -0000 Hi Mark, thanks for sharing your perspective. I'll give it more thought tomo= rrow.=20 Peter Sent from mobile, might be terse=20 > On Aug 3, 2015, at 6:10 PM, Mark Nottingham wrote: >=20 > Hi Peter, >=20 > As I discussed with Barry, I don't have any strong guidance here; I agree t= hat his approach is probably the way I'd go with if I designed it myself, bu= t I agree it's highly dependent on the situation. With my DE hat on, I'm neu= tral on this.=20 >=20 > Cheers, >=20 >=20 >> On 4 Aug 2015, at 9:31 am, Peter Saint-Andre - &yet wr= ote: >>=20 >> Adding Mark to this thread, with pointers to get him up to speed... >>=20 >> On 7/31/15 7:50 PM, Barry Leiba wrote: >>>>> If you like, it could even do POSH service names and POSH format >>>>> names, and specify ".well-known/posh//", >>>>=20 >>>> Currently it's the field that we're most interested in. >>>=20 >>> Right... and that's what I'm suggesting an FCFS registry for. You >>> register "posh" in .well-known, and you create your own FCFS registry >>> for service names, and if you don't care about the format as a >>> separate thing, you just register "spice.json" (and so on) in your >>> FCFS registry. That way, Mark doesn't get involved in approving >>> "posh.x" and "posh.y" and "posh.z", when Mark has no idea of what to >>> say about posh service names (or seedy ones, for that matter). >>>=20 >>>> Perhaps it makes sense to talk about it again with Mark? >>>=20 >>> Sounds like a plan. >>=20 >> Hi Mark, >>=20 >> During IESG review of draft-ietf-xmpp-posh, Barry raised a question about= the .well-known registration, which you and Matt Miller and I talked about a= ges ago. Here are some relevant readings: >>=20 >> https://tools.ietf.org/html/draft-ietf-xmpp-posh-04#section-8 >>=20 >> https://mailarchive.ietf.org/arch/msg/xmpp/Vcikwhh1Fln6Z7WfKlb0mCarFDw >>=20 >> https://mailarchive.ietf.org/arch/msg/xmpp/5bRV3Ob2ugDkL2E7XFrCL-eKLFE >>=20 >> https://mailarchive.ietf.org/arch/msg/xmpp/xw_-TOVxkQJWqquZe4UH2yDJKAg >>=20 >> Barry's proposed approach is more elegant. However, my feeling is that PO= SH is essentially a one-off workaround for use in XMPP until DNSSEC and DANE= are more widely deployed. Although we've tried to design it in such a way t= hat it *could* be used by other application protocols, I doubt that folks in= those communities will use POSH unless Matt and I start actively promoting i= t (and even that is only a necessary condition, not a sufficent one). Becaus= e I don't think that we'll see additional .well-known registrations related t= o POSH, setting up a separate POSH registry to supplement a "posh" entry in t= he well-known URIs registry feels like overkill to me given the burden on IA= NA (I'm not a fan of one-entry registries). >>=20 >> That said, people have been wrong before about the popularity of technolo= gies defined in RFCs and it's possible that POSH could become more popular, i= n which case I'd lean more strongly toward the approach that Barry has outli= ned. >>=20 >> As the designated expert for the well-known URIs registry, do you have an= y suggestions or preferences on how to proceed? >>=20 >> Thanks! >>=20 >> Peter >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 From nobody Tue Aug 4 08:04:54 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13711A6F1F; Mon, 3 Aug 2015 17:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-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 icGNR7QrfKkX; Mon, 3 Aug 2015 17:10:53 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E62661B3226; Mon, 3 Aug 2015 17:10:52 -0700 (PDT) Received: from [192.168.0.3] (unknown [120.149.147.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D026322E1F4; Mon, 3 Aug 2015 20:10:48 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Mark Nottingham In-Reply-To: <55BFF9C3.2090203@andyet.net> Date: Tue, 4 Aug 2015 10:10:46 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <471F2CED-DDAE-496B-8673-2CE882B7066A@mnot.net> References: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> <55BACBBF.3060301@andyet.net> <55BBA4C1.6040404@andyet.net> <55BFF9C3.2090203@andyet.net> To: Peter Saint-Andre - &yet X-Mailer: Apple Mail (2.2102) Archived-At: X-Mailman-Approved-At: Tue, 04 Aug 2015 08:04:53 -0700 Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, Barry Leiba , draft-ietf-xmpp-posh@ietf.org, The IESG Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 00:10:59 -0000 Hi Peter, As I discussed with Barry, I don't have any strong guidance here; I = agree that his approach is probably the way I'd go with if I designed it = myself, but I agree it's highly dependent on the situation. With my DE = hat on, I'm neutral on this.=20 Cheers, > On 4 Aug 2015, at 9:31 am, Peter Saint-Andre - &yet = wrote: >=20 > Adding Mark to this thread, with pointers to get him up to speed... >=20 > On 7/31/15 7:50 PM, Barry Leiba wrote: >>>> If you like, it could even do POSH service names and POSH format >>>> names, and specify ".well-known/posh//", >>>=20 >>> Currently it's the field that we're most interested = in. >>=20 >> Right... and that's what I'm suggesting an FCFS registry for. You >> register "posh" in .well-known, and you create your own FCFS registry >> for service names, and if you don't care about the format as a >> separate thing, you just register "spice.json" (and so on) in your >> FCFS registry. That way, Mark doesn't get involved in approving >> "posh.x" and "posh.y" and "posh.z", when Mark has no idea of what to >> say about posh service names (or seedy ones, for that matter). >>=20 >>> Perhaps it makes sense to talk about it again with Mark? >>=20 >> Sounds like a plan. >=20 > Hi Mark, >=20 > During IESG review of draft-ietf-xmpp-posh, Barry raised a question = about the .well-known registration, which you and Matt Miller and I = talked about ages ago. Here are some relevant readings: >=20 > https://tools.ietf.org/html/draft-ietf-xmpp-posh-04#section-8 >=20 > https://mailarchive.ietf.org/arch/msg/xmpp/Vcikwhh1Fln6Z7WfKlb0mCarFDw >=20 > https://mailarchive.ietf.org/arch/msg/xmpp/5bRV3Ob2ugDkL2E7XFrCL-eKLFE >=20 > https://mailarchive.ietf.org/arch/msg/xmpp/xw_-TOVxkQJWqquZe4UH2yDJKAg >=20 > Barry's proposed approach is more elegant. However, my feeling is that = POSH is essentially a one-off workaround for use in XMPP until DNSSEC = and DANE are more widely deployed. Although we've tried to design it in = such a way that it *could* be used by other application protocols, I = doubt that folks in those communities will use POSH unless Matt and I = start actively promoting it (and even that is only a necessary = condition, not a sufficent one). Because I don't think that we'll see = additional .well-known registrations related to POSH, setting up a = separate POSH registry to supplement a "posh" entry in the well-known = URIs registry feels like overkill to me given the burden on IANA (I'm = not a fan of one-entry registries). >=20 > That said, people have been wrong before about the popularity of = technologies defined in RFCs and it's possible that POSH could become = more popular, in which case I'd lean more strongly toward the approach = that Barry has outlined. >=20 > As the designated expert for the well-known URIs registry, do you have = any suggestions or preferences on how to proceed? >=20 > Thanks! >=20 > Peter >=20 >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Tue Aug 4 12:54:32 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06A81A8920; Tue, 4 Aug 2015 12:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 QP0ePUCPtTEb; Tue, 4 Aug 2015 12:42:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02EA71A8913; Tue, 4 Aug 2015 12:42:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.3.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150804194208.20336.3337.idtracker@ietfa.amsl.com> Date: Tue, 04 Aug 2015 12:42:08 -0700 Archived-At: X-Mailman-Approved-At: Tue, 04 Aug 2015 12:54:30 -0700 Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, draft-ietf-xmpp-posh@ietf.org Subject: [xmpp] Kathleen Moriarty's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 19:42:18 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-xmpp-posh-04: 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 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-xmpp-posh/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Nice work on this draft! I do have a few comments that I'd like to chat about. In the examples, could you switch them to have sha-256 as the low mark instead of sha-1? sha-1 is only a problem if you need collision resistance, but since it's just used in examples, it might be easier to just get rid of it. In the first paragraph of the Security Considerations section, could you add a reference to RFC7525 as well? Otherwise, it looks great. It should fit in nicely after the RFC2818 reference. Thanks. From nobody Wed Aug 5 08:02:52 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A31A1B30AE; Wed, 5 Aug 2015 08:02:49 -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 SHbLplfT8vAR; Wed, 5 Aug 2015 08:02:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3A71B3066; Wed, 5 Aug 2015 08:02:25 -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: 6.3.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150805150225.15925.93150.idtracker@ietfa.amsl.com> Date: Wed, 05 Aug 2015 08:02:25 -0700 Archived-At: Cc: draft-ietf-xmpp-dna.ad@ietf.org, draft-ietf-xmpp-dna@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, draft-ietf-xmpp-dna.shepherd@ietf.org Subject: [xmpp] Stephen Farrell's No Objection on draft-ietf-xmpp-dna-10: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 15:02:49 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-xmpp-dna-10: 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 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-xmpp-dna/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - section 3: does nobody ever use mutually authenticated TLS for this with XMPP? (Just wondering.) - 3.2: I didn't know that XMPP clients send a user ID in cleartext before turning on TLS. Pity that. Is it ok for a client to fake that and then later authenticate as a different entity such as "usertwo@a.example"? - 3.2, step 5: "proving" isn't quite right but is good enough here. - 4.1: Please separate the seperable pictures by at least some whitespace but ideally with captions. Right now it looks initially as if it's just one big figure. At present, I find that figure makes things less clear rather than more. - 4.2, bullets: the 2nd last one here is really similar to the 1st two (as I read 'em). Maybe consider merging. And the use of "is trusted by" in the 1st two is a bit inaccurate, but could be lived with;-) - 4.4.1: should the refs for dialback (and the "first specified..." comment) be earlier? - 5.1: Is there going to be another "XMPP with DANE prooftype" document? I'm not sure that 5.1 alone is enough, and there is one for POSH, so I wondered. - 5.2: does this repeat text from the POSH I-D? If so, is that a good idea? - 8.1: Huh? Why aren't these in the POSH I-d? - 8.1/8.2: Is it a good/bad idea to have structure in the .well-known URIs and where that structure is not a pathname? Personally, I think it's not a great idea but that's just a personal preference. I also don't think "_tcp.json" is good to include in the URI. From nobody Wed Aug 5 08:04:09 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE86C1B2FE3; Wed, 5 Aug 2015 08:04:05 -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 wh7hyvFpcrzf; Wed, 5 Aug 2015 08:04:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A831D1B30AC; Wed, 5 Aug 2015 08:02:44 -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: 6.3.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150805150244.8466.87044.idtracker@ietfa.amsl.com> Date: Wed, 05 Aug 2015 08:02:44 -0700 Archived-At: Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, draft-ietf-xmpp-posh@ietf.org Subject: [xmpp] Stephen Farrell's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 15:04:06 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-xmpp-posh-04: 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 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-xmpp-posh/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 3.1: fingerprints: sigh, I wish we could agree to just do this kind of thing a few times and not re-do it over and over and over (but we always do;-). RFC6920 could probably have been used there (caveat lector: that's an RFC I'm a co-author on). 3.1: fingerprints - your hash input here is the entire cert so the value will be out of date when a cert expires (or is revoked). While 3.3 makes clear that a match on any of these is ok, I think it'd be good to say here that the hashes may be of different certs. You do clarify in section 7, but I'd suggest moving section 7 into 3.1 myself. (I don't object if you prefer to not change though.) 3.2: A "MUST use HTTPS" statement might have been nice there. It's not absolutely needed but would maybe be something to help an implementer not get this wrong by just using some generic URL handling library without a check for scheme==https. section 6: surely the cache expiry ought be the earliest of the possibly two POST expires or the X.509 notAfter? section 8: see my comments on draft-dna, I think the .well-known URIs should be here and not there. But it works as-is too, even if ickky:-) section 8: I dislike the "{servicedesc}" thing, but that's just me. Breaking down servicedesc further into "{service}.{proto}" is worse though, I don't get why that's a good idea at all, nor the "_" convention. If you want/need all that you should've just registered "posh" as a well-known and then said the the rest of the pathname was whatever structure you needed and not possibly end up registering loads of DNA .well-known URLs. section 9: section 8 is IMO an IANA section, so you're fibbing here:-) - 11.2: odd one this but [HASH-NAMES] might be better in 11.1. I won't try force you to do that though as it may be messy. From nobody Wed Aug 5 08:25:01 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B059F1A9166 for ; Wed, 5 Aug 2015 08:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 fpk2qzQGSfMa for ; Wed, 5 Aug 2015 08:24:59 -0700 (PDT) Received: from mail-io0-f179.google.com (mail-io0-f179.google.com [209.85.223.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 546111A00DD for ; Wed, 5 Aug 2015 08:24:59 -0700 (PDT) Received: by ioeg141 with SMTP id g141so52660244ioe.3 for ; Wed, 05 Aug 2015 08:24:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=acEoREkDuHO4ZJ3vPLtrp+E7KLvBFv0ZszgtvB485h8=; b=Qad8ygGdMWWYtQili9JXEkOwf458bqVgRoAbbhxbQoAh6eCB/FftyAJMBFb7vjhiwj HCkByMLm04dc2gnqbDKxC4t8AkqKHvCDIs7K5L9DhO0fDibCMMmvsVxqJcCzDB6Ej/Mm Jmwy+sm06y2BmUdrzmS2IegjwR53MQfXV3eTFMkdous9NjcPGv0Oipg1QrnFzKfJc7CP bIg5LMIhp72bvnevEncEi34xoWd+RYkfc+1Ffh+4/dnVZz/MwBVsiG4HdAD/Ylf+MWnF atQ7Ms5efQaTR0MwKUotut58AJtbYL1NzL5ja3HD/j3YpvTYpV3Io0IqVvsJD7jEVHWJ lJwA== X-Gm-Message-State: ALoCoQluUXYxgU9+4z1YLhPbXGPFnjMMJ/2XB7rgfaNshidbBtCZEZ+v2Zj2/jKO1kj+bom0fbOs X-Received: by 10.107.129.81 with SMTP id c78mr4461356iod.4.1438788298702; Wed, 05 Aug 2015 08:24:58 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id b32sm2306355iod.16.2015.08.05.08.24.57 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Aug 2015 08:24:57 -0700 (PDT) To: Kathleen Moriarty , The IESG References: <20150804194208.20336.3337.idtracker@ietfa.amsl.com> From: Peter Saint-Andre - &yet Message-ID: <55C22AC7.9020004@andyet.net> Date: Wed, 5 Aug 2015 09:24:55 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150804194208.20336.3337.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, draft-ietf-xmpp-posh@ietf.org Subject: Re: [xmpp] Kathleen Moriarty's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 15:25:00 -0000 Hi Kathleen, thanks for the review. On 8/4/15 1:42 PM, Kathleen Moriarty wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-xmpp-posh-04: 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 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-xmpp-posh/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Nice work on this draft! I do have a few comments that I'd like to chat > about. > > In the examples, could you switch them to have sha-256 as the low mark > instead of sha-1? sha-1 is only a problem if you need collision > resistance, but since it's just used in examples, it might be easier to > just get rid of it. Good idea. > In the first paragraph of the Security Considerations section, could you > add a reference to RFC7525 as well? Otherwise, it looks great. It > should fit in nicely after the RFC2818 reference. Thanks. +1 Peter From nobody Wed Aug 5 09:06:29 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00EEA1B3127; Wed, 5 Aug 2015 09:06:26 -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 kwFOMGDlnkEY; Wed, 5 Aug 2015 09:06:25 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 F34311B3123; Wed, 5 Aug 2015 09:06:24 -0700 (PDT) Received: by vkgc186 with SMTP id c186so17354107vkg.0; Wed, 05 Aug 2015 09:06:24 -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=KkLPL2sA/1PcG44DbMSGMokkJSM8l5Hny+gokG236jA=; b=PT+P7S0hwCOgKNKdIrso33z9Y6axQyPTbscR75zPVAJOBVdu8vAFpQh6cydoHQb2kg ZG4b6ZjiXApFRUn41BECcIDb+EJc2M/mlgV0XC+S3088bN+9mIgURYW7kkewJ1nXU8tz 5k2z0uk5vp3+/BHpysjpX9WMLJqiR0GcdwocMLpjfJOEVH6kJp9EkPz65Jqq0YehDf1s s5+rAUDX1AABTz1cjO0bCO9ZPWiILt+GAyzH+N+bDW3qSIZyiKL3+p7SPytfxrBW813p 6XRHDoT3XvDDQ55oQBS+j9ZZwuOHmxT2rW+k28eDFdC+HkYYzk631w21LAhf8iuIGYqW StRQ== MIME-Version: 1.0 X-Received: by 10.52.32.34 with SMTP id f2mr13164383vdi.11.1438790784188; Wed, 05 Aug 2015 09:06:24 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Wed, 5 Aug 2015 09:06:24 -0700 (PDT) In-Reply-To: <20150805150244.8466.87044.idtracker@ietfa.amsl.com> References: <20150805150244.8466.87044.idtracker@ietfa.amsl.com> Date: Wed, 5 Aug 2015 18:06:24 +0200 X-Google-Sender-Auth: ibfEgwP5DngOQvPnqJkge7yfNHE Message-ID: From: Barry Leiba To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, xmpp@ietf.org, The IESG , draft-ietf-xmpp-posh@ietf.org Subject: Re: [xmpp] Stephen Farrell's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 16:06:26 -0000 > section 8: I dislike the "{servicedesc}" thing, but > that's just me. Breaking down servicedesc further into > "{service}.{proto}" is worse though, I don't get why > that's a good idea at all, nor the "_" convention. If > you want/need all that you should've just registered > "posh" as a well-known and then said the the rest of the > pathname was whatever structure you needed and not > possibly end up registering loads of DNA .well-known > URLs. Yep... I made a similar comment, which Peter and I have been discussing. He's mulling over what to do. Barry From nobody Wed Aug 5 09:20:41 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A665F1A1AC9; Wed, 5 Aug 2015 09:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 hVqxm1fbbXvg; Wed, 5 Aug 2015 09:20:32 -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 AFF871A1AAE; Wed, 5 Aug 2015 09:20:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8A019BE58; Wed, 5 Aug 2015 17:20:30 +0100 (IST) 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 0jzKoQUult0m; Wed, 5 Aug 2015 17:20:30 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C635ABE9C; Wed, 5 Aug 2015 17:20:29 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1438791629; bh=dM+zGZAX3a5wULI98g8EITRSkSHx6BdwNthho3zmXok=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=ZFzP8uY/3KQwkOCiCvDhrgPCv1fSXlGufYNgILM71JgaO10lA3GI/N6ebpeNGA0Iy M3OhvOUB2fN/8aMYJk2JKfLei4AmK87tz3Yhnorkrx8SdNIcVJFil0TZGcb2z0Ckqx 1LwBgmZV4Ne9PdUNTp5/a1/GCwf19Wts4hFZl9zo= Message-ID: <55C237CD.1060000@cs.tcd.ie> Date: Wed, 05 Aug 2015 17:20:29 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Barry Leiba References: <20150805150244.8466.87044.idtracker@ietfa.amsl.com> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, xmpp@ietf.org, The IESG , draft-ietf-xmpp-posh@ietf.org Subject: Re: [xmpp] Stephen Farrell's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 16:20:36 -0000 On 05/08/15 17:06, Barry Leiba wrote: >> section 8: I dislike the "{servicedesc}" thing, but >> that's just me. Breaking down servicedesc further into >> "{service}.{proto}" is worse though, I don't get why >> that's a good idea at all, nor the "_" convention. If >> you want/need all that you should've just registered >> "posh" as a well-known and then said the the rest of the >> pathname was whatever structure you needed and not >> possibly end up registering loads of DNA .well-known >> URLs. > > Yep... I made a similar comment, which Peter and I have been > discussing. He's mulling over what to do. Thanks - I saw that go by but didn't follow. Best to continue in that other thread I'd say. S > > Barry > From nobody Wed Aug 5 15:55:34 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42B31ACED9 for ; Wed, 5 Aug 2015 15:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 WuHbU1mqy4G2 for ; Wed, 5 Aug 2015 15:55:31 -0700 (PDT) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com [209.85.223.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 D78721ACECC for ; Wed, 5 Aug 2015 15:55:30 -0700 (PDT) Received: by ioii16 with SMTP id i16so64630206ioi.0 for ; Wed, 05 Aug 2015 15:55:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=xLNwQmrmQRF9MygKnpCA6gTX9sD7yvrOOYrTRrmWbKg=; b=ZMhKd6qqOl8swLhaZqdaPlzk7eRUOUNB+C6giJ+/0RBhqXi6RwT7sVuclYBBQMamtl 3IRwnFf4zjgJQPx6mG9evGXgwZnXVM1TlWPIe4mMKlnJ0HCvOn+xfGCG8ESaESajQHO1 OROERpF+E1GbYUhWbpn/csH51oOp7YYSPNXDR9DpoSGzKz07dtJGOzHbuB5Plbut9hc8 Njt5LwUHGB9zX8KEfwfbdPh87Xw/d5YWns8EinF5g9aURYhoz0fkw4HD/V+9xe4viuAO uYCQNW4aZ9l7x89waMuZ5z6xaYe5je4IjUhzL6naU1M+6FnL+gjTCABNb0f5iEdxFMGs jxOA== X-Gm-Message-State: ALoCoQnI9upyEaMNOM09gNBXKbctsAOZc461VSVD72lLyEVILPwKdEzhn5wurYi0XIRMKZE2+VA6 X-Received: by 10.107.157.4 with SMTP id g4mr12579488ioe.66.1438815330226; Wed, 05 Aug 2015 15:55:30 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id o19sm30702igi.14.2015.08.05.15.55.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Aug 2015 15:55:28 -0700 (PDT) To: Stephen Farrell , The IESG References: <20150805150244.8466.87044.idtracker@ietfa.amsl.com> From: Peter Saint-Andre - &yet Message-ID: <55C2945E.9010503@andyet.net> Date: Wed, 5 Aug 2015 16:55:26 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150805150244.8466.87044.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, draft-ietf-xmpp-posh@ietf.org Subject: Re: [xmpp] Stephen Farrell's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 22:55:33 -0000 Hi Stephen, this is a quick reply because time is short here (also, I will be offilne tomorrow and Friday). On 8/5/15 9:02 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-xmpp-posh-04: 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 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-xmpp-posh/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > > 3.1: fingerprints: sigh, I wish we could agree to just > do this kind of thing a few times and not re-do it over > and over and over (but we always do;-). RFC6920 could > probably have been used there (caveat lector: that's an > RFC I'm a co-author on). Sorry, I should have thought of RFC 6920 in this context. :( Matt and I will look at this. (He is offline this week so we won't be able to sync up until then.) We will also reach out to implementers because as I recall we chose this approach in part for ease of implementation. > 3.1: fingerprints - your hash input here is the entire > cert so the value will be out of date when a cert > expires (or is revoked). While 3.3 makes clear that > a match on any of these is ok, I think it'd be good > to say here that the hashes may be of different certs. Good points all. > You do clarify in section 7, but I'd suggest moving > section 7 into 3.1 myself. (I don't object if you > prefer to not change though.) I think that might be a sensible change. > 3.2: A "MUST use HTTPS" statement might have been nice > there. It's not absolutely needed but would maybe be > something to help an implementer not get this wrong by > just using some generic URL handling library without a > check for scheme==https. We have been assuming "MUST use HTTPS" but it seems that we didn't quite come out and say that. > section 6: surely the cache expiry ought be the earliest > of the possibly two POST expires or the X.509 notAfter? We were thinking specifically of HTTPS-related caching, but yes I certainly see your point! > section 8: see my comments on draft-dna, I think the > .well-known URIs should be here and not there. But > it works as-is too, even if ickky:-) We had some debate about exactly where things belonged, but decided in the end that the xmpp-related registrations belonged in the -dna document. > section 8: I dislike the "{servicedesc}" thing, but > that's just me. Breaking down servicedesc further into > "{service}.{proto}" is worse though, I don't get why > that's a good idea at all, nor the "_" convention. If > you want/need all that you should've just registered > "posh" as a well-known and then said the the rest of the > pathname was whatever structure you needed and not > possibly end up registering loads of DNA .well-known > URLs. See other thread. > section 9: section 8 is IMO an IANA section, so you're > fibbing here:-) Section 8 doesn't make any requests of the IANA, so it doesn't feel like material for a standard IANA considerations section. > - 11.2: odd one this but [HASH-NAMES] might be better > in 11.1. I won't try force you to do that though as > it may be messy. I'm agnostic on that, I suppose. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Aug 5 18:59:34 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C99E1B2A7D for ; Wed, 5 Aug 2015 18:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 8priNGyWJPYF for ; Wed, 5 Aug 2015 18:59:28 -0700 (PDT) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (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 49DEE1B2A72 for ; Wed, 5 Aug 2015 18:59:28 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so2432949igb.0 for ; Wed, 05 Aug 2015 18:59:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=u4Tg6iEFv+8LiO5RCCzO51fo5YvZEIA8QXqT7t3MKII=; b=Z3x6V4p4R05iuFkxXT0a9jlpZJcLk3Bh8xd9Uc0sW0DaA6+RjOVJ0X2b3ljU+TIYkM VGvMDqeQ1qrKUTPeUPyA6OMkbBGqnB8P5dUJxius8fzF1wZT5yfLmAZ99AIAu2jlYLit h0ZM9a72fo2iGeLKHYL1qTsOXaQlgiME0hbozJLVdCnbkH9lOFavdosMPOdMzDJ6Zn2h 93wBikfW08QHOBe1GpcHKjmH+gQueczvO6nHEu19LYecpAkmzqS+Z0fxdapTaJhYF5DN IKEb3FOUaB1V78nNkHBFT9NkwocI5qPp+iNjfhFIoUgRb5zF/zCIsXnvDCAne8DcpfZj wKUg== X-Gm-Message-State: ALoCoQmH6C/FIP4tfYh49TU8dQwqxiTpz75ZcMSMlljumEhg6BoMBGdCbG9UMVqjxexouhBkAOr0 X-Received: by 10.50.138.76 with SMTP id qo12mr829727igb.38.1438826367522; Wed, 05 Aug 2015 18:59:27 -0700 (PDT) Received: from aither.local ([2601:282:4201:ef5b:fd55:db01:48f0:2211]) by smtp.googlemail.com with ESMTPSA id r4sm345309igh.9.2015.08.05.18.59.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Aug 2015 18:59:26 -0700 (PDT) To: Mahesh Jethanandani References: <65CE3787-11DC-4216-B6F0-93B2EA411195@gmail.com> <53444484-149D-4B4D-B1FE-0F71AABF0E72@gmail.com> From: Peter Saint-Andre - &yet Message-ID: <55C2BF7B.1030809@andyet.net> Date: Wed, 5 Aug 2015 19:59:23 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-xmpp-dna.all@tools.ietf.org" , "ops-dir@ietf.org" , XMPP Working Group Subject: Re: [xmpp] OPS-DIR review of draft-ietf-xmpp-dna-10 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 01:59:30 -0000 Looping in the XMPP WG for completeness... On 8/5/15 7:40 PM, Peter Saint-Andre wrote: > Hi Mahesh, thanks for the review. Brief comments inline. > > On Aug 5, 2015, at 6:45 PM, Mahesh Jethanandani > wrote: > >> [Resending with the correct email address] >> >> I have reviewed this document as part of the Operational directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written with the intent of improving the >> operational aspects of the IETF drafts. Comments that are not >> addressed in last call may be included in AD reviews during the IESG >> review. Document editors and WG chairs should treat these comments >> just like any other last call comments. >> >> Status: >> >> Ready with issues. >> >> Summary: >> >> This document defines new “prototypes” used to establish a strong >> association between a domain name and an XML stream. There are two >> companion documents draft-ietf-xmpp-posh-04 >> and >> draft-ietf-dane-srv-12 >> that should be >> viewed as part of reviewing this document. >> >> If there are any management requirements to configure the new >> “prototypes”, they have not been discussed as part of this document. > > We introduced the concept of a prooftype (not prototype) in order to > explain the security approach here. No operator will directly deploy > prooftypes in the abstract. > >> I did not review the companion documents to see if management of the >> feature has been addressed in them. This document should talk about >> how the feature will be managed, even if it means referring to >> relevant sections of the other documents. > > That is a good point. We will need to think about this a bit more from > the ops and management perspective, and formulate some text. But I think > most or all of the text belongs in the dane-srv and POSH specs. > >> If there is a need to define a YANG model to configure the feature, it >> should be identified, even if it is not defined in this document. > > I have not seen YANG deployed with XMPP systems. > >> From an operational perspective, it would be helpful to know how this >> would be deployed in the field. Are there any issues beyond >> certificate configuration that operators should be aware of? Some of >> the services are replacements for existing services, e.g. DNS with >> secure DNS. How would the operators role out the service in the field >> with existing service(s)? > > Some of these issues are addressed by the relevant specifications (e.g., > about DNSSEC). In general for DNA these are matters for the specific > prooftypes. > >> Section 3: >> >> The document talks about establishing a client to server Domain Name >> Association (DNA) in this section. This is a simpler case of the >> server to server DNA. However, it is not clear what happens if the >> certificate verification fails. Is the behavior the same as when a >> self-signed certificate is presented? Is there a fallback process or >> does the session just terminate? > > That is covered by RFC 6120. We might to point to the relevant sections > of that spec. > > Peter > >> In addition, the following nits should be addressed in the document. >> >> Checking nits according tohttp://www.ietf.org/id-info/checklist : >> ---------------------------------------------------------------------------- >> >> == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the >> document. >> >> >> Checking references for intended status: Proposed Standard >> ---------------------------------------------------------------------------- >> >> (See RFCs 3967 and 4897 for information about using normative references >> to lower-maturity documents in RFCs) >> >> == Outdated reference: A later version (-14) exists of >> draft-ietf-dane-srv-12 >> >> ** Downref: Normative reference to an Informational RFC: RFC 4949 >> >> -- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0220' >> >> == Outdated reference: draft-ietf-uta-xmpp has been published as RFC 7590 >> >> -- Obsolete informational reference (is this intentional?): RFC 3920 >> (Obsoleted by RFC 6120) >> >> >> Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (—). >> >> Thanks. >> Mahesh Jethanandani >> mjethanandani@gmail.com >> >> >> >> >> From nobody Thu Aug 6 03:33:48 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042FC1B2C4B; Thu, 6 Aug 2015 03:33:45 -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 Gtq1_9PcKA9w; Thu, 6 Aug 2015 03:33:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2998E1B2C48; Thu, 6 Aug 2015 03:33:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.3.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150806103342.2703.18148.idtracker@ietfa.amsl.com> Date: Thu, 06 Aug 2015 03:33:42 -0700 Archived-At: Cc: draft-ietf-xmpp-dna.ad@ietf.org, draft-ietf-xmpp-dna@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, mjethanandani@gmail.com, draft-ietf-xmpp-dna.shepherd@ietf.org Subject: [xmpp] Benoit Claise's No Objection on draft-ietf-xmpp-dna-10: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 10:33:45 -0000 Benoit Claise has entered the following ballot position for draft-ietf-xmpp-dna-10: 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 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-xmpp-dna/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The conversation started between Mahesh (OPS-DIR reviewer) and the authors on the following points: Summary: This document defines new “prooftype” used to establish a strong association between a domain name and an XML stream. There are two companion documents draft-ietf-xmpp-posh-04 and draft-ietf-dane-srv-12 that should be viewed as part of reviewing this document. If there are any management requirements to configure the new “prooftype”, they have not been discussed as part of this document. I did not review the companion documents to see if management of the feature has been addressed in them. This document should talk about how the feature will be managed, even if it means referring to relevant sections of the other documents. If there is a need to define a YANG model to configure the feature, it should be identified, even if it is not defined in this document. >From an operational perspective, it would be helpful to know how this would be deployed in the field. Are there any issues beyond certificate configuration that operators should be aware of? Some of the services are replacements for existing services, e.g. DNS with secure DNS. How would the operators role out the service in the field with existing service(s)? Section 3: The document talks about establishing a client to server Domain Name Association (DNA) in this section. This is a simpler case of the server to server DNA. However, it is not clear what happens if the certificate verification fails. Is the behavior the same as when a self-signed certificate is presented? Is there a fallback process or does the session just terminate? In addition, the following nits should be addressed in the document. Checking nits according to http://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-14) exists of draft-ietf-dane-srv-12 ** Downref: Normative reference to an Informational RFC: RFC 4949 -- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0220' == Outdated reference: draft-ietf-uta-xmpp has been published as RFC 7590 -- Obsolete informational reference (is this intentional?): RFC 3920 (Obsoleted by RFC 6120) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (—). Thanks. From nobody Sat Aug 8 09:25:22 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F9A1A8AAD for ; Sat, 8 Aug 2015 09:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SE=0.35, 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 a3reBsFdfDLb for ; Sat, 8 Aug 2015 09:25:19 -0700 (PDT) Received: from mail.zash.se (ip66.hethane.riksnet.nu [85.11.25.66]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 016701A8A60 for ; Sat, 8 Aug 2015 09:25:18 -0700 (PDT) Received: from [IPv6:2001:470:def1:0:3402:83ad:1122:fedb] (unknown [IPv6:2001:470:def1:0:3402:83ad:1122:fedb]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: zash) by mail.zash.se (Postfix) with ESMTPSA id 9319163405 for ; Sat, 8 Aug 2015 18:25:14 +0200 (CEST) Message-ID: <55C62D65.8030802@zash.se> Date: Sat, 08 Aug 2015 18:25:09 +0200 From: Kim Alvefur User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: xmpp@ietf.org References: <20150805150225.15925.93150.idtracker@ietfa.amsl.com> In-Reply-To: <20150805150225.15925.93150.idtracker@ietfa.amsl.com> OpenPGP: id=3E52119EF853C59678DBBF6BADED9A77B67AD329; url=http://zash.se/~zash/pubkey.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aLGeeSGNgU1oNd9RwMIbKVDvBvsbMXCr7" Archived-At: Subject: Re: [xmpp] Stephen Farrell's No Objection on draft-ietf-xmpp-dna-10: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 16:25:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aLGeeSGNgU1oNd9RwMIbKVDvBvsbMXCr7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Just want reply to these: On 2015-08-05 17:02, Stephen Farrell wrote: > - section 3: does nobody ever use mutually authenticated > TLS for this with XMPP? (Just wondering.) No, mutual authentication using TLS for client-to-server connections is used, I believe, in some environments. > - 3.2: I didn't know that XMPP clients send a user ID in > cleartext before turning on TLS. Pity that. Is it ok > for a client to fake that and then later authenticate as > a different entity such as "usertwo@a.example"? I don't think many clients really do that, for privacy concern. Our server implementation doesn't care about the stream 'from' on client connections, regardless of security and authentication. --=20 Kim "Zash" Alvefur --aLGeeSGNgU1oNd9RwMIbKVDvBvsbMXCr7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAEBCgAGBQJVxi1lAAoJEK3tmne2etMp86AQAJh0/wEYy2MvPwa23PtVVSKM GXRpktNAGPreQujLpYQD2Vlsh050xxDKwTN8qB54zjoyQ3de2m2d4UoyPEFLii1C peM7MxfOxR8tFyJ794i3BzaWp5HF+2lz3RC5Q5EeNB43GibNDTcDgsuF1y+kEVBI gvpgLiTMQ2KkaJaOhA+8eWpKIGQOkd3yN+/jjHh8gmNREmC2F0k1RDvha9MLxodj NXnmqGeQI74LIA0A9f3GLzSqmmhTHykCDGQKw2CW5RM7waK1S7CE/7sqBziw5oEu kMsqROvQzfumMwHlutp/umnhJCoKEIuZjdkZ8VKZr81GNph5kMzBg8lHvLRngpaT RMYjIPk65T+CWi5zbfK8SUMOhwB7eGLh8pdvMLZameysrFozfEm/MYdfHcvFDGdE rasJv3EwXh3MyD6W6V0rmgHqLd3i/NwwZcZOoMJYvgbUfE3kLx74jJf8aq9FrgMw XhrjV7wWxxfN6OLrmLncW31X5bgOGzRb2JW9yfkH5Fryqz3moBJf8LCboBrcDjzM eAdaXidzWx3t4sVMCOVAdCBexxYorYA+3JK6nNA2+IwNsxetHnahwxyRWDiH7sWM tSmyT4iEaHxvZoahV5Br9O2H4BUuogCCAGTTb2vDxtV0g+ip7DfpQFHVbi/1/ru/ FQRHGJaiK/Unc6Jagnyb =Kziv -----END PGP SIGNATURE----- --aLGeeSGNgU1oNd9RwMIbKVDvBvsbMXCr7-- From nobody Mon Aug 10 16:31:37 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC931A1B4E for ; Mon, 10 Aug 2015 16:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 fLR9xOQB8Yrc for ; Mon, 10 Aug 2015 16:31:33 -0700 (PDT) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (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 DD5311A1AB6 for ; Mon, 10 Aug 2015 16:31:31 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so80169645igb.0 for ; Mon, 10 Aug 2015 16:31:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=aAlLvzd1w66ozQ9gxsM0CNGAVejetD53gYyHWUFHpYM=; b=HGsOq5Igjf10ty69ZBdTJN72hZuxU94yZ/22U06h83l6A8GSJOfTumH9O44bA9z1YB Z38VGdK0U4Opg8Fet8UN8Ag90/BAYiDu0OVYyA7zvUlnUiT7tdmIR/yBx1fFG4uxHWju oIykkiPtoWyjluKUs4t/O8MUWKOCvoiuIaeSjVqKTNYlZs2d46bAZgGvs7KN/IM6ZYbs VmkNN1ojq7j/p5OIK31EJHzNbCeLa1pa2J3SqtXrAkvy1X4KRUdn9rSzvA6RqdexVi00 5supZtmuOjj7+T0eXx1inV1ZvsIxde7/X5Ffjk3OzMc5iv3oPH6yh56RkUTh8tZUyJgg wx1g== X-Gm-Message-State: ALoCoQmUJrrz04HwYvIWBotU0jyombTe0R0eSRFbGibCBHJ1uKs21msVlt44/QYAFaNnJEyfBJuk X-Received: by 10.50.57.52 with SMTP id f20mr9812083igq.54.1439249491208; Mon, 10 Aug 2015 16:31:31 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id f126sm279062ioe.21.2015.08.10.16.31.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Aug 2015 16:31:29 -0700 (PDT) To: Benoit Claise , The IESG References: <20150806103342.2703.18148.idtracker@ietfa.amsl.com> From: Peter Saint-Andre - &yet Message-ID: <55C9344F.90201@andyet.net> Date: Mon, 10 Aug 2015 17:31:27 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150806103342.2703.18148.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-xmpp-dna.ad@ietf.org, draft-ietf-xmpp-dna@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, mjethanandani@gmail.com, draft-ietf-xmpp-dna.shepherd@ietf.org Subject: Re: [xmpp] Benoit Claise's No Objection on draft-ietf-xmpp-dna-10: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 23:31:35 -0000 Hi Benoit, I posted a reply to the OPS-DIR review here: https://mailarchive.ietf.org/arch/msg/xmpp/VymvhuVNfSFaNv8YEjpslzR_tw4 My feeling is that it would be best for this document to point to the companion documents (draft-ietf-xmpp-posh and draft-ietf-dane-srv) with regard to operations and management. Note that draft-ietf-dane-srv already includes the following text: ### 6. Guidance for Server Operators To conform to this specification, the published SRV records and subsequent address (A and AAAA) records MUST be secured with DNSSEC. There SHOULD also be at least one TLSA record published that authenticates the server's certificate. When using TLSA records with Certificate Usage "DANE-EE", it is not necessary for the deployed certificate to contain an identifier for either the source domain or target server host name. However, operators need to be aware that servers relying solely on validation using Certificate Usage "DANE-EE" TLSA records might prevent clients that do not support this specification from successfully connecting with TLS. For TLSA records with Certificate Usage types other than "DANE-EE", the certificate(s) MUST contain an identifier that matches: o the service domain name (the "source domain" in [RFC6125] terms, which is the SRV query domain); and/or o the target server host name (the "derived domain" in [RFC6125] terms, which is the SRV target host name). Servers that support multiple service domains (i.e., so-called "multi-tenanted environments") can implement the Transport Layer Security Server Name Indication (TLS SNI) [RFC6066] or its functional equivalent to determine which certificate to offer. Clients that do not support this specification will indicate a preference for the service domain name, while clients that support this specification will indicate the target server host name. However, the server determines what certificate to present in the TLS handshake; e.g., the presented certificate might only authenticate the target server host name. ### Is that text helpful and complete? (Note that draft-ietf-dane-srv has already been approved for publication, but if we need to make some slight adjustments during AUTH48 we could do so.) Also, do you think it would be preferable for draft-ietf-xmpp-posh to include a similar section providing guidance for server operators in draft-ietf-xmpp-posh? If so, Matt and I can work to formulate some text. Thanks! Peter On 8/6/15 4:33 AM, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > draft-ietf-xmpp-dna-10: 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 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-xmpp-dna/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The conversation started between Mahesh (OPS-DIR reviewer) and the > authors on the following points: > > Summary: > > This document defines new “prooftype” used to establish a strong > association between a domain name and an XML stream. There are two > companion documents draft-ietf-xmpp-posh-04 and draft-ietf-dane-srv-12 > that should be viewed as part of reviewing this document. > > If there are any management requirements to configure the new > “prooftype”, they have not been discussed as part of this document. I did > not review the companion documents to see if management of the feature > has been addressed in them. This document should talk about how the > feature will be managed, even if it means referring to relevant sections > of the other documents. If there is a need to define a YANG model to > configure the feature, it should be identified, even if it is not defined > in this document. > >>From an operational perspective, it would be helpful to know how this > would be deployed in the field. Are there any issues beyond certificate > configuration that operators should be aware of? Some of the services are > replacements for existing services, e.g. DNS with secure DNS. How would > the operators role out the service in the field with existing > service(s)? > > Section 3: > > The document talks about establishing a client to server Domain Name > Association (DNA) in this section. This is a simpler case of the server > to server DNA. However, it is not clear what happens if the certificate > verification fails. Is the behavior the same as when a self-signed > certificate is presented? Is there a fallback process or does the session > just terminate? > > In addition, the following nits should be addressed in the document. > > Checking nits according to http://www.ietf.org/id-info/checklist : > > ---------------------------------------------------------------------------- > > == There are 2 instances of lines with non-RFC2606-compliant FQDNs in > the > document. > > > Checking references for intended status: Proposed Standard > > ---------------------------------------------------------------------------- > > (See RFCs 3967 and 4897 for information about using normative > references > to lower-maturity documents in RFCs) > > == Outdated reference: A later version (-14) exists of > draft-ietf-dane-srv-12 > > ** Downref: Normative reference to an Informational RFC: RFC 4949 > > -- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0220' > > == Outdated reference: draft-ietf-uta-xmpp has been published as RFC > 7590 > > -- Obsolete informational reference (is this intentional?): RFC 3920 > (Obsoleted by RFC 6120) > > > Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments > (—). > > > Thanks. > > -- Peter Saint-Andre https://andyet.com/ From nobody Mon Aug 10 16:55:27 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872E21A1BE6 for ; Mon, 10 Aug 2015 16:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 c0ZrCtD1DkU0 for ; Mon, 10 Aug 2015 16:55:23 -0700 (PDT) Received: from mail-io0-f180.google.com (mail-io0-f180.google.com [209.85.223.180]) (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 B57F11A1B4E for ; Mon, 10 Aug 2015 16:55:22 -0700 (PDT) Received: by ioeg141 with SMTP id g141so186092800ioe.3 for ; Mon, 10 Aug 2015 16:55:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Ozba4W1LZT/b0JAEwAxb6YzNrt/ot8VNpMhOb9qli28=; b=i+/EbSfm4eEMZfseq8xSaX5JW3kZ+hliUgUtoDBab0QWAv7tXEfNtrAd73oR6BUv19 mbTGQgIe/WET1cWu7EHsueaL0BeGAwe7TswrfnG8b+h5ZoEYtfoJRlBhirwhbrkfYk7z AH6+MeBeMxZIKMA1cyibQlJd4B/LWin/ywr7vmSH104E70vN6Dlb8Ta4t72qfQsGjzli KdQ7Qmf+0NbQSFx6YzNQD4k3LvtnVowy3/yF8xgOmqBPuuSkEIL1qMXypkaTaJPaLWkI g1Oj6+aUTZnlbIm40tDMABzJNoQYLlb7enyzobfKyw1Lz82rlbT6DcdA8Wyo+0EPWHMG 5hPg== X-Gm-Message-State: ALoCoQlU1V+/J0S1MycksEjY9oR2j5Zjh9r/daiA92iWPKw/hU8ybAfdFHyWwtTEunBRYFtZ10EM X-Received: by 10.107.137.217 with SMTP id t86mr28944422ioi.103.1439250922071; Mon, 10 Aug 2015 16:55:22 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id cr1sm316932igb.15.2015.08.10.16.55.19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Aug 2015 16:55:20 -0700 (PDT) To: Stephen Farrell , The IESG References: <20150805150225.15925.93150.idtracker@ietfa.amsl.com> From: Peter Saint-Andre - &yet Message-ID: <55C939E6.1000609@andyet.net> Date: Mon, 10 Aug 2015 17:55:18 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150805150225.15925.93150.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-xmpp-dna.ad@ietf.org, xmpp-chairs@ietf.org, draft-ietf-xmpp-dna@ietf.org, xmpp@ietf.org, draft-ietf-xmpp-dna.shepherd@ietf.org Subject: Re: [xmpp] Stephen Farrell's No Objection on draft-ietf-xmpp-dna-10: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 23:55:25 -0000 Hi Stephen, thanks for the review, and my apologies regarding the delayed reply. On 8/5/15 9:02 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-xmpp-dna-10: 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 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-xmpp-dna/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - section 3: does nobody ever use mutually authenticated > TLS for this with XMPP? (Just wondering.) As Kim noted, it happens, but it's not yet widespread. > - 3.2: I didn't know that XMPP clients send a user ID in > cleartext before turning on TLS. They can. Section 4.7.1 of RFC 6120 states: For initial stream headers in client-to-server communication, the 'from' attribute is the XMPP identity of the principal controlling the client, i.e., a JID of the form . The client might not know the XMPP identity, e.g., because the XMPP identity is assigned at a level other than the XMPP application layer (as in the Generic Security Service Application Program Interface [GSS-API]) or is derived by the server from information provided by the client (as in some deployments of end-user certificates with the SASL EXTERNAL mechanism). Furthermore, if the client considers the XMPP identity to be private information then it is advised not to include a 'from' attribute before the confidentiality and integrity of the stream are protected via TLS or an equivalent security layer. However, if the client knows the XMPP identity then it SHOULD include the 'from' attribute after the confidentiality and integrity of the stream are protected via TLS or an equivalent security layer. > Pity that. Is it ok > for a client to fake that and then later authenticate as > a different entity such as "usertwo@a.example"? The 'from' is not required on initial stream headers, and it is perfectly acceptable to not include it (which is what most clients do). > - 3.2, step 5: "proving" isn't quite right but is good > enough here. OK. We are using "proof" here in the sense later described in Section 5: The foregoing protocol flows assumed that domain name associations were proved using the PKI prooftype specified in [RFC6120]: that is, the server's proof consists of a PKIX certificate that is checked according to the XMPP profile [RFC6120] of the matching rules from [RFC6125] (and the overall validation rules from [RFC5280]), the client's verification material is obtained out of band in the form of a trusted root, and secure DNS is not necessary. Perhaps a forward pointer would be helpful? > - 4.1: Please separate the seperable pictures by at > least some whitespace but ideally with captions. Right > now it looks initially as if it's just one big figure. > At present, I find that figure makes things less clear > rather than more. OK, we'll try to break it into smaller chunks. > - 4.2, bullets: the 2nd last one here is really similar > to the 1st two (as I read 'em). Maybe consider merging. I don't quite follow. > And the use of "is trusted by" in the 1st two is a bit > inaccurate, but could be lived with;-) Maybe "is acceptable to" would be better? I agree that "trust" is a slippery notion. > - 4.4.1: should the refs for dialback (and the "first > specified..." comment) be earlier? There is a reference in the first paragraph of Section 4, but do you mean that it needs to be mentioned even sooner? > - 5.1: Is there going to be another "XMPP with DANE > prooftype" document? I'm not sure that 5.1 alone is > enough, and there is one for POSH, so I wondered. At IETF 89, Matt and I chatted with Jon Peterson, who was concerned about the possible need to write DANE-SRV profile documents for every SRV-using application protocol. To address his concern, we established reasonable defaults in draft-ietf-dane-srv, thus enabling application protocol specifications to re-use what's in draft-ietf-dane-srv or use it with only slight modifications or additions. The last two bullet points in draft-ietf-xmpp-dna specify some adjustments for XMPP, but everything *should* be covered by draft-ietf-dane-srv. Or at least that was the intent. > - 5.2: does this repeat text from the POSH I-D? If so, > is that a good idea? > > - 8.1: Huh? Why aren't these in the POSH I-d? Although we went back and forth on the matter for a long time, we eventually decided to place the XMPP DNA prooftype information (such as the .well-known registrations and the prooftype definitions) for both the DANE prooftype and the POSH prooftype in the XMPP DNA spec. The reasoning is that theoretically the POSH I-D is not XMPP-specific and could be re-used by other application protocols (as can the DANE-SRV I-D). > - 8.1/8.2: Is it a good/bad idea to have structure in > the .well-known URIs and where that structure is not a > pathname? Personally, I think it's not a great idea but > that's just a personal preference. As you know, see the thread with Barry. > I also don't think > "_tcp.json" is good to include in the URI. Why not? Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Aug 10 19:17:14 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645321A8943 for ; Mon, 10 Aug 2015 19:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 RLaVVFHuDRyX for ; Mon, 10 Aug 2015 19:17:10 -0700 (PDT) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (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 4FFE91A891B for ; Mon, 10 Aug 2015 19:17:10 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so82065521igb.0 for ; Mon, 10 Aug 2015 19:17:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=FgCDgKeIgeEBr0zFRgOVvwI74cMI324kXGO3Y7fBizg=; b=dKyukcad5pOGVFvotqkBcPHuEX6uGHVfLRry70RKDV4dpVHYg6adwSvrdTFE5QKIX1 Y6KZMv8G0BZ3EQXY8Dc+CdzvMIsK2yF0n0BLNdK++v19Y43d5pZiDHM0DUDWL+OWqge3 lJrlbBoXfQmG5LUjPeY+U1lOgvSX2iRizy/Mn+RwHRZyxiUQrhrHkWTgVJlijxwFDmQc V5WedVqgcc3oXfux4zZtCPYuwOBYyuoYIB+ZNF08dJp/L6dxENzlFp+Jvmy0T518OH4J YoZCUZIlgRqcejWGCocxxBex+OZeZgbvDO9u1GCKmy/Kp9iOODfxtY5sbU6YNASUXMIf ORzg== X-Gm-Message-State: ALoCoQnJvl63dBTmc8LWmdC61MbVgShAztH+wdriWbkluVAhB9bBKCPP6MMvlitB3EcNdc7xMnMI X-Received: by 10.50.111.164 with SMTP id ij4mr14466410igb.70.1439259429565; Mon, 10 Aug 2015 19:17:09 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id m134sm543894ioe.42.2015.08.10.19.17.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Aug 2015 19:17:08 -0700 (PDT) To: Mahesh Jethanandani References: <20150806103342.2703.18148.idtracker@ietfa.amsl.com> <55C9344F.90201@andyet.net> <11AAE863-30CB-4B50-90FE-C83D68E434EA@gmail.com> From: Peter Saint-Andre - &yet Message-ID: <55C95B20.3050902@andyet.net> Date: Mon, 10 Aug 2015 20:17:04 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <11AAE863-30CB-4B50-90FE-C83D68E434EA@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-xmpp-dna.ad@ietf.org, draft-ietf-xmpp-dna@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, The IESG , Benoit Claise , draft-ietf-xmpp-dna.shepherd@ietf.org Subject: Re: [xmpp] Benoit Claise's No Objection on draft-ietf-xmpp-dna-10: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 02:17:13 -0000 Hi Mahesh, I suggest that we add a section something like the following to draft-ietf-xmpp-dna and then add a section to draft-ietf-xmpp-posh as well (I haven't written any text for the latter yet, thus the "FIXME" for a section number in what follows). ### 8. Guidance for Server Operators This document introduces the concept of a prooftype in order to explain and generalize the approach to establishing a strong association between the DNS domain name of an XMPP service and the XML stream that a client or peer server initiates with that service. The operators of XMPP services will not directly deploy DNA prooftypes, and the operations and management implications will depend on the prooftypes that an operator supports. For example: o To support the PKIX prooftype [RFC6120], an operator needs to interact with a certification authority but does not need to deploy DNS security. o To support the DANE prooftype [I-D.ietf-dane-srv], an operator can generate its own certificates or obtain them from a certification authority but needs to deploy DNS security. o To support the POSH prooftype [I-D.ietf-xmpp-posh], an operator can generate its own certificates or obtain them from a certification authority but does not need to deploy DNS security. Considerations for use of the foregoing prooftypes are explained in the relevant specifications. See in particular Section 13.7 of [RFC6120], Section 6 of [I-D.ietf-dane-srv], and Section FIXME of [I-D.ietf-xmpp-posh]. Naturally, these operations and management considerations are additive: if an operator wishes to use multiple prooftypes, the complexity of deployment increases (e.g., the operator might want to obtain a PKIX certificate from a certification authority for use in the PKIX prooftype and generate its own certificate for use in the DANE prooftype). This is an unavoidable aspect of supporting as many prooftypes as needed in order to ensure that domain name associations can be established in the largest possible percentage of cases. ### What do you think? (I haven't shared this text yet with my co-authors, since I've been working on it just now.) Peter On 8/10/15 8:09 PM, Mahesh Jethanandani wrote: > Peter, > > I agree. As I suggested in the review, a reference to the section you reproduce below from draft-ietf-dane-srv (and a similar reference to a section in draft-ietf-xmpp-posh) is what you need in draft-ietf-xmpp-dna. > > Cheers. > >> On Aug 10, 2015, at 4:31 PM, Peter Saint-Andre - &yet wrote: >> >> Hi Benoit, I posted a reply to the OPS-DIR review here: >> >> https://mailarchive.ietf.org/arch/msg/xmpp/VymvhuVNfSFaNv8YEjpslzR_tw4 >> >> My feeling is that it would be best for this document to point to the companion documents (draft-ietf-xmpp-posh and draft-ietf-dane-srv) with regard to operations and management. Note that draft-ietf-dane-srv already includes the following text: >> >> ### >> >> 6. Guidance for Server Operators >> >> To conform to this specification, the published SRV records and >> subsequent address (A and AAAA) records MUST be secured with DNSSEC. >> There SHOULD also be at least one TLSA record published that >> authenticates the server's certificate. >> >> When using TLSA records with Certificate Usage "DANE-EE", it is not >> necessary for the deployed certificate to contain an identifier for >> either the source domain or target server host name. However, >> operators need to be aware that servers relying solely on validation >> using Certificate Usage "DANE-EE" TLSA records might prevent clients >> that do not support this specification from successfully connecting >> with TLS. >> >> For TLSA records with Certificate Usage types other than "DANE-EE", >> the certificate(s) MUST contain an identifier that matches: >> >> o the service domain name (the "source domain" in [RFC6125] terms, >> which is the SRV query domain); and/or >> >> o the target server host name (the "derived domain" in [RFC6125] >> terms, which is the SRV target host name). >> >> Servers that support multiple service domains (i.e., so-called >> "multi-tenanted environments") can implement the Transport Layer >> Security Server Name Indication (TLS SNI) [RFC6066] or its functional >> equivalent to determine which certificate to offer. Clients that do >> not support this specification will indicate a preference for the >> service domain name, while clients that support this specification >> will indicate the target server host name. However, the server >> determines what certificate to present in the TLS handshake; e.g., >> the presented certificate might only authenticate the target server >> host name. >> >> ### >> >> Is that text helpful and complete? (Note that draft-ietf-dane-srv has already been approved for publication, but if we need to make some slight adjustments during AUTH48 we could do so.) >> >> Also, do you think it would be preferable for draft-ietf-xmpp-posh to include a similar section providing guidance for server operators in draft-ietf-xmpp-posh? If so, Matt and I can work to formulate some text. >> >> Thanks! >> >> Peter >> >> On 8/6/15 4:33 AM, Benoit Claise wrote: >>> Benoit Claise has entered the following ballot position for >>> draft-ietf-xmpp-dna-10: 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 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-xmpp-dna/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> The conversation started between Mahesh (OPS-DIR reviewer) and the >>> authors on the following points: >>> >>> Summary: >>> >>> This document defines new “prooftype” used to establish a strong >>> association between a domain name and an XML stream. There are two >>> companion documents draft-ietf-xmpp-posh-04 and draft-ietf-dane-srv-12 >>> that should be viewed as part of reviewing this document. >>> >>> If there are any management requirements to configure the new >>> “prooftype”, they have not been discussed as part of this document. I did >>> not review the companion documents to see if management of the feature >>> has been addressed in them. This document should talk about how the >>> feature will be managed, even if it means referring to relevant sections >>> of the other documents. If there is a need to define a YANG model to >>> configure the feature, it should be identified, even if it is not defined >>> in this document. >>> >>>> From an operational perspective, it would be helpful to know how this >>> would be deployed in the field. Are there any issues beyond certificate >>> configuration that operators should be aware of? Some of the services are >>> replacements for existing services, e.g. DNS with secure DNS. How would >>> the operators role out the service in the field with existing >>> service(s)? >>> >>> Section 3: >>> >>> The document talks about establishing a client to server Domain Name >>> Association (DNA) in this section. This is a simpler case of the server >>> to server DNA. However, it is not clear what happens if the certificate >>> verification fails. Is the behavior the same as when a self-signed >>> certificate is presented? Is there a fallback process or does the session >>> just terminate? >>> >>> In addition, the following nits should be addressed in the document. >>> >>> Checking nits according to http://www.ietf.org/id-info/checklist : >>> >>> ---------------------------------------------------------------------------- >>> >>> == There are 2 instances of lines with non-RFC2606-compliant FQDNs in >>> the >>> document. >>> >>> >>> Checking references for intended status: Proposed Standard >>> >>> ---------------------------------------------------------------------------- >>> >>> (See RFCs 3967 and 4897 for information about using normative >>> references >>> to lower-maturity documents in RFCs) >>> >>> == Outdated reference: A later version (-14) exists of >>> draft-ietf-dane-srv-12 >>> >>> ** Downref: Normative reference to an Informational RFC: RFC 4949 >>> >>> -- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0220' >>> >>> == Outdated reference: draft-ietf-uta-xmpp has been published as RFC >>> 7590 >>> >>> -- Obsolete informational reference (is this intentional?): RFC 3920 >>> (Obsoleted by RFC 6120) >>> >>> >>> Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments >>> (—). >>> >>> >>> Thanks. >>> >>> From nobody Mon Aug 10 20:10:17 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00861A8907; Mon, 10 Aug 2015 19:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-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 7Wk--BHpUYQB; Mon, 10 Aug 2015 19:09:04 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (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 9D2401A891B; Mon, 10 Aug 2015 19:08:28 -0700 (PDT) Received: by pawu10 with SMTP id u10so152543357paw.1; Mon, 10 Aug 2015 19:08:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xX6z2+U03/v1C/aE5Iv4Ue2Xq+6VAcXPjZ1xIXin6O0=; b=xVfzz6rXh13xKkAusx+SYJqNwFVkCnllrdBwrs/1aw/Pg0X4j8bLuqu3cFxG/WtFzC TkFKygpGc0r6Y/kwPczGnTc7+5SSxp46jTNOAJ1KUlIzXF16Q78zCqowiUOx/xNQB+pP h+fy1frRZyjx9ld0ep1fwSd0zLHEQBsRqnr28zJnprK2Z8SVthrS8pAuMHvc3quwngbT BLI8wOLdeBTBdzM48uSRdlX79DoGBAfFTGGgNnyZJ3pCuNJE8AMzV/c+Rh2OGR+d3Ex9 B1YCpi09ONKc6K38YSS4s+72tSbJCAGc6srMDBTeQzk1zPirMC7qh7Knt6o6AKWd9v7L 43rQ== X-Received: by 10.68.194.170 with SMTP id hx10mr51260829pbc.64.1439258908138; Mon, 10 Aug 2015 19:08:28 -0700 (PDT) Received: from [10.24.84.226] ([128.107.241.188]) by smtp.gmail.com with ESMTPSA id qc2sm354058pbc.79.2015.08.10.19.08.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Aug 2015 19:08:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Mahesh Jethanandani In-Reply-To: <55C9344F.90201@andyet.net> Date: Mon, 10 Aug 2015 19:09:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <11AAE863-30CB-4B50-90FE-C83D68E434EA@gmail.com> References: <20150806103342.2703.18148.idtracker@ietfa.amsl.com> <55C9344F.90201@andyet.net> To: Peter Saint-Andre - &yet X-Mailer: Apple Mail (2.2098) Archived-At: X-Mailman-Approved-At: Mon, 10 Aug 2015 20:10:17 -0700 Cc: draft-ietf-xmpp-dna.ad@ietf.org, draft-ietf-xmpp-dna@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, The IESG , Benoit Claise , draft-ietf-xmpp-dna.shepherd@ietf.org Subject: Re: [xmpp] Benoit Claise's No Objection on draft-ietf-xmpp-dna-10: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 02:09:06 -0000 Peter, I agree. As I suggested in the review, a reference to the section you = reproduce below from draft-ietf-dane-srv (and a similar reference to a = section in draft-ietf-xmpp-posh) is what you need in = draft-ietf-xmpp-dna. Cheers. > On Aug 10, 2015, at 4:31 PM, Peter Saint-Andre - &yet = wrote: >=20 > Hi Benoit, I posted a reply to the OPS-DIR review here: >=20 > https://mailarchive.ietf.org/arch/msg/xmpp/VymvhuVNfSFaNv8YEjpslzR_tw4 >=20 > My feeling is that it would be best for this document to point to the = companion documents (draft-ietf-xmpp-posh and draft-ietf-dane-srv) with = regard to operations and management. Note that draft-ietf-dane-srv = already includes the following text: >=20 > ### >=20 > 6. Guidance for Server Operators >=20 > To conform to this specification, the published SRV records and > subsequent address (A and AAAA) records MUST be secured with DNSSEC. > There SHOULD also be at least one TLSA record published that > authenticates the server's certificate. >=20 > When using TLSA records with Certificate Usage "DANE-EE", it is not > necessary for the deployed certificate to contain an identifier for > either the source domain or target server host name. However, > operators need to be aware that servers relying solely on validation > using Certificate Usage "DANE-EE" TLSA records might prevent clients > that do not support this specification from successfully connecting > with TLS. >=20 > For TLSA records with Certificate Usage types other than "DANE-EE", > the certificate(s) MUST contain an identifier that matches: >=20 > o the service domain name (the "source domain" in [RFC6125] terms, > which is the SRV query domain); and/or >=20 > o the target server host name (the "derived domain" in [RFC6125] > terms, which is the SRV target host name). >=20 > Servers that support multiple service domains (i.e., so-called > "multi-tenanted environments") can implement the Transport Layer > Security Server Name Indication (TLS SNI) [RFC6066] or its = functional > equivalent to determine which certificate to offer. Clients that do > not support this specification will indicate a preference for the > service domain name, while clients that support this specification > will indicate the target server host name. However, the server > determines what certificate to present in the TLS handshake; e.g., > the presented certificate might only authenticate the target server > host name. >=20 > ### >=20 > Is that text helpful and complete? (Note that draft-ietf-dane-srv has = already been approved for publication, but if we need to make some = slight adjustments during AUTH48 we could do so.) >=20 > Also, do you think it would be preferable for draft-ietf-xmpp-posh to = include a similar section providing guidance for server operators in = draft-ietf-xmpp-posh? If so, Matt and I can work to formulate some text. >=20 > Thanks! >=20 > Peter >=20 > On 8/6/15 4:33 AM, Benoit Claise wrote: >> Benoit Claise has entered the following ballot position for >> draft-ietf-xmpp-dna-10: No Objection >>=20 >> 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.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> The conversation started between Mahesh (OPS-DIR reviewer) and the >> authors on the following points: >>=20 >> Summary: >>=20 >> This document defines new =E2=80=9Cprooftype=E2=80=9D used to = establish a strong >> association between a domain name and an XML stream. There are two >> companion documents draft-ietf-xmpp-posh-04 and = draft-ietf-dane-srv-12 >> that should be viewed as part of reviewing this document. >>=20 >> If there are any management requirements to configure the new >> =E2=80=9Cprooftype=E2=80=9D, they have not been discussed as part of = this document. I did >> not review the companion documents to see if management of the = feature >> has been addressed in them. This document should talk about how the >> feature will be managed, even if it means referring to relevant = sections >> of the other documents. If there is a need to define a YANG model to >> configure the feature, it should be identified, even if it is not = defined >> in this document. >>=20 >>> =46rom an operational perspective, it would be helpful to know how = this >> would be deployed in the field. Are there any issues beyond = certificate >> configuration that operators should be aware of? Some of the services = are >> replacements for existing services, e.g. DNS with secure DNS. How = would >> the operators role out the service in the field with existing >> service(s)? >>=20 >> Section 3: >>=20 >> The document talks about establishing a client to server Domain Name >> Association (DNA) in this section. This is a simpler case of the = server >> to server DNA. However, it is not clear what happens if the = certificate >> verification fails. Is the behavior the same as when a self-signed >> certificate is presented? Is there a fallback process or does the = session >> just terminate? >>=20 >> In addition, the following nits should be addressed in the document. >>=20 >> Checking nits according to http://www.ietf.org/id-info/checklist : >>=20 >> = --------------------------------------------------------------------------= -- >>=20 >> =3D=3D There are 2 instances of lines with non-RFC2606-compliant = FQDNs in >> the >> document. >>=20 >>=20 >> Checking references for intended status: Proposed Standard >>=20 >> = --------------------------------------------------------------------------= -- >>=20 >> (See RFCs 3967 and 4897 for information about using normative >> references >> to lower-maturity documents in RFCs) >>=20 >> =3D=3D Outdated reference: A later version (-14) exists of >> draft-ietf-dane-srv-12 >>=20 >> ** Downref: Normative reference to an Informational RFC: RFC 4949 >>=20 >> -- Possible downref: Non-RFC (?) normative reference: ref. = 'XEP-0220' >>=20 >> =3D=3D Outdated reference: draft-ietf-uta-xmpp has been published = as RFC >> 7590 >>=20 >> -- Obsolete informational reference (is this intentional?): RFC = 3920 >> (Obsoleted by RFC 6120) >>=20 >>=20 >> Summary: 1 error (**), 0 flaws (~~), 3 warnings (=3D=3D), 3 = comments >> (=E2=80=94). >>=20 >>=20 >> Thanks. >>=20 >>=20 >=20 >=20 > --=20 > Peter Saint-Andre > https://andyet.com/ Mahesh Jethanandani mjethanandani@gmail.com From nobody Mon Aug 10 20:10:19 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9AE61A89A2; Mon, 10 Aug 2015 19:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-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 zICUe_os7IrD; Mon, 10 Aug 2015 19:26:53 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (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 6E4C71A89AC; Mon, 10 Aug 2015 19:26:51 -0700 (PDT) Received: by pdrg1 with SMTP id g1so77877922pdr.2; Mon, 10 Aug 2015 19:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t0KBT9EyrHsJlbb4u+l5drSoPjCDEDdTmJudqucWM+4=; b=yuMwMpMTcqVcdUbpyhQBVptxa0iGJFZwrsbF6nRpY2fzw/LG3yi+LGKO5RFpPnM4ZC qsK7TF0Li6RGDh3dtPNG9amTBDwL33S1XV2U65YJ9F1GqfUsOHmGTQ4nxlMf7g1K7caS XwcF6Xt7Kb6q3aLFviUnjmZtVdBHj7WV11pkqaBhfLAWr3lX12xrnlOb0Cvuxa+9kkX0 L44Q+pCz+3O8zgX8fulQKDvAqMpQFGTCiwWyDouu1y12uHJZvyB5iIbyeqTfd1ULwXKU 7khcs1NbipkmvN03ldW+a/IFeoPdYgSwbLyRxqKZ6v97Zt3gV9viO7QYitK/zW6moTqZ Zq7A== X-Received: by 10.70.36.138 with SMTP id q10mr8957705pdj.32.1439260011079; Mon, 10 Aug 2015 19:26:51 -0700 (PDT) Received: from ?IPv6:2001:420:c0c8:1003::323? ([2001:420:c0c8:1003::323]) by smtp.gmail.com with ESMTPSA id k5sm400815pdo.48.2015.08.10.19.26.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Aug 2015 19:26:50 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Mahesh Jethanandani In-Reply-To: <55C95B20.3050902@andyet.net> Date: Mon, 10 Aug 2015 19:27:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8208F533-C48C-48DC-8756-7A3F99938F67@gmail.com> References: <20150806103342.2703.18148.idtracker@ietfa.amsl.com> <55C9344F.90201@andyet.net> <11AAE863-30CB-4B50-90FE-C83D68E434EA@gmail.com> <55C95B20.3050902@andyet.net> To: Peter Saint-Andre - &yet X-Mailer: Apple Mail (2.2098) Archived-At: X-Mailman-Approved-At: Mon, 10 Aug 2015 20:10:17 -0700 Cc: draft-ietf-xmpp-dna.ad@ietf.org, draft-ietf-xmpp-dna@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, The IESG , Benoit Claise , draft-ietf-xmpp-dna.shepherd@ietf.org Subject: Re: [xmpp] Benoit Claise's No Objection on draft-ietf-xmpp-dna-10: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 02:26:55 -0000 Hi Peter, The text looks good to me. Thanks. > On Aug 10, 2015, at 7:17 PM, Peter Saint-Andre - &yet = wrote: >=20 > Hi Mahesh, >=20 > I suggest that we add a section something like the following to = draft-ietf-xmpp-dna and then add a section to draft-ietf-xmpp-posh as = well (I haven't written any text for the latter yet, thus the "FIXME" = for a section number in what follows). >=20 > ### >=20 > 8. Guidance for Server Operators >=20 > This document introduces the concept of a prooftype in order to > explain and generalize the approach to establishing a strong > association between the DNS domain name of an XMPP service and the > XML stream that a client or peer server initiates with that service. >=20 > The operators of XMPP services will not directly deploy DNA > prooftypes, and the operations and management implications will > depend on the prooftypes that an operator supports. For example: >=20 > o To support the PKIX prooftype [RFC6120], an operator needs to > interact with a certification authority but does not need to > deploy DNS security. >=20 > o To support the DANE prooftype [I-D.ietf-dane-srv], an operator = can > generate its own certificates or obtain them from a certification > authority but needs to deploy DNS security. >=20 > o To support the POSH prooftype [I-D.ietf-xmpp-posh], an operator > can generate its own certificates or obtain them from a > certification authority but does not need to deploy DNS security. >=20 > Considerations for use of the foregoing prooftypes are explained in > the relevant specifications. See in particular Section 13.7 of > [RFC6120], Section 6 of [I-D.ietf-dane-srv], and Section FIXME of > [I-D.ietf-xmpp-posh]. >=20 > Naturally, these operations and management considerations are > additive: if an operator wishes to use multiple prooftypes, the > complexity of deployment increases (e.g., the operator might want to > obtain a PKIX certificate from a certification authority for use in > the PKIX prooftype and generate its own certificate for use in the > DANE prooftype). This is an unavoidable aspect of supporting as = many > prooftypes as needed in order to ensure that domain name = associations > can be established in the largest possible percentage of cases. >=20 > ### >=20 > What do you think? >=20 > (I haven't shared this text yet with my co-authors, since I've been = working on it just now.) >=20 > Peter >=20 > On 8/10/15 8:09 PM, Mahesh Jethanandani wrote: >> Peter, >>=20 >> I agree. As I suggested in the review, a reference to the section you = reproduce below from draft-ietf-dane-srv (and a similar reference to a = section in draft-ietf-xmpp-posh) is what you need in = draft-ietf-xmpp-dna. >>=20 >> Cheers. >>=20 >>> On Aug 10, 2015, at 4:31 PM, Peter Saint-Andre - &yet = wrote: >>>=20 >>> Hi Benoit, I posted a reply to the OPS-DIR review here: >>>=20 >>> = https://mailarchive.ietf.org/arch/msg/xmpp/VymvhuVNfSFaNv8YEjpslzR_tw4 >>>=20 >>> My feeling is that it would be best for this document to point to = the companion documents (draft-ietf-xmpp-posh and draft-ietf-dane-srv) = with regard to operations and management. Note that draft-ietf-dane-srv = already includes the following text: >>>=20 >>> ### >>>=20 >>> 6. Guidance for Server Operators >>>=20 >>> To conform to this specification, the published SRV records and >>> subsequent address (A and AAAA) records MUST be secured with = DNSSEC. >>> There SHOULD also be at least one TLSA record published that >>> authenticates the server's certificate. >>>=20 >>> When using TLSA records with Certificate Usage "DANE-EE", it is = not >>> necessary for the deployed certificate to contain an identifier = for >>> either the source domain or target server host name. However, >>> operators need to be aware that servers relying solely on = validation >>> using Certificate Usage "DANE-EE" TLSA records might prevent = clients >>> that do not support this specification from successfully = connecting >>> with TLS. >>>=20 >>> For TLSA records with Certificate Usage types other than = "DANE-EE", >>> the certificate(s) MUST contain an identifier that matches: >>>=20 >>> o the service domain name (the "source domain" in [RFC6125] = terms, >>> which is the SRV query domain); and/or >>>=20 >>> o the target server host name (the "derived domain" in [RFC6125] >>> terms, which is the SRV target host name). >>>=20 >>> Servers that support multiple service domains (i.e., so-called >>> "multi-tenanted environments") can implement the Transport Layer >>> Security Server Name Indication (TLS SNI) [RFC6066] or its = functional >>> equivalent to determine which certificate to offer. Clients that = do >>> not support this specification will indicate a preference for the >>> service domain name, while clients that support this specification >>> will indicate the target server host name. However, the server >>> determines what certificate to present in the TLS handshake; e.g., >>> the presented certificate might only authenticate the target = server >>> host name. >>>=20 >>> ### >>>=20 >>> Is that text helpful and complete? (Note that draft-ietf-dane-srv = has already been approved for publication, but if we need to make some = slight adjustments during AUTH48 we could do so.) >>>=20 >>> Also, do you think it would be preferable for draft-ietf-xmpp-posh = to include a similar section providing guidance for server operators in = draft-ietf-xmpp-posh? If so, Matt and I can work to formulate some text. >>>=20 >>> Thanks! >>>=20 >>> Peter >>>=20 >>> On 8/6/15 4:33 AM, Benoit Claise wrote: >>>> Benoit Claise has entered the following ballot position for >>>> draft-ietf-xmpp-dna-10: No Objection >>>>=20 >>>> 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.) >>>>=20 >>>>=20 >>>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/ >>>>=20 >>>>=20 >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> COMMENT: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> The conversation started between Mahesh (OPS-DIR reviewer) and the >>>> authors on the following points: >>>>=20 >>>> Summary: >>>>=20 >>>> This document defines new =E2=80=9Cprooftype=E2=80=9D used to = establish a strong >>>> association between a domain name and an XML stream. There are two >>>> companion documents draft-ietf-xmpp-posh-04 and = draft-ietf-dane-srv-12 >>>> that should be viewed as part of reviewing this document. >>>>=20 >>>> If there are any management requirements to configure the new >>>> =E2=80=9Cprooftype=E2=80=9D, they have not been discussed as part = of this document. I did >>>> not review the companion documents to see if management of the = feature >>>> has been addressed in them. This document should talk about how the >>>> feature will be managed, even if it means referring to relevant = sections >>>> of the other documents. If there is a need to define a YANG model = to >>>> configure the feature, it should be identified, even if it is not = defined >>>> in this document. >>>>=20 >>>>> =46rom an operational perspective, it would be helpful to know how = this >>>> would be deployed in the field. Are there any issues beyond = certificate >>>> configuration that operators should be aware of? Some of the = services are >>>> replacements for existing services, e.g. DNS with secure DNS. How = would >>>> the operators role out the service in the field with existing >>>> service(s)? >>>>=20 >>>> Section 3: >>>>=20 >>>> The document talks about establishing a client to server Domain = Name >>>> Association (DNA) in this section. This is a simpler case of the = server >>>> to server DNA. However, it is not clear what happens if the = certificate >>>> verification fails. Is the behavior the same as when a self-signed >>>> certificate is presented? Is there a fallback process or does the = session >>>> just terminate? >>>>=20 >>>> In addition, the following nits should be addressed in the = document. >>>>=20 >>>> Checking nits according to http://www.ietf.org/id-info/checklist = : >>>>=20 >>>> = --------------------------------------------------------------------------= -- >>>>=20 >>>> =3D=3D There are 2 instances of lines with non-RFC2606-compliant = FQDNs in >>>> the >>>> document. >>>>=20 >>>>=20 >>>> Checking references for intended status: Proposed Standard >>>>=20 >>>> = --------------------------------------------------------------------------= -- >>>>=20 >>>> (See RFCs 3967 and 4897 for information about using normative >>>> references >>>> to lower-maturity documents in RFCs) >>>>=20 >>>> =3D=3D Outdated reference: A later version (-14) exists of >>>> draft-ietf-dane-srv-12 >>>>=20 >>>> ** Downref: Normative reference to an Informational RFC: RFC 4949 >>>>=20 >>>> -- Possible downref: Non-RFC (?) normative reference: ref. = 'XEP-0220' >>>>=20 >>>> =3D=3D Outdated reference: draft-ietf-uta-xmpp has been published = as RFC >>>> 7590 >>>>=20 >>>> -- Obsolete informational reference (is this intentional?): RFC = 3920 >>>> (Obsoleted by RFC 6120) >>>>=20 >>>>=20 >>>> Summary: 1 error (**), 0 flaws (~~), 3 warnings (=3D=3D), 3 = comments >>>> (=E2=80=94). >>>>=20 >>>>=20 >>>> Thanks. >>>>=20 >>>>=20 Mahesh Jethanandani mjethanandani@gmail.com From nobody Tue Aug 11 11:05:13 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40A41A9155 for ; Tue, 11 Aug 2015 08:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 5x1j9dhtTMvb for ; Tue, 11 Aug 2015 08:56:41 -0700 (PDT) Received: from mail-io0-f172.google.com (mail-io0-f172.google.com [209.85.223.172]) (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 BB27C1A9165 for ; Tue, 11 Aug 2015 08:56:33 -0700 (PDT) Received: by iodt126 with SMTP id t126so15492722iod.2 for ; Tue, 11 Aug 2015 08:56:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=OgekbL6fmx6QASRG+rjDDDk985XX1bI76hLKFY1azUY=; b=kWZNTXvnebu6zk8pzFGqZzA34Fs9Rzd6F28f7aEbA3yBYEXkqXXtK4ysUdE3YcHM3c UYGtR3uOduO4bEpCysHWuy8OhCv9cI/gBmkBDfXKlNyEcT34nCVJ+1uFUgVEt2mBkbA5 EytmTH7Me3vh3BZIqwD7BOF2qp7ruq1oky1QS9n26SYZcvBvHsafjdf7mXoA2kjhv/f2 w6H+JyNiwAA4hN4gp6J67M7lEP/zbHzucnfDCSIRujZwXeFDndeVz9CT223NZgTznd5S 7i0xPvOKTBFj8q5INvU8lDKG3yw4EnbwMfH2BWq9jQK6PMMsyorBaw+hTLfKShxjNQSO NpOQ== X-Gm-Message-State: ALoCoQldo+4Xlap+35Olczj8jKJ7wpckf8qhEoKWzWQbSehKO49jfBk+MRKfHi2PspA5oaKK3Bnk X-Received: by 10.107.165.142 with SMTP id o136mr28071054ioe.120.1439308592723; Tue, 11 Aug 2015 08:56:32 -0700 (PDT) Received: from aither.local ([2601:282:4201:ef5b:9c73:d370:d1e8:173c]) by smtp.googlemail.com with ESMTPSA id o19sm8363343igs.18.2015.08.11.08.56.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Aug 2015 08:56:31 -0700 (PDT) To: Mahesh Jethanandani , Peter Saint-Andre - &yet References: <20150806103342.2703.18148.idtracker@ietfa.amsl.com> <55C9344F.90201@andyet.net> <11AAE863-30CB-4B50-90FE-C83D68E434EA@gmail.com> <55C95B20.3050902@andyet.net> <8208F533-C48C-48DC-8756-7A3F99938F67@gmail.com> From: Peter Saint-Andre - &yet Message-ID: <55CA1B2C.3030406@andyet.net> Date: Tue, 11 Aug 2015 09:56:28 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <8208F533-C48C-48DC-8756-7A3F99938F67@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Tue, 11 Aug 2015 11:05:12 -0700 Cc: draft-ietf-xmpp-dna.ad@ietf.org, draft-ietf-xmpp-dna@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, The IESG , Benoit Claise , draft-ietf-xmpp-dna.shepherd@ietf.org Subject: Re: [xmpp] Benoit Claise's No Objection on draft-ietf-xmpp-dna-10: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 15:56:43 -0000 Great, thanks for checking it. BTW, here is initial proposed text for the section we would reference in draft-ietf-xmpp-posh (I know you weren't tasked with reviewing that spec, so I'm including it here only for completeness): ### 8. Guidance for Server Operators POSH is intended to ease the operational burden of securing application services, especially in multi-tenanted environments. It does so by obviating the need to obtain certificates for hosted domains, so that an operator can obtain a certificate only for its hosting service (naturally, this certificate needs to be valid according to [RFC5280] and contain the proper identifier(s) in accordance with [RFC6125] and the relevant application protocol specification). However, in order to use POSH, an operator does need to coordinate with its customers so that the appropriate POSH files are provided via HTTPS at a well-known URI at each customer's domain (i.e., at the Source Domain), thus ensuring delegation to the operator's hosting service (i.e., the Delegated Domain). Because correct hosting of the POSH file at the Source Domain is essential for successful functioning of the POSH "chain", errors at the Source Domain will result in authentication problems, certificate warnings, and other operational issues. Furthermore, if the POSH file performs reference rather than possession as described in this document, the operational burden is further decreased since the operator does not need to provision its customers with updated POSH files when the certificate for the Delegated Domain expires or is replaced. ### Matt Miller and I will work on that text further this week. Peter On 8/10/15 8:27 PM, Mahesh Jethanandani wrote: > Hi Peter, > > The text looks good to me. > > Thanks. > >> On Aug 10, 2015, at 7:17 PM, Peter Saint-Andre - &yet wrote: >> >> Hi Mahesh, >> >> I suggest that we add a section something like the following to draft-ietf-xmpp-dna and then add a section to draft-ietf-xmpp-posh as well (I haven't written any text for the latter yet, thus the "FIXME" for a section number in what follows). >> >> ### >> >> 8. Guidance for Server Operators >> >> This document introduces the concept of a prooftype in order to >> explain and generalize the approach to establishing a strong >> association between the DNS domain name of an XMPP service and the >> XML stream that a client or peer server initiates with that service. >> >> The operators of XMPP services will not directly deploy DNA >> prooftypes, and the operations and management implications will >> depend on the prooftypes that an operator supports. For example: >> >> o To support the PKIX prooftype [RFC6120], an operator needs to >> interact with a certification authority but does not need to >> deploy DNS security. >> >> o To support the DANE prooftype [I-D.ietf-dane-srv], an operator can >> generate its own certificates or obtain them from a certification >> authority but needs to deploy DNS security. >> >> o To support the POSH prooftype [I-D.ietf-xmpp-posh], an operator >> can generate its own certificates or obtain them from a >> certification authority but does not need to deploy DNS security. >> >> Considerations for use of the foregoing prooftypes are explained in >> the relevant specifications. See in particular Section 13.7 of >> [RFC6120], Section 6 of [I-D.ietf-dane-srv], and Section FIXME of >> [I-D.ietf-xmpp-posh]. >> >> Naturally, these operations and management considerations are >> additive: if an operator wishes to use multiple prooftypes, the >> complexity of deployment increases (e.g., the operator might want to >> obtain a PKIX certificate from a certification authority for use in >> the PKIX prooftype and generate its own certificate for use in the >> DANE prooftype). This is an unavoidable aspect of supporting as many >> prooftypes as needed in order to ensure that domain name associations >> can be established in the largest possible percentage of cases. >> >> ### >> >> What do you think? >> >> (I haven't shared this text yet with my co-authors, since I've been working on it just now.) >> >> Peter >> >> On 8/10/15 8:09 PM, Mahesh Jethanandani wrote: >>> Peter, >>> >>> I agree. As I suggested in the review, a reference to the section you reproduce below from draft-ietf-dane-srv (and a similar reference to a section in draft-ietf-xmpp-posh) is what you need in draft-ietf-xmpp-dna. >>> >>> Cheers. >>> >>>> On Aug 10, 2015, at 4:31 PM, Peter Saint-Andre - &yet wrote: >>>> >>>> Hi Benoit, I posted a reply to the OPS-DIR review here: >>>> >>>> https://mailarchive.ietf.org/arch/msg/xmpp/VymvhuVNfSFaNv8YEjpslzR_tw4 >>>> >>>> My feeling is that it would be best for this document to point to the companion documents (draft-ietf-xmpp-posh and draft-ietf-dane-srv) with regard to operations and management. Note that draft-ietf-dane-srv already includes the following text: >>>> >>>> ### >>>> >>>> 6. Guidance for Server Operators >>>> >>>> To conform to this specification, the published SRV records and >>>> subsequent address (A and AAAA) records MUST be secured with DNSSEC. >>>> There SHOULD also be at least one TLSA record published that >>>> authenticates the server's certificate. >>>> >>>> When using TLSA records with Certificate Usage "DANE-EE", it is not >>>> necessary for the deployed certificate to contain an identifier for >>>> either the source domain or target server host name. However, >>>> operators need to be aware that servers relying solely on validation >>>> using Certificate Usage "DANE-EE" TLSA records might prevent clients >>>> that do not support this specification from successfully connecting >>>> with TLS. >>>> >>>> For TLSA records with Certificate Usage types other than "DANE-EE", >>>> the certificate(s) MUST contain an identifier that matches: >>>> >>>> o the service domain name (the "source domain" in [RFC6125] terms, >>>> which is the SRV query domain); and/or >>>> >>>> o the target server host name (the "derived domain" in [RFC6125] >>>> terms, which is the SRV target host name). >>>> >>>> Servers that support multiple service domains (i.e., so-called >>>> "multi-tenanted environments") can implement the Transport Layer >>>> Security Server Name Indication (TLS SNI) [RFC6066] or its functional >>>> equivalent to determine which certificate to offer. Clients that do >>>> not support this specification will indicate a preference for the >>>> service domain name, while clients that support this specification >>>> will indicate the target server host name. However, the server >>>> determines what certificate to present in the TLS handshake; e.g., >>>> the presented certificate might only authenticate the target server >>>> host name. >>>> >>>> ### >>>> >>>> Is that text helpful and complete? (Note that draft-ietf-dane-srv has already been approved for publication, but if we need to make some slight adjustments during AUTH48 we could do so.) >>>> >>>> Also, do you think it would be preferable for draft-ietf-xmpp-posh to include a similar section providing guidance for server operators in draft-ietf-xmpp-posh? If so, Matt and I can work to formulate some text. >>>> >>>> Thanks! >>>> >>>> Peter >>>> >>>> On 8/6/15 4:33 AM, Benoit Claise wrote: >>>>> Benoit Claise has entered the following ballot position for >>>>> draft-ietf-xmpp-dna-10: 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 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-xmpp-dna/ >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> The conversation started between Mahesh (OPS-DIR reviewer) and the >>>>> authors on the following points: >>>>> >>>>> Summary: >>>>> >>>>> This document defines new “prooftype” used to establish a strong >>>>> association between a domain name and an XML stream. There are two >>>>> companion documents draft-ietf-xmpp-posh-04 and draft-ietf-dane-srv-12 >>>>> that should be viewed as part of reviewing this document. >>>>> >>>>> If there are any management requirements to configure the new >>>>> “prooftype”, they have not been discussed as part of this document. I did >>>>> not review the companion documents to see if management of the feature >>>>> has been addressed in them. This document should talk about how the >>>>> feature will be managed, even if it means referring to relevant sections >>>>> of the other documents. If there is a need to define a YANG model to >>>>> configure the feature, it should be identified, even if it is not defined >>>>> in this document. >>>>> >>>>>> From an operational perspective, it would be helpful to know how this >>>>> would be deployed in the field. Are there any issues beyond certificate >>>>> configuration that operators should be aware of? Some of the services are >>>>> replacements for existing services, e.g. DNS with secure DNS. How would >>>>> the operators role out the service in the field with existing >>>>> service(s)? >>>>> >>>>> Section 3: >>>>> >>>>> The document talks about establishing a client to server Domain Name >>>>> Association (DNA) in this section. This is a simpler case of the server >>>>> to server DNA. However, it is not clear what happens if the certificate >>>>> verification fails. Is the behavior the same as when a self-signed >>>>> certificate is presented? Is there a fallback process or does the session >>>>> just terminate? >>>>> >>>>> In addition, the following nits should be addressed in the document. >>>>> >>>>> Checking nits according to http://www.ietf.org/id-info/checklist : >>>>> >>>>> ---------------------------------------------------------------------------- >>>>> >>>>> == There are 2 instances of lines with non-RFC2606-compliant FQDNs in >>>>> the >>>>> document. >>>>> >>>>> >>>>> Checking references for intended status: Proposed Standard >>>>> >>>>> ---------------------------------------------------------------------------- >>>>> >>>>> (See RFCs 3967 and 4897 for information about using normative >>>>> references >>>>> to lower-maturity documents in RFCs) >>>>> >>>>> == Outdated reference: A later version (-14) exists of >>>>> draft-ietf-dane-srv-12 >>>>> >>>>> ** Downref: Normative reference to an Informational RFC: RFC 4949 >>>>> >>>>> -- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0220' >>>>> >>>>> == Outdated reference: draft-ietf-uta-xmpp has been published as RFC >>>>> 7590 >>>>> >>>>> -- Obsolete informational reference (is this intentional?): RFC 3920 >>>>> (Obsoleted by RFC 6120) >>>>> >>>>> >>>>> Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments >>>>> (—). >>>>> >>>>> >>>>> Thanks. >>>>> >>>>> -- Peter Saint-Andre https://andyet.com/ From nobody Tue Aug 11 17:58:04 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385491A8A89 for ; Tue, 11 Aug 2015 17:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 YQ5fL1PIxK2B for ; Tue, 11 Aug 2015 17:58:01 -0700 (PDT) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (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 9325A1ACD4F for ; Tue, 11 Aug 2015 17:57:57 -0700 (PDT) Received: by igui7 with SMTP id i7so52122674igu.1 for ; Tue, 11 Aug 2015 17:57:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Lq9JTLxh+FkLZZHoLKRwGCWyGckY34RQyhxMz1rC6k8=; b=E7v6PbA8gLIGp1+hLqPrkO9Hineo3ct6jso3c77Gmyxiz8nLnKpw8zsr1AJ2683skn cxrmD10KMyDTAgOGlVm7iNVcedRWhwtKV9vPGSd59L+m2wLq4EscaTUU0oVtY7Nehs76 ukDkjGT+Ix/Fz0xBdUCDGt74Y5LRlOzayjcc6LeQko0Z6ccpjgFh1U4AnTlSnPBbaX+K wFVdV3xMBJTj4tcyc6gsfZmUAVtaAsJGEAt/MofKArvCma8mLgmzDgauen/9TO41MWBX 0cmDZUNH8t2nkMflISsic9Td9wp5HSNK27DzNKKHwbDfE5/3ROlhg3QwCfXeJzwApCXS k4gg== X-Gm-Message-State: ALoCoQlALkfAUzcYAuXnaThyGdu4WFc150fgbgm1gli0juyBwUJPyi7TrvOrMQFzsTNS5xmwB0qf X-Received: by 10.50.102.98 with SMTP id fn2mr22044582igb.55.1439341076760; Tue, 11 Aug 2015 17:57:56 -0700 (PDT) Received: from aither.local ([2601:282:4201:ef5b:b4bc:6cdf:f03:aabe]) by smtp.googlemail.com with ESMTPSA id z6sm9365238ign.12.2015.08.11.17.57.54 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Aug 2015 17:57:55 -0700 (PDT) To: Barry Leiba References: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> <55BACBBF.3060301@andyet.net> <55BBA4C1.6040404@andyet.net> From: Peter Saint-Andre - &yet Message-ID: <55CA9A10.2080603@andyet.net> Date: Tue, 11 Aug 2015 18:57:52 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, The IESG , draft-ietf-xmpp-posh@ietf.org Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 00:58:02 -0000 On 7/31/15 7:50 PM, Barry Leiba wrote: >>> If you like, it could even do POSH service names and POSH format >>> names, and specify ".well-known/posh//", >> >> Currently it's the field that we're most interested in. > > Right... and that's what I'm suggesting an FCFS registry for. You > register "posh" in .well-known, and you create your own FCFS registry > for service names, and if you don't care about the format as a > separate thing, you just register "spice.json" (and so on) in your > FCFS registry. That way, Mark doesn't get involved in approving > "posh.x" and "posh.y" and "posh.z", when Mark has no idea of what to > say about posh service names (or seedy ones, for that matter). I'm warming to this suggestion. Part of my hesitation was caused by the fact that I had misunderstood RFC 5785. I somehow had the impression that it discouraged path components beyond the registered name, but that impression was false: Typically, a registration will reference a specification that defines the format and associated media type to be obtained by dereferencing the well-known URI. It MAY also contain additional information, such as the syntax of additional path components, query strings and/or fragment identifiers to be appended to the well-known URI, or protocol-specific details (e.g., HTTP [RFC2616] method handling). However, I haven't yet had an opportunity to discuss this in depth with my co-author. We'll be back in touch once we've talked about it and perhaps discussed it with implementers. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue Aug 11 18:28:46 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8F71A1B3F; Tue, 11 Aug 2015 18:28:42 -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 crH2L1Os3JwO; Tue, 11 Aug 2015 18:28:41 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (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 776E31A1B34; Tue, 11 Aug 2015 18:28:41 -0700 (PDT) Received: by vkbc123 with SMTP id c123so1015986vkb.0; Tue, 11 Aug 2015 18:28:40 -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=iq49GqFgVh6+3Xo775vBrW0k+JaL/r5XYfH8L3qg7DE=; b=yQulVbNbc8b5zNMSiK3kO8UPF4DIHiLnzKdsYlCjzy7yEKEreGqW0TgX7cQGlAVYN/ erIi5Yen9jfYZFOkb+BF4aGvi1G9ykJuC4r4M3djfISzERewgyypSX7LeHCjUZozz7Ex DHVQAuYRduGQ5QqV0t+VL3tuUujAEAmSvxquzjRTvMXQFqGQ6tAS8zDdD+F8xw6DdCQm rprgfjrCTxzWsoThAQgHXQsfceGUUnFAX0DJcoX0IUUQncWiekHmkuTR8DWRvJ3I77sG 1ThUtpmESltJ0SNfzWcHwlTJ5TAIXhhqD2Sn1xDNzIhSCso2bPhgy4+jU9nluYbg6F2D uH+Q== MIME-Version: 1.0 X-Received: by 10.52.137.236 with SMTP id ql12mr36502617vdb.48.1439342920656; Tue, 11 Aug 2015 18:28:40 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Tue, 11 Aug 2015 18:28:40 -0700 (PDT) In-Reply-To: <55CA9A10.2080603@andyet.net> References: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> <55BACBBF.3060301@andyet.net> <55BBA4C1.6040404@andyet.net> <55CA9A10.2080603@andyet.net> Date: Tue, 11 Aug 2015 18:28:40 -0700 X-Google-Sender-Auth: lEaajZ0bULThyo1er2UwUXdzHw8 Message-ID: From: Barry Leiba To: "Peter Saint-Andre - &yet" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, The IESG , draft-ietf-xmpp-posh@ietf.org Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 01:28:42 -0000 > I'm warming to this suggestion. :-) Nice. > However, I haven't yet had an opportunity to discuss this in depth with my > co-author. We'll be back in touch once we've talked about it and perhaps > discussed it with implementers. Fair 'nough; thanks. Barry From nobody Tue Aug 11 18:48:49 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CFD1A1BB0; Tue, 11 Aug 2015 18:48:44 -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=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 Dmmh810NGRXD; Tue, 11 Aug 2015 18:48:43 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 CC3B41A1A29; Tue, 11 Aug 2015 18:48:43 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t7C1mOKD035677 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 11 Aug 2015 20:48:35 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Peter Saint-Andre - &yet" Date: Tue, 11 Aug 2015 20:48:24 -0500 Message-ID: In-Reply-To: <55CA9A10.2080603@andyet.net> References: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> <55BACBBF.3060301@andyet.net> <55BBA4C1.6040404@andyet.net> <55CA9A10.2080603@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, Barry Leiba , draft-ietf-xmpp-posh@ietf.org, The IESG Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 01:48:44 -0000 On 11 Aug 2015, at 19:57, Peter Saint-Andre - &yet wrote: > On 7/31/15 7:50 PM, Barry Leiba wrote: >>>> If you like, it could even do POSH service names and POSH format >>>> names, and specify ".well-known/posh//", >>> >>> Currently it's the field that we're most interested >>> in. >> >> Right... and that's what I'm suggesting an FCFS registry for. You >> register "posh" in .well-known, and you create your own FCFS registry >> for service names, and if you don't care about the format as a >> separate thing, you just register "spice.json" (and so on) in your >> FCFS registry. That way, Mark doesn't get involved in approving >> "posh.x" and "posh.y" and "posh.z", when Mark has no idea of what to >> say about posh service names (or seedy ones, for that matter). > > I'm warming to this suggestion. Part of my hesitation was caused by > the fact that I had misunderstood RFC 5785. I somehow had the > impression that it discouraged path components beyond the registered > name, but that impression was false: > > Typically, a registration will reference a specification that defines > the format and associated media type to be obtained by dereferencing > the well-known URI. > > It MAY also contain additional information, such as the syntax of > additional path components, query strings and/or fragment identifiers > to be appended to the well-known URI, or protocol-specific details > (e.g., HTTP [RFC2616] method handling). > > However, I haven't yet had an opportunity to discuss this in depth > with my co-author. We'll be back in touch once we've talked about it > and perhaps discussed it with implementers. For the record, I do not object to this change. I can even see the advantage. But let's keep in mind that there was working group consensus (such as it was) to do things as currently written. We can change that if there is good reason--but I want to make sure people think the reason is really good enough (with all due respect to Barry and Stephen). If we do change it, we should probably consider an abbreviated WGLC on just this point. (Or perhaps the discussion with implementors would serve the same purpose.) Thanks! Ben. From nobody Tue Aug 18 15:25:37 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781FA1A8767 for ; Tue, 18 Aug 2015 15:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 mCaHkOcO3fa9 for ; Tue, 18 Aug 2015 15:25:33 -0700 (PDT) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.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 AE0301A8759 for ; Tue, 18 Aug 2015 15:25:31 -0700 (PDT) Received: by igxp17 with SMTP id p17so92339185igx.1 for ; Tue, 18 Aug 2015 15:25:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=flyTeDLcrrnh11FIqMEXLOz1ze7CO38yCAa9Cxs5W94=; b=CDLBblQ2u7SXXVKDULPvwAOfREknhcJMo7ll2DZrCQGuhIWFsWSX9aTnr+xlv96Fc3 LvN5mNp35TwPDzvqO7sCvhzxXUsCpR5fde114Q5ELu4RUscvtfL//cOCDc6EBjtxOBav ld8i7OZ2l2grmCX5d77JbYUTivvwfHhUgT7ENDCc60GSYHMlwCFhpNa4b6ShGtfJZPYE c8tb5+WAkCiP9ZRFtHeXj8K5lL6NVRp32nwCgF1S6VHfr3gcFo48NP4t/24qh2UmoE9F UmwxqoYQHjOC6O9cMU45ojSUcePvEtz10zEeNyIYmp4hgJYOVxiFh8o5Of0WVjQyKO4H 1osg== X-Gm-Message-State: ALoCoQlQuhFm71xSWPvkfE7qltyGVVpC0JXfjxEg44WmCo58Hik5d+paCGsRi+iRR3K5MURUcopc X-Received: by 10.50.66.197 with SMTP id h5mr23318285igt.82.1439936730965; Tue, 18 Aug 2015 15:25:30 -0700 (PDT) Received: from aither.local ([2601:282:4201:ef5b:f46e:ce6a:4c42:3b3e]) by smtp.googlemail.com with ESMTPSA id n6sm654178igv.17.2015.08.18.15.25.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Aug 2015 15:25:30 -0700 (PDT) To: Ben Campbell References: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> <55BACBBF.3060301@andyet.net> <55BBA4C1.6040404@andyet.net> <55CA9A10.2080603@andyet.net> From: Peter Saint-Andre - &yet Message-ID: <55D3B0D8.2010202@andyet.net> Date: Tue, 18 Aug 2015 16:25:28 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, Barry Leiba , draft-ietf-xmpp-posh@ietf.org, The IESG Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 22:25:34 -0000 On 8/11/15 7:48 PM, Ben Campbell wrote: > On 11 Aug 2015, at 19:57, Peter Saint-Andre - &yet wrote: > >> On 7/31/15 7:50 PM, Barry Leiba wrote: >>>>> If you like, it could even do POSH service names and POSH format >>>>> names, and specify ".well-known/posh//", >>>> >>>> Currently it's the field that we're most interested in. >>> >>> Right... and that's what I'm suggesting an FCFS registry for. You >>> register "posh" in .well-known, and you create your own FCFS registry >>> for service names, and if you don't care about the format as a >>> separate thing, you just register "spice.json" (and so on) in your >>> FCFS registry. That way, Mark doesn't get involved in approving >>> "posh.x" and "posh.y" and "posh.z", when Mark has no idea of what to >>> say about posh service names (or seedy ones, for that matter). >> >> I'm warming to this suggestion. Part of my hesitation was caused by >> the fact that I had misunderstood RFC 5785. I somehow had the >> impression that it discouraged path components beyond the registered >> name, but that impression was false: >> >> Typically, a registration will reference a specification that defines >> the format and associated media type to be obtained by dereferencing >> the well-known URI. >> >> It MAY also contain additional information, such as the syntax of >> additional path components, query strings and/or fragment identifiers >> to be appended to the well-known URI, or protocol-specific details >> (e.g., HTTP [RFC2616] method handling). >> >> However, I haven't yet had an opportunity to discuss this in depth >> with my co-author. We'll be back in touch once we've talked about it >> and perhaps discussed it with implementers. > > For the record, I do not object to this change. I can even see the > advantage. But let's keep in mind that there was working group consensus > (such as it was) to do things as currently written. We can change that > if there is good reason--but I want to make sure people think the reason > is really good enough (with all due respect to Barry and Stephen). > > If we do change it, we should probably consider an abbreviated WGLC on > just this point. (Or perhaps the discussion with implementors would > serve the same purpose.) Hi all, A quick status update... The authors have provisionally addressed all of the other issues from IESG review of draft-ietf-xmpp-posh and draft-ietf-xmpp-dna in our working copies. Matt and I are currently pinging implementers and we aim to finish gathering feedback from them by the end of this week. We'll report further once that is done. Peter From nobody Mon Aug 24 15:52:36 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188E81ACDF4; Mon, 24 Aug 2015 15:52:31 -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=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 Kb5MclBQ88to; Mon, 24 Aug 2015 15:52:28 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 0F9D11B2BC4; Mon, 24 Aug 2015 15:52:28 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t7OMqFmw090888 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 24 Aug 2015 17:52:25 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Peter Saint-Andre - &yet" Date: Mon, 24 Aug 2015 17:52:15 -0500 Message-ID: <37FFCBB4-6921-4A6C-91A4-D1569CD96381@nostrum.com> In-Reply-To: <55D3B0D8.2010202@andyet.net> References: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> <55BACBBF.3060301@andyet.net> <55BBA4C1.6040404@andyet.net> <55CA9A10.2080603@andyet.net> <55D3B0D8.2010202@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, xmpp@ietf.org, Barry Leiba , draft-ietf-xmpp-posh@ietf.org, The IESG Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 22:52:31 -0000 On 18 Aug 2015, at 17:25, Peter Saint-Andre - &yet wrote: > Hi all, > > A quick status update... > > The authors have provisionally addressed all of the other issues from > IESG review of draft-ietf-xmpp-posh and draft-ietf-xmpp-dna in our > working copies. Matt and I are currently pinging implementers and we > aim to finish gathering feedback from them by the end of this week. > We'll report further once that is done. Hi, Any updates? Thanks! Ben. From nobody Mon Aug 24 16:52:09 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339591A1A40; Mon, 24 Aug 2015 16:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 r8fYMapW6Zs5; Mon, 24 Aug 2015 16:52:03 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30D751A1BB5; Mon, 24 Aug 2015 16:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1426; q=dns/txt; s=iport; t=1440460323; x=1441669923; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=subRV2SQtXshz/XMLSTtnH36alVN6ni0lEGWhJFsCe8=; b=hs4gqyVjk5NGO/eKz9w24QRT5xtwHz2yzyuSSLIE9vrZiwMYBQ+UdQ4M LypROkCf38aKX9VNkT0FZJWbYEw+VYnGhJ/CmgTS1o7LONrbl2iW3r8ms MDDfylSzcz8xGAavj2sKlV99FulhwKhzhivsKJ8Z/37Dw9hU6nrLal/xw U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CXBQA5rdtV/5NdJa1dgxtUaYMlvEeGAwKBLjsRAQEBAQEBAYEKhCQBAQQjDwFFARALGAICBRYLAgIJAwIBAgFFBgEMAQUCAQGIKrITlRUBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEiijWEVzMHgmmBQwEEjV6HVoUGh2yBSocpiSmIMyaCDR0WgV1SgkwBAQE X-IronPort-AV: E=Sophos;i="5.15,742,1432598400"; d="scan'208";a="181639782" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP; 24 Aug 2015 23:52:02 +0000 Received: from [64.101.72.31] ([64.101.72.31]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t7ONq2Gs009680; Mon, 24 Aug 2015 23:52:02 GMT Message-ID: <55DBAE21.3020408@cisco.com> Date: Mon, 24 Aug 2015 17:52:01 -0600 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ben Campbell , Peter Saint-Andre - &yet References: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> <55BACBBF.3060301@andyet.net> <55BBA4C1.6040404@andyet.net> <55CA9A10.2080603@andyet.net> <55D3B0D8.2010202@andyet.net> <37FFCBB4-6921-4A6C-91A4-D1569CD96381@nostrum.com> In-Reply-To: <37FFCBB4-6921-4A6C-91A4-D1569CD96381@nostrum.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, xmpp@ietf.org, Barry Leiba , draft-ietf-xmpp-posh@ietf.org, The IESG Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 23:52:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 8/24/15 4:52 PM, Ben Campbell wrote: > On 18 Aug 2015, at 17:25, Peter Saint-Andre - &yet wrote: > >> Hi all, >> >> A quick status update... >> >> The authors have provisionally addressed all of the other issues >> from IESG review of draft-ietf-xmpp-posh and draft-ietf-xmpp-dna >> in our working copies. Matt and I are currently pinging >> implementers and we aim to finish gathering feedback from them by >> the end of this week. We'll report further once that is done. > > Hi, > > Any updates? > > Thanks! > > Ben. Peter and I have reached out to a number of implementers. No one we've talked to objects to changing the URI. We still need to make the appropriate changes to POSH and DNA; we are meeting later this week to work out those details. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJV264hAAoJEDWi+S0W7cO1/ckH/Rzr9icA0sy7hhisb1Mgn/DN R1Jy3jkpt+NXeNNm9InsYMsAvxLPaZY7tVQyYxl8wEdTpTWOF/WARW57AYXFXLzm NUllGNu1c3D8Mt7YnK8nXmypqk0W3xvzJGm9YWjPdrpfD5rtcbsO5DI8unVSiN6s IMKBcgCZv2xDFGwWkAQhDl9ooRyMEDeWhNh2/dIWDvevSqbLmorTsHgGVcPVLA/9 5ibL6mH9idDA1Il/GUql5ZTIKDgdwvp0gXpVhoMNXur3KK+XDPaYbODBo8/TPGUR zaTFT+Bj42YHUzeq5kme473E/wglMNlN0xz53wSE/lRK1IvhkUlaSf5g53g9Eik= =GAbe -----END PGP SIGNATURE----- From nobody Mon Aug 24 18:08:15 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B961E1A6EED; Mon, 24 Aug 2015 18:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] 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 gjDLCTQCfirm; Mon, 24 Aug 2015 18:08:07 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 310DD1A1BD1; Mon, 24 Aug 2015 18:08:07 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t7P17pEB003396 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 24 Aug 2015 20:08:01 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "=?utf-8?q?=E2=8C=98?= Matt Miller" Date: Mon, 24 Aug 2015 20:07:51 -0500 Message-ID: <8C4C868A-B232-4F2B-A6D3-980785C95DB8@nostrum.com> In-Reply-To: <55DBAE21.3020408@cisco.com> References: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> <55BACBBF.3060301@andyet.net> <55BBA4C1.6040404@andyet.net> <55CA9A10.2080603@andyet.net> <55D3B0D8.2010202@andyet.net> <37FFCBB4-6921-4A6C-91A4-D1569CD96381@nostrum.com> <55DBAE21.3020408@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, Barry Leiba , draft-ietf-xmpp-posh@ietf.org, The IESG Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 01:08:07 -0000 On 24 Aug 2015, at 18:52, ⌘ Matt Miller wrote: >> Hi, >> >> Any updates? >> >> Thanks! >> >> Ben. > > > Peter and I have reached out to a number of implementers. No one > we've talked to objects to changing the URI. We still need to make > the appropriate changes to POSH and DNA; we are meeting later this > week to work out those details. Thanks! Ben. From nobody Tue Aug 25 19:29:55 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6453D1A88BA for ; Tue, 25 Aug 2015 19:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 DXovBbW2qvOo for ; Tue, 25 Aug 2015 19:29:53 -0700 (PDT) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) (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 9C9931A88F7 for ; Tue, 25 Aug 2015 19:29:49 -0700 (PDT) Received: by igfj19 with SMTP id j19so1960899igf.1 for ; Tue, 25 Aug 2015 19:29:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=tMGz8NuZ/SeOepHO7UzA7vk/xGzQw1m1dbeNrQBVoSQ=; b=ThWlSXQ25bH4atJenG1qh/75+P4xrQkOe5TVQjBZNOrjb/N1r2lSJH1ETkbiGpc56Q vZyK7dPS26div7c1Rod0VFf+ixGQgST+fC1yG3Dwd7PAYCu8eZcRkrqVB5+W5mwidayQ dROkDb4C3GGXnxX02LiycqraO3d3JdLAIvWwWlJhrh8UWzJkx0t8o+CCB4BLyo3G5ReU HTWwajQN63enrJCVOV+7b6YPEVofRxLub+ub6gU7TX8ldt8KR4lnHb9UyIN4qXNLcZC4 O0Q7PUSQ0l8aT++NmYSoCMT6HCZ0BX3DTtQIXcXE+fEp/u/ZVnvBJ4z1tJQJT0iqjTwd 8CqQ== X-Gm-Message-State: ALoCoQkxNBYkubmPShK4265secRVBaSzfjv6vc3VWOHDy+16cLckZZJnXHDS4VKTbtuRYW2vQIBv X-Received: by 10.50.119.33 with SMTP id kr1mr6942392igb.75.1440556188940; Tue, 25 Aug 2015 19:29:48 -0700 (PDT) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id b5sm17004467iob.39.2015.08.25.19.29.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Aug 2015 19:29:47 -0700 (PDT) To: Ben Campbell , =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= References: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> <55BACBBF.3060301@andyet.net> <55BBA4C1.6040404@andyet.net> <55CA9A10.2080603@andyet.net> <55D3B0D8.2010202@andyet.net> <37FFCBB4-6921-4A6C-91A4-D1569CD96381@nostrum.com> <55DBAE21.3020408@cisco.com> <8C4C868A-B232-4F2B-A6D3-980785C95DB8@nostrum.com> From: Peter Saint-Andre - &yet Message-ID: <55DD249A.4080109@andyet.net> Date: Tue, 25 Aug 2015 20:29:46 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <8C4C868A-B232-4F2B-A6D3-980785C95DB8@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, xmpp@ietf.org, Barry Leiba , draft-ietf-xmpp-posh@ietf.org, The IESG Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 02:29:54 -0000 On 8/24/15 7:07 PM, Ben Campbell wrote: > On 24 Aug 2015, at 18:52, ⌘ Matt Miller wrote: > >>> Hi, >>> >>> Any updates? >>> >>> Thanks! >>> >>> Ben. >> >> >> Peter and I have reached out to a number of implementers. No one >> we've talked to objects to changing the URI. We still need to make >> the appropriate changes to POSH and DNA; we are meeting later this >> week to work out those details. > > Thanks! Right, I think we need to do the following: 1. Recommend URIs like https://example.com/.well-known/posh/spice.json 2. In draft-ietf-xmpp-posh, register "posh" in the well-known URIs registry 3. In draft-ietf-xmpp-posh, set up a registry for POSH protocols 4. In draft-ietf-xmpp-dna, register "xmpp-client" and "xmpp-server" in the POSH registry I offered to Matt that I can propose text for the IANA considerations sections since I've written such text before. I'll endeavor to draft something in the next few days. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu Aug 27 21:51:23 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2711B3D5D for ; Thu, 27 Aug 2015 21:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 0VjECEjzLE4q for ; Thu, 27 Aug 2015 21:51:20 -0700 (PDT) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.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 A3C4B1B3D5C for ; Thu, 27 Aug 2015 21:51:19 -0700 (PDT) Received: by pacdd16 with SMTP id dd16so49276202pac.2 for ; Thu, 27 Aug 2015 21:51: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:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Wg6NQY62YabX2wGun2MjF4kkuRTW1eL7e3piXJ66dQI=; b=E8Grvp/ilYWmu5rGvu0cfc2+76Rz0H5E+5OzDWqwbhCszUw3o3PkIPTQVLm4ok7hMb A1nIKvcvf1fgfiRVaNXxQaawIDs9ay7qbZYHJ0R/G6zELZjup0ea7S/hyZp920qD/SCi N1ExPywhzKCPWu0KQi53AoJlwd9Tu+c9CLin4uvv8/TqnNSf9etTXfOVuLDlwHY8OLTx fb0aoKuKxBrcA99Q2sWJTgk+nlHsuR3IhNkPj/WMIS6DuZ3brTh1RwmJYSGiEA37+U+2 4uMKPHt1DmqwH3Zg5PWSt5fk6AqeuZdSKPYoXgRrMEJKdXt+uok86qv3P6P93RbEoJGl Xq6Q== X-Gm-Message-State: ALoCoQnxIcCuDOqYmZDO+9PE+C4NSulz7AOYEK5DfvuzVwW2brShdZNRtpL9WRM+NPUaNvreuHxv X-Received: by 10.66.62.229 with SMTP id b5mr11768452pas.81.1440737479054; Thu, 27 Aug 2015 21:51:19 -0700 (PDT) Received: from aither.local (71-94-217-18.static.knwc.wa.charter.com. [71.94.217.18]) by smtp.googlemail.com with ESMTPSA id oq3sm4153297pdb.75.2015.08.27.21.51.17 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Aug 2015 21:51:18 -0700 (PDT) To: Ben Campbell , =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= References: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> <55BACBBF.3060301@andyet.net> <55BBA4C1.6040404@andyet.net> <55CA9A10.2080603@andyet.net> <55D3B0D8.2010202@andyet.net> <37FFCBB4-6921-4A6C-91A4-D1569CD96381@nostrum.com> <55DBAE21.3020408@cisco.com> <8C4C868A-B232-4F2B-A6D3-980785C95DB8@nostrum.com> <55DD249A.4080109@andyet.net> From: Peter Saint-Andre - &yet Message-ID: <55DFE8C4.7090707@andyet.net> Date: Thu, 27 Aug 2015 21:51:16 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55DD249A.4080109@andyet.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, xmpp@ietf.org, Barry Leiba , draft-ietf-xmpp-posh@ietf.org, The IESG Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 04:51:22 -0000 On 8/25/15 7:29 PM, Peter Saint-Andre - &yet wrote: > On 8/24/15 7:07 PM, Ben Campbell wrote: >> On 24 Aug 2015, at 18:52, ⌘ Matt Miller wrote: >> >>>> Hi, >>>> >>>> Any updates? >>>> >>>> Thanks! >>>> >>>> Ben. >>> >>> >>> Peter and I have reached out to a number of implementers. No one >>> we've talked to objects to changing the URI. We still need to make >>> the appropriate changes to POSH and DNA; we are meeting later this >>> week to work out those details. >> >> Thanks! > > Right, I think we need to do the following: > > 1. Recommend URIs like https://example.com/.well-known/posh/spice.json > > 2. In draft-ietf-xmpp-posh, register "posh" in the well-known URIs registry > > 3. In draft-ietf-xmpp-posh, set up a registry for POSH protocols > > 4. In draft-ietf-xmpp-dna, register "xmpp-client" and "xmpp-server" in > the POSH registry > > I offered to Matt that I can propose text for the IANA considerations > sections since I've written such text before. I'll endeavor to draft > something in the next few days. Here is proposed text for draft-ietf-xmpp-posh... ### 9. IANA Considerations 9.1. Well-Known URI This specification registers "posh" in the Well-Known URI Registry as defined by [RFC5785]. The completed template follows. URI suffix: posh Change controller: IETF Specification: [[ this document ]] Related information: The suffix "posh" is expected to be followed by an additional path component consisting of a service name (say, "spice") and a file extension of ".json", resulting in a full path of, for instance, "/.well-known/posh/spice.json". Registration of service names shall be requested by developers of the relevant application protocols. 9.2. POSH Service Names This document establishes a registry for POSH service names. POSH service names are registered on the advice of one or more Designated Experts (appointed by the IESG or their delegate). An IANA registration policy [RFC5226] of Expert Review was chosen instead of the more liberal First Come First Served to help ensure that POSH is used in appropriate ways within applications. Registration requests are to be sent to the posh@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request for POSH service name: example"). Before a period of 14 days has passed, the Designated Expert(s) will either approve or deny the registration request, communicating this decision both to the review list and to IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@iesg.org mailing list) for resolution. 9.2.1. Registration Template Service name: The name requested, relative to "/.well-known/posh/"; e.g., a service name of "example" would result in a well-known URI such as "https://example.com/.well-known/posh/example.json". Change controller: For Standards-Track RFCs, state "IETF". In all other cases, give the name of the responsible party. Other details (e.g., postal address, e-mail address, home page URI) may also be included. Definition and usage: A brief description that defines the service name and mentions where and how it is used (e.g., in the context of a particular application protocol). Specification: Optionally, reference to a document that specifies the service or application protocol that uses the service name, preferably including a URI that can be used to retrieve a copy of the document. An indication of the relevant sections may also be included, but is not required. ### And we would need to make associated changes in draft-ietf-xmpp-dna, such as... ### 9. IANA Considerations The POSH specification [I-D.ietf-xmpp-posh] establishes a registry for POSH service names to be used in well-known URIs [RFC5785]. This specification registers two such URIs for use in XMPP: "xmpp-client" and "xmpp-server". The completed registration templates follow. 9.1. POSH Service Name for xmpp-client Service POSH service name: xmpp-client Change controller: IETF Definition and usage: Specifies the location of a POSH file containing verification material or a reference thereto that enables a client to verify the identity of a server for a client-to-server stream in XMPP Specification: [[ this document ]] 9.2. POSH Service Name for xmpp-server Service POSH service name: xmpp-server Change controller: IETF Definition and usage: Specifies the location of a POSH file containing verification material or a reference thereto that enables a server to verify the identity of a peer server for a server-to- server stream in XMPP Specification: [[ this document ]] ### Matt and I have checked this approach with a few implementers and potential implementers; no one has objected yet, but if folks on the xmpp@ietf.org list or elsewhere have significant concerns it would be great to hear from you. :-) Thanks! Peter -- Peter Saint-Andre https://andyet.com/ From nobody Fri Aug 28 06:05:17 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0DC1ACF59; Fri, 28 Aug 2015 06:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.268 X-Spam-Level: X-Spam-Status: No, score=-1.268 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, T_FILL_THIS_FORM_SHORT=0.01] 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 F5sxB1kkSqiz; Fri, 28 Aug 2015 06:05:10 -0700 (PDT) Received: from mail-vk0-x241.google.com (mail-vk0-x241.google.com [IPv6:2607:f8b0:400c:c05::241]) (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 387601AD248; Fri, 28 Aug 2015 06:05:10 -0700 (PDT) Received: by vkbc123 with SMTP id c123so853540vkb.3; Fri, 28 Aug 2015 06:05:09 -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=Xwmm78PRWEiwnUVPecSAnyfXyF0UjnUGBhRQz18lz/w=; b=XsfzZCiy7Gw533tRZwywGORob8lgfmndHsP9OeQrs6kOXopMJm1VSqk4WnaiZDM6O+ 5au31u238k4P5mGeiKrqb1sfu1ZNmEwRYLgTPDR94JGrfoMG7TD3wCY8I8n7HoL56+Aq OgrXwfaBAF1TpRW3I7V5p4ev0qUfBPOx/QUvxpb1TLIV9R0TxQkykVUJuikoM2A2Pgmd Q6bifUZBol+ZsU/JiCF3/WKQqCt/zAGGpqNiOosvjPwTEcHlq8t7ruoeQspnqPeRVPQS USPxO3dB+dcd63b/aNY7jDyHF799nJUyuYIMg6x0QVL2e+M4krYbsiwrUHyDCswAmXO9 Gtrw== MIME-Version: 1.0 X-Received: by 10.52.156.106 with SMTP id wd10mr8566615vdb.64.1440767109396; Fri, 28 Aug 2015 06:05:09 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Fri, 28 Aug 2015 06:05:09 -0700 (PDT) In-Reply-To: <55DFE8C4.7090707@andyet.net> References: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> <55BACBBF.3060301@andyet.net> <55BBA4C1.6040404@andyet.net> <55CA9A10.2080603@andyet.net> <55D3B0D8.2010202@andyet.net> <37FFCBB4-6921-4A6C-91A4-D1569CD96381@nostrum.com> <55DBAE21.3020408@cisco.com> <8C4C868A-B232-4F2B-A6D3-980785C95DB8@nostrum.com> <55DD249A.4080109@andyet.net> <55DFE8C4.7090707@andyet.net> Date: Fri, 28 Aug 2015 09:05:09 -0400 X-Google-Sender-Auth: A36cNyZi_6ff5mVvPCqQF7G5Rmw Message-ID: From: Barry Leiba To: "Peter Saint-Andre - &yet" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Ben Campbell , draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, draft-ietf-xmpp-posh@ietf.org, The IESG Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 13:05:12 -0000 >> 1. Recommend URIs like https://example.com/.well-known/posh/spice.json >> >> 2. In draft-ietf-xmpp-posh, register "posh" in the well-known URIs >> registry >> >> 3. In draft-ietf-xmpp-posh, set up a registry for POSH protocols >> >> 4. In draft-ietf-xmpp-dna, register "xmpp-client" and "xmpp-server" in >> the POSH registry >> >> I offered to Matt that I can propose text for the IANA considerations >> sections since I've written such text before. I'll endeavor to draft >> something in the next few days. > > Here is proposed text for draft-ietf-xmpp-posh... Thanks, Peter; this looks good. Two questions, inline. > 9. IANA Considerations > > 9.1. Well-Known URI > > This specification registers "posh" in the Well-Known URI Registry as > defined by [RFC5785]. The completed template follows. > > URI suffix: posh > > Change controller: IETF > > Specification: [[ this document ]] > > Related information: The suffix "posh" is expected to be followed by > an additional path component consisting of a service name (say, > "spice") and a file extension of ".json", resulting in a full path > of, for instance, "/.well-known/posh/spice.json". Registration of > service names shall be requested by developers of the relevant > application protocols. > > 9.2. POSH Service Names > > This document establishes a registry for POSH service names. It would help IANA if you suggested where to put the registry (in an existing group of registries, or in its own, new top-level group). > POSH service names are registered on the advice of one or more > Designated Experts (appointed by the IESG or their delegate). An > IANA registration policy [RFC5226] of Expert Review was chosen > instead of the more liberal First Come First Served to help ensure > that POSH is used in appropriate ways within applications. Thanks for that explanation; it helps. 1. Are Peter Saint-Andre and Matt Miller willing and able to act as the designated experts? If so, I'll put that in for IESG approval. 2. Do you want expert review to also apply to IETF documents (such as xmpp-dna, which would then need expert review before final approval)? If not, you could use "Expert Review OR IETF Review", or "Expert Review OR Standards Action". 3. It would be good to have a short paragraph or a pointer to other text that gives some guidance of what "used in appropriate ways" means, so the DEs (should we eventually put in someone other than the authors) know what not to accept. > Registration requests are to be sent to the posh@ietf.org mailing > list for review and comment, with an appropriate subject (e.g., > "Request for POSH service name: example"). > > Before a period of 14 days has passed, the Designated Expert(s) will > either approve or deny the registration request, communicating this > decision both to the review list and to IANA. Denials should include > an explanation and, if applicable, suggestions as to how to make the > request successful. Registration requests that are undetermined for > a period longer than 21 days can be brought to the IESG's attention > (using the iesg@iesg.org mailing list) for resolution. > > 9.2.1. Registration Template > > Service name: The name requested, relative to "/.well-known/posh/"; > e.g., a service name of "example" would result in a well-known URI > such as "https://example.com/.well-known/posh/example.json". > > Change controller: For Standards-Track RFCs, state "IETF". In all > other cases, give the name of the responsible party. Other > details (e.g., postal address, e-mail address, home page URI) may > also be included. Is there a reason not to make e-mail address mandatory? IANA ought to have a recorded contact point. > Definition and usage: A brief description that defines the service > name and mentions where and how it is used (e.g., in the context > of a particular application protocol). > > Specification: Optionally, reference to a document that specifies > the service or application protocol that uses the service name, > preferably including a URI that can be used to retrieve a copy of > the document. An indication of the relevant sections may also be > included, but is not required. > > ### > > And we would need to make associated changes in draft-ietf-xmpp-dna, such > as... > > ### > > 9. IANA Considerations > > The POSH specification [I-D.ietf-xmpp-posh] establishes a registry > for POSH service names to be used in well-known URIs [RFC5785]. This > specification registers two such URIs for use in XMPP: "xmpp-client" > and "xmpp-server". The completed registration templates follow. > > 9.1. POSH Service Name for xmpp-client Service > > POSH service name: xmpp-client This should probably match the template in the other document, so either change this to "Service name" or change the template to "POSH service name". > Change controller: IETF > > Definition and usage: Specifies the location of a POSH file > containing verification material or a reference thereto that enables > a client to verify the identity of a server for a client-to-server > stream in XMPP > > Specification: [[ this document ]] > > 9.2. POSH Service Name for xmpp-server Service > > POSH service name: xmpp-server > > Change controller: IETF > > Definition and usage: Specifies the location of a POSH file > containing verification material or a reference thereto that enables > a server to verify the identity of a peer server for a server-to- > server stream in XMPP > > Specification: [[ this document ]] > > ### > > Matt and I have checked this approach with a few implementers and potential > implementers; no one has objected yet, but if folks on the xmpp@ietf.org > list or elsewhere have significant concerns it would be great to hear from > you. :-) Barry From nobody Fri Aug 28 06:49:16 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62A41ACEB6 for ; Fri, 28 Aug 2015 06:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 A_z7KwRzLE-V for ; Fri, 28 Aug 2015 06:49:10 -0700 (PDT) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) (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 D0C261AC3E1 for ; Fri, 28 Aug 2015 06:49:07 -0700 (PDT) Received: by padfo6 with SMTP id fo6so25104545pad.0 for ; Fri, 28 Aug 2015 06:49:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=9CEUzuajDk5nJtXBtUVM+s6L8lAfj6SVFV59rxzdk1w=; b=VewVw8oOz1xSfkgerZc54Nysh6QIDTcPpMlFm7N5BgolIt53+IIX+GeVqvuUkGffkK rH/A7T9LwNeWXc+pKfl/yfdG+cKfedPJ5FEjntijNqK6GlhpTcVi39JENV1hW6y7aHdY E7uV4ogMWld4RXIS7H5R29om4fgZHZoE2OlbkE/q8CxOnae0NelcjtPQi27rokDZRA0O szbxf/83ak0xB/hByQxEEIV1Fgve6zc7BWrbV6FpUIvXC15bRzAsk7kc7coMDHG5mhuz T74kHVliWf6rUE7Y2WAVH9xI5o5HDMRDd0zA4fsXDgglP2qqdRvJ18OXTe+yEibPqAPz H91g== X-Gm-Message-State: ALoCoQmSt5KC9VQkW1Aovecr032ebPwipn2EjRK/8nHST2A8vcBwHyQ2r0J0mcqsF/DbvQwxH5YK X-Received: by 10.68.184.225 with SMTP id ex1mr15165184pbc.75.1440769747447; Fri, 28 Aug 2015 06:49:07 -0700 (PDT) Received: from aither.local (71-94-217-18.static.knwc.wa.charter.com. [71.94.217.18]) by smtp.googlemail.com with ESMTPSA id fd9sm1147229pab.34.2015.08.28.06.49.05 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 28 Aug 2015 06:49:06 -0700 (PDT) To: Barry Leiba References: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> <55BACBBF.3060301@andyet.net> <55BBA4C1.6040404@andyet.net> <55CA9A10.2080603@andyet.net> <55D3B0D8.2010202@andyet.net> <37FFCBB4-6921-4A6C-91A4-D1569CD96381@nostrum.com> <55DBAE21.3020408@cisco.com> <8C4C868A-B232-4F2B-A6D3-980785C95DB8@nostrum.com> <55DD249A.4080109@andyet.net> <55DFE8C4.7090707@andyet.net> From: Peter Saint-Andre - &yet Message-ID: <55E066D0.3020109@andyet.net> Date: Fri, 28 Aug 2015 06:49:04 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Ben Campbell , draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, draft-ietf-xmpp-posh@ietf.org, The IESG Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 13:49:12 -0000 On 8/28/15 6:05 AM, Barry Leiba wrote: >>> 1. Recommend URIs like https://example.com/.well-known/posh/spice.json >>> >>> 2. In draft-ietf-xmpp-posh, register "posh" in the well-known URIs >>> registry >>> >>> 3. In draft-ietf-xmpp-posh, set up a registry for POSH protocols >>> >>> 4. In draft-ietf-xmpp-dna, register "xmpp-client" and "xmpp-server" in >>> the POSH registry >>> >>> I offered to Matt that I can propose text for the IANA considerations >>> sections since I've written such text before. I'll endeavor to draft >>> something in the next few days. >> >> Here is proposed text for draft-ietf-xmpp-posh... > > Thanks, Peter; this looks good. Two questions, inline. > >> 9. IANA Considerations >> >> 9.1. Well-Known URI >> >> This specification registers "posh" in the Well-Known URI Registry as >> defined by [RFC5785]. The completed template follows. >> >> URI suffix: posh >> >> Change controller: IETF >> >> Specification: [[ this document ]] >> >> Related information: The suffix "posh" is expected to be followed by >> an additional path component consisting of a service name (say, >> "spice") and a file extension of ".json", resulting in a full path >> of, for instance, "/.well-known/posh/spice.json". Registration of >> service names shall be requested by developers of the relevant >> application protocols. >> >> 9.2. POSH Service Names >> >> This document establishes a registry for POSH service names. > > It would help IANA if you suggested where to put the registry (in an > existing group of registries, or in its own, new top-level group). Ah, I thought that was up to the IANA. Given that POSH service names are used an additional path component in well-known URIs, placing this registry in the Uniform Resource Identifier (URI) Schemes registry would make sense. >> POSH service names are registered on the advice of one or more >> Designated Experts (appointed by the IESG or their delegate). An >> IANA registration policy [RFC5226] of Expert Review was chosen >> instead of the more liberal First Come First Served to help ensure >> that POSH is used in appropriate ways within applications. > > Thanks for that explanation; it helps. > > 1. Are Peter Saint-Andre and Matt Miller willing and able to act as > the designated experts? If so, I'll put that in for IESG approval. I can serve in that capacity. > 2. Do you want expert review to also apply to IETF documents (such as > xmpp-dna, which would then need expert review before final approval)? > If not, you could use "Expert Review OR IETF Review", or "Expert > Review OR Standards Action". I think "Expert Review OR IETF Review" would be fine but I'm not sure what Matt thinks. > 3. It would be good to have a short paragraph or a pointer to other > text that gives some guidance of what "used in appropriate ways" > means, so the DEs (should we eventually put in someone other than the > authors) know what not to accept. Matt and I will try to formulate some text. We had some more specific text but it wasn't quite right. The basic idea is that we don't want folks to be using POSH when other technologies are a better fit. The example we had was DNS SRV but that wasn't correct since the two are complementary. >> Registration requests are to be sent to the posh@ietf.org mailing >> list for review and comment, with an appropriate subject (e.g., >> "Request for POSH service name: example"). >> >> Before a period of 14 days has passed, the Designated Expert(s) will >> either approve or deny the registration request, communicating this >> decision both to the review list and to IANA. Denials should include >> an explanation and, if applicable, suggestions as to how to make the >> request successful. Registration requests that are undetermined for >> a period longer than 21 days can be brought to the IESG's attention >> (using the iesg@iesg.org mailing list) for resolution. >> >> 9.2.1. Registration Template >> >> Service name: The name requested, relative to "/.well-known/posh/"; >> e.g., a service name of "example" would result in a well-known URI >> such as "https://example.com/.well-known/posh/example.json". >> >> Change controller: For Standards-Track RFCs, state "IETF". In all >> other cases, give the name of the responsible party. Other >> details (e.g., postal address, e-mail address, home page URI) may >> also be included. > > Is there a reason not to make e-mail address mandatory? IANA ought to > have a recorded contact point. True. I think that's better. >> Definition and usage: A brief description that defines the service >> name and mentions where and how it is used (e.g., in the context >> of a particular application protocol). >> >> Specification: Optionally, reference to a document that specifies >> the service or application protocol that uses the service name, >> preferably including a URI that can be used to retrieve a copy of >> the document. An indication of the relevant sections may also be >> included, but is not required. >> >> ### >> >> And we would need to make associated changes in draft-ietf-xmpp-dna, such >> as... >> >> ### >> >> 9. IANA Considerations >> >> The POSH specification [I-D.ietf-xmpp-posh] establishes a registry >> for POSH service names to be used in well-known URIs [RFC5785]. This >> specification registers two such URIs for use in XMPP: "xmpp-client" >> and "xmpp-server". The completed registration templates follow. >> >> 9.1. POSH Service Name for xmpp-client Service >> >> POSH service name: xmpp-client > > This should probably match the template in the other document, so > either change this to "Service name" or change the template to "POSH > service name". Correct. >> Change controller: IETF >> >> Definition and usage: Specifies the location of a POSH file >> containing verification material or a reference thereto that enables >> a client to verify the identity of a server for a client-to-server >> stream in XMPP >> >> Specification: [[ this document ]] >> >> 9.2. POSH Service Name for xmpp-server Service >> >> POSH service name: xmpp-server >> >> Change controller: IETF >> >> Definition and usage: Specifies the location of a POSH file >> containing verification material or a reference thereto that enables >> a server to verify the identity of a peer server for a server-to- >> server stream in XMPP >> >> Specification: [[ this document ]] >> >> ### >> >> Matt and I have checked this approach with a few implementers and potential >> implementers; no one has objected yet, but if folks on the xmpp@ietf.org >> list or elsewhere have significant concerns it would be great to hear from >> you. :-) > > Barry Thanks for the review! Peter -- Peter Saint-Andre https://andyet.com/ From nobody Fri Aug 28 07:26:33 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771B51B2BB7; Fri, 28 Aug 2015 07:26: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=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 mvghvb6PUC3k; Fri, 28 Aug 2015 07:26:31 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 AE3BD1B2AD5; Fri, 28 Aug 2015 07:26:25 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t7SEQ7J6018473 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 28 Aug 2015 09:26:17 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Barry Leiba" Date: Fri, 28 Aug 2015 09:26:06 -0500 Message-ID: In-Reply-To: References: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> <55BACBBF.3060301@andyet.net> <55BBA4C1.6040404@andyet.net> <55CA9A10.2080603@andyet.net> <55D3B0D8.2010202@andyet.net> <37FFCBB4-6921-4A6C-91A4-D1569CD96381@nostrum.com> <55DBAE21.3020408@cisco.com> <8C4C868A-B232-4F2B-A6D3-980785C95DB8@nostrum.com> <55DD249A.4080109@andyet.net> <55DFE8C4.7090707@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, draft-ietf-xmpp-posh@ietf.org, The IESG Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 14:26:32 -0000 On 28 Aug 2015, at 8:05, Barry Leiba wrote: >> Here is proposed text for draft-ietf-xmpp-posh... > > Thanks, Peter; this looks good. Two questions, inline. +1. Just one additional question: > >> Registration requests are to be sent to the posh@ietf.org mailing >> list for review and comment, with an appropriate subject (e.g., >> "Request for POSH service name: example"). >> >> Before a period of 14 days has passed, the Designated Expert(s) will >> either approve or deny the registration request, communicating this >> decision both to the review list and to IANA. Denials should include >> an explanation and, if applicable, suggestions as to how to make the >> request successful. Registration requests that are undetermined for >> a period longer than 21 days can be brought to the IESG's attention >> (using the iesg@iesg.org mailing list) for resolution. Do you expect to have a (perhaps rotating) panel of experts? I think if we have one or two designated (to IANA) experts, IANA will automatically do the right thing for any registration attempt, including bugging the ADs if the experts are non-responsive. From nobody Fri Aug 28 08:00:05 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC2B1B3377; Fri, 28 Aug 2015 08:00:01 -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 jJC-56VTZbIe; Fri, 28 Aug 2015 08:00:00 -0700 (PDT) Received: from mail-vk0-x244.google.com (mail-vk0-x244.google.com [IPv6:2607:f8b0:400c:c05::244]) (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 1EFD31B334F; Fri, 28 Aug 2015 08:00:00 -0700 (PDT) Received: by vkbf67 with SMTP id f67so477188vkb.0; Fri, 28 Aug 2015 07:59:59 -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=yndS4U85YiLcyqLbWgFvUHTZiR6nQlLujvlkrNtx01Q=; b=JPI75L/6HIbgmW9ysLkbw1y3AzpzDU5k4eOvfqs5/3YxgND4PHTupxvCnylVBUY3NX 20V1kxHtu1hSKFh/kcFRdbP7N1pQLYg+BtbRfGEWtNkZ+J9OXa2D5ohGBLHpdYNKqUlJ s8aqgMSyRUsne72ZdaesU4PPR/Wqr6zs0V4iKYP8AJtiEAeYO/zHaaE5eOXgdekp0KY9 5++Z4mYQLtkNE50a70vEPzXqQaYaJXI48JOcUgZVt3ybLB438OQtlhck5vNY63DTl8jC 2M3qExl7Ew3y2Pp2s3cP7hY0N+VQvEuH5iCdmNAVtSk0UZnjUSD5lmRijVAejOhTgMVP eFUg== MIME-Version: 1.0 X-Received: by 10.52.185.74 with SMTP id fa10mr8747608vdc.63.1440773999404; Fri, 28 Aug 2015 07:59:59 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Fri, 28 Aug 2015 07:59:59 -0700 (PDT) In-Reply-To: References: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> <55BACBBF.3060301@andyet.net> <55BBA4C1.6040404@andyet.net> <55CA9A10.2080603@andyet.net> <55D3B0D8.2010202@andyet.net> <37FFCBB4-6921-4A6C-91A4-D1569CD96381@nostrum.com> <55DBAE21.3020408@cisco.com> <8C4C868A-B232-4F2B-A6D3-980785C95DB8@nostrum.com> <55DD249A.4080109@andyet.net> <55DFE8C4.7090707@andyet.net> Date: Fri, 28 Aug 2015 10:59:59 -0400 X-Google-Sender-Auth: ZIjV-XREw_uue4-zsa_s6zwmLbg Message-ID: From: Barry Leiba To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, draft-ietf-xmpp-posh@ietf.org, The IESG Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 15:00:01 -0000 >>> Before a period of 14 days has passed, the Designated Expert(s) will >>> either approve or deny the registration request, communicating this >>> decision both to the review list and to IANA. Denials should include >>> an explanation and, if applicable, suggestions as to how to make the >>> request successful. Registration requests that are undetermined for >>> a period longer than 21 days can be brought to the IESG's attention >>> (using the iesg@iesg.org mailing list) for resolution. > > Do you expect to have a (perhaps rotating) panel of experts? I think if we > have one or two designated (to IANA) experts, IANA will automatically do the > right thing for any registration attempt, including bugging the ADs if the > experts are non-responsive. That's true, and it's not necessary to have time periods in there. On the other hand, putting in recommended times does seem to me to be useful for setting expectations. Maybe IANA can comment about whether they like such things, or prefer not to be constrained by them. Barry From nobody Fri Aug 28 08:16:51 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1CA1B3660; Fri, 28 Aug 2015 08:16:48 -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=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 YervRNgTfvAY; Fri, 28 Aug 2015 08:16:40 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 D67FD1B3667; Fri, 28 Aug 2015 08:16:40 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t7SFGRlD022978 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 28 Aug 2015 10:16:37 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Barry Leiba" Date: Fri, 28 Aug 2015 10:16:26 -0500 Message-ID: <65E92DD7-E2D2-473C-B67A-70B6B6230BDA@nostrum.com> In-Reply-To: References: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> <55BACBBF.3060301@andyet.net> <55BBA4C1.6040404@andyet.net> <55CA9A10.2080603@andyet.net> <55D3B0D8.2010202@andyet.net> <37FFCBB4-6921-4A6C-91A4-D1569CD96381@nostrum.com> <55DBAE21.3020408@cisco.com> <8C4C868A-B232-4F2B-A6D3-980785C95DB8@nostrum.com> <55DD249A.4080109@andyet.net> <55DFE8C4.7090707@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, draft-ietf-xmpp-posh@ietf.org, The IESG Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 15:16:49 -0000 On 28 Aug 2015, at 9:59, Barry Leiba wrote: >>>> Before a period of 14 days has passed, the Designated Expert(s) >>>> will >>>> either approve or deny the registration request, communicating this >>>> decision both to the review list and to IANA. Denials should >>>> include >>>> an explanation and, if applicable, suggestions as to how to make >>>> the >>>> request successful. Registration requests that are undetermined >>>> for >>>> a period longer than 21 days can be brought to the IESG's attention >>>> (using the iesg@iesg.org mailing list) for resolution. >> >> Do you expect to have a (perhaps rotating) panel of experts? I think >> if we >> have one or two designated (to IANA) experts, IANA will automatically >> do the >> right thing for any registration attempt, including bugging the ADs >> if the >> experts are non-responsive. > > That's true, and it's not necessary to have time periods in there. On > the other hand, putting in recommended times does seem to me to be > useful for setting expectations. > > Maybe IANA can comment about whether they like such things, or prefer > not to be constrained by them. For what it's worth, the comment also applied to the prior paragraph (to the effect that registration requests should be sent to a designated mailing list.). From nobody Fri Aug 28 08:22:10 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893C41B31F3; Fri, 28 Aug 2015 08:22:05 -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 8zNcDBlShxoN; Fri, 28 Aug 2015 08:22:04 -0700 (PDT) Received: from mail-vk0-x241.google.com (mail-vk0-x241.google.com [IPv6:2607:f8b0:400c:c05::241]) (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 9C9041ACDAB; Fri, 28 Aug 2015 08:22:04 -0700 (PDT) Received: by vkbf67 with SMTP id f67so505106vkb.0; Fri, 28 Aug 2015 08:22:04 -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=sDiMR0u0i3avTMBthX2DewRvRBsZadQMyPy2OupgL3E=; b=bYvFzf6EOsrMNIf6vi3pV3vJKTKYhiTFnjWzz/hD07GdjCHjDuXo1wy6sdaDHdNpkC ZsK+SghJpc3WB99Wz66Ww6zs2a4RZqm6LuzP2m6QAJnFR0fWDKNk4UpiUBkApoCYrdD7 TOncSIPnFKj6jaoy56owJBUCJKpQhRFsRKbq8o4Nz93Ifn3nBO1lb74cp/6sSkuujvE4 WB2bSpXicW7+8U5yqZh+kedaoeh1xrmUcPFoUTaXfPZl60EXVmrxep+IJlECcA2yFob0 A/yMlOaP2H6osMfVbmovqnYPIY4+BKkg4V59KonpBnEXNPuOWUD+0SHMdm2vN3qogVly 8sSg== MIME-Version: 1.0 X-Received: by 10.52.108.233 with SMTP id hn9mr4564788vdb.27.1440775323911; Fri, 28 Aug 2015 08:22:03 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Fri, 28 Aug 2015 08:22:03 -0700 (PDT) In-Reply-To: <65E92DD7-E2D2-473C-B67A-70B6B6230BDA@nostrum.com> References: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> <55BACBBF.3060301@andyet.net> <55BBA4C1.6040404@andyet.net> <55CA9A10.2080603@andyet.net> <55D3B0D8.2010202@andyet.net> <37FFCBB4-6921-4A6C-91A4-D1569CD96381@nostrum.com> <55DBAE21.3020408@cisco.com> <8C4C868A-B232-4F2B-A6D3-980785C95DB8@nostrum.com> <55DD249A.4080109@andyet.net> <55DFE8C4.7090707@andyet.net> <65E92DD7-E2D2-473C-B67A-70B6B6230BDA@nostrum.com> Date: Fri, 28 Aug 2015 11:22:03 -0400 X-Google-Sender-Auth: zI83xuQDDDFdYKSMWvuyZ55ucH0 Message-ID: From: Barry Leiba To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, draft-ietf-xmpp-posh@ietf.org, The IESG Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 15:22:05 -0000 > For what it's worth, the comment also applied to the prior paragraph (to the > effect that registration requests should be sent to a designated mailing > list.). That's been a common thing in many app-related registries, to allow the community to participate in the process and comment. It's been a useful way for people making requests to get feedback, not just from the DEs. Barry From nobody Fri Aug 28 08:38:48 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116D21A1A11; Fri, 28 Aug 2015 08:38:44 -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=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 WH-ePwvGFOmu; Fri, 28 Aug 2015 08:38:43 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 407731A0083; Fri, 28 Aug 2015 08:38:43 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t7SFcTbx033774 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 28 Aug 2015 10:38:40 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Barry Leiba" Date: Fri, 28 Aug 2015 10:38:29 -0500 Message-ID: <8CC458C6-2460-4075-8F0F-DE54B97B134C@nostrum.com> In-Reply-To: References: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> <55BACBBF.3060301@andyet.net> <55BBA4C1.6040404@andyet.net> <55CA9A10.2080603@andyet.net> <55D3B0D8.2010202@andyet.net> <37FFCBB4-6921-4A6C-91A4-D1569CD96381@nostrum.com> <55DBAE21.3020408@cisco.com> <8C4C868A-B232-4F2B-A6D3-980785C95DB8@nostrum.com> <55DD249A.4080109@andyet.net> <55DFE8C4.7090707@andyet.net> <65E92DD7-E2D2-473C-B67A-70B6B6230BDA@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, draft-ietf-xmpp-posh@ietf.org, The IESG Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 15:38:44 -0000 On 28 Aug 2015, at 10:22, Barry Leiba wrote: >> For what it's worth, the comment also applied to the prior paragraph >> (to the >> effect that registration requests should be sent to a designated >> mailing >> list.). > > That's been a common thing in many app-related registries, to allow > the community to participate in the process and comment. It's been a > useful way for people making requests to get feedback, not just from > the DEs. > I'm happy with that in principle, but do we expect _IANA_ to send to the mailing list vs directly to designated experts? Will that list be limited to approved designated experts? Is the list for people to get early advice on registrations before they go to IANA? (I'm sure this has all been worked out for other app-related registries. I just don't know the answers.) > Barry From nobody Fri Aug 28 10:58:26 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543081ACE41; Fri, 28 Aug 2015 10:58:22 -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 pfeRpW7rm7BM; Fri, 28 Aug 2015 10:58:21 -0700 (PDT) Received: from mail-vk0-x241.google.com (mail-vk0-x241.google.com [IPv6:2607:f8b0:400c:c05::241]) (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 4EE491A1A06; Fri, 28 Aug 2015 10:58:21 -0700 (PDT) Received: by vkaw128 with SMTP id w128so1209704vka.2; Fri, 28 Aug 2015 10:58:20 -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=7DAmVS9NRDyzP8WtliywLV5w7EDuZ3eoFK3UrGt0g98=; b=nq7+Mf0hTmpuidJXbIZdz7dekuHYqUvPnaHaKUCIoDhZEAjvUwJyLylQlK8tVBZTqG XTPrf1j/o3nFVkEFo+9nEhJuCWdNifMUgcF9VZrhUgZmJG/i/Tp5w58vuZ69Bk7N+AIb stY5hRx/NWf1su4Yw3WpcQ5/iSOAFIrHt2MdieZagoGkSNCFcWvgwpdsb+C1MRAB3/lh fS6lIm+QCpXWeuntrGuHd7kpjRELYUa0ZItFdz077l6IXVmZFFcwJXLD/RUoNnKqxN0+ +MyJNFPWwnKvVdw2nmbtAA8lUaROqNzBcva1SOU4hOBIitn4SNHiF5D1Zi/zEN+9cJ2S avKw== MIME-Version: 1.0 X-Received: by 10.52.32.230 with SMTP id m6mr9562953vdi.80.1440784700577; Fri, 28 Aug 2015 10:58:20 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.88.196 with HTTP; Fri, 28 Aug 2015 10:58:20 -0700 (PDT) In-Reply-To: <8CC458C6-2460-4075-8F0F-DE54B97B134C@nostrum.com> References: <20150729090441.16993.2639.idtracker@ietfa.amsl.com> <55BACBBF.3060301@andyet.net> <55BBA4C1.6040404@andyet.net> <55CA9A10.2080603@andyet.net> <55D3B0D8.2010202@andyet.net> <37FFCBB4-6921-4A6C-91A4-D1569CD96381@nostrum.com> <55DBAE21.3020408@cisco.com> <8C4C868A-B232-4F2B-A6D3-980785C95DB8@nostrum.com> <55DD249A.4080109@andyet.net> <55DFE8C4.7090707@andyet.net> <65E92DD7-E2D2-473C-B67A-70B6B6230BDA@nostrum.com> <8CC458C6-2460-4075-8F0F-DE54B97B134C@nostrum.com> Date: Fri, 28 Aug 2015 13:58:20 -0400 X-Google-Sender-Auth: feJn-Aq0AkNoU7IBNLHqmRriNl0 Message-ID: From: Barry Leiba To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-xmpp-posh.shepherd@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, draft-ietf-xmpp-posh.ad@ietf.org, draft-ietf-xmpp-posh@ietf.org, The IESG Subject: Re: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 17:58:22 -0000 >> That's been a common thing in many app-related registries, to allow >> the community to participate in the process and comment. It's been a >> useful way for people making requests to get feedback, not just from >> the DEs. > > I'm happy with that in principle, but do we expect _IANA_ to send to the > mailing list vs directly to designated experts? Will that list be limited to > approved designated experts? Is the list for people to get early advice on > registrations before they go to IANA? Ah, no: IANA does what IANA does, which is contacting the DE(s). When people have tried to say otherwise in their documents, I've pushed them not to tell IANA how to run their process, and instead to give advice to those making the requests. For the mailing lists discussions, it's always the intent that requestors are asked to post to the mailing list, and that DEs should use any discussion on the mailing list to advise their review. Barry