Re: [alto] Benjamin Kaduk's No Objection on draft-ietf-alto-xdom-disc-05: (with COMMENT)
Sebastian Kiesel <ietf-alto@skiesel.de> Thu, 01 August 2019 20:13 UTC
Return-Path: <ietf-alto@skiesel.de>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE121201E6; Thu, 1 Aug 2019 13:13:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRXGS3BZV_Cf; Thu, 1 Aug 2019 13:13:48 -0700 (PDT)
Received: from gw01.ehlo.wurstkaes.de (gw01.ehlo.wurstkaes.de [IPv6:2a02:a00:e000:116::41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B85C1201DC; Thu, 1 Aug 2019 13:13:48 -0700 (PDT)
Received: from gw01.ehlo.wurstkaes.de ([2a02:a00:e000:116::41]:43328) by gw01.ehlo.wurstkaes.de with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <ietf-alto@skiesel.de>) id 1htHSL-0002g0-26; Thu, 01 Aug 2019 22:13:45 +0200
Date: Thu, 01 Aug 2019 22:13:43 +0200
From: Sebastian Kiesel <ietf-alto@skiesel.de>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, alto-chairs@ietf.org, draft-ietf-alto-xdom-disc@ietf.org, jan.seedorf@hft-stuttgart.de, alto@ietf.org
Message-ID: <20190801201343.GA3131@gw01.ehlo.wurstkaes.de>
References: <156340393916.25833.11508102922044405602.idtracker@ietfa.amsl.com> <20190729184132.GA6931@blafasel.ehlo.wurstkaes.de> <20190731201521.GJ1006@kduck.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20190731201521.GJ1006@kduck.mit.edu>
Organization: my personal mail account
Accept-Languages: en, de
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/LQ1tco6lIA34i0c-6hD_glMMayI>
Subject: Re: [alto] Benjamin Kaduk's No Objection on draft-ietf-alto-xdom-disc-05: (with COMMENT)
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Aug 2019 20:13:51 -0000
On Wed, Jul 31, 2019 at 03:15:22PM -0500, Benjamin Kaduk wrote: > On Mon, Jul 29, 2019 at 08:41:32PM +0200, Sebastian Kiesel wrote: > > On Wed, Jul 17, 2019 at 03:52:19PM -0700, Benjamin Kaduk via Datatracker wrote: > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-alto-xdom-disc-05: No Objection > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > However, I do think that we need to clarify in Section 5.2.2 that this > > > mechanism is compatible with the BCP 20 sub-allocation scheme only > > > insamuch as you can add NAPTR records in the relevant locations -- the > > > current procedures described in the text will not catch everything > > > just on their own, IIUC. > > > > Thanks for your feedback and sorry that I have to ask, but > > could you please be more specific about what you think is still missing? > > Well, I was reading fairly fast so it's quite possible the confusion is/was > on my end... > > I'm not 100% sure I know what "the relevant NAPTR resource records" are in > "This ISP may populate the subdomain of in-addr.arpa. that corresponds to > the whole /24 prefix with the relevant NAPTR resource records, even if > BCP20-style delegations or no delegations at all are used"; If we assume the scenario introduced in RFC 2417 Section 4, organization "A" would configure: $ORIGIN 0/25.2.0.192.in-addr.arpa. ... 1 PTR host1.A.domain. 1 NAPTR 100 10 "u" "ALTO:https" "!.*!https://alto.A.domain/ird!" "" 2 PTR host2.A.domain. 2 NAPTR 100 10 "u" "ALTO:https" "!.*!https://alto.A.domain/ird!" "" 3 PTR host3.A.domain. 3 NAPTR 100 10 "u" "ALTO:https" "!.*!https://alto.A.domain/ird!" "" and organization "B" would configure $ORIGIN 128/26.2.0.192.in-addr.arpa. ... 129 PTR host1.B.domain. 129 NAPTR 100 10 "u" "ALTO:https" "!.*!https://alto.B.domain/ird!" "" ... ==> "The ALTO Cross-Domain Server Discovery procedure is compatible with this method." (Note: "this method" = BCP20; the word "this" was missing in that sentence in draft-ietf-alto-xdom-disc-05, will be fixed in the next version of the document). However, organization "C" might not know about this great new discovery method or maybe they do not understand the benefits. But the ISP that has the /24 and serves organizations A, B, and C may still want to use ALTO, because the ISP might benefit from lower resource utilization in the network infrastructure if the traffic from/to hosts in C's network is optimized using ALTO. Thus, the ISP could configure: $ORIGIN 2.0.192.in-addr.arpa. ... . NAPTR 100 10 "u" "ALTO:https" "!.*!https://alto.my.domain/ird!" "" ==> "This ISP may populate the subdomain of in-addr.arpa. that corresponds to the whole /24 prefix with the relevant NAPTR resource records, ..." If we'd call, for example, XDOMDISC(192.0.2.193/32,"ALTO:https"), the procedure would first search for a NAPTR record at R32=193.2.0.192.in-addr.arpa.=cname=>193.192/26.2.0.192.in-addr.arpa. without result (as organization "C" did not configure the NAPTRs), then do a lookup for R24=2.0.192.in-addr.arpa. and find the ISP's ALTO server. How could we improve the second quoted sentence? > If there's anything in a different form than what's already shown in > examples in section 3, it may be worth providing another example here, even > though RFC 2317 will have the bulk of the relevant content. I think our main priority should be to improve the second sentence quoted above, to show that the interaction between XDOMDISC and BCP20 is very straightforward, so maybe we can omit a further example. Btw: is BCP20 widely in use? I might be wrong, but my impression is that this is a niche solution for a (hopefully) disappearing protocol (IPv4). Just wondering how much space we should use in our document for explaining that there is no interoperability problem. Thanks, Sebastian
- [alto] Benjamin Kaduk's No Objection on draft-iet… Benjamin Kaduk via Datatracker
- Re: [alto] Benjamin Kaduk's No Objection on draft… Sebastian Kiesel
- Re: [alto] Benjamin Kaduk's No Objection on draft… Benjamin Kaduk
- Re: [alto] Benjamin Kaduk's No Objection on draft… Sebastian Kiesel
- Re: [alto] Benjamin Kaduk's No Objection on draft… Sebastian Kiesel