Subject: Re: [alto] Benjamin Kaduk's No Objection on draft-ietf-alto-xdom-disc-05: (with COMMENT)

From: Sebastian Kiesel <[email-masked]>
Date: Thu, 1 Aug 2019 22:13:43 +0200

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

---

From: Sebastian Kiesel <[email-masked]>
Date: Tue, 20 Aug 2019 20:14:33 +0200

On Wed, Jul 31, 2019 at 03:15:22PM -0500, Benjamin Kaduk wrote:
> BCP20-style delegations or no delegations at all are used"

we have submitted a new version of the draft that (hopefully) clarifies this:

   This ISP may install NAPTR resource
   records, which are needed for the ALTO Cross-Domain Server Discovery
   procedure, in the subdomain of in-addr.arpa. that corresponds to the
   whole /24 prefix (c.f., R24 in Section 3.3 of this document), even if
   BCP20-style delegations or no delegations at all are in use.

Thanks,
Sebastian