Subject: [Gen-art] Gen-ART review of draft-ietf-alto-protocol-25

From: Martin Thomson <[email-masked]>
Date: Sun, 26 Jan 2014 13:12:06 -0800

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-alto-protocol-25
Reviewer: Martin Thomson
Review Date: 2014-01-25
IETF LC End Date: 2014-02-04
IESG Telechat date: ?

Summary:  This is a pretty damned good document and an impressive
achievement.  Don't let the number of issues I raise lead you to
conclude that it isn't.  It's huge and complex and does a decent job
of containing that complexity, even though at times it requires a deal
of back-and-forth to comprehend properly.  I don't think it should be
published until at least the major issues I raise have been addressed,
but those issues don't represent fundamental flaws.

Major Issues:

You can't use US ASCII encoding as you do; simply stating that the
value is a string would be better.  JSON is required to be
UTF-{8|16|32}, so mandating an alternative encoding could be a real
problem.  Same for most of the string-based types.  In most cases you
can simply s/US ASCII string/string/ safely.  This extends to the way
that specific characters are identified; this should use the U+
notation, rather than the 0x notation used.

Section 10.2 defines a resource ID.  Why do this when you could use
URIs?  After all, that's what URIs are for.  I realize that this would
be something of a major change to the protocol, but I think that the
question is particularly important.

Use of URIs has particularly benefits too.  For example, the "uses"
attribute of the IRD would be made far more easily navigable if URIs
were used.

It's unclear to me what value VersionTag (Section 10.3) has over URI +
ETag.  Section 10.3 doesn't really explain this at all, and the bulk
of the explanation is ad hoc at best.  I'll note that the way of
describing a dependency is quite roundabout and potentially
problematic.  Each resource that has a dependency has a name+tag for
each dependency.

The name is a name from an IRD, but this creates a uniqueness problem
if multiple IRDs reference the same IR.  This seems likely for cases
where adjunct services like the endpoint cost service rely on a common
network map.

On the other hand, if this were changed to URI + ETag, consistent with
my earlier recommendation, there would be no need for the extra
indirection and HTTP headers could carry version information for each
resource.  All that would be required is to identify dependencies
correctly.  Even better, a link relation.

I note also that vtag is used in filtered documents.  I think that
this is problematic because two differently filtered maps will have
the same ID, and - according to 11.3.1.6 - the same vtag.  That makes
it impossible to identify a filtered map.  Better to instead identify
each with their own URI (use Content-Location) and to separately
identify the complete map from the filtered one so that it can be made
clear that identifiers in each of the filtered maps is from the same
namespace.

Minor Issues:

I think that the document needs to be clearer with respect to how the
source and destination in a cost map are identified.  For example,
Section 6.1.2 specially calls out IP addresses as the basis for costs.
 However, the introduction to Section 6 states (though I may be
inferring this) that PID is the only basis.

Section 8.2 leaves quite a few questions unanswered.  For instance, is
'object' and 'object-map' the only reserved words?  How is Type2
actually defined as a string?  How might I define Type4 as an array?
I'm not expecting formal grammar or a rigorous definition, but the
definition is a wee bit sparse.

The MUST in Section 8.3.3 isn't really necessary.  Particularly when
it is so immediately contradicted.

Section 8.3.4.3 isn't exhaustive, obviously, but it does highlight
just two of the major fallback techniques:
 * ask another server
 * manage without the information (since it's basically advisory in
most use cases anyway)
The third option is to find an alternative way to obtain the desired
information, since the protocol provides redundancy at more than the
resource level.  For example, a complete cost map could be requested
if the endpoint cost service fails.  This would be suboptimal, but
probably better than managing without.

Section 8.3.7 seems odd.  At the server, it would be easier to require
that cookies not be set.  A client is likely going to use a general
purpose client for making requests, so cookies set by the server are
probably going to be returned as per spec.  In either case, forcing
cookies to be ignored is potentially restrictive on the server choices
(authentication springs to mind here) or requiring of special work on
the client.  Either requires greater justification than this document
provides.

In Section 8.4.1, why not define ResponseMeta as an object with an
optional "code" attribute and all of the other optional "meta"
occupants you define?  Otherwise, this object is a non-definition of
sorts.

Section 10.6 and 10.8.2 define a prefixing rule for cost metric type
and endpoint properties.  This is contradictory to the received wisdom
of RFC 6648 and I encourage you not to define these special rules.
(Note: "priv:" =~ "x-", "exp:" == "x=")

With that, I think that it would be appropriate to lower the
registration requirements to "Expert Review".  "IETF Review" is a high
bar to set.

I am not convinced that a namespace system based on a period ('.') is
necessary when the CostType object can be expanded with additional
attributes.  Removing the significance of ':' and '.' (and either
allowing as regular characters or forbidding entirely) would be both
sufficient and considerably simpler.

I found it quite difficult to work out what an endpoint property was.
The explanation is a little lacking here.  I also think that the
structure could be greatly improved.

Furthermore, I find the construction of identifiers to be brittle.
The following would simpler in my opinion:

Request:
  {
    "properties" : [ "pid",
                     "my-example-prop" ],
    "endpoints"  : [ "ipv4:192.0.2.34",
                     "ipv4:203.0.113.129" ],
    "network-maps": [ "http://example.com/my-default-network-map" ]
  }

Response:
    {
    "meta" : {
      "depends" : { "http://example.com/my-default-network-map": "xyzzy" }
    },
    "endpoint-properties": {
      "ipv4:192.0.2.34"    : { "pid": {
"http://example.com/my-default-network-map": "PID1" }
                               "my-example-prop": "1" },
      "ipv4:203.0.113.129" : { "pid": {
"http://example.com/my-default-network-map": "PID3" } }
    }
  }

I'm tempted to suggest that there be a little consistency with respect
to network locations as well.  Sometimes type and value are in
separate fields, other times not.  (I know that this was a point of
long discussion in the WG though, so I'm less concerned here.)

Section 15.4.1 should probably mention the tracking of clients using
cookies or fingerprinting techniques.  (Is this where the Cookie
prohibition in Section 8.3.7 came from?  Because if it is, then it
should be MUST NOT send for clients as opposed to MUST NOT use for
servers.)

For Section 15.5.2, a server could also limit the size of M and N that
it is happy to accept a request for.

Is Appendix C normative?  It looks like it, but it's insufficiently
specified, particularly with respect to the formatting of "field" to
be normative.

Nits:

There's a bunch of lowercase "may" and "should" throughout.  I know
that opinions differ on the use of these in combination with 2119
lanauge, but I'll note that some of the statements appear to be
normative.

Later in p3, the SHOULD here doesn't seem particularly testable, as
phrased, though a rewording might make it so.

Section 8.2 is a little cramped.  Don't be scared of using more whitespace.

In Section 8.2, why 'JSONString' and not simply 'string'?  After all,
you use object rather than JSONObject.

Section 8.3.4.2 s/should normally be/is/

In Section 8.4.2 check the spelling of Info[r]ResourceDirectory.

Section 9.1.4, consider quoting "accepts" in "The associated accepts
attribute of an Information Resource [...]"

Last character of Section 9.2.5.1, delete ".

In Section 10.1, the definition of PID seems like an exemplar
candidate for ABNF.

In Section 11.2.1, the idea of optimizing for compactness in a
text-based format is somewhat laughable.  Compactness is best achieved
in these cases through the use of compression.  Readability is
laudable, as is accessibility to software.

Section 15.3.2, p2 s/need/needs/

Section 15.5.1 p1, missing space(s), consider capitalizing "m" and "n".

---

From: "Y. Richard Yang" <[email-masked]>
Date: Sun, 26 Jan 2014 16:40:11 -0500

Dear Martin,

This is an Ack that the authors have received the wonderful comments. Thank
you so much!

The first major issue (regarding string) is a good suggestion. We will take
a pass to address it.

The second major issue (uri) is more involved. There was one initial
proposal of using URI, and then the URI may point to any arbitrary
location. In light of your comments, the authors will discuss and get back
to you soon. Do you want to get involved in the discussions, or prefer that
the authors first discuss internally to get certain conclusion and then
involve you? Please advise. We will respond to the other issues within a
few days as well.

Thanks again!

Richard

---

From: Wendy Roome <[email-masked]>
Date: Mon, 27 Jan 2014 11:16:32 -0500

Here¹s my response for ³why resource ids instead of uris²:

An ³ALTO Server² is a collection of services provided by a provider. That
provider may distribute these services over several different physical
servers, and that distribution may change over time. If we used URIs to
identify those services, the IDs would have to change whenever the provider
redistributed services.

Therefore we defined ³Resource IDs² as persistent, location-independent, IDs
for those services. Resource IDs must be unique, but only within the context
of one provider¹s services ‹ that is, the services defined by the tree of
IRDs reachable from a root IRD. That IRD tree maps those Resource IDs to
URIs, and allows the provider to change the mapping without disrupting
clients. Thus ALTO Resource IDs are relative to the URI of the provider¹s
IRD tree. If a provider had to use globally unique, location-dependent URIs,
instead of location-independent relative IDs, the provider would have an
unnecessary administrative burden.

(Yes, I know ³URIs², unlike URLs, are supposed to be ³location independent.²
But let¹s face reality: that only works if there¹s some higher level mapping
of URIs to locations. For all practical purposes, ³URI² means host-specific
³URL².)

Another way to look at it is that ³Resource IDs² are like using relative
addresses within a web page. They make it easier to move a tree of related
pages from one host to another.

- Wendy Roome

From:  "Y. Richard Yang" <[email-masked]>
Date:  Sun, January 26, 2014 at 16:40
To:  Martin Thomson <[email-masked]>
Cc:  "N:" <[email-masked]>, "[email-masked]"
<[email-masked]>, Richard Alimi <[email-masked]>, "Reinaldo Penno,
(repenno)" <[email-masked]>, Wendy Roome <[email-masked]>,
Sebastian Kiesel <[email-masked]>
Subject:  Re: Gen-ART review of draft-ietf-alto-protocol-25