From mailman-admin@ietf.org Sat May 1 11:15:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24596 for ; Sat, 1 May 2004 11:15:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJuR7-0007aI-Lc for DHC-ARCHIVE@lists.ietf.org; Sat, 01 May 2004 09:21:45 -0400 Date: Sat, 01 May 2004 09:21:45 -0400 Message-ID: <20040501132145.27207.73307.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: DHC-ARCHIVE@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, dhcwg-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for DHC-ARCHIVE@lists.ietf.org: List Password // URL ---- -------- dhcwg@ietf.org aCBd https://www1.ietf.org/mailman/options/dhcwg/dhc-archive%40lists.ietf.org From dhcwg-admin@ietf.org Mon May 3 14:36:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19099; Mon, 3 May 2004 14:36:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKi0v-00072E-Ut; Mon, 03 May 2004 14:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKhu9-0005UD-QG for dhcwg@optimus.ietf.org; Mon, 03 May 2004 14:11:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17398 for ; Mon, 3 May 2004 14:10:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKhu7-0000hF-D9 for dhcwg@ietf.org; Mon, 03 May 2004 14:10:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKhtA-0000av-00 for dhcwg@ietf.org; Mon, 03 May 2004 14:10:01 -0400 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 1BKhsb-0000Sm-00 for dhcwg@ietf.org; Mon, 03 May 2004 14:09:26 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i43I8qMS418990 for ; Mon, 3 May 2004 14:08:52 -0400 Received: from IBM-KHXOIC5VFKN.beaverton.ibm.com ([9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i43I8nUM378640 for ; Mon, 3 May 2004 12:08:51 -0600 From: Shirley Ma To: dhcwg@ietf.org Date: Mon, 3 May 2004 11:08:43 -0700 User-Agent: KMail/1.5 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200405031108.44346.mashirle@us.ibm.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCP server supports BOOTP client Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit In RFC 1534, Section 2. BOOTP clients and DHCP servers In summary, a DHCP server: . May suppport BOOTP client In RFC 2131, section 1.6 Design goals . DHCP must provide service to existing BOOTP clients. It's confused, which one we need to follow? -- Thanks Shirley Ma IBM Linux Technology Center _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon May 3 14:37:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19271; Mon, 3 May 2004 14:37:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKi4m-0007r7-OY; Mon, 03 May 2004 14:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKhv8-0005hc-6k for dhcwg@optimus.ietf.org; Mon, 03 May 2004 14:12:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17459 for ; Mon, 3 May 2004 14:11:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKhv5-0000na-Ni for dhcwg@ietf.org; Mon, 03 May 2004 14:11:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKhuC-0000hr-00 for dhcwg@ietf.org; Mon, 03 May 2004 14:11:05 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BKhtU-0000ZR-00; Mon, 03 May 2004 14:10:20 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i43I9kW9020592; Mon, 3 May 2004 11:09:46 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.168]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIC61594; Mon, 3 May 2004 14:09:44 -0400 (EDT) Message-Id: <4.3.2.7.2.20040503135215.02b13dd8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 03 May 2004 14:09:40 -0400 To: minutes@ietf.org From: Ralph Droms Cc: dhcwg@ietf.org, margaret@thingmagic.com, narten@us.ibm.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_246879293==_" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Minutes from interim dhc WG meeting Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --=====================_246879293==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Attached are the minutes from two phone calls held by the dhc WG to discuss draft-ietf-dhc-implementation-01.txt, which addresses issues identified by implementors of RFC 2131. The phone calls took place 2004-02-23 and 2004-02-25. The minutes include a list of participants on each phone call. My apologies for the late submission. I wrote up the notes and submitted them for review to the call participants, but neglected to follow up by formally submitting the minutes... - Ralph --=====================_246879293==_ Content-Type: text/plain; name="20040225-RFC2131-issues-minutes.txt"; x-mac-type="42494E41"; x-mac-creator="74747874" Content-Disposition: attachment; filename="20040225-RFC2131-issues-minutes.txt" Content-Transfer-Encoding: base64 ICAgICAgIE1pbnV0ZXMgZnJvbSBjb25mIGNhbGwgb24gUkZDMjEzMSBpbXBsZW1lbnRhdGlvbiBp c3N1ZXMKCQkJICAgICBXZWQgMi8yNS8wNAogICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKUGFydGljaXBhbnRzOiBSYWxwaCBEcm9t cyAocmRyb21zQGNpc2NvLmNvbSkKICAgICAgICAgICAgICBCYXJyIEhpYmJzIChyYmhpYmJzQHBh Y2JlbGwubmV0KQogICAgICAgICAgICAgIEtpbSBLaW5uZWFyIChra2luZWVhckBjaXNjby5jb20p CiAgICAgICAgICAgICAgQW5kcmUgS29zdHVyIChBbmRyZUBpbmNvZ25pdG8uY29tKQogICAgICAg ICAgICAgIFJvYiBTdGV2ZW5zIChyb2JzQGNydXppby5jb20pCgpJbmNsdXNpb24gb2YgREhDUElO Rk9STSBpbiBzcGVjaWZpY2F0aW9ucwotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQoKVGhlIGRlc2lnbiB0ZWFtIGFmZmlybWVkIHRoZSBwcmV2aW91cyBkZWNpc2lvbiBu b3QgdG8gYWRkIERIQ1BJTkZPUk0KdG8gdGhlIHN0YXRlIG1hY2hpbmUgaW4gUkZDMjEzMS4gIFRo ZXJlIG1heSBiZSBhIG5lZWQgdG8gcmV2aXNpdCB0aGUKZGVmaW5pdGlvbiBvZiB3aGVuIHRvIHVz ZSBESENQSU5GT1JNLCBiYXNlZCBvbiB3b3JrIGVsc2V3aGVyZSBvbgoiZGV0ZWN0aW5nIG5ldHdv cmsgYXR0YWNobWVudCIgKEROQSkgYW5kIHJlY29nbml6aW5nIHRoYXQgYXBwbGljYXRpb25zCm1h eSB1c2UgREhDUElORk9STSB0byBvYnRhaW4gc3BlY2lmaWMgY29uZmlndXJhdGlvbiBpbmZvcm1h dGlvbi4KCkNvbnNpZGVyYXRpb24gb2YgcGFyYWxsZWwgd29yayBvbiBESENQIHNwZWNpZmljYXRp b24KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoK V29yayBmcm9tIG90aGVyIEludGVybmV0IERyYWZ0cyB0aGF0IGFmZmVjdHMgdGhlIERIQ1Agc3Bl Y2lmaWNhdGlvbgp3aWxsIGJlIGludGVncmF0ZWQgaW50byBSRkMyMTMxYmlzLgoKWElEIGNvbnNp c3RlbmN5Ci0tLS0tLS0tLS0tLS0tLQoKQ2xpZW50cyBNVVNUIHVzZSB0aGUgc2FtZSBYSUQgZm9y IHJldHJhbnNtaXR0ZWQgbWVzc2FnZXMuICBPdGhlcndpc2UsCnRoZXJlIGFyZSBubyByZXN0cmlj dGlvbnMgb24gdGhlIFhJRCBzdXBwbGllZCBieSB0aGUgY2xpZW50LiAgSW4KcGFydGljdWxhciwg dGhlIGNsaWVudCBpcyBub3QgcmVxdWlyZWQgdG8gdXNlIHRoZSBzYW1lIFhJRCBpbiBhCkRIQ1BE SVNDT1ZFUiBhbmQgc3Vic2VxdWVudCBESENQUkVRVUVTVC4KClNlcnZlciByZXNwb25kaW5nIHdp dGggY2xpZW50IGlkZW50aWZpZXIKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQoKU2VydmVycyB3aWxsIGJlIHJlcXVpcmVkIHRvIGluY2x1ZGUgdGhlIGNsaWVudCBpZGVu dGlmaWVyIGluIGFsbApyZXNwb25zZXMuCgooVGhlIGZvbGxvd2luZyB0ZXh0IGRpc2N1c3NlcyBz ZWN0aW9ucyBmcm9tCmRyYWZ0LWlldGYtZGhjLWltcGxlbWVudGF0aW9uLTAxLnR4dDsgdGV4dCBu b3QgZXhwbGljaXRseSBkaXNjdXNzZWQgaXMKaW1wbGljaXRseSBhY2NlcHRlZC4pCgpTZWN0aW9u IDIuMTE6IFVuaWNhc3Qgb2YgREhDUERJU0NPVkVSIAotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tCgpUaGUgZGlzY3Vzc2lvbiBvZiBwcm94aWVzIChlLmcuLCBOQVMsIFJBUykg d2lsbCBiZSBtb3ZlZCB0byBhCmRpZmZlcmVudCBkb2N1bWVudC4KClNlY3Rpb24gMi4xMjsgREhD UFJFTEVBU0UKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKVGhlIGZvbGxvd2luZyBjaGFuZ2Vz IHdpbGwgYmUgbWFkZSB0byB0YWJsZSA1IG9mIFJGQyAyMTMxIGZvciB0aGUKREhDUERFQ0xJTkUg YW5kIERIQ1BSRUxFQVNFIG1lc3NhZ2VzOgoKKiB0aGUgJ3NuYW1lJyBhbmQgJ2ZpbGUnIGZpZWxk cyB3aWxsIGJlIG1hcmtlZCAidW51c2VkIiAocmF0aGVyIHRoYW4KICAiTUFZIjsgbm90ZSB0aGF0 IHRhYmxlIDUgaXMgaW5jb25zaXN0ZW50IGluIGl0cyBkZXNjcmlwdGlvbiBvZiB0aGUKICB1c2Ug b2YgdGhlICdzbmFtZScgYW5kICdmaWxlJyBmaWVsZHMpCiogVGhlICdtZXNzYWdlJyBvcHRpb24g d2lsbCBiZSBwZXJtaXR0ZWQKKiBUaGUgJ21lc3NhZ2UgdHlwZScgb3B0aW9uIGlzIHJlcXVpcmVk ICh0YWJsZSA1IGhhcyB0aGUgJ29wdGlvbnMnCiAgZmllbGQgYXMgIih1bnVzZWQpIikKClNlY3Rp b24gMi4xMzogQ2xpZW50IHN0YXRlIGRpYWdyYW0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQoKVGhlIHN0YXRlIHRyYW5zaXRpb24gZGlhZ3JhbSBhbmQgYXNzb2NpYXRlZCB0ZXh0 IHdpbGwgYmUgY2hlY2tlZCBmb3IKY29ycmVjdG5lc3MgYW5kIGNvbnNpc3RlbmN5LiAgVGhlIHRl eHQgZGVzY3JpYmluZyB0aGUgZGlhZ3JhbSB3aWxsCmNsYXJpZnkgdGhhdCB0aGUgY2xpZW50IGZp cnN0IHNlbmRzIHRoZSBhc3NvY2lhdGVkIG1lc3NhZ2UgYW5kIHRoZW4KdHJhbnNpdGlvbnMgdG8g dGhlIG5leHQgc3RhdGUuCgpTZWN0aW9uIDIuMTQuMTsgV2hpY2ggb3B0aW9ucyB0byByZXR1cm4/ Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KClRoZSBzZXJ2ZXIgc2hv dWxkIHJldHVybiBvcHRpb25zIGFjY29yZGluZyB0byB0aGUgZm9sbG93aW5nIHByaW9yaXR5Cm9y ZGVyOgoKKiByZXR1cm4gcmVxdWlyZWQgZmllbGRzIChsZWFzZSB0aW1lLCBtZXNzYWdlIHR5cGUs IHN1Ym5ldCAKICBtYXNrLCBjbGllbnQgSUQpCiogcmV0dXJuIG9wdGlvbnMgY2xpZW50IHJlcXVl c3RlZAoqIHJldHVybiBhZGRpdGlvbmFsIG9wdGlvbnMgdGhhdCBhbiBhZG1pbiB3YW50cyAoU0hP VUxEIGJlIAogIGNvbmZpZ3VyYWJsZSB0byBkbyBzbykKCkEgY2xpZW50IE1VU1QgYmUgcHJlcGFy ZWQgdG8gYWNjZXB0IG9wdGlvbnMgdGhhdCBpdCBkaWQgbm90IHJlcXVlc3QsCmFuZCBNVVNUIGdy YWNlZnVsbHkgZGlzY2FyZCBhbnkgb3B0aW9ucyB0aGF0IGl0IGRvZXMgbm90IHJlY29nbml6ZS4K ClRoZSB0ZXh0IGZyb20gdGhlICdsb25nIG9wdGlvbnMnIFJGQyB3aWxsIGJlIGZvbGRlZCBpbnRv IFJGQzIxMzFiaXMuCgpTZWN0aW9uIDIuMTQuMzogT3B0aW9uIG9yZGVyaW5nCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0KClRoZSBjbGllbnQgTVVTVCBOT1QgbWFrZSBhbnkgYXNzdW1w dGlvbnMgYWJvdXQgdGhlIG9yZGVyIG9mIG9wdGlvbnMgaW4KYSBESENQIG1lc3NhZ2UuCgpTZWN0 aW9uIDIuMTQuNDogT3B0aW9ucyA2NiBhbmQgNjcKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCgpCZWNhdXNlIHRoaXMgc2VjdGlvbiBhZGRyZXNzZXMgYSBmdW5kYW1lbnRhbCBjaGFu Z2UgdG8gdGhlIERIQ1AKcHJvdG9jb2wgbWVzc2FnZSBmb3JtYXQsIGl0IHdpbGwgYmUgbW92ZWQg dG8gYW5vdGhlciBkb2N1bWVudC4KClNlY3Rpb24gMi4xNTogVmVuZG9yIENsYXNzZXMgCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KClNlY3Rpb24gMS4xIG9mIFJGQzIxMzEgd2lsbCBiZSBk aXNjYXJkZWQgZnJvbSBSRkMyMTMxYmlzLgoKU2VjdGlvbiAyLjE1LjE6IENoYXJhY3RlciBzZXQK LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KClRoZSBkZXNpZ24gdGVhbSB3YXMgdW5hYmxl IHRvIHJlYWNoIGNvbnNlbnN1cyBvbiB3aGV0aGVyIHRoZSB2ZW5kb3IKY2xhc3MgaWRlbnRpZmll ciBzaG91bGQgYmUgY29uc2lkZXJlZCBhbiBvcGFxdWUgdmFsdWUsIGEgcHJpbnRhYmxlCnN0cmlu Zywgb3Igc29tZSBvdGhlciBhbHRlcm5hdGl2ZS4gIEFsc28sIHRoZXJlIHdhcyBubyBjb25zZW5z dXMgYWJvdXQKdXNlIG9mIE5WVCBBU0NJSSBvciBhbGxvd2luZyB0aGUgaW5jbHVzaW9uIG9mIHdo aXRlc3BhY2UgY2hhcmFjdGVycy4KVGhlIHF1ZXN0aW9uIHdpbGwgYmUgZm9yd2FyZGVkIHRvIHRo ZSBkaGMgV0cgbWFpbGluZyBsaXN0LgoKVGhlIHRleHQgZnJvbSAnVmVuZG9yLUlkZW50aWZ5aW5n IFZlbmRvciBPcHRpb25zIGZvciBESENQdjQiCjxkcmFmdC1pZXRmLWRoYy12ZW5kb3ItMDEudHh0 PiBzaG91bGQgYmUgY29uc2lkZXJlZCBmb3IgaW5jbHVzaW9uIGluClJGQzIxMzFiaXMuCgpTZWN0 aW9uIDIuMTY6IENsaWVudC9TZXJ2ZXIgUmV0cmFuc21pc3Npb24gCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKVGhlIHRleHQgb24gcmV0cmFuc21pc3Npb24gdGlt aW5nIGZyb20gUkZDMzMxNSBzaG91bGQgYmUgcmV2aWV3ZWQgZm9yCnVzZSBpbiBSRkMyMTMxYmlz LiAgVGhlIGlzc3VlIHdpbGwgYmUgcG9zdGVkIHRvIHRoZSBkaGMgV0cgbWFpbGluZwpsaXN0LgoK U2VjdGlvbiAyLjE3OiBUcmFuc21pc3Npb24gb2YgREhDUE5BS3MKLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0KCkRIQ1BOQUtzIFNIT1VMRCBiZSBicm9hZGNhc3QgdW5sZXNz IHRoZSBzZXJ2ZXIga25vd3MgZGVmaW5pdGl2ZWx5IHRoYXQKYSB1bmljYXN0IHdpbGwgZ2V0IHRv IHRoZSBjbGllbnQgKGUuZy4sIGNsaWVudCBoYXMgdmFsaWQgYWRkcmVzcyBpbgoneWlhZGRyJzsg c2VydmVyIGlzIGRpc2FsbG93aW5nIGZ1cnRoZXIgdXNlIG9mIHRoYXQgYWRkcmVzcykuICBWYXJp b3VzCnNlY3Rpb25zIG9mIFJGQzIxMzFiaXMgc2hvdWxkIGJlIHJld29yZGVkIGZvciBjb3JyZWN0 bmVzcyBhbmQgY2xhcml0eS4KClNlY3Rpb24gMi4xODogVXNlIG9mIGNpYWRkcgotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0KClRoZSBsYXN0IHNlbnRlbmNlIGluIHRoaXMgc2VjdGlvbiwgIlNl cnZlcnMgdHJ1c3QgJ2NpYWRkciwnIHBlcmlvZC4iLAppcyBpbmNvcnJlY3QuICBTZXJ2ZXJzIFNI T1VMRCBjaGVjayAnY2lhZGRyJyBmb3IgY29ycmVjdG5lc3MuCgpTZWN0aW9uIDIuMTk6IFNpemUg b2YgYSBCT09UUC9ESENQIGZyYW1lIAotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCgpSRkMyMTMxYmlzIHNob3VsZCBleHBsaWNpdGx5IG1lbnRpb24gMzAwIG9jdGV0IGxv d2VyIGJvdW5kIGZvciBESENQCm1lc3NhZ2VzLiAgT3RoZXIgaXNzdWVzIC0gbWF4aW11bSBzaXpl LCBNVFUsIHVzZSBvZiBmcmFnbWVudGF0aW9uIGFuZAptZXNzYWdlIHNpemUgb3B0aW9ucyAtIHdp bGwgYmUgZGlzY3Vzc2VkIG9uIHRoZSBkaGMgV0cgbWFpbGluZyBsaXN0LgoKCgoKCgoK --=====================_246879293==_ Content-Type: text/plain; name="20040223-RFC2131-issues-minutes.txt"; x-mac-type="42494E41"; x-mac-creator="74747874" Content-Disposition: attachment; filename="20040223-RFC2131-issues-minutes.txt" Content-Transfer-Encoding: base64 ICAgICAgIE1pbnV0ZXMgZnJvbSBjb25mIGNhbGwgb24gUkZDMjEzMSBpbXBsZW1lbnRhdGlvbiBp c3N1ZXMKCQkJICAgICBNb24gMi8yMy8wNAogICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKUGFydGljaXBhbnRzOiBWaWpheWFiaGFz a2FyIEEgS2FsdXNpdmFsaW5nYW0gKHZpamF5YWtAaW5kaWEuaHAuY29tKQogICAgICAgICAgICAg IFJhbHBoIERyb21zIChyZHJvbXNAY2lzY28uY29tKQogICAgICAgICAgICAgIEJhcnIgSGliYnMg KHJiaGliYnNAcGFjYmVsbC5uZXQpCiAgICAgICAgICAgICAgS2ltIEtpbm5lYXIgKGtraW5lZWFy QGNpc2NvLmNvbSkKICAgICAgICAgICAgICBBbmRyZSBLb3N0dXIgKEFuZHJlQGluY29nbml0by5j b20pCiAgICAgICAgICAgICAgQnVkIE1pbGx3b29kIChidWRtQHdlaXJkLXNvbHV0aW9ucy5jb20p CiAgICAgICAgICAgICAgS2V2aW4gTm9sbCAoa2V2aW4ubm9sbEBwZXJmZWN0b3JkZXIuY29tKQog ICAgICAgICAgICAgIFJvYiBTdGV2ZW5zIChyb2JzQGNydXppby5jb20pCiAgICAgICAgICAgICAg QmVybmllIFZvbHogKHZvbHpAY2lzY28uY29tKQoKMS4gRG8gd2UgaGF2ZSBzdWZmaWNpZW50IHJl c3BvbnNlIGZyb20gdGhlIGNvbW11bml0eSB0byBwcm9jZWVkPwoKVGhlIHJldmlldyB0ZWFtIGhh cyBnb3R0ZW4gZ29vZCByZXNwb25zZSBhbmQgZGlzY3Vzc2lvbiBhYm91dAonSW1wbGVtZW50YXRp b24gSXNzdWVzIHdpdGggUkZDIDIxMzEsICJEeW5hbWljIEhvc3QgQ29uZmlndXJhdGlvbgpQcm90 b2NvbCInIDxkcmFmdC1pZXRmLWRoYy1pbXBsZW1lbnRhdGlvbi0wMS50eHQ+LiAgVGhpcyBkcmFm dCB3aWxsIGJlCnB1Ymxpc2hlZCBhcyBJbmZvcm1hdGlvbmFsIGFuZCB1c2VkIGFzIHRoZSBiYXNp cyBmb3IgcHVibGlzaGluZwpSRkMyMTMxYmlzLCB3aGljaCB3aWxsIGJlIGNvbnNpZGVyZWQgZm9y IGFkdmFuY2VtZW50IGFzIGEgRnVsbApTdGFuZGFyZC4KCjIuIEFjY2VwdCBvciByZWplY3QgdHlw b2dyYXBoaWMgY29ycmVjdGlvbnMKClRoZSBzdGF0ZSBtYWNoaW5lIGluIFJGQzIxMzEgd2lsbCBi ZSByZXRhaW5lZC4gIEFsdGhvdWdoIHRoZQpESENQSU5GT1JNIG1lc3NhZ2UgaXMgbm90IGluY2x1 ZGVkIGluIHRoZSBzdGF0ZSBtYWNoaW5lLCBpdCBoYXMgbm8KaW1wYWN0IG9uIHRoZSBjbGllbnQg c3RhdGUgYW5kIHdpbGwgbm90IGJlIGFkZGVkIHRvIHRoZSBzdGF0ZSBtYWNoaW5lCmRpYWdyYW0u ICBUaGVyZSB3YXMgc29tZSBkaXNjdXNzaW9uIGFib3V0IHdoZXRoZXIgc29tZSBtZXNzYWdlcyB3 ZXJlCnNlbnQgQkVGT1JFIG9yIEFGVEVSIHRyYW5zaXRpb25pbmcgZnJvbSBvbmUgc3RhdGUgdG8g dGhlIG90aGVyLCB3aXRoCm5vIGNsZWFyIGNvbnNlbnN1czsgQmFyciBIaWJicyBvZmZlcmVkIHRv IHN1cHBseSBhbiB1cGRhdGVkIHZlcnNpb24gb2YKdGhlIGNsaWVudCBzdGF0ZSB0cmFuc2l0aW9u IGRpYWdyYW0gZm9yIGRpc2N1c3Npb24gYmFzZWQgb24gYQpjb25zaXN0ZW50IGludGVycHJldGF0 aW9uIG9mIHdoZW4gbWVzc2FnZXMgYXJlIHNlbnQgcmVsYXRpdmUgdG8KdHJhbnNpdGlvbnMuCgpS RkMyMTMxYmlzIChhbmQgdGhlIGluY2x1ZGVkIHN0YXRlIG1hY2hpbmUpIHdpbGwgYmUKcHVibGlz aGVkIGluIEFTQ0lJIGZvcm1hdCAobm8gUERGLCBQUywgZXRjLikgIE90aGVyd2lzZSwgYWxsCnR5 cG9ncmFwaGljIGNvcnJlY3Rpb25zIGFyZSBhY2NlcHRlZC4KCjMuIFBvbGljeSBpc3N1ZXM6IGFu eSBwcm9wb3NlZCB3b3JkaW5nIGNoYW5nZXM/CgpUaGUgZGVzaWduIHRlYW0gZXhwcmVzc2VkIGNv bnNlbnN1cyB0aGF0IGNsaWVudCB0aW1lb3V0cyBhcmUKc3VmZmljaWVudGx5IHNwZWNpZmllZCBh bmQgdGhlIHNwZWNpZmljYXRpb24gc2hvdWxkIGJlIGNhcmVmdWwgdG8KYXZvaWQgb3Zlci1zcGVj aWZ5aW5nIGNsaWVudCBiZWhhdmlvci4KCjQuIEludmFyaWFiaWxpdHkgb2YgJ2NoYWRkcicKClRo ZSBkaXNjdXNzaW9uIHdlbnQgdG8gdGhlIHJlcXVpcmVtZW50IGxldmVsIGZvciAnY2hhZGRyJyBh bmQgJ2NsaWVudAppZGVudGlmaWVyJy4gIFJGQzIxMzFiaXMgd2lsbCByZXF1aXJlIHRoYXQgYSBj bGllbnQgTVVTVCBzZW5kIGJvdGgKJ2NoYWRkcicgYW5kICdjbGllbnQgaWRlbnRpZmllcicsIHdo aWxlIGEgc2VydmVyIG11c3QgYmUgcHJlcGFyZWQgdG8KcmVjZWl2ZSBhIG1lc3NhZ2Ugd2l0aCBv bmx5ICdjaGFkZHInLgoKNS4gQ2xhcmlmaWNhdGlvbiBvZiB0aGUgQ2xpZW50IElkZW50aWZpZXIg KGVsaW1pbmF0ZSBzdWdnZXN0ZWQgZm9ybWF0KQoKUkZDMjEzMWJpcyAoYXMgd2VsbCBhcyBSRkMy MTMyYmlzKSB3aWxsIHNwZWNpZnkgdGhhdCB0aGUgJ2NsaWVudAppZGVudGlmaWVyJyBpcyBhbiBv cGFxdWUgc3RyaW5nLCB3aXRoIG9uZSBzdWdnZXN0aW9uIHRoYXQgdGhlIGNsaWVudApjYW4gY29u c3RydWN0IHRoZSAnY2xpZW50IGlkZW50aWZpZXInIGFzIGFuIGh0eXBlL2FkZHJlc3MgcGFpci4g IFRoZQpzZXJ2ZXIgTVVTVCBOT1QgdHJ5IHRvIGludGVycHJldCB0aGUgY29udGVudHMgb2YgdGhl ICdjbGllbnQKaWRlbnRpZmllcic7IGluIHBhcnRpY3VsYXIsIHRoZSBzZXJ2ZXIgd2lsbCBub3Qg dHJ5IHRvIGRldGVybWluZSBpZgp0aGUgbGVuZ3RoIG9mIHRoZSBhZGRyZXNzIG1hdGNoZXMgdGhl IGhhcmR3YXJlIHR5cGUuCgpUaGVyZSB3YXMgYWxzbyBkaXNjdXNzaW9uIGFib3V0ICdjaGFkZHIn IGFuZCAnaHR5cGUnLiAgVGhlIGNvbnNlbnN1cwp3YXMgdGhhdCB0aGUgc2VydmVyIFNIT1VMRCBj aGVjayB0aGF0IHRoZSBsZW5ndGggb2YgJ2NoYWRkcicgbWF0Y2ggdGhlCmV4cGVjdGVkIGxlbmd0 aCBmcm9tICdodHlwZScuICBOb3RlIHRoYXQgaWYgJ2NoYWRkcicgaXMgaW5jb3JyZWN0IG9yCmlu dmFsaWQsIHRoZSBzZXJ2ZXIgKG9yIHJlbGF5IGFnZW50KSB3aWxsIG5vdCBiZSBhYmxlIHRvIGRl bGl2ZXIKcmVzcG9uc2VzIHRvIHRoZSBjbGllbnQuCgpObyBjb25zZW5zdXMgd2FzIHJlYWNoZWQg Zm9yIGEgcmVxdWlyZW1lbnQgdGhhdCBhIGNsaWVudCBpZGVudGlmaWVyIGJlCmdsb2JhbGx5IHVu aXF1ZS4gIFJGQzIxMzJiaXMgd2lsbCBpbmNsdWRlIHN1Z2dlc3Rpb25zIGZvciBmb3JtaW5nCmds b2JhbGx5IHVuaXF1ZSBjbGllbnQgaWRlbnRpZmllcnMuCgo2LiBBZGRyZXNzIGluIHVzZSBkZXRl Y3Rpb246IGNhbiB3ZSBpbXByb3ZlIGl0PwoKVGhlIG1lY2hhbmlzbXMgc3VnZ2VzdGVkIGluIFJG QzIxMzEgLSBJQ01QIGVjaG8gZnJvbSB0aGUgc2VydmVyLCBBUlAKZnJvbSB0aGUgY2xpZW50IC0g d2lsbCBiZSBzcGVjaWZpZWQgYXMgU0hPVUxEIGluIFJGQzIxMzFiaXMuCgpJZiBhbm90aGVyIGRv Y3VtZW50IGlzIGF2YWlsYWJsZSB0aGF0IG1vcmUgY29tcGxldGVseSBzcGVjaWZpZXMKZHVwbGlj YXRlIGFkZHJlc3MgZGV0ZWN0aW9uIGZvciBJUHY0LCBhIGNpdGF0aW9uIG9mIHRoYXQgZG9jdW1l bnQgd2lsbApiZSBzdWJzdGl0dXRlZCBmb3IgdGhlIHRleHQgaW4gc2VjdGlvbiAyLjIgKGFuZCBl bHNld2hlcmUpIHRoYXQKZGVzY3JpYmVzIHRoZSB1c2Ugb2YgQVJQIGFuZCBJQ01QIEVjaG8gZm9y IGR1cGxpY2F0ZSBhZGRyZXNzCmRldGVjdGlvbi4KCjcuIFJlbGF5IGFnZW50IHNvdXJjZSBhZGRy ZXNzZXMgYW5kIHBvcnQgdXNhZ2UKClRoZSByZWxheSBhZ2VudCBNVVNUIHNlbmQgdGhlIHJlbGF5 ZWQgbWVzc2FnZSB3aXRoIGFuIGFkZHJlc3MgZnJvbQpvbmUgb2YgaXRzIGludGVyZmFjZSAocHJl ZmVyYWJseSBmcm9tIHRoZSBpbnRlcmZhY2UgdGhyb3VnaCB3aGljaCB0aGUKcmVsYXllZCBtZXNz YWdlIGlzIHNlbnQpIGFzIHRoZSBzb3VyY2UgYWRkcmVzcy4KClBvcnQgdXNhZ2UgaXMgYW4gUkZD MTU0MiBpc3N1ZS4KCjguIENhbiB3ZSBlbGltaW5hdGUgdGhlICdzbmFtZScgYW5kICdmaWxlJyBm aWVsZHMgb2YgdGhlIEJPT1RQIHBhY2tldD8KCkJlY2F1c2UgdGhpcyB0b3BpYyB0b3VjaGVzIG9u IHNpZ25pZmljYW50IGNoYW5nZXMgdG8gdGhlIERIQ1AKc3BlY2lmaWNhdGlvbiwgaXQgd2lsbCBi ZSB0aGUgc3ViamVjdCBvZiBhIHNlcGFyYXRlIGRvY3VtZW50LgoKQ3VycmVudGx5LCAnc2lhZGRy JyBjYXJyaWVzIHRoZSBhZGRyZXNzIG9mIG9uZSBib290IHNlcnZlciwgd2hpbGUKJ3NuYW1lJyBh bmQgdGhlIFRGVFAgc2VydmVyIG5hbWUgb3B0aW9uICg2NikgY2FycnkgYSBETlMgbmFtZS4gIElz CnRoZXJlIGEgcmVxdWlyZW1lbnQgZm9yIGFuIG9wdGlvbiB0aGF0IGNhcnJpZXMgYSBsaXN0IG9m IGFkZHJlc3NlcyBvZgpib290IHNlcnZlcnM/ICBkcmFmdC12aWpheS1kaGMtb3B0LWV4dHJib290 LTAwLnR4dCBkZWZpbmVzIGEgbmV3Cm9wdGlvbiB3aXRoIGEgbGlzdCBvZiBzZXJ2ZXJzIGFuZCBh c3NvY2lhdGVkIGZpbGUgbmFtZXMuCgo5LiBBY2NlcHQsIHJlamVjdCwgb3IgZnVydGhlciBzdHVk eSBTSE9VTEQgdi4gTVVTVCBjaGFuZ2VzCgpkcmFmdC1oaWJicy1kaGMtY2hhbmdlcy0wMC50eHQg d2lsbCBiZSBkaXNjdXNzZWQgaW4gZGV0YWlsIGluIHRoZSBuZXh0CmNvbmYgY2FsbC4KCjEwLiBS ZXZpZXcgb2Ygb3RoZXIgaXNzdWVzIGFzIHRpbWUgcGVybWl0cwoKKHRpbWUgZGlkIG5vdCBwZXJt aXQpCgoxMS4gU2NoZWR1bGUgZm9sbG93LW9uIHJldmlldyBvZiB1bnJlc29sdmVkIGlzc3VlcwoK TmV4dCBjb25mIGNhbGwgc2NoZWR1bGVkIGZvciAyLzI1LzA0CgoxMi4gSWRlbnRpZnkgUkZDMjEz MWJpcyBlZGl0b3JzCjEzLiBJZGVudGlmeSBpbnRlcmVzdCBhbmQgaW5pdGlhbCByZXZpZXdlcnMg Zm9yIFJGQzIxMzIKClJGQzIxMzEgYW5kIFJGQzIxMzIgbXVzdCBiZSB1cGRhdGVkIGluIHBhcmFs bGVsLiAgRWRpdG9ycyB3aWxsIGJlCmlkZW50aWZpZWQgYWZ0ZXIgZnVydGhlciByZXZpc2lvbiB0 byBkcmFmdC1oaWJicy1kaGMtY2hhbmdlcy0wMC50eHQuClJldmlldyB0ZWFtIHdpbGwgd29yayBv biBSRkMyMTMyIGlzc3VlcyBhZnRlciBjb21wbGV0aW5nIHJldmlldyBvZgpSRkMyMTMxIGlzc3Vl cy4KCgoK --=====================_246879293==_-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon May 3 15:18:40 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23157; Mon, 3 May 2004 15:18:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKilR-0007k4-Fp; Mon, 03 May 2004 15:06:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKifT-0000gl-Bl for dhcwg@optimus.ietf.org; Mon, 03 May 2004 14:59:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20536 for ; Mon, 3 May 2004 14:59:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKifQ-0006Xx-Ca for dhcwg@ietf.org; Mon, 03 May 2004 14:59:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKiei-0006RM-00 for dhcwg@ietf.org; Mon, 03 May 2004 14:59:08 -0400 Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com) by ietf-mx with esmtp (Exim 4.12) id 1BKidb-0006E4-00 for dhcwg@ietf.org; Mon, 03 May 2004 14:57:59 -0400 Received: from conversion-daemon.endeavor.poss.com by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <0HX500101J0E8R@endeavor.poss.com> for dhcwg@ietf.org; Mon, 03 May 2004 14:57:28 -0400 (EDT) Received: from kan1 (user213.net456.oh.sprint-hsd.net [65.40.141.213]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HX500MSLJBQC4@endeavor.poss.com>; Mon, 03 May 2004 14:57:27 -0400 (EDT) Date: Mon, 03 May 2004 14:57:26 -0400 From: "Kevin A. Noll" Subject: RE: [dhcwg] DHCP server supports BOOTP client In-reply-to: <200405031108.44346.mashirle@us.ibm.com> To: Shirley Ma Cc: dhcwg@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT I think the correct interpretation would be that the server MUST be able to support BOOTP clients, but the system administrator MUST be able to determine how BOOTP requests are handled. If you re-read Section 2, Paragraph 1 of RFC 1534, I think you'll see that this interpretation is implied. There appears to be a consensus on this because most DHCP servers do it this way. --kan-- > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Shirley Ma > Sent: Monday, 03 May, 2004 2:09 PM > To: dhcwg@ietf.org > Subject: [dhcwg] DHCP server supports BOOTP client > > > In RFC 1534, Section 2. BOOTP clients and DHCP servers > In summary, a DHCP server: > . May suppport BOOTP client > > In RFC 2131, section 1.6 Design goals > . DHCP must provide service to existing BOOTP clients. > > It's confused, which one we need to follow? > > -- > Thanks > Shirley Ma > IBM Linux Technology Center > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon May 3 15:41:04 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24801; Mon, 3 May 2004 15:41:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKjCV-0006Wj-1H; Mon, 03 May 2004 15:34:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BKiyt-0003W9-Pl for dhcwg@optimus.ietf.org; Mon, 03 May 2004 15:19:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23405 for ; Mon, 3 May 2004 15:19:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BKiys-0001Sc-Ib for dhcwg@ietf.org; Mon, 03 May 2004 15:19:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BKiy7-0001M1-00 for dhcwg@ietf.org; Mon, 03 May 2004 15:19:12 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BKixR-0001Bx-00 for dhcwg@ietf.org; Mon, 03 May 2004 15:18:29 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i43JHtWB000774; Mon, 3 May 2004 12:17:57 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.168]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIC68309; Mon, 3 May 2004 15:17:54 -0400 (EDT) Message-Id: <4.3.2.7.2.20040503151126.02b61840@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 03 May 2004 15:17:50 -0400 To: Shirley Ma From: Ralph Droms Subject: Re: [dhcwg] DHCP server supports BOOTP client Cc: dhcwg@ietf.org In-Reply-To: <200405031108.44346.mashirle@us.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The two statements are subtly different. The design goal from RFC 2131 (which is not particularly well-worded) is aimed at compatibility of the DHCP specification with BOOTP clients. The statement from RFC 1534 is intended to allow but not require that any specific DHCP server provide BOOTP service. A DHCP server can be compliant with RFC 2131 without providing service to BOOTP clients... - Ralph At 11:08 AM 5/3/2004 -0700, Shirley Ma wrote: >In RFC 1534, Section 2. BOOTP clients and DHCP servers > In summary, a DHCP server: > . May suppport BOOTP client > >In RFC 2131, section 1.6 Design goals > . DHCP must provide service to existing BOOTP clients. > >It's confused, which one we need to follow? > >-- >Thanks >Shirley Ma >IBM Linux Technology Center > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 4 11:08:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07132; Tue, 4 May 2004 11:08:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL1Uf-0006L3-Jd; Tue, 04 May 2004 11:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0se-0003Yr-TZ for dhcwg@optimus.ietf.org; Tue, 04 May 2004 10:26:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04249 for ; Tue, 4 May 2004 10:26:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL0sc-0005hb-LW for dhcwg@ietf.org; Tue, 04 May 2004 10:26:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL0rd-0005df-00 for dhcwg@ietf.org; Tue, 04 May 2004 10:25:42 -0400 Received: from gwa2.fe.bosch.de ([194.39.218.2]) by ietf-mx with esmtp (Exim 4.12) id 1BL0r4-0005YD-00 for dhcwg@ietf.org; Tue, 04 May 2004 10:25:06 -0400 Received: from fe63090.de.bosch.com (unknown [10.4.4.19]) by gwa2.fe.bosch.de (Postfix) with SMTP id A14B1C59ED for ; Tue, 4 May 2004 16:24:24 +0200 (MEST) Received: from 128.14.10.199 by fe63090.de.bosch.com (InterScan E-Mail VirusWall NT); Tue, 04 May 2004 16:24:24 +0200 Received: from hi-mail01.de.bosch.com ([10.34.16.70]) by fe-imc02.de.bosch.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 4 May 2004 16:24:23 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-7406c994-6500-4c44-98cf-518c40e2446e" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 4 May 2004 16:24:21 +0200 Message-ID: <9D116DC155764D4F9C2CECDA2580DF4701007736@hi-mail01.de.bosch.com> Thread-Topic: About DHCP! Thread-Index: AcQx433Pe9bFH4QgRLWi12trbNU1LA== From: "Zhao Dewen (FV/SLM)" To: X-OriginalArrivalTime: 04 May 2004 14:24:23.0791 (UTC) FILETIME=[7F6577F0:01C431E3] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.8 required=5.0 tests=DEAR_SOMETHING,HTML_20_30, HTML_MESSAGE,MIME_BOUND_NEXTPART autolearn=no version=2.60 Subject: [dhcwg] About DHCP! Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPartTM-000-7406c994-6500-4c44-98cf-518c40e2446e Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C431E3.7E058166" ------_=_NextPart_001_01C431E3.7E058166 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Sir, I'm student in the university Duisburg-Essen in Germany.Now I have a = task to develop and implement an automatic Set-Up-Mechanism for = Plug-and-Play IP Cameras.With this mechanism,the camera by connection = with IP-Network can automatic register on the Sever- and = Monitoring-System, transfer the main parameters of the camera and create = a data-connection.I'm new in this field.I don't know whether this task = concerns the DHCP.So could you give me any informations or methods about = it? Thank you very much! Sincerity, Dewen Zhao ------_=_NextPart_001_01C431E3.7E058166 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable About DHCP!

Dear Sir,
I'm  student in the university = Duisburg-Essen in Germany.Now I have a task to develop and implement an = automatic Set-Up-Mechanism for Plug-and-Play IP Cameras.With this = mechanism,the camera by connection with IP-Network can automatic = register on the Sever- and Monitoring-System, transfer the main = parameters of the camera and create a data-connection.I'm new in this = field.I don't know whether this task concerns the DHCP.So could you give = me any informations or methods about it?

Thank you very much!

Sincerity,

Dewen Zhao

------_=_NextPart_001_01C431E3.7E058166-- ------=_NextPartTM-000-7406c994-6500-4c44-98cf-518c40e2446e-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 5 20:22:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22024; Wed, 5 May 2004 20:22:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLWbN-0005Zq-1o; Wed, 05 May 2004 20:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLWVh-0003T1-Qg for dhcwg@optimus.ietf.org; Wed, 05 May 2004 20:13:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21705 for ; Wed, 5 May 2004 20:13:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLWVf-0003k2-PO for dhcwg@ietf.org; Wed, 05 May 2004 20:13:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLWUg-0003S5-00 for dhcwg@ietf.org; Wed, 05 May 2004 20:12:06 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1BLWTq-0002t8-00 for dhcwg@ietf.org; Wed, 05 May 2004 20:11:15 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HX900AGRN5WKU@mailout1.samsung.com> for dhcwg@ietf.org; Thu, 06 May 2004 09:10:44 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HX900LVGN5P6K@mailout1.samsung.com> for dhcwg@ietf.org; Thu, 06 May 2004 09:10:37 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HX900AOLN5O5H@mmp1.samsung.com> for dhcwg@ietf.org; Thu, 06 May 2004 09:10:37 +0900 (KST) Date: Thu, 06 May 2004 09:11:02 +0900 From: "S. Daniel Park" Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt In-reply-to: <4.3.2.7.2.20040420112559.02f34e78@flask.cisco.com> To: "'Ralph Droms'" , dhcwg@ietf.org Cc: "'S. Daniel Park'" Message-id: <006a01c432fe$a118de20$67cadba8@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT I have received below comments on this draft during 2nd WGLC and modifying it. - editorial comment: s/physical/physical subnet in Section 3.1 - word strength: s/SHOULD/MUST in Section 4 - Regarding RFC-2131 text, it still remains without change. clear enough for moving forward ? or anything else ? Regards. - Daniel (Soohong Daniel Park) - Mobile Platform Laboratory, SAMSUNG Electronics. > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On > Behalf Of Ralph Droms > Sent: Wednesday, April 21, 2004 12:30 AM > To: dhcwg@ietf.org > Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-rapid-commit-opt > > > This message announces a WG last call on "Rapid Commit Option > for DHCPv4" > . The last call will > conclude at 5PM EDT > on 4/30/2004. > > Please respond to this WG last call. If you support acceptance of the > document without change, respond with a simple acknowledgment, so that > support for the document can be assessed. Note that this is a new > last call on this document, which was revised after comment recieved > during the WG last call that ended on 4/15/2004. > > draft-ietf-dhc-rapid-commit-opt defines a new DHCPv4 option, > modeled on > the DHCPv6 Rapid Commit option, for obtaining IP address and > configuration > information using a 2-message exchange rather than the usual > 4- message > exchange, expediting client configuration. This draft is available as > http://www.ietf.org/internet-drafts/draft-ietf-dhc-rapid-commi t-opt-02.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 6 11:15:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19382; Thu, 6 May 2004 11:15:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLkQo-0004nv-T4; Thu, 06 May 2004 11:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLjH2-0003V5-Kp for dhcwg@optimus.ietf.org; Thu, 06 May 2004 09:50:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13314 for ; Thu, 6 May 2004 09:50:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLjH0-0007BV-Oy for dhcwg@ietf.org; Thu, 06 May 2004 09:50:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLjFt-0006XZ-00 for dhcwg@ietf.org; Thu, 06 May 2004 09:49:42 -0400 Received: from ns.cnri.reston.va.us ([132.151.1.1]) by ietf-mx with esmtp (Exim 4.12) id 1BLjEg-0005oS-00; Thu, 06 May 2004 09:48:26 -0400 Received: from rbunch.cnri.reston.va.us ([132.151.2.53]) by ns.cnri.reston.va.us with esmtp (Exim 4.20) id 1BLjEf-0004NV-TP; Thu, 06 May 2004 09:48:25 -0400 Message-Id: <6.0.0.9.2.20040506094113.02baab90@odin> X-Sender: rbunch@odin X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.9 (Beta) X-Priority: 2 (High) Date: Thu, 06 May 2004 09:48:29 -0400 To: Ralph Droms , minutes@ietf.org From: Rebecca Bunch Cc: dhcwg@ietf.org, margaret@thingmagic.com, narten@us.ibm.com In-Reply-To: <4.3.2.7.2.20040503135215.02b13dd8@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Re: Minutes from interim dhc WG meeting Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Ralph, I need to put a choice to you about the inclusion of the interim minutes to the IETF-59 Proceedings. I can either: 1. Include the interim minutes to the DHC wg page (http://www.ietf.org/proceedings/04mar/135.htm ) after the slides section with out giving your group time to approve the contents, before the making of the Master CD-Rom for these proceedings. or 2. Make the Master CD-Rom with the existing information of the IETF Proceedings and include the interim minutes only on the Web-Version of the Proceedings. Today is the day that I make the CD-Rom for mass production. I'm afraid to delay the production, to allow your group time to give approval for the changes to your groups page. Please let me know your decision ASAP today. If you have any other questions, please feel free to contact me directly. Thank you. At 02:09 PM 5/3/2004, Ralph Droms wrote: >Attached are the minutes from two phone calls held by the dhc WG to discuss >draft-ietf-dhc-implementation-01.txt, which addresses issues identified by >implementors of RFC 2131. The phone calls took place 2004-02-23 and >2004-02-25. > >The minutes include a list of participants on each phone call. > >My apologies for the late submission. I wrote up the notes and submitted >them for review to the call participants, but neglected to follow up by >formally submitting the minutes... > >- Ralph > > Rebecca F. Bunch _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 6 13:26:55 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04366; Thu, 6 May 2004 13:26:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLmOD-00038X-8T; Thu, 06 May 2004 13:10:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLlSM-0002bq-C0 for dhcwg@optimus.ietf.org; Thu, 06 May 2004 12:10:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24199 for ; Thu, 6 May 2004 12:10:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLlSL-0004x5-24 for dhcwg@ietf.org; Thu, 06 May 2004 12:10:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLlP7-0003n8-00 for dhcwg@ietf.org; Thu, 06 May 2004 12:07:23 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BLlLy-0002Tp-00; Thu, 06 May 2004 12:04:07 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 06 May 2004 08:58:25 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i46G3YYu018444; Thu, 6 May 2004 12:03:34 -0400 (EDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.168]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIE86581; Thu, 6 May 2004 12:03:31 -0400 (EDT) Message-Id: <4.3.2.7.2.20040506120158.02d41008@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 X-Priority: 2 (High) Date: Thu, 06 May 2004 12:03:29 -0400 To: Rebecca Bunch From: Ralph Droms Subject: Re: [dhcwg] Re: Minutes from interim dhc WG meeting Cc: minutes@ietf.org, dhcwg@ietf.org, margaret@thingmagic.com, narten@us.ibm.com In-Reply-To: <6.0.0.9.2.20040506094113.02baab90@odin> References: <4.3.2.7.2.20040503135215.02b13dd8@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Rebecca - the participants in the interim meeting have already reviewed and approved the minutes, so they should be OK for inclusion in the IETF-59 proceedings. So, if it's not too late, please go ahead and include the minutes from the interim meeting in the IETF 59 proceeding CD-ROM. Thanks... - Ralph At 09:48 AM 5/6/2004 -0400, Rebecca Bunch wrote: >Ralph, > >I need to put a choice to you about the inclusion of the interim minutes >to the IETF-59 Proceedings. > >I can either: > >1. Include the interim minutes to the DHC wg page >(http://www.ietf.org/proceedings/04mar/135.htm ) after the slides section >with out giving your group time to approve the contents, before the making >of the Master CD-Rom for these proceedings. > >or > >2. Make the Master CD-Rom with the existing information of the IETF >Proceedings and include the interim minutes only on the Web-Version of the >Proceedings. > >Today is the day that I make the CD-Rom for mass production. I'm afraid >to delay the production, to allow your group time to give approval for the >changes to your groups page. > >Please let me know your decision ASAP today. If you have any other >questions, please feel free to contact me directly. > >Thank you. > > >At 02:09 PM 5/3/2004, Ralph Droms wrote: >>Attached are the minutes from two phone calls held by the dhc WG to discuss >>draft-ietf-dhc-implementation-01.txt, which addresses issues identified by >>implementors of RFC 2131. The phone calls took place 2004-02-23 and >>2004-02-25. >> >>The minutes include a list of participants on each phone call. >> >>My apologies for the late submission. I wrote up the notes and submitted >>them for review to the call participants, but neglected to follow up by >>formally submitting the minutes... >> >>- Ralph >> > >Rebecca F. Bunch > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From bup_press@mail.com Sat May 8 03:11:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17829 for ; Sat, 8 May 2004 03:11:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMLzh-0003jt-ET for dhc-archive@ietf.org; Sat, 08 May 2004 03:11:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMLye-0003JK-00 for dhc-archive@ietf.org; Sat, 08 May 2004 03:10:29 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BMLxf-0002t1-00; Sat, 08 May 2004 03:09:28 -0400 Received: from [218.12.34.234] (helo=ietf.org) by mx2.foretec.com with smtp (Exim 4.24) id 1BMLv6-00048y-H0; Sat, 08 May 2004 03:06:51 -0400 From: "Brasil 2004: . duv" To: dhc-archive@ietf.org Subject: A propriedade, em vias de extinção? cf.: ixn User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Sat, 08 May 2004 03:06:51 -0400 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.9 required=5.0 tests=HTML_40_50,HTML_FONT_BIG, HTML_MESSAGE,MAILTO_SUBJ_REMOVE,MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,REMOVE_REMOVAL_2WORD, SUBJ_HAS_SPACES,SUBJ_ILLEGAL_CHARS autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters

(ref.:dwg) Aos caros amigos, atenciosamente, Ferreira Passos/ConstruNews.

Lindenberg:EnEspañol - Lindenberg:InEnglish(LinkToFreeTranslator)

Série Temas Patrulhados (6)

Brasil 2004: direito de propriedade, em vias de extinção?

Caso não houver uma reação, em poucos anos a propriedade terá se transformado numa reminiscência histórica, e o velho sonho marxista se realizado na apatia e indiferença da chamada "burguesia", adverte Lindenberg

"Patrulhas", mordaça, anestesia

* Adolpho Lindenberg é autor do livro "Os católicos e a economia de mercado", em que denuncia uma política com viés esquerdista que censura, marginaliza ou encobre com um manto de silêncio, opiniões "politicamente incorretas", não afinadas com as assim denominadas "causas populares" inspiradas na teologia da libertação e nos Fóruns Sociais Mundiais. Assim, os meios de comunicação e a sociedade brasileira estão sendo "patrulhados", amordaçados, anestesiados.

Duas ameaças

* Em seu recente artigo "O direito de propriedade, instituição em vias de extinção?", da Série Temas Patrulhados, Lindenberg afirma que o direito de propriedade, no Brasil, está sendo vítima de duas ameaças implacáveis: o aumento da carga tributária - uma das mais altas do mundo - e os movimentos dos sem-terra e sem-teto, inspirados na teologia da libertação e no modelo cubano de produção de miséria.

"Burguesia": sem reação?

* Citando testemunhas de especialistas, o autor constata que se todos os projetos de majoração de impostos que estão sendo discutidos no Congresso forem aprovados, em poucos anos o direito de propriedade terá se transformado numa reminiscência histórica . O velho sonho marxista teria se realizado assim sem grandes reações por parte da "burguesia", anestesiada.

* No entanto, para as pessoas de bom senso, em geral, e para os católicos, em particular, essa escalada contra a propriedade constitui uma flagrante desobediência da lei divina e da lei natural, sem falar que caracterizará um golpe a mais na já combalida instituição familiar.

Reta ordem socioeconômica

* No artigo "O direito de propriedade, instituição em vias de extinção?" se lembra com abundante argumentação que a propriedade constitui pedra de ângulo da estrutura econômica e um dos princípios fundamentais de uma reta ordem socioeconômica. E não só por razões econômicas, perfeitamente válidas, mas também e principalmente por razões de ordem moral e religiosa.

Outros itens

* Outros itens desenvolvidos no artigo de Lindenberg, que oferecemos gratuitamente, por e-mail, junto com a Introdução do livro "Os católicos e a economia de mercado":

- Família e propriedade

- Propriedade e princípio ontológico

- Propriedade, autonomia, personalidad

- Bolo, fatias e solução

- Economias socializadas versus bom senso

Link gratuito:

* Para receber gratuitamente, por e-mail, o texto completo deste artigo, clique em: Lindenberg:EsteArtigoCompletoGratuitamente

Outros links gratuitos (e-Book e outros artigos):

Lindenberg:e-BookGratuitoBr (em formato Word, com 11 artigos de Lindenberg)

Lindenberg:IntroduçãoGratuitaDoLivro (em formato Word, Introdução do livro "Os católicos e a economia de mercado")

Lindenberg:ArtigosAnteriores

Lindenberg:ProximosArtigos

Links de opinião

Gostariamos muito de receber seu seu voto eletrônico sobre a temática abordada neste e-mail e, se possível, conhecer sua valiosa opinião:

Lindenberg:Concordo - Lindenberg:Discrepo - Lindenberg:EmTermos

Outros links

Lindenberg:DesejoAdquirirLivro (receberá instruções sobre como poder adquirir o livro no Brasil)

Remover (para ser retirado imediatamente de nosso Address Book).

A difusão desta mensagem, com uma finalidade cultural e com o intuito de promover um debate construtivo e respeitoso de idéias, é de exclusiva responsabilidade da ConstruNews. Telefone de contato: (11) 9252 - 7873

 From dhcwg-admin@ietf.org Tue May 11 10:41:16 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00199; Tue, 11 May 2004 10:41:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNYAr-0005QG-Ga; Tue, 11 May 2004 10:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNPKn-0006yN-Bo for dhcwg@optimus.ietf.org; Tue, 11 May 2004 00:57:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01516 for ; Tue, 11 May 2004 00:57:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNPKk-0006iL-Jv for dhcwg@ietf.org; Tue, 11 May 2004 00:57:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNPJq-0006MG-00 for dhcwg@ietf.org; Tue, 11 May 2004 00:56:43 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BNPJH-0005zI-00 for dhcwg@ietf.org; Tue, 11 May 2004 00:56:07 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i4B4tZd14121; Tue, 11 May 2004 07:55:35 +0300 Date: Tue, 11 May 2004 07:55:35 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] Review requested: draft-daniel-dhc-ipv6in4-opt-03.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , (co-chair hat on) DHC WG is considering whether to adopt draft-daniel-dhc-ipv6in4-opt-03.txt as their work item for signalling IPv6-in-IPv4 endpoint in DHCPv4. DHC WG has asked to get feedback whether this would be applicable in the IPv6 transition process. For a more generic look on the tunnel end-point discovery, please have a look at draft-palet-v6ops-tun-auto-disc-00.txt (feedback is welcome on that on v6ops list as well, but please use a separate thread). So, (1) please review the document and send feedback on v6ops list, or both v6ops and dhc lists. (2) please consider whether this would be applicable in the transition process and send feedback to v6ops list. In particular, please consider at least: a. which scenario(s) would this be applicable to? b. which mechanism(s) would this be applicable to? c. if multiple mechanisms, would it be needed to distinguish which mechanism's end-point this is applicable to? d. what more is needed to make this applicable as this only solves one part of the problem (i.e., how does the server end configure the tunnel, i.e., learn the client's IPv4 address?) e. whether we have yet enough knowledge of these issues to go forward and specifying the option, or whether we should work e.g., on the mechanisms first. Please send feedback within a week, by 17th May. (hat off) For what it's worth, my personal take is that this is work that may be worth doing, but it is still too early to take it as dhc WG item, because there are still too many unknowns on the field especially regarding: - which specific mechanisms this would be applicable to (2.c), and - we don't have all the pieces of the puzzle in order yet (2.d). _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 11 10:43:47 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00389; Tue, 11 May 2004 10:43:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNYEk-0006Tg-5j; Tue, 11 May 2004 10:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNGnp-0005wR-Qp for dhcwg@optimus.ietf.org; Mon, 10 May 2004 15:51:05 -0400 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29252 for ; Mon, 10 May 2004 15:51:03 -0400 (EDT) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1BNGm0-0005Td-IT; Mon, 10 May 2004 15:49:12 -0400 X-test-idtracker: no To: IETF-Announce :; From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Mon, 10 May 2004 15:49:12 -0400 Subject: [dhcwg] Last Call: 'Reclassifying DHCPv4 Options' to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Dynamic Host Configuration WG to consider the following document: - 'Reclassifying DHCPv4 Options ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-05-24. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-reclassify-options-01.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 13 16:44:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11932; Thu, 13 May 2004 16:44:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOMkq-0004vX-4y; Thu, 13 May 2004 16:24:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOM7E-0004Q4-73 for dhcwg@optimus.ietf.org; Thu, 13 May 2004 15:43:36 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09109; Thu, 13 May 2004 15:43:33 -0400 (EDT) Message-Id: <200405131943.PAA09109@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 13 May 2004 15:43:33 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-rapid-commit-opt-03.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart 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 : Rapid Commit Option for DHCPv4 Author(s) : P. Kim, et al. Filename : draft-ietf-dhc-rapid-commit-opt-03.txt Pages : 11 Date : 2004-5-13 This document defines a new DHCPv4 option, modeled on the DHCPv6 Rapid Commit option, for obtaining IP address and configuration information using a 2-message exchange rather than the usual 4- message exchange, expediting client configuration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-rapid-commit-opt-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-rapid-commit-opt-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-rapid-commit-opt-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-13160741.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-rapid-commit-opt-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-rapid-commit-opt-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-13160741.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri May 14 08:53:00 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19107; Fri, 14 May 2004 08:53:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOc7Z-0003fv-4Y; Fri, 14 May 2004 08:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BObv3-00015Q-AC for dhcwg@optimus.ietf.org; Fri, 14 May 2004 08:36:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18214 for ; Fri, 14 May 2004 08:36:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BObv2-0002M4-4f for dhcwg@ietf.org; Fri, 14 May 2004 08:36:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BObu2-0001rF-00 for dhcwg@ietf.org; Fri, 14 May 2004 08:35:03 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BObt9-0001Ls-00 for dhcwg@ietf.org; Fri, 14 May 2004 08:34:07 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:96f:69a3:96a3:6369]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 161541525D for ; Fri, 14 May 2004 21:33:56 +0900 (JST) Date: Fri, 14 May 2004 21:34:10 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: dhcwg@ietf.org User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [dhcwg] question about NoPrefixAvail in DHCPv6 advertisement Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hello, I have a question about the following part of RFC3633 (Prefix Options for DHCPv6): 11.2. Delegating router behavior [...] If the delegating router will not assign any prefixes to any IA_PDs in a subsequent Request from the requesting router, the delegating router MUST send an Advertise message to the requesting router that includes the IA_PD with no prefixes in the IA_PD and a Status Code option in the IA_PD containing status code NoPrefixAvail and a status message for the user, a Server Identifier option with the delegating router's DUID and a Client Identifier option with the requesting router's DUID. Why should the delegating router include the IA_PD option(s) as well as the status code option (for NoPrefixAvail)? According to the condition that "the router will not assign *any prefixes* to *any IA_PDs*", it should be enough to include the status code only. In fact, in the similar condition of RFC3315 a DHCPv6 server just include a status code option with NoAddrsAvail: If the server will not assign any addresses to any IAs in a subsequent Request from the client, the server MUST send an Advertise message to the client that includes only a Status Code option with code NoAddrsAvail and a status message for the user, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID. I don't see any fundamental differences between the two cases. Moreover, the description for the counterpart at the requesting router seems to not be consistent very much with the above description for the delegating router. In section 11.1, RFC3633 says: The requesting router MUST ignore any Advertise message that includes a Status Code option containing the value NoPrefixAvail, with the exception that the requesting router MAY display the associated status message to the user. It seems to me that this description does not assume the IA_PD option containing a Status Code option (with NoPrefixAvail). Rather, the intention seems to be an advertisement only containing a status code option. To be more concrete, consider the following example. 1. the requesting router sends a DHCPv6 solicit message that includes two IA_PD options: solicit: IA_PD (IAID=1, T1, T2), IA_PD(IAID=2, T1, T2) 2. unfortunately, the delegating router cannot assign any prefix to any IA_PDs specified by the requesting router. According to section 11.2, the delegating router sends a DHCPv6 advertisement like this: advertisement: IA_PD (IAID=1, T1, T2, StatusCode(NoPrefixAvail)), IA_PD (IAID=1, T1, T2, StatusCode(NoPrefixAvail)) 3. the delegating router receives the advertisement. The intention of section 11.1 is probably that the delegating router must ignore the advertisement. The intention looks sane, but the description of the specification is not very clear. It says: The requesting router MUST ignore any Advertise message that includes a Status Code option containing the value NoPrefixAvail, so, can the requesting router ignore the advertisement by simply seeing the first StatusCode with NoPrefixAvail containing in the first IA_PD? Or, is the requesting router expected to parse the entire advertisement and to make the decision to ignore the advertisement only after confirming all the IA_PD options contain StatusCode with NoPrefixAvail? What should the requesting router do if the first IA_PD contains NoPrefixAvail but the second one does not? I personally think the behavior described in RFC3633 is not the best one, and should be revised to be consistent with RFC3315. It should probably be too late, however, and if so, I believe we should at least clarify the point and make a separate internet draft clarifying this point (which will hopefully be merged to the PD specification when it is ready for becoming a DS). Otherwise, this might be a serious interoperability issue. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat May 15 09:12:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20739; Sat, 15 May 2004 09:12:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOyvR-0003Ji-K0; Sat, 15 May 2004 09:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOoTY-00006s-MI for dhcwg@optimus.ietf.org; Fri, 14 May 2004 22:00:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11875 for ; Fri, 14 May 2004 22:00:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOoTV-0004tO-IF for dhcwg@ietf.org; Fri, 14 May 2004 22:00:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOoSV-0004QH-00 for dhcwg@ietf.org; Fri, 14 May 2004 21:59:27 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BOoRO-0003bJ-00 for dhcwg@ietf.org; Fri, 14 May 2004 21:58:18 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:96f:69a3:96a3:6369]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id CE2C91525D for ; Sat, 15 May 2004 10:58:15 +0900 (JST) Date: Sat, 15 May 2004 10:58:31 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: dhcwg@ietf.org Subject: Re: [dhcwg] question about NoPrefixAvail in DHCPv6 advertisement In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Fri, 14 May 2004 21:34:10 +0900, >>>>> JINMEI Tatuya said: > 2. unfortunately, the delegating router cannot assign any prefix to > any IA_PDs specified by the requesting router. According to > section 11.2, the delegating router sends a DHCPv6 advertisement > like this: > advertisement: IA_PD (IAID=1, T1, T2, StatusCode(NoPrefixAvail)), > IA_PD (IAID=1, T1, T2, StatusCode(NoPrefixAvail)) ^^^^^^^this should be "IAID=2". Sorry for the confusing typo. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 18 03:56:19 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22125; Tue, 18 May 2004 03:56:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPzMU-0002kD-Lx; Tue, 18 May 2004 03:50:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPzJI-0001S9-IV for dhcwg@optimus.ietf.org; Tue, 18 May 2004 03:46:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21658 for ; Tue, 18 May 2004 03:46:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPzJF-0004Kn-VO for dhcwg@ietf.org; Tue, 18 May 2004 03:46:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPzIQ-0003xm-00 for dhcwg@ietf.org; Tue, 18 May 2004 03:45:55 -0400 Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn) by ietf-mx with esmtp (Exim 4.12) id 1BPzHT-0003Dk-00 for dhcwg@ietf.org; Tue, 18 May 2004 03:44:56 -0400 Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id i4I7fVI4012679 for ; Tue, 18 May 2004 15:41:32 +0800 (CST) Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Tue May 18 15:44:04 2004 +0800 Received: from BELLNET-MAIL3.sbell.com.cn ([172.24.208.23]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Tue, 18 May 2004 15:44:03 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 18 May 2004 15:44:03 +0800 Message-ID: <8634B809B90D6E4AACA4AB0562A1F07223187A@bellnet-mail3.sbell.com.cn> Thread-Topic: difference of domain name and FQDN option Thread-Index: AcQ8q+P0dJv0+BRVSH+7UjzTSjGmDA== From: "CTO YAN Renxiang" To: X-OriginalArrivalTime: 18 May 2004 07:44:04.0134 (UTC) FILETIME=[E4592C60:01C43CAB] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [dhcwg] difference of domain name and FQDN option Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Does any one could explain the different usage of domain name option = (15) and FQDN option (81)? regards, Yan Renxiang Research&Innovation Center, Alcatel Shanghai Bell Co.,Ltd. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 18 15:55:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10533; Tue, 18 May 2004 15:55:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQAQb-0005SR-Dc; Tue, 18 May 2004 15:39:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQAKO-0001v6-KS for dhcwg@optimus.ietf.org; Tue, 18 May 2004 15:32:40 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09208; Tue, 18 May 2004 15:32:38 -0400 (EDT) Message-Id: <200405181932.PAA09208@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 18 May 2004 15:32:38 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-vendor-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart 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 : Vendor-Identifying Vendor Options for DHCPv4 Author(s) : J. Littlefield Filename : draft-ietf-dhc-vendor-02.txt Pages : 9 Date : 2004-5-18 The DHCP options for Vendor Class and Vendor-Specific Information can be ambiguous when a DHCP client represents multiple vendors. This document defines two new options, modeled on the IPv6 options for vendor class and vendor-specific information, which contain Enterprise Numbers to remove ambiguity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-vendor-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-vendor-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-vendor-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-18155741.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-vendor-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-vendor-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-18155741.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 18 21:45:08 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04119; Tue, 18 May 2004 21:45:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQG5p-0004WW-Gq; Tue, 18 May 2004 21:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQFmq-0001AS-9i for dhcwg@optimus.ietf.org; Tue, 18 May 2004 21:22:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03227 for ; Tue, 18 May 2004 21:22:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQFmn-0007ck-HA for dhcwg@ietf.org; Tue, 18 May 2004 21:22:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQFlt-0007YA-00 for dhcwg@ietf.org; Tue, 18 May 2004 21:21:25 -0400 Received: from smtp804.mail.sc5.yahoo.com ([66.163.168.183]) by ietf-mx with smtp (Exim 4.12) id 1BQFl4-0007UJ-00 for dhcwg@ietf.org; Tue, 18 May 2004 21:20:34 -0400 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@63.193.193.52 with login) by smtp804.mail.sc5.yahoo.com with SMTP; 19 May 2004 00:44:20 -0000 Reply-To: From: "Richard Barr Hibbs" To: Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-vendor-02.txt Date: Tue, 18 May 2004 17:54:04 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <200405181932.PAA09208@ietf.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Josh-- here's an excerpt from section 3: "This option contains information corresponding to one or more Enterprise Numbers. Multiple instances of this option may be present, and MUST be concatenated in accordance with RFC 3396 [4]. An Enterprise Number SHOULD only occur once among all instances of this option. Behavior is undefined if an Enterprise Number occurs multiple times. The information for each Enterprise Number is treated independently, regardless or whether it occurs in an option with other Enterprise Numbers, or in a separate option." While I agree that it is very difficult to specify appropriate behavior of the server if a client sends [apparently] ambiguous data (i.e., multiple instances of an Enterprise Number), I'm becoming less and less favorably disposed towards protocol behavior that is undefined or implementation-dependent. I'd prefer to see something like the following: "An Enterprise Number MUST only occur once among all instances of this option. If an Enterprise Number occurs more than once, despite this restriction, a DHCPv4 server SHOULD process only the LAST instance." I suggest this wording because I believe that the MUST is what you really intend in this section, and the second proposed sentence specifies what would happen if a client violates the restriction. I'm open to suggestions and other opinions about this, however. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 18 23:17:42 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08687; Tue, 18 May 2004 23:17:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQHTy-0003MZ-2X; Tue, 18 May 2004 23:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQHSA-00036s-El for dhcwg@optimus.ietf.org; Tue, 18 May 2004 23:09:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08163 for ; Tue, 18 May 2004 23:09:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQHS6-0001uG-HF for dhcwg@ietf.org; Tue, 18 May 2004 23:09:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQHQY-0001nL-00 for dhcwg@ietf.org; Tue, 18 May 2004 23:07:33 -0400 Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com) by ietf-mx with esmtp (Exim 4.12) id 1BQHPP-0001dO-00 for dhcwg@ietf.org; Tue, 18 May 2004 23:06:19 -0400 Received: from conversion-daemon.endeavor.poss.com by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <0HXX00001XSQUL@endeavor.poss.com> for dhcwg@ietf.org; Tue, 18 May 2004 23:05:50 -0400 (EDT) Received: from kan1 (user188.net390.oh.sprint-hsd.net [65.40.75.188]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HXX0005GXXKFZ@endeavor.poss.com> for dhcwg@ietf.org; Tue, 18 May 2004 23:05:49 -0400 (EDT) Date: Tue, 18 May 2004 23:05:48 -0400 From: "Kevin A. Noll" In-reply-to: <4.3.2.7.2.20040503151126.02b61840@flask.cisco.com> To: dhcwg@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [dhcwg] Client behavior with Parameter Request List Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Section 4.4.1 of RFC 2131 says "If the client included a list of requested parameters in a DHCPDISCOVER message, it MUST include that list in all subsequent messages". I can't find any statement as to what should happen if the client *does not* include the list. Clearly it would be a protocol violation and therefore a broken client if it didn't, but what should the server do about it? I assume it should drop the message. Taking this to a different level of discussion - I question the purpose of making this requirement. I can understand why you would want to require options like "Client Identifier" to always be sent, I'm not sure why the parameter request list must always be included. --kan-- -- Kevin A. Noll, KD4WOZ CCIE 10948, CCDP Perfect Order, Inc. Kevin.Noll@perfectorder.com 717-796-1936 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 19 18:23:00 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24907; Wed, 19 May 2004 18:23:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQZIC-0003Sr-B2; Wed, 19 May 2004 18:12:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQZ6s-0004NC-EZ for dhcwg@optimus.ietf.org; Wed, 19 May 2004 18:00:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22798 for ; Wed, 19 May 2004 18:00:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQZ6p-0000Id-Kg for dhcwg@ietf.org; Wed, 19 May 2004 18:00:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQZ5t-0000BN-00 for dhcwg@ietf.org; Wed, 19 May 2004 17:59:22 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1BQZ5P-00003V-00 for dhcwg@ietf.org; Wed, 19 May 2004 17:58:51 -0400 Received: from [128.177.194.120] (dhcp-120.engr.nominum.com [128.177.194.120]) by toccata.fugue.com (Postfix) with ESMTP id 386D21B2482; Wed, 19 May 2004 16:45:18 -0500 (CDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] Client behavior with Parameter Request List Date: Wed, 19 May 2004 14:58:49 -0700 To: "Kevin A. Noll" X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On May 18, 2004, at 8:05 PM, Kevin A. Noll wrote: > I can't find any statement as to what should happen if the client > *does not* include the list. Clearly it would be a protocol violation > and therefore a broken client if it didn't, but what should the > server do about it? I assume it should drop the message. > > Taking this to a different level of discussion - I question the > purpose of making this requirement. I can understand why you > would want to require options like "Client Identifier" to always > be sent, I'm not sure why the parameter request list must always > be included. The intent was that the client must do this if it expects to get a consistent response from the DHCP server. Of course you should not drop the packet if it doesn't follow this. The point is that you don't have to bend over backwards to be consistent if the client violates this restriction. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 19 21:31:15 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03945; Wed, 19 May 2004 21:31:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQcJv-0004nY-Q6; Wed, 19 May 2004 21:26:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQcFH-00038S-4Z for dhcwg@optimus.ietf.org; Wed, 19 May 2004 21:21:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03575 for ; Wed, 19 May 2004 21:21:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQcFE-0001H5-Ad for dhcwg@ietf.org; Wed, 19 May 2004 21:21:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQcEO-00019m-00 for dhcwg@ietf.org; Wed, 19 May 2004 21:20:21 -0400 Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com) by ietf-mx with esmtp (Exim 4.12) id 1BQcDk-0000zH-00 for dhcwg@ietf.org; Wed, 19 May 2004 21:19:40 -0400 Received: from conversion-daemon.endeavor.poss.com by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <0HXZ00C01NBPTO@endeavor.poss.com> for dhcwg@ietf.org; Wed, 19 May 2004 21:19:05 -0400 (EDT) Received: from kan1 (user188.net390.oh.sprint-hsd.net [65.40.75.188]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HXZ000I1NNSFZ@endeavor.poss.com>; Wed, 19 May 2004 21:19:05 -0400 (EDT) Date: Wed, 19 May 2004 21:19:04 -0400 From: "Kevin A. Noll" Subject: RE: [dhcwg] Client behavior with Parameter Request List In-reply-to: To: Ted Lemon Cc: dhcwg@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT That makes sense. Thanks! Now, I wonder if any server implementations actually check this. --kan-- > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Ted > Lemon > Sent: Wednesday, 19 May, 2004 5:59 PM > To: Kevin A. Noll > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] Client behavior with Parameter Request List > > > On May 18, 2004, at 8:05 PM, Kevin A. Noll wrote: > > > I can't find any statement as to what should happen if the client > > *does not* include the list. Clearly it would be a protocol violation > > and therefore a broken client if it didn't, but what should the > > server do about it? I assume it should drop the message. > > > > Taking this to a different level of discussion - I question the > > purpose of making this requirement. I can understand why you > > would want to require options like "Client Identifier" to always > > be sent, I'm not sure why the parameter request list must always > > be included. > > The intent was that the client must do this if it expects to get a > consistent response from the DHCP server. Of course you should not > drop the packet if it doesn't follow this. The point is that you > don't have to bend over backwards to be consistent if the client > violates this restriction. > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 19 22:42:08 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07209; Wed, 19 May 2004 22:42:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQdSY-0004OK-3E; Wed, 19 May 2004 22:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQdLz-0002K2-CN for dhcwg@optimus.ietf.org; Wed, 19 May 2004 22:32:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06891 for ; Wed, 19 May 2004 22:32:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQdLv-0003XR-TO for dhcwg@ietf.org; Wed, 19 May 2004 22:32:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQdL0-0003OA-00 for dhcwg@ietf.org; Wed, 19 May 2004 22:31:15 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BQdK4-00036u-00 for dhcwg@ietf.org; Wed, 19 May 2004 22:30:16 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 19 May 2004 19:29:56 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4K2Tg30010136; Wed, 19 May 2004 22:29:43 -0400 (EDT) Received: from volzw2k (che-vpn-cluster-2-183.cisco.com [10.86.242.183]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIP86736; Wed, 19 May 2004 22:29:42 -0400 (EDT) From: "Bernie Volz" To: "'CTO YAN Renxiang'" , Subject: RE: [dhcwg] difference of domain name and FQDN option Date: Wed, 19 May 2004 22:29:39 -0400 Organization: Cisco Message-ID: <000001c43e12$4d4b9930$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <8634B809B90D6E4AACA4AB0562A1F07223187A@bellnet-mail3.sbell.com.cn> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Domain name is the default domain the host is in (such as alcatel-sbell.com.cn). Usually, this gets appended to names entered on = the client when trying to do DNS resolution - so if you enter http://www/, = the resolver would look up www.alcatel-sbell.com.cn. FQDN is the = fully-qualified domain of the host - this might be myhost.alcatel-sbell.com.cn. Generally speaking, the FQDN is likely the "host-name" option + "." + = the "domain name" option, but this doesn't have to be case. - Bernie Volz > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On=20 > Behalf Of CTO YAN Renxiang > Sent: Tuesday, May 18, 2004 3:44 AM > To: dhcwg@ietf.org > Subject: [dhcwg] difference of domain name and FQDN option >=20 >=20 >=20 > Does any one could explain the different usage of domain name=20 > option (15) and FQDN option (81)? >=20 > regards, >=20 > Yan Renxiang > Research&Innovation Center, > Alcatel Shanghai Bell Co.,Ltd. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 20 01:35:28 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14941; Thu, 20 May 2004 01:35:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQg8z-00037T-3q; Thu, 20 May 2004 01:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQg2b-0001cT-Gk for dhcwg@optimus.ietf.org; Thu, 20 May 2004 01:24:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14527 for ; Thu, 20 May 2004 01:24:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQg2Y-0006Fy-G4 for dhcwg@ietf.org; Thu, 20 May 2004 01:24:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQg1Z-00064o-00 for dhcwg@ietf.org; Thu, 20 May 2004 01:23:21 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1BQg0i-0005ve-00 for dhcwg@ietf.org; Thu, 20 May 2004 01:22:28 -0400 Received: from [209.233.46.87] (adsl-209-233-46-87.dsl.snfc21.pacbell.net [209.233.46.87]) by toccata.fugue.com (Postfix) with ESMTP id 6968F1B231D; Thu, 20 May 2004 00:08:52 -0500 (CDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] Client behavior with Parameter Request List Date: Wed, 19 May 2004 22:22:27 -0700 To: "Kevin A. Noll" X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On May 19, 2004, at 6:19 PM, Kevin A. Noll wrote: > Now, I wonder if any server implementations actually check this. I would guess that none do - the whole point of that is that you don't have to. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 20 07:15:45 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11802; Thu, 20 May 2004 07:15:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQlKe-0002U5-UE; Thu, 20 May 2004 07:03:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQl4N-0008FJ-NS for dhcwg@optimus.ietf.org; Thu, 20 May 2004 06:46:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10719 for ; Thu, 20 May 2004 06:46:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQl4J-0007f3-Fb for dhcwg@ietf.org; Thu, 20 May 2004 06:46:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQl3M-0007U1-00 for dhcwg@ietf.org; Thu, 20 May 2004 06:45:33 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BQl2T-000795-00 for dhcwg@ietf.org; Thu, 20 May 2004 06:44:37 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 20 May 2004 03:47:35 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4KAi530005640; Thu, 20 May 2004 06:44:05 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-49.cisco.com [10.86.240.49]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIQ03119; Thu, 20 May 2004 06:44:05 -0400 (EDT) Message-Id: <4.3.2.7.2.20040520064145.02b56ba8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 May 2004 06:43:51 -0400 To: "'CTO YAN Renxiang'" , From: Ralph Droms Subject: RE: [dhcwg] difference of domain name and FQDN option In-Reply-To: <000001c43e12$4d4b9930$6401a8c0@amer.cisco.com> References: <8634B809B90D6E4AACA4AB0562A1F07223187A@bellnet-mail3.sbell.com.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Also, option 81 has not yet been specified as a Standard; it is defined in Internet Draft draft-ietf-dhc-fqdn-option-06.txt - Ralph At 10:29 PM 5/19/2004 -0400, Bernie Volz wrote: >Domain name is the default domain the host is in (such as >alcatel-sbell.com.cn). Usually, this gets appended to names entered on the >client when trying to do DNS resolution - so if you enter http://www/, the >resolver would look up www.alcatel-sbell.com.cn. FQDN is the fully-qualified >domain of the host - this might be myhost.alcatel-sbell.com.cn. > >Generally speaking, the FQDN is likely the "host-name" option + "." + the >"domain name" option, but this doesn't have to be case. > >- Bernie Volz > > > -----Original Message----- > > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On > > Behalf Of CTO YAN Renxiang > > Sent: Tuesday, May 18, 2004 3:44 AM > > To: dhcwg@ietf.org > > Subject: [dhcwg] difference of domain name and FQDN option > > > > > > > > Does any one could explain the different usage of domain name > > option (15) and FQDN option (81)? > > > > regards, > > > > Yan Renxiang > > Research&Innovation Center, > > Alcatel Shanghai Bell Co.,Ltd. > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 20 13:32:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04652; Thu, 20 May 2004 13:32:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQrD7-0008PP-Fi; Thu, 20 May 2004 13:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQr6Z-0006Ym-Eg for dhcwg@optimus.ietf.org; Thu, 20 May 2004 13:13:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03128 for ; Thu, 20 May 2004 13:13:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQr6X-0007iw-GQ for dhcwg@ietf.org; Thu, 20 May 2004 13:13:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQr5S-0007aK-00 for dhcwg@ietf.org; Thu, 20 May 2004 13:12:07 -0400 Received: from smtp814.mail.sc5.yahoo.com ([66.163.170.84]) by ietf-mx with smtp (Exim 4.12) id 1BQr4b-0007UX-00 for dhcwg@ietf.org; Thu, 20 May 2004 13:11:14 -0400 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@63.193.193.52 with login) by smtp814.mail.sc5.yahoo.com with SMTP; 20 May 2004 16:37:30 -0000 Reply-To: From: "Richard Barr Hibbs" To: "Dhcwg" Subject: RE: [dhcwg] Client behavior with Parameter Request List Date: Thu, 20 May 2004 09:47:19 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Ted Lemon > > On May 18, 2004, at 8:05 PM, Kevin A. Noll wrote: > > > I can't find any statement as to what should > > happen if the client *does not* include the list. > > Clearly it would be a protocol violation > > and therefore a broken client if it didn't, but > > what should the server do about it? I assume it > > should drop the message. > > > > The intent was that the client must do this if it > expects to get a consistent response from the DHCP > server. Of course you should not drop the packet > if it doesn't follow this. The point is that you > don't have to bend over backwards to be > consistent if the client violates this restriction. > Ted-- while I agree that servers should be "liberal in what they accept, strict in what they send," this is a good example of the questions that arise [and must be settled by agreements outside the text of RFCs] when the protocol behavior is not tightly specified. One shouldn't have to mandate absolutely every behavior in an RFC, but I think your summary of the point would make an excellent correction for RFC2131bis.... "A client MUST send a consistent Parameter Request List if it expects the DHCP server to provide consistent responses to DHCPDISCOVER and DHCPREQUEST messages. If a client does not send a consistent Parameter Request List, the server MAY choose to resolve any conflicts according to [local] implementation policy, which is not specified by this memo." --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 20 14:40:47 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10681; Thu, 20 May 2004 14:40:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQsE5-0008Ma-Cs; Thu, 20 May 2004 14:25:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQsAz-0007LN-L3 for dhcwg@optimus.ietf.org; Thu, 20 May 2004 14:21:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08952 for ; Thu, 20 May 2004 14:21:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQsAw-00079h-IK for dhcwg@ietf.org; Thu, 20 May 2004 14:21:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQs9w-00073V-00 for dhcwg@ietf.org; Thu, 20 May 2004 14:20:49 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1BQs90-0006xK-00 for dhcwg@ietf.org; Thu, 20 May 2004 14:19:50 -0400 Received: from [128.177.194.120] (dhcp-120.engr.nominum.com [128.177.194.120]) by toccata.fugue.com (Postfix) with ESMTP id E62DE1B2765; Thu, 20 May 2004 13:06:08 -0500 (CDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <481EBF5A-AA8A-11D8-9337-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit Cc: "Dhcwg" From: Ted Lemon Subject: Re: [dhcwg] Client behavior with Parameter Request List Date: Thu, 20 May 2004 11:19:49 -0700 To: X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On May 20, 2004, at 9:47 AM, Richard Barr Hibbs wrote: > "A client MUST send a consistent Parameter Request List if > it expects the DHCP server to provide consistent responses > to DHCPDISCOVER and DHCPREQUEST messages. If a client does > not send a consistent Parameter Request List, the server MAY > choose to resolve any conflicts according to [local] > implementation policy, which is not specified by this memo." Yes, we should definitely update the text. I think it needs a bit more thought, though - what are we really trying to accomplish? I think there is very little we actually can require here without placing an undue burden on implementation. I would suggest that the only time that consistency between DHCP server responses is even desirable is between the initial DHCPOFFER and DHCPACK. As long as the client sends the same options in its DHCPDISCOVER that it sends in its DHCPACK, it should get the same answers back. The server should not, however, be required to implement this behavior across restarts or reconfiguration events, although it certainly may. The client should be allowed to restart the configuration process if it receives inconsistent results, and the server should be required to be consistent in its response if it has _not_ been reconfigured. Consistency from the initial DHCPACK to the renewal DHCPACK isn't really possible, IMHO, so we shouldn't require it. That is, we could just save what we sent to the client last time, but that actually would be really bad, and we've seen the badness that it causes, because old versions of Windows assumed parameters would not change. What happens is that when network server addresses change, the clients don't pick up the change, and this results in a management nightmare. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri May 21 05:13:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17529; Fri, 21 May 2004 05:13:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5t2-0007Q6-QN; Fri, 21 May 2004 05:00:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR5kY-0004gW-3Q for dhcwg@optimus.ietf.org; Fri, 21 May 2004 04:51:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16140 for ; Fri, 21 May 2004 04:51:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR5kV-00015g-0m for dhcwg@ietf.org; Fri, 21 May 2004 04:51:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR5jY-0000wr-00 for dhcwg@ietf.org; Fri, 21 May 2004 04:50:28 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BR5ie-0000em-00 for dhcwg@ietf.org; Fri, 21 May 2004 04:49:33 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i4L8mvDW047189 for ; Fri, 21 May 2004 10:48:57 +0200 (CEST) Received: from cadar.office (cadar.office [10.1.1.118]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 031AC44A90 for ; Fri, 21 May 2004 10:48:57 +0200 (CEST) From: Cristian Cadar Organization: NEC Europe Ltd. To: dhcwg@ietf.org Date: Fri, 21 May 2004 10:49:33 +0200 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200405211049.33733.Cristian.Cadar@netlab.nec.de> X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Deafult Router information for DHCPv6 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I know that this issue was already discussed on the list but I ran into a problem which I would like to clarify here. Seemingly the only way for getting the default router information is to make use of the RA. So when I'm using dhcpv6 and want get the default router information is it a MUST to use the RA for this pourpose? I could not find any statement in any of the RFC/drafts saying that. I mean for the time being I cannot see any other possibility. There might be scenarios where the use of RA is not desired and prefering to have a dhcpv6 option carrying this information along. If the use of RA is not a MUST I think we need a new option. Thanks, Cristian _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri May 21 08:43:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27632; Fri, 21 May 2004 08:43:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR94X-0007Xt-1h; Fri, 21 May 2004 08:24:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BR8Q0-0007Jz-6L for dhcwg@optimus.ietf.org; Fri, 21 May 2004 07:42:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25169 for ; Fri, 21 May 2004 07:42:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BR8Pz-0006bK-Cw for dhcwg@ietf.org; Fri, 21 May 2004 07:42:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BR8Oy-0006QS-00 for dhcwg@ietf.org; Fri, 21 May 2004 07:41:25 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BR8Nx-00065M-00 for dhcwg@ietf.org; Fri, 21 May 2004 07:40:21 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 21 May 2004 04:43:29 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4LBdk32011571; Fri, 21 May 2004 07:39:49 -0400 (EDT) Received: from volzw2k (che-vpn-cluster-1-102.cisco.com [10.86.240.102]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIR09323; Fri, 21 May 2004 07:39:45 -0400 (EDT) From: "Bernie Volz" To: "'Cristian Cadar'" , Subject: RE: [dhcwg] Deafult Router information for DHCPv6 Date: Fri, 21 May 2004 07:39:45 -0400 Organization: Cisco Message-ID: <000601c43f28$50c3fdc0$6601a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <200405211049.33733.Cristian.Cadar@netlab.nec.de> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit It would be far better to have *ONE* way in which this information is configured and as RAs already provide it, use that mechanism. If you can come up with a VERY GOOD motivation for why DHCPv6 needs to have an option to specify routing information, feel free to write it up and submit it (personal submission draft) and request for it to be considered a Working Group item. - Bernie > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On > Behalf Of Cristian Cadar > Sent: Friday, May 21, 2004 4:50 AM > To: dhcwg@ietf.org > Subject: [dhcwg] Deafult Router information for DHCPv6 > > > > Hi, > > I know that this issue was already discussed on the list but > I ran into a problem which I would like to clarify here. > Seemingly the only way for getting the default router > information is to make use of > the RA. So when I'm using dhcpv6 and want get the default > router information > is it a MUST to use the RA for this pourpose? I could not > find any statement in any of the RFC/drafts saying that. I > mean for the time being I cannot see any other possibility. > There might be scenarios where the use of RA is not desired > and prefering to have a dhcpv6 option carrying this > information along. If the use of RA is not a MUST I think we > need a new option. > > > Thanks, > Cristian > > > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri May 21 12:28:55 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12657; Fri, 21 May 2004 12:28:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRCX5-0003om-82; Fri, 21 May 2004 12:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRCFS-0007Ym-Uy for dhcwg@optimus.ietf.org; Fri, 21 May 2004 11:47:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10149 for ; Fri, 21 May 2004 11:47:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRCFR-0007Bd-Q8 for dhcwg@ietf.org; Fri, 21 May 2004 11:47:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRCEh-000783-00 for dhcwg@ietf.org; Fri, 21 May 2004 11:47:04 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BRCE0-00072x-00 for dhcwg@ietf.org; Fri, 21 May 2004 11:46:20 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i4LFjmDW080928 for ; Fri, 21 May 2004 17:45:48 +0200 (CEST) Received: from cadar.office (cadar.office [10.1.1.118]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id E7D7F4E7E2 for ; Fri, 21 May 2004 17:45:47 +0200 (CEST) From: Cristian Cadar Organization: NEC Europe Ltd. To: dhcwg@ietf.org Subject: Re: [dhcwg] Deafult Router information for DHCPv6 Date: Fri, 21 May 2004 17:46:27 +0200 User-Agent: KMail/1.5.4 References: <000601c43f28$50c3fdc0$6601a8c0@amer.cisco.com> In-Reply-To: <000601c43f28$50c3fdc0$6601a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200405211746.27193.Cristian.Cadar@netlab.nec.de> X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Bernie I agree completely with you having only one solution for that, I raised the question since I had not found any statement saying that "When use statefull dhcpv6 MUST use RA for getting the default route information" On the other hand having for instance an IPv6 network with 100 subnets I would not feel like installing and managing the radvd daemon on all of the routers in the network just to make the default router information available for the clients, instead I'd rather configure it through a statefull dhcpv6 server for all clients of the network. Cristian On Friday 21 May 2004 13:39, Bernie Volz wrote: > It would be far better to have *ONE* way in which this information is > configured and as RAs already provide it, use that mechanism. > > If you can come up with a VERY GOOD motivation for why DHCPv6 needs to have > an option to specify routing information, feel free to write it up and > submit it (personal submission draft) and request for it to be considered a > Working Group item. > > - Bernie > > > -----Original Message----- > > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On > > Behalf Of Cristian Cadar > > Sent: Friday, May 21, 2004 4:50 AM > > To: dhcwg@ietf.org > > Subject: [dhcwg] Deafult Router information for DHCPv6 > > > > > > > > Hi, > > > > I know that this issue was already discussed on the list but > > I ran into a problem which I would like to clarify here. > > Seemingly the only way for getting the default router > > information is to make use of > > the RA. So when I'm using dhcpv6 and want get the default > > router information > > is it a MUST to use the RA for this pourpose? I could not > > find any statement in any of the RFC/drafts saying that. I > > mean for the time being I cannot see any other possibility. > > There might be scenarios where the use of RA is not desired > > and prefering to have a dhcpv6 option carrying this > > information along. If the use of RA is not a MUST I think we > > need a new option. > > > > > > Thanks, > > Cristian > > > > > > > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > -- ________________________________________________________ | Cristian Cadar cadar@netlab.nec.de | Network Laboratories Heidelberg NEC Europe Ltd. | Kurfuerstenanlage 36 D 69115 Heidelberg | Tel. (+49) 6221 90511-21 Fax: (+49) 6221 90511-55 | URL: http://www.netlab.nec.de/heidelberg/index.html | ________________________________________________________ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri May 21 12:55:40 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14952; Fri, 21 May 2004 12:55:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRDEg-0000J9-Nx; Fri, 21 May 2004 12:51:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRD4X-00067l-WC for dhcwg@optimus.ietf.org; Fri, 21 May 2004 12:40:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13970 for ; Fri, 21 May 2004 12:40:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRD4W-0002vQ-Dy for dhcwg@ietf.org; Fri, 21 May 2004 12:40:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRD3n-0002qW-00 for dhcwg@ietf.org; Fri, 21 May 2004 12:39:51 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BRD2w-0002eu-00 for dhcwg@ietf.org; Fri, 21 May 2004 12:38:58 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 21 May 2004 09:42:08 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4LGcN32015243; Fri, 21 May 2004 12:38:25 -0400 (EDT) Received: from volzw2k (che-vpn-cluster-1-102.cisco.com [10.86.240.102]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIR35146; Fri, 21 May 2004 12:37:09 -0400 (EDT) From: "Bernie Volz" To: "'Cristian Cadar'" , Subject: RE: [dhcwg] Deafult Router information for DHCPv6 Date: Fri, 21 May 2004 12:37:09 -0400 Organization: Cisco Message-ID: <001e01c43f51$dc983540$6601a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <200405211746.27193.Cristian.Cadar@netlab.nec.de> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit There is no statement in RFC3315 because there doesn't need to be one. See the IPv6 specifications (such as RFC 2462, 2461) as these cover the IPv6 requirements. I also don't understand your "100 subnets [perfixes or links?]" situation ... You've got to configure the routers anyway, so they already have all of the information! (Though they could use DHCPv6 & prefix delegation!!) - Bernie > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On > Behalf Of Cristian Cadar > Sent: Friday, May 21, 2004 11:46 AM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] Deafult Router information for DHCPv6 > > > Hi Bernie > > I agree completely with you having only one solution for > that, I raised the question since I had not found any > statement saying that "When use statefull dhcpv6 MUST use RA > for getting the default route information" > > On the other hand having for instance an IPv6 network with > 100 subnets I would not > feel like installing and managing the radvd daemon on all of > the routers in the network just to make the default router > information available for the clients, instead I'd rather > configure it through a statefull dhcpv6 server for all > clients of the network. > > Cristian > > > On Friday 21 May 2004 13:39, Bernie Volz wrote: > > It would be far better to have *ONE* way in which this > information is > > configured and as RAs already provide it, use that mechanism. > > > > If you can come up with a VERY GOOD motivation for why > DHCPv6 needs to > > have an option to specify routing information, feel free to > write it > > up and submit it (personal submission draft) and request > for it to be > > considered a Working Group item. > > > > - Bernie > > > > > -----Original Message----- > > > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On > > > Behalf Of Cristian Cadar > > > Sent: Friday, May 21, 2004 4:50 AM > > > To: dhcwg@ietf.org > > > Subject: [dhcwg] Deafult Router information for DHCPv6 > > > > > > > > > > > > Hi, > > > > > > I know that this issue was already discussed on the list but > > > I ran into a problem which I would like to clarify here. > > > Seemingly the only way for getting the default router > > > information is to make use of > > > the RA. So when I'm using dhcpv6 and want get the default > > > router information > > > is it a MUST to use the RA for this pourpose? I could not > > > find any statement in any of the RFC/drafts saying that. I > > > mean for the time being I cannot see any other possibility. > > > There might be scenarios where the use of RA is not desired > > > and prefering to have a dhcpv6 option carrying this > > > information along. If the use of RA is not a MUST I think we > > > need a new option. > > > > > > > > > Thanks, > > > Cristian > > > > > > > > > > > > > > > > > > _______________________________________________ > > > dhcwg mailing list > > > dhcwg@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > > > > > -- > ________________________________________________________ > | Cristian Cadar cadar@netlab.nec.de > | Network Laboratories Heidelberg NEC Europe Ltd. > | Kurfuerstenanlage 36 D 69115 Heidelberg > | Tel. (+49) 6221 90511-21 Fax: (+49) 6221 90511-55 > | URL: http://www.netlab.nec.de/heidelberg/index.html > | ________________________________________________________ > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri May 21 13:43:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17495; Fri, 21 May 2004 13:43:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRDuG-0001x9-9o; Fri, 21 May 2004 13:34:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRDqc-0000xC-9V for dhcwg@optimus.ietf.org; Fri, 21 May 2004 13:30:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16601 for ; Fri, 21 May 2004 13:30:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRDqa-0006Cw-5p for dhcwg@ietf.org; Fri, 21 May 2004 13:30:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRDpB-0005zU-00 for dhcwg@ietf.org; Fri, 21 May 2004 13:28:49 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BRDoP-0005vF-00 for dhcwg@ietf.org; Fri, 21 May 2004 13:28:01 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BRDoR-0001k1-A9 for dhcwg@ietf.org; Fri, 21 May 2004 13:28:03 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i4LHRToK022598; Fri, 21 May 2004 10:27:30 -0700 (PDT) Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i4LHRRQ15436; Fri, 21 May 2004 19:27:28 +0200 (MEST) Date: Fri, 21 May 2004 10:27:30 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [dhcwg] Deafult Router information for DHCPv6 To: Cristian Cadar Cc: dhcwg@ietf.org In-Reply-To: "Your message with ID" <200405211746.27193.Cristian.Cadar@netlab.nec.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > On the other hand having for instance an IPv6 network with 100 subnets I > would not feel like installing and managing the radvd daemon on all of the > routers in the network just to make the default router information > available for the clients, instead I'd rather configure it through a > statefull dhcpv6 server for all clients of the network. But the router advertisements are needed to provide the on-link prefixes to the hosts in addition to the default router. And that isn't the end of the list... My point is that your argument above is really that all information carried in router advertisement messages (including future extensions?) also needs to be available as DHCP options. I certainly don't see a strong enough case for that level of duplication. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri May 21 23:34:57 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22965; Fri, 21 May 2004 23:34:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRN3P-0007sz-UK; Fri, 21 May 2004 23:20:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRMtk-0006ED-Kn for dhcwg@optimus.ietf.org; Fri, 21 May 2004 23:10:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22191 for ; Fri, 21 May 2004 23:10:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRMtU-00022q-36 for dhcwg@ietf.org; Fri, 21 May 2004 23:09:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRMsV-0001vs-00 for dhcwg@ietf.org; Fri, 21 May 2004 23:08:52 -0400 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by ietf-mx with esmtp (Exim 4.12) id 1BRMrX-0001p2-00 for dhcwg@ietf.org; Fri, 21 May 2004 23:07:51 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 3B3D477; Fri, 21 May 2004 23:07:52 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 May 2004 23:07:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Deafult Router information for DHCPv6 Date: Fri, 21 May 2004 23:07:47 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644C130@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] Deafult Router information for DHCPv6 Thread-Index: AcQ/E+lNAekpCfYKScyQGgasN5GWaAAlcsow From: "Bound, Jim" To: "Cristian Cadar" , X-OriginalArrivalTime: 22 May 2004 03:07:51.0986 (UTC) FILETIME=[F83B1120:01C43FA9] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Christian, I have been down this patha and I cannot see a good case for this to be in DHCPv6. I concur with Eric and Bernie. The entire conversion of routes on a link should come from ND RA. Once the edge link routers have the prefixes it is automatic for the hosts. I can see any good reason to add state to the IPv6 network architecture for route propogation? =20 thanks /jim=20 > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On=20 > Behalf Of Cristian Cadar > Sent: Friday, May 21, 2004 4:50 AM > To: dhcwg@ietf.org > Subject: [dhcwg] Deafult Router information for DHCPv6 >=20 >=20 > Hi, >=20 > I know that this issue was already discussed on the list but=20 > I ran into a problem which I would like to clarify here.=20 > Seemingly the only way for getting the default router=20 > information is to make use of the RA. So when I'm using=20 > dhcpv6 and want get the default router information is it a=20 > MUST to use the RA for this pourpose? I could not find any=20 > statement in any of the RFC/drafts saying that. > I mean for the time being I cannot see any other possibility. > There might be scenarios where the use of RA is not desired=20 > and prefering to have a dhcpv6 option carrying this=20 > information along. If the use of RA is not a MUST I think we=20 > need a new option. >=20 >=20 > Thanks, > Cristian >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat May 22 00:06:01 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24781; Sat, 22 May 2004 00:06:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRNe6-0006nY-NG; Fri, 21 May 2004 23:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRNRW-0004uy-Bu for dhcwg@optimus.ietf.org; Fri, 21 May 2004 23:45:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23862 for ; Fri, 21 May 2004 23:44:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRNRR-0005kL-Vk for dhcwg@ietf.org; Fri, 21 May 2004 23:44:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRNQL-0005WE-00 for dhcwg@ietf.org; Fri, 21 May 2004 23:43:50 -0400 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by ietf-mx with esmtp (Exim 4.12) id 1BRNO9-0005K8-00 for dhcwg@ietf.org; Fri, 21 May 2004 23:41:33 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 5F5FC5E; Fri, 21 May 2004 23:41:33 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 21 May 2004 23:41:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Deafult Router information for DHCPv6 Date: Fri, 21 May 2004 23:41:28 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644C135@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] Deafult Router information for DHCPv6 Thread-Index: AcQ/E+lNAekpCfYKScyQGgasN5GWaAAlcsowAAE3b/A= From: "Bound, Jim" To: "Bound, Jim" , "Cristian Cadar" , X-OriginalArrivalTime: 22 May 2004 03:41:33.0065 (UTC) FILETIME=[ACE33F90:01C43FAE] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable whoops... "I cannot see any reason........." is what was meant in last sentence.=20 /jim=20 > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On=20 > Behalf Of Bound, Jim > Sent: Friday, May 21, 2004 11:08 PM > To: Cristian Cadar; dhcwg@ietf.org > Subject: RE: [dhcwg] Deafult Router information for DHCPv6 >=20 > Christian, >=20 > I have been down this patha and I cannot see a good case for=20 > this to be in DHCPv6. I concur with Eric and Bernie. The=20 > entire conversion of routes on a link should come from ND RA.=20 > Once the edge link routers have the prefixes it is automatic=20 > for the hosts. I can see any good reason to add state to the=20 > IPv6 network architecture for route propogation? =20 >=20 > thanks > /jim=20 >=20 > > -----Original Message----- > > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On=20 > Behalf Of=20 > > Cristian Cadar > > Sent: Friday, May 21, 2004 4:50 AM > > To: dhcwg@ietf.org > > Subject: [dhcwg] Deafult Router information for DHCPv6 > >=20 > >=20 > > Hi, > >=20 > > I know that this issue was already discussed on the list but I ran=20 > > into a problem which I would like to clarify here. > > Seemingly the only way for getting the default router=20 > information is=20 > > to make use of the RA. So when I'm using > > dhcpv6 and want get the default router information is it a=20 > MUST to use=20 > > the RA for this pourpose? I could not find any statement in=20 > any of the=20 > > RFC/drafts saying that. > > I mean for the time being I cannot see any other possibility. > > There might be scenarios where the use of RA is not desired and=20 > > prefering to have a dhcpv6 option carrying this information=20 > along. If=20 > > the use of RA is not a MUST I think we need a new option. > >=20 > >=20 > > Thanks, > > Cristian > >=20 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > >=20 > >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat May 22 07:19:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29650; Sat, 22 May 2004 07:19:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRUIW-0003PS-1T; Sat, 22 May 2004 07:04:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BRU7u-0000f7-8e for dhcwg@optimus.ietf.org; Sat, 22 May 2004 06:53:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28067 for ; Sat, 22 May 2004 06:53:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRU7q-00029y-2N for dhcwg@ietf.org; Sat, 22 May 2004 06:53:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRU6u-00021r-00 for dhcwg@ietf.org; Sat, 22 May 2004 06:52:13 -0400 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1BRU6B-0001tq-00; Sat, 22 May 2004 06:51:27 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i4MApTWE001471; Sat, 22 May 2004 11:51:29 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA16099; Sat, 22 May 2004 11:51:24 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i4MApOP05968; Sat, 22 May 2004 11:51:24 +0100 Date: Sat, 22 May 2004 11:51:24 +0100 From: Tim Chown To: dhcwg@ietf.org Cc: ipv6@ietf.org Subject: Re: [dhcwg] Deafult Router information for DHCPv6 Message-ID: <20040522105124.GD5178@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org, ipv6@ietf.org References: <9C422444DE99BC46B3AD3C6EAFC9711B0644C130@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0644C130@tayexc13.americas.cpqcorp.net> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This reminds me, I don't think the IPv6 nodes requirements draft has yet gone final, since draft-ietf-ipv6-node-requirements-08 still exists on the IETF I-D area. Should we not update this before it goes final with the wording that has been agreed for the M and O flags, and also to clarify the assertion below, that RAs are the way to get default router and onlink prefix information? It would be a shame to not convey this consensus in the nodes document. In the draft, that's at least section 4.5.2 and 4.5.5 that probably need a tweak. Tim On Fri, May 21, 2004 at 11:07:47PM -0400, Bound, Jim wrote: > Christian, > > I have been down this patha and I cannot see a good case for this to be > in DHCPv6. I concur with Eric and Bernie. The entire conversion of > routes on a link should come from ND RA. Once the edge link routers > have the prefixes it is automatic for the hosts. I can see any good > reason to add state to the IPv6 network architecture for route > propogation? > > thanks > /jim > > > -----Original Message----- > > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On > > Behalf Of Cristian Cadar > > Sent: Friday, May 21, 2004 4:50 AM > > To: dhcwg@ietf.org > > Subject: [dhcwg] Deafult Router information for DHCPv6 > > > > > > Hi, > > > > I know that this issue was already discussed on the list but > > I ran into a problem which I would like to clarify here. > > Seemingly the only way for getting the default router > > information is to make use of the RA. So when I'm using > > dhcpv6 and want get the default router information is it a > > MUST to use the RA for this pourpose? I could not find any > > statement in any of the RFC/drafts saying that. > > I mean for the time being I cannot see any other possibility. > > There might be scenarios where the use of RA is not desired > > and prefering to have a dhcpv6 option carrying this > > information along. If the use of RA is not a MUST I think we > > need a new option. > > > > > > Thanks, > > Cristian > > > > > > > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 23 18:58:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12576; Sun, 23 May 2004 18:58:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS1kE-0001Yn-G5; Sun, 23 May 2004 18:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BS1j1-0001QB-Q7 for dhcwg@optimus.ietf.org; Sun, 23 May 2004 18:45:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12143 for ; Sun, 23 May 2004 18:45:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BS1iy-0001Tp-KC for dhcwg@ietf.org; Sun, 23 May 2004 18:45:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BS1hy-0001E3-00 for dhcwg@ietf.org; Sun, 23 May 2004 18:44:43 -0400 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx with esmtp (Exim 4.12) id 1BS1gv-0000kb-00; Sun, 23 May 2004 18:43:38 -0400 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id i4NMhWWE010738; Sun, 23 May 2004 23:43:33 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id XAA00748; Sun, 23 May 2004 23:43:28 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i4NMhSJ10175; Sun, 23 May 2004 23:43:28 +0100 Date: Sun, 23 May 2004 23:43:28 +0100 From: Tim Chown To: dhcwg@ietf.org, ipv6@ietf.org Subject: Re: [dhcwg] Default Router information for DHCPv6 Message-ID: <20040523224328.GB9749@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org, ipv6@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Sat, May 22, 2004 at 05:22:32PM +0300, john.loughney@nokia.com wrote: > > > Should we not update this before it goes final with the wording that has > > been agreed for the M and O flags, and also to clarify the assertion below, > > that RAs are the way to get default router and onlink prefix information? > > > > It would be a shame to not convey this consensus in the nodes document. > > In the draft, that's at least section 4.5.2 and 4.5.5 that probably need a > > tweak. > > Take a look at the current draft, a copy can be found here: > http://www-nrc.nokia.com/sua/draft-ietf-ipv6-node-requirements-09.txt > > and let me know what you think should be modified. Please note that > the idea was that this document should not update any existing RFCs, > so we cannot prescribe new behavior. Ah, good point. However, the 2462 update is due to be submitted very soon, so is it worth waiting on that one to get the more appropriate text in this nodes document? Regarding changes, there would be three I'd suggest. The first two point into 2462-bis, so we just need to (as Christian would say) use the "less is more" maxim, so do something like this: 1. In 5.3.1 change "IPv6 Nodes that use DHCP for address assignment initiate DHCP to obtain IPv6 addresses and other configuration information upon receipt of a Router Advertisement with the 'M' flag set, as described in section 5.5.3 of RFC 2462." to "The method by which IPv6 Nodes that use DHCP for address assignment can obtain IPv6 addresses and other configuration information upon receipt of a Router Advertisement with the 'M' flag set is described in section 5.5.3 of RFC 2462." (leaves the suggestion of M being "mandatory" without using the "MAY" term) 2. In 5.3.2 change "Those IPv6 Nodes that use DHCP to obtain other configuration information initiate DHCP for other configuration information upon receipt of a Router Advertisement with the 'O' flag set, as described in section 5.5.3 of RFC 2462." to "The method by which IPv6 Nodes that use DHCP to obtain other configuration information can obtain other configuration information upon receipt of a Router Advertisement with the 'O' flag set is described in section 5.5.3 of RFC 2462." (ideally that "can" would be a "may", but that suggests something that is not finalised yet, so would be a change of meaning, which you don't want) 3. Add a section 5.5.3: "5.3.3 Use of Router Advertisements in Managed Environments Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) are expected to determine their default router information and on-link prefix information from received Router Advertisements." (Perhaps some people may think this is saying too much, or the section heading could be improved, but if the opinion on the list is consensus, we should add it? You may wish to add reference to Stateless DHCPv6 in that extra section too?) Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon May 24 05:56:49 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23442; Mon, 24 May 2004 05:56:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSC1D-00020M-7X; Mon, 24 May 2004 05:45:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSBog-0008Nl-DE for dhcwg@optimus.ietf.org; Mon, 24 May 2004 05:32:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22498 for ; Mon, 24 May 2004 05:32:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSBoc-0001c5-J7 for dhcwg@ietf.org; Mon, 24 May 2004 05:32:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSBna-0001JN-00 for dhcwg@ietf.org; Mon, 24 May 2004 05:31:10 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BSBma-0000js-00 for dhcwg@ietf.org; Mon, 24 May 2004 05:30:08 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i4O9TcDW063896 for ; Mon, 24 May 2004 11:29:38 +0200 (CEST) Received: from cadar.office (cadar.office [10.1.1.118]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 21C5D1324F3 for ; Mon, 24 May 2004 11:29:38 +0200 (CEST) From: Cristian Cadar Organization: NEC Europe Ltd. To: dhcwg@ietf.org Date: Mon, 24 May 2004 11:30:29 +0200 User-Agent: KMail/1.5.4 References: <20040523224328.GB9749@login.ecs.soton.ac.uk> In-Reply-To: <20040523224328.GB9749@login.ecs.soton.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200405241130.29058.Cristian.Cadar@netlab.nec.de> X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Enabling ipv6 forwarding with dhcpv6 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi , Since there might be clients configured by dhcpv6 with routing capabilities in the network I'm missing the feature of enabling the ipv6 forwarding in dhcpv6. As far as I know the RA does not provide this feature. On a dual-stack UNIX machine there are two different flags to be set for enabling ip forwarding, one for ipv4 and the other for ipv6. Is there any way for doing it with dhcp or RA ? I could not find any. TNX Cristian _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon May 24 18:59:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14598; Mon, 24 May 2004 18:59:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSOMG-0004p5-Te; Mon, 24 May 2004 18:55:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSODn-0004FW-Le for dhcwg@megatron.ietf.org; Mon, 24 May 2004 18:47:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14199 for ; Mon, 24 May 2004 18:47:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSODm-0004e0-61 for dhcwg@ietf.org; Mon, 24 May 2004 18:47:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSOCs-0004ai-00 for dhcwg@ietf.org; Mon, 24 May 2004 18:46:07 -0400 Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com) by ietf-mx with esmtp (Exim 4.12) id 1BSOCA-0004TD-00 for dhcwg@ietf.org; Mon, 24 May 2004 18:45:22 -0400 Received: from conversion-daemon.endeavor.poss.com by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <0HY800C01POD40@endeavor.poss.com> for dhcwg@ietf.org; Mon, 24 May 2004 18:44:47 -0400 (EDT) Received: from kan1 (user188.net390.oh.sprint-hsd.net [65.40.75.188]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HY800D0SPUMN4@endeavor.poss.com> for dhcwg@ietf.org; Mon, 24 May 2004 18:44:47 -0400 (EDT) Date: Mon, 24 May 2004 18:44:46 -0400 From: "Kevin A. Noll" In-reply-to: <481EBF5A-AA8A-11D8-9337-000A95D9C74C@nominum.com> To: Dhcwg Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [dhcwg] Parameter list from multiple servers? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT Section 4.3.1 of RFC2131 states (from the paragraph just below Table 3): "It is important for all DHCP servers to return the same parameters (with the possible exception of a newly allocated network address) to ensure predictable client behavior regardless of which server the client selects." I understand the intent of the statement to assure that clients don't get confused or what not. I would want to assume that it is referring to servers that are "cooperating" (this is not stated) to provide parameters to a specific client (or set of clients). However, it seems to me that it could be clarified a bit, since it is entirely possible (and common practice in my experience) that different servers can be configured to service different clients (or sets/types of clients) on the same network/segment. In the purest protocol sense, the only way for a client to select among them is based on the options being returned. In other words, one server returns a set of options (set A) and another server returns a set of options (set B) in the DHCPOFFER. The client receives both and compares set A and B to find that one (A for example) contains the options that it requires and the other (B) does not, and therefore chooses the most preferred DHCPOFFER. In the practical world, the servers should (and typically are) configured to only respond to specific sets of clients and remain silent when receiving messages from clients not matching the set the server is configured to service. Perhaps the paragraph needs a small alteration to clarify this? Perhaps Barr can include it in his next "implementation" draft? --kan-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue May 25 11:22:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18443; Tue, 25 May 2004 11:22:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSdbt-0001g0-6D; Tue, 25 May 2004 11:12:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSdPH-00071Y-LZ for dhcwg@megatron.ietf.org; Tue, 25 May 2004 10:59:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16716 for ; Tue, 25 May 2004 10:59:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSdPG-0007et-Nw for dhcwg@ietf.org; Tue, 25 May 2004 10:59:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSdOO-0007d4-00 for dhcwg@ietf.org; Tue, 25 May 2004 10:59:01 -0400 Received: from smtp805.mail.sc5.yahoo.com ([66.163.168.184]) by ietf-mx with smtp (Exim 4.12) id 1BSdNm-0007bH-00 for dhcwg@ietf.org; Tue, 25 May 2004 10:58:22 -0400 Received: from unknown (HELO BarrH63p601) (rbhibbs@pacbell.net@63.193.193.52 with login) by smtp805.mail.sc5.yahoo.com with SMTP; 25 May 2004 14:58:15 -0000 From: "Richard Barr Hibbs" To: "Dhcwg" Subject: RE: [dhcwg] Parameter list from multiple servers? Date: Tue, 25 May 2004 08:08:20 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit this is one of our famous (infamous?) "out-of-band" configuration suggestions.... obviously, DHCP servers provisioned by different authorities but serving the same client population might not be able to comply with this behavior. I take a small exception to one thing you said: the RFC implies that a client selects from multiple offers based on some unspecified criteria, with few guidelines as to what the criteria might be, or how they are established. We've seen clients that (1) always selected the first offer received, (2) only selected offers that included all options requested, and (3) refused to accept offers differing from the immediately prior lease accepted. My own opinion is that attempting to define "best" choice of competing offers in the RFC would be both a thankless task, and unlikely to be successful. --Barr -----Original Message----- From: Kevin A. Noll Sent: Monday, 24 May, 2004 15:45 Section 4.3.1 of RFC2131 states (from the paragraph just below Table 3): "It is important for all DHCP servers to return the same parameters (with the possible exception of a newly allocated network address) to ensure predictable client behavior regardless of which server the client selects." I understand the intent of the statement to assure that clients don't get confused or what not. I would want to assume that it is referring to servers that are "cooperating" (this is not stated) to provide parameters to a specific client (or set of clients). However, it seems to me that it could be clarified a bit, since it is entirely possible (and common practice in my experience) that different servers can be configured to service different clients (or sets/types of clients) on the same network/segment. In the purest protocol sense, the only way for a client to select among them is based on the options being returned. In other words, one server returns a set of options (set A) and another server returns a set of options (set B) in the DHCPOFFER. The client receives both and compares set A and B to find that one (A for example) contains the options that it requires and the other (B) does not, and therefore chooses the most preferred DHCPOFFER. In the practical world, the servers should (and typically are) configured to only respond to specific sets of clients and remain silent when receiving messages from clients not matching the set the server is configured to service. Perhaps the paragraph needs a small alteration to clarify this? Perhaps Barr can include it in his next "implementation" draft? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue May 25 13:07:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00220; Tue, 25 May 2004 13:07:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSf5z-00056q-3U; Tue, 25 May 2004 12:48:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSe8K-0002Ba-Oq for dhcwg@megatron.ietf.org; Tue, 25 May 2004 11:46:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20702 for ; Tue, 25 May 2004 11:46:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSe8J-0003ts-Sf for dhcwg@ietf.org; Tue, 25 May 2004 11:46:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSe75-0003ie-00 for dhcwg@ietf.org; Tue, 25 May 2004 11:45:12 -0400 Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com) by ietf-mx with esmtp (Exim 4.12) id 1BSe5o-0003Rz-00 for dhcwg@ietf.org; Tue, 25 May 2004 11:43:52 -0400 Received: from conversion-daemon.endeavor.poss.com by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <0HYA00E010SWOF@endeavor.poss.com> for dhcwg@ietf.org; Tue, 25 May 2004 11:43:22 -0400 (EDT) Received: from kan1 (user188.net390.oh.sprint-hsd.net [65.40.75.188]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HYA00540108QY@endeavor.poss.com>; Tue, 25 May 2004 11:43:22 -0400 (EDT) Date: Tue, 25 May 2004 11:43:21 -0400 From: "Kevin A. Noll" Subject: RE: [dhcwg] Parameter list from multiple servers? In-reply-to: To: Richard Barr Hibbs , Dhcwg Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT I suppose I could have guessed, but didn't realize that this was a subject of such notoriety. Regarding the way a client chooses an OFFER, I completely agree with you, Barr. I was not suggesting a method/criteria by which a client SHOULD choose between offers, but offering it as an example of how one *might* choose given the specific scenario I was laying out. I agree, we should not attempt to specify the methods/criteria by which a client chooses between multiple OFFERs. As you suggest, that would be difficult at best, and would unnecessarily limit the client implementation. --kan-- > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]On Behalf Of > Richard Barr Hibbs > Sent: Tuesday, 25 May, 2004 11:08 AM > To: Dhcwg > Subject: RE: [dhcwg] Parameter list from multiple servers? > > > > this is one of our famous (infamous?) "out-of-band" configuration > suggestions.... obviously, DHCP servers provisioned by different > authorities but serving the same client population might not be able to > comply with this behavior. > > I take a small exception to one thing you said: the RFC implies that a > client selects from multiple offers based on some unspecified > criteria, with > few guidelines as to what the criteria might be, or how they are > established. We've seen clients that (1) always selected the first offer > received, (2) only selected offers that included all options > requested, and > (3) refused to accept offers differing from the immediately prior lease > accepted. My own opinion is that attempting to define "best" choice of > competing offers in the RFC would be both a thankless task, and > unlikely to > be successful. > > --Barr > > > > -----Original Message----- > From: Kevin A. Noll > Sent: Monday, 24 May, 2004 15:45 > > Section 4.3.1 of RFC2131 states (from the paragraph just below > Table 3): > > "It is important for all DHCP servers to return the same parameters > (with the possible exception of a newly allocated network address) > to ensure predictable client behavior regardless of which server the > client selects." > > I understand the intent of the statement to assure that clients don't > get confused or what not. I would want to assume that it is referring > to servers that are "cooperating" (this is not stated) to provide > parameters to a specific client (or set of clients). > > However, it seems to me that it could be clarified a bit, since it is > entirely possible (and common practice in my experience) that different > servers can be configured to service different clients (or sets/types of > clients) on the same network/segment. > > In the purest protocol sense, the only way for a client to select among > them is based on the options being returned. In other words, one server > returns a set of options (set A) and another server returns a set of > options (set B) in the DHCPOFFER. The client receives both and compares > set A and B to find that one (A for example) contains the options that > it requires and the other (B) does not, and therefore chooses the most > preferred DHCPOFFER. > > In the practical world, the servers should (and typically are) > configured to only respond to specific sets of clients and remain silent > when receiving messages from clients not matching the set the server is > configured to service. > > Perhaps the paragraph needs a small alteration to clarify this? Perhaps > Barr can include it in his next "implementation" draft? > > > > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue May 25 13:16:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00998; Tue, 25 May 2004 13:16:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSfJ0-0000Ed-PA; Tue, 25 May 2004 13:01:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSec9-0003NG-BN for dhcwg@megatron.ietf.org; Tue, 25 May 2004 12:17:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24037 for ; Tue, 25 May 2004 12:17:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSec8-0000TF-4i for dhcwg@ietf.org; Tue, 25 May 2004 12:17:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSeZR-00003S-00 for dhcwg@ietf.org; Tue, 25 May 2004 12:14:30 -0400 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by ietf-mx with esmtp (Exim 4.12) id 1BSeX8-0007Sl-00 for dhcwg@ietf.org; Tue, 25 May 2004 12:12:06 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 8073D6707; Tue, 25 May 2004 12:12:05 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 25 May 2004 12:11:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Enabling ipv6 forwarding with dhcpv6 Date: Tue, 25 May 2004 12:11:39 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0644C239@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] Enabling ipv6 forwarding with dhcpv6 Thread-Index: AcRBdSxLGRZZ1x4HS3KV1DR37tmuegA/WoGw From: "Bound, Jim" To: "Cristian Cadar" , X-OriginalArrivalTime: 25 May 2004 16:11:43.0115 (UTC) FILETIME=[F83515B0:01C44272] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Christian, IPv6 is very clear about Host vs Router. An interface cannot be both. So a router interface would not be using a DHCPv6 client is my guess. I think giving hints to the Host interface of a client that has a router interface state too is not a good idea. A UNIX router interface will get all it needs from being a router. We had to do this to support MIPv6 HA on UNIX where I work and the trick is to get all the OSPF, IS-IS, RIPng, BGP et al updates via routing daemon for that interface. Does this answer help? Good question. /jim=20 > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On=20 > Behalf Of Cristian Cadar > Sent: Monday, May 24, 2004 5:30 AM > To: dhcwg@ietf.org > Subject: [dhcwg] Enabling ipv6 forwarding with dhcpv6 >=20 > Hi , >=20 > Since there might be clients configured by dhcpv6 with=20 > routing capabilities in the network I'm missing the feature=20 > of enabling the ipv6 forwarding in dhcpv6. As far as I know=20 > the RA does not provide this feature. On a dual-stack UNIX=20 > machine there are two different flags to be set for enabling=20 > ip forwarding, one for ipv4 and the other for ipv6. > Is there any way for doing it with dhcp or RA ? I could not find any. >=20 > TNX > Cristian >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu May 27 07:50:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17498; Thu, 27 May 2004 07:50:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTJ4V-0004KY-Ua; Thu, 27 May 2004 07:29:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTIvL-0007WK-CP for dhcwg@megatron.ietf.org; Thu, 27 May 2004 07:19:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15568 for ; Thu, 27 May 2004 07:19:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTIv4-0007kW-Ud for dhcwg@ietf.org; Thu, 27 May 2004 07:19:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTIu9-0007Zk-00 for dhcwg@ietf.org; Thu, 27 May 2004 07:18:33 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BTItM-0007D6-00 for dhcwg@ietf.org; Thu, 27 May 2004 07:17:44 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i4RBHCDW075640 for ; Thu, 27 May 2004 13:17:12 +0200 (CEST) Received: from cadar.office (cadar.office [10.1.1.118]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 2EAE2138BE9 for ; Thu, 27 May 2004 13:17:12 +0200 (CEST) From: Cristian Cadar Organization: NEC Europe Ltd. To: dhcwg@ietf.org Subject: Re: [dhcwg] Enabling ipv6 forwarding with dhcpv6 Date: Thu, 27 May 2004 13:18:31 +0200 User-Agent: KMail/1.5.4 References: <9C422444DE99BC46B3AD3C6EAFC9711B0644C239@tayexc13.americas.cpqcorp.net> In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0644C239@tayexc13.americas.cpqcorp.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200405271318.31936.Cristian.Cadar@netlab.nec.de> X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Jim, I think since the use of the RA daemon on ipv6 routers is "almost" a must and it comes together with enabling the ipv6 forwarding the problem is somehow solved. I might be wrong.... Cristian On Tuesday 25 May 2004 18:11, Bound, Jim wrote: > Hi Christian, > > IPv6 is very clear about Host vs Router. An interface cannot be both. > So a router interface would not be using a DHCPv6 client is my guess. I > think giving hints to the Host interface of a client that has a router > interface state too is not a good idea. A UNIX router interface will > get all it needs from being a router. We had to do this to support > MIPv6 HA on UNIX where I work and the trick is to get all the OSPF, > IS-IS, RIPng, BGP et al updates via routing daemon for that interface. > > Does this answer help? > > Good question. > > /jim > > > -----Original Message----- > > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On > > Behalf Of Cristian Cadar > > Sent: Monday, May 24, 2004 5:30 AM > > To: dhcwg@ietf.org > > Subject: [dhcwg] Enabling ipv6 forwarding with dhcpv6 > > > > Hi , > > > > Since there might be clients configured by dhcpv6 with > > routing capabilities in the network I'm missing the feature > > of enabling the ipv6 forwarding in dhcpv6. As far as I know > > the RA does not provide this feature. On a dual-stack UNIX > > machine there are two different flags to be set for enabling > > ip forwarding, one for ipv4 and the other for ipv6. > > Is there any way for doing it with dhcp or RA ? I could not find any. > > > > TNX > > Cristian > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > -- ________________________________________________________ | Cristian Cadar cadar@netlab.nec.de | Network Laboratories Heidelberg NEC Europe Ltd. | Kurfuerstenanlage 36 D 69115 Heidelberg | Tel. (+49) 6221 90511-21 Fax: (+49) 6221 90511-55 | URL: http://www.netlab.nec.de/heidelberg/index.html | ________________________________________________________ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From cfe_press@mail.com Sat May 29 19:29:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28093 for ; Sat, 29 May 2004 19:29:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BUDGs-0006NE-Es for dhc-archive@ietf.org; Sat, 29 May 2004 19:29:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BUDFP-0005ur-00 for dhc-archive@ietf.org; Sat, 29 May 2004 19:28:16 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BUDEI-0005Pz-00; Sat, 29 May 2004 19:27:06 -0400 Received: from [200.61.188.90] (helo=ietf.org) by mx2.foretec.com with smtp (Exim 4.24) id 1BUDDV-0000y3-UH; Sat, 29 May 2004 19:26:44 -0400 From: "Atualidade Brasileira . fmj" To: ietf-action@ietf.org Subject: Revolução de 64 e esquecimento . zjy X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Sat, 29 May 2004 19:26:44 -0400 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=10.8 required=5.0 tests=AWL,FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,HTML_40_50,HTML_FONT_BIG,HTML_MESSAGE, MAILTO_SUBJ_REMOVE,MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,REMOVE_REMOVAL_2WORD, SUBJ_HAS_SPACES,SUBJ_HAS_UNIQ_ID,SUBJ_ILLEGAL_CHARS autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 0.2 SUBJ_HAS_UNIQ_ID Subject contains a unique ID * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 0.0 AWL AWL: Auto-whitelist adjustment

(ref.:rir) Aos caros amigos, aguardando, se possível, vossa valiosa opinião. Atenciosamente, Ferreira-Passos, Atualidade Brasileira.

Lindenberg:LinkToFreeTranslator (English, Español, Deutsche, Français, etc.)

Série Temas Patrulhados (7)

A Revolução de 64 e o esquecimento de sua razão de ser

No 40o. aniversário, o levantamento cívico-militar foi largamente comentado, mas a sua causa profunda, inexplicavelmente omitida, afirma Lindenberg

* No 40o. aniversário da Revolução de 31 de março de 1964, que depôs o presidente esquerdista João Goulart, o histórico episódio foi comentado, discutido e esmiuçado em dezenas de artigos e livros, a causa principal do movimento de 64 foi silenciada de maneira quase unânime por seus detratores, e também por não poucos de seus simpatizantes, constata Adolpho Lindenberg em artigo da Série Temas Patrulhados.

* Lindenberg é autor do livro "Os católicos e a economia de mercado", em que denuncia uma política com viés esquerdista que censura, marginaliza, "patrulha" ou encobre com um manto de silêncio, opiniões "politicamente incorretas", não afinadas com as ideologias de esquerda.

* Neste artigo sobre a Revolução de 64, o autor explica que a sua causa profunda esteve nos rumos cada vez mais esquerdizantes do governo Goulart e na crescente reação do povo brasileiro contra tais rumos; e que as Marchas da Família com Deus e pela Liberdade expressaram bem a inconformidade não somente da classe média, mas da grande maioria da população brasileira para com a comunização do país (SolicitoGratuitamenteEsteArtigoCompleto).

* Se a Revolução não tivesse ocorrido, tudo indica que nosso país teria evoluído para um regime socialista, à semelhança da Cuba castrista, ou do Chile de Allende, continua o autor, acrescentando que as "reformas de base", incluindo uma radical reforma agrária, a política de estatizações e a "demonização" dos Estados Unidos, teriam sido apenas os passos iniciais de um vasto programa de socialização do país.

* Tudo isso, não só com o apóio das lideranças mais radicais, mas também com as "bênçãos" da chamada "esquerda católica". É o que se depreende da ideologia e das metas de figuras exponenciais da era janguista, a começar pelo próprio presidente Goulart, mas também por figuras civis e eclesiásticas de destaque na época, como Leonel Brizola, dom Hélder Câmara, Francisco Julião e outros.

* Pelo inegável apoio e participação de todas as camadas da população com que contou, a Revolução de 64 não pode ser reduzida a um "golpe militar", como pretendem as esquerdas, nem tampouco identificada inteiramente com os rumos e atos do regime militar que lhe sucedeu, ou desqualificada pelos censuráveis atos de torturas acontecidos durante esse regime.

* Entre outros esquecimentos a respeito da Revolução de 64, o articulista constata que os analistas brasileiros que neste 40o. aniversário abordaram o tema, não fizeram sequer uma referência ao papel fundamental do movimento Tradição, Família, Propriedade na criação do clima ideológico e psicológico, na opinião pública brasileira e católica, que levou à Revolução de 64 (EnviarGratuitamenteInfoTFP-Revolução64). O referido silêncio - talvez se pudesse falar até de "patrulhamento" - contrasta com diversos estudos de "brasilianistas" estrangeiros publicados ao longo dos anos, muitos deles de esquerda, que tiveram a honestidade intelectual de reconhecer esse papel fundamental da TFP (EnviarGratuitamenteInfoBrasilianistas ).

* A difusão do livro "Reforma Agrária - Questão de Consciência", escrito por Plinio Corrêa de Oliveira em colaboração com dois bispos e um economista, e as públicas polêmicas dessa entidade com membros da ala esquerda do episcopado e da Ação Católica, tiveram tal relevância que a elas aludiu o presidente Goulart, em tom amargo, em discurso televisionado ao País, um dia antes de sua queda (EnviarGratuitamenteDiscursoGoulart).

* O esquecimento da causa profunda e do contexto histórico nacional em que se deu a Revolução de 64 poderá trazer sérios prejuízos à chamada "memória histórica" do Brasil, pois as novas gerações se verão afetadas por uma espécie de "lacuna" ou "amnésia" a respeito desse período, ou, na melhor das hipóteses, passarão a serem (des)informadas por uma visão profundamente distorcida desse processo, conclui Lindenberg.

Link gratuito:

* Para receber gratuitamente, por e-mail, o texto completo deste artigo, clique em: EnviarEsteArtigoCompletoGratuitamente(No.7)

Outros links gratuitos (e-Book e outros artigos):

Lindenberg:e-BookGratuitoBr (em formato Word, com 11 artigos de Lindenberg)

ProximosArtigos

Links de opinião

Gostariamos muito de receber seu seu voto eletrônico sobre a temática da Revolução de 64 abordada neste e-mail e, se possível, conhecer sua valiosa opinião:

Lindenberg:Concordo - Lindenberg:Discrepo - Lindenberg:EmTermos

Outros links

Lindenberg:DesejoAdquirirLivro (receberá instruções sobre como poder adquirir o livro no Brasil)

Remover (para ser retirado imediatamente de nosso Address Book).

A difusão desta mensagem, com uma finalidade cultural e com o intuito de promover um debate construtivo e respeitoso de idéias, é de exclusiva responsabilidade da ConstruNews. Telefone de contato: (11) 9252 - 7873