From dna-owner@webcamserver.eng.monash.edu.au Mon Jan 01 19:19:29 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1XNJ-0002mM-Uc for dna-archive@lists.ietf.org; Mon, 01 Jan 2007 19:19:29 -0500 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1XNE-0001Nd-HE for dna-archive@lists.ietf.org; Mon, 01 Jan 2007 19:19:29 -0500 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01MBGA2L821U8WXE3B@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 02 Jan 2007 11:19:14 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7292CAB546; Tue, 02 Jan 2007 11:19:11 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 32F854FB02; Tue, 02 Jan 2007 11:19:11 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l020CpD14676 for dna-list; Tue, 02 Jan 2007 11:12:51 +1100 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l02046H11022 for ; Tue, 02 Jan 2007 11:04:13 +1100 Received: from kenny.its.monash.edu.au ([130.194.13.164]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01MBEGEBLKAQ8WXEGS@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 01 Jan 2007 03:58:52 +1000 Received: from spam-daemon.kenny.its.monash.edu.au by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JB500M0NDU27900@kenny.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 01 Jan 2007 03:58:52 +1100 (EST) Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JB500F01B478200@kenny.its.monash.edu.au> (original mail from dromasca@avaya.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 01 Jan 2007 03:58:49 +1100 (EST) Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JB5001NIDU0I890@kenny.its.monash.edu.au> for dna@eng.monash.edu.au; Mon, 01 Jan 2007 03:58:49 +1100 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBVGwjfR002050 for ; Sun, 31 Dec 2006 11:58:46 -0500 Date: Sun, 31 Dec 2006 18:58:44 +0200 From: "Romascanu, Dan (Dan)" Subject: [DNA] RE: Last Call: 'Link-layer Event Notifications for Detecting Network Attachments' to Informational RFC (draft-ietf-dna-link-information) Sender: owner-dna@ecselists.eng.monash.edu.au To: iesg@ietf.org, dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-topic: Last Call: 'Link-layer Event Notifications for Detecting Network Attachments' to Informational RFC (draft-ietf-dna-link-information) Thread-index: AccdOI+1TR3wttb+TV2a1AYVSeAekwPwcQxQ Content-class: urn:content-classes:message X-Scanner: InterScan AntiVirus for Sendmail X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 I apologize for the last day comments. I am still in time however, I hope. 1. The strategy and heuristics described in 2.4.2 and 2.4.3 for detecting the presence of a bridge port and the link-up connectivity could be improved by using the IEEE 802.1X Port Based Network Access Control Standard http://www.ieee802.org/1/pages/802.1x.html. This protocol involves interaction between the host and the attachment port on a bridge, which happens prior to the other control protocols like STP/RSTP and 802.1AB being activated, actually those are allowed to run only if the security framework allows authenticated access of the host to the network. The exchange of information and credentials includes the identification of the host and bridge respectively. 2. In 2.4.2 - ' Where the host is not running STP itself, no explicit indication that forwarding has begun is sent from a bridge.' - well, hosts never run STP, only bridges do. 3. another nit in 2.4.3 - 'Where a host receives the Systems Capabilities TLV which indicate that no Bridging or Repeating is occurring on the LLDP transmitter, then no delays for STP calculation will be applied to packets sent through this transmitter, if the host does not perform STP itself. Again, hosts do not perform STP. Also only Bridging should be mentioned here, as only bridges run STP, repeaters do not. 4. The Security Consideration section could refer when speaking about 'authentication, replay and integrity protection of link-layer management messages' to the IEEE 802.1AE standard - Media Access Control (MAC) Security http://www.ieee802.org/1/pages/802.1ae.html which was approved by the IEEE in June 2006 Dan > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org] > Sent: Monday, December 11, 2006 5:20 PM > To: IETF-Announce > Cc: dna@eng.monash.edu.au > Subject: Last Call: 'Link-layer Event Notifications for > Detecting Network Attachments' to Informational RFC > (draft-ietf-dna-link-information) > > The IESG has received a request from the Detecting Network > Attachment WG to consider the following document: > > - 'Link-layer Event Notifications for Detecting Network Attachments ' > as an Informational RFC > > 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 2006-12-31. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-dna-link-inform > ation-05.txt > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > From dna-owner@webcamserver.eng.monash.edu.au Mon Jan 01 19:19:49 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1XNd-0002o5-Mw for dna-archive@lists.ietf.org; Mon, 01 Jan 2007 19:19:49 -0500 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1XNY-0001nS-8v for dna-archive@lists.ietf.org; Mon, 01 Jan 2007 19:19:49 -0500 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01MBGA2WYS0A8YAH4U@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 02 Jan 2007 11:19:31 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3C51180004; Tue, 02 Jan 2007 11:19:27 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 033753C006; Tue, 02 Jan 2007 11:19:27 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l020BmR13845 for dna-list; Tue, 02 Jan 2007 11:11:48 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l0204lH11141 for ; Tue, 02 Jan 2007 11:04:47 +1100 Received: from stan.its.monash.edu.au ([130.194.13.165]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01MAZGEQ6IFW8WZDF2@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 21 Dec 2006 10:17:18 +1100 Received: from spam-daemon.stan.its.monash.edu.au by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JAL00D2QI0RH100@stan.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 21 Dec 2006 10:17:18 +1100 (EST) Received: from imr1.ericy.com ([198.24.6.9]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JAL00G01DBNUT00@stan.its.monash.edu.au> (original mail from suresh.krishnan@ericsson.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 21 Dec 2006 10:14:26 +1100 (EST) Received: from imr1.ericy.com ([198.24.6.9]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JAL00742HW1MC20@stan.its.monash.edu.au> for dna@eng.monash.edu.au; Thu, 21 Dec 2006 10:14:26 +1100 (EST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id kBKNENqs022965; Wed, 20 Dec 2006 17:14:24 -0600 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 17:14:23 -0600 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 17:14:23 -0600 Date: Wed, 20 Dec 2006 18:14:40 -0500 From: Suresh Krishnan Subject: [DNA] Re: Last Call: 'Link-layer Event Notifications for Detecting Network Attachments' to Informational RFC (draft-ietf-dna-link-information) In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Pekka Savola Cc: iesg@ietf.org, dna@eng.monash.edu.au, dna-chairs@tools.ietf.org Message-id: <4589C3E0.4050302@ericsson.com> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (X11/20060313) X-Spam-Level: References: <45886ED7.9060807@ericsson.com> X-OriginalArrivalTime: 20 Dec 2006 23:14:23.0232 (UTC) FILETIME=[95E71800:01C7248C] X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hi Pekka, I do not see what you mean by "implementation hints should be removed or reworded". Do you mean not using normative language? Cheers Suresh Pekka Savola wrote: > On Tue, 19 Dec 2006, Suresh Krishnan wrote: >>> I do however have one bigger "meta-comment". The draft is aiming >>> Informational, but includes normative specification (also in >>> uppercase). >>> What is the goal of this draft? Offer information on how various link >>> layers specify L2 notifications (aimed at the general public/background >>> for DNA WG, and possibly implementors), and/or to make implementation >>> specifications of its own (aimed at implementors)? >> >> It is the former. > > In that case I think the recommendations ("implementation hints") should > be removed or reworded in such a way impact (or lack thereof) is > clearer. For example, draft-ietf-dkim-base-07.txt includes some similar > text but it's clearly separated from the rest; that might be one way to > go, but other approaches are probably also possible. > From dna-owner@webcamserver.eng.monash.edu.au Mon Jan 01 19:20:32 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1XOK-00030y-BM for dna-archive@lists.ietf.org; Mon, 01 Jan 2007 19:20:32 -0500 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1XOH-0001za-46 for dna-archive@lists.ietf.org; Mon, 01 Jan 2007 19:20:32 -0500 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01MBGA2R4D9S8X1JGA@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 02 Jan 2007 11:19:57 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 30513AB547; Tue, 02 Jan 2007 11:19:19 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id EC9454FB02; Tue, 02 Jan 2007 11:19:18 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l020Cus14774 for dna-list; Tue, 02 Jan 2007 11:12:56 +1100 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l0201tH10030 for ; Tue, 02 Jan 2007 11:01:55 +1100 Received: from kenny.its.monash.edu.au ([130.194.13.164]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01MB15COLZWU8WWV4W@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 22 Dec 2006 15:22:40 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JAN00J01MTM2V00@kenny.its.monash.edu.au> (original mail from Greg.Daley@eng.monash.edu.au) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 22 Dec 2006 15:22:40 +1100 (EST) Received: from curly.its.monash.edu.au ([130.194.13.87]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JAN00I43QTS8O70@kenny.its.monash.edu.au> for dna@eng.monash.edu.au; Fri, 22 Dec 2006 15:22:40 +1100 (EST) Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 345D5AB543; Fri, 22 Dec 2006 15:22:40 +1100 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by curly.its.monash.edu.au (Postfix) with ESMTP id 1EC524FB03; Fri, 22 Dec 2006 15:22:40 +1100 (EST) Received: from [203.8.7.222] by mail-store-2.its.monash.edu.au (mshttpd); Fri, 22 Dec 2006 15:22:39 +1100 Date: Fri, 22 Dec 2006 15:22:39 +1100 From: Greg Daley Subject: [DNA] Re: Last Call: 'Link-layer Event Notifications for Detecting Network Attachments' to Informational RFC (draft-ietf-dna-link-information) In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Pekka Savola Cc: Suresh Krishnan , iesg@ietf.org, dna@eng.monash.edu.au, dna-chairs@tools.ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.12 (built May 22 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en References: <45886ED7.9060807@ericsson.com> <4589C3E0.4050302@ericsson.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Dear Pekka, I understand your point about review by peer organizations, if this were a standards or BCP document. It is purely informational, and has been reviewed by several people who have worked both within IETF and other organizations, without formal liaison with other organizations. The document has received extensive review, as described in: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=45426 No document would be compliant with an informational RFC in any case, so I can't really see the point of your comment regarding implementation compliance. Informational documents are often used to provide technical guidance based on the behaviour of particular protocols (rather than the standards bodies that originally developed them). This is the case with this document, and I can't see that there's a particular reason to avoid that if the guidance is generally useful. Regarding the value of implementation hints in general: identification of the applicability, and delineating what is useful in some situations, is perhaps worthwhile. At this late stage though, any particular guidance or text you can provide to assist this would be illustrative. I'm not sure that this would be absolutely necessary to block the document, but if there's a straightforward resolution, perhaps changes could be made. (Sorry, but I will be incommunicado again until 8 jan). Greg ----- Original Message ----- From: Pekka Savola Date: Thursday, December 21, 2006 5:05 pm Subject: Re: Last Call: 'Link-layer Event Notifications for Detecting Network Attachments' to Informational RFC (draft-ietf-dna-link-information) To: Suresh Krishnan Cc: iesg@ietf.org, dna@eng.monash.edu.au, dna-chairs@tools.ietf.org > On Wed, 20 Dec 2006, Suresh Krishnan wrote: > > I do not see what you mean by "implementation hints should be > removed or > > reworded". Do you mean not using normative language? > > I mean that if the intent of this document is just to describe the > specifications or implementations in general (for general > background), > it should not try to give advice on implementations. Doing so is > problematic for multiple reasons; first, the IETF is not in charge > of > developing these techniques, and any 'hints' we give need to be > carefully reviewed (via the liaison process) by the authoritative > organizations. Second, it confuses the meaning of this draft if > you > expect that implementations would say "compliant with > draft-ietf-dna-link-information". Third, giving these hints may > not > be appropriate in an Informational document, i.e., it might require > wider review (though I don't have a strong opinion on this). > > All in all, it would be clearer if there were no implementation > hints > at all, but if those were clearly marked (example: the DKIM base > spec) > and in lowercase, it might be clear enough. > > Another way to approach this is to remove recommendation about > implementation hints but describe them like 'Some implementations > implement FOO which has XXX benefit for DNA purposes, with YYY > drawbacks", i.e., more like what implementations are doing (and > why) rather than what they should do. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > From dna-owner@webcamserver.eng.monash.edu.au Tue Jan 02 10:30:41 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1lb0-0000NM-N6 for dna-archive@lists.ietf.org; Tue, 02 Jan 2007 10:30:34 -0500 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1lXf-0005xf-K6 for dna-archive@lists.ietf.org; Tue, 02 Jan 2007 10:27:09 -0500 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01MBH5R0T2YI8WXETZ@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 03 Jan 2007 02:26:55 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 57F3EAB543; Wed, 03 Jan 2007 02:26:54 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 1D3124FB04; Wed, 03 Jan 2007 02:26:54 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l02FKDk27287 for dna-list; Wed, 03 Jan 2007 02:20:13 +1100 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l02FKBH27283 for ; Wed, 03 Jan 2007 02:20:12 +1100 Received: from stan.its.monash.edu.au ([130.194.13.165]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01MBH5IJYRAY8Y8WYR@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 03 Jan 2007 02:20:05 +1100 Received: from spam-daemon.stan.its.monash.edu.au by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JB800M0QYLGBF00@stan.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 03 Jan 2007 02:20:04 +1100 (EST) Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JB800601TJXDD00@stan.its.monash.edu.au> (original mail from dromasca@avaya.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 03 Jan 2007 02:19:56 +1100 (EST) Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JB8005X0YL6GUD0@stan.its.monash.edu.au> for dna@eng.monash.edu.au; Wed, 03 Jan 2007 02:19:56 +1100 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l02FJnWP014183 for ; Tue, 02 Jan 2007 10:19:49 -0500 Date: Tue, 02 Jan 2007 17:19:48 +0200 From: "Romascanu, Dan (Dan)" Subject: [DNA] RE: Last Call: 'Link-layer Event Notifications for Detecting Network Attachments' to Informational RFC (draft-ietf-dna-link-information) Sender: owner-dna@ecselists.eng.monash.edu.au To: Sam Hartman Cc: iesg@ietf.org, dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-topic: Last Call: 'Link-layer Event Notifications for Detecting Network Attachments' to Informational RFC (draft-ietf-dna-link-information) Thread-index: Accufzny6bzRsBczSYqn1iYLjiHqZAAAWVvA Content-class: urn:content-classes:message X-Scanner: InterScan AntiVirus for Sendmail X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Sam, you are correct that there the management entities on bridges can be looked at as hosts that also do bridging. This is however an exception, and to the best of my understanding the document targets the general case of attached hosts. To your second point, I am not aware about operating systems that use bridging and run STP between interfaces on hosts (again, bridges themselves excluded) but I may not know all. Dan > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Tuesday, January 02, 2007 5:03 PM > To: Romascanu, Dan (Dan) > Cc: iesg@ietf.org; dna@eng.monash.edu.au > Subject: Re: Last Call: 'Link-layer Event Notifications for > Detecting Network Attachments' to Informational RFC > (draft-ietf-dna-link-information) > > Dan, while I agree that only bridges run STP, there are > devices that are both hosts and bridges. First, most bridges > have management interfaces. Second, it's actually reasonably > common to get a consumer operating system into a mode where > it is bridging (or considering > bridging) two ports together and thus participates in the STP > instance. > From dna-owner@webcamserver.eng.monash.edu.au Sun Jan 07 17:45:28 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3glc-0005ME-Ct for dna-archive@lists.ietf.org; Sun, 07 Jan 2007 17:45:28 -0500 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3glZ-0004Fv-2M for dna-archive@lists.ietf.org; Sun, 07 Jan 2007 17:45:28 -0500 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01MBOKI3Z1OO8Y9IZ0@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 08 Jan 2007 09:44:45 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 55666AB543; Mon, 08 Jan 2007 09:44:22 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 18C4F4FB03; Mon, 08 Jan 2007 09:44:22 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l07Md2l27958 for dna-list; Mon, 08 Jan 2007 09:39:02 +1100 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l07McvH27954 for ; Mon, 08 Jan 2007 09:38:57 +1100 Received: from cartman.its.monash.edu.au ([130.194.13.166]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01MBOKB9RYS08X2Q0Z@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 08 Jan 2007 09:38:52 +1100 Received: from larry.its.monash.edu.au ([130.194.13.82]) by cartman.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JBI00I01RJ05F00@cartman.its.monash.edu.au> (original mail from Greg.Daley@eng.monash.edu.au) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 08 Jan 2007 09:38:51 +1100 (EST) Received: from larry.its.monash.edu.au ([130.194.13.82]) by cartman.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JBI00IQZS8NZR10@cartman.its.monash.edu.au> for dna@eng.monash.edu.au; Mon, 08 Jan 2007 09:38:51 +1100 (EST) Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 77B1C80002; Mon, 08 Jan 2007 09:38:51 +1100 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by larry.its.monash.edu.au (Postfix) with ESMTP id 628373C004; Mon, 08 Jan 2007 09:38:51 +1100 (EST) Received: from [203.8.7.222] by mail-store-2.its.monash.edu.au (mshttpd); Mon, 08 Jan 2007 09:38:50 +1100 Date: Mon, 08 Jan 2007 09:38:50 +1100 From: Greg Daley Subject: [DNA] Re: Last Call: 'Link-layer Event Notifications for Detecting Network Attachments' to Informational RFC (draft-ietf-dna-link-information) In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Sam Hartman Cc: Pekka Savola , dna@eng.monash.edu.au, dna-chairs@tools.ietf.org, Suresh Krishnan , iesg@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.12 (built May 22 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en References: <45886ED7.9060807@ericsson.com> <4589C3E0.4050302@ericsson.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Hi Sam, The document has not been aimed at informational to reduce the requirements for review. The document has always been viewed as informational as it was intended to provide context for implementors of DNA solutions which require link-up indications. There are no standards recommendations in the document. No packets are transferred and no protocol is defined. What is provided are pointers for constructing internal APIs, which as I understand, are not normally defined in IETF standards documents. The difference with this document is that it relies upon packet transfer behaviour of lower layer protocols. The descriptions of protocols have been provided to illustrate where packet transfer is available, and each has been reviewed by experts on the subject matter. The decision of whether to make liaisons with other organizations formal or informal was made with the ADs. So is the question you have regarding the quality of the review, or on the process itself? Greg ----- Original Message ----- From: Sam Hartman Date: Monday, December 25, 2006 1:56 pm Subject: Re: Last Call: 'Link-layer Event Notifications for Detecting Network Attachments' to Informational RFC (draft-ietf-dna-link-information) To: Greg Daley Cc: Pekka Savola , dna@eng.monash.edu.au, dna-chairs@tools.ietf.org, Suresh Krishnan , iesg@ietf.org > >>>>> "Greg" == Greg Daley writes: > > Greg> Dear Pekka, I understand your point about review by peer > Greg> organizations, if this were a standards or BCP document. > > Greg> It is purely informational, and has been reviewed by several > Greg> people who have worked both within IETF and other > Greg> organizations, without formal liaison with other > Greg> organizations. > > I'm uncomfortable with the practice of marking a document > informational to reduce the review required and to avoid coming to > consensus on important issues. > > > I'd like to understand in this instance why informational requires > less review than for another document category? Do you intend this to > be an ietf consensus recommendation? If so, why does it require less > review? If not, what is the value in publishing? > > From usagi_kirin@ocn.ne.jp Thu Jan 11 07:25:14 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4yza-0002kO-Ix for DNA-ARCHIVE@LISTS.IETF.ORG; Thu, 11 Jan 2007 07:25:14 -0500 Received: from [218.61.104.151] (helo=allabout.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4yzQ-0000rg-Pg for DNA-ARCHIVE@LISTS.IETF.ORG; Thu, 11 Jan 2007 07:25:14 -0500 Received: from kevcko9 (unknown [107.206.188.33]) by smtp36 (Coremail) with SMTP id 4xksG6eI7KaCsEbI.1 for ; Thu, 11 Jan 2007 20:25:06 +0800 (CST) X-Originating-IP: [107.206.188.33] Subject: =?iso-2022-jp?B?GyRCTyJNbUBoOHgzKyJ2GyhC?= From: =?shift-jis?B?cmlla28=?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0192_01C6F135.436D38F0" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f This is a multi-part message in MIME format. ------=_NextPart_000_0192_01C6F135.436D38F0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit SEXしてくれる女性を確実に見つけられます　http://vqlh.com/?fs28 全て無料で使えるのでお試し下さい /_/_/_/_/_/_/_/_/_/_/_/_/_/ メール不要 ever_green_1313@yahoo.fr /_/_/_/_/_/_/_/_/_/_/_/_/_/ ------=_NextPart_000_0192_01C6F135.436D38F0 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
SEX=1B$B$7$F$/$l$k=3Dw@-$r3Nhttp://vqlh.com/?fs28
=1B$BA4$FL5NA$G;H$($k$N$G$*;n$72<$5$$=1B(B
=
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
/_/_/_/_/_/_/_/_/_/_/_/_/_/
=1B$B%a!<%kITMW=1B(B
ever_green_1313@yahoo.fr
/_/_/_/_/_/_/_/_/_/_/_/_/_/
 
 
------=_NextPart_000_0192_01C6F135.436D38F0-- From dna-owner@webcamserver.eng.monash.edu.au Mon Jan 15 18:45:20 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6bVw-0006cJ-O3 for dna-archive@lists.ietf.org; Mon, 15 Jan 2007 18:45:20 -0500 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6bVu-0008GU-N5 for dna-archive@lists.ietf.org; Mon, 15 Jan 2007 18:45:20 -0500 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01MBZSXYCR1S8X4A1W@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 16 Jan 2007 10:45:08 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4AAD0AB543; Tue, 16 Jan 2007 10:44:55 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 0B9CC4FB04; Tue, 16 Jan 2007 10:44:55 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l0FNgL514385 for dna-list; Tue, 16 Jan 2007 10:42:21 +1100 Received: from kyle.its.monash.edu.au (kyle.its.monash.edu.au [130.194.13.163]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l0FNgGH14379 for ; Tue, 16 Jan 2007 10:42:17 +1100 Received: from spam-daemon.kyle.its.monash.edu.au by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JBX00D1EOIGSC00@kyle.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 16 Jan 2007 10:42:17 +1100 (EST) Received: from imr2.ericy.com ([198.24.6.3]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JBX00901NAOAE00@kyle.its.monash.edu.au> (original mail from suresh.krishnan@ericsson.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 16 Jan 2007 10:42:08 +1100 (EST) Received: from imr2.ericy.com ([198.24.6.3]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JBX00GZXOI63XE0@kyle.its.monash.edu.au> for dna@eng.monash.edu.au; Tue, 16 Jan 2007 10:42:08 +1100 (EST) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l0G04DVB014652; Mon, 15 Jan 2007 18:04:14 -0600 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 17:42:04 -0600 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 17:42:04 -0600 Date: Mon, 15 Jan 2007 18:45:37 -0500 From: Suresh Krishnan Subject: [DNA] Re: Last Call: 'Link-layer Event Notifications for Detecting Network Attachments' to Informational RFC (draft-ietf-dna-link-information) In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Sam Hartman Cc: Greg Daley , Pekka Savola , dna@eng.monash.edu.au, dna-chairs@tools.ietf.org, iesg@ietf.org Message-id: <45AC1221.1060403@ericsson.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (X11/20060313) X-Spam-Level: References: <45886ED7.9060807@ericsson.com> <4589C3E0.4050302@ericsson.com> X-OriginalArrivalTime: 15 Jan 2007 23:42:04.0307 (UTC) FILETIME=[C2B88630:01C738FE] X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Hi Sam, Thanks for the review. Sorry I could not reply earlier since I was on vacation. Please find comments inline. Thanks Suresh Sam Hartman wrote: > I'm uncomfortable with the practice of marking a document > informational to reduce the review required and to avoid coming to > consensus on important issues. > I can assure you this is not the case. The document has had extensive review both within the WG and outside the WG. Greg was talking about a formal liaison review (with related SDOs) not being done. > > I'd like to understand in this instance why informational requires > less review than for another document category? Do you intend this to > be an ietf consensus recommendation? If so, why does it require less > review? If not, what is the value in publishing? As I said earlier, this document has had extensive review. It is indeed a consensus recommendation from the dna wg. From dna-owner@webcamserver.eng.monash.edu.au Mon Jan 15 19:03:56 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6bnw-00039v-QG for dna-archive@lists.ietf.org; Mon, 15 Jan 2007 19:03:56 -0500 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6bnt-0003H4-Mn for dna-archive@lists.ietf.org; Mon, 15 Jan 2007 19:03:56 -0500 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01MBZTKT10OK8YAHX1@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 16 Jan 2007 11:03:36 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1E7A580003; Tue, 16 Jan 2007 11:03:25 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id CA4653C008; Tue, 16 Jan 2007 11:03:24 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l0G02Xs14517 for dna-list; Tue, 16 Jan 2007 11:02:33 +1100 Received: from cartman.its.monash.edu.au (cartman.its.monash.edu.au [130.194.13.166]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l0G02WH14513 for ; Tue, 16 Jan 2007 11:02:32 +1100 Received: from spam-daemon.cartman.its.monash.edu.au by cartman.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JBX00E75PG5JS00@cartman.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 16 Jan 2007 11:02:32 +1100 (EST) Received: from imr2.ericy.com ([198.24.6.3]) by cartman.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JBX00701NLSZ100@cartman.its.monash.edu.au> (original mail from suresh.krishnan@ericsson.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 16 Jan 2007 11:02:14 +1100 (EST) Received: from imr2.ericy.com ([198.24.6.3]) by cartman.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JBX00184PFPBP50@cartman.its.monash.edu.au> for dna@eng.monash.edu.au; Tue, 16 Jan 2007 11:02:14 +1100 (EST) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l0G0OKpb021202; Mon, 15 Jan 2007 18:24:20 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 18:02:11 -0600 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 18:02:11 -0600 Date: Mon, 15 Jan 2007 19:05:44 -0500 From: Suresh Krishnan Subject: Re: [DNA] RE: Last Call: 'Link-layer Event Notifications for Detecting Network Attachments' to Informational RFC (draft-ietf-dna-link-information) In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: "Romascanu, Dan (Dan)" Cc: iesg@ietf.org, dna@eng.monash.edu.au Message-id: <45AC16D8.30201@ericsson.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (X11/20060313) X-Spam-Level: References: X-OriginalArrivalTime: 16 Jan 2007 00:02:11.0311 (UTC) FILETIME=[9226B7F0:01C73901] X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Hi Dan, Thanks for the review. Sorry I could not reply earlier since I was on vacation. Please find comments inline. Thanks Suresh Romascanu, Dan (Dan) wrote: > I apologize for the last day comments. I am still in time however, I > hope. > > 1. The strategy and heuristics described in 2.4.2 and 2.4.3 for > detecting the presence of a bridge port and the link-up connectivity > could be improved by using the IEEE 802.1X Port Based Network Access > Control Standard http://www.ieee802.org/1/pages/802.1x.html. This > protocol involves interaction between the host and the attachment port > on a bridge, which happens prior to the other control protocols like > STP/RSTP and 802.1AB being activated, actually those are allowed to run > only if the security framework allows authenticated access of the host > to the network. The exchange of information and credentials includes the > identification of the host and bridge respectively. Would you like me to add a sub section regarding 802.1X? > > 2. In 2.4.2 - ' Where the host is not running STP itself, no explicit > indication that forwarding has begun is sent from a bridge.' - well, > hosts never run STP, only bridges do. OK. Will this text work? "A host connected to a bridge port does not receive any explicit indication that the bridge has started forwarding packets." > > 3. another nit in 2.4.3 - > > 'Where a host receives the Systems Capabilities TLV which > indicate that no Bridging or Repeating is occurring on the LLDP > transmitter, then no delays for STP calculation will be applied to > packets sent through this transmitter, if the host does not perform > STP itself. > > Again, hosts do not perform STP. Also only Bridging should be mentioned > here, as only bridges run STP, repeaters do not. Will replace with "Where a host receives the Systems Capabilities TLV which indicate that no Bridging is occurring on the LLDP transmitter, then no delays for STP calculation will be applied to packets sent through this transmitter." Is that OK? > > 4. The Security Consideration section could refer when speaking about > 'authentication, replay and integrity protection of link-layer > management messages' to the IEEE 802.1AE standard - Media Access Control > (MAC) Security http://www.ieee802.org/1/pages/802.1ae.html which was > approved by the IEEE in June 2006 OK. Will do. From dna-owner@webcamserver.eng.monash.edu.au Mon Jan 15 19:10:19 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6bu7-0007fh-0r for dna-archive@lists.ietf.org; Mon, 15 Jan 2007 19:10:19 -0500 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6bu5-0004C0-3e for dna-archive@lists.ietf.org; Mon, 15 Jan 2007 19:10:19 -0500 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01MBZTSJSZY28YAHX1@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 16 Jan 2007 11:09:52 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6B94E80004; Tue, 16 Jan 2007 11:09:35 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 23F293C006; Tue, 16 Jan 2007 11:09:35 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l0G094w14594 for dna-list; Tue, 16 Jan 2007 11:09:04 +1100 Received: from kenny.its.monash.edu.au (kenny.its.monash.edu.au [130.194.13.164]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l0G093H14590 for ; Tue, 16 Jan 2007 11:09:03 +1100 Received: from spam-daemon.kenny.its.monash.edu.au by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JBX00N0KPR21N00@kenny.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 16 Jan 2007 11:09:04 +1100 (EST) Received: from imr2.ericy.com ([198.24.6.3]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JBX00801LWR4H00@kenny.its.monash.edu.au> (original mail from suresh.krishnan@ericsson.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 16 Jan 2007 11:08:57 +1100 (EST) Received: from imr2.ericy.com ([198.24.6.3]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JBX00591PQW72B0@kenny.its.monash.edu.au> for dna@eng.monash.edu.au; Tue, 16 Jan 2007 11:08:57 +1100 (EST) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l0G0UqjN023323; Mon, 15 Jan 2007 18:30:52 -0600 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 18:08:43 -0600 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 18:08:43 -0600 Date: Mon, 15 Jan 2007 19:12:16 -0500 From: Suresh Krishnan Subject: [DNA] Re: Review of: 'Link-layer Event Notifications for Detecting Network Attachments' to Informational RFC (draft-ietf-dna-link-information) In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Matt Mathis Cc: The IESG , montavont@dpt-info.u-strasbg.fr, Lars Eggert , lars.eggert@nokia.com, dna@eng.monash.edu.au Message-id: <45AC1860.90105@ericsson.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (X11/20060313) X-Spam-Level: References: <1B299A0E-FB62-42E0-AC5E-31DB69252E9D@netlab.nec.de> X-OriginalArrivalTime: 16 Jan 2007 00:08:43.0079 (UTC) FILETIME=[7BA9C570:01C73902] X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Hi Matt, Thanks for the review. Sorry I could not reply earlier since I was on vacation. Please find comments inline. Thanks Suresh Matt Mathis wrote: > This document is an informational catalog of link state information available > from well-known access technologies, yet many portions read like a standard, > including the use of prescriptive language and RFC 2119 terminology. This is > likely to be confusing to future implementers. > > For example: > > "If a link up with the R-flag set was generated, another link up MUST > follow up as soon as.... The event attributes MUST indicate > whether the packets transmitted since the previous notification were > presumed to be blocked (B-flag) or allowed (A-flag) ... > > Where "R-flag", "B-flag" and "A-flag" are constructs of this draft and not > some other document. > > In many parts of the document, standards language is used to emphasize > relationships that are implicit in the definitions. For example it defines > "Link up" to be an event signifying that the interface has become capable of > communicating data packets (my paraphrase). The document tends to say > something like "Event X MUST generate Link-Up ..... which MUST be signaled to > the IP layer" (my rewrite), rather than "The [device] becomes capable of > communicating data packets on event X, so (by definition) it is Link-Up." Do you feel strongly about the normative language in the document? If so we can spend some time to rewrite the text. But since it is an informational document, no one can really claim compatibility to draft-ietf-dna-link-information, can they? > > For some of the specific link technologies, this language seems to be an > after-the-fact specification of how current implementations actually work. > Most of the document is written in an appropriate observational language: > "Since the [device] becomes capable of communicating data packets on event > [X], this is an appropriate indication of link up." This "observational" > style is by far best for an Informational document. > > It would be appropriate to rewrite all paragraphs using 2119 language, as well > as the less formal "must" used in 3 places. > > Some specific comments: > PDP is not defined OK. Will take care of this. > > It says: "The activation of a such secondary PDP Context MUST NOT generate > another link up event notification." Given that other device types permit > link-up events that do not require new IP parameters, it seems out of place to > forbid this case. (even ignoring the MUST) Perhaps something like "it is not > desirable treat every new PDP context as a link change because...." OK. How about "The activation of such a secondary PDP context does not usually generate a link up event since it does not require new IP parameters". From dna-owner@webcamserver.eng.monash.edu.au Wed Jan 17 18:49:49 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7KXN-0004uP-Fr for dna-archive@lists.ietf.org; Wed, 17 Jan 2007 18:49:49 -0500 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7KXK-0008Sz-Oq for dna-archive@lists.ietf.org; Wed, 17 Jan 2007 18:49:48 -0500 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01MC2LO9GJ168YAQ8E@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 18 Jan 2007 10:49:32 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C7DB9AB545; Thu, 18 Jan 2007 10:49:26 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 901304FB02; Thu, 18 Jan 2007 10:49:26 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l0HNjO608894 for dna-list; Thu, 18 Jan 2007 10:45:24 +1100 Received: from stan.its.monash.edu.au (stan.its.monash.edu.au [130.194.13.165]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l0HNjHs08890 for ; Thu, 18 Jan 2007 10:45:21 +1100 Received: from spam-daemon.stan.its.monash.edu.au by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JC100C5EDZEVB00@stan.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 18 Jan 2007 10:45:17 +1100 (EST) Received: from imr1.ericy.com ([198.24.6.9]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JC100401BLWE700@stan.its.monash.edu.au> (original mail from suresh.krishnan@ericsson.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 18 Jan 2007 10:45:02 +1100 (EST) Received: from imr1.ericy.com ([198.24.6.9]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JC100502DZ0SPA0@stan.its.monash.edu.au> for dna@eng.monash.edu.au; Thu, 18 Jan 2007 10:45:01 +1100 (EST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l0HNijw6031275; Wed, 17 Jan 2007 17:44:45 -0600 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jan 2007 17:44:45 -0600 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jan 2007 17:44:44 -0600 Date: Wed, 17 Jan 2007 18:48:31 -0500 From: Suresh Krishnan Subject: [DNA] Re: Review of: 'Link-layer Event Notifications for Detecting Network Attachments' to Informational RFC (draft-ietf-dna-link-information) In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Matt Mathis Cc: The IESG , montavont@dpt-info.u-strasbg.fr, Lars Eggert , lars.eggert@nokia.com, dna@eng.monash.edu.au Message-id: <45AEB5CF.1030102@ericsson.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (X11/20060313) X-Spam-Level: References: <1B299A0E-FB62-42E0-AC5E-31DB69252E9D@netlab.nec.de> <45AC1860.90105@ericsson.com> X-OriginalArrivalTime: 17 Jan 2007 23:44:44.0942 (UTC) FILETIME=[774AFAE0:01C73A91] X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Hi Matt, Please find comments inline. Thanks Suresh Matt Mathis wrote: > Well, people can quote normative language out of context, which is likely to > be very confusing. At the very least MUST->must (etc) everywhere. I don't > know how picky the IESG is about this. They should be because it dilutes all > standards to allow documents that resemble standards but are not. The document aims to be informational and will be indicated as such in the Category field of the eventual RFC(if any). If you have strong feelings about upper case MUSTs or if the IESG has any problems with this, this would be an easy change to make. > > Defining R-flag etc bother me too, when there are also observational ways to > address this. E.g. device X has multiple up states that have different rules > regarding legal traffic types (e.g link management vs other). "The stack > needs to be informed of which traffic classes are permitted at any given > time...." The risk here is that your text partially describes one particular > implementation, which may not be the only way to solve the problem. Do you > meant to imply other solutions are incorrect? No. The R-flag just implies that the link up event is not deterministic and the link layer is not sure whether the packet will get through. From dna-owner@webcamserver.eng.monash.edu.au Thu Jan 18 16:01:05 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7eNd-0004gZ-8D for dna-archive@lists.ietf.org; Thu, 18 Jan 2007 16:01:05 -0500 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7eNb-0000Xx-5m for dna-archive@lists.ietf.org; Thu, 18 Jan 2007 16:01:05 -0500 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01MC3U3MB6EQ8YD17H@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 19 Jan 2007 08:00:57 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id DDE8AAB543; Fri, 19 Jan 2007 08:00:48 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id AAED14FB03; Fri, 19 Jan 2007 08:00:48 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l0IKwXd14188 for dna-list; Fri, 19 Jan 2007 07:58:33 +1100 Received: from stan.its.monash.edu.au (stan.its.monash.edu.au [130.194.13.165]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l0IKwXs14184 for ; Fri, 19 Jan 2007 07:58:33 +1100 Received: from spam-daemon.stan.its.monash.edu.au by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JC300D0H0XJZ700@stan.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 19 Jan 2007 07:58:33 +1100 (EST) Received: from oak.research.panasonic.com ([150.169.1.4]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JC200601YOXU100@stan.its.monash.edu.au> (original mail from sathya@research.panasonic.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 19 Jan 2007 07:58:27 +1100 (EST) Received: from oak.research.panasonic.com ([150.169.1.4]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JC300MTC0XD6H90@stan.its.monash.edu.au> for dna@eng.monash.edu.au; Fri, 19 Jan 2007 07:58:27 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with ESMTP id l0IKwPDx025905 for ; Thu, 18 Jan 2007 15:58:25 -0500 Received: from [150.169.1.185] ([150.169.1.185]) by redwood.research.panasonic.com (MOS 3.7.4b-GA) with ESMTP id AQC50848; Thu, 18 Jan 2007 15:56:58 -0500 (EST) Date: Thu, 18 Jan 2007 15:56:34 -0500 From: Sathya Narayanan Subject: Re: [DNA] Issue 1: Use of 1.5 hours in the text In-reply-to: <92e919fb0611162100tb4eae2fsce899cfb697d1218@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Message-id: <45AFDF02.1090601@Research.Panasonic.COM> Organization: Panasonic Technologies Company MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Spam-Level: References: <45537862.4060803@Research.Panasonic.COM> <92e919fb0611162100tb4eae2fsce899cfb697d1218@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 I am starting to close the issues and would like to generate the next version of the draft before the end of next week. I am closing this issue, by replacing the 1.5 hours requirement with 3 times maximum of MaxRtrAdvInterval. - Sathya JinHyeock Choi wrote: > Dear Sathya > >> Issue: WiMAX is trying to increase the MaxRtrAdvInterval into hours or >> days. Should we change 1.5 hours to 3 * MaxRtrAdvInterval? > > > I think there is a misunderstanding. 1.5 hour is computed as 3 * 30 mins, > where 30 mins is NOT MaxRtrAdvInterval BUT Maximum MaxRtrAdvInterval. > (I am confused about MaxRtrAdvInterval and Maximum MaxRtrAdvInterval. > :-() > > MaxRtrAdvInterval can be any value between 3 secs and 1800 secs as below. > > MaxRtrAdvInterval > The maximum time allowed between sending > unsolicited multicast Router Advertisements from > the interface, in seconds. MUST be no less than 4 > seconds and no greater than 1800 seconds. > > Default: 600 seconds > >> Agreement at the meeting: Yes. Lets make the change. We need to include >> the MaxRtrAdvInterval in the RA so that the hosts can know about the >> value. If different routers on the link use different values for >> MaxRtrAdvInterval, host should use the minimum (Should it be maximum?) >> value of MaxRtsAdvtInterval times three as the lifetime for prefixes in >> the DNAHostPrefixList. >> >> If you have any objection to the proposed change, please post your >> objection on the list. > > > I propose to use 3 * Maximum MaxRtrAdvInterval as prefix lifetime. > > Best Regards > > JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Jan 18 16:10:41 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7eWv-0002Il-Du for dna-archive@lists.ietf.org; Thu, 18 Jan 2007 16:10:41 -0500 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7eWs-0002Ms-LF for dna-archive@lists.ietf.org; Thu, 18 Jan 2007 16:10:41 -0500 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01MC3UF8VVFK8YB3Q0@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 19 Jan 2007 08:10:27 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A50C880002; Fri, 19 Jan 2007 08:10:16 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 6D9F13C007; Fri, 19 Jan 2007 08:10:16 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l0IL9vE14271 for dna-list; Fri, 19 Jan 2007 08:09:57 +1100 Received: from kyle.its.monash.edu.au (kyle.its.monash.edu.au [130.194.13.163]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l0IL9us14266 for ; Fri, 19 Jan 2007 08:09:56 +1100 Received: from spam-daemon.kyle.its.monash.edu.au by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JC30041Z1GKXE00@kyle.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 19 Jan 2007 08:09:56 +1100 (EST) Received: from oak.research.panasonic.com ([150.169.1.4]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JC3003010ZKIL00@kyle.its.monash.edu.au> (original mail from sathya@research.panasonic.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 19 Jan 2007 08:09:52 +1100 (EST) Received: from oak.research.panasonic.com ([150.169.1.4]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JC30003L1GE7H40@kyle.its.monash.edu.au> for dna@eng.monash.edu.au; Fri, 19 Jan 2007 08:09:52 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with ESMTP id l0IL9oYR026584 for ; Thu, 18 Jan 2007 16:09:50 -0500 Received: from [150.169.1.185] ([150.169.1.185]) by redwood.research.panasonic.com (MOS 3.7.4b-GA) with ESMTP id AQC51662; Thu, 18 Jan 2007 16:08:24 -0500 (EST) Date: Thu, 18 Jan 2007 16:08:00 -0500 From: Sathya Narayanan Subject: Re: [DNA] Issue 3: Do we need landmark Y/N bit? In-reply-to: <455378D9.4090702@Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Message-id: <45AFE1B0.3000105@Research.Panasonic.COM> Organization: Panasonic Technologies Company MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Spam-Level: References: <455378D9.4090702@Research.Panasonic.COM> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Closed. - Sathya Sathya Narayanan wrote: > Issue: The current text doesn't use the 'N' bit - because we don't > want to waste space on the RA including a No response. The same > functionality of 'Y' bit can be achieved by just including the > landmark prefix in a PIO or a LPO. > > Agreement at the meeting: We remove the Y/N bits from the landmark. > This changes the semantics of a landmark in the RS from a question to > just a statement, the host includes a prefix in the RS to let the > router know which link it thinks it is currently on - the router > confirms it by responding with a RA containing the same prefix or > informs the host that its thinking is wrong by sending a RA not > including the particular prefix, but with as much information as > possible for the host to reconfigure itself. > > Any objections to the change? > > - Sathya > From dna-owner@webcamserver.eng.monash.edu.au Thu Jan 18 16:10:44 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7eWy-0002JL-RL for dna-archive@lists.ietf.org; Thu, 18 Jan 2007 16:10:44 -0500 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7eWv-0002Mz-N3 for dna-archive@lists.ietf.org; Thu, 18 Jan 2007 16:10:44 -0500 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01MC3UF2PH228X4FTT@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 19 Jan 2007 08:10:15 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A13F7AB542; Fri, 19 Jan 2007 07:10:00 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 696FE4FB07; Fri, 19 Jan 2007 07:10:00 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l0IL9pl14263 for dna-list; Fri, 19 Jan 2007 08:09:51 +1100 Received: from stan.its.monash.edu.au (stan.its.monash.edu.au [130.194.13.165]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l0IL9ps14259 for ; Fri, 19 Jan 2007 08:09:51 +1100 Received: from spam-daemon.stan.its.monash.edu.au by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JC300FA51GE6800@stan.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 19 Jan 2007 08:09:51 +1100 (EST) Received: from oak.research.panasonic.com ([150.169.1.4]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JC200601YOXU100@stan.its.monash.edu.au> (original mail from sathya@research.panasonic.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 19 Jan 2007 08:09:47 +1100 (EST) Received: from oak.research.panasonic.com ([150.169.1.4]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JC300MHB1G96DA0@stan.its.monash.edu.au> for dna@eng.monash.edu.au; Fri, 19 Jan 2007 08:09:47 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with ESMTP id l0IL9jnM026579 for ; Thu, 18 Jan 2007 16:09:45 -0500 Received: from [150.169.1.185] ([150.169.1.185]) by redwood.research.panasonic.com (MOS 3.7.4b-GA) with ESMTP id AQC51655; Thu, 18 Jan 2007 16:08:19 -0500 (EST) Date: Thu, 18 Jan 2007 16:07:55 -0500 From: Sathya Narayanan Subject: Re: [DNA] Issue 2: What if no prefix is advertised? In-reply-to: <92e919fb0611162125r4b243f9fie702bdff10649b58@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Message-id: <45AFE1AB.6070105@Research.Panasonic.COM> Organization: Panasonic Technologies Company MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Spam-Level: References: <4553788F.9070009@Research.Panasonic.COM> <92e919fb0611162125r4b243f9fie702bdff10649b58@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 If we are going to mandate that the router advertise one prefix even when stateful autoconfiguration is used and that it must be the smallest prefix, we are implicitly requiring the adminstrator to configure each of these routers with this information, right? Or, are we talking about the routers sniffing DHCP messages - What does it mean? I am leaving this open for now, until I hear comments on this question. - Sathya JinHyeock Choi wrote: >> Issue: If stateful autoconfiguration is used, the routers may not >> advertise any prefix in its RA message. DNA will not work without prefix >> advertised. Current text relies on DHCP confirm message exchange for DNA >> in that case. >> >> Agreement at the meeting: Lets mandate the inclusion of one prefix in >> all RA message, with L= 0 and A=0. But, atleast one prefix is a MUST. >> The router MUST include the smallest prefix either in PIO or LPO of all >> RA messages. >> Note: I am not refering to the smallest prefix as "LinkID" because in >> "Issue 6", I will be proposing the removal of the concept of LinkIDs. >> The forward compatibility advantage of the LinkIDs can be easily >> supported and refer to the email on Issue 6 is further details. >> >> If you have any objections to the proposed change please post your >> objections on the list. > > > I agree and, IMO, the concept of 'LinkID' is of help. It would be > simpler to mandate to include LinkID prefix. > > Best Regards > > JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Jan 18 17:02:55 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7fLT-0007NN-Pj for dna-archive@lists.ietf.org; Thu, 18 Jan 2007 17:02:55 -0500 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7fLO-0001OO-38 for dna-archive@lists.ietf.org; Thu, 18 Jan 2007 17:02:55 -0500 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01MC3W9B4G528YCRPF@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 19 Jan 2007 09:02:47 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1F88F80004; Fri, 19 Jan 2007 09:02:40 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id D4F753C005; Fri, 19 Jan 2007 09:02:39 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l0IM02x14527 for dna-list; Fri, 19 Jan 2007 09:00:02 +1100 Received: from kenny.its.monash.edu.au (kenny.its.monash.edu.au [130.194.13.164]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l0IM02s14523 for ; Fri, 19 Jan 2007 09:00:02 +1100 Received: from spam-daemon.kenny.its.monash.edu.au by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JC300B023S2WK00@kenny.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 19 Jan 2007 09:00:03 +1100 (EST) Received: from oak.research.panasonic.com ([150.169.1.4]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JC200F01XRENW00@kenny.its.monash.edu.au> (original mail from sathya@research.panasonic.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 19 Jan 2007 09:00:02 +1100 (EST) Received: from oak.research.panasonic.com ([150.169.1.4]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JC300GG73S09360@kenny.its.monash.edu.au> for dna@eng.monash.edu.au; Fri, 19 Jan 2007 09:00:02 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with ESMTP id l0IM00EU029160 for ; Thu, 18 Jan 2007 17:00:00 -0500 Received: from [150.169.1.185] ([150.169.1.185]) by redwood.research.panasonic.com (MOS 3.7.4b-GA) with ESMTP id AQC55717; Thu, 18 Jan 2007 16:58:33 -0500 (EST) Date: Thu, 18 Jan 2007 16:58:09 -0500 From: Sathya Narayanan Subject: Re: [DNA] Issue 5, Issue 7, In-reply-to: <92e919fb0611160509s10e07294nd3cb749490f1c100@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Message-id: <45AFED71.8080305@Research.Panasonic.COM> Organization: Panasonic Technologies Company MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Spam-Level: References: <45537932.6030907@Research.Panasonic.COM> <92e919fb0611160509s10e07294nd3cb749490f1c100@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Issues 5 and 7 Closed. Issue 4: Made NumRSRAComplete a constant with value 2, MinRAWait a constant with value 4 seconds. - Sathya JinHyeock Choi wrote: >> Issue 4, was about DNA terminology - I will take care of it. >> >> Issue: There is text about using prior information for detecting link >> change in the text. Do we want to keep something like that? >> >> Agreement at the meeting: No. Lets remove the text. > > > agree. > > JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Fri Jan 19 00:09:38 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7m0Q-00030g-La for dna-archive@lists.ietf.org; Fri, 19 Jan 2007 00:09:38 -0500 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7m0N-0007gS-Fk for dna-archive@lists.ietf.org; Fri, 19 Jan 2007 00:09:38 -0500 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01MC4B58FHS48YD7HY@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 19 Jan 2007 16:09:24 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B224AAB543; Fri, 19 Jan 2007 15:09:06 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 7A5774FB07; Fri, 19 Jan 2007 15:09:06 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l0J54MN16077 for dna-list; Fri, 19 Jan 2007 16:04:22 +1100 Received: from stan.its.monash.edu.au (stan.its.monash.edu.au [130.194.13.165]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l0J54Ls16073 for ; Fri, 19 Jan 2007 16:04:21 +1100 Received: from larry.its.monash.edu.au ([130.194.13.82]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JC300I01MMDBP00@stan.its.monash.edu.au> (original mail from Greg.Daley@eng.monash.edu.au) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 19 Jan 2007 16:04:21 +1100 (EST) Received: from larry.its.monash.edu.au ([130.194.13.82]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JC3007ZQNF9SRA0@stan.its.monash.edu.au> for dna@eng.monash.edu.au; Fri, 19 Jan 2007 16:04:21 +1100 (EST) Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B5DB580002; Fri, 19 Jan 2007 16:04:21 +1100 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by larry.its.monash.edu.au (Postfix) with ESMTP id A0A433C004; Fri, 19 Jan 2007 16:04:21 +1100 (EST) Received: from [203.202.5.75] by mail-store-2.its.monash.edu.au (mshttpd); Fri, 19 Jan 2007 16:04:20 +1100 Date: Fri, 19 Jan 2007 16:04:20 +1100 From: Greg Daley Subject: Re: [DNA] Issue 2: What if no prefix is advertised? In-reply-to: <45AFE1AB.6070105@Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Dna Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.12 (built May 22 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en References: <4553788F.9070009@Research.Panasonic.COM> <92e919fb0611162125r4b243f9fie702bdff10649b58@mail.gmail.com> <45AFE1AB.6070105@Research.Panasonic.COM> X-Spam-Score: 1.8 (+) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Hi Sathya, We have an issue in that routers may already be available which do not advertise a prefix (as it is not precluded). I would suggest that these routers should try to advertise a prefix, be it a learned or native (PIO) prefix. That way routers can participate if they learn of other prefixes. Otherwise, they will still advertise if there are no prefixes known anyway. This will provide hosts with the A= and M= flags sufficient to initiate DHCP (which is not a DNA process but can provide the change detection required). Greg ----- Original Message ----- From: Sathya Narayanan Date: Friday, January 19, 2007 8:10 am Subject: Re: [DNA] Issue 2: What if no prefix is advertised? To: Dna > If we are going to mandate that the router advertise one prefix even > when stateful autoconfiguration is used and that it must be the > smallestprefix, we are implicitly requiring the adminstrator to > configure each > of these routers with this information, right? Or, are we talking > aboutthe routers sniffing DHCP messages - What does it mean? > > I am leaving this open for now, until I hear comments on this > question. > - Sathya > > JinHyeock Choi wrote: > > >> Issue: If stateful autoconfiguration is used, the routers may not > >> advertise any prefix in its RA message. DNA will not work > without prefix > >> advertised. Current text relies on DHCP confirm message exchange > for DNA > >> in that case. > >> > >> Agreement at the meeting: Lets mandate the inclusion of one > prefix in > >> all RA message, with L= 0 and A=0. But, atleast one prefix is a > MUST.>> The router MUST include the smallest prefix either in PIO > or LPO of all > >> RA messages. > >> Note: I am not refering to the smallest prefix as "LinkID" > because in > >> "Issue 6", I will be proposing the removal of the concept of > LinkIDs.>> The forward compatibility advantage of the LinkIDs can > be easily > >> supported and refer to the email on Issue 6 is further details. > >> > >> If you have any objections to the proposed change please post your > >> objections on the list. > > > > > > I agree and, IMO, the concept of 'LinkID' is of help. It would be > > simpler to mandate to include LinkID prefix. > > > > Best Regards > > > > JinHyeock > > > From dna-owner@webcamserver.eng.monash.edu.au Fri Jan 19 15:52:54 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H80jG-0006F0-1X for dna-archive@lists.ietf.org; Fri, 19 Jan 2007 15:52:54 -0500 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H80iz-0007bX-DY for dna-archive@lists.ietf.org; Fri, 19 Jan 2007 15:52:54 -0500 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01MC582ZWQ4I8X4XRS@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 20 Jan 2007 07:52:16 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E7DB3AB544; Sat, 20 Jan 2007 06:51:52 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id B003C4FB04; Sat, 20 Jan 2007 06:51:52 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l0JKne520013 for dna-list; Sat, 20 Jan 2007 07:49:40 +1100 Received: from kenny.its.monash.edu.au (kenny.its.monash.edu.au [130.194.13.164]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l0JKnds20009 for ; Sat, 20 Jan 2007 07:49:39 +1100 Received: from spam-daemon.kenny.its.monash.edu.au by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JC400D1ZV6Q3A00@kenny.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 20 Jan 2007 07:49:39 +1100 (EST) Received: from stl-smtpout-01.ns.cs.boeing.com ([130.76.96.56]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JC400I01POFFQ00@kenny.its.monash.edu.au> (original mail from Fred.L.Templin@boeing.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 20 Jan 2007 07:49:33 +1100 (EST) Received: from stl-smtpout-01.ns.cs.boeing.com ([130.76.96.56]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JC4007G6V6KPOE0@kenny.its.monash.edu.au> for dna@eng.monash.edu.au; Sat, 20 Jan 2007 07:49:33 +1100 (EST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l0JKnVTd025100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 19 Jan 2007 14:49:31 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l0JKnVIE010297; Fri, 19 Jan 2007 14:49:31 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l0JKnQln010127; Fri, 19 Jan 2007 14:49:31 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 12:49:27 -0800 Date: Fri, 19 Jan 2007 12:49:26 -0800 From: "Templin, Fred L" Subject: RE: [DNA] Issue 2: What if no prefix is advertised? In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg.Daley@eng.monash.edu.au, sathya@research.panasonic.com Cc: dna@eng.monash.edu.au Message-id: <39C363776A4E8C4A94691D2BD9D1C9A1017745D7@XCH-NW-7V2.nw.nos.boeing.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 X-MIME-Autoconverted: from quoted-printable to 8bit by webcamserver.eng.monash.edu.au id l0JKnds20010 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-topic: [DNA] Issue 2: What if no prefix is advertised? Thread-index: Acc7iAwRURm0/z+rSginp8mJ6ej5QAAglhCg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Spam-Level: X-OriginalArrivalTime: 19 Jan 2007 20:49:27.0314 (UTC) FILETIME=[4F1FCF20:01C73C0B] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 I haven't followed these discussions closely, but would there be anything wrong with a router advertising a prefix with 'A'='L'=0? Nodes that receive the prefix could consider it as a "landmark prefix" for the link, but would not infer anything further from it such as address configuration expectations, neighbor relationships with other nodes that receive the prefix, etc. Should there be a draft issued to discuss this (or, maybe there already has)? Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Greg Daley [mailto:Greg.Daley@eng.monash.edu.au] > Sent: Thursday, January 18, 2007 9:04 PM > To: Sathya Narayanan > Cc: Dna > Subject: Re: [DNA] Issue 2: What if no prefix is advertised? > > > Hi Sathya, > > We have an issue in that routers may already be available which do > not advertise a prefix (as it is not precluded). > > I would suggest that these routers should try to advertise a prefix, > be it a learned or native (PIO) prefix. > > That way routers can participate if they learn of other prefixes. > Otherwise, they will still advertise if there are no prefixes > known anyway. > This will provide hosts with the A= and M= flags sufficient > to initiate DHCP > (which is not a DNA process but can provide the change > detection required). > > Greg > > ----- Original Message ----- > From: Sathya Narayanan > Date: Friday, January 19, 2007 8:10 am > Subject: Re: [DNA] Issue 2: What if no prefix is advertised? > To: Dna > > > If we are going to mandate that the router advertise one prefix even > > when stateful autoconfiguration is used and that it must be the > > smallestprefix, we are implicitly requiring the adminstrator to > > configure each > > of these routers with this information, right? Or, are we talking > > aboutthe routers sniffing DHCP messages - What does it mean? > > > > I am leaving this open for now, until I hear comments on this > > question. > > - Sathya > > > > JinHyeock Choi wrote: > > > > >> Issue: If stateful autoconfiguration is used, the routers may not > > >> advertise any prefix in its RA message. DNA will not work > > without prefix > > >> advertised. Current text relies on DHCP confirm message exchange > > for DNA > > >> in that case. > > >> > > >> Agreement at the meeting: Lets mandate the inclusion of one > > prefix in > > >> all RA message, with L= 0 and A=0. But, atleast one prefix is a > > MUST.>> The router MUST include the smallest prefix either in PIO > > or LPO of all > > >> RA messages. > > >> Note: I am not refering to the smallest prefix as "LinkID" > > because in > > >> "Issue 6", I will be proposing the removal of the concept of > > LinkIDs.>> The forward compatibility advantage of the LinkIDs can > > be easily > > >> supported and refer to the email on Issue 6 is further details. > > >> > > >> If you have any objections to the proposed change please > post your > > >> objections on the list. > > > > > > > > > I agree and, IMO, the concept of 'LinkID' is of help. It would be > > > simpler to mandate to include LinkID prefix. > > > > > > Best Regards > > > > > > JinHyeock > > > > > > > From dna-owner@webcamserver.eng.monash.edu.au Fri Jan 19 15:56:46 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H80n0-0002SM-Sv for dna-archive@lists.ietf.org; Fri, 19 Jan 2007 15:56:46 -0500 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H80mm-0008Qt-94 for dna-archive@lists.ietf.org; Fri, 19 Jan 2007 15:56:46 -0500 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01MC588B9RNG8YD686@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 20 Jan 2007 07:56:22 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 72D43AB544; Sat, 20 Jan 2007 06:56:03 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 35FEC4FB0A; Sat, 20 Jan 2007 06:56:03 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l0JKu1Z20080 for dna-list; Sat, 20 Jan 2007 07:56:01 +1100 Received: from kenny.its.monash.edu.au (kenny.its.monash.edu.au [130.194.13.164]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l0JKu1s20076 for ; Sat, 20 Jan 2007 07:56:01 +1100 Received: from spam-daemon.kenny.its.monash.edu.au by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JC400E1WVHC2B00@kenny.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 20 Jan 2007 07:56:01 +1100 (EST) Received: from oak.research.panasonic.com ([150.169.1.4]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JC400I01POFFQ00@kenny.its.monash.edu.au> (original mail from sathya@research.panasonic.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 20 Jan 2007 07:55:55 +1100 (EST) Received: from oak.research.panasonic.com ([150.169.1.4]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JC40032NVH5SFC0@kenny.its.monash.edu.au> for dna@eng.monash.edu.au; Sat, 20 Jan 2007 07:55:55 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with ESMTP id l0JKtrpZ003881; Fri, 19 Jan 2007 15:55:53 -0500 Received: from [150.169.17.2] ([150.169.17.2]) by redwood.research.panasonic.com (MOS 3.7.4b-GA) with ESMTP id AQD76673; Fri, 19 Jan 2007 15:54:25 -0500 (EST) Date: Fri, 19 Jan 2007 15:56:01 -0500 From: Sathya Narayanan Subject: Re: [DNA] Issue 2: What if no prefix is advertised? In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: Dna Message-id: <45B13061.7090002@Research.Panasonic.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Spam-Level: References: <4553788F.9070009@Research.Panasonic.COM> <92e919fb0611162125r4b243f9fie702bdff10649b58@mail.gmail.com> <45AFE1AB.6070105@Research.Panasonic.COM> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Hello Greg - I agree with what you have said. But, the open issue is different: the case we are talking about with this issue is when stateful address configuration is used on a particular link. We agreed during the last meeting to mandate the router on such a link to advertise atleast one prefix (the smallest prefix) with A=0 and L=0, so that the hosts can still use the RS/RA exchange to find out about network attachement. At the moment, there is text in the draft for using DHCP CONFIRM - we thought we could remove this text after mandating that routers advertise atleast one prefix. My questions is: how will the routers know about a prefix if stateful address configuration is used - do we understand/agree that the routers MUST be configured with this information (atleast one prefix) even when stateful address configuration is used. Is that acceptable? Sathya >Hi Sathya, > >We have an issue in that routers may already be available which do >not advertise a prefix (as it is not precluded). > >I would suggest that these routers should try to advertise a prefix, >be it a learned or native (PIO) prefix. > >That way routers can participate if they learn of other prefixes. >Otherwise, they will still advertise if there are no prefixes known anyway. >This will provide hosts with the A= and M= flags sufficient to initiate DHCP >(which is not a DNA process but can provide the change detection required). > >Greg > >----- Original Message ----- >From: Sathya Narayanan >Date: Friday, January 19, 2007 8:10 am >Subject: Re: [DNA] Issue 2: What if no prefix is advertised? >To: Dna > > > >>If we are going to mandate that the router advertise one prefix even >>when stateful autoconfiguration is used and that it must be the >>smallestprefix, we are implicitly requiring the adminstrator to >>configure each >>of these routers with this information, right? Or, are we talking >>aboutthe routers sniffing DHCP messages - What does it mean? >> >>I am leaving this open for now, until I hear comments on this >>question. >>- Sathya >> >>JinHyeock Choi wrote: >> >> >> >>>>Issue: If stateful autoconfiguration is used, the routers may not >>>>advertise any prefix in its RA message. DNA will not work >>>> >>>> >>without prefix >> >> >>>>advertised. Current text relies on DHCP confirm message exchange >>>> >>>> >>for DNA >> >> >>>>in that case. >>>> >>>>Agreement at the meeting: Lets mandate the inclusion of one >>>> >>>> >>prefix in >> >> >>>>all RA message, with L= 0 and A=0. But, atleast one prefix is a >>>> >>>> >>MUST.>> The router MUST include the smallest prefix either in PIO >>or LPO of all >> >> >>>>RA messages. >>>>Note: I am not refering to the smallest prefix as "LinkID" >>>> >>>> >>because in >> >> >>>>"Issue 6", I will be proposing the removal of the concept of >>>> >>>> >>LinkIDs.>> The forward compatibility advantage of the LinkIDs can >>be easily >> >> >>>>supported and refer to the email on Issue 6 is further details. >>>> >>>>If you have any objections to the proposed change please post your >>>>objections on the list. >>>> >>>> >>>I agree and, IMO, the concept of 'LinkID' is of help. It would be >>>simpler to mandate to include LinkID prefix. >>> >>>Best Regards >>> >>>JinHyeock >>> >>> >> >> >> From dna-owner@webcamserver.eng.monash.edu.au Sun Jan 21 17:40:14 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8lME-0002Nb-Rw for dna-archive@lists.ietf.org; Sun, 21 Jan 2007 17:40:14 -0500 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8lMA-00055y-R5 for dna-archive@lists.ietf.org; Sun, 21 Jan 2007 17:40:14 -0500 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01MC84F9B79I8WY8I3@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 22 Jan 2007 09:39:53 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 09AB880004; Mon, 22 Jan 2007 09:39:47 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id BC75D3C003; Mon, 22 Jan 2007 09:39:46 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l0LMaiU02280 for dna-list; Mon, 22 Jan 2007 09:36:44 +1100 Received: from kyle.its.monash.edu.au (kyle.its.monash.edu.au [130.194.13.163]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l0LMahs02276 for ; Mon, 22 Jan 2007 09:36:43 +1100 Received: from moe.its.monash.edu.au ([130.194.13.88]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JC800001OTYNC00@kyle.its.monash.edu.au> (original mail from Greg.Daley@eng.monash.edu.au) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 22 Jan 2007 09:36:44 +1100 (EST) Received: from moe.its.monash.edu.au ([130.194.13.88]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JC800AA9PH6X4C0@kyle.its.monash.edu.au> for dna@eng.monash.edu.au; Mon, 22 Jan 2007 09:36:44 +1100 (EST) Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2BBD1AB542; Mon, 22 Jan 2007 08:36:27 +1100 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by moe.its.monash.edu.au (Postfix) with ESMTP id 113464FB0A; Mon, 22 Jan 2007 08:36:27 +1100 (EST) Received: from [203.8.7.222] by mail-store-2.its.monash.edu.au (mshttpd); Mon, 22 Jan 2007 09:36:42 +1100 Date: Mon, 22 Jan 2007 09:36:42 +1100 From: Greg Daley Subject: Re: [DNA] Issue 2: What if no prefix is advertised? In-reply-to: <45B13061.7090002@Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Dna Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.12 (built May 22 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en References: <4553788F.9070009@Research.Panasonic.COM> <92e919fb0611162125r4b243f9fie702bdff10649b58@mail.gmail.com> <45AFE1AB.6070105@Research.Panasonic.COM> <45B13061.7090002@Research.Panasonic.COM> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Hi Sathya, I agree that we can ask DNA routers to do this, and perhaps for DNA purposes MUST is OK. Greg ----- Original Message ----- From: Sathya Narayanan Date: Saturday, January 20, 2007 7:56 am Subject: Re: [DNA] Issue 2: What if no prefix is advertised? To: Greg Daley Cc: Dna > Hello Greg - > > I agree with what you have said. > > But, the open issue is different: the case we are talking about > with > this issue is when stateful address configuration is used on a > particular link. We agreed during the last meeting to mandate the > router > on such a link to advertise atleast one prefix (the smallest > prefix) > with A=0 and L=0, so that the hosts can still use the RS/RA > exchange to > find out about network attachement. At the moment, there is text in > the > draft for using DHCP CONFIRM - we thought we could remove this text > after mandating that routers advertise atleast one prefix. > > My questions is: how will the routers know about a prefix if > stateful > address configuration is used - do we understand/agree that the > routers > MUST be configured with this information (atleast one prefix) even > when > stateful address configuration is used. Is that acceptable? > > Sathya > > >Hi Sathya, > > > >We have an issue in that routers may already be available which do > >not advertise a prefix (as it is not precluded). > > > >I would suggest that these routers should try to advertise a > prefix, > >be it a learned or native (PIO) prefix. > > > >That way routers can participate if they learn of other prefixes. > >Otherwise, they will still advertise if there are no prefixes > known anyway. > >This will provide hosts with the A= and M= flags sufficient to > initiate DHCP > >(which is not a DNA process but can provide the change detection > required).> > >Greg > > > >----- Original Message ----- > >From: Sathya Narayanan > >Date: Friday, January 19, 2007 8:10 am > >Subject: Re: [DNA] Issue 2: What if no prefix is advertised? > >To: Dna > > > > > > > >>If we are going to mandate that the router advertise one prefix even > >>when stateful autoconfiguration is used and that it must be the > >>smallestprefix, we are implicitly requiring the adminstrator to > >>configure each > >>of these routers with this information, right? Or, are we talking > >>aboutthe routers sniffing DHCP messages - What does it mean? > >> > >>I am leaving this open for now, until I hear comments on this > >>question. > >>- Sathya > >> > >>JinHyeock Choi wrote: > >> > >> > >> > >>>>Issue: If stateful autoconfiguration is used, the routers may not > >>>>advertise any prefix in its RA message. DNA will not work > >>>> > >>>> > >>without prefix > >> > >> > >>>>advertised. Current text relies on DHCP confirm message > exchange > >>>> > >>>> > >>for DNA > >> > >> > >>>>in that case. > >>>> > >>>>Agreement at the meeting: Lets mandate the inclusion of one > >>>> > >>>> > >>prefix in > >> > >> > >>>>all RA message, with L= 0 and A=0. But, atleast one prefix is a > >>>> > >>>> > >>MUST.>> The router MUST include the smallest prefix either in PIO > >>or LPO of all > >> > >> > >>>>RA messages. > >>>>Note: I am not refering to the smallest prefix as "LinkID" > >>>> > >>>> > >>because in > >> > >> > >>>>"Issue 6", I will be proposing the removal of the concept of > >>>> > >>>> > >>LinkIDs.>> The forward compatibility advantage of the LinkIDs can > >>be easily > >> > >> > >>>>supported and refer to the email on Issue 6 is further details. > >>>> > >>>>If you have any objections to the proposed change please post your > >>>>objections on the list. > >>>> > >>>> > >>>I agree and, IMO, the concept of 'LinkID' is of help. It would be > >>>simpler to mandate to include LinkID prefix. > >>> > >>>Best Regards > >>> > >>>JinHyeock > >>> > >>> > >> > >> > >> > > From dna-owner@webcamserver.eng.monash.edu.au Fri Jan 26 15:14:45 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAXTB-00061M-8T for dna-archive@lists.ietf.org; Fri, 26 Jan 2007 15:14:45 -0500 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAXT4-0007Ze-Tn for dna-archive@lists.ietf.org; Fri, 26 Jan 2007 15:14:45 -0500 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01MCEYSJ5ZMU8X61NC@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 27 Jan 2007 07:14:28 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 01E37AB545; Sat, 27 Jan 2007 07:14:14 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id BA91F4FB05; Sat, 27 Jan 2007 07:14:13 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l0QK6Ta30910 for dna-list; Sat, 27 Jan 2007 07:06:29 +1100 Received: from cartman.its.monash.edu.au (cartman.its.monash.edu.au [130.194.13.166]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l0QK6Ss30906 for ; Sat, 27 Jan 2007 07:06:28 +1100 Received: from spam-daemon.cartman.its.monash.edu.au by cartman.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JCH00F02RUQJD00@cartman.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 27 Jan 2007 07:06:29 +1100 (EST) Received: from oak.research.panasonic.com ([150.169.1.4]) by cartman.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JCH00301OG4HG00@cartman.its.monash.edu.au> (original mail from sathya@research.panasonic.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 27 Jan 2007 07:06:09 +1100 (EST) Received: from oak.research.panasonic.com ([150.169.1.4]) by cartman.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JCH004VFRU8DEA0@cartman.its.monash.edu.au> for dna@eng.monash.edu.au; Sat, 27 Jan 2007 07:06:09 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with ESMTP id l0QK67Gj029727; Fri, 26 Jan 2007 15:06:07 -0500 Received: from [150.169.1.185] ([150.169.1.185]) by redwood.research.panasonic.com (MOS 3.7.4b-GA) with ESMTP id AQM08774; Fri, 26 Jan 2007 15:04:35 -0500 (EST) Date: Fri, 26 Jan 2007 15:04:16 -0500 From: Sathya Narayanan Subject: Re: [DNA] Issue 6: DNAHostLinkIDList In-reply-to: <45704479.8060209@Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Dna Message-id: <45BA5EC0.5070104@Research.Panasonic.COM> Organization: Panasonic Technologies Company MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Spam-Level: References: <45537A0D.3020009@Research.Panasonic.COM> <92e919fb0611162105x39e4fa03u8f9a07c4ec7f27e6@mail.gmail.com> <455DDE50.7010204@Research.Panasonic.COM> <92e919fb0611200137r174a212apadc4ca2bacbf262f@mail.gmail.com> <456F85D1.30509@Research.Panasonic.COM> <92e919fb0612010333ob58c56eo827a74128e6126bd@mail.gmail.com> <45704479.8060209@Research.Panasonic.COM> X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 This is the last email on this subject I can find on the list. I am going to close this issue, removing LinkID from the solution while making sure that the points raised by JinHyeock are covered in the text. I still haven't closed Issue 2:, changes to support Stateful autoconfiguration scenario. The current text depends on DHCP CONFIRM to address this scenario. I am still uncomfortable requiring configuration of each router on the link with the smallest prefix - a sysadmin then becomes responsible for keeping track of the smallest prefix and updating the configuration each time. Depending on DHCP CONFIRM is a more dynamic solution, imho. I will close this later on, after I do one-on-one discussion with a few people. Hopefully, I will submit a new version before the end of next week. Thanks, Sathya Sathya Narayanan wrote: > Dear JinHyeock: > > You are right. The DNA bit in the RA should be enough to take care of > non-DNA router messages. If the host doesn't find a prefix in a DNA-RA > that is already in the DNAHostPrefixList, it can conclude that it has > changed link - and it would be correct. If it is a non-DNA-RA, it > should fall back on CPL or wait for another DNA-RA. I will make sure > that the text is written accordingly. > > - Sathya > >> Dear Sathya >> >>> Since I didn't hear any other objections, I am going start closing the >>> issues using the suggested changes, except for this issue on >>> DNAHostLinkIDList. >>> >>> My proposal for removing DNAHostLinkIDList is as follows: >>> We remove the concept of identifying a particular prefix as LinkID >>> prefix and mandate the inclusion of the smallest prefix in all RA >>> messages. On the host side, we only need to check if there is a prefix >>> included in the RA that is in the DNAHostPrefixList. This will work if >>> we make sure that when there is a change in the smallest prefix, the RA >>> includes the previous smallest and the current smallest (similar to >>> what >>> is done when the LinkID changes now). So, the algorithm will be: >>> >>> For non-landmark RA or a NO landmark response: >>> Router SHOULD try to send a completeRA. >>> If the completeRA is not possible due size restriction, the RA MUST >>> include the smallest prefix. >>> If the smallest prefix was first seen within 1.5 hours ago, then the >>> second smallest prefix MUST be included in the RA. >>> If the second smallest prefix was first seen within 1.5 hours ago, then >>> the third smallest prefix MUST be included in the RA. >>> And so on... (I don't like that this is open ended, but thats how >>> things >>> are right now with including LinkIDs) >>> >>> For unsolicited RA: >>> MAY be a completeRA. >>> >>> If not a completeRA, same rules as above to include the smallest >>> prefix(es). >>> >>> What I am trying to do here should be obvious. The functionality is >>> exactly the same as the LinkID component of the current draft, but >>> there >>> is no explicit marking as such and more importantly no explicit LinkID >>> check at the host. The overlapping prefix check covers that for us, >>> removes the need for a DNAHostLinkIDList, thus simplifying the >>> operation >>> significantly on the host side. >>> >>> For future non-prefix linkIDs, they can be included in the LPO and they >>> MUST be 128 bits long. Since LPO cannot be used to configure addresses >>> this won't cause any trouble and cannot overlap with other prefixes >>> since they are 128 bits. >>> >>> I would like to know if people think this is workable - am I >>> overlooking >>> something? >> >> >> I think the above is workable but have a few concerns. >> >> 1. >> >>> This will work if >>> we make sure that when there is a change in the smallest prefix, the RA >>> includes the previous smallest and the current smallest (similar to >>> what >>> is done when the LinkID changes now). So, the algorithm will be: >> >> >> For the above, DNA routers should manage "the smallest prefix list" >> which it recently advertised. >> >> 2. RA should include the indication that this RA includes the >> smallest prefix. >> >> A DNA router and a non-DNA router may co-exist on a link. If the >> non-DNA router advertises an RA without the smallest prefix, that may >> cause a host to make a mistake. >> >> The inclusion of the smallest prefix can be indicated with >> either 1) DNA router bit in RA or 2) a new bit in PIO. >> >> For the first, a host assumes that the RA from the DNA router includes >> the smallest prefix automatically. >> >> For the second, a host assumes that the RA includes the smallest >> prefix only when there is a smallest prefix bit in PIO/ or LPIO. >> >> Thanks for your kind consideration. >> >> Best Regards >> >> JinHyeock > > From hikita_tenkou_2000@yahoo.fr Fri Jan 26 21:22:53 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAdD8-0000Eh-RS for DNA-ARCHIVE@LISTS.IETF.ORG; Fri, 26 Jan 2007 21:22:34 -0500 Received: from [59.44.235.133] (helo=so-net.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAdB7-0007zC-Hg for DNA-ARCHIVE@LISTS.IETF.ORG; Fri, 26 Jan 2007 21:20:31 -0500 Received: from asw8 (unknown [104.151.135.98]) by smtp16 (Coremail) with SMTP id wFGpyHcKhgrXm8ht.1 for ; Sat, 27 Jan 2007 10:20:29 +0800 (CST) X-Originating-IP: [104.151.135.98] X-Spam-Score: 1.6 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f From: To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 メール拒否 maki_noda21@yahoo.co.uk From dna-owner@webcamserver.eng.monash.edu.au Sun Jan 28 21:44:30 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBMVR-0002dI-Tj for dna-archive@lists.ietf.org; Sun, 28 Jan 2007 21:44:29 -0500 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBMVP-0004U1-Sv for dna-archive@lists.ietf.org; Sun, 28 Jan 2007 21:44:29 -0500 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01MCI5015DPQ8YEATV@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 29 Jan 2007 13:44:29 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 04A0AAB544; Mon, 29 Jan 2007 12:43:54 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id C82B44FB04; Mon, 29 Jan 2007 12:43:53 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l0T2fAF13359 for dna-list; Mon, 29 Jan 2007 13:41:10 +1100 Received: from kyle.its.monash.edu.au (kyle.its.monash.edu.au [130.194.13.163]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l0T2f9s13355 for ; Mon, 29 Jan 2007 13:41:09 +1100 Received: from spam-daemon.kyle.its.monash.edu.au by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JCL00805ZGIH200@kyle.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 29 Jan 2007 13:41:07 +1100 (EST) Received: from nf-out-0910.google.com ([64.233.182.189]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JCL00601YVWR200@kyle.its.monash.edu.au> (original mail from jinchoe@gmail.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 29 Jan 2007 13:41:06 +1100 (EST) Received: from nf-out-0910.google.com ([64.233.182.189]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JCL0057CZGGJI20@kyle.its.monash.edu.au> for dna@eng.monash.edu.au; Mon, 29 Jan 2007 13:41:06 +1100 (EST) Received: by nf-out-0910.google.com with SMTP id b2so2050960nfe for ; Sun, 28 Jan 2007 18:41:04 -0800 (PST) Received: by 10.49.28.3 with SMTP id f3mr8577506nfj.1170038464102; Sun, 28 Jan 2007 18:41:04 -0800 (PST) Received: by 10.48.217.6 with HTTP; Sun, 28 Jan 2007 18:41:03 -0800 (PST) Date: Mon, 29 Jan 2007 11:41:04 +0900 From: JinHyeock Choi Subject: Re: [DNA] Issue 6: DNAHostLinkIDList In-reply-to: <45BA5EC0.5070104@Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Dna Message-id: <92e919fb0701281841r912fe16q6db795dd5ded99ca@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=N4j/mHLFg7C6HEeRCZbSVATIRHqEXqDVfjgJ1lc0tTqycvaDcN8Ks0cY1EveMFRJyzaONU7iq+WWQQ9ipU3htLPqZzSGe2cerSMvEvUWOyFluZnOzyUL2xocLxhYwNmYzvM0xGrw57/hWrvVJIWAFb//unZwMWKDry/x+HThfLU= X-Spam-Level: References: <45537A0D.3020009@Research.Panasonic.COM> <92e919fb0611162105x39e4fa03u8f9a07c4ec7f27e6@mail.gmail.com> <455DDE50.7010204@Research.Panasonic.COM> <92e919fb0611200137r174a212apadc4ca2bacbf262f@mail.gmail.com> <456F85D1.30509@Research.Panasonic.COM> <92e919fb0612010333ob58c56eo827a74128e6126bd@mail.gmail.com> <45704479.8060209@Research.Panasonic.COM> <45BA5EC0.5070104@Research.Panasonic.COM> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Dear Sathya Thanks for your trouble advancing the work. > I still haven't closed Issue 2:, changes to support Stateful > autoconfiguration scenario. The current text depends on DHCP CONFIRM to > address this scenario. I am still uncomfortable requiring configuration > of each router on the link with the smallest prefix - a sysadmin then > becomes responsible for keeping track of the smallest prefix and > updating the configuration each time. Sysamin doesn't have to keep track of the smallest prefix and configure it to each router manually. Sysamin only have to configure a router to advertise at least one prefix. Then, after a while, the routers on the same link, upon hearing the prefixes from each other, will pick the smallest prefix and advertise it in either PIO or LPIO. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Mon Jan 29 22:39:34 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBjqH-0003Ws-Vv for dna-archive@lists.ietf.org; Mon, 29 Jan 2007 22:39:33 -0500 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBjqF-0001yP-Uj for dna-archive@lists.ietf.org; Mon, 29 Jan 2007 22:39:33 -0500 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V6.2-1x9 #31276) with ESMTP id <01MCJL7PYB6Q8YETZX@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 30 Jan 2007 14:39:38 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8FDCD80004; Tue, 30 Jan 2007 14:39:13 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 4E7E63C005; Tue, 30 Jan 2007 14:39:13 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l0U3aY818978 for dna-list; Tue, 30 Jan 2007 14:36:34 +1100 Received: from kenny.its.monash.edu.au (kenny.its.monash.edu.au [130.194.13.164]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l0U3aTs18974 for ; Tue, 30 Jan 2007 14:36:29 +1100 Received: from larry.its.monash.edu.au ([130.194.13.82]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JCN00401QBQKB00@kenny.its.monash.edu.au> (original mail from Greg.Daley@eng.monash.edu.au) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 30 Jan 2007 14:36:26 +1100 (EST) Received: from larry.its.monash.edu.au ([130.194.13.82]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JCN00IXYWOQKY80@kenny.its.monash.edu.au> for dna@eng.monash.edu.au; Tue, 30 Jan 2007 14:36:26 +1100 (EST) Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EB3A680003; Tue, 30 Jan 2007 14:36:25 +1100 (EST) Received: from monash.edu.au (dollet.its.monash.edu.au [130.194.11.236]) by larry.its.monash.edu.au (Postfix) with ESMTP id D62263C004; Tue, 30 Jan 2007 14:36:25 +1100 (EST) Received: from [203.8.7.222] by mail-store-2.its.monash.edu.au (mshttpd); Tue, 30 Jan 2007 14:36:24 +1100 Date: Tue, 30 Jan 2007 14:36:24 +1100 From: Greg Daley Subject: Re: [DNA] Issue 6: DNAHostLinkIDList In-reply-to: <92e919fb0701281841r912fe16q6db795dd5ded99ca@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Sathya Narayanan , Dna Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.12 (built May 22 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en References: <45537A0D.3020009@Research.Panasonic.COM> <92e919fb0611162105x39e4fa03u8f9a07c4ec7f27e6@mail.gmail.com> <455DDE50.7010204@Research.Panasonic.COM> <92e919fb0611200137r174a212apadc4ca2bacbf262f@mail.gmail.com> <456F85D1.30509@Research.Panasonic.COM> <92e919fb0612010333ob58c56eo827a74128e6126bd@mail.gmail.com> <45704479.8060209@Research.Panasonic.COM> <45BA5EC0.5070104@Research.Panasonic.COM> <92e919fb0701281841r912fe16q6db795dd5ded99ca@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Hi JinHyeock, If the router has an address prefix configured for routing (local delivery), even if it is not configured for stateless address autoconfiguration, it can advertise it as a learned prefix. This could be an automatic process. If the router doesn't have any prefixes configured for routing, then I would prefer not requiring it to have a prefix configured just for the purpose of link identification. How about we say: "... In some circumstances, such as when DHCPv6 is used, a router may not be configured to advertise prefixes in Prefix Information Options [RFC3315]. If a router interface is configured with a non link-local prefix and does not send Prefix Information Options, each Router Advertisement it sends MUST contain at least one prefix in a Learned Prefix Option for the purposes of Link Identification. If the router has not learnt any valid Prefix Information Options this prefix MUST be one of its own locally configured non link-local prefixes, and the "Complete" flag MUST NOT be set in the RA. If this router learns valid prefixes from a Prefix Information Option, it SHOULD advertise this instead, advertising the "Complete" flag if all of the link's PIO advertised prefixes are readvertised in LPOs. ..." Of course, learned prefixes aren't readvertised, and multiple non PIO-advertising routers may advertise disjoint LPOs. In that case, the Complete Flag isn't set, and the routers provide the prefix only to assist CPL hosts in determining link change. The system reverts to nromal operation if even one router advertises with a PIO. Greg ----- Original Message ----- From: JinHyeock Choi Date: Monday, January 29, 2007 1:44 pm Subject: Re: [DNA] Issue 6: DNAHostLinkIDList To: Sathya Narayanan Cc: Dna > Dear Sathya > > Thanks for your trouble advancing the work. > > > I still haven't closed Issue 2:, changes to support Stateful > > autoconfiguration scenario. The current text depends on DHCP > CONFIRM to > > address this scenario. I am still uncomfortable requiring > configuration> of each router on the link with the smallest prefix - > a sysadmin then > > becomes responsible for keeping track of the smallest prefix and > > updating the configuration each time. > > Sysamin doesn't have to keep track of the smallest prefix and > configure it to each router manually. > > Sysamin only have to configure a router to advertise at least one > prefix. Then, after a while, the routers on the same link, upon > hearing the prefixes from each other, will pick the smallest prefix > and advertise it in either PIO or LPIO. > > Thanks for your kind consideration. > > Best Regards > > JinHyeock > From dna-owner@webcamserver.eng.monash.edu.au Tue Jan 30 10:30:31 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBuwI-0002pk-W2 for dna-archive@lists.ietf.org; Tue, 30 Jan 2007 10:30:30 -0500 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBuwG-00087O-UC for dna-archive@lists.ietf.org; Tue, 30 Jan 2007 10:30:30 -0500 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01MCKA1PYYRI8YCITS@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 31 Jan 2007 02:30:21 +1100 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9D172AB544; Wed, 31 Jan 2007 02:30:10 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 68B934FB02; Wed, 31 Jan 2007 02:30:10 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l0UFSIj21569 for dna-list; Wed, 31 Jan 2007 02:28:18 +1100 Received: from kenny.its.monash.edu.au (kenny.its.monash.edu.au [130.194.13.164]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l0UFSHs21565 for ; Wed, 31 Jan 2007 02:28:18 +1100 Received: from spam-daemon.kenny.its.monash.edu.au by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JCO00F2HTN1TZ00@kenny.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 31 Jan 2007 02:28:14 +1100 (EST) Received: from oak.research.panasonic.com ([150.169.1.4]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JCO00D01SZNE200@kenny.its.monash.edu.au> (original mail from sathya@research.panasonic.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 31 Jan 2007 02:28:06 +1100 (EST) Received: from oak.research.panasonic.com ([150.169.1.4]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JCO002PITMTO190@kenny.its.monash.edu.au> for dna@eng.monash.edu.au; Wed, 31 Jan 2007 02:28:06 +1100 (EST) Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with ESMTP id l0UFS4Sj017238; Tue, 30 Jan 2007 10:28:04 -0500 Received: from [150.169.1.185] ([150.169.1.185]) by redwood.research.panasonic.com (MOS 3.7.4b-GA) with ESMTP id AQR03037; Tue, 30 Jan 2007 10:29:33 -0500 (EST) Date: Tue, 30 Jan 2007 10:26:14 -0500 From: Sathya Narayanan Subject: Re: [DNA] Issue 6: DNAHostLinkIDList In-reply-to: <92e919fb0701281841r912fe16q6db795dd5ded99ca@mail.gmail.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Dna Message-id: <45BF6396.6050202@Research.Panasonic.COM> Organization: Panasonic Technologies Company MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Spam-Level: References: <45537A0D.3020009@Research.Panasonic.COM> <92e919fb0611162105x39e4fa03u8f9a07c4ec7f27e6@mail.gmail.com> <455DDE50.7010204@Research.Panasonic.COM> <92e919fb0611200137r174a212apadc4ca2bacbf262f@mail.gmail.com> <456F85D1.30509@Research.Panasonic.COM> <92e919fb0612010333ob58c56eo827a74128e6126bd@mail.gmail.com> <45704479.8060209@Research.Panasonic.COM> <45BA5EC0.5070104@Research.Panasonic.COM> <92e919fb0701281841r912fe16q6db795dd5ded99ca@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 JinHyeock - You are right. I didn't realize that before. Thanks for correcting me. I feel a lot more comfortable now. Now, is it ok the REQUIRE the sysadmin to configure the routers with atleast one prefix even if stateful address configuration is used. I guess it is ok. I don't know what others think. Greg - Your idea to use the configured non-link local prefix is a good one, but it still leaves the scenario where the router is configured only with link-local addresses on it local interface. AFAIK, thats going to be the most common scenario. So, if we require the routers to advertise atleast one prefix, it MUST be configured on the router even when stateful address configuration is used. Sathya > Dear Sathya > > Thanks for your trouble advancing the work. > >> I still haven't closed Issue 2:, changes to support Stateful >> autoconfiguration scenario. The current text depends on DHCP CONFIRM to >> address this scenario. I am still uncomfortable requiring configuration >> of each router on the link with the smallest prefix - a sysadmin then >> becomes responsible for keeping track of the smallest prefix and >> updating the configuration each time. > > > Sysamin doesn't have to keep track of the smallest prefix and > configure it to each router manually. > > Sysamin only have to configure a router to advertise at least one > prefix. Then, after a while, the routers on the same link, upon > hearing the prefixes from each other, will pick the smallest prefix > and advertise it in either PIO or LPIO. > > Thanks for your kind consideration. > > Best Regards > > JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Wed Jan 31 05:28:00 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCCh6-00033Z-9Y for dna-archive@lists.ietf.org; Wed, 31 Jan 2007 05:28:00 -0500 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCCh4-0002Hb-9q for dna-archive@lists.ietf.org; Wed, 31 Jan 2007 05:28:00 -0500 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01MCLDQU0NYQ8X74VP@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 31 Jan 2007 21:27:38 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 509BD80003; Wed, 31 Jan 2007 21:27:30 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 083433C004; Wed, 31 Jan 2007 21:27:30 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l0VALxS25838 for dna-list; Wed, 31 Jan 2007 21:21:59 +1100 Received: from stan.its.monash.edu.au (stan.its.monash.edu.au [130.194.13.165]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l0VALws25834 for ; Wed, 31 Jan 2007 21:21:58 +1100 Received: from spam-daemon.stan.its.monash.edu.au by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JCQ00105A4LKB00@stan.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 31 Jan 2007 21:21:58 +1100 (EST) Received: from nf-out-0910.google.com ([64.233.182.190]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JCQ00J0185Z4G00@stan.its.monash.edu.au> (original mail from jinchoe@gmail.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 31 Jan 2007 21:21:49 +1100 (EST) Received: from nf-out-0910.google.com ([64.233.182.190]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JCQ009GBA4B19A0@stan.its.monash.edu.au> for dna@eng.monash.edu.au; Wed, 31 Jan 2007 21:21:49 +1100 (EST) Received: by nf-out-0910.google.com with SMTP id b2so492863nfe for ; Wed, 31 Jan 2007 02:21:47 -0800 (PST) Received: by 10.49.8.15 with SMTP id l15mr406415nfi.1170238906737; Wed, 31 Jan 2007 02:21:46 -0800 (PST) Received: by 10.48.217.6 with HTTP; Wed, 31 Jan 2007 02:21:46 -0800 (PST) Date: Wed, 31 Jan 2007 19:21:46 +0900 From: JinHyeock Choi Subject: Re: [DNA] Issue 6: DNAHostLinkIDList In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley Cc: Sathya Narayanan , Dna Message-id: <92e919fb0701310221u517ac9c6v9e4662343ed17337@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=P6iQ7EswY9yh+5BHm2OxV6xQMX5mSK9Rdgx3myK4YGJJfdiejI2sTqAYAEiG5TSilQGfOOOimQyLBfci2P3EqXIkkXkP7rqVZedFq+T771ibuZDadSWx1ycDQCrYfoHTbziaRZGZn35RChzmokumPMNW9uBPHoL5O+TCJbp82DY= X-Spam-Level: References: <45537A0D.3020009@Research.Panasonic.COM> <92e919fb0611162105x39e4fa03u8f9a07c4ec7f27e6@mail.gmail.com> <455DDE50.7010204@Research.Panasonic.COM> <92e919fb0611200137r174a212apadc4ca2bacbf262f@mail.gmail.com> <456F85D1.30509@Research.Panasonic.COM> <92e919fb0612010333ob58c56eo827a74128e6126bd@mail.gmail.com> <45704479.8060209@Research.Panasonic.COM> <45BA5EC0.5070104@Research.Panasonic.COM> <92e919fb0701281841r912fe16q6db795dd5ded99ca@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Dear Greg glad to hear from you after a while. :-) > If the router has an address prefix configured for routing (local delivery), > even if it is not configured for stateless address autoconfiguration, it > can advertise it as a learned prefix. > > This could be an automatic process. ok. If a router receives traffic through prefix based routing, (i.e other routers forward packets to the router with the longest prefix match), I guess some prefix need to be configured to the router. > If the router doesn't have any prefixes configured for routing, then > I would prefer not requiring it to have a prefix configured just for the > purpose > of link identification. It's my opinion that would be simpler and, may say, better. Also I think the above case (router with some prefix being configured) holds for the most occasions. If I miss something, kindly let me know. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Wed Jan 31 05:28:18 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCChO-0003Aq-O6 for dna-archive@lists.ietf.org; Wed, 31 Jan 2007 05:28:18 -0500 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCChM-0002Xs-Uz for dna-archive@lists.ietf.org; Wed, 31 Jan 2007 05:28:18 -0500 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01MCLDQZYIM88YCFOQ@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 31 Jan 2007 21:27:54 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3DED6AB543; Wed, 31 Jan 2007 21:27:38 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 010D24FB02; Wed, 31 Jan 2007 21:27:38 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id l0VAMUQ25846 for dna-list; Wed, 31 Jan 2007 21:22:30 +1100 Received: from cartman.its.monash.edu.au (cartman.its.monash.edu.au [130.194.13.166]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id l0VAMTs25842 for ; Wed, 31 Jan 2007 21:22:29 +1100 Received: from spam-daemon.cartman.its.monash.edu.au by cartman.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JCQ0071KA5HPX00@cartman.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 31 Jan 2007 21:22:29 +1100 (EST) Received: from nf-out-0910.google.com ([64.233.182.191]) by cartman.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JCQ00G0158IMK00@cartman.its.monash.edu.au> (original mail from jinchoe@gmail.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 31 Jan 2007 21:22:03 +1100 (EST) Received: from nf-out-0910.google.com ([64.233.182.191]) by cartman.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JCQ005D5A4BUW70@cartman.its.monash.edu.au> for dna@eng.monash.edu.au; Wed, 31 Jan 2007 21:22:03 +1100 (EST) Received: by nf-out-0910.google.com with SMTP id b2so492864nfe for ; Wed, 31 Jan 2007 02:22:02 -0800 (PST) Received: by 10.49.54.3 with SMTP id g3mr2215911nfk.1170238922074; Wed, 31 Jan 2007 02:22:02 -0800 (PST) Received: by 10.48.217.6 with HTTP; Wed, 31 Jan 2007 02:22:02 -0800 (PST) Date: Wed, 31 Jan 2007 19:22:02 +0900 From: JinHyeock Choi Subject: Re: [DNA] Issue 6: DNAHostLinkIDList In-reply-to: <45BF6396.6050202@Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: Dna Message-id: <92e919fb0701310222n594716fib343334cf69711de@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=f5GOjoYTYkomhNB3sbO1dheiBkf6hElOl39aVctT/yXQ+co2+hxr47w7EyO/2zx96Zx5bT2+Vj5SwKwT0RFlwFp75VtkeAMCeoamqYpZEyvU2v0t2N1zQkehZxKHoOR/k0EApj0aR+JqIzqK357ZZk/FTLbrez5/NAJ9brfs4Vw= X-Spam-Level: References: <45537A0D.3020009@Research.Panasonic.COM> <92e919fb0611162105x39e4fa03u8f9a07c4ec7f27e6@mail.gmail.com> <455DDE50.7010204@Research.Panasonic.COM> <92e919fb0611200137r174a212apadc4ca2bacbf262f@mail.gmail.com> <456F85D1.30509@Research.Panasonic.COM> <92e919fb0612010333ob58c56eo827a74128e6126bd@mail.gmail.com> <45704479.8060209@Research.Panasonic.COM> <45BA5EC0.5070104@Research.Panasonic.COM> <92e919fb0701281841r912fe16q6db795dd5ded99ca@mail.gmail.com> <45BF6396.6050202@Research.Panasonic.COM> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Dear Sathya glad to hear that now you feel more comfortable. :-) > You are right. I didn't realize that before. Thanks for correcting me. I > feel a lot more comfortable now. > > Now, is it ok the REQUIRE the sysadmin to configure the routers with > atleast one prefix even if stateful address configuration is used. I > guess it is ok. I don't know what others think. It's ok for me. Thanks for your kind consideration. Best Regards JinHyeock