Subject: [alto] category of resource/consumer (was: Comments on draft-ietf-alto-reqs-08)

From: Martin Stiemerling <[email-masked]>
Date: Wed, 11 May 2011 08:44:12 +0000

[please read this email to the very end, as it requires the attention of the whole WG!]

Hi Ben, all, 

This is in response to your point 27. I will use a separate thread, as this deserves more attention by the WG. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ben Niven-Jenkins
> Sent: Friday, April 29, 2011 1:53 PM
> To: [email-masked]
> Subject: [alto] Comments on draft-ietf-alto-reqs-08
> 

[...]
 
> 27)
>    REQ.  ARv08-55: The ALTO client protocol SHOULD be defined in a way,
>    that the operator of one ALTO server cannot easily deduce the
>    resource identifier (e.g., file name in P2P file sharing) which the
>    resource consumer seeking ALTO guidance wants to access.
> 
> Is the intent
> A) A P2P (or other) client does not want to expose themselves or their
> clients to revealing the actual resources they intend to
> access/distribute; or
> B) A P2P (or other) client may be willing to reveal the resource they
> intend to access to their local ALTO server but does not want that
> information being redistributed?

It is A, as an early outcome of WG discussions and finally a WG decision. It is was feared that ALTO could be used to collect information about p2p clients and to further use this information in other contexts. 

> 
> Given that ALTO is independent of resource identifier and is about
> relationships between end points not between resources it seems to be
> an irrelevant requirement. Or if the intent is (A) it is probably

Well, one outcome of this requirements is that ALTO is independent of the resource identifier. So this makes this requirement still relevant. 

> better stated along those lines, e.g. that the ALTO protocol SHOULD NOT
> require the specific resource to be accessed to be included in ALTO
> requests.

Let's wait with the wording until we have finished the point below :)

> 
> I can see that an ALTO server may want to return different responses
> depending on the category of resource (or possibly more precisely the
> category of consumer) and we don't want to preclude that, e.g.
> returning a different response to a P2P client than it would to a CDN.

The assumption until now was really focused on the p2p use case and not on the CDN use case. However, I can see that in the CDN use case, an ALTO server may return a different response for CDN. For P2P on the other hand, we definitely do not want to identify the resource category. 

Adding the possibility to identify the category of resource to the ALTO requirements would require a WG consensus IMHO. 

The requirements would read along these lines:
(a) that the ALTO protocol MUST NOT require the specific resource to be accessed to be included in ALTO requests.
(b) that the ALTO protocol SHOULD allow to specify the resource to be accessed to be included in ALTO requests. 

(a) rules out the requirement to have it in all requests, while (b) allows the protocol to have such a capability.

  Martin

[email-masked]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 11 May 2011 11:58:07 +0200

Ben,

Thanks for the extensive review. Martin and I have posted a new version
of the draft (-09) yesterday, which addresses many of your comments.

So far we only made changes that make the doc clearer to read but did
not change the intention of any requirement. Therefore we did not
resolve all issues.  Please see inline below as well as separate email
threads for more details on specific issues.

On Fri, Apr 29, 2011 at 12:52:49PM +0100, Ben Niven-Jenkins wrote:
> Colleagues,
> 
> Today I read draft-ietf-alto-reqs-08 in detail and my reading of the draft generated a number of comments which I have detailed below.
> 
> I appreciate that WG Last Call for draft-ietf-alto-reqs ended on the 25th February and that therefore my comments are somewhat late, for that I apologise and can only offer the excuse that I was not actually active in ALTO work during the Last Call period.
> 
> I hope my comments can still be taken into account as I believe that addressing them will result in am improved document.
> 
> My comments:
> 
> 1)
> I'm not sure it's reasonable to reference the ALTO Charter without giving a link as the charter will change over time and the reference is likely intended to be a reference to a historical version of the charter.
> 
> The current [ALTO-charter] reference refers to the Feb 2009 charter for which a suitable link may be:
> http://tools.ietf.org/wg/alto/charters?item=charter-alto-2009-02-11.txt

ok, fixed.

> 
> 2)
> The requirement numbering appears to embed the draft's version number within the requirement number. Is the intent to remove that when published as an RFC and have numbers like AR-1? 

yes, this is the intent. 

as numbering of the reqs changes whenever we add or delete a req, we
decided to have a unique numbering for every version of the draft.

> 3)
> Throughout the document I find the use of "client protocol" confusing. Surely it is just the "ALTO protocol". draft-ietf-alto-protocol-07 does not use the term "client protocol" at all.

RFC 5693 defines the term "ALTO client protocol" and
draft-ietf-alto-protocol-07 is one possible protocol specification.
See also next comment...

> 
> 4)
> ARv08-1 would appear to be redundant as it essentially states "An ALTO server MUST implement the ALTO Protocol" which is simply obvious and I wouldn't think need to be explicitly stated, although stating it is harmless.
> 
> 5)
> The same comment as for ARv08-1 applies to ARv08-2 except s/server/client/
> 
> 6)
>    ARv08-3: The format of the ALTO query message MUST allow the
>    ALTO client to solicit guidance for selecting appropriate resource
>    providers.
> 
> I'm struggling to parse what this requirement actually means. I think what is trying to be conveyed is that the ALTO protocol MUST support a service to enable an ALTO client to present a list of candidates resource providers and have the ALTO server provide guidance on the ranking of those candidates? I don't see what that really has to do with the format of query message.
> 
> 7)
> Similarly for ARv08-4 if there is a requirement for the ALTO protocol to support a service where to ALTO server offers guidance to clients is it really necessary to explicitly state that the format of the ALTO response message MUST support encoding that guidance. The phrase teaching granny to suck eggs comes to mind.
> 
> 8)
>    REQ.  ARv08-5: The detailed specification of a protocol is out of the
>    scope of this document.  However, any protocol specification that
>    claims to implement the ALTO client protocol MUST be compliant to the
>    requirements itemized in this document.
> 
> I'm not sure what is meant by "MUST be compliant" in this context - the ALTO protocol it MUST include protocol elements for all MUST requirements, for all MUST & SHOULD requirements, something else? Anyway this requirement seems aimed at setting some ground rules for comparing different proposed protocol solutions against one another and as far as I can see there is only one candidate protocol being developed and therefore the requirement would seem somewhat redundant. 

Although draft-ietf-alto-protocol-07 is the only active WG item that
specifies an ALTO client protocol, the ALTO reqs draft assumes that
there can be several different protocols, as have been in the past.
I also heard about rumors that there might be alternate protocols
appearing soon...

See also the abstract:

   This document enumerates requirements for ALTO, which should be
   considered when specifying, assessing, or comparing protocols and
   implementations.

ARv09-1 to -5 aim at setting ground for this multiplicity, by defining
the very basics of ALTO:  It is a client-server-protocol, with the
client asking for guidance wrt. peer selection and the server providing
that guidance. There may be many protocols, but if you want to call
your protocol ALTO you have to fulfill these requirements.

> 
> 9)
>    REQ.  ARv08-6: The ALTO client protocol MUST support the usage of
>    several different host group descriptor types.
> 
> "MUST support ? several" is very vague for a MUST level requirement. A pedant could say a protocol that only supports 3 different host group descriptors is sufficient and I don't think that's really the intent of the requirement.
> 
> I would suggest re-wording/re-structuring ARv08-6, ARv08-7, ARv08-8 & ARv08-9 to more clearly express the following intent (if you agree I can work with the authors to produce exact text):
> 
> - The ALTO protocol MUST support Host group descriptors of type IPv4 prefix & IPv6 prefix
> - The ALTO protocol MUST be extensible to enable support of other host group descriptor types in future, for example by explicitly typing host group descriptor records and maintaining an IANA registry of defined types.
> - The ALTO protocol MUST define a minimum set of host group descriptor types that MUST be supported by all implementations in order to aid inter-operability.

ok, fixed.

> 10)
> ARv08-11 & ARv08-12. While the intent of these requirements may be laudable I really struggle to envision how they could actually be implemented or whether they are actually achievable in all circumstances.

In the early days of this WG there were proposals that the ALTO server
could give guidance to P2P apps like 
"prefer peers in AS (autonomous system) No. ???" or 
"avoid peers in <country of the world>".

This is problematic as p2p software nowadays usually doesn't know about
AS numbers etc, it only knows about the IP addresses of candidate
resource providers it has to select.

The intent of these requirements is to discourage using hosts group
discriptors other than IP addresses. However, we do not want to prohibit
it, given that there is a reasonable mapping mechanism provided. The
PID mechanism specified in draft-ietf-alto-protocol-07 is IMO OK.

> 11)
> ARv08-14 appears to be a duplicate of ARv08-13

No, the roles of client and server are interchanged. These two
requirements used to be one, but there were comments that some
clause about informing "the other party" is difficult to understand.

> 
> 12)
> ARv08-15 is similar to ARv08-6 in that it states the protocol "MUST support ? several" and the following requirements 16, 17 & 18 are similar than requirements 7, 8 & 9.
> 
> I'd suggest removing ARv08-15 and then either inserting a requirement between 17 & 18 (or including some text in 18) to state that the protocol MUST be extensible to enable the support of new rating criteria.
> 
> Also you may want to consider explicitly stating what the "basic set of criteria types, which MUST be supported are". "Relative operator's preference" is obviously one as it's an explicit requirement for the protocol to support it but are there others?

OK, fixed.

> 13)
>    REQ.  ARv08-20: Applications using ALTO guidance MUST NOT rely on the
>    ALTO guidance to avoid network congestion.  Instead, applications
>    MUST use other appropriate means, such as TCP based transport, to
>    avoid causing excessive congestion.
> 
> I struggle to see the relevance of the second sentence to the requirement. The first sentence essentially says "in the presence of congestion you MUST NOT rely on ALTO to avoid that congestion" which seems reasonable, however the second sentence says "applications should avoid causing excessive congestion" which doesn't appear to relate to the requirement to not use ALTO to avoid congestion that has already been caused (quite possibly by a different application/client/user). I'd suggest removing the second sentence.

The intent of this req is:

Nobody should ever try to use ALTO for providing a map with current
link/path capacities (or even worse: provisioned link/path capacities) and
then allow the clients to send data at the indicated rates without
any additional congestion avoidance strategies. In other words: ALTO is
not intended as admission control system.

I guess we should better change the first sentence to "... MUST NOT rely
on the ALTO guidance to avoid ***causing*** network congestion ..."

does this make sense?

> 14)
> ARv08-21 & 22 are similar to ARv08-3 & 4. I don't think the query message/response is relevant. I think you want the protocol to allow an ALTO client to request guidance based on the client's preferred rating criteria.

ARv08-3 & 4  aim at defining the very basic mode of operation for ALTO.

ARv08-21 & 22 are about dealing with multiple rating criteria within one
query.

> Also ARv08-21 mentions the client being able to express a relative relevance between different rating criteria but it is unclear to me how an ALTO server could satisfy such a requirement given that it may not be possible to directly compare (and therefore order) different rating criteria. If this part of the requirement is to remain I think you need to be more explicit about what you mean by "relative relevance"

In the sorting oracle query style, it is useful to have a second sorting
criterion if two candidate resource providers are equal or very similar
according to the primary criterion.

> 15)
> ARv08-24 & 25. I don't think the placement of the ALTO client relative to the ultimate consumer of the information really affects the mode of operation of the protocol.
> 
> I think what you want to express is:
> - An ALTO server MUST NOT assume that the ALTO client making requests will be the ultimate consumer of the information contained in any response.
> - The ALTO protocol MUST support embedding any required consumer related information in the protocol itself.

technically we agree but we think that the old wording is better in the
sense of having a checklist for assessing protocol specs or
implementations

> 16)
> ARv08-26. Do you really mean to restrict this requirement to only separation from "the operator of the IP access network" or do you actually mean to say "The ALTO protocol MUST be designed in a way that the ALTO service can be provided by an entity which is not the operator of the underlying [IP?] network"?

ok. fixed.

> 
> 17)
>    REQ.  ARv08-28: The ALTO client protocol MUST support at least one of
>    these two modes, either the target-aware or the target-independent
>    query mode.
> 
>    REQ.  ARv08-29: The ALTO client protocol SHOULD support both the
>    target-aware and the target-independent query mode.
> 
> Do you really mean this? I can see that an implementation may only want to support one or other mode, but if both modes are valid then surely the protocol itself should provide support for both and I believe the ALTO protocol spec does in fact support both modes.

in the sense of my reply to your comment no. 8) we should change this
to "An ALTO client protocol..."

> 18)
>    REQ.  ARv08-30: The ALTO client protocol SHOULD support lifetime
>    attributes, to enable caching of recommendations at ALTO clients.
> 
> What is a "lifetime attribute"? It implies to me an attribute that is permanent whereas I suspect you really mean "a TTL or similar mechanism, to enable caching"?

yes. fixed.

> 19)
>    REQ.  ARv08-31: The ALTO client protocol SHOULD specify an aging
>    mechanism, which allows to give newer recommendations precedence over
>    older ones.
> 
> I don't really understand the motivation for this requirement. Surely more recent responses always take precedence over earlier responses? I'm struggling to see a situation where a client would receive a "younger" recommendation before an "older" one and need the capability to say "although I received recommendation X after recommendation Y I can see that Y is younger so I will discard X".

the original idea was to have some kind of soft fade-out of
recommendations instead of switching from 100% to 0% consideration
at the end of the TTL.

We're discussing with the proponents of this idea whether this still
makes sense.

> 20)
> ARv08-33 is pretty vague. I'm not sure a requirement that essentially states that the protocol MUST support scenarios where the client is behind NAT by itself is implementable. Are there specific use cases that could be articulated that the protocol needs to accommodate for?

Again, this is due to the idea that there might be several protocols.
For the current draft-ietf-alto-protocol-07 using HTTP transport the
req is fulfilled. But please do not design an alternate prococol using
FTP-style backconnects, etc.

> 21)
>    REQ.  ARv08-40: An ALTO server, which is operating close to its
>    capacity limit, MUST be able to inform clients about its impending
>    overload situation, and reject new conversation attempts.
> 
> I'm not sure how this would be implemented. If the server is able to inform the client about its impending overload, has it not by definition already entered into a conversation with the client and therefore the situation is already covered by ARv08-39?

ok. removed.

> 
> 22)
> In the first sentence of section 3.2 I think "one or more" is better language to use rather than "one or several". I would also s/is supported/may be supported/
> 

ok.

> Additionally the introduction text in section 3.2 seems to end rather abruptly and not be entirely related to the rest of the section.
> 
> Was there an intent to have some additional text, for example "The following requirements apply to any ALTO server discovery mechanism"?

The problem here is that this section basically enumerates use cases
that have to be supported by the set of (one or more) discovery
protocols as a whole, not by an individual mechanism.

> 23)
> ARv08-41, 42, 43 & 44. Is there really any value in separating out requirements between "resource consumer initiated ALTO server discovery" and "third-party ALTO server discovery" given that the requirements are actually identical?
> 
> I think the actual requirements are:
> - An ALTO server discovery mechanism MUST support ALTO server discovery by ALTO clients irrespective of whether the ALTO client will be the ultimate consumer of the ALTO information or whether the ALTO client will be making queries on behalf on another entity which is the ultimate consumer.
> - ALTO clients MUST be able to perform ALTO server discovery irrespective of whether they or the ultimate consumer of the ALTO information are located behind NAT.

technically we agree but we think that the old wording is better in the
sense of having a checklist for assessing protocol specs or
implementations

> 24)
> ARv08-49, 50 & 51. The intent is not that authentication and encryption mechanisms MUST be built-in to the protocol itself but that the requirement can be adequately met by a substrate over which the ALTO protocol operates (e.g. mechanisms already provided by HTTP/HTTPS)?

right. made it more explicit.

> 25)
>    REQ.  ARv08-52: The ALTO client protocol MUST support different
>    levels of detail in queries and responses, in order for the operator
>    of an ALTO service to be able to control how much information (e.g.,
>    about the network topology) is disclosed.
> 
> Is this really a requirement on the ALTO protocol or is it a requirement on the ALTO server?

it is a req on the protocol, e.g., it should be allowed to give an IP
prefix instead of a single IP address for describing a host, in order
to obfuscate the host's identity.

> The same comment also applies to ARv08-54.
> 
> 26)
> ARv08-53. This requirement seems related to ARv08-32 on reuse of responses and may be better place after that requirement to make the association between the two clearer.

The intent of this req ist to say "we do not want to use DRM (digital
rights management) to prevent ALTO clients from redistributing the
guidance they received". That's why this req is in the security&privacy
section.

> A) A P2P (or other) client does not want to expose themselves or their clients to revealing the actual resources they intend to access/distribute; or
> B) A P2P (or other) client may be willing to reveal the resource they intend to access to their local ALTO server but does not want that information being redistributed?
> 
> Given that ALTO is independent of resource identifier and is about relationships between end points not between resources it seems to be an irrelevant requirement. Or if the intent is (A) it is probably better stated along those lines, e.g. that the ALTO protocol SHOULD NOT require the specific resource to be accessed to be included in ALTO requests.
> 
> I can see that an ALTO server may want to return different responses depending on the category of resource (or possibly more precisely the category of consumer) and we don't want to preclude that, e.g. returning a different response to a P2P client than it would to a CDN.

see Martin's separate mail on this topic.

> 28)
>    REQ.  ARv08-56: The ALTO client protocol MUST support appropriate
>    mechanisms to protect the ALTO service against DoS attacks.
> 
> Is this actually a requirement on the protocol itself, i.e. that it needs specific protocol machinery to protect against DoS attacks or is it a more general requirement on server implementation and deployment strategy?

the latter - again in the sense of a checklist for assessing
implementations.

> 29)
> Section 5.2.1 & 5.2.3 cover a number of potential security issues and cite examples of how they may be addressed. It might be useful to also refer to specific requirements stated earlier in the document that address those scenarios.
> 
> Even if not included directly within the document such an exercise (if it hasn't been done already) might help to ensure a possible requirement has not been inadvertently overlooked.

right. we are checking how to make crossrefs to the req. numbers.

Thanks
Sebastian

---

From: Richard Alimi <[email-masked]>
Date: Wed, 11 May 2011 08:44:49 -0700

Comment inline with most of the textual discussion omitted...

On Wed, May 11, 2011 at 1:44 AM, Martin Stiemerling
<[email-masked]> wrote:

...

> (a) rules out the requirement to have it in all requests, while (b) allows the protocol to have such a capability.

For the sake of completeness, I'll offer another one which was demoed
(by Juniper) in the running code show. They allowed an ALTO Server to
internally contain multiple "views" (read: set of maps), and it would
serve maps based on the requesting client. The client could be
determined by requesting IP address, supplied credentials, additional
HTTP headers, etc.  This avoids us defining any additional
identifiers, or classifying applications into any particular types in
the protocol specification.

An early implementation of the P4P work used multiple views which were
advertised by the server.  It was up to the client to determine
whether they wished the default one, or wished to select a different
one.

There are some reservations about including a resource identifier in
ALTO.  In particular, we need to find a way to name it that allows
this must work under different applications that exist today and in
the future. There are ways to do it, but I'm just mentioning that this
does open a can of worms (the DECADE WG is an example of this, and I'm
sure there are others).

Yes, you proposed this as a SHOULD so we probably aren't bound to put
this in the base protocol, but it would need to be worked out at some
point.

Rich

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

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 11 May 2011 18:27:42 +0100

Rich, Martin,

Please see inline.

> whether they wished the default one, or wished to select a different

Before we go to far down the line of resource identifiers I think Martin may have misinterpreted what I meant slightly.

I was never thinking about including resource identifiers in ALTO. I was thinking of the multiple views scenario described above, e.g. an ALTO server "knows" (somehow) the client is a P2P client and gives it the P2P map which may expose different costs between the same endpoints (or even different sets of end points) to the CDN map for example.

I see know need to include categories of individual resources, but returning different maps based on the category of client/consumer (e.g. P2P client or CDN client, etc.) should not be precluded. Having said that I don't think that the category of resource client needs including in the protocol either.

I do think the original wording of the requirement could be improved though.

Apologies for sending you off on a tangent.

Ben

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 13 May 2011 12:52:57 +0000

Hi Rich, 

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Richard Alimi
> Sent: Wednesday, May 11, 2011 5:45 PM
> To: Martin Stiemerling
> Cc: Ben Niven-Jenkins; [email-masked]
> Subject: Re: [alto] category of resource/consumer (was: Comments on
> draft-ietf-alto-reqs-08)
> 
> > The assumption until now was really focused on the p2p use case and
> not on the CDN use case. However, I can see that in the CDN use case,
> an ALTO server may return a different response for CDN. For P2P on the
> other hand, we definitely do not want to identify the resource
> category.
> >
> > Adding the possibility to identify the category of resource to the
> ALTO requirements would require a WG consensus IMHO.
> >
> > (a) that the ALTO protocol MUST NOT require the specific resource to
> be accessed to be included in ALTO requests.
> > (b) that the ALTO protocol SHOULD allow to specify the resource to be
> accessed to be included in ALTO requests.
> >
> > (a) rules out the requirement to have it in all requests, while (b)
> allows the protocol to have such a capability.
> 

I had this in mind, but this is not affecting the protocol as such, but the back end of the server. A server implementation can do this anyhow.

> this in the base protocol, but it would need to be worked out at some

I'm also not particular happy about adding this and I would like to avoid it.

  Maritn

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 28320

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 13 May 2011 12:55:50 +0000

Hi Ben, 

> Sent: Wednesday, May 11, 2011 7:28 PM
> To: Richard Alimi
> Cc: [email-masked]
> >> (b) that the ALTO protocol SHOULD allow to specify the resource to
> Before we go to far down the line of resource identifiers I think
> Martin may have misinterpreted what I meant slightly.
> 
> I was never thinking about including resource identifiers in ALTO. I
> was thinking of the multiple views scenario described above, e.g. an
> ALTO server "knows" (somehow) the client is a P2P client and gives it
> the P2P map which may expose different costs between the same endpoints
> (or even different sets of end points) to the CDN map for example.
> 
> I see know need to include categories of individual resources, but
> returning different maps based on the category of client/consumer (e.g.
> P2P client or CDN client, etc.) should not be precluded. Having said
> that I don't think that the category of resource client needs including
> in the protocol either.

Ah, ok. This looks different :)

There is nothing which precludes any operational detail of the ALTO server in the back end, i.e., the requirements and the protocol are only about the communication between the ALTO client and the ALTO server. 

We do not specify how the data (e.g., IP addresses, topology data, etc) is process on either end (client or server). 

> I do think the original wording of the requirement could be improved

Any text suggestion?

> Apologies for sending you off on a tangent.

Don't mind :)

  Martin

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sat, 21 May 2011 02:08:48 +0100

Sebastian,

Please see inline for my responses. I've explicitly ack'd some of your responses to indicate the changes you've made have addressed my previous comment.

>> http://tools.ietf.org/wg/alto/charters?item=charter-alto-2009-02-11.txt

It wasn't in the -09 version I downloaded.

> decided to have a unique numbering for every version of the draft.

OK. It might be worth including a short RFC Editor's note to instruct them to normalise the numbering on publication.

> draft-ietf-alto-protocol-07 is one possible protocol specification.

I have significant concerns with the idea of the WG producing multiple competing ALTO protocol specifications but that's a conversation to be had if any alternative proposals are brought to the WG.

> your protocol ALTO you have to fulfill these requirements.

I am OK with the intent and the actual text in the abstract. What I object to is ARv08-5 strengthening that into "MUST be compliant" as I am not sure what the expectation is for a protocol specification to demonstrate such compliance. I assume it MUST provide protocol mechanisms for all MUST-level requirements in this document and also for SHOULD-level requirements otherwise it MUST provide justification for their absence.

That would appear to be stating that the scope of the document is not a set of requirements "that should be considered when specifying, assessing, or comparing protocols and implementations" but is in fact a formal compliance checklist.

Additionally given that some of the requirements appear to be aimed at the client protocol specification and others appear to be aimed at ALTO server implementations or ALTO discovery mechanisms then if the intent is to mandate compliance in order to be able to call something ALTO I think you need be more explicit about which requirements apply to the protocol specification Versus individual implementations

>> - The ALTO protocol MUST define a minimum set of host group descriptor types that MUST be supported by all implementations in order to aid inter-operability.

I much prefer the new text of ARv09-6 & -7 to ARv08-6,7,8,9.

However I would suggest removing "It is also possible to specify a broader address range (i.e., a shorter prefix length) than the intended group of hosts actually uses, in order to conceal their exact identity." because it's simply a statement of fact [it is possible to do many things :-)] and not a requirement that influences the protocol specification.

Or alternatively make it into a MUST level requirement but ARv08-52 already covers that use case I think.

> PID mechanism specified in draft-ietf-alto-protocol-07 is IMO OK.

Ok I now understand the intent.

However, I think the text of ARv09-10 could be improved, e.g. "SHOULD be made available by the same entity that wants to use these host group descriptors within the ALTO client protocol" is getting quite specific about the possible implementation, how about something like:

REQ.  ARv09-10: Protocol functions for mapping other host group descriptor types to IPv4/IPv6 address prefixes SHOULD be designed and specified as part of the ALTO client protocol. The corresponding address mapping information SHOULD be accessible via the ALTO client protocol.  However, an ALTO server or an ALTO client MAY utilise an external mapping facility, e.g., a translation table obtained via an alternative mechanism.

> clause about informing "the other party" is difficult to understand.

OK I missed that.

>> Also you may want to consider explicitly stating what the "basic set of criteria types, which MUST be supported are". "Relative operator's preference" is obviously one as it's an explicit requirem…

Thanks.
	
The second sentence of ARv09-14 appears to duplicate the text of ARv09-15 ("The ALTO client protocol specification MUST define an appropriate procedure for adding new rating criteria types, e.g., by establishing an IANA registry.")

I guess that's a copy & paste error :-)

> on the ALTO guidance to avoid ***causing*** network congestion ..."

Ah I understand the intent now. Yes making the change you suggest would clarify the intent perfectly.

> ARv08-21 & 22 are about dealing with multiple rating criteria within one

Ok. I personally do not like the references to query/response messages as it comes across as a specific solution rather than a requirement but I won't get too hung up about it :-)

> according to the primary criterion.

OK I think text such as the following might make that clearer/more explicit:

The ALTO query message SHOULD allow the ALTO client to express which rating criteria should be considered, as well as the order in which to apply the rating criteria for the specific application that will eventually make use of the guidance.

> sense of having a checklist for assessing protocol specs or

I struggle to see that myself.

For example I can easily look at a protocol specification and determine what assumptions it makes regarding encoding & transporting information. I can not easily look at a protocol specification and determine if it is possible to embed it in all possible third party applications.

>> ARv08-26. Do you really mean to restrict this requirement to only separation from "the operator of the IP access network" or do you actually mean to say "The ALTO protocol MUST be designed in a wa…

OK.

> to "An ALTO client protocol..."

That would clarify the requirements as stated (BTW there are many other requirements throughout the document that refer to "The ALTO client protocol")

However, my original point was really that maybe ARv09-25 (ex-ARv08-28) should really be:

"The ALTO client protocol MUST support both the target-aware and the target-independent query mode."

Different implementations may decide to support only one mode but any protocol specification should define both IMO.

>> What is a "lifetime attribute"? It implies to me an attribute that is permanent whereas I suspect you really mean "a TTL or similar mechanism, to enable caching"?

Ok.

> We're discussing with the proponents of this idea whether this still

OK I don't see any value in such a mechanism myself.

> FTP-style backconnects, etc.

Ah I think I see. The requirement is talking about an ALTO client being able to communicate with an ALTO server when NAT is in the middle. That's a well understood problem.

At first I assumed you were making a statement about the ALTO protocol having to support scenarios where the same private IP address may be assigned to multiple consumers/clients that exist in multiple places in the network and that is not a well scoped problem in the context of ALTO IMO (the current ALTO protocol draft doesn't support such a scenario for example).

>> I'm not sure how this would be implemented. If the server is able to inform the client about its impending overload, has it not by definition already entered into a conversation with the client an…

Ok

>> In the first sentence of section 3.2 I think "one or more" is better language to use rather than "one or several". I would also s/is supported/may be supported/

Ok

> protocols as a whole, not by an individual mechanism.

I see but I still think it needs to be explicitly clarified that this section does not apply to the ALTO client protocol specification conformance requirement stated in ARv09-5. 

> sense of having a checklist for assessing protocol specs or

Ok I won't get hung up about it :-)

> right. made it more explicit.

Ok

> to obfuscate the host's identity.

Is it only meant to apply to host descriptors (in which case can that be made more explciit?) or is it meant to convey that any item of information MUST be supported at different levels of details.

For example, I could intepret it to mean that the ALTO client protocol MUST support a mode where a client queries for a numerical cost between some set of Host Group Descriptors and the ALTO server responds with an ordinal ranking of the supplied Host Group Descriptors? Is that a mode of operation that it is intended that ALTO protocol specification MUST conform to?

> guidance they received". That's why this req is in the security&privacy

Ok I can see that it could fit in either section. I'm not passionate about which one it goes in.

> the latter - again in the sense of a checklist for assessing

If it is a requirement on server implementation then it shouldn't be a requirement on the ALTO protocol. I'd suggest removing it as a requirement entirely as I don't think this document is the right place to be covering generic ALTO implementation & deployment details. IMO stating a server MUST support anti-DOS mechanisms is like stating that the server MUST scale to the required transaction rate for an operator. It's a reasonable thing for an operator to require from their vendors but a protocol requirements document isn't the place to document it IMO.

Thanks
Ben