Re: Éric Vyncke's Yes on draft-ietf-httpbis-alias-proxy-status-05: (with COMMENT)

[Tommy Pauly <[e-mail]>]

Hi Éric,

Thanks for the review! I’m glad you like the IPv6 =) Some comments inline.

Best,
Tommy

> On Oct 24, 2023, at 2:36 AM, Éric Vyncke via Datatracker <[e-mail]> wrote:
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-httpbis-alias-proxy-status-05: Yes
> 
> 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/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-alias-proxy-status/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> # Éric Vyncke, INT AD, comments for draft-ietf-httpbis-alias-proxy-status-05
> 
> Thank you for the work put into this document. It is well written, concise, and
> useful. I love when an I-D uses IPv6 examples ;-)
> 
> Please find below osome non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education).
> 
> Special thanks to Mark Nottingham for the shepherd's detailed write-up
> including the WG consensus, ***but it lacks*** the justification of the
> intended status.
> 
> Other thanks to Brian Haberman, the Internet directorate reviewer (at my
> request), please consider this int-dir review:
> https://datatracker.ietf.org/doc/review-ietf-httpbis-alias-proxy-status-05-intdir-telechat-haberman-2023-10-23/
> (and I have read the follow-up discussion)
> 
> I hope that this review helps to improve the document,
> 
> Regards,
> 
> -éric
> # COMMENTS
> 
> ## Use of 'name'
> 
> The text often use the word 'name', while draft-ietf-dnsop-rfc8499bis (and of
> course RFC 8499) does not use the word 'name' without qualification. I strongly
> suggest to stick to the 'approved' DNS terminology.
> 
> Adding draft-ietf-dnsop-rfc8499bis or RFC 8499 as informative reference would
> be a plus.
> 
> ## Multiple hops example
> 
> Another example with a proxy chain (i.e., multiple names in Proxy-Status:)
> would be benefitial.

Interesting point! I’ll see if there’s a way to add an example in for that that isn’t too verbose.
> 
> ## Section 2
> 
> Why is this not a MUST in `The names SHOULD appear in the order in which they
> were received in DNS` ? Is the information still useful if not in the order ?
> When can the SHOULD not be enforced ?

Two thoughts here:
- The information could indeed still be useful; the order isn’t really the key piece of information for the client.
- This could be a MUST, but it is unenforceable — the client has no way to know one way or the other. I often prefer MUSTs that would cause a failure if it isn’t followed.

> 
> `The proxy MAY send the empty string ("")`, I usually do not like 'negative
> signalling', i.e., giving semantics to an absence of signal. There could be too
> many false positives.

This was not originally something we included, but it was added based on server implementor feedback.

> 
> ## Section 2.1
> 
> RFC 1035 section 3.1 is not really specifying the set of characters in a DNS
> label. And, it is also clear in this RFC that neither comma nor dot are valid
> in a label per BNF, please update the reference.

The paragraph within that section that I was referencing is this:

Although labels can contain any 8 bit values in octets that make up a
label, it is strongly recommended that labels follow the preferred
syntax described elsewhere in this memo, which is compatible with
existing host naming conventions.  Name servers and resolvers must
compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII
with zero parity.  Non-alphabetic codes must match exactly.

So, I believe this is correct. The feedback we go during development of the draft was clear that labels in CNAMEs could have commas or dots.

> 
> ## Normative references
> 
> Really unsure whether RFC 9298 is normative.

I could see this going either way. If anyone has particularly strong feelings, I’d be happy to change this, but this is one of the kinds of proxies this applies to.