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 mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
