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

Benjamin Kaduk <kaduk@mit.edu> Wed, 31 July 2019 20:21 UTC

Return-Path: <kaduk@mit.edu>
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 CE9CE12004F; Wed, 31 Jul 2019 13:21:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 F5e_VUEYjpOs; Wed, 31 Jul 2019 13:21:30 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 9ED3A120018; Wed, 31 Jul 2019 13:21:30 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6VKFMmJ021117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 31 Jul 2019 16:15:24 -0400
Date: Wed, 31 Jul 2019 15:15:22 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Sebastian Kiesel <ietf-alto@skiesel.de>
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: <20190731201521.GJ1006@kduck.mit.edu>
References: <156340393916.25833.11508102922044405602.idtracker@ietfa.amsl.com> <20190729184132.GA6931@blafasel.ehlo.wurstkaes.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190729184132.GA6931@blafasel.ehlo.wurstkaes.de>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/-Ybz7XjYcrtG-0qa-T4sDqhXYLc>
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: Wed, 31 Jul 2019 20:21:33 -0000

On Mon, Jul 29, 2019 at 08:41:32PM +0200, Sebastian Kiesel wrote:
> Hi, 
> 
> 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"; would that be
something like:

192/26.100.51.198.IN-ADDR.ARPA   IN NAPTR <...>
?

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.

Thanks,

Ben