[spring] Re: Question about draft-ietf-dhc-rfc8415bis

--===============8569273284410707692==
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha512; protocol="application/pgp-signature"

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


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 t=
he
    > 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 NPTv=
6)

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.

=2D-
]               Never tell me the odds!                 | ipv6 mesh network=
s [
]   Michael Richardson, Sandelman Software Works        |    IoT architect =
  [
]     [email protected]  http://www.sandelman.ca/        |   ruby on rails  =
  [






=2D-
Michael Richardson <[email protected]>   . o O ( IPv6 I=C3=B8T consulti=
ng )
           Sandelman Software Works Inc, Ottawa and Worldwide





--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmk8giUACgkQgItw+93Q
3WWwBwf/T3QfSFsbFX8C6NHpvMLd6pWL2rN9Md7IJr6fYlOWH1OlkyU/vRkV4orB
8PXByonQ46C1T4x1n7PM/tRrL/XjYX/v0aIlb2G6lBI9687+XeN+fCxjZ9LSUmyC
bKpkMrg8bOIRxpeR63x6HztdmXpWZwn2qmZ3RYvnvugtr1X3wNfsh6N3HsyOqk8s
p2eNgtysKS0IoBjIXVFKBntQpAKLcI/SXZd7gM7kJ/PoM+g8FSsszKsYcSsya8x7
q87jUMROVFeaQyljCXrpfJuzv0+Ac+8+iRuKmBePrWpWyqFr5ltFp99ETlcuAcBd
/foyBI1+/GnSEk+DaaCxut950ppnPQ==
=i90b
-----END PGP SIGNATURE-----
--=-=-=--


--===============8569273284410707692==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kc3ByaW5nIG1h
aWxpbmcgbGlzdCAtLSBzcHJpbmdAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFp
bCB0byBzcHJpbmctbGVhdmVAaWV0Zi5vcmcK

--===============8569273284410707692==--