Adding spring@ Adrian Farrel <[email protected]> wrote: > Looking at your section 18.1 I find:
> This document assumes that a client SHOULD use a single transaction
> for all of the IA options required on an interface; this simplifies the
> client implementation and reduces the potential number of transactions
> required.
> The use of "SHOULD" puzzles me. It appears a bit of a double
> conditional: you are assuming client implementation behavior, and the
> clients should act in a certain way. What happens if a client decides
> to use more than one transaction, and why might it do that?
I think that if the client does multiple transactions, then it is sending
multiple messages. It can do the Discovery as normal, and then having a
list of available servers, it either puts its needs into a single Request
message, or it can send multiple Request messages.
With servers and systems that I'm familiar with, a server that saw multiple
requests from the same client for different kinds of objects would just send
multiple replies. If the client asks for multiple IA_NA in different
messages, that might be fine.
(Maybe, for IA_PD, it's really multiple containers/VMs, behind an icky NPTv6)
Perhaps there are some scenarios where a server would fail to answer the
additional requests because it only gives out N things per macaddress,
and had they been in the same Request, it would have counted at 1, not N.
having glanced at draft-ietf-spring-dhc-distribute-srv6-locator-dhcp
Note about:
> After the DHCPv6 server allocates PD, BRAS will add a network route
> corresponding to PD to local routing table and distribute the network
> route to the upstream routers.
how the BRAS, if it is not the DHCPv6-server, knows to do this, is not
standardized. Today, implementations eavesdrop on the DHCPv6 Reply, which I
hate. But, that section (3. Motivation) is describing the bad way :-)
I was looking for maybe if this document had defined *two* things and that
they could be split up, but that woudldn't work. I see IA_SVR6_LOCATOR,
and within it, IALOCATOR.
And then 5.0 with that single-transaction comment.
I'm not keen on section 5.1 retelling so much of 8514bis.
At least, "As described..." makes it clear that nothing is being changed.
This is a refresher.... But the paragraphs which do not say that concern me
slightly.
As I began reading section 5.1, I thought I'd say some other request, like a
PD, being asked for at the same time, and needing to be qualified by the
SVR6* stuff. nope.
I would turn 5.3, paragraph 4 into points.
So I'm not seeing any reason to assume that 5.0 text, the client can't send
things as multiple transactions, because there is only one transaction.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
