On 06/23/2011 12:00 PM, Ben Niven-Jenkins wrote:
Vijay,
Ben: Thanks for your feedback.
I took a quick look over the test cases and although the details are
not complete for some of them they look a fairly reasonable set of
tests.
Right, the intent is to get the test cases out so
folks can see the nature of the tests, while simultaneously
fine tuning them.
More inline.
Some comments:
1) I wonder whether it is worthwhile to define at least one of the
PIDs as containing multiple IP subnets as in real life PIDs are
likely to contain>1 subnet.
Good idea. I will put multiple subnets in a PID.
2) As part of the IPv6 test cases I think some PIDs should contain a
mixture of both IPv4& IPv6 PIDs while other PIDs contain purely IPv4
or IPv6.
What triggers the choice of an ALTO server returning an IPv6
address? An IPv6 address sent by the client and indicated as
the source address? Returning IPv6 addresses to clients who
have indicated a source address of IPv4, obviously, does not
make sense.
I have put a placeholder for an IPv6 test, but decided to
concentrate on IPv4 first to get the flavour of the tests
out as a first cut.
3) I assume that the specific hostnames and URLs used in the test
cases are purely used for example purposes and the expectation is
that the client will be configured with the location of the IRD and
then discover the other services based on the contents on the
obtained IRD?
Yes, indeed.
More below.
You also asked:
Miscellaneous notes
1) Section 4.2.1 says that "Each endpoint MUST map into exactly
one PID."
What happens if a client finds out that the above is not true?
IMO:
If a client discovers that a given CIDR block is present in more than
one PID then the client should be free to pick any of the PIDs that
the block is a member of according to local configuration/policy.
If a server discovers that a given CIDR block is present in more than
one PID then the server should be free to pick any of the PIDs the
block is a member of according to local configuration/policy. However
for a given resource the same decision should be made for a given
version of the underlying map (i.e. subsequent requests generate the
exact same result and URLs that are served by multiple implementation
instances also generate the exact same result regardless of which
implementation instance is returning the response).
This all sounds reasonable. The question I have is how much of
this should be captured in the protocol document. That document
simply states that there is a 1-1 relationship between an
endpoint and PID. We can leave it at that and not worry about
the question I ask above. However, if we go down the route of
providing heuristics to deal with 1-N mapping, then we should
just as well put it in the document itself.
Thoughts?
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email protected]
Web: http://ect.bell-labs.com/who/vkg/
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto