Subject: [alto] [[email-masked]: I-D Action: draft-ietf-alto-server-discovery-07.txt]

From: Sebastian Kiesel <[email-masked]>
Date: Thu, 17 Jan 2013 11:27:42 +0100

Dear ALTO WG members,

this new version of the ALTO server discovery draft is based on the
feedback we got during WGLC.

Thanks to all reviewers!
Sebastian and the other document authors

----- Forwarded message from [email-masked] -----

Date: Thu, 17 Jan 2013 02:25:00 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: [alto] I-D Action: draft-ietf-alto-server-discovery-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Application-Layer Traffic Optimization Working Group of the IETF.

	Title           : ALTO Server Discovery
	Author(s)       : Sebastian Kiesel
                          Martin Stiemerling
                          Nico Schwan
                          Michael Scharf
                          Haibin Song
	Filename        : draft-ietf-alto-server-discovery-07.txt
	Pages           : 16
	Date            : 2013-01-17

Abstract:
   The goal of Application-Layer Traffic Optimization (ALTO) is to
   provide guidance to applications that have to select one or several
   hosts from a set of candidates capable of providing a desired
   resource.  ALTO is realized by a client-server protocol.  Before an
   ALTO client can ask for guidance it needs to discover one or more
   ALTO servers that can provide suitable guidance.

   This document specifies a procedure for resource consumer initiated
   ALTO server discovery, which can be used if the ALTO client is
   embedded in the resource consumer.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-server-discovery

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-alto-server-discovery-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-alto-server-discovery-07

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

----- End forwarded message -----

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 23 Jan 2013 10:43:18 +0100

On Thu, Jan 17, 2013 at 11:27:42AM +0100,
 Sebastian Kiesel <[email-masked]> wrote 

> feedback we got during WGLC.

I know it's late but I still have a question: why using U-NAPTR when
S-NAPTR (RFC 3958) would be sufficient?

Both examples in the draft -07 use no left-hand part in the regexp
(and I do not see what could be used for this part) and therefore
would work with S-NAPTR.

I find zero discussion on this issue in the archives of the mailing
list.

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 23 Jan 2013 16:34:27 +0100

Stephane,

Earlier versions explicitly had a reference to RFC 3958, explaining that ALTO discovery requires an URI as output.

RFC 3958 states: "The expected output of this Application is the information necessary for a client to connect to authoritative server(s) (host, port, protocol) for a particular application service within a given domain."

That seems to prevent returning an URI as needed by ALTO, right?

Thanks

Michael

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stephane Bortzmeyer
> Sent: Wednesday, January 23, 2013 10:43 AM
> To: Sebastian Kiesel
> Cc: [email-masked]
> Subject: [alto] S-NAPTR? (Was: [[email-masked]: I-D 
> Action: draft-ietf-alto-server-discovery-07.txt]
> 
> On Thu, Jan 17, 2013 at 11:27:42AM +0100,  Sebastian Kiesel 
> <[email-masked]> wrote  a message of 67 lines which said:
> 
> I know it's late but I still have a question: why using 
> U-NAPTR when S-NAPTR (RFC 3958) would be sufficient?
> 
> Both examples in the draft -07 use no left-hand part in the 
> regexp (and I do not see what could be used for this part) 
> and therefore would work with S-NAPTR.
> 
> I find zero discussion on this issue in the archives of the 
> mailing list.

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 23 Jan 2013 16:47:17 +0100

Stephane, Michael,

On Wed, Jan 23, 2013 at 04:34:27PM +0100, Scharf, Michael (Michael) wrote:
> Stephane,
> 
> Earlier versions explicitly had a reference to RFC 3958, explaining
> that ALTO discovery requires an URI as output.

this is still in section 1, third paragraph of our draft.

> > and therefore would work with S-NAPTR.

Please have a look at the (cited) RFC 4848. Sec 4.6 says that
the only type of allowed regexp is a "complete replacement" regexp,
i.e., without backreference to some part of the input.

regards,
Sebastian

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 23 Jan 2013 16:49:54 +0100

On Wed, Jan 23, 2013 at 04:34:27PM +0100,
 Scharf, Michael (Michael) <[email-masked]> wrote 

> That seems to prevent returning an URI as needed by ALTO, right?

Right. Thanks for the explanation.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 23 Jan 2013 16:52:48 +0100

On Wed, Jan 23, 2013 at 04:47:17PM +0100,
 Sebastian Kiesel <[email-masked]> wrote 

> this is still in section 1, third paragraph of our draft.

No, it is not, the reference to S-NAPTR (RFC 3958) is not
present. (There is a reference to RFC 3958 later but for a differant
reason.)

BTW, to return a URI, there is also draft-faltstrom-uri

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 23 Jan 2013 17:05:49 +0100

> present. (There is a reference to RFC 3958 later but for a differant

our draft states that we have to yield and deliver an URI.

The U-NAPTR spec, RFC 4848 which is cited, has an introduction section
with rationale why S-NAPTR is not sufficient for all applications.

let me cite from that:

   This U-NAPTR is effectively a modest extension to S-NAPTR, to
   accommodate the use of URIs as targets, without allowing the full
   range of possible regular expressions in NAPTR records.

> BTW, to return a URI, there is also draft-faltstrom-uri

we have all we need in RFCs, so why build on drafts that might still
be subject to change?

Sebastian