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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 17 Jul 2019 15:52:19 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-alto-xdom-disc-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-alto-xdom-disc/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the updates; they have captured enough of the discussion we had
to clarify that most of my points of concern are either non-concerns or have
adequate workarounds.

I'm still not entirely sure that DNSSEC in the reverse zone is available everywhere
in a robust fashion, but it seems that there is enough availability that the mechanisms
specified here can still be used in a useful manner.

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.

Also, one nit in Section 2: s/is usually always be set/is usually set/

---

From: Sebastian Kiesel <[email-masked]>
Date: Mon, 29 Jul 2019 20:41:32 +0200

Hi, 

On Wed, Jul 17, 2019 at 03:52:19PM -0700, Benjamin Kaduk via Datatracker wrote:
> 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?

Thanks
Sebastian

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 31 Jul 2019 15:15:22 -0500

> 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