Re: [dhcwg] New Version Notification for draft-dhcwg-dhc-rfc8415bis-00.txt

[Michael Richardson <[e-mail]>]

I used:
  https://author-tools.ietf.org/diff?doc_1=rfc8415&doc_2=draft-dhcwg-dhc-rfc8415bis-00

90% of the changes are, alas, gratuitous format changes.

Bernie asks:
> Should we remove all text related to even checking for unicast
> transmissions and even deprecate the UseMulticast status code. I think the
> only case that can end up with unicast at a 8415bis server would be if the
> server had been sending Server-Unicast option and is then upgraded as
> existing (pre8415bis clients) may then unicast … but likely if the upgraded
> server just accepted the message, there would not really be any harm. A
> 8415bis client that always multicasts should never run into problems (and
> thus get the UseMulticast status). The 8415bis server would never need to
> check if unicast.

which corresponds to text:

      Once the client has determined the address of a server, it may, under
      some circumstances, send messages directly to the server using
      unicast.

And I think this is significant, and I'd like to understand why we should
consider this change at Internet Standard step.  Does it simplify something
or solve some problem?

I guess maybe:

 	   Use of unicast may avoid delays due to the relaying of messages by
 	   relay agents, as well as avoid overhead on servers due to the
 	   delivery of client messages to multiple servers.  However, requiring
 	   the client to relay all DHCP messages through a relay agent enables
 	   the inclusion of relay agent options in all messages sent by the
 	   client.  **The server should enable the use of unicast only when relay
 	   agent options will not be used**

is the point.

(My server implementation never cared, as it was for a PPPoE DSLAM, and there
were only two nodes on the PPP link)



--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide