[alto] Review of draft-ietf-alto-xdom-disc-02

["Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[e-mail]>]

Hello authors of the XDOM draft,

Please find below par my review of draft-ietf-alto-xdom-disc-02, with a focus on sections 1 and 2.
The high text volume in the detailed comments is due to copy-pasting text to insert suggested updates.

For the caption in modified sentences:
"... ++bla bla++  ..." means respectively ++added text++
"... --bla bla--  ..." means respectively --deleted text--

Thanks,
Sabine

========================================================
General comments on the document
========================================================
The Introduction clearly motivates the need for an extended server discovery procedure but lacks a couple of sentences, before diving into technical details, on what the new procedure does, how one can use its output and for which type of request it is more advantageous to use this extension rather than RFC7286.

In this extent Section 2 kind of misses an overview before section 2.1, that would list and define the  main steps described in sections 2.2 to 2.4 and suitability for given ALTO services. The latter sections also need more clarifications and details. A more "fleshed" example procedure in section 2.4 would help.

In section 3 some more text would help to highlight the role of xdom.
Section 3.1: what is the relation to xdom? If the purpose is to show that xdom is not necessarily suitable there a sentence in that sense should be added there.
Section 3.2: conclusion seems similar to section 3.2 and should be added as well.
Section 3.3 and 3.4 should empasize the utility of xdom and how it can be expoited, possibly with an example.

The appendices and other sections are clear and well written.

========================================================
SOME DETAILED COMMENTS AND SUGGESTIONS - Intro + section 2
========================================================

----------------
1. Introduction
----------------

--- Para 4
Some positioning is needed there. Proposal:
... specifies an ++ extended ++ ALTO server discovery that runs
on the client side. ++ It is called "ALTO Cross-Domain Server Discovery Procedure" and provides one more ALTO server IRD URIs that are relevant for given IP addresses or prefixes. ++ An ALTO client ... answer. ++ The suitable ALTO server can be selected from the resulting list. ++ The wording ...

----------------
2. ALTO Cross-Domain Server Discovery Procedure Specification
----------------
This procedure was inspired by ++ the Location Information Server (LIS) Discovery solution Using IP Addresses and Reverse DNS solution described in++ [RFC7216] and...

----------------
2.1. Interface
----------------
An overview is needed at this stage so I suggest to entitle this section "Overview" move some text around and add some according explanations. Proposals:

- After paragraph 1 (The procedure...), move/insert:
The procedure performs DNS lookups and returns one or more URI(s) of
information resources related to that IP address or prefix, usually
the URI(s) of one or more ALTO Information Resource Directory (IRD,
see Section 9 of [RFC7285]).

For the remainder of the document, we use the notation:
IRD_URIS_X := XDOMDISC(X,"ALTO:https").
++ This notation designates TBC .... ++

2.1.1 Main steps of the XDOM... procedure
The subsection should list the steps in section 2.2 and add their definition and purpose and say they will be detailed in sections 2.2, 2.3 and 2.4

2.1.2 Interface
The parameter X may be an IPv4 or an IPv6 address or prefix in CIDR
notation (see [RFC4632] for the IPv4 CIDR notation and [RFC4291] for
IPv6). In both cases, it consists of an IP address A and a prefix
length L. For IPv4, it holds: 0 <= L <= 32 and for IPv6, it holds: 0
<= L <= 128.

For example, for X=198.51.100.0/24, we get A=198.51.100.0 and L=24.
Similarly, for X=2001:0DB8::20/128, we get A=2001:0DB8::20 and L=128.

The procedure SHOULD always be called with the U-NAPTR Service
Parameter [RFC4848] set to "ALTO:https". However, other parameter
values MAY be used in some scenarios, e.g., "ALTO:http" to request
unencrypted transmission for debugging purposes, or other application
protocol or service tags if applicable.

----------------
2.2. Step 1: Prepare Domain Name for Reverse DNS Lookup
----------------
OK

----------------
2.3. Step 2: Prepare Shortened Domain Names
----------------
--- Para 2
- last sentence: for easier reading, propose to re-order as follows: "Removing one label (i.e., one number of the "dotted quad notation") from a domain name corresponds to shortening the prefix length by 8 bits."

----------------
2.4. Step 3: Perform DNS U-NAPTR lookups
----------------

--- Para 2: are there examples of other U-NAPTR service types then "ALTO:https" that the procedure can be called with?