Subject: Re: [dhcwg] dhcwg Digest, Vol 91, Issue 7

From: Ericric Jose Benitez Centeno <[email-masked]>
Date: Wed, 9 Nov 2011 09:06:47 -0800 (PST)

[email-masked] 
Eric Benitez

&gt;________________________________
&gt;From: &quot;[email-masked]&quot; &lt;[email-masked]&gt;
&gt;To: [email-masked]
&gt;Sent: Wednesday, November 9, 2011 12:05 PM
&gt;Subject: dhcwg Digest, Vol 91, Issue 7
&gt;
&gt;If you have received this digest without all the individual message
&gt;attachments you will need to update your digest options in your list
&gt;subscription.  To do so, go to 
&gt;
&gt;https://www.ietf.org/mailman/listinfo/dhcwg
&gt;
&gt;Click the &#39;Unsubscribe or edit options&#39; button, log in, and set &quot;Get
&gt;MIME or Plain Text Digests?&quot; to MIME.  You can set this option
&gt;globally for all the list digests you receive at this point.
&gt;
&gt;
&gt;
&gt;Send dhcwg mailing list submissions to
&gt;    [email-masked]
&gt;
&gt;To subscribe or unsubscribe via the World Wide Web, visit
&gt;    https://www.ietf.org/mailman/listinfo/dhcwg
&gt;or, via email, send a message with subject or body &#39;help&#39; to
&gt;    [email-masked]
&gt;
&gt;You can reach the person managing the list at
&gt;    [email-masked]
&gt;
&gt;When replying, please edit your Subject line so it is more specific
&gt;than &quot;Re: Contents of dhcwg digest...&quot;
&gt;
&gt;
&gt;Today&#39;s Topics:
&gt;
&gt;   1. Re: Proposed change to MAX_SOL_RT (Ralph Droms)
&gt;   2. Re: Proposed change to MAX_SOL_RT (Ole Troan)
&gt;   3. Re: Proposed change to MAX_SOL_RT (Ralph Droms)
&gt;   4. reviews of draft-ietf-6man-addr-select-opt-01 (Arifumi Matsumoto)
&gt;   5. Re: dhc-dhcpv6-redundancy-consider-02 draft (post WGLC)
&gt;      (VithalPrasad Gaitonde)
&gt;   6. Re: dhc-dhcpv6-redundancy-consider-02 draft (post WGLC)
&gt;      (Marcus Goller)
&gt;
&gt;
&gt;----------------------------------------------------------------------
&gt;
&gt;Message: 1
&gt;Date: Tue, 8 Nov 2011 15:22:02 -0500
&gt;From: Ralph Droms &lt;[email-masked]&gt;
&gt;To: &quot;[email-masked] WG&quot; &lt;[email-masked]&gt;
&gt;Subject: Re: [dhcwg] Proposed change to MAX_SOL_RT
&gt;Message-ID: &lt;[email-masked]&gt;
&gt;Content-Type: text/plain; charset=us-ascii
&gt;
&gt;Followup to previous message about changing MAX_SOL_RT...
&gt;
&gt;On Nov 4, 2011, at 7:33 AM 11/4/11, Ralph Droms wrote:
&gt;&gt; 
&gt;&gt; 2. In a scenario in which the DHCPv6 service is unresponsive for SOL_MAX_RT and the DHCPv6 clients are all now sending a Solicit every SOL_MAX_RT, the average wait time for those clients to complete the DHCPv6 message exchange after the DHCPv6 service comes back up will be MAX_SOL_RT/2.  Is that situation acceptable or should we define some other trigger through which the DHCPv6 clients can be signaled explicitly to restart the Solicit transmission algorithm in section 17.1.2 of RFC 3315.  My personal opinion is that an additional trigger is unnecessary.
&gt;
&gt;In support of my opinion, I came up with the following analysis of the likelihood of a client getting to the long-term MAX_SOL_RT interval state. 
&gt;
&gt;If the CM and CE router have been up and running, with the CE configured through DHCPv6, a WAN link flap will have no effect on DHCPv6 unless the link is down past the address/PD lease expiration...and in this case, the CE router will lose connectivity regardless.
&gt;
&gt;If the CE router comes up without a valid address/PD lease before the DHCPv6 service is running, the CE router will get to the long-term state of waiting on average MAX_SOL_RT/2 only if the DHCPv6 service is down longer than MAX_SOL_RT/2.  Note that this situation will only occur if the CE router is coming up for the first time or coming up after its address/PD lease has expired.
&gt;
&gt;So, a DHCPv6 client can get to that long-term state sending a Solicit every MAX_SOL_RT interval, but I don&#39;t think it&#39;s very likely.
&gt;
&gt;Discussion welcome and encouraged.
&gt;
&gt;- Ralph
&gt;
&gt;
&gt;
&gt;------------------------------
&gt;
&gt;Message: 2
&gt;Date: Tue, 8 Nov 2011 21:39:58 +0100
&gt;From: Ole Troan &lt;[email-masked]&gt;
&gt;To: Ralph Droms &lt;[email-masked]&gt;
&gt;Cc: &quot;[email-masked] WG&quot; &lt;[email-masked]&gt;
&gt;Subject: Re: [dhcwg] Proposed change to MAX_SOL_RT
&gt;Message-ID: &lt;[email-masked]&gt;
&gt;Content-Type: text/plain; charset=us-ascii
&gt;
&gt;Ralph,
&gt;
&gt;before we jump to conclusions and change the spec, I would very much like to understand this better.
&gt;the issue here is a DHCP server receiving SOLICITS from clients that it is unwilling to serve, right?
&gt;and that all solicits are going to be discarded, not replied to and created a binding for.
&gt;
&gt;assuming a million DHCPv6 clients with a 120 second timeout that&#39;s ~8333 solicits/s.
&gt;can&#39;t a vanilla DHCP server implementation handle that? 
&gt;
&gt;if a solicit packet is 150 bytes, that&#39;s only a ~12Mbps datastream...
&gt;
&gt;cheers,
&gt;Ole
&gt;
&gt;
&gt;
&gt;On Nov 4, 2011, at 12:33 , Ralph Droms wrote:
&gt;
&gt;&gt; I&#39;ve asked the chairs for a short slot in the Taipei WG meeting to discuss draft-droms-dhc-dhcpv6-maxsolrt-update-00.  While the doc won&#39;t officially be published until I-D publication quiet period ends, the important text of the draft is only 2 paragraphs, so I&#39;m posting it now to encourage discussion prior to the WG meeting.
&gt;&gt; 
&gt;&gt; Here is text of the doc:
&gt;&gt; 
&gt;&gt; Abstract
&gt;&gt; 
&gt;&gt;  This document updates RFC 3315 by defining a new default value for
&gt;&gt;  SOL_MAX_RT.
&gt;&gt; 
&gt;&gt; 1.  Introduction
&gt;&gt; 
&gt;&gt;  Section 5.5 of the DHCP specification [RFC3315] defines the default
&gt;&gt;  value of MAX_SOL_RT to be 120 seconds.  In some circumstances, this
&gt;&gt;  default will lead to an unacceptably high volume of aggregated
&gt;&gt;  traffic at a DHCPv6 server.
&gt;&gt; 
&gt;&gt; 2.  Update to RC 3315
&gt;&gt; 
&gt;&gt;  This document changes section 5.5 of RFC 3315 as follows:
&gt;&gt; 
&gt;&gt;  OLD:
&gt;&gt;     SOL_MAX_RT      120 secs  Max Solicit timeout value
&gt;&gt; 
&gt;&gt;  NEW:
&gt;&gt;     SOL_MAX_RT     3600 secs  Max Solicit timeout value
&gt;&gt; 
&gt;&gt;  With this change, a DHCPv6 client that does not receive a
&gt;&gt;  satisfactory response will send Solicit messages with the same
&gt;&gt;  initial frequency and exponential backoff as specified in RFC 3315.
&gt;&gt;  However, the long term behavior of these DHCPv6 clients will be to
&gt;&gt;  send a Solicit message every 3600 seconds rather than every 120
&gt;&gt;  seconds, significantly reducing the aggregated traffic at the DHCPv6
&gt;&gt;  server.
&gt;&gt; 
&gt;&gt;  The change to MAX_SOL_RT is in response to DHCPv6 message rates
&gt;&gt;  observed at a DHCPv6 server in a deployment in which many DHCPv6
&gt;&gt;  clients are sending Solicit messages but the DHCPv6 server has been
&gt;&gt;  configured not to respond to those Solicit messages.  RFC 3315 was
&gt;&gt;  written with the expectation that the &#39;M&#39; and &#39;O&#39; flags in NDP
&gt;&gt;  [RFC2461] would control the use of DHCPv6 by hosts.  However, the
&gt;&gt;  current definition of the &#39;M&#39; and &#39;O&#39; flags in RFC 4861 [RFC4861]
&gt;&gt;  does not explicitly preclude the use of DHCPv6 by a host.  Some
&gt;&gt;  devices will initiate DHCPv6 even if RAs are received with the &#39;M&#39;
&gt;&gt;  and &#39;O&#39; bits set to 0.  In some circumstances, it is desirable to
&gt;&gt;  enable the assignment of IPv6 addresses through DHCPv6 to some
&gt;&gt;  nodes on a link but not to others, which cannot be implemented
&gt;&gt;  through the &#39;M&#39; and &#39;O&#39; bits.
&gt;&gt; 
&gt;&gt; Two issues to consider:
&gt;&gt; 
&gt;&gt; 1. Is 3600 seconds the right number?  How about 7200 seconds?
&gt;&gt; 
&gt;&gt; 2. In a scenario in which the DHCPv6 service is unresponsive for SOL_MAX_RT and the DHCPv6 clients are all now sending a Solicit every SOL_MAX_RT, the average wait time for those clients to complete the DHCPv6 message exchange after the DHCPv6 service comes back up will be MAX_SOL_RT/2.  Is that situation acceptable or should we define some other trigger through which the DHCPv6 clients can be signaled explicitly to restart the Solicit transmission algorithm in section 17.1.2 of RFC 3315.  My personal opinion is that an additional trigger is unnecessary.
&gt;&gt; 
&gt;&gt; - Ralph
&gt;&gt; 
&gt;&gt; _______________________________________________
&gt;&gt; dhcwg mailing list
&gt;&gt; [email-masked]
&gt;&gt; https://www.ietf.org/mailman/listinfo/dhcwg
&gt;
&gt;
&gt;
&gt;------------------------------
&gt;
&gt;Message: 3
&gt;Date: Tue, 8 Nov 2011 15:54:02 -0500
&gt;From: Ralph Droms &lt;[email-masked]&gt;
&gt;To: Ole Troan &lt;[email-masked]&gt;
&gt;Cc: &quot;[email-masked] WG&quot; &lt;[email-masked]&gt;
&gt;Subject: Re: [dhcwg] Proposed change to MAX_SOL_RT
&gt;Message-ID: &lt;[email-masked]&gt;
&gt;Content-Type: text/plain; charset=us-ascii
&gt;
&gt;
&gt;On Nov 8, 2011, at 3:39 PM 11/8/11, Ole Troan wrote:
&gt;
&gt;&gt; Ralph,
&gt;&gt; 
&gt;&gt; before we jump to conclusions and change the spec, I would very much like to understand this better.
&gt;&gt; the issue here is a DHCP server receiving SOLICITS from clients that it is unwilling to serve, right?
&gt;&gt; and that all solicits are going to be discarded, not replied to and created a binding for.
&gt;
&gt;Right.
&gt;
&gt;&gt; assuming a million DHCPv6 clients with a 120 second timeout that&#39;s ~8333 solicits/s.
&gt;&gt; can&#39;t a vanilla DHCP server implementation handle that? 
&gt;
&gt;On the other hand, that stream of Solicits may represent a 100x increase over the level of traffic in the steady state.
&gt;
&gt;- Ralph
&gt;
&gt;&gt; if a solicit packet is 150 bytes, that&#39;s only a ~12Mbps datastream...
&gt;&gt; 
&gt;&gt; cheers,
&gt;&gt; Ole
&gt;&gt; 
&gt;&gt; 
&gt;&gt; 
&gt;&gt; On Nov 4, 2011, at 12:33 , Ralph Droms wrote:
&gt;&gt; 
&gt;&gt;&gt; I&#39;ve asked the chairs for a short slot in the Taipei WG meeting to discuss draft-droms-dhc-dhcpv6-maxsolrt-update-00.  While the doc won&#39;t officially be published until I-D publication quiet period ends, the important text of the draft is only 2 paragraphs, so I&#39;m posting it now to encourage discussion prior to the WG meeting.
&gt;&gt;&gt; 
&gt;&gt;&gt; Here is text of the doc:
&gt;&gt;&gt; 
&gt;&gt;&gt; Abstract
&gt;&gt;&gt; 
&gt;&gt;&gt; This document updates RFC 3315 by defining a new default value for
&gt;&gt;&gt; SOL_MAX_RT.
&gt;&gt;&gt; 
&gt;&gt;&gt; 1.  Introduction
&gt;&gt;&gt; 
&gt;&gt;&gt; Section 5.5 of the DHCP specification [RFC3315] defines the default
&gt;&gt;&gt; value of MAX_SOL_RT to be 120 seconds.  In some circumstances, this
&gt;&gt;&gt; default will lead to an unacceptably high volume of aggregated
&gt;&gt;&gt; traffic at a DHCPv6 server.
&gt;&gt;&gt; 
&gt;&gt;&gt; 2.  Update to RC 3315
&gt;&gt;&gt; 
&gt;&gt;&gt; This document changes section 5.5 of RFC 3315 as follows:
&gt;&gt;&gt; 
&gt;&gt;&gt; OLD:
&gt;&gt;&gt;    SOL_MAX_RT      120 secs  Max Solicit timeout value
&gt;&gt;&gt; 
&gt;&gt;&gt; NEW:
&gt;&gt;&gt;    SOL_MAX_RT     3600 secs  Max Solicit timeout value
&gt;&gt;&gt; 
&gt;&gt;&gt; With this change, a DHCPv6 client that does not receive a
&gt;&gt;&gt; satisfactory response will send Solicit messages with the same
&gt;&gt;&gt; initial frequency and exponential backoff as specified in RFC 3315.
&gt;&gt;&gt; However, the long term behavior of these DHCPv6 clients will be to
&gt;&gt;&gt; send a Solicit message every 3600 seconds rather than every 120
&gt;&gt;&gt; seconds, significantly reducing the aggregated traffic at the DHCPv6
&gt;&gt;&gt; server.
&gt;&gt;&gt; 
&gt;&gt;&gt; The change to MAX_SOL_RT is in response to DHCPv6 message rates
&gt;&gt;&gt; observed at a DHCPv6 server in a deployment in which many DHCPv6
&gt;&gt;&gt; clients are sending Solicit messages but the DHCPv6 server has been
&gt;&gt;&gt; configured not to respond to those Solicit messages.  RFC 3315 was
&gt;&gt;&gt; written with the expectation that the &#39;M&#39; and &#39;O&#39; flags in NDP
&gt;&gt;&gt; [RFC2461] would control the use of DHCPv6 by hosts.  However, the
&gt;&gt;&gt; current definition of the &#39;M&#39; and &#39;O&#39; flags in RFC 4861 [RFC4861]
&gt;&gt;&gt; does not explicitly preclude the use of DHCPv6 by a host.  Some
&gt;&gt;&gt; devices will initiate DHCPv6 even if RAs are received with the &#39;M&#39;
&gt;&gt;&gt; and &#39;O&#39; bits set to 0.  In some circumstances, it is desirable to
&gt;&gt;&gt; enable the assignment of IPv6 addresses through DHCPv6 to some
&gt;&gt;&gt; nodes on a link but not to others, which cannot be implemented
&gt;&gt;&gt; through the &#39;M&#39; and &#39;O&#39; bits.
&gt;&gt;&gt; 
&gt;&gt;&gt; Two issues to consider:
&gt;&gt;&gt; 
&gt;&gt;&gt; 1. Is 3600 seconds the right number?  How about 7200 seconds?
&gt;&gt;&gt; 
&gt;&gt;&gt; 2. In a scenario in which the DHCPv6 service is unresponsive for SOL_MAX_RT and the DHCPv6 clients are all now sending a Solicit every SOL_MAX_RT, the average wait time for those clients to complete the DHCPv6 message exchange after the DHCPv6 service comes back up will be MAX_SOL_RT/2.  Is that situation acceptable or should we define some other trigger through which the DHCPv6 clients can be signaled explicitly to restart the Solicit transmission algorithm in section 17.1.2 of RFC 3315.  My personal opinion is that an additional trigger is unnecessary.
&gt;&gt;&gt; 
&gt;&gt;&gt; - Ralph
&gt;&gt;&gt; 
&gt;&gt;&gt; _______________________________________________
&gt;&gt;&gt; dhcwg mailing list
&gt;&gt;&gt; [email-masked]
&gt;&gt;&gt; https://www.ietf.org/mailman/listinfo/dhcwg
&gt;&gt; 
&gt;
&gt;
&gt;
&gt;------------------------------
&gt;
&gt;Message: 4
&gt;Date: Wed, 9 Nov 2011 17:21:00 +0900
&gt;From: Arifumi Matsumoto &lt;[email-masked]&gt;
&gt;To: &quot;[email-masked] WG&quot; &lt;[email-masked]&gt;
&gt;Subject: [dhcwg] reviews of draft-ietf-6man-addr-select-opt-01
&gt;Message-ID: &lt;[email-masked]&gt;
&gt;Content-Type: text/plain; charset=us-ascii
&gt;
&gt;All,
&gt;
&gt;at Quebec, Tim Chown presented about address selection documents
&gt;discussed in 6man WG, and requested reviewers for the draft
&gt;draft-ietf-6man-addr-select-opt-01.
&gt;slides are http://tools.ietf.org/agenda/81/slides/dhc-13.pdf
&gt;
&gt;IIRC, one reviewer was chosen at that time, and the other was left
&gt;undecided.
&gt;
&gt;So, my questions are
&gt;the review was submitted somewhere ?
&gt;the other reviewer was chosen ?
&gt;
&gt;--
&gt;Arifumi Matsumoto
&gt;  NGN System Architecture Project
&gt;  NTT Service Integration Laboratories
&gt;  E-mail: [email-masked]
&gt;  TEL +81-422-59-3334 FAX +81-422-59-6364
&gt;
&gt;
&gt;
&gt;------------------------------
&gt;
&gt;Message: 5
&gt;Date: Wed, 9 Nov 2011 15:12:09 +0530
&gt;From: VithalPrasad Gaitonde &lt;[email-masked]&gt;
&gt;To: &quot;Brzozowski, John&quot; &lt;[email-masked]&gt;
&gt;Cc: dhc WG &lt;[email-masked]&gt;, Jack Chen &lt;[email-masked]&gt;,
&gt;    Jean-Francois Tremblay &lt;[email-masked]&gt;,    Ted
&gt;    Lemon &lt;[email-masked]&gt;
&gt;Subject: Re: [dhcwg] dhc-dhcpv6-redundancy-consider-02 draft (post
&gt;    WGLC)
&gt;Message-ID:
&gt;    &lt;CAAfac2jqr5UcBAFm0uwy_qvs=[email-masked]&gt;
&gt;Content-Type: text/plain; charset=&quot;iso-8859-1&quot;
&gt;
&gt;The documentation of these redundancy approaches serves as a useful
&gt;guidance.
&gt;Support this document.
&gt;
&gt;Thanks,
&gt;Prasad
&gt;
&gt;On Tue, Nov 8, 2011 at 9:41 PM, Brzozowski, John &lt;
&gt;[email-masked]&gt; wrote:
&gt;
&gt;&gt; I support this as well, from what we have heard this is useful information.
&gt;&gt;
&gt;&gt; John
&gt;&gt; =========================================
&gt;&gt; John Jason Brzozowski
&gt;&gt; Comcast Cable
&gt;&gt; e) mailto:[email-masked]
&gt;&gt; o) 609-377-6594
&gt;&gt; m) 484-962-0060
&gt;&gt; w) http://www.comcast6.net
&gt;&gt; =========================================
&gt;&gt;
&gt;&gt;
&gt;&gt;
&gt;&gt;
&gt;&gt; On 11/8/11 10:13 AM, &quot;Tomek Mrugalski&quot; &lt;[email-masked]&gt; wrote:
&gt;&gt;
&gt;&gt; &gt;On 08.11.2011 13:02, Ted Lemon wrote:
&gt;&gt; &gt;&gt; On Oct 17, 2011, at 11:11 AM, &quot;Tomasz Mrugalski&quot;
&gt;&gt; &gt;&gt; &lt;[email-masked]&gt; wrote:
&gt;&gt; &gt;&gt;&gt; This draft seem to successfully pass WGLC
&gt;&gt; &gt;&gt;&gt; (http://www.ietf.org/mail-archive/web/dhcwg/current/msg11930.html).
&gt;&gt; &gt;&gt;
&gt;&gt; &gt;&gt;&gt;
&gt;&gt; &gt;&gt; Only one person actually expressed support for this document, so in
&gt;&gt; &gt;&gt; fact it did not pass WGLC. however there were a number of comments,
&gt;&gt; &gt;&gt; so I presume there actually is support.  Cpuld those who want this to
&gt;&gt; &gt;&gt; be published please formally indicate that they do?
&gt;&gt; &gt;I support this draft. As I&#39;m co-author, it probably doesn&#39;t count.
&gt;&gt; &gt;
&gt;&gt; &gt;Tomek
&gt;&gt;
&gt;&gt; _______________________________________________
&gt;&gt; dhcwg mailing list
&gt;&gt; [email-masked]
&gt;&gt; https://www.ietf.org/mailman/listinfo/dhcwg
&gt;&gt;
&gt;-------------- next part --------------
&gt;An HTML attachment was scrubbed...
&gt;URL: &lt;http://www.ietf.org/mail-archive/web/dhcwg/attachments/20111109/f182bec5/attachment.htm&gt;
&gt;
&gt;------------------------------
&gt;
&gt;Message: 6
&gt;Date: Wed, 9 Nov 2011 16:05:33 +0100
&gt;From: Marcus Goller &lt;[email-masked]&gt;
&gt;To: dhc WG &lt;[email-masked]&gt;
&gt;Cc: Jack Chen &lt;[email-masked]&gt;,    Jean-Francois Tremblay
&gt;    &lt;[email-masked]&gt;,    Ted Lemon
&gt;    &lt;[email-masked]&gt;
&gt;Subject: Re: [dhcwg] dhc-dhcpv6-redundancy-consider-02 draft (post
&gt;    WGLC)
&gt;Message-ID:
&gt;    &lt;CAMdbJyKP+vh1ZL-F-1avTUxv+sBMDNiEPnF4AStp=n=[email-masked]&gt;
&gt;Content-Type: text/plain; charset=ISO-8859-1
&gt;
&gt;I also think this very useful to have.
&gt;
&gt;Marcus
&gt;
&gt;On Wed, Nov 9, 2011 at 10:42 AM, VithalPrasad Gaitonde
&gt;&lt;[email-masked]&gt; wrote:
&gt;&gt; The documentation of these redundancy approaches serves as a useful
&gt;&gt; guidance.
&gt;&gt; Support this document.
&gt;&gt;
&gt;&gt; Thanks,
&gt;&gt; Prasad
&gt;&gt;
&gt;&gt; On Tue, Nov 8, 2011 at 9:41 PM, Brzozowski, John
&gt;&gt; &lt;[email-masked]&gt; wrote:
&gt;&gt;&gt;
&gt;&gt;&gt; I support this as well, from what we have heard this is useful
&gt;&gt;&gt; information.
&gt;&gt;&gt;
&gt;&gt;&gt; John
&gt;&gt;&gt; =========================================
&gt;&gt;&gt; John Jason Brzozowski
&gt;&gt;&gt; Comcast Cable
&gt;&gt;&gt; e) mailto:[email-masked]
&gt;&gt;&gt; o) 609-377-6594
&gt;&gt;&gt; m) 484-962-0060
&gt;&gt;&gt; w) http://www.comcast6.net
&gt;&gt;&gt; =========================================
&gt;&gt;&gt;
&gt;&gt;&gt;
&gt;&gt;&gt;
&gt;&gt;&gt;
&gt;&gt;&gt; On 11/8/11 10:13 AM, &quot;Tomek Mrugalski&quot; &lt;[email-masked]&gt; wrote:
&gt;&gt;&gt;
&gt;&gt;&gt; &gt;On 08.11.2011 13:02, Ted Lemon wrote:
&gt;&gt;&gt; &gt;&gt; On Oct 17, 2011, at 11:11 AM, &quot;Tomasz Mrugalski&quot;
&gt;&gt;&gt; &gt;&gt; &lt;[email-masked]&gt; wrote:
&gt;&gt;&gt; &gt;&gt;&gt; This draft seem to successfully pass WGLC
&gt;&gt;&gt; &gt;&gt;&gt; (http://www.ietf.org/mail-archive/web/dhcwg/current/msg11930.html).
&gt;&gt;&gt; &gt;&gt;
&gt;&gt;&gt; &gt;&gt;&gt;
&gt;&gt;&gt; &gt;&gt; Only one person actually expressed support for this document, so in
&gt;&gt;&gt; &gt;&gt; fact it did not pass WGLC. however there were a number of comments,
&gt;&gt;&gt; &gt;&gt; so I presume there actually is support. ?Cpuld those who want this to
&gt;&gt;&gt; &gt;&gt; be published please formally indicate that they do?
&gt;&gt;&gt; &gt;I support this draft. As I&#39;m co-author, it probably doesn&#39;t count.
&gt;&gt;&gt; &gt;
&gt;&gt;&gt; &gt;Tomek
&gt;&gt;&gt;
&gt;&gt;&gt; _______________________________________________
&gt;&gt;&gt; dhcwg mailing list
&gt;&gt;&gt; [email-masked]
&gt;&gt;&gt; https://www.ietf.org/mailman/listinfo/dhcwg
&gt;&gt;
&gt;&gt;
&gt;&gt; _______________________________________________
&gt;&gt; dhcwg mailing list
&gt;&gt; [email-masked]
&gt;&gt; https://www.ietf.org/mailman/listinfo/dhcwg
&gt;&gt;
&gt;&gt;
&gt;
&gt;
&gt;------------------------------
&gt;
&gt;_______________________________________________
&gt;dhcwg mailing list
&gt;[email-masked]
&gt;https://www.ietf.org/mailman/listinfo/dhcwg
&gt;
&gt;
&gt;End of dhcwg Digest, Vol 91, Issue 7
&gt;************************************
&gt;
&gt;
&gt;