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

From: Martin Stiemerling <[email-masked]>
Date: Tue, 5 Jul 2011 09:34:11 +0000

Hi Ben, all, 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ben Niven-Jenkins
> Sent: Thursday, June 23, 2011 5:24 PM
> To: Enrico Marocco
> Cc: [email-masked]
> Subject: Re: [alto] Short WGLC for draft-ietf-alto-reqs-08
> 
> Enrico, alto-reqs authors,
> 
> On 21 Jun 2011, at 14:51, Enrico Marocco wrote:
> 
> > 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.
> 
> 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.

See below in the comments.

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

This sounds good. The text block is now in draft-to-appear -11.

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

The requirement is redundant, as there is right now only a single ALTO protocol. However, this may change anytime in the future, if people or the market would choose to go for another ALTO protocol. In case, it is good to have the ALTO reqs document which is open for other ALTO protocols. Redundancy can also improve clarity. 

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

Yes, that is the intention of the requirements draft. 

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

Well, a protocol must comply with the requirements. Obviously this requires fulfilling the requirements according to the language as specified in RFC 2119. I don't see any doubt here. 

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

I see that "relative relevance" is not as good as "the order" in the text. Your text suggestion immediately rules out other modes of relevance. For instance, we have an ALTO server implementation which can be asked to combine different ratings based on a ratio, such as 80:20 of rating critera 1 to criteria 2. In this case, there is just no order. 

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

Conceptually it does not make a big difference, but to make it clear for an educational purpose it is way better to differentiate the modes of operation. 

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

The rest of the working group seems to be fine with the general wording, as we have passed multiple WGLCs with the wording. I would call this a rough consensus. 

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

The charter anyhow limits to p2p apps right now. Not every possible.

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

I will put this in a separated track, so that this gets more attention by the WG. 

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

This got fixed in -11.

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

See separate email to be sent in a second after this email is being sent. 

Kind regards

  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: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 17 Jul 2011 14:52:00 +0100

Martin,

Thanks for the reply, I understand from your response that the outstanding comments I had were not included in -10 because I am in the rough part of rough consensus, which I can accept.

Thanks
Ben