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