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?
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto