[apps-discuss] Review of draft-ietf-alto-protocol-11.txt
Ted Hardie <ted.ietf@gmail.com> Thu, 26 April 2012 21:40 UTC
Return-Path: <ted.ietf@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8444A11E809B for <apps-discuss@ietfa.amsl.com>; Thu, 26 Apr 2012 14:40:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.569
X-Spam-Level:
X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WU8gz2w5jNfH for <apps-discuss@ietfa.amsl.com>; Thu, 26 Apr 2012 14:40:30 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0486821F883A for <apps-discuss@ietf.org>; Thu, 26 Apr 2012 14:40:29 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so73850vcb.31 for <apps-discuss@ietf.org>; Thu, 26 Apr 2012 14:40:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=vOqYhJorrJWhHncrw26vOJE50g5SJ0HaAtkDr8y+UJE=; b=vTPSbdU1n4kU/ka8urOSO/ImeOe3H0MXxSn6eyvLkGli9TKxo18SAdT1M5ayDhOzoQ YuPjxv2d5QTTfJ/iBCf/1BfxRnzQykVkfwhgLN8Yor+NOLdEoY1SIqRqCbwJZ3QjmhN/ dTSek/bt/nK0H3GDoWEZQlCC+PD4779VLgfpAQIkuxZ9shipNXNkmYJhb20OUAc+PMVU fd7EItZD7F0S5bOcEQr4YbdND9S0mICTvi+i9Q8vdRxnBA8pFjsjNbuCHO8mVVL9pGGj m57e9PJ1t1TF/rEhQPJgK2DjNEiWVyg8LtiEFTbasVjGXM1sQi3A3M5qL+oflwpy1P3Z rt/A==
MIME-Version: 1.0
Received: by 10.220.149.79 with SMTP id s15mr8743370vcv.60.1335476429508; Thu, 26 Apr 2012 14:40:29 -0700 (PDT)
Received: by 10.52.162.99 with HTTP; Thu, 26 Apr 2012 14:40:29 -0700 (PDT)
Date: Thu, 26 Apr 2012 14:40:29 -0700
Message-ID: <CA+9kkMB4nUayYO3q8ydj477jh9NM8oZyXAQ5k-NsRN=KHjb3cA@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: draft-ietf-alto-protocol.all@tools.ietf.org, apps-discuss@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [apps-discuss] Review of draft-ietf-alto-protocol-11.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Apr 2012 21:40:31 -0000
Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-alto-protocol-11.txt Title: ALTO Protocol Reviewer: Ted Hardie Review Date: April 26, 2012 Summary: Despite the length of this review, the document is fundamentally ready for publication on the standards track. There are sections which need clarification or re-consideration, but they are not fundamental to the protocol's operation. Major: Section 5.1 needs clarification. While it clearly introduces the types for the cost type and cost mode parameters, it buries the type for the cost itself within the description of the ordinal cost mode: 5.1.2.2. Cost Mode: ordinal This Cost Mode is indicated by the string 'ordinal'. This mode indicates that the costs values to a set of Destination Network Locations from a particular Source Network Location are a ranking, with lower values indicating a higher preference. The values are non-negative integers. This makes it unclear whether Costs of the numerical Cost Type are similarly restricted to non-negative integers. Based on other descriptions of ordinal comparison (e.g. q values in content negotiation), I also presume that the clients are not expected to infer anything about the weights based on the integers chosen for the ordinal type. That is: 3 PIDS with costs of 2, 4, 6 should be treated the same if the assigned values are 3, 17, 18, because the order is the same. Additional text to highlight this (or provide the appropriate treatment) would be useful. The section would also benefit from an example of a numerical operation other than normalization. In Section 7.2, the document describes the request/response traffic as based on "standard HTTP"; the security considerations sections appears to recommend TLS for integrity protection in 11.3 (this property is not mentioned in 7.2.5, which lists TLS as MAY for authentication and encryption). This should be reconciled; if 11.3 is not recommending TLS or any object-based security, more detail is probably needed on the consequences of an attacker controlling this data. Minor: General comment: there is a great deal of material in this document that is either tutorial in nature or which defends a particular set of design choices (e.g. section 6.1). While this material is not inherently bad, it is interleaved into the specification in ways that make it difficult to extract the concrete protocol specification. If there were sections that the WG felt could be moved to an appendix summarizing the benefits of the ALTO approach and its choices, the spec might get significantly tighter and easier to read. In Section 4.1, the concept of a PID as an identifier is introduced, but without a pointer to the definition of the identifier type. There is a forward reference to section 5, but this describes cost maps, not the PID identifier itself. Reading (or grepping) forward provides a pointer to PIDName, but without a succinct relationship defined. I suggest adapting the description in 7.7.1.1.5 for this purpose: "A PID is a US-ASCII string of type PIDName (see section 7.5.1) and its associated set of endpoint addresses." I believe this could be inserted between the first two sentences of the first paragraph in section 4.1 In Section 4.2.1, the document says: A RECOMMENDED way to satisfy this property is to define a PID that contains the 0.0.0.0/0 prefix for IPv4 or ::/0 (for IPv6). This assumes that the cost map provided includes all IP addresses. While this may be true for some use cases, there are other use cases where it may not be true, and the text here should probably be modified to handle those cases. Something like "A RECOMMENDED way to satisfy this property is to define a PID with the shortest enclosing prefix of the addresses provided in the map. For a map with full IPv4 reachability, this would mean including the 0.0.0.0/ prefix in a PID; for full IPv6 reachability, this would be the ::/0 prefix" might suit the case. In section 7.2.2, the document says: "Note that it is possible for an ALTO Server to employ caching for the response to a POST request. This can be accomplished by returning an HTTP 303 status code ("See Other") indicating to the ALTO Client that the resulting Cost Map is available via a GET request to an alternate URL (which may be cached)." The phrase "employ caching" is ambiguous here, as the results of the initial POST are not cacheable even in the case of a 303; only the results of the later GET request are cachable. Since cachability is a major reason cited for the re-use of HTTP, some additional text on the use cache control directives ("public" and "Max-age" seem particularly important in this context) might also be useful. In 7.4.2, the document describes the error resource, and notes this: reason A (free-form) human-readable explanation of the particular error If I understand JASONString correctly, no language tag is supplied, so human readability will be highly variable, Fixing that, rather than relying on a local mapping of the underlying code, is hard work. Dropping this optional aspect of the error resource may be something for the WG to consider; this pushes localization of the error code description to the endpoint. The endpoint property resource seems to be specified in too many sections for easy comprehension. Section 7.7.3.1 describes it, but points to 7.7.3.1.4 (the related capabilities) which in turn points to 3.1.3, which says: This service allows ALTO Clients to look up properties for individual endpoints. An example endpoint property is its Network Location (its grouping defined by the ALTO Server) or connectivity type (e.g., ADSL, Cable, or FTTH). It is only in Section 10.3, with the creation of the registry, that it is clear that these are registered tokens, rather than free text. I suggest that this be clarified early, with a forward pointer to the actual registry. In section 9.3, the document notes that the ALTO client SHOULD use STUN to determine a public IP for a source address. However, the description of the Endpoint Cost Service contains this text: If the list of Source Endpoints is empty (or not included), the ALTO Server MUST interpret it as if it contained the Endpoint Address corresponding to the client IP address from the incoming connection It would seem a valid recommendation here would be to propose that the CLIENT omit the Source Endpoint where it currently recommends the use of STUN. I infer that this is not recommended because the Endpoint Address service may be provided within a NAT boundary shared with the CLIENT, thus making the source address of the packet different from that which would be seen externally (resolving this would require the ALTO service to have general knowledge of the NAT bindings). But the opposite case is not handled. What happens when the destination address is within the NAT boundary of the client? Won't the external address determined by STUN will have a similar mismatch to the true origin address for packets destined to the internal destination? In 9.4, it may be useful to note that there are private ASNs which are not unique, and that a single looking glass may therefore give an incomplete view of the full mapping of IP addresses to ASNs. In general, this section seems to point to future work, and I suggest that it more clearly say that a standardized method for this mapping is left to future work. In section 10.4, it may be useful to advise the Expert Reviewer on how to handle registrations which differ only as to case; for example, would PRIV: or EXP: be permitted in a registration? Nits: The Abstract says: These maps provide simplified, yet enough information of a network for applications to effectively utilize. This seems to be missing a noun or to require restructuring. Possibly: "These maps provide simplified information, but it is enough for applications to effectively use."? "Additional services are built on top the maps." should be "on top of the maps". In the Introduction, "see below" could be shifted to a more precise forward reference to a specific section. In section 2.2, the document says: In particular, an ALTO Server defines network Endpoints (and aggregations thereof) and generic costs amongst them, both from the network region's own perspective. I personally found this hard to parse. Some re-wording may be useful. (Possibly eliminating the ", both"?) In Figure 1, the top most enclosing box is labelled "ISP". While that is certainly a common use case, there seem to be others. Given the preceding text, would it be more general to use the term "Network Region"? In section 3, the document says: "Note that functionality offered in different services are not totally non-overlapping (e.g., the Map Service and Map Filtering Service)." Would it be equivalent to say "functionality offered in different services may overlap"? Section 3 is titled "Protocol Structure", but the subsections are about specific services, and the base text doesn't really describe what most IETF readers will understand as a description of the structure of the protocol (that seems to be in Section 7). A different title (maybe "Service framework"?) would seem to be a better fit. I believe Section 4 might read more naturally if the second paragraph were moved up to be first. In 7.5.1, the encoding of PID Name is given in relation to a permitted US-ASCII code range, except for the "." separator. Providing the related code point would be useful. Several other sections use "alphanumeric" as a limitation without giving the code point ranges; in those cases, the actual code point ranges would be useful. The Content-Length in some examples (e.g. in 7.6.3) are listed as [TODO]; this should be fixed. In section 9.2, the document says "one path my have a NAT64 middlebox)", where my should be "may". In Section 10.1, it is common for the change controller to be the IESG, rather than the individual editors of the draft.
- [apps-discuss] Review of draft-ietf-alto-protocol… Ted Hardie
- Re: [apps-discuss] Review of draft-ietf-alto-prot… Ben Niven-Jenkins
- Re: [apps-discuss] Review of draft-ietf-alto-prot… Ted Hardie
- Re: [apps-discuss] Review of draft-ietf-alto-prot… Ben Niven-Jenkins
- Re: [apps-discuss] Review of draft-ietf-alto-prot… Ben Niven-Jenkins
- Re: [apps-discuss] Review of draft-ietf-alto-prot… Ben Niven-Jenkins
- Re: [apps-discuss] [alto] Review of draft-ietf-al… Richard Alimi
- Re: [apps-discuss] [alto] Review of draft-ietf-al… Ben Niven-Jenkins
- Re: [apps-discuss] [alto] Review of draft-ietf-al… Vijay K. Gurbani
- Re: [apps-discuss] Review of draft-ietf-alto-prot… Richard Alimi
- Re: [apps-discuss] [alto] Review of draft-ietf-al… David Harrington
- Re: [apps-discuss] [alto] Review of draft-ietf-al… Richard Alimi
- Re: [apps-discuss] Review of draft-ietf-alto-prot… Richard Alimi
- Re: [apps-discuss] Review of draft-ietf-alto-prot… Ted Hardie
- Re: [apps-discuss] Review of draft-ietf-alto-prot… Richard Alimi