Subject: [alto] Short WGLC for draft-ietf-alto-reqs-08

From: Enrico Marocco <[email-masked]>
Date: Tue, 21 Jun 2011 15:51:07 +0200

As agreed during the latest interim, the chairs would like to declare
one last Working Group Last Call for draft-ietf-alto-reqs-08, ending
Tuesday, July 5.

Please do review the changes in the latest version of the draft, and
send any comments to the list before the expiry of WGLC so we can get
this document ready for the IESG.

-- 
Ciao,
Enrico

---

From: Sebastian Kiesel <[email-masked]>
Date: Tue, 21 Jun 2011 17:43:11 +0200

Hi Enrico, all,

> this document ready for the IESG.

The latest version of the document is draft-ietf-alto-reqs-10.
I assume this was just an error and we should all review version 10.

Thanks,
Sebastian

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 22 Jun 2011 08:57:04 +0200

> I assume this was just an error and we should all review version 10.

Of course, I mistook protocol's version with reqs', my bad.

-- 
Ciao,
Enrico

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 22 Jun 2011 03:25:27 -0400

I've sent some emails in the past regarding ARV-31-34 that were echoed by
other people. I still think WGLC can be completed without changing their
text

For example...

"   REQ.  ARv10-32: An ALTO client protocol specification MUST specify
   mechanisms, or detail how to leverage appropriate mechanisms provided
   by underlying protocol layers, which can be used by an ALTO server
   operating close to its capacity limit, to inform clients about its
   impending overload situation, and require them to throttle their
   query rate.
"

- Why is 'impending overload'?
- Why clients need to throttle their requests? Throttle how? Exponetial
backoff, etc...

Others

- " operating close to its capacity limit". How close?

This all leads to multiple interpretations and interoperability issues

As I mention before we should just use wording similar to HTTP.

Suggested simpler text

"...inform the client that the server is currently unable to handle the
request due to a temporary overloading or maintenance of the server."

On 6/21/11 8:43 AM, "Sebastian Kiesel" <[email-masked]> wrote:

> draft-ietf-alto-reqs-10

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 22 Jun 2011 03:25:30 -0400

Comments on ARV10-34 which I believe need to be fixed before making it a
RFC.

"   REQ.  ARv10-34: An ALTO client protocol specification MUST specify
   mechanisms, or detail how to leverage appropriate mechanisms provided
   by underlying protocol layers, which can be used by an ALTO server
   operating close to its capacity limit, to inform clients about its
   impending overload situation, and terminate the conversation with the
   ALTO client.
"

What is the meaning of "terminate the conversation". We should be a bit more
specific or be simpler and drop the wording.

For example, from HTTP

"     Note: The existence of the 503 status code does not imply that a
      server must use it when becoming overloaded. Some servers may wish
      to simply refuse the connection.
"

In other words, why the ALTO Server needs to accept the connection just to
send a message saying 'I can not really serve this request'.

Suggested text

"   REQ.  ARv10-34: An ALTO client protocol specification MUST specify
   mechanisms, or detail how to leverage appropriate mechanisms provided
   by underlying protocol layers, which can be used by an ALTO server
   that is temporarily overloaded to inform clients that is unable to handle
   the request. A server also can simply refuse the connection.
"

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 23 Jun 2011 16:23:43 +0100

Enrico, alto-reqs authors,

> this document ready for the IESG.

I previously made some comments against -08, most of which have been incorporated into the latest version (-10), however it is not clear to me whether they have not been reflected in the -10 draft because they have been overlooked or because they have been rejected by the authors/WG.

One additional comment I would make is that the introduction text to section 3.2. states:

   This section enumerates requirements for an ALTO client
   protocol, as well as general requirements to be fulfilled by the ALTO
   server discovery mechanisms.

However, none of the requirements in that section relate to an ALTO client protocol although some do relate to an ALTO client implementation. Therefore I would suggest the sentence is reworded as follows:

   This section enumerates requirements for an ALTO client, as well as
   general requirements to be fulfilled by the ALTO server discovery
   mechanisms.

Thanks
Ben

The four comments I mention above are:

On 21 May 2011, at 02:08, Ben Niven-Jenkins wrote:
> On 11 May 2011, at 10:58, Sebastian Kiesel wrote:
>> On Fri, Apr 29, 2011 at 12:52:49PM +0100, Ben Niven-Jenkins wrote:
>>> 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.
> 
> 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
> 
>>> 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.
> 
> 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.
> 
>>> 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
> 
> 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.
> 
> 
>>> 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..."
> 
> 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.
> 
>

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 29 Jun 2011 13:26:48 +0000

Reinaldo,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Reinaldo Penno
> Sent: Wednesday, June 22, 2011 9:25 AM
> To: Sebastian Kiesel; Enrico Marocco
> Cc: [email-masked]
> Subject: [alto] Second round of comments on Re: WGLC on ALTO reqs 10, not
> 08
> 
> other people. I still think WGLC can be completed without changing their text
> 
> For example...
> 

I guess the text is fine as it is: this draft is not a protocol specification which needs to specify what the back-off algorithm is. 

> - " operating close to its capacity limit". How close?

This is neither a matter of the ALTO requirements nor of the ALTO protocol specification but a local configuration of the ALTO server. 

> "...inform the client that the server is currently unable to handle the request
> due to a temporary overloading or maintenance of the server."

HTTP is a protocol specification, this draft is a requirements draft.

  Martin

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

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 29 Jun 2011 13:31:58 +0000

Reinaldo, 

Arv10-34 is describing the last resort, when the ALTO server is unable to tell the client to throttle or redirect it to another server. 

 This draft is a requirements draft and it is not about define the exact measures to be taken by the actual protocol. Termination of a conversation can mean different things in different situations, e.g., sending a TCP reset or stay silent to not exacerbate the overload situation. 

  Martin

> Sent: Wednesday, June 22, 2011 9:26 AM
> Subject: [alto] Comments on Re: WGLC on ALTO reqs 10, not 08
> 
> What is the meaning of "terminate the conversation". We should be a bit
> more specific or be simpler and drop the wording.
> 
> For example, from HTTP
>

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 29 Jun 2011 09:40:13 -0400

On 6/29/11 6:26 AM, "Martin Stiemerling" <[email-masked]>
wrote:

> I guess the text is fine as it is: this draft is not a protocol specification
> which needs to specify what the back-off algorithm is.

If you are requiring clients to throttle then the protocol needs to specify
how to throttle, the algorithm and others. This makes the client more
complex without any tangible benefit.

> This is neither a matter of the ALTO requirements nor of the ALTO protocol
> specification but a local configuration of the ALTO server.

If it is not a matter of requirements can we drop this requirement? The IETF
does not standardize local policy issues, right?

>> request

It is still making a requirement that is open to interpretation. Why not
simplify the requirement wording?