Subject: Re: [alto] #1: Message format

From: "alto issue tracker" <[email-masked]>
Date: Thu, 04 Mar 2010 19:44:59 -0000

#1: Message format
---------------------------------------------+------------------------------
 Reporter:  enrico.marocco@…                 |       Owner:  richard.alimi@…       
     Type:  enhancement                      |      Status:  new                   
 Priority:  blocker                          |   Milestone:                        
Component:  protocol                         |     Version:                        
 Severity:  Active WG Document               |    Keywords:                        
---------------------------------------------+------------------------------

Comment(by richard.alimi@…):

 draft-ietf-alto-protocol-02 now includes a more complete protocol
 specification.  The current encoding specification provides example
 requests and responses, as well as documenting the syntax and enumerating
 the components of the messages.

 The current encoding specification is not as formal and compact as it
 probably could be, so work is needed in this area. One possibility for a
 more compact representation is a C-style syntax where JSON objects are
 formally documented as C-style structs.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/alto/trac/ticket/1#comment:1>
alto <http://tools.ietf.org/alto/>

---

From: "alto issue tracker" <[email-masked]>
Date: Tue, 09 Mar 2010 00:57:54 -0000

#1: Message format
---------------------------------------------+------------------------------
 Reporter:  enrico.marocco@…                 |       Owner:  richard.alimi@…       
     Type:  enhancement                      |      Status:  assigned              
 Priority:  blocker                          |   Milestone:                        
Component:  protocol                         |     Version:                        
 Severity:  Active WG Document               |    Keywords:                        
---------------------------------------------+------------------------------
Changes (by richard.alimi@…):

  * status:  new => assigned

Comment:

 draft-ietf-alto-protocol-03 now uses a more concise representation (using
 C-style structs) for formally specifying protocol structure.

 Still leaving this issue open since there has been no discussion yet in
 the WG regarding the messaging.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/alto/trac/ticket/1#comment:2>
alto <http://tools.ietf.org/alto/>

---

From: Jason Livingood <[email-masked]>
Date: Thu, 11 Mar 2010 15:38:53 -0500

You may want to make some of these tracker notes more verbose.

In any case, was your objective to make the request and response simpler or
what's in body of the <ALTOResponse> itself?

And depending upon the case, which section of
http://tools.ietf.org/html/draft-ietf-alto-protocol-03 would you like
targeted comments on? (7.5?)

Thanks
Jason

On 3/8/10 7:57 PM, "alto issue tracker" <[email-masked]> wrote:

> #1: Message 
> format
---------------------------------------------+-------------------------
> -----
 Reporter:  enrico.marocco@Š                 |       Owner:
> richard.alimi@Š       
     Type:  enhancement                      |
> Status:  assigned              
 Priority:  blocker                          |
> Milestone:                        
Component:  protocol
> |     Version:                        
 Severity:  Active WG Document
> |    Keywords:   

> Changes (by richard.alimi@Š):

> C-style structs) for formally specifying protocol structure.

 Still leaving
> this issue open since there has been no discussion yet in
 the WG regarding
> the messaging.

-- 
Ticket URL:
> <http://trac.tools.ietf.org/wg/alto/trac/ticket/1#comment:2>
alto
> <http://tools.ietf.org/alto/>

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

---

From: Richard Alimi <[email-masked]>
Date: Thu, 11 Mar 2010 17:29:33 -0500

Hi Jason,

Thank you very much for taking a look.  Please see below:

> You may want to make some of these tracker notes more verbose.

At this point, since this is a first stab at fully specifying protocol 
details, my personal feeling is that we are still wide-open for discussion on 
the whole document. However, there on a few points that I think are particular 
important for this go-around:

- IPv4/IPv6 needs much more thought before integrating it into
  the document.  In particular, what are the right semantics for handling IPv4
  and IPv6 with respect to indicating provider preferences? (Some initial
  questions are noted on Issue #9 for this)?

- With regard to messaging (including usage of HTTP URIs and the actual body
  encodings), can people think of issues that might cause problems for
  deployment in an operational network (e.g., load-balancing configuration)?
  Difficult or non-intuitive implementation (both server-side and
  client-side)?  Are there any ambiguities you can see?
  I thinking through the current protocol details we have tried to address
  these, but input from others would be extremely helpful.

- For Redistribution, this is a capability that seemed to get favorable
  feedback at IETF76. The current implementation uses HTTP headers/trailers to
  send the signatures, and a certificate is encoded in the Server Capability
  response. The idea is that an ALTO Client can locally cache the certificate
  and only contact the ALTO Server very infrequently even if it is gathering
  ALTO information (i.e., ALTOResponse structs) from other ALTO Clients
  instead of the ALTO Server itself. For this part, what do people think about
  how such redistribution information is encoded in the protocol? Is there a
  clean way to do this without requiring custom HTTP headers/trailers? Does
  the spec sufficiently convey when redistribution should or should not be
  used?

> what's in body of the <ALTOResponse> itself?

The changes from -02 -> -03 were to bring the encoding specification more in 
sync with other IETF specs and specify the structure of messages more formally 
(with adjustments made since we are actually specifying encoding within JSON). 
They were not intended to make the request/response simpler -- only to make 
the specification more precise.

In the document, ALTOResponse is a JSON Object with certain required fields, 
which are specified in 7.2.3.3 (and the subsections thereof).  This was the 
intent, anyways. Should this be made more clear?

> targeted comments on? (7.5?)

For protocol messaging, 7.5 is currently the guts of how ALTO Information is 
encoded. However, the current usage of HTTP (e.g., URI's, status codes, etc) 
in earlier subsections of Section 7 would be good to get feedback.

As mentioned above, I would think that comments about the entire document are 
very useful, but the major changes in these couple of revisions have been to 
sections 6, 7, and 11 (so feel free to focus there).

-- 
Richard Alimi
Department of Computer Science
Yale University

---

From: "Martin Stiemerling" <[email-masked]>
Date: Thu, 18 Mar 2010 12:39:15 +0100

Rich, 

a few comments inline:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Richard Alimi
> Sent: Thursday, March 11, 2010 11:30 PM
> To: Jason Livingood
> Cc: [email-masked]
> Subject: Re: [alto] #1: Message format
> 
> Hi Jason,
> 

A simple turn on this: limit a single query-object to an IP address family. However, a query to the server can include multiple query-objects, i.e., one each for an IP address family or whatever identifier comes up later on (e.g. HIP IDs ;)

>   these, but input from others would be extremely helpful.

I'm still browsing through this and how JSON works. 

>   the spec sufficiently convey when redistribution should or should not

I'm not sure that the spec is doing good in this respect. The emphasize is on the security (i.e., using certificates), but an important point is missing. The server should state in what area (i.e., IP prefix) this information is allowed to be distributed. 

See draft-kiesel-alto-h12-02 under redistribution:

   The response contains also a resource consumer host location
   attribute (rc_hla).  This rc_hla echos partially the information from
   the request, but gives actually guidance to the ALTO client in what
   scope this information can be distributed amongst other peers.  In
   this response, the server allows the redistribution of the received
   guidance to peers with the IP prefix 195.37.0.0/16.

> sections 6, 7, and 11 (so feel free to focus there).

I'm still reading...
 
  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: Richard Alimi <[email-masked]>
Date: Thu, 18 Mar 2010 09:50:22 -0400

Hi Martin,

Thank you very much for the comments.  Please see inline:

On Thursday 18 March 2010 7:39:15 am Martin Stiemerling wrote:
> >   the document.  In particular, what are the right semantics for
> > 
> > handling IPv4
> > 
> >   and IPv6 with respect to indicating provider preferences? (Some
> > 
> > initial
> > 
> A simple turn on this: limit a single query-object to an IP address family.
> However, a query to the server can include multiple query-objects, i.e.,
> one each for an IP address family or whatever identifier comes up later on
> (e.g. HIP IDs ;)

Yes, this is one possibility.  One limitation of this approach is that we 
could only convey a _global_ preference for IPv4, IPv6, etc.  That is, a 
network provider could say "please prefer IPv6 regardless of who you are 
contacting."

Another possible preference that one might want to convey is per-destination 
Network Location. For example, "please prefer IPv6 when contacting endpoints 
in ISP A, but please prefer IPv4 when contacting endpoints in ISP B."  It 
would be good to hear some opinions (particularly from service providers) as 
to whether such preferences this would useful or necessary.  If so, we can 
figure out a reasonable way to encode such preferences (one possibility may be 
a per-PID attribute).

> >   deployment in an operational network (e.g., load-balancing
> > 
> > configuration)?
> > 
> >   I thinking through the current protocol details we have tried to
> > 
> > address
> > 

Sounds good.

> >   feedback at IETF76. The current implementation uses HTTP
> > 
> > headers/trailers to
> > 
> >   send the signatures, and a certificate is encoded in the Server
> > 
> > Capability
> > 
> >   response. The idea is that an ALTO Client can locally cache the
> > 
> > certificate
> > 
> >   and only contact the ALTO Server very infrequently even if it is
> > 
> > gathering
> > 
> >   instead of the ALTO Server itself. For this part, what do people
> > 
> > think about
> > 
> >   how such redistribution information is encoded in the protocol? Is
> > 
> > there a
> > 
> >   clean way to do this without requiring custom HTTP headers/trailers?
> > 
> > Does
> > 
> >   the spec sufficiently convey when redistribution should or should not
> > 
> > be
> > 
> >   used?
> 
> I'm not sure that the spec is doing good in this respect. The emphasize is
> on the security (i.e., using certificates), but an important point is
> missing. The server should state in what area (i.e., IP prefix) this
> information is allowed to be distributed.
> 

This is actually what the "server", "request_uri" and "request_body" 
attributes are for. As stated in the draft:

   ... This allows ALTO Clients to which the information is distributed to
   understand the context of the query and interpret the results.

Here, the "context" basically means "the full set of input parameters that 
would have produced this response."  Using this, ALTO Clients can determine 
the distribution scope.  Put another way, if another ALTO Client executed the 
same query (to the same server) with this particular input, they'd get the 
same response.

The only case where such a guarantee is not available is when other 
information beyond the URI or ALTO Request Body is used to generate the 
response.  In the current protocol, such cases should not (as a side note, 
perhaps it should be changed to a MUST NOT..) be redistributed:

   Note that information about ALTO Client performing the Request and
   any HTTP Headers passed in the request are not included.  If any such
   information or headers influence the response generated by the ALTO
   Server, the response SHOULD NOT be indicated as redistributable.

Such a case *could* be handled as you mentioned by explicitly giving a scope 
for redistribution, but I'm wondering what particular queries you were 
thinking about here, and whether it makes sense to redistribute the responses 
to such queries.

Another way to interpret your concern is from an access-control perspective. 
That is, using such a scope to indicate which other ALTO Clients have 
permission to receive this particular ALTO Response.  If this is the intention 
(I'm not implying that you think it is, I'm just trying to cover all of the 
bases), then I don't think this is reasonable to put in the protocol, since 
ALTO Clients are in no way bound to follow this advice.

> > sections 6, 7, and 11 (so feel free to focus there).

Great :)

Thanks again for the comments!

---

From: "Martin Stiemerling" <[email-masked]>
Date: Sat, 27 Mar 2010 11:57:01 +0100

Hi Rich, 

For the IPv6/IPv4 part: I would give it an easy start and to simply return two lists (if asked for), one for IPv4 and one for IPv6. Expressing relationships or dependencies between them would go too far (it's not about us to solve the IP4/IPv6 transistion) and would also increase the complexity in the protocol and also the implementation. 

  Martin

> From: Richard Alimi [mailto:[email-masked]] On Behalf Of
> Richard Alimi
> Sent: Thursday, March 18, 2010 2:50 PM
> To: Martin Stiemerling
> Cc: [email-masked]
> > > - With regard to messaging (including usage of HTTP URIs and the
> actual
> > > body
> > >
> > > very useful, but the major changes in these couple of revisions
> have
> > > been to