Subject: [alto] WG adoption of *-3pdisc and *-ip-based-srv-disc drafts

From: Enrico Marocco <[email-masked]>
Date: Tue, 15 Oct 2013 09:44:54 +0200

Dear WG participants:

we would like to check consensus on the adoption of the following drafts
that will complement the server discovery deliverable in the current
ALTO WG charter:

  + draft-kiesel-alto-ip-based-srv-disc
  + draft-kist-alto-3pdisc

The drafts were discussed on this list and presented in a few meetings.
In Orlando (IETF-86) the WG indicated consensus, but we agreed to
postpone the adoption in order to focus energies on the base protocol.
Now that the core specs are undergoing WGLC, it seems a good time to
resume the work.

If you have any opinion on whether such document should or should not
become working group items, please state it by Wednesday, October 30.

Enrico

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 16 Oct 2013 16:32:24 -0400

In short, I support adopting the two documents as WG working items.

Below are some detailed comments, in case anyone cares to read more details.

- http://tools.ietf.org/html/draft-kiesel-alto-ip-based-srv-disc-02

  As already discussed, this document has potential to become a
general-purpose mechanism (e.g., instead of http://192.0.0.X/alto, a
general one might be http://192.0.0.X/<service>).

 After becoming a WG item, it may keep this general-purpose mechanism in
mind. Here is one example of potential impact: the current version
specifies HTTP redirect (Sec. 2.3, first para of Sec. 2.4). A
general-purpose service may not use HTTP, and hence, it might need to
include other mechanisms (e.g., redirect info contained in the returned
page of the* WkAsdURI).*

 Some details need to be added, and some are already marked TBD. There are
can be additional items. For example, it specifies that a change of IP
address of an interface invalidates the result. This is in a sense a
sufficient condition. There can be corner cases such as the IP address does
not change but the MAC address of 192.0.0.X changes (change of redirection
server). A soft state based approach based on refresh may help to detect
such changes in a more uniform way. As another example, I still need to be
convinced on some requirements such as the 3rd paragraph of Sec. 2.4 (IRD
not reside on WkAsdIPa). Finishing the security section will be helpful too.

 Despite the preceding comments, the document is an excellent starting
point on an important service, and I support adopting this document.

- http://tools.ietf.org/html/draft-kist-alto-3pdisc-04

  This is also an important use case: 3rd party, and the WG should resolve
this item completely.

Richard

On Tue, Oct 15, 2013 at 3:44 AM, Enrico Marocco <
[email-masked]> wrote:

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

---

From: Sebastian Kiesel <[email-masked]>
Date: Thu, 17 Oct 2013 14:04:31 +0200

Dear all,

>   + draft-kiesel-alto-ip-based-srv-disc

[writing as a co-author of these two drafts]

Of course I think both drafts are useful and should be adopted, but
I leave the decision up to our valued chairmen whether to consider/count
this statement. :)

[writing as a co-author of RFC 6708 (ALTO requirements)]

I'd like to bring to your attention that AR-33 (third-party discovery)
is the only requirement we have documented, for which no WG item
specification exists so far.  
draft-kist-alto-3pdisc provides a solution for this requirement.
However, if someone knows another (better?) solution, please share it
with us now.

AR-32 (resource consumer initiated ALTO server discovery) is supported
by draft-ietf-alto-server-discovery-10, which is now in the RFC editor
queue.  While this draft is definitely uselful in several important
deployment scenarios, it is not 100% optimal in the light of AR-37.
This is where draft-kiesel-alto-ip-based-srv-disc fits in.

Thanks
Sebastian