Subject: [alto] Some comments on draft-ietf-alto-protocol-08.txt

From: "Zhang, Ning" <[email-masked]>
Date: Fri, 10 Jun 2011 12:49:51 -0400

Here are some comments on the I-D:

7.3.4.1

'InfoResourceRedistDesc' is not defined. Instead, Section 8.2 defines 'RspRedistDesc'.

7.4.3

Specific error codes have been defined for cost types, cost modes, properties.

Additional error codes may need to be defined for invalid PIDs, IP addresses, etc.

7.6.3

On page 31, the last ',' for the "http://custom.alto.example.com/maps" resource record should be removed.

7.7.2.1.6

The last ']' in the example on page 38 should be '}' instead.

7.7.3.1.6

The 'pids' field is better to be quoted in the JSON request message, such as:

{
   "pids" : [ "PID1", "PID2" ]
}

7.7.4.1.3

Should the 'properties' and 'endpoints' fields be defined as <1..*> instead of <0..*>?

7.7.5.1.3

The 'srcs' field is specified as OPTIONAL, with the default value as EndPoint address of the requesting client, if none is specified.

This may not work if the intermediate network devices/applications do not forward the address to the ALTO server.  The requesting client may be under the false assumption that the ALTO server would always be able to determine its address.

7.7.5.1.6

The response example is missing the 'cost-type' and 'cost-mode' fields.

-EOF-

---

From: Richard Alimi <[email-masked]>
Date: Tue, 14 Jun 2011 22:24:27 -0700

Hi Ning,

Thank you very much for reading through the draft.  Some replies
below. I've marked as done/fixed the items where I've modified
locally, and the updates will be present in the next posted version of
the draft.

> 'InfoResourceRedistDesc' is not defined. Instead, Section 8.2 defines 'RspRedistDesc'.

Fixed the reference to RspRedistDesc. The correct name should be
InfoResourceRedistDesc. Also fixed the reference to RspMetaData (it
should be InfoResourceMetaData).

> Additional error codes may need to be defined for invalid PIDs, IP addresses, etc.

For PIDs, by design, the ALTO Server currently ignores ones that are
non-existent.  The idea was to get some useful work done even if the
ALTO Server's map is changing.

For IP addresses, do you mean improper syntax?  In that case, how
about a more general error code like E_SYNTAX (which might also
include JSON syntax errors, or we could define a new status code to
distinguish between ALTO syntax and JSON syntax).  If you mean
something beyond syntax, can you expand on the case that you were
thinking about?

> On page 31, the last ',' for the "http://custom.alto.example.com/maps" resource record should be removed.

Good catch. Fixed.

> The last ']' in the example on page 38 should be '}' instead.

Fixed.

>   "pids" : [ "PID1", "PID2" ]

Yes indeed. Fixed.

> Should the 'properties' and 'endpoints' fields be defined as <1..*> instead of <0..*>?

That sounds reasonable to me. Done.

> This may not work if the intermediate network devices/applications do not forward the address to the ALTO server.  The requesting client may be under the false assumption that the ALTO server would…

Yes, there is a note about this in 10.3.  Reworded the text here to
read: ".. the ALTO Server MUST interpret it as if it contained the
Endpoint Address corresponding to the client IP address from the
incoming connection." Also added a reference to 10.3.

Does this sound better?

Yes, it should be used with caution, but it might be a reasonable
approximation, e.g., if the NAT is nearby the client in the network.

> The response example is missing the 'cost-type' and 'cost-mode' fields.

Fixed.

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

---

From: Richard Alimi <[email-masked]>
Date: Wed, 15 Jun 2011 07:37:52 -0700

On Wed, Jun 15, 2011 at 7:16 AM, Zhang, Ning <[email-masked]> wrote:
> Hi, Rich,
>
> A general ALTO syntax error code would be sufficient for covering those syntax errors of various input fields, such as IP addresses.

Great - if there are no objections from others, we'll put that in the
next version.

>
> The change to be made in 7.7.5.1.3 makes things clear.

Great.

Thanks again for finding these!

Rich

>
> Thanks,
> -Ning
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Alimi
> Sent: Wednesday, June 15, 2011 1:24 AM
> To: Zhang, Ning
> Cc: [email-masked]
> Subject: Re: [alto] Some comments on draft-ietf-alto-protocol-08.txt
>
> Hi Ning,
>

---

From: "Zhang, Ning" <[email-masked]>
Date: Wed, 15 Jun 2011 10:16:45 -0400

Hi, Rich,

Thanks,
-Ning

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Alimi
Sent: Wednesday, June 15, 2011 1:24 AM
To: Zhang, Ning
Cc: [email-masked]
Subject: Re: [alto] Some comments on draft-ietf-alto-protocol-08.txt

Hi Ning,

Good catch. Fixed.

Fixed.

Yes indeed. Fixed.

Does this sound better?

Fixed.

---

From: Richard Alimi <[email-masked]>
Date: Wed, 15 Jun 2011 23:34:08 -0700

On Wed, Jun 15, 2011 at 9:32 AM, Zhang, Ning <[email-masked]> wrote:
> Hi, Rich,
>
> Here is another comment regarding to the IP addresses in an endpoint cost lookup response, specified in Section 7.7.5.1.5.
>
> It would be better to make it clear that each IP address in the response must be encoded in the same format as specified in the incoming request.
>
> For example, if "ipv6:FF00::192.1.1.1" is specified in the request, the server should use the same one in the response, instead of other equivalent formats, such as "ipv6:FF00::C001:0101".
>

I'm not convinced there needs to be such a requirement - can you say
why this should be?  For example, in implementation I would imagine
parsing the addresses in the request into the raw bytes (since that is
presumably the format used for the longest-prefix-matching).  It seems
like extra work (and messy) to ask the ALTO Server to return addresses
in a particular format since it needs to also store this bookkeeping
information along with the parsed request. Furthermore, what if the
ALTO Client put two addresses in different formats in the request?
Which format should the ALTO Server use in the response?  This seems
much more complicated than it needs to be.

Thanks,
Rich

---

From: "Zhang, Ning" <[email-masked]>
Date: Wed, 15 Jun 2011 12:32:13 -0400

Hi, Rich,

Thanks,
-Ning

---

From: Richard Alimi <[email-masked]>
Date: Thu, 16 Jun 2011 09:37:05 -0700

Hi Ning,

On Thu, Jun 16, 2011 at 8:32 AM, Zhang, Ning <[email-masked]> wrote:
> Hi, Rich,
>
> The issue is related to lookup specific answers in the response efficiently.
>
> For example, if the request is as the following:
>
>   {
>     "cost-mode" : "ordinal",
>     "cost-type" : "routingcost",
>     "endpoints" : {
>       "srcs": [ "ipv6:FF00::192.0.1.1" ],
>       "dsts": [ "ipv6:FF00::192.168.1.1", "ipv4:198.100.1.1" ]
>     }
>   }
>
> And the answer is as the following:
>
>   {
>     "meta" : {},
>     "data" : {
>       "map" : {
>         "ipv6:FF00::C000:0101" : {
>           "ipv6:FF00::C0A8:0101" : 1,
>           "ipv4:198.100.1.1"     : 2
>         }
>       }
>     }
>   }
>
> The client would not able to simply use its original IP addresses as keys for checking answers.
>
> In most JSON implementations, the "map" object in the response would be implemented as an associated array. If an IP address in the response is in different format from the one in the request, the client would have to be forced to convert all addresses into a uniform format, and loop thru the array for the answer.
>
> For example, the following javascript code would not work for the above response:
>
>        answer = rsp.data.map["ipv6:FF00::192.0.1.1"];
>        if( answer != null ) {
>                rank = answer["ipv6:FF00:192.168.1.1"];
>        }

My feeling is that this is an implementation detail of the server.  In
particular, it would be coupling the server implementation to a
particular encoding on the wire, which would better be left separated.
 For example, imagine a server implementation that wished to offload
JSON processing to a separate component or server. That implementation
would become quite complex if it needed to also track the original
encoded version of each IP address.  Are there any other example
protocols (preferably in the IETF) that you can point to that do what
you are suggesting?

Thanks,
Rich

> Sent: Thursday, June 16, 2011 2:34 AM
> To: Zhang, Ning
> Cc: [email-masked]

---

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

On 16 Jun 2011, at 07:34, Richard Alimi wrote:

> why this should be?

I also don't see the need to force the server to reply in the same format that the client used. It may be sensible to recommend (or even mandate) that servers return IPv6 addresses according to the recommendations in RFC5952 though.

Ben

>  For example, in implementation I would imagine

---

From: "Zhang, Ning" <[email-masked]>
Date: Thu, 16 Jun 2011 11:32:53 -0400

Hi, Rich,

   {
     "cost-mode" : "ordinal",

   {
     "meta" : {},
     "data" : {
       "map" : {

Thanks,
-Ning

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Alimi
Sent: Thursday, June 16, 2011 2:34 AM
To: Zhang, Ning
Cc: [email-masked]
Subject: Re: [alto] Some comments on draft-ietf-alto-protocol-08.txt

Thanks,
Rich