Subject: Re: [apps-discuss] Review of draft-ietf-alto-protocol-11.txt

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 2 May 2012 17:23:54 +0100

Ted,
On 26 Apr 2012, at 22:40, Ted Hardie wrote:
> 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.

I do not believe that this is the case, from Section 6.5 of draft-ietf-httpbis-p2-semantics-19 (RFC2616 has similar text to the first paragraph):

   Responses to POST requests are only cacheable when they include
   explicit freshness information (see Section 2.3.1 of [Part6]).  A
   cached POST response with a Content-Location header field (see
   Section 6.7 of [Part3]) whose value is the effective Request URI MAY
   be used to satisfy subsequent GET and HEAD requests.

   Note that POST caching is not widely implemented.  However, the 303
   (See Other) response can be used to direct the user agent to retrieve
   a cacheable resource.

Ben

>  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.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 2 May 2012 09:28:49 -0700

>   (See Other) response can be used to direct the user agent to retrieve

It is not the cacheability of the results of post request that I was
referring to, but
the cacheability of the results of a 303.  See 10.3.4 of RFC 2616:

The 303 response MUST NOT be cached, but the response to the second
(redirected) request might be cacheable.

regards,

Ted Hardie

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 2 May 2012 18:39:04 +0100

On 2 May 2012, at 17:28, Ted Hardie wrote:

> the cacheability of the results of a 303.

Ah, I see. Yes I see your issue with the text now. 

I believe there is an implicit assumption on the part of the authors that in this model (receive a POST and return a 303) that the ALTO server could be doing some level of "ALTO-application level caching" to avoid repeating expensive queries by determining that a given POST would execute the same query as a previous POST and therefore rather than run the query again, just return a 303 to a resource on the ALTO server that contains the results of the previous (identical) query.

But as I'm not an author I'll crawl back under my rock now.

Ben

>  See 10.3.4 of RFC 2616:

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 2 May 2012 20:24:39 +0100

Rich, Ted,

On 2 May 2012, at 18:49, Richard Alimi wrote:

> On Wed, May 2, 2012 at 10:39 AM, Ben Niven-Jenkins
> The word 'caching' was meant to apply to the response the ALTO Client
> that actually contained the data it was looking for (that is, the
> following GET).  An ALTO Server could also internally cache the
> results to avoid repeated computation, but that was meant to be
> implicit since this text was referring to the protocol messaging.
> 
> I understand Ted's point about the ambiguity in the text 'employ
> caching for the response to a POST request'.  We can clean that up to
> indicate that the caching is for the ALTO-level response (as returned
> by the following GET) and not the response to the POST itself.
> 
> No - come back! :)

As you asked so nicely, I wonder if the following (slightly wordy) change would address Ted's comment:

OLD:
   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).
NEW:
Note that it is possible for an ALTO Server to leverage caching HTTP intermediaries for responses to both GET and POST requests by including explicit freshness information (see Section 2.3.1 of [HTTPBIS Part6]).

Caching of POST requests is not widely implemented by HTTP intermediaries, however an alternative approach is for an ALTO Server, in response to POST requests, to return 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. HTTP intermediaries that do not support caching of POST requests could then cache the response to the GET request from the ALTO Client following the alternate URL in the 303 response (if the response to the subsequent GET request contains explicit freshness information).
END

> particularly important in this context) might also be useful.

I wonder whether a reference to Section 3.2 of HTTPBIS Part6 would suffice?

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 2 May 2012 20:29:42 +0100

cc'ing ALTO as Vijay suggested. Ben

On 2 May 2012, at 20:24, Ben Niven-Jenkins wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Richard Alimi <[email-masked]>
Date: Wed, 2 May 2012 22:22:43 -0700

>> Caching of POST requests is not widely implemented by HTTP intermediaries, however an alternative approach is for an ALTO Server, in response to POST requests, to return an HTTP 303 status code ("…

This seems reasonable to me, except would it be appropriate to have
this kind of document dependency?  Would it be more appropriate to
just reference RFC2616?

>> I wonder whether a reference to Section 3.2 of HTTPBIS Part6 would suffice?

Once upon a time, we used to have more detail about how to use HTTP
(caching in particular) in the ALTO Protocol draft itself. The
recommendation at that point was to strip out the large majority of it
and rely on the reference to the HTTP specs being sufficient.

That said, any pointers to help out implementers are fine with me as
long as we don't to back to where we were before :)  A concise hint or
direct reference pointing to the cache control directives seems
reasonable to me unless there are objections.

Thanks for the feedback,
Rich

> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 3 May 2012 07:59:28 +0100

Rich,

> this kind of document dependency?  Would it be more appropriate to

Up to you. HTTPBIS is in the process of putting the HTTPBIS specs through WG LC so there is light at the end of the tunnel for them popping out as RFCs. I referred to the HTTPBIS document because it's easier to find an appropriate reference but similar material is in 2616.

> and rely on the reference to the HTTP specs being sufficient.

I seem to remember being one of the people saying to strip it out and just provide a reference :-)

Ben

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 03 May 2012 08:38:37 -0500

On 05/03/2012 01:59 AM, Ben Niven-Jenkins wrote:
>> This seems reasonable to me, except would it be appropriate to
>> have this kind of document dependency?  Would it be more
>> appropriate to just reference RFC2616?
>
> Up to you. HTTPBIS is in the process of putting the HTTPBIS specs
> through WG LC so there is light at the end of the tunnel for them
> popping out as RFCs. I referred to the HTTPBIS document because it's
> easier to find an appropriate reference but similar material is in
> 2616.

If the reference to HTTPBIS is informative, then we are not gated
by HTTPBIS reaching the terminal state of RFC assignment.

So the question to Rich A. would be whether he thinks that the
reference we put in fits better as Informative or Normative.
If the former, then we can move ahead without any delays.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Richard Alimi <[email-masked]>
Date: Wed, 2 May 2012 10:49:40 -0700

No - come back! :)

Rich

---

From: David Harrington <[email-masked]>
Date: Thu, 03 May 2012 09:26:28 -0700

I would also recommend providing a reference rather than duplicating
specification, so there is no possibility of conflict between this and the
normative spec.
--
David Harrington
Internet Engineering Task Force (IETF)
[email-masked]
+1-603-828-1401

On 5/2/12 11:59 PM, "Ben Niven-Jenkins" <[email-masked]> wrote:

>>>> Note that it is possible for an ALTO Server to leverage caching HTTP
>>>>intermediaries for responses to both GET and POST requests by
>>>>including explicit freshness information (see Section 2.3.1 of
>>>>[HTTPBIS Part6]).
>>>> 
>>>> Caching of POST requests is not widely implemented by HTTP
>>>>intermediaries, however an alternative approach is for an ALTO Server,
>>>>in response to POST requests, to return 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. HTTP intermediaries
>>>>that do not support caching of POST requests could then cache the
>>>>response to the GET request from the ALTO Client following the
>>>>alternate URL in the 303 response (if the response to the subsequent
>>>>GET request contains explicit freshness information).
>>>> END
>> 
>Up to you. HTTPBIS is in the process of putting the HTTPBIS specs through
>WG LC so there is light at the end of the tunnel for them popping out as
>RFCs. I referred to the HTTPBIS document because it's easier to find an
>appropriate reference but similar material is in 2616.
>
>>>> Ted went on to say:
>>>>> Since cachability

---

From: Richard Alimi <[email-masked]>
Date: Fri, 4 May 2012 17:34:26 -0700

> If the former, then we can move ahead without any delays.

Based on my understanding, this seems like a normative reference.  If
someone thinks otherwise, please say so and I'll be happy to add a
reference to HTTPbis instead :)

Rich

---

From: Richard Alimi <[email-masked]>
Date: Sat, 12 May 2012 12:39:00 -0700

Thanks for the review!

On Thu, Apr 26, 2012 at 2:40 PM, Ted Hardie <[email-masked]> wrote:
> 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.

Ack - this can certainly be clarified.  Your understanding for ordinal
costs is correct.  Numerical costs can be any non-negative
floating-point number (representable in JSON, of course).

> 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.

Agree. Integrity protection and authentication are probably the
crucial ones, with encryption valuable in some deployment scenarios.
We can make these consistent.

Detail on what happens when an attacker controls the data would be
good.  I thought we had that text in one of the documents, but the
reference escapes me at the moment.  We'll at least add an explicit
pointer to where this is discussed in more detail.

>
> 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.

That sounds reasonable.  I'll hang on for others in the WG to respond
if there are other thoughts for which text should be moved and where.

At the very least, moving 6.1 earlier on in the document sounds reasonable.

On the flip side, another possibility would be to add a forward
pointer from the introduction to the core spec (for those who only
care about the spec pieces).

>
> 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

Sounds good to me.

>
> 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.

Sounds good.

> the results of the later GET request are cachable.  Since cachability

(discussed on a different thread where we seemed to reach a conclusion)

>
> 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.

That seems reasonable.  The intent was to help with debugging (and not
display to a user), so I'd either be okay with removing it or keeping
it and not worrying about the language.  Is there standard guidance to
apply here?

> 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.

It looks like the reference to 3.1.3 was wrong.  It should have been a
direct pointer to 10.3.  Thanks for catching that.  We can make it
clear when pointing forward to 10.3 that these are identifiers from a
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?

Yes - I see the disconnect.  I'd like to avoid solving the larger
deployment considerations under NATs (the deployment consideratoins
document should be handling that) in this document and instead focus
on the messaging details. Perhaps it would be best to change the
statement w.r.t. STUN to instead say MAY.  This document can certainly
give a concise statement of the problems you identified there.

How does that sound?

> 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.

Agree - we'll add text there to convey that.

>
>
> 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"?)

Ack.  We'll clean these up.

>
> 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"?

Agree. "Network Region" sounds good.

>
> 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"?

Agree.  Fewer double-negatives would be better :)

>
> 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.

Agree. I like "Service Framework"

> I believe Section 4 might read more naturally if the second paragraph
> were moved up to be first.

Agree.

> 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.

Ack.

> The Content-Length in some examples (e.g. in 7.6.3) are listed
> as [TODO]; this should be fixed.

Yeah - these haven't changed in a few revisions, so it would be
reasonable to resolve those TODO's now :)

> 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.

Ack.

Thanks again!
Rich

---

From: Ted Hardie <[email-masked]>
Date: Mon, 14 May 2012 07:09:12 -0700

On Sat, May 12, 2012 at 12:39 PM, Richard Alimi <[email-masked]> wrote:
<snipped>
> it and not worrying about the language.  Is there standard guidance to

I don't think there is standard guidance.  My personal advice, free
today and worth what you pay for it, is that localization of error
codes works better if the client simply has a local table of what maps
to the code.  If you have to do language negotiation just to get the
error string right, you're introducing a lot of complexity for
marginal gain.  If it's a debug string, rather than a user-facing
error, then marking it such and noting it will contain arcana rather
than actual error explanations is probably okay.  I don't think many
people expect a localized stack trace.

<much snipped>
> on the messaging details.

I haven't read the deployment considerations doc, but if this is
handled there, then a pointer to that would be fine.

> Perhaps it would be best to change the

I don't think it is really a question of MAY vs. SHOULD.  The document
seems to be assigning responsibility to working out the NAT boundary
problem to the client.  That means the client needs some way of
determining whether it is going through an address translator to reach
 the target.  I think keeping it at SHOULD use STUN for cases where a
translation will take place is correct; the problem is it is SHOULD
NOT for cases where the source and destination are within a NAT
boundary.  If you can, I would personally say something brief like
that, and give a pointer to the deployment considerations document for
more on how you determine when you have each case.  The optimization
(omitting the Source Endpoint), just highlights the problem.

regards,

Ted Hardie

---

From: Richard Alimi <[email-masked]>
Date: Tue, 15 May 2012 00:37:10 -0700

> people expect a localized stack trace.

Okay - I'll see if anyone else in the WG would like to comment, but
for now we can plan to remove it.

> handled there, then a pointer to that would be fine.

Okay, so my memory served me incorrectly here.  I thought it was
handled there, but it wasn't...

> (omitting the Source Endpoint), just highlights the problem.

Okay, so I think we'll need a bit more discussion on this as to how to
handle it.  I tend to think the deployment considerations document
would be a better place to handle this, but this section of it doesn't
exist yet today (contrary to my memory).

A solution without multiple levels of NATs here would be for the ALTO
Client to do the following algorithm:

  let D = set of destination addresses to which the cost should be queried
  for each address 'a' through which the ALTO Client is reachable
(discovered via STUN, local interface address)
    Pick D_a = { subset of D that can reach the ALTO Client via address 'a')
    query the Endpoint Cost Service with the source address and
destination addresses D_a

Things get hairier with multiple NATs, obviously.  The trickier part
of this would be how a client determines 'a'.  Multiple P2P
applications that I know about already implement logic for detecting
if it can use local address to talk to another peer.  We could
explicitly reference one of those as an example, but AFAIK those
algorithms mostly work only if there's a peer speaking the same P2P
protocol at the other end.

So, how about this which doesn't introduce a dependency on text which
does not yet exist in the deployment considerations document:
(1) as you suggested, indicate that the client SHOULD use STUN to
discover its own IP addresses when query for destination addresses
that are not behind the same NAT boundary, and SHOULD NOT use STUN for
destination addresses that are behind the same NAT boundary.
(2) Add this algorithm sketch as an example for using the Endpoint
Cost Service in a NAT environment, with the statement that determining
D_a may be application-dependent.

Then, if we want to add detail for specific techniques, we could add
those later in the deployment considerations document.

How does that sound?
Rich