http://blog.gmane.org/gmane.ietf.dhc hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.dhc/12837 <pre>Hello, What is the correct source IP address for a DHCPREQUEST generated during REBINDING state? Should it be the unicast IP, or 0.0.0.0? I'm not quite clear on this after combing through RFC 2131 .. any pointers would be appreciated. RFC 2131 4.3.2 DHCPREQUEST message DHCPREQUEST generated during REBINDING state This message MUST be broadcast to the 0xffffffff IP broadcast address. </pre> SPHICAS, PHIL G 2013-05-17T15:55:51 http://comments.gmane.org/gmane.ietf.dhc/12833 <pre>Hi, I was just looking through this draft again and one thing that I noticed is that the RFC4361 compliant behaviour is only mandated for clients. There is no mention of compliance for the server. Surely, it's needed for both? Cheers, Ian _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg </pre> ian.farrer< at >telekom.de 2013-05-16T17:16:10 http://comments.gmane.org/gmane.ietf.dhc/12817 <pre>Does RFC 3315 mandate that DHCPv6 server should echo back all options in the client request message in its response even if the server does not support a specific option. For example, if the client message contains vendor-specific information option (section 22.17 rfc 3315), does the server need to echo back the same option in its response even if does not support that option. Thanks, Prasad _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg </pre> gvithal . 2013-05-15T13:00:24 http://comments.gmane.org/gmane.ietf.dhc/12810 <pre>Hi: This is an updated version of this document. It includes a few minor changes from the WG last call and is there mostly to restore this document as it has expired a few days ago. I still have a bunch of the comments from the WG Last Call in January/February to address. There is also one key issue that will need some discussion from the WG. In particular, handling of Rebind requests. One major flaw with respect to the Rebind message handling in RFC 3315 and this draft is that as the client has sent the Rebind to multiple servers, all of which could respond, there is no way for a particular server to know whether its Reply will be accepted by the client. This is essentially the same issue with using Rapid Commit in a Solicit when there are multiple servers available. I think the Rebind processing should essentially be changed so that a server will either return everything the client requested to be rebound (and nothing more) or nothing (in which case it returns NoBinding status for all bindings). If the server is willing to extend (or grant) the existing leases, the Rebind is fine. If the server is unwilling or unable, then it should force the client back into a Request phase as described in RFC 3315 section 18.1.8. That 18.1.8 section is also the only place a NoBinding status appears to be mentioned in terms of the Rebind. - Bernie _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg </pre> Bernie Volz (volz 2013-05-13T18:04:17 http://comments.gmane.org/gmane.ietf.dhc/12809 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Issues with multiple stateful DHCPv6 options Author(s) : Ole Troan Bernie Volz Filename : draft-ietf-dhc-dhcpv6-stateful-issues-04.txt Pages : 10 Date : 2013-05-13 Abstract: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written with the expectation that additional stateful DHCPv6 options would be developed. IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 shoe-horned the new options for Prefix Delegation into DHCPv6. Implementation experience of the CPE model described in [RFC6204] has shown multiple issues with the DHCPv6 protocol in supporting multiple stateful options. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-stateful-issues There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-stateful-issues-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ </pre> internet-drafts< at >ietf.org 2013-05-13T17:55:48 http://comments.gmane.org/gmane.ietf.dhc/12808 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Provisioning IPv4 Configuration Over IPv6 Only Networks Author(s) : Branimir Rajtar Ian Farrer Filename : draft-ietf-dhc-v4configuration-00.txt Pages : 13 Date : 2013-05-13 Abstract: As IPv6 becomes more widely adopted, some service providers are taking the approach of deploying IPv6 only networks, without dual- stack functionality for IPv4. However, access to IPv4 based services is still an ongoing requirement and approaches such as IPv4-in-IPv6 softwire tunnels are being developed to meet this need. In order to provision end-user's hosts with the necessary IPv4 configuration, a number of different mechanisms have been proposed. This memo discusses the benefits and drawbacks of each, with the aim of recommending a single approach as the basis for future work. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-v4configuration There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-v4configuration-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ </pre> internet-drafts< at >ietf.org 2013-05-13T08:39:17 http://comments.gmane.org/gmane.ietf.dhc/12802 <pre>The following errata report has been submitted for RFC6656, "Description of Cisco Systems' Subnet Allocation Option for DHCPv4". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6656&amp;eid=3617 -------------------------------------- Type: Technical Reported by: Dushyant Raghuvanshi &lt;draghuva&lt; at &gt;cisco.com&gt; Section: 3.2 Original Text ------------- Len = Length of the suboption (min. length of 8) (1 octet) Corrected Text -------------- Len = Length of the suboption (min. length of 1) (1 octet) Notes ----- RFC 6656 suggests that a DHCP Client MAY request list of previously allocated subnets from the DHCP Server in case of recovering from a restart if the Client does not have local storage in order to retain the information itself. But there will be cases when Server does not have any information to send back (this could be a new Client or this Client never spoke to this Server before). In this case, DHCP Server may decide to remain silent and discard the request. This approach will make it difficult for DHCP Client to decide if request could not reach to Server or Server did not have any information to send back. A possible approach could be to send the OFFER back to Client with Subnet-Information Suboption (without Subnet Prefix Information Block) in it. So that Client can proceed by making a request to allocate new subnets. This would require to reduce the minimum length of Subnet-Information Suboption to 1 (just include flags). Section 6 would require to be updated as well t o reflect the new behavior (to respond). Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6656 (draft-ietf-dhc-subnet-alloc-13) -------------------------------------- Title : Description of Cisco Systems' Subnet Allocation Option for DHCPv4 Publication Date : July 2012 Author(s) : R. Johnson, K. Kinnear, M. Stapp Category : INFORMATIONAL Source : Dynamic Host Configuration Area : Internet Stream : IETF Verifying Party : IESG </pre> RFC Errata System 2013-05-09T04:16:39 http://comments.gmane.org/gmane.ietf.dhc/12785 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Reconfigure Triggered by DHCPv6 Relay Agents Author(s) : Mohamed Boucadair Xavier Pougnard Filename : draft-ietf-dhc-triggered-reconfigure-06.txt Pages : 13 Date : 2013-05-06 Abstract: This document defines new DHCPv6 messages: Reconfigure-Request and Reconfigure-Reply. Reconfigure-Request message is sent by a DHCPv6 relay agent to notify a DHCPv6 server about a configuration information change, so that the DHCPv6 server can send a Reconfigure message accordingly. Reconfigure-Reply message is used by the server to acknowledge the receipt of Reconfigure-Request. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-triggered-reconfigure There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-triggered-reconfigure-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-triggered-reconfigure-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ </pre> internet-drafts< at >ietf.org 2013-05-06T07:55:57 http://comments.gmane.org/gmane.ietf.dhc/12783 <pre>Hi: Some comments on the 01 draft: - In 1. Introduction: Several approaches for provisioning such information have been already been proposed. This document describes one such approach Is this really worth adding? Especially without providing references? Also, if we are to abandon those other approaches, why would we want the RFC (assuming this becomes one) to confuse people into thinking they may have alternatives? - In 3. Terminology This seems an odd section title to define new messages? Could this not just be "New Messages" or something like that? It may also make sense to move this to after current section 4? I also think it would be best to clearly indicate that these messages are formatted as show in Section6 of RFC 3315 (yes, that may be obvious to us, but best to be explicit). This would also mean you could remove the "A new type of ..." in the definition. And, "Each BOOTP Message Option" makes it appear there could be more than one in a message, which is not something I think we want. So, how about: 3. New DHCPv6 Messages The following new DHCPv6 Client/Server messages are defined by this document. These are formatted as specified in Section 6 of [RFC 3315]. BOOTREQUESTV6 (TBD): A client sends a BOOTREQUESTV6 message to a server, which contains a BOOTP Message Option. The BOOTP Message Option contains a BOOTREQUEST message that the client uses to request IPv4 configuration parameters from the server. BOOTREPLYV6 (TBD): A server sends a BOOTREPLYV6 message containing a BOOTP Message Option in response to a client's BOOTREQUESTV6 message. The BOOTP Message Option contains a BOOTREPLY message in response to a BOOTREQUEST received by the server in the BOOTP Message Option of a BOOTREQUESTV6 message. </pre> Bernie Volz (volz 2013-05-02T17:24:22 http://comments.gmane.org/gmane.ietf.dhc/12767 <pre>Hi: Just a reminder that we have the following WGLCs outstanding: * draft-ietf-dhc-option-guidelines-11 - ends 2013-04-24 (extended a few days per AD request - now ends 2013-04-30) * draft-ietf-dhc-dhcpv6-radius-opt-11 - ends 2013-05-02 (2nd WGLC because of late IPR) And the following WG Adoption Calls (to adopt the draft as WG item) outstanding: * draft-bhandari-dhc-access-network-identifier-04 - ends 2013-05-02 * draft-lemon-dhc-topo-conf-01 - ends 2013-05-02 * draft-rajtar-dhc-v4configuration-02 - ends 2013-05-08 Please comment! Your input to the WG is important!! - Tomek &amp; Bernie _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg </pre> Bernie Volz (volz 2013-04-29T01:13:29 http://comments.gmane.org/gmane.ietf.dhc/12764 <pre>Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg </pre> johnsonhammond2< at >hushmail.com 2013-04-27T17:08:46 http://comments.gmane.org/gmane.ietf.dhc/12760 <pre>I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at &lt;http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq&gt;. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dhc-triggered-reconfigure-05 Reviewer: Robert Sparks Review Date: April 26, 2013 IETF LC End Date: May 6, 2013 IESG Telechat date: May 16, 2013 Summary: This draft is on the right track but has open issues, described in the review. Major issues: Overall, this document is solid, but I think there is a bug in section 6.3. I could be wrong, but If I'm right, this paragraph: When retransmission is required, the relay may decide to correct the content of RECONFIGURE-REQUEST message it issues (e.g., update the Client Identifier list). This decision is local to the relay (e.g., it may be based on observed events such as one or more clients were reconfigured on their own). introduces a race-condition that could lead to an erroneous state. If a relay's first message included client A, then the retransmission included clients A and B, but that retransmission crosses with a success RECONFIGURE-REPLY to the request that only included client A, the relay will think it succeeded in asking A and B to be reconfigured. Minor issues: This sentence: Furthermore, means to recover state in failure events must be supported, but are not discussed in this document. places a requirement on a relay (even though it's not using a 2119 MUST). Is there some other document that defines this requirement that you can reference? If not, the requirement should be discussed in this document. Alternatively, you could change the sentence to talk about the consequences of not having a proprietary means for recovering state. Nits/editorial comments: _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg </pre> Robert Sparks 2013-04-26T15:42:09 http://comments.gmane.org/gmane.ietf.dhc/12758 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCPv4 over DHCPv6 Transport Author(s) : Qi Sun Yong Cui Marcin Siodelski Suresh Krishnan Ian Farrer Filename : draft-ietf-dhc-dhcpv4-over-dhcpv6-00.txt Pages : 9 Date : 2013-04-26 Abstract: This document describes a mechanism for obtaining IPv4 address and other parameters in IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-dhcpv6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ </pre> internet-drafts< at >ietf.org 2013-04-26T14:59:11 http://comments.gmane.org/gmane.ietf.dhc/12743 <pre>Hi, Just in case you missed it, a new version of draft-rajtar-dhc-v4configuration (02) was recently posted. As this version incorporates the new DCHPv4 over DHCPv6 model described in the recently adopted draft-scskf-dhcpv4-over-dhcpv6 and other changes based on the discussions in Orlando, the authors would like request that the WG chairs make a call for adoption based. Cheers, Ian _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg </pre> ian.farrer< at >telekom.de 2013-04-23T21:23:46 http://comments.gmane.org/gmane.ietf.dhc/12741 <pre>It came to my attention that the current mailing lists configuration did not allow the mail from IESG to go through. I have updated the list configuration, so this should not happen anymore. Although I'm manually re-sending this, I want to make clear that this mail came from IESG, not from me. This draft has passed WGLC couple weeks ago and is now in IETF wide LC. If you have any outstanding comments on it, this is the last time anyone will listen. So speak now or forever hold your peace. Tomek ----- Subject: Last Call: &lt;draft-ietf-dhc-triggered-reconfigure-05.txt&gt; (Reconfigure Triggered by DHCPv6 Relay Agents) to Proposed Standard From: The IESG &lt;noreply&lt; at &gt;ietf.org&gt; Date: 22.04.2013 16:15 To: IETF-Announce:; CC: &lt;dhcwg&lt; at &gt;ietf.org&gt; The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Reconfigure Triggered by DHCPv6 Relay Agents' &lt;draft-ietf-dhc-triggered-reconfigure-05.txt&gt; as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf&lt; at &gt;ietf.org mailing lists by 2013-05-06. Exceptionally, comments may be sent to iesg&lt; at &gt;ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines new DHCPv6 messages: Reconfigure-Request and Reconfigure-Reply. Reconfigure-Request message is sent by a DHCPv6 relay agent to notify a DHCPv6 server about a configuration information change, so that the DHCPv6 server can send a Reconfigure message accordingly. Reconfigure-Reply message is used by the server to acknowledge the receipt of Reconfigure-Request. This document updates RFC 3315 and RFC 6422. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-triggered-reconfigure/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-triggered-reconfigure/ballot/ No IPR declarations have been submitted directly on this I-D. </pre> Tomek Mrugalski 2013-04-23T11:37:17 http://comments.gmane.org/gmane.ietf.dhc/12716 <pre>Regular DHC working group members may be amused or perhaps disturbed to learn that I've posted yet another ops doc for the working group. This one documents how enterprises and ISPs can manage their network device inventory using bar codes on boxes, link-layer addresses, and DUIDs. It might be slightly more controversial than the topology document, because it actually proposes an update to RFC3315 to clarify the meaning of the text forbidding the DHCP server looking at the contents of DUIDs. This probably ought to be in a separate document, if the working group agrees that this is a good idea. Like the topo doc, this is being submitted with my AD hat off—the reason I've submitted so many documents lately is because I keep noticing situations where we all know something, but nobody else in the IETF knows it, and I think it's worth actually documenting this stuff. Let me know what you think! Thanks! http://tools.ietf.org/html/draft-lemon-dhc-inventory-00 </pre> Ted Lemon 2013-04-22T00:22:58 http://comments.gmane.org/gmane.ietf.dhc/12709 <pre>A reminder: Please note that the obligation to disclose IPR regarding an IETF document exists as soon as the author knows a patent application will be filed or intends to file for one, not at the time the patent is issued, and not at some later date when the company decides what sort of terms they want to ask for. If the patent is not granted, or a decision is made on licensing terms, the company can amend the IPR disclosure. And, here's a resend of an email I sent to the DHC WG Mailing List recently: The following is a good reminder about the IETF IPR policy that Kathleen Moriarty sent to the MILE WG in August 2012. I replaced MILE with DHC: Dear DHC WG: As DHC WG chairs, we would like to minimize or hopefully even eliminate late disclosures relating to documents under consideration within the DHC WG. Therefore you might see us send "reminder" messages in the future to authors or to the DHC WG email list as a whole, asking people whether they know of Intellectual Property Rights (IPR) relating to specific documents. In order to comply with IETF processes and avoid unnecessary delays, document authors and contributors to our discussions in the DHC WG are asked to pay careful attention to these messages and to reply in a timely fashion. Please note that these messages are only reminders of existing IETF policy, and we are all bound by that policy even in the absence of such reminder messages. Everyone who participates in the Internet Standards Process (whether by posting to IETF mailing lists, authoring documents, attending IETF meetings, or in other ways) needs to be aware of the IETF rules with regard to IPR. These rules are described in BCP79 and can be referenced through http://www.ietf.org/ipr/policy.html. In addition, online tools for filing IPR disclosures can be found at http://www.ietf.org/ipr/file-disclosure. Finally, existing disclosures can be searched online at https://datatracker.ietf.org/ipr/search/. Also note that these are personal requirements applying to all IETF participants as individuals, and that these requirements also apply to all participants in the DHC WG. Thanks, Bernie &amp; Tomek (DHC WG Co-chairs) _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg </pre> Bernie Volz (volz 2013-04-19T13:55:33 http://comments.gmane.org/gmane.ietf.dhc/12708 <pre>Hello: Because of a late IPR notice, we are re-issuing the WG Last Call for draft-ietf-dhc-dhcpv6-radius-opt-11. This last call will end May 2nd, 2013. However, as this document has already passed WG Last Call, for this Last Call we are primarily focused on whether the IPR notice changes your position as to whether the draft should advance. If you have no issues because of the IPR, you do not need to respond. If you do have concerns because of the IPR notice, please let the working group know. For details on the IPR notice, see https://datatracker.ietf.org/ipr/2052/. For the draft, see http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-radius-opt. I will also send a separate notice, but please note that the obligation to disclose IPR regarding an IETF document exists as soon as the author knows a patent application will be filed or intends to file for one, not at the time the patent is issued, and not at some later date when the company decides what sort of terms they want to ask for. If the patent is not granted, or a decision is made on licensing terms, the company can amend the IPR disclosure. These rules are described in BCP79 and can be referenced through http://www.ietf.org/ipr/policy.html. In addition, online tools for filing IPR disclosures can be found at http://www.ietf.org/ipr/file-disclosure. Finally, existing disclosures can be searched online at https://datatracker.ietf.org/ipr/search/. - Bernie &amp; Tomek _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg </pre> Bernie Volz (volz 2013-04-19T13:55:23 http://comments.gmane.org/gmane.ietf.dhc/12707 <pre>This is a formal notice of an IPR policy violation according to rfC3979, section 6.2.1, by Leaf Y. Yeh, regarding the "RADIUS Option for DHCPv6 Relay Agent" and "Prefix Pool Option for DHCPv6 Relay Agent on the Provider Edge Routers" drafts mentioned in the subject of this message. The working group chairs or AD are responsible for keeping track of IPR policy violations and imposing appropriate sanctions. The nature of the policy violation is that disclosure of IPR that the author of the drafts believed to cover the drafts was made more than 1 year after the publication of the initial individual submissions. Disclosure of IPR is required of IETF participants, as documented in the Note Well policy, and it is required to be done in a timely manner. Please see the text here: http://tools.ietf.org/html/rfc3979#section-6.2 I do not know the full details of the sequence of events, but here is the history from a publication perspective: For draft-ietf-dhc-dhcpv6-radius-opt: * Patent applied for November 8, 2011 (from https://datatracker.ietf.org/ipr/2052/) * draft-yeh-dhc-dhcpv6-authorization-opt-00 published March 5, 2012 * draft-ietf-dhc-dhcpv6-radius-opt-00 published May 7, 2012 * WGLC passed announced February 25, 2013 * IPR 2052 published April 8, 2013 For draft-ietf-dhc-dhcpv6-prefix-pool-opt: * Patent applied for September 26, 2010 (from https://datatracker.ietf.org/ipr/2051/) * draft-yeh-dhc-dhcpv6-prefix-pool-opt-00 published April 16, 2011 * draft-ietf-dhc-dhcpv6-prefix-pool-opt-00 published September 10, 2012 * WGLC started March 24, 2013 for 2 weeks, did not pass announced * IPR 2051 published April 8, 2013 The working group was unaware of the IPR at the time of the WGLC. Thus, a WGLC has been re-issued for draft-ietf-dhc-dhcpv6-radius-opt before it can proceed. As draft-ietf-dhc-dhcpv6-prefix-pool-opt did not pass its WGLC, no action will be taken regarding this document at this time. RFC6701 requires working group chairs and/or ADs to impose sanctions when IPR policy violations have occurred. RFC6701 provides a list of potential sanctions up to and including removing authors from drafts and restricting their ability to post on working group mailing lists for periods of time. The sanction that the chairs and AD have chosen in this case is option d in section 4 of RFC6701, which is to announce what happened on the mailing list. And, we also will re-issue the WGLC for draft-ietf-dhc-dhcpv6-radius-opt. I would encourage any and all participants in the working group who have any thoughts of acquiring IPR on IETF work that they may be doing, or are aware of patent applications or similar efforts relating to work they are doing, to review BCP79 and RFC6701 to obtain a clear understanding of what is required of you in relation to these efforts. - Bernie &amp; Tomek _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg </pre> Bernie Volz (volz 2013-04-19T13:55:14 http://comments.gmane.org/gmane.ietf.dhc/12680 <pre>Hi all: The author has requested a call for adoption by the WG for draft-lemon-dhc-topo-conf-01. This call is being initiated to confirm whether there is WG consensus to adopt this work as DHC WG draft. Please state whether or not you're in favor of the adoption by replying to this mail. If you are not in favor, please also state your objections in your response. This adoption call will complete on May 2nd, 2013. Note that when Ted first published this draft, he posted the following to the DHC WG list: I just submitted a new document to the tracker that attempts to document existing practice with respect to how DHCP options are derived and sent to clients in modern DHCP servers. This is a first draft, and probably needs some new examples. People on this mailing list will, I suspect, find it difficult to remain awake while reading it because it is such old hat to us, but it's been brought to my attention recently that not everybody in the IETF is an expert on DHCP server configuration; this document is an attempt to provide a short, pithy tutorial for IETF document writers who are interested in understanding how DHCP is used in practice. The HTML version of the document can be viewed at http://tools.ietf.org/html/draft-lemon-dhc-topo-conf Regards, Tomek &amp; Bernie _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg </pre> Bernie Volz (volz 2013-04-17T13:47:49 http://comments.gmane.org/gmane.ietf.dhc/12679 <pre>Hi all: The authors have requested a call for adoption by the WG for draft-bhandari-dhc-access-network-identifier-04. This call is being initiated to confirm whether there is WG consensus to adopt this work as DHC WG draft. Please state whether or not you're in favor of the adoption by replying to this mail. If you are not in favor, please also state your objections in your response. This adoption call will complete on May 2nd, 2013. Note that the 04 draft was just published and has redesigned options to better follow the option guidelines. The HTML version of the document can be viewed at http://tools.ietf.org/html/draft-bhandari-dhc-access-network-identifier-04. Regards, Tomek &amp; Bernie _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg </pre> Bernie Volz (volz 2013-04-17T13:32:56 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.dhc