Hi Martin,
Thank you very much for your comments on the draft. See below:
> First of all, I'm a bit disappointed that the draft name says
> 'protocol', but there is still no complete protocol defined in that
> draft, that I could start to implement. The whole
> syntax is missing, even in the latest revision. This does not make
> life easier in judging whether the claimed ALTO protocol is
> progressing in the right direction.
Based on feedback from the meeting in Stockholm, there were a few major
points that we tried to address in this draft:
1) It was unclear how a number of proposals could be "merged" into a
single protocol and still have something efficient;
2) It was unclear where the ranking service functionality went;
3) Remove XML as an encoding and replace with something else.
4) Splitting the protocol into core and optional services for rapid
deployment.
You are entirely correct that we removed specific protocol encodings
from this draft. It was intentional, as is stated in Section 7:
Note that the primary focus of the current draft is the architecture
and protocol operations, and only the structure of messages is
specified (without actual message encoding).
Our feeling is that the major changes to be made are still
architectural. Instead of spending effort in detailing all of the bytes
on the wire, and possibly having to duplicate or migrate the details at
a later time, we decided to first focus on getting consensus with the
architecture and set of operations in the protocol.
We removed the XML details to avoid repeated feedback saying "please
remove XML!" and instead focus on the higher-level issues.
> Reading the draft and understanding the different building blocks is
> very, very difficult, if not impossible for implementers not attending
> the ALTO WG. The draft starts with a lot of marketing talk in the
> beginning (sections 1 & 2) and afterwards tries to introduce the
> different elements.
Can you be more specific about what you feel is "marketing talk"? The
descriptive text in there is meant to show why an ALTO Service can be
useful to service providers and applications, and to show how it
relates architecturally to other network elements and protocols.
> I'm stuck after section 4 (which
> introduces the Network Maps), as I would expect a clean and neat
> introduction to the Cost Maps. I do like the concept of these two
> maps, but I'm lost after reading the Section 4
> and 5. Section 4 starts well with the Network Maps and I would expect
> the intro of the Cost maps, but instead the combination path rating
> and cost maps is introduced in Section 5.
I do agree that it may be possible to reorganize Section 5 a bit to make
the introduction of the two maps cleaner. We'll note that for the next
revision.
> Some technical questions:
> - why do we need ordinal and numerical ranking. A numerical ranking
> would be just enough and also eliminate one degree of freedom (i.e.,
> making the job of the implementers easier :)
Section '5.1.2. Cost Mode' talks about the different properties of
the two cost modes, and also says that an ALTO Server must implement at
least one of the cost modes but not necessarily both. So, you do not
actually need to implement ordinal if you choose.
> - how are ordinal/numerical lists sorted, i.e., is it descending or
> ascending. This is not defined, only implicit by guessing.
The oridinal cost indicates the 'ranking' (Sec 5.1.2), which is the
position in the list. Consider the example in the document (Sec
7.3.5.1.3):
{
"ipv4:128.30.24.89" : 1,
"ipv4:130.132.33.4" : 2,
"ipv4:12.32.67.3" : 3
}
The corresponding ordered list would be:
128.30.24.89, 130.132.33.4, 12.32.67.3.
> - why POST for all operations if data is sent to the server, even
> though in some occasions (e.g., 7.3.3.1.1), if GET with parameters in
> URI just works?
Allowing alternatives for some queries to use GET is a possibility.
To keep the operations simpler and more uniform at this point in the
design process, we used POST for all operations that send map data to
the ALTO Server (e.g., PIDs).
> - why hard coded URI paths? do we need this, i.e., wouldn't it be fine
> to learn those paths while querying the server capabilities (Section
> 7.3.1.1)
If you look at
http://tools.ietf.org/html/draft-penno-alto-protocol-01#section-5.1 this
capability was present, but we received comments that such flexibility
may make interoperability harder. Additionally, Lisa commented during
the session at IETF75 that there are clearly people on both sides of the
fence here.
> - where is the real protocol spec, i.e., the actual encoding of the
> entity bodies? That is probably the interesting part with a lot of
> work ahead.
As was mentioned above, the focus in this document was not the
encodings themselves. Given that there was still very fruitful
feedback about the overall organization and operations in the protocol,
there were still higher-level changes to be made and agreed upon by the
working group.
You're right that specifying the encodings is an important task that
will require a lot of work. However, we did not feel it wise to do it
at this point where higher-level changes are still being made, which
would likely cause changes to encoding details, error conditions, etc,
meaning the detailed work may need to be redone multiple times.
> - where is the status code for the ALTO information query? There is
> only the http status code discussed. This status code does not say
> anything about the result of the queries, but
> about the http transport.
If you look at
http://tools.ietf.org/html/draft-penno-alto-protocol-01#section-4.3.1
this capability was there but again, it was deemed not necessary once we
moved to a REST-like design.
If there are places where it turns out that the HTTP status code is
not enough to convey what is needed or it departs from error conditions
provided by HTTP, then adding an ALTO status code is a possibility.
> - section 7.1.1: why does ALTO need to obey TCP transport
> considerations? Is it not enough to use standard TCP? Does this hint
> to some required tuning of the TCP transport? ;)
By TCP Transport considerations, the idea was to convey that the
transport layer provides a congestion-enabled, reliable, stream based
service. Using standard TCP works, and we can revise the text to make
that clearer.
> - what is the measure of the ALTO server, if it is overloaded?
My feeling is that this is up to the provider of the ALTO Server to
decide, as this can depend on the specifics of their deployment such as
server resources, network resources and costs, etc.
> - http caching: what cache directives shall be used for what
> information? You claim caching to be a strong point for the protocol,
> there is not much information about what to cache
> and how (see RFC 2616, Section 13. ...)
More information should be specified here in the document.
Cache-control: max-age or the Expires headers are the basic ones
that should be used, and they should only be used for queries that
do not depend information other than those in the HTTP Request URI
(e.g., the request body or per-client information such as whether
the client is authenticated to the ALTO Server). Details will be
included in the next revision.
Thanks,
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
