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

Sebastian Kiesel <ietf-alto@skiesel.de> Tue, 20 August 2019 18:14 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 C11BA12097D; Tue, 20 Aug 2019 11:14:43 -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 8BlQUG4D5xbL; Tue, 20 Aug 2019 11:14:42 -0700 (PDT)
Received: from mx10.wurstkaes.de (mx10.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 3FA551207FC; Tue, 20 Aug 2019 11:14:42 -0700 (PDT)
Received: from p200300e7ef0189003285a9fffe406c00.dip0.t-ipconnect.de ([2003:e7:ef01:8900:3285:a9ff:fe40:6c00]:45570 helo=blafasel.ehlo.wurstkaes.de) by mx10.wurstkaes.de with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <ietf-alto@skiesel.de>) id 1i08eR-0005U5-4H; Tue, 20 Aug 2019 20:14:35 +0200
Date: Tue, 20 Aug 2019 20:14:33 +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: <20190820181432.GB6040@blafasel.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)
X-Wurstkaes-SMTP-Client: IPv6:[2003:e7:ef01:8900:3285:a9ff:fe40:6c00]:45570
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/8owQ6xkSK2vbHq5xFBHHLIuZTOo>
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: Tue, 20 Aug 2019 18:14:44 -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"

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