From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 06 15:57:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnhg1-0004I1-8n for dna-archive@lists.ietf.org; Tue, 06 Jun 2006 15:57:21 -0400 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnhfy-0007xe-V8 for dna-archive@lists.ietf.org; Tue, 06 Jun 2006 15:57:21 -0400 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M3BZW556IY8YGV8U@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 07 Jun 2006 05:57:16 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 020DFAB544; Wed, 07 Jun 2006 05:57:08 +1000 (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 A7E594FB0B; Wed, 07 Jun 2006 05:57:07 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k56JoKj03073 for dna-list; Wed, 07 Jun 2006 05:50:20 +1000 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 k56JoJu03067 for ; Wed, 07 Jun 2006 05:50:19 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M3BZNGLLLC8XBQT9@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 07 Jun 2006 05:50:08 +1000 Received: by localhost (Postfix, from userid 510) id 394E1AB542; Wed, 07 Jun 2006 05:50:08 +1000 (EST) Received: from cypress.neustar.com (cypress.neustar.com [209.173.57.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id BB1E04FB05 for ; Wed, 07 Jun 2006 05:50:06 +1000 (EST) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k56Jo1mU022828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 06 Jun 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FnhYv-0007NC-Tw; Tue, 06 Jun 2006 15:50:01 -0400 Date: Tue, 06 Jun 2006 15:50:01 -0400 From: Internet-Drafts@ietf.org Subject: [DNA] I-D ACTION:draft-ietf-dna-network-00.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: i-d-announce@ietf.org Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_LAkkJ+lMWZNF1XE278+EIw)" X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Spam-Score: 0.2 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be --Boundary_(ID_LAkkJ+lMWZNF1XE278+EIw) Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Detecting Network Attachment Working Group of the IETF. Title : Detecting Network Attachment in IPv6 - Network Deployment Considerations Author(s) : S. Narayanan, et al. Filename : draft-ietf-dna-network-00.txt Pages : 19 Date : 2006-6-6 Hosts experiencing rapid link-layer changes may require to do configuration change detection procedures more frequently than traditional fixed hosts. This document describes practices available to network deployers in order to support such hosts in Detecting Network Attachment in IPv6 networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dna-network-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dna-network-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dna-network-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_LAkkJ+lMWZNF1XE278+EIw) Content-type: multipart/alternative; boundary="Boundary_(ID_WiYk5pi0U0+JiXo5vFqnug)" --Boundary_(ID_WiYk5pi0U0+JiXo5vFqnug) Content-type: Message/External-body; access-type=mail-server; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-6135031.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dna-network-00.txt --Boundary_(ID_WiYk5pi0U0+JiXo5vFqnug) Content-type: Message/External-body; name=draft-ietf-dna-network-00.txt; site=ftp.ietf.org; access-type=anon-ftp; directory=internet-drafts Content-disposition: attachment; filename=draft-ietf-dna-network-00.txt Content-Type: text/plain Content-ID: <2006-6-6135031.I-D@ietf.org> --Boundary_(ID_WiYk5pi0U0+JiXo5vFqnug)-- --Boundary_(ID_LAkkJ+lMWZNF1XE278+EIw)-- From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 06 17:54:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnjVD-000069-6Y for dna-archive@lists.ietf.org; Tue, 06 Jun 2006 17:54:19 -0400 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnjVB-00071E-Nk for dna-archive@lists.ietf.org; Tue, 06 Jun 2006 17:54:19 -0400 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M3C3Y4GSWW8XBN58@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 07 Jun 2006 07:53:50 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EB4CFAB545; Wed, 07 Jun 2006 07:53:15 +1000 (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 9A4614FB07; Wed, 07 Jun 2006 07:53:15 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k56LqV904250 for dna-list; Wed, 07 Jun 2006 07:52:31 +1000 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 k56LqUu04246 for ; Wed, 07 Jun 2006 07:52:30 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M3C3WYIVTC8YDJ5I@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 07 Jun 2006 07:52:30 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 685E7AB543 for ; Wed, 07 Jun 2006 07:52:30 +1000 (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 5531C4FB0B for ; Wed, 07 Jun 2006 07:52:30 +1000 (EST) Received: from [150.169.1.225] by mail-store-2.its.monash.edu.au (mshttpd) ; Tue, 06 Jun 2006 17:52:29 -0400 Date: Tue, 06 Jun 2006 17:52:29 -0400 From: Greg Daley Subject: Re: [DNA] I-D ACTION:draft-ietf-dna-network-00.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.09 (built Nov 18 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Hi, Please note that draft-ietf-dna-network is the replacement for draft-ietf-dna-routers whose name was changed due to feedback that the document didn't modify routers. Greg From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 06 21:35:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnmxM-0007lx-TQ for dna-archive@lists.ietf.org; Tue, 06 Jun 2006 21:35:36 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnmxL-0000Dh-DS for dna-archive@lists.ietf.org; Tue, 06 Jun 2006 21:35:36 -0400 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 <01M3CBNICQXQ8Y6CVX@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 07 Jun 2006 11:34:24 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 67B4E80004; Wed, 07 Jun 2006 11:34:16 +1000 (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 08C903C007; Wed, 07 Jun 2006 11:34:16 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k571XWT06356 for dna-list; Wed, 07 Jun 2006 11:33:32 +1000 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 k571XVu06352 for ; Wed, 07 Jun 2006 11:33:31 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M3CBMX1V9M8YG784@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 07 Jun 2006 11:33:20 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D016680002; Wed, 07 Jun 2006 11:33:18 +1000 (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 BAD2F3C011; Wed, 07 Jun 2006 11:33:18 +1000 (EST) Received: from [150.169.1.225] by mail-store-2.its.monash.edu.au (mshttpd) ; Tue, 06 Jun 2006 21:33:17 -0400 Date: Tue, 06 Jun 2006 21:33:17 -0400 From: Greg Daley Subject: [DNA] Review of draft-ietf-dna-frd-00.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Cc: jinchoe@samsung.com, yun7521@samsung.com, Wassim.Haddad@ericsson.com, Suresh.Krishnan@ericsson.com Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.09 (built Nov 18 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en X-Spam-Score: 0.0 (/) X-Scan-Signature: ea36de7a5e28e9b4461c8d685f4e97f1 Hi, Here is a review of FRD. I will be travelling for the next two weeks, so my response will be limited. Greg This document has expired in the repository, please submit a new version. Abstract Please do not make any abbreviations in the abstract. Abbreviations should be introduced on their first use in the text. It's not clear what the optimized result is... The Suggested abstract is as follows: For efficient detection of network Attachment, a host should quickly receive a Router Advertisement upon a new link-layer connection. This draft presents a quick advertisement acquisition scheme with the support of a link-layer Point of Attachment. Upon a new network attachment, the Point of Attachment may either trigger an Access Router to immediately send a unicast advertisement "RA Triggering" or send such an advertisement itself "RA Proxying". Such functions may be placed on a Point of Attachment to deliver Router Advertisements rapidly without changes to IPv6 Neighbor Discovery Introduction DNA is used in paragraph 2 without being introduced. Paragraph 2 and 3 overlap in coverage. Here is a suggested amalgamation: A host needs to receive a Router Advertisement (RA) when it has moved to a different link in order to Detect Network Attachment (DNA). Router advertisements contain IP prefix information which identify the composition of a link, and the available prefixes to configure upon link change. This document focusses on Rapid delivery of RA messages without describing their content . Those interested in RA contents are referred to . In Paragraph 4, please change sentence beginning "Second, ..." as follows: Second, a host should randomly delay before initial transmission of a Router Solicitation (RS) message. Please note that this restriction has been relaxed in RFC2461bis. Paragraph 5: s/broadcast/multicast/ s/For DNA purpose/For DNA purposes/ Paragraph 6: s/PoA (Point of Attachment) is the link endpoint fo the link, such as/ A PoA is a link-layer connection point through which a wired or wireless host interfaces to an access network, such as/ s/, PoA,/, the PoA/ s/delivered to the host in unicast/unicast to the host/ Paragraph 7: s/the PoA may either trigger an AR (Access Router) to immediately send a suitable RA or/ the PoA may trigger an AR to either sen Protocol Overview: Paragraph 1: I suggest replacing the text with: Using the procedures outlined in this document, when a host establishes a link-layer connection a PoA, can detect the host's new attachment and get the necessary information to deliver an unicast L2 frame to it. For example, this link-layer information may be a 802.11 MAC address or 802.16 CID (Connection Identifier) [19]. Paragraph 2: s/forward the information/forward the link-layer information/ Paragraph 3: s/Or the PoA/Alternatively, the PoA/ 3.1 RA triggering: Paragraph 1: s/to IP layer/to the IP layer/ Paragraph2: s/deliver the AR the Link Up event notification/ deliver a Link Up event notification to the AR/ Paragraph 3: s/TSLLAO/Tentative Option/ 3.2 RA proxying: Paragraph 2 s/We may manually/An administrator may manually/ s/use the scanning scheme/use an RA scanning scheme/ s/Or PoA and AR may use a special information service/ Alternatively, a PoA and AR may use an information service/ s/porxy/proxy/ Paragraph 3 s/, PoA may/, the PoA may/ 4. RA Triggering Suggest replacement of paragraph 1 with: In case the PoA and AR are in the same node, when a new host is attached link-layer events may be delivered locally. The arriving host's link-layer address can be passed from the PoA (Link-Layer) to the AR (IP Layer) in the same stack. Subsequently, the AR can immediately send a suitable RA in a unicast L2 frame with the new host's MAC address. Paragraph 2: s/, we may use/, they may communicate using/ Paragraph 4: Add to the end: Further deatils of these operations are provided in section 5.1.3. 5. RA proxying: paragraph 1: s/we recomment to use RA triggering instead/ it is RECOMMENDED that RA triggering is used instead/ 5.1 RA Caching: Replace with: Three different methods for storing RAs in a PoA are presented. 5.1.1 Manual Configuration: please replace with: In the simplest way, an administraotr can manually configure a suitable RA in the PoA. Such an RA may contain a link-identifier or be a Complete RA . This may be applicable where the AR and PoA are under the same administrative control, and the RA message contents don't change often. 5.1.2 Scanning Note that there is no description of a suitable RA. paragraph 1 s/L2 frame /L2 frames / Paragraph 2: s/scans L2 frame/scans the L2 frame/ s/sends that frame down the link and scans a next L2 frame/ ignores that frame for caching purposes/ s/If incoming/If an incoming/ Paragraph 3: Please replace the paragraph with: A PoA can scan continuously, updating an old RA with a new RA. Alternatively, if it costs too much for the PoA to scan every incoming L2 frame, it may control the scanning rate. For example, it can set a timer and execute scanning every T seconds, Or the PoA itself can send a Router Solicitation (RS) message periodically. It is noted that the PoA doesn't need to have an IP address since it can use the unspecified address as its RS source address. Paragraph 4: Please replace with: It assists RA caching if routers advertised changed parameters rapidly as described in section 6.2.6 of IPv6 Neighbour Discovery . 5.1.3 MICS (Media Indepenent Comment (sic) Service) Globally: s/Comment Service/Command Service/ Paragraph2: s/Remote MIH Command, "MIH Network Address Information"/ Remote MIH Command Primitive: "MIH Network Address Information"/ Paragraph3: it greatly concerns me that this paragraph suggests standardization by someone "we"! that a new 802.21 Command service primitive is defined for this role. As described in 7.4.11 of 802.21 D01.00, Network Address Information request can be used to gather addressing and routing information on the PoA. There are still uncertainties there regarding the content of messages, and any recommendations seem highly conjectural for a document aiming to be an RFC. Perhaps such suggestions should be placed in the appendix. 5.2 RA Delivery s/attachement/attachment/ s/describes/described/ 5.2.1 802.11 No mention of how this works with 802.11i RSN is made. This needs to be fixed. 5.2.2 802.16 Paragraph 3 and Paragraph 7 Both seem to indicate that 802.16 procedures are not well enough developed to normatively describe. This section should be removed or moved to an appendix. My concern here is that it's implicitly putting requirements on 802.16 for the channel establishment operations. 7. Security Considerations DoS Attacks seem to be ignored here. parrticularly: Paragraph 3: It's wrong to say there's no FRD specific problem, as false or spurious Associations (caused by a sequence of L2 messages) can be used to trigger an additional RA on the PoA. This is a potential amplification attack in some scenarios, and consumes wireless medium bandwidth. s/through secure port/through a secure port/ Paragraph 4: It is wrong to say there is no additional security vulnrebility if there's not a secured path between PoA and AR. An on-link attacker can potentially forge MICS events which can force the Router to place configuration information on the PoA. An attacker can also fill the PoA's cache with false router advertisements, which can make change undetectable for nodes transiting from an adjacent link. This will significantly slow change detection. Paragraphs 6-9 Ownership proof is best not hidden in the Security considerations section. It's clearly the crux of how to cache securely. You need to ensure that the Solicited RA (from the RS with the OP option) contains a valid Timestamp option though, and that the solicited timestamp is within range. Please state this (and that an OP on the subsequent RA cannot be used as proof instead). ----------------------------------------- idnits 1.101 tmp/draft-ietf-dna-frd-00.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... the boilerplate looks good. No nits found. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: Nothing found here (but these checks do not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: - The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 paragraph 2 text: "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119." Experimental warnings: - Unused Reference: [2] is defined on line 474, but not referenced ' [2] Thomson, S. and T. Narten, "IPv6 Stateless Address' - Unused Reference: [3] is defined on line 477, but not referenced ' [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)' - Unused Reference: [6] is defined on line 488, but not referenced ' [6] Nordmark, E. and J. Choi, "DNA with unmodified routers: Prefix' - Unused Reference: [8] is defined on line 496, but not referenced ' [8] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in' - Unused Reference: [11] is defined on line 506, but not referenced ' [11] Pentland, B., "An Overview of Approaches to Detecting Network' - Unused Reference: [15] is defined on line 522, but not referenced ' [15] Aboba, B., "Detecting Network Attachment (DNA) in IPv4",' - Unused Reference: [16] is defined on line 525, but not referenced ' [16] Nordmark, E., "MIPv6: from hindsight to foresight?",' - Unused Reference: [17] is defined on line 529, but not referenced ' [17] Kempf, J., Khalil, M., and B. Pentland, "IPv6 Fast Router' - Unused Reference: [18] is defined on line 533, but not referenced ' [18] Daley, G. and J. Choi, "Movement Detection Optimization in' - Unused Reference: [20] is defined on line 541, but not referenced ' [20] IEEE 802.16 TGe Working Document (Draft Standard), "Amendment' No nits found. General: please remove references to: draft-ietf-dna-soln-frame-00 (deprecated) draft-ietf-dna-cpl-01 (unless referenced from paragraph 2 of introduction). draft-jinchoi-dna-protocol2-01 (linkid related) draft-mkhalil-ipv6-fastra-05 (?, is it going to be referenced?) draft-nordmark-mobileip-mipv6-hindsight (linkid related) Please update references to: draft-ietf-send-ndopt-06 --> RFC 3971 draft-ietf-dhc-dnav4-16 --> RFC 4436 draft-daley-ipv6-tsllao-02 --> draft-ietf-dna-tentative-00 draft-pentland-sna-protocol-01 --> draft-ietf-dna-protocol-00 draft-ietf-dna-link-information-02 --> draft-ietf-dna-link-information-03 IEEE 802.21 draft D00.01 --> D01 From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 08 04:01:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoFS1-0005dR-3H for dna-archive@lists.ietf.org; Thu, 08 Jun 2006 04:01:09 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoFRz-0008NU-At for dna-archive@lists.ietf.org; Thu, 08 Jun 2006 04:01:09 -0400 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 <01M3E3EMUN5S8Y6MGP@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 08 Jun 2006 17:59:12 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3C76B80003; Thu, 08 Jun 2006 17:59:08 +1000 (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 E7DB63C006; Thu, 08 Jun 2006 17:59:07 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k587vCg24174 for dna-list; Thu, 08 Jun 2006 17:57:12 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k587v9u24168 for ; Thu, 08 Jun 2006 17:57:09 +1000 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 <01M3E3BTF1ZM8Y6PS4@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 08 Jun 2006 17:56:55 +1000 Received: by localhost (Postfix, from userid 510) id 5722B80002; Thu, 08 Jun 2006 17:56:55 +1000 (EST) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id 379513C012; Thu, 08 Jun 2006 17:56:53 +1000 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k587ulHM012844; Thu, 08 Jun 2006 09:56:47 +0200 Received: from l2.rennes.enst-bretagne.fr (l2.rennes.enst-bretagne.fr [192.44.77.4]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k587uhnK012839; Thu, 08 Jun 2006 09:56:43 +0200 Received: from [192.44.77.161] (dhcpe61 [192.44.77.161]) (authenticated bits=0) by l2.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k587ugjD008798 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 08 Jun 2006 09:56:43 +0200 Date: Thu, 08 Jun 2006 09:56:43 +0200 From: Nicolas Montavont Subject: Re: [DNA] RE: draft-ietf-dna-link-information-03 In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba Cc: hunter@timefactor.com, alper.yegin@yegin.org, jari.arkko@piuha.net, Greg.Daley@eng.monash.edu.au, Suresh.Krishnan@ericsson.com, gregdaley@ieee.org, dna@eng.monash.edu.au Message-id: <8252A2A5-F610-4CA9-90A2-1ED82492A99B@enst-bretagne.fr> MIME-version: 1.0 X-Mailer: Apple Mail (2.749.3) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Virus-Scanned: amavisd-new at enst-bretagne.fr References: X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Hi, On 26 mai 06, at 04:02, Bernard Aboba wrote: > I didn't realize this document was trying to take 802.21 into account. I just have a question here: which document are you talking about when you say "take into account 802.21"? Tx, Nicolas > I had assumed that it was targeting a relatively short-term > completion date, so that it was not feasible to wait until 802.11r > completed sponsor ballot later this year. But given that the gears > of the IETF grind slowly indeed, perhaps there is little reason not > to add new text. > >> From: David Hunter >> To: Bernard Aboba >> ,alper.yegin@yegin.org, >> jari.arkko@piuha.net >> CC: Greg.Daley@eng.monash.edu.au,Suresh.Krishnan@ericsson.com, >> gregdaley@ieee.org,dna@eng.monash.edu.au,hunter@timefactor.com >> Subject: RE: [DNA] RE: draft-ietf-dna-link-information-03 >> Date: Thu, 25 May 2006 15:58:17 -0700 >> >> Agree with Bernard on the antecedents, but not on the >> conclusions. Bad news: to work with 802.11, 802.21 is going to >> have to accommodate 802.11r (just a fact of the market). Good >> news: 802.11r is much further along than 802.21. *If* no major >> glitches happen, 802.11r will be complete and passed through as a >> standard by the time 802.21 hits sponsor ballot. So it's pretty >> safe to include 802.11r accommodations in a document that is also >> trying to take 802.21 into account. >> >> Hunter >> >> At 11:14 PM 5/24/2006, Bernard Aboba wrote: >>>> Does the document provide any guidance on what the link up/down >>>> events should be for preauthentication or fast handoff (802.11r) >>>> situations? Or is it too early to specify these? >>> >>> EAP pre-authentication can only occur if the host is already >>> connected (e.g. link is in the "up" state), so this is not >>> relevant to DNA. IEEE 802.11r is a somewhat complicated because >>> initial authentication uses the 802.11i model (e.g. no IP >>> connectivity prior to post-EAP handshake completion), but >>> handoffs are more like the original 802.11 model ("link up" on >>> completion of authenticated re-association). Given that 11r >>> isn't done yet, it is probably best not to try to cover it in >>> this document. >> >> > From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 13 21:41:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqKNQ-0002mr-Fp for dna-archive@lists.ietf.org; Tue, 13 Jun 2006 21:41:00 -0400 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqKNP-0004cy-Er for dna-archive@lists.ietf.org; Tue, 13 Jun 2006 21:41:00 -0400 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M3M3UHERUE8YHYH4@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 14 Jun 2006 11:38:43 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 020D680008; Wed, 14 Jun 2006 11:38:15 +1000 (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 AD8933C005; Wed, 14 Jun 2006 11:38:14 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k5E1Xb807240 for dna-list; Wed, 14 Jun 2006 11:33:37 +1000 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 k5E1Xau07236 for ; Wed, 14 Jun 2006 11:33:36 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M3M3OH0W248YHHGK@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 14 Jun 2006 11:33:27 +1000 Received: by localhost (Postfix, from userid 510) id B160B80003; Wed, 14 Jun 2006 11:33:27 +1000 (EST) Received: from mout.perfora.net (mout.perfora.net [217.160.230.40]) by larry.its.monash.edu.au (Postfix) with ESMTP id 766763C004; Wed, 14 Jun 2006 11:33:23 +1000 (EST) Received: from [207.62.244.189] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus0) with ESMTP (Nemesis), id 0MKoyl-1FqKFj2xjb-0002pg; Tue, 13 Jun 2006 21:33:09 -0400 Date: Tue, 13 Jun 2006 18:32:47 -0700 From: Alper Yegin Subject: RE: [DNA] RE: draft-ietf-dna-link-information-03 In-reply-to: <44756372.2090502@piuha.net> Sender: owner-dna@ecselists.eng.monash.edu.au To: 'Jari Arkko' Cc: 'Greg Daley' , Suresh.Krishnan@ericsson.com, gregdaley@ieee.org, dna@eng.monash.edu.au Message-id: <0MKoyl-1FqKFj2xjb-0002pg@mrelay.perfora.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT thread-index: AcZ/0MV/oPvgWcXPSKGQnJpZDzvDkwPf6ZlQ X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Jari, > >>>4. Security Considerations > >>> > >>> A faked link-layer event notification can be used to launch a > >>> denial-of service attack on the node and the associated network. > >>> Secure generation and delivery of these notifications MUST be > >>> ensured. This is a subject for link-layer and network stack designs > >>> and therefore it is outside the scope of this document. ... > >As for the "MUST", I understand that there are currently deployed systems > >that do not deploy appropriate security to handle this threat. That fact > >should not take anything away from what a secure system MUST be doing. I > >think that fact just makes them insecure in this sense, hence vulnerable > to > >spoofed link ups and downs. For that, I'm inclined to keep the MUST in > >there. > > > > > What you said was "Secure generation and delivery of these > notifications MUST be ensured." What I'm complaining about > is that there's no way to fully protect the notifications > against all threats, particularly if you include DoS. > Reading your response I realized the current text is open to interpretation. All I wanted to say was, if my L3 receives a link-up notification, this notification should be integrity protected, replay protected, and source authenticated -- in some form. If these are not achieved, it can be "leveraged" for DoS attacks. I didn't mean to require DoS prevention for any DoS attacks. This level of security is very practical. In most (if not all) cases where the L2 and L3 reside on the same physical box, we rely on physical security. Only in cases where L2 and L3 reside on separate boxes, and they notifications go over a link, then we may need to rely on additional measures, like L2 or L3 security (IPsec). In fact, physical security may be used there too. Having said that, let me look at your text below... > As > a result, it seems that we are making a MUST that no one > can implement. You also do not specify what the implementor > needs to do to satisfy the MUST, so it would hard for > anyone to determine whether they are compliant with > the spec. > > What would perhaps be more useful is to avoid any > requirements, or say something that is a bit > more specific, such as "It is RECOMMENDED that > security at the link layer be used". > > Here's some strawman text: > > Attackers may spoof various indications at the link layer, or > manipulate the physical medium directly in an effort to confuse the > host about the state of the link layer. For instance, attackers may > spoof error messages or disturb the wireless medium to cause the host > to move its connection elsewhere or to even disconnect. Attackers may > also spoof information to make the host believe it has a connection > when, in reality, it does not. > > These attacks may cause use of non-preferred networks or even > denial-of-service. > > This specification does not provide any protection of its own for the > the indications from the lower layers. But the vulnerabilities > can be mitigated through the use of techniques in other > parts of the protocol stack. So far so good. > In particular, it is RECOMMENDED > that link layer security is used. What we need is L2 security that can specifically secure link-layer connection management related signaling. As you know, not all L2 security solutions do that. Also, we need to capture the other aspect: secure relaying of the event notification from L2 to the L3. > However, these techniques are typically unable to > protect against all threats, particularly those related to > denial-of-service. I'd not even mention DoSs. I didn't mean to get into general DoS. Just wanted to mention unsecured L2 events can lead up to DoS attacks. > It should also be noted that upper layer mechanisms may provide > partial protection against situations where incorrect event > notifications are generated. For instance, where Secure NEighbor > Discovery (SEND) [RFC 3971] is used, the host can ensure that it is > ultimately connected to an authorized router. I'm not sure if we really want to say that. Because it opens up a lot of questions and the solution is not straight forward. Let me know what you think about my points above. We can take your text as baseline. Alper > > --Jari > From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 15 14:22:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqwTq-0004Yt-KA for dna-archive@lists.ietf.org; Thu, 15 Jun 2006 14:22:10 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqwTo-0003G6-US for dna-archive@lists.ietf.org; Thu, 15 Jun 2006 14:22:10 -0400 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 <01M3OGYCTA3S8Y7K8C@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 16 Jun 2006 04:15:03 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1CD7BAB549; Fri, 16 Jun 2006 04:14:58 +1000 (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 9E92F4FB08; Fri, 16 Jun 2006 04:14:57 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k5FI9dw30777 for dna-list; Fri, 16 Jun 2006 04:09:39 +1000 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 k5FI9au30773 for ; Fri, 16 Jun 2006 04:09:36 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M3OGRJ6A7O8YI9VW@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 16 Jun 2006 04:09:19 +1000 Received: by localhost (Postfix, from userid 510) id 7D06CAB547; Fri, 16 Jun 2006 04:09:19 +1000 (EST) Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by curly.its.monash.edu.au (Postfix) with ESMTP id 285E64FB12 for ; Fri, 16 Jun 2006 04:09:17 +1000 (EST) Received: from [68.126.186.235] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus0) with ESMTP (Nemesis), id 0MKoyl-1FqwGx1xjW-0002nr; Thu, 15 Jun 2006 14:08:59 -0400 Date: Thu, 15 Jun 2006 11:08:44 -0700 From: Alper Yegin Subject: RE: [DNA] Review of draft-ietf-dna-link-information-03.txt In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: 'Bernard Aboba' , dna@eng.monash.edu.au Cc: nicolas.montavont@enst-bretagne.fr, 'Greg Daley' Message-id: <0MKoyl-1FqwGx1xjW-0002nr@mrelay.perfora.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Index: AcZ93qYgzTuBH/tETK2AlAK39u3pMARdZ1rA X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.0 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 > Review of draft-ietf-dna-link-information-03.txt > > Overall, I think this document has some issues: > > a. The document appears to apply to both IPv4 and IPv6, but it makes a > number of statements that do not reflect the operation of DNAv4 as defined > in RFC 4436. For example, DNAv4 does not utilize "link down" events or > make > use of link layer "hints". The document aims to be useful to both DNAv4 and DNAv6. While it defines the L2 events and their associated notifications, it does not aim defining how they shall be used. This is the job of DNA specifications. I guess there is some residual text that falls beyond this scope. You found some. We'll clean that up. > > b. A terminology section is needed, and terminology > consistency needs to be improved. For example the terms > "event notifications" and "link layer events" are used. It > is not clear to me if these are synonymous with terms such > as "triggers" or "link indications" used in other documents. Oh, we had banned the use of "triggers" in this community a while ago :-) I've looked at the definition of "Link indications" in your draft-iab-link-indications-04.txt document. Based on that, an event notification is a type of indication. Of course, there are other types of indications as well. For example, a non-event-notification type indication: L3 can read certain L2 attributes to use them as indications of various things (e.g., lack of security, lack of bandwidth, etc. etc.) Do we need to do anything to harmonize the two documents? Shall we state that "A link-layer event notification is a type of link indication [ref]"? Btw, your I-D makes statements like "Link Up event should not be sent"... It is the "event notification" that is sent, not the "event" itself. Event takes place in the L2. > Similarly, the term "link layer connection" is > used, which may or may not correspond to the term > "link up" used in this and other documents. "Link up" is an event provided by the link-layer that signifies a state change associated with the interface becoming capable of communicating data packets. This event is associated with a link- layer connection between the node and an attachment point. > c. Normative language is used relating to events without > a tie to the DNA spec. For example, the document requires > that "link down" events be generated prior to a "link up" without > indicating why such events would be helpful. In fact, in DNAv4 these > events will be ignored, and generating such events would actually be > harmful to operating systems or applications that tear down connections on > receipt of "link down" events. Irrespective of the "consumer of such event notifications", events do take place. And they should be marked that way in the L2 (a). Whether the "event notifications" shall be generated and sent up to the L3 is another story (b). And how they are used is a totally different story (c). For (b), I'll scan the document and make sure we don't overstep the scope and make statements about the event notifications being always sent up or anything. It's really upto the L3 and the specific consumer if it wants to hear certain types of notifications (b), and how they want to use it (c). > > Abstract: > > " Certain network access technologies are capable of providing various > link-layer status information to IP. Link-layer event notifications > can help IP expeditiously detect configuration changes. This > document provides a non-exhaustive catalogue of information available > from well-known access technologies." > > This abstract does not clearly indicate the purpose of the document. It > would be helpful to state that the primary purpose is to address > events relating to DNAv6 (since the document does not appear to apply to > DNAv4). DNAv2 and DNAv6 are the main focus. But.... this document should also be useful to other protocols, anything that talks about link up and link down at IETF. > > Section 1 > > " Detecting the subnet change can usually use > network-layer indications such as a change in the advertised prefixes > (i.e., appearance and disappearance of prefixes)." > > Is this document solely focussed on DNAv6? If IPv4 is in scope, then since > router advertisement is not widely implemented, it should be made clear > that prefixes are just an example. For example, you can change the text > to: > > " Detecting the subnet change can usually use > network-layer indications (such as a change in the advertised > prefixes for IPv6)." Good idea. > > "Establishment and > tear down of a link-layer connection are two basic events types. > Additional information can be conveyed in addition to the event type, > such as the identifier of the network attachment point (e.g., IEEE > 802.11 BSSID and SSID), or network-layer configuration parameters > obtained via the link-layer attachment process if available. It is > envisaged that such event notifications can in certain circumstances > be used to expedite the inter-subnet movement detection and > reconfiguration process. For example, the notification indicating > that the node has established a new link-layer connection MAY be used > for immediately probing the network for a possible configuration > change. In the absence of such a notification from the link-layer, > IP has to wait for indications that are not immediately available, > such as receipt of next scheduled router advertisement, > unreachability of the default gateway, etc." > > The term "link layer connection" is used here, but is not defined. > I am not sure whether this only relates to connection-oriented > link layers, or whether this is synonymous with "link up". Is there a better term to indicate both connection-oriented and connectionless link-layers are covered? > What are "network layer configuration parameters obtained via the > link-layer attachment process"? Perhaps an example would help (e.g. PPP > IPCP) OK. > > " Two basic link-layer events are considered potentially useful to DNA > process: link up and link down." > > This contradicts RFC 4436, Section 1.3: > "DNAv4 does not utilize "Link Down" indications." We shall remove that text. But I'm not suggesting we remove the "link down" as described in the document. Even if DNA methods don't use it, link down is the counter part to link up. It may very well be used by other specifications. People should have to write a separate document just for defining link-down. > "Each time the interface changes its point of attachment, a > link down event with the previous attachment point MUST be followed > by a link up event with the new one. Finally, when the network > interface is disabled, this MUST generate a link down event. Each > one of these events MUST generate a notification in the order they > occur." > > I don't understand the use of normative language here. Given that > link down is not used by DNAv4, why is it relevant to require that > link down events be generated on handoff? Existing operating systems > do not necessarily generate these events because they can be disruptive > to applications. I think the events MUST take place (i.e., there must be some state variable in the L2 that indicates the event took place). But I agree it's none of this I-D's business to state that the event notifications MUST be generated. Instead, "The link-layer MUST be capable of generating the matching event notifications. Whether the link-layer delivers a given type of event notification depends on the local configuration." And this says nothing about what the network-layer would do if it received any such notifications. > "While > merely knowing that a new link-layer connection is established may > prompt DNA process to immediately seek other clues for detecting > network configuration change, auxiliary information may constitute > further clues (and even the final answers sometimes)." > > DNAv4 does not utilize link-layer information this way. Rather than > utilizing link-layer "hints", in DNAv4, all the active configurations > are probed via ARP. > > Section 2.3 > > "A station (STA) MUST establish > a IEEE 802.11 link with an AP in order to send and receive IP > packets." > > I'm not clear why the term "link" is used here (I think this refers to > Association) or why it is normative (presumably the ability to send > data frames is determined by the 802.11 specification, not this document). Will fix. > > " BSSID and SSID MUST be provided as auxiliary information > along with the link up notification. Unfortunately this information > does not provide a deterministic indication of whether the IP-layer > configuration MUST be changed upon movement." > > Given the limitations of the BSSID and SSID, why the > normative language? DNAv4 implementations will not use this > information. BSSID/SSID info is always available to L2, therefore I don't see a problem in making them available to the L3. Reducing MUST to a SHOULD or MAY does not really buy us anything, but makes the L2 implementations less predictable. > "If authentication is performed, a link up indication can be > generated upon authentication, and a link down indication can be > generated upon deauthentication." > > What if authentication is not performed? How are "link up" > and "link down" determined? I'll let Nicolas answer that (IEEE 802.11). > > Section 2.4.2 > > " Ethernet networks commonly consist of LANs joined together by > transparent bridges (usually implemented as switches). Transparent > bridges require the active topology to be loop free. The Spanning > Tree Protocol (STP) achieves this by the exchange of Bridge Protocol > Data Unit (BPDU), as defined in [IEEE-802.1D], which leads to, where > required, the blocking of ports (i.e., not forwarding)." > > I think you need to mention RSTP here as well. > > " Most hosts today do not listen to BPDU frames. For these hosts, > connectivity to the a port which is potentially bridged (any Ethernet > port) carries the potential of frame loss if transmissions occur > before any bridges' ForwardDelay timers have expired twice." > > "to the a port" - "to the port" > > " If no bridge configuration messages are received within the > Bridge_Max_Age interval (default 20s), then it is likely that there > is no visible bridge whose port is enabled for bridging (S8.4.5 of > [IEEE-802.1D]), since at least two BPDU hello messages would have > been lost. Upon this timeout, a link up notification MUST be > generated. > > It is not easy for a non-STP host to distinguish between Disabled > bridge ports and non-bridge ports with no IP nodes on them, as > Disabled ports will have no traffic on them, and incur 100% sender > loss. > > Upon this Bridge_Max_Age timeout, a link up notification must be > generated. If an earlier link up was generated with the R-flag set, > this new one MUST set the A-flag showing that packets sent within the > prior interval were likely to have traversed the forwarding path > (unless the port is disabled)." > > The next section talks about when to enable the delay, but I think you > could be more clear about this here as well. For example, are you > recommending that hosts listen for STP/RSTP messages, or use 802.1AB > in order to decide on the appropriate delay? Delaying for 20 seconds > by default probably isn't a good idea now that RSTP is becoming more > common. > > " Due to the protocol's newness and lack of deployment, it is unclear > how this protocol will eventually affect DNA in IPv4 or IPv6 > networks." > > DNAv4 does not utilize 802.1AB "hints", so this could be clarified. > > Section 2.4.4 > > " Link-Layer indications in Ethernet-like networks are complicated by > additional unadvertised delays due to Spanning Tree calculations. > This may cause re-indication (link up with A-flag) or retraction > (link up with B-flag) of indications previously sent to upper layer > protocols." > > What are the A and B flags? Is this an artifact of a previous revision? > I'll let Greg answer these (Ethernet). Alper From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 15 14:22:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqwTs-0004Z7-TI for dna-archive@lists.ietf.org; Thu, 15 Jun 2006 14:22:12 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqwTq-0003G6-Sk for dna-archive@lists.ietf.org; Thu, 15 Jun 2006 14:22:12 -0400 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 <01M3OGYKQFAG8Y7OAI@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 16 Jun 2006 04:15:06 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CCD86AB54E; Fri, 16 Jun 2006 04:15:02 +1000 (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 6879A4FB08; Fri, 16 Jun 2006 04:15:02 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k5FI9Pe30768 for dna-list; Fri, 16 Jun 2006 04:09:25 +1000 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 k5FI9Ku30764 for ; Fri, 16 Jun 2006 04:09:21 +1000 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M3OGR8RCSM8YHM5G@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 16 Jun 2006 04:09:05 +1000 Received: by localhost (Postfix, from userid 510) id 7BC04AB543; Fri, 16 Jun 2006 04:09:05 +1000 (EST) Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by moe.its.monash.edu.au (Postfix) with ESMTP id 2EFD44FB04 for ; Fri, 16 Jun 2006 04:09:04 +1000 (EST) Received: from [68.126.186.235] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus0) with ESMTP (Nemesis), id 0MKoyl-1FqwH50ag1-0002nr; Thu, 15 Jun 2006 14:09:01 -0400 Date: Thu, 15 Jun 2006 11:08:45 -0700 From: Alper Yegin Subject: RE: [DNA] RE: draft-ietf-dna-link-information-03 In-reply-to: <448FE447.3000307@piuha.net> Sender: owner-dna@ecselists.eng.monash.edu.au To: 'Jari Arkko' Cc: dna@eng.monash.edu.au Message-id: <0MKoyl-1FqwH50ag1-0002nr@mrelay.perfora.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Index: AcaPnPtG53oL6n+wRT2hXW5RaZqsYwAWz11g X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Jari, all: Please see below for the revised text for the security considerations section. Especially the last paragraph. I personally find it useful. But if you believe it is not useful, or harmful, etc., I don't mind deleting it. Suggest deletion/modification/etc as you see appropriate. -- 4. Security Considerations Attackers may spoof various indications at the link-layer, or manipulate the physical medium directly in an effort to confuse the host about the state of the link-layer. For instance, attackers may spoof error messages or disturb the wireless medium to cause the host to move its connection elsewhere or to even disconnect. Attackers may also spoof information to make the host believe it has a connection when, in reality, it does not. These attacks may cause use of non-preferred networks or even denial-of-service. This specification does not provide any protection of its own for the the indications from the lower layers. But the vulnerabilities can be mitigated through the use of techniques in other parts of the protocol stack. In particular, it is RECOMMENDED that authentication, replay and integrity protection of link-layer management messages is enabled when available. Additionally, protocol stack may also use some upper layer mechanisms to achieve partial protection against situations where incorrect event notifications are generated (e.g., upper-layer confirmation of the link-layer event). When the link-layer and the network-layer reside on separate nodes as in a distributed stack implementation, the event notifications MUST be authenticated, replay and integrity protected as they are delivered. The specific mechanisms to achieve the security of notifications are outside the scope of this document. Alper > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Wednesday, June 14, 2006 3:26 AM > To: Alper Yegin > Cc: dna@eng.monash.edu.au > Subject: Re: [DNA] RE: draft-ietf-dna-link-information-03 > > Hi Alper, > > Some further discussion inline: > > > > > > >>In particular, it is RECOMMENDED > >>that link layer security is used. > >> > >> > > > >What we need is L2 security that can specifically secure link-layer > >connection management related signaling. As you know, not all L2 security > >solutions do that. > > > >Also, we need to capture the other aspect: secure relaying of the event > >notification from L2 to the L3. > > > > > This is stack internal unless you have a distributed implementation. > My advice would be to not start a discussion of how the distributed > implementation can secure its communication between L2 and L3. > > >>However, these techniques are typically unable to > >>protect against all threats, particularly those related to > >>denial-of-service. > >> > >> > > > >I'd not even mention DoSs. I didn't mean to get into general DoS. Just > >wanted to mention unsecured L2 events can lead up to DoS attacks. > > > > > Yes. Perhaps we could use a sentence that mentions the specific L2 event > DoS threat, and not my general DoS issue above. > > > > > > >>It should also be noted that upper layer mechanisms may provide > >>partial protection against situations where incorrect event > >>notifications are generated. For instance, where Secure NEighbor > >>Discovery (SEND) [RFC 3971] is used, the host can ensure that it is > >>ultimately connected to an authorized router. > >> > >> > > > >I'm not sure if we really want to say that. Because it opens up a lot of > >questions and the solution is not straight forward. > > > > > Its only an example. We could remove the example part or use another > example if you want. > > --Jari From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 15 18:41:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr0XA-0006mq-N2 for dna-archive@lists.ietf.org; Thu, 15 Jun 2006 18:41:52 -0400 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr0X8-0004eK-VO for dna-archive@lists.ietf.org; Thu, 15 Jun 2006 18:41:52 -0400 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M3OQ8ZLZMC8XDFF2@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 16 Jun 2006 08:40:52 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4A9C980004; Fri, 16 Jun 2006 08:40:42 +1000 (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 0DD493C005; Fri, 16 Jun 2006 08:40:42 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k5FMbYN01117 for dna-list; Fri, 16 Jun 2006 08:37:34 +1000 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 k5FMbXu01113 for ; Fri, 16 Jun 2006 08:37:33 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M3OQ4R8LOO8XDSKN@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 16 Jun 2006 08:37:26 +1000 Received: by localhost (Postfix, from userid 510) id A921180002; Fri, 16 Jun 2006 08:37:26 +1000 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id D65873C003 for ; Fri, 16 Jun 2006 08:37:25 +1000 (EST) Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id k5FMnXfJ031160; Thu, 15 Jun 2006 17:49:39 -0500 Received: from [142.133.10.59] (142.133.10.59 [142.133.10.59]) by eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id KYBW6JXR; Thu, 15 Jun 2006 17:37:16 -0500 Date: Thu, 15 Jun 2006 18:36:10 -0400 From: Suresh Krishnan Subject: [DNA] CONSENSUS CALL : Document merges Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Cc: "Suresh Krishnan (QB/EMC)" , Greg Daley , Jari Arkko Reply-to: suresh.krishnan@ericsson.ca Message-id: <4491E0DA.4000104@ericsson.ca> Organization: Ericsson MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-Priority: 1) User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Sybari-Trust: 2c22a385 d453c899 0dfa9b66 00000139 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Hi Folks, At the last meeting in Dallas lot of concerns were raised about the number of documents being produced by the WG. The Consensus was to reduce the number of documents to keep related information together. The chairs have identified two possible merger scenarios and would like to know the opinion of the working group regarding these two. Option A: ========= Combine 1) Detecting Network Attachment in IPv6 Networks (DNAv6) and 2) Tentative Options for Link-Layer Addresses in IPv6 Neighbour Discovery (draft-ietf-dna-protocol-00 + draft-ietf-dna-tentative-00) into one document. Merge 3) Detecting Network Attachment in IPv6 - Best Current Practices for hosts and 4) DNA with unmodified routers: Prefix list based approach (draft-ietf-dna-hosts-03 + draft-ietf-dna-cpl-02) into another document. Option B: ========= Merge all the above mentioned documents * draft-ietf-dna-protocol-00 * draft-ietf-dna-tentative-00 * draft-ietf-dna-hosts-03 * draft-ietf-dna-cpl-02 into a single document. This consensus call will last for two weeks and will end on the 29th of June 2006. Please respond to the list whether you * Prefer Option A * Prefer Option B If you do not have a preference and you are ok with either option, please respond with "Don't care ". If we have consensus on the Don't cares the chairs will make the decision. Thanks Suresh and Greg From dna-owner@webcamserver.eng.monash.edu.au Fri Jun 16 12:03:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrGnB-0006Of-Kw for dna-archive@lists.ietf.org; Fri, 16 Jun 2006 12:03:29 -0400 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrGn9-0000nt-Ki for dna-archive@lists.ietf.org; Fri, 16 Jun 2006 12:03:29 -0400 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M3PQNLE3XU8YG07I@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 17 Jun 2006 02:03:22 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BB3B1AB545; Sat, 17 Jun 2006 02:03:14 +1000 (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 5D2BC4FB05; Sat, 17 Jun 2006 02:03:14 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k5GFxC711295 for dna-list; Sat, 17 Jun 2006 01:59:12 +1000 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 k5GFxAu11291 for ; Sat, 17 Jun 2006 01:59:10 +1000 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M3PQI7P2EU8YI9JL@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 17 Jun 2006 01:58:56 +1000 Received: by localhost (Postfix, from userid 510) id D6B97AB546; Sat, 17 Jun 2006 01:58:55 +1000 (EST) Received: from hotmail.com (bay106-f33.bay106.hotmail.com [65.54.161.43]) by curly.its.monash.edu.au (Postfix) with ESMTP id 2E6DC4FB02 for ; Sat, 17 Jun 2006 01:58:55 +1000 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 16 Jun 2006 08:58:52 -0700 Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Fri, 16 Jun 2006 15:58:48 +0000 (GMT) Date: Fri, 16 Jun 2006 08:58:48 -0700 From: Bernard Aboba Subject: RE: [DNA] RE: draft-ietf-dna-link-information-03 In-reply-to: <0MKoyl-1FqwH50ag1-0002nr@mrelay.perfora.net> X-Originating-IP: [24.16.73.85] Sender: owner-dna@ecselists.eng.monash.edu.au X-Sender: bernard_aboba@hotmail.com To: alper.yegin@yegin.org, jari.arkko@piuha.net Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Originating-Email: [bernard_aboba@hotmail.com] X-OriginalArrivalTime: 16 Jun 2006 15:58:52.0508 (UTC) FILETIME=[C387C9C0:01C6915D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 >Additionally, protocol stack >may also use some upper layer mechanisms to achieve partial protection >against situations where incorrect event notifications are generated (e.g., >upper-layer confirmation of the link-layer event). Are you referring to DNA itself here? (e.g. use of SEND) >When the link-layer and the network-layer reside on separate nodes as in a >distributed stack implementation, the event notifications MUST be >authenticated, replay and integrity protected as they are delivered. The >specific mechanisms to achieve the security of notifications are outside >the >scope of this document. It seems odd to be making strong normative statements at the same time it is stated that the mechanisms to achieve the mandates are out of scope. Overall, I think there is still a missing piece here relating to damping. It is one thing for an attacker to be able to execute a DoS attack on one node; it is another to be able to leverage that node's DNA implementation to DoS others on the same network, or across the Internet. From dna-owner@webcamserver.eng.monash.edu.au Fri Jun 16 17:03:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrLTj-0002Qp-C2 for dna-archive@lists.ietf.org; Fri, 16 Jun 2006 17:03:43 -0400 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrLTh-0003IT-DD for dna-archive@lists.ietf.org; Fri, 16 Jun 2006 17:03:43 -0400 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M3Q13YFIWI8XD7QP@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 17 Jun 2006 07:02:53 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 22360AB548; Sat, 17 Jun 2006 07:02:46 +1000 (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 D83B64FB09; Sat, 17 Jun 2006 07:02:45 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k5GKwjM14346 for dna-list; Sat, 17 Jun 2006 06:58:45 +1000 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 k5GKwiu14342 for ; Sat, 17 Jun 2006 06:58:44 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M3Q0YNHIZU8XE1OL@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 17 Jun 2006 06:58:29 +1000 Received: by localhost (Postfix, from userid 510) id 9E7AB80002; Sat, 17 Jun 2006 06:58:29 +1000 (EST) Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by larry.its.monash.edu.au (Postfix) with ESMTP id BA5B33C010 for ; Sat, 17 Jun 2006 06:58:25 +1000 (EST) Received: from [207.62.244.181] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus1) with ESMTP (Nemesis), id 0MKp2t-1FrLON1cmc-0003cA; Fri, 16 Jun 2006 16:58:17 -0400 Date: Fri, 16 Jun 2006 13:56:59 -0700 From: Alper Yegin Subject: RE: [DNA] RE: draft-ietf-dna-link-information-03 In-reply-to: Sender: owner-dna@ecselists.eng.monash.edu.au To: 'Bernard Aboba' , jari.arkko@piuha.net Cc: dna@eng.monash.edu.au Message-id: <0MKp2t-1FrLON1cmc-0003cA@mrelay.perfora.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Index: AcaRXcPSb2QAO+etQc6jXC2Vsb9W5wAKEouA X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 > >Additionally, protocol stack > >may also use some upper layer mechanisms to achieve partial protection > >against situations where incorrect event notifications are generated > (e.g., > >upper-layer confirmation of the link-layer event). > > Are you referring to DNA itself here? (e.g. use of SEND) I know the above text is vague. If we try to make it more concrete by giving examples, I'm afraid we need to further expand on it as it is not straight forward how one can use SEND, etc. to achieve that added protection. If we cannot capture a solid solution (even as an example) without generating more questions than we answer, I'm inclined to delete the above paragraph as it may not help in this form. Thoughts? > >When the link-layer and the network-layer reside on separate nodes as in > a > >distributed stack implementation, the event notifications MUST be > >authenticated, replay and integrity protected as they are delivered. The > >specific mechanisms to achieve the security of notifications are outside > >the > >scope of this document. > > It seems odd to be making strong normative statements at the same time it > is > stated that the mechanisms to achieve the mandates are out of scope. I didn't think of shying away from a must-do just because we are not providing the solution in this document. Think of it as a requirement for the implementations of event notifications. Please let us know if you have a suggested text replacement. > Overall, I think there is still a missing piece here relating to damping. > It is one thing for an attacker to be able to execute a DoS attack on one > node; it is another to be able to leverage that node's DNA implementation > to DoS others on the same network, or across the Internet. This sounds reasonable. Can you please propose some text to capture what you are saying? Alper From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 22 06:13:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtMCC-0001yv-Bl for dna-archive@lists.ietf.org; Thu, 22 Jun 2006 06:13:56 -0400 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtMCA-0001SW-AR for dna-archive@lists.ietf.org; Thu, 22 Jun 2006 06:13:56 -0400 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M3XQK4F4PE8XF3RI@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 22 Jun 2006 19:27:16 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D3782AB547; Thu, 22 Jun 2006 19:26:46 +1000 (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 95A5F4FB1B; Thu, 22 Jun 2006 19:26:46 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k5M9Okl30939 for dna-list; Thu, 22 Jun 2006 19:24:46 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k5M9Oju30935 for ; Thu, 22 Jun 2006 19:24:45 +1000 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 <01M3XQHAJ5GI8Y8JUF@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 22 Jun 2006 19:24:31 +1000 Received: by localhost (Postfix, from userid 510) id 67806AB542; Thu, 22 Jun 2006 19:24:31 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by moe.its.monash.edu.au (Postfix) with ESMTP id 22C454FB0B; Thu, 22 Jun 2006 19:24:29 +1000 (EST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J1900ARW8QR59@mailout1.samsung.com>; Thu, 22 Jun 2006 18:23:15 +0900 (KST) Received: from NC (adsl-75-2-41-222.dsl.ipltin.sbcglobal.net [75.2.41.222]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0J1900D6W8QQHG@mmp1.samsung.com>; Thu, 22 Jun 2006 18:23:15 +0900 (KST) Date: Thu, 22 Jun 2006 18:23:14 +0900 From: JinHyeock Choi Subject: [DNA] Re: Review of draft-ietf-dna-frd-00.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley , dna@eng.monash.edu.au Cc: yun7521@samsung.com, Wassim.Haddad@ericsson.com, Suresh.Krishnan@ericsson.com Message-id: <023a01c695dd$7d2c15b0$de29024b@NC> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d38eb86565b1a4d8c3dba35af39014d Dear Greg Thanks for your kind and detailed feedback. Kindly find my inline comments. > This document has expired in the repository, please submit a new version. ok. > Please do not make any abbreviations in the abstract. Abbreviations > should be introduced on their first use in the text. > > It's not clear what the optimized result is... > > The Suggested abstract is as follows: > > For efficient detection of network Attachment, a host should quickly > receive a Router Advertisement upon a new link-layer connection. > This draft presents a quick advertisement acquisition scheme with > the support of a link-layer Point of Attachment. > > Upon a new network attachment, the Point of Attachment may either > trigger an Access Router to immediately send a unicast advertisement > "RA Triggering" or send such an advertisement itself "RA Proxying". > Such functions may be placed on a Point of Attachment to deliver > Router Advertisements rapidly without changes to IPv6 Neighbor > Discovery I checked a few RFCs, such as SeND (RFC 3971), and found out they also uses abbreviation in the abstract. Also DNA Goals (RFC 4135), which we co-authored, includes abbreviations in the abstract. Also when we wrote DNA Goals, Jim Bound explicitly objected 'abstract' to be separated into two parts as above. > Introduction > > DNA is used in paragraph 2 without being introduced. I added a text. > Paragraph 2 and 3 overlap in coverage. > > Here is a suggested amalgamation: > > > A host needs to receive a Router Advertisement (RA) when it has moved > to a different link in order to Detect Network Attachment (DNA). > Router advertisements contain IP prefix information which identify > the composition of a link, and the available prefixes to configure > upon link change. This document focusses on Rapid delivery of RA > messages without describing their content . > Those interested in RA contents are referred to > . I modified the phrases including the definition of 'a suitable RA'. > In Paragraph 4, please change sentence beginning "Second, ..." > as follows: > > Second, a host should randomly delay before initial transmission > of a Router Solicitation (RS) message. > > Please note that this restriction has been relaxed in RFC2461bis. ok, but I prefer 'delay random amount of time'. > Paragraph 5: > > s/broadcast/multicast/ because there is 'over wireless link', I prefer 'broadcast'. > s/For DNA purpose/For DNA purposes/ ok. > Paragraph 6: > > s/PoA (Point of Attachment) is the link endpoint fo the link, such as/ > A PoA is a link-layer connection point through which a wired or wireless > host > interfaces to an access network, such as/ This is how PoA is defined in Bernard Aboba's DNAv4 (RFC4436). When he wrote the draft, we had a discussion about the terminology to synchronize DNAv4 and DNAv6. I guess we'd better be in sync with the existing definition unless that's unacceptable. > s/, PoA,/, the PoA/ ok. > s/delivered to the host in unicast/unicast to the host/ > > Paragraph 7: > > s/the PoA may either trigger an AR (Access Router) to immediately send a > suitable RA or/ > the PoA may trigger an AR to either sen Please elaborate more. The current ones seem better to me. > Protocol Overview: > > Paragraph 1: > > I suggest replacing the text with: > > Using the procedures outlined in this document, when a host establishes a > link-layer connection a PoA, can detect the host's new attachment and get > the necessary information to deliver an unicast L2 frame to it. For > example, this link-layer information may be a 802.11 MAC address or > 802.16 > CID (Connection Identifier) [19]. I can't see the benefit of a change. Please elaborate more. The document doesn't intend to outline the procedures for a PoA to detect the host's new attachment and get the necessary information to deliver an unicast L2 frame to it. Those are given and out of scope and described only when necessary for explaining FRD process. > Paragraph 2: > > s/forward the information/forward the link-layer information/ > > Paragraph 3: > > s/Or the PoA/Alternatively, the PoA/ > > 3.1 RA triggering: > > Paragraph 1: > > s/to IP layer/to the IP layer/ > > > Paragraph2: > > s/deliver the AR the Link Up event notification/ > deliver a Link Up event notification to the AR/ > > Paragraph 3: > s/TSLLAO/Tentative Option/ > > 3.2 RA proxying: > > Paragraph 2 > > > s/We may manually/An administrator may manually/ > > s/use the scanning scheme/use an RA scanning scheme/ > > s/Or PoA and AR may use a special information service/ > Alternatively, a PoA and AR may use an information service/ > > s/porxy/proxy/ > > Paragraph 3 > > s/, PoA may/, the PoA may/ ok. > 4. RA Triggering > > Suggest replacement of paragraph 1 with: > > In case the PoA and AR are in the same node, when a new host is attached > link-layer events may be delivered locally. The arriving host's > link-layer > address can be passed from the PoA (Link-Layer) to the AR (IP Layer) in > the same stack. Subsequently, the AR can immediately send a suitable > RA in a unicast L2 frame with the new host's MAC address. > > Paragraph 2: > > s/, we may use/, they may communicate using/ > > Paragraph 4: > > Add to the end: > > Further deatils of these operations are provided in section 5.1.3. I prefer the current ones. For example 5.1.3 is not about further details of 4. Please elaborate whey changes are needed. > 5. RA proxying: > > paragraph 1: > > s/we recomment to use RA triggering instead/ > it is RECOMMENDED that RA triggering is used instead/ > > 5.1 RA Caching: > > Replace with: > > Three different methods for storing RAs in a PoA are presented. I prefer the current ones. For example, this is intended as an Informational and why should we RECOMMEND? Please elaborate whey changes are needed. > 5.1.1 Manual Configuration: > > please replace with: > > In the simplest way, an administraotr can manually configure a > suitable RA in the PoA. Such an RA may contain a link-identifier > or be a Complete RA . This > may be applicable where the AR and PoA are under the same administrative > control, and the RA message contents don't change often. I modified the text with the term 'a suitable RA'. > 5.1.2 Scanning > > Note that there is no description of a suitable RA. I added it in Introduction. > paragraph 1 > > s/L2 frame /L2 frames / > > Paragraph 2: > > s/scans L2 frame/scans the L2 frame/ > > s/sends that frame down the link and scans a next L2 frame/ > ignores that frame for caching purposes/ > > s/If incoming/If an incoming/ ok. > Paragraph 3: > > Please replace the paragraph with: > > A PoA can scan continuously, updating an old RA with a new RA. > Alternatively, if it costs too much for the PoA to scan every > incoming L2 frame, it may control the scanning rate. For example, > it can set a timer and execute scanning every T seconds, Or the PoA > itself can send a Router Solicitation (RS) message periodically. > It is noted that the PoA doesn't need to have an IP address since > it can use the unspecified address as its RS source address. > > Paragraph 4: > > Please replace with: > > It assists RA caching if routers advertised changed parameters > rapidly as described in section 6.2.6 of IPv6 Neighbour Discovery > . I don't see much difference from the current one. Please elaborate whey changes are needed. > 5.1.3 MICS (Media Indepenent Comment (sic) Service) > > Globally: > > s/Comment Service/Command Service/ > > > Paragraph2: > s/Remote MIH Command, "MIH Network Address Information"/ > Remote MIH Command Primitive: "MIH Network Address Information"/ I checked with Xiaoyu, 802.21 secretary, and he recommended the current one. 'Primitive' is used inside local stack. > Paragraph3: > it greatly concerns me that this paragraph suggests standardization > by someone "we"! that a new 802.21 Command service primitive is defined > for this role. > As described in 7.4.11 of 802.21 D01.00, Network Address Information > request can be used to gather addressing and routing information on the PoA. > > There are still uncertainties there regarding the content of messages, > and any recommendations seem highly conjectural for a document aiming > to be an RFC. > > Perhaps such suggestions should be placed in the appendix. I see your point. I made a comment at the end accordingly. Also, if needed, we can move it to Appendix. > 5.2 RA Delivery > > s/attachement/attachment/ > > s/describes/described/ > > 5.2.1 802.11 > > No mention of how this works with 802.11i RSN is made. > > This needs to be fixed. ok. > 5.2.2 802.16 > > Paragraph 3 and Paragraph 7 > Both seem to indicate that 802.16 procedures are not > well enough developed to normatively describe. > > This section should be removed or moved to an appendix. > > My concern here is that it's implicitly putting requirements > on 802.16 for the channel establishment operations. The main concern was that the connection to be used for ND is not decided but now it become more clear. ND messages can be carried in a separate transport connection, ISF (Initial Service Flow). I reflected that into the text. > 7. Security Considerations > > DoS Attacks seem to be ignored here. I mentioned about excessive signaling. > parrticularly: > > Paragraph 3: > > It's wrong to say there's no FRD specific problem, as > false or spurious Associations (caused by a sequence of > L2 messages) can be used to trigger an additional RA > on the PoA. This is a potential amplification attack > in some scenarios, and consumes wireless medium bandwidth. I mentioned that in relationship with excessive signaling. > s/through secure port/through a secure port/ ok. > Paragraph 4: > > It is wrong to say there is no additional security vulnrebility > if there's not a secured path between PoA and AR. > > An on-link attacker can potentially forge MICS events which > can force the Router to place configuration information on > the PoA. > > An attacker can also fill the PoA's cache with false router advertisements, > which can make change undetectable for nodes transiting from an > adjacent link. This will significantly slow change detection. I modified the text. But take notice, even without FRD, an attacker can send a bogus RA for itself to mislead the DNA decision. > Paragraphs 6-9 > > Ownership proof is best not hidden in the Security considerations > section. It's clearly the crux of how to cache securely. > > You need to ensure that the Solicited RA (from the RS with the OP > option) contains a valid Timestamp option though, and that the > solicited timestamp is within range. > > Please state this (and that an OP on the subsequent RA cannot > be used as proof instead). OP part is intended to sketch a scheme. So I guess general overview is ok and wonder it's necessary to delve into details. > ----------------------------------------- > > idnits 1.101 > > tmp/draft-ietf-dna-frd-00.txt: > > > Checking nits according to http://www.ietf.org/ID-Checklist.html: > > Checking conformance with RFC 3978/3979 boilerplate... > > the boilerplate looks good. > > No nits found. > > Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: > Nothing found here (but these checks do not cover all of > 1id-guidelines.txt yet). > > Miscellaneous warnings: > - The document seems to lack the recommended RFC 2119 boilerplate, even if > it appears to use RFC 2119 keywords. > > RFC 2119 paragraph 2 text: > "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119." > > > Experimental warnings: > - Unused Reference: [2] is defined on line 474, but not referenced > ' [2] Thomson, S. and T. Narten, "IPv6 Stateless Address' > > - Unused Reference: [3] is defined on line 477, but not referenced > ' [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)' > > - Unused Reference: [6] is defined on line 488, but not referenced > ' [6] Nordmark, E. and J. Choi, "DNA with unmodified routers: > Prefix' > > - Unused Reference: [8] is defined on line 496, but not referenced > ' [8] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in' > > - Unused Reference: [11] is defined on line 506, but not referenced > ' [11] Pentland, B., "An Overview of Approaches to Detecting Network' > > - Unused Reference: [15] is defined on line 522, but not referenced > ' [15] Aboba, B., "Detecting Network Attachment (DNA) in IPv4",' > > - Unused Reference: [16] is defined on line 525, but not referenced > ' [16] Nordmark, E., "MIPv6: from hindsight to foresight?",' > > - Unused Reference: [17] is defined on line 529, but not referenced > ' [17] Kempf, J., Khalil, M., and B. Pentland, "IPv6 Fast Router' > > - Unused Reference: [18] is defined on line 533, but not referenced > ' [18] Daley, G. and J. Choi, "Movement Detection Optimization in' > > - Unused Reference: [20] is defined on line 541, but not referenced > ' [20] IEEE 802.16 TGe Working Document (Draft Standard), "Amendment' > > > No nits found. > > General: > > please remove references to: > > draft-ietf-dna-soln-frame-00 (deprecated) > draft-ietf-dna-cpl-01 (unless referenced from paragraph 2 of introduction). > draft-jinchoi-dna-protocol2-01 (linkid related) > draft-mkhalil-ipv6-fastra-05 (?, is it going to be referenced?) > draft-nordmark-mobileip-mipv6-hindsight (linkid related) > > Please update references to: > draft-ietf-send-ndopt-06 --> RFC 3971 > draft-ietf-dhc-dnav4-16 --> RFC 4436 > draft-daley-ipv6-tsllao-02 --> draft-ietf-dna-tentative-00 > draft-pentland-sna-protocol-01 --> draft-ietf-dna-protocol-00 > draft-ietf-dna-link-information-02 --> draft-ietf-dna-link-information-03 > > IEEE 802.21 draft D00.01 --> D01 I changed the draft number but prefer remove the ref at the last moment. (It's easier to remove than add.) Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 22 09:44:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtPUI-00047F-AQ for dna-archive@lists.ietf.org; Thu, 22 Jun 2006 09:44:50 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtMXZ-0002T6-DM for dna-archive@lists.ietf.org; Thu, 22 Jun 2006 06:36:01 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtMKE-0001q6-IW for dna-archive@lists.ietf.org; Thu, 22 Jun 2006 06:22:17 -0400 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 <01M3XS806TM68WWYN2@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 22 Jun 2006 20:14:19 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C51F0AB547; Thu, 22 Jun 2006 20:14:16 +1000 (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 78D2E4FB12; Thu, 22 Jun 2006 20:14:16 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k5MAE0731463 for dna-list; Thu, 22 Jun 2006 20:14:00 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k5MADxu31459 for ; Thu, 22 Jun 2006 20:13:59 +1000 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 <01M3XS7C8NNW8Y8F8F@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 22 Jun 2006 20:13:44 +1000 Received: by localhost (Postfix, from userid 510) id C17B4AB544; Thu, 22 Jun 2006 20:13:44 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by moe.its.monash.edu.au (Postfix) with ESMTP id E720A4FB0A; Thu, 22 Jun 2006 20:13:43 +1000 (EST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J1900F51B2SUE@mailout2.samsung.com>; Thu, 22 Jun 2006 19:13:40 +0900 (KST) Received: from NC (adsl-75-2-41-222.dsl.ipltin.sbcglobal.net [75.2.41.222]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0J19002CJB2SDT@mmp2.samsung.com>; Thu, 22 Jun 2006 19:13:40 +0900 (KST) Date: Thu, 22 Jun 2006 19:13:39 +0900 From: JinHyeock Choi Subject: [DNA] FRD I-D Update Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley , dna@eng.monash.edu.au Cc: yun7521@samsung.com, Wassim.Haddad@ericsson.com, Suresh.Krishnan@ericsson.com Message-id: <028701c695e4$886faca0$de29024b@NC> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: References: X-Spam-Score: -2.6 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Dear WG We have updated the FRD draft. It's not in the repository yet but available in http://www.diffeo.com/drafts/draft-ietf-dna-frd-01.txt Mainly we reflected the changes which happened since the 00-version such as DNA solution progress & 802.16 ISF (Initial Service Flow) definition. Also we incorporated feedback from WG, special thanks to Greg for detailed comments. Additional new text was introduced in last 2 paragraphs of section 4 and last 2 paragraphs of the security considerations. Please give your opinion on the addition. Kindly see that everything is ok. We wish to LC the draft in near future, so your feedback would be appreciated. Thanks for your kind consideration. Authors From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 22 18:53:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtY36-0000Ks-LX for dna-archive@lists.ietf.org; Thu, 22 Jun 2006 18:53:20 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtY34-0004Rc-5v for dna-archive@lists.ietf.org; Thu, 22 Jun 2006 18:53:20 -0400 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 <01M3YINP60YS8WWYNG@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 23 Jun 2006 08:51:28 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8900D80003; Fri, 23 Jun 2006 08:51:23 +1000 (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 4C5D53C007; Fri, 23 Jun 2006 08:51:23 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k5MMoI506646 for dna-list; Fri, 23 Jun 2006 08:50:18 +1000 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 k5MMoHu06640 for ; Fri, 23 Jun 2006 08:50:17 +1000 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 <01M3YIM1VYSS8WWYNG@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 23 Jun 2006 08:50:07 +1000 Received: by localhost (Postfix, from userid 510) id 92E2AAB546; Fri, 23 Jun 2006 08:50:07 +1000 (EST) Received: from cypress.neustar.com (cypress.neustar.com [209.173.57.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by curly.its.monash.edu.au (Postfix) with ESMTP id 346964FB03 for ; Fri, 23 Jun 2006 08:50:05 +1000 (EST) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5MMo1mU022636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jun 2006 22:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtXzt-0007sE-Lf; Thu, 22 Jun 2006 18:50:01 -0400 Date: Thu, 22 Jun 2006 18:50:01 -0400 From: Internet-Drafts@ietf.org Subject: [DNA] I-D ACTION:draft-ietf-dna-frd-01.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: i-d-announce@ietf.org Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_W3WqFXBZUkCi0KuzWG1WXg)" X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Spam-Score: 0.2 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 --Boundary_(ID_W3WqFXBZUkCi0KuzWG1WXg) Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Detecting Network Attachment Working Group of the IETF. Title : Fast Router Discovery with L2 support Author(s) : J. Choi, et al. Filename : draft-ietf-dna-frd-01.txt Pages : 20 Date : 2006-6-22 For efficient Detecting Network Attachment (DNA), a host should quickly receive a Router Advertisement (RA) message upon a new link- layer connection. This draft presents a quick RA acquisition scheme with the support of a link-layer entity, Point of Attachment (PoA). Upon a new network attachment, the PoA may either trigger an Access Router (AR) to immediately send an unicast RA, "RA Triggering" or send such an RA for itself, "RA Proxying". We may put "RA Triggering" or "RA Proxying" functionality on a PoA to get the optimized result without IPv6 standard change. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dna-frd-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dna-frd-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dna-frd-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_W3WqFXBZUkCi0KuzWG1WXg) Content-type: multipart/alternative; boundary="Boundary_(ID_Abb/bXaq6qXxs+vuGuCMaA)" --Boundary_(ID_Abb/bXaq6qXxs+vuGuCMaA) Content-type: Message/External-body; access-type=mail-server; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-22151044.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dna-frd-01.txt --Boundary_(ID_Abb/bXaq6qXxs+vuGuCMaA) Content-type: Message/External-body; name=draft-ietf-dna-frd-01.txt; site=ftp.ietf.org; access-type=anon-ftp; directory=internet-drafts Content-disposition: attachment; filename=draft-ietf-dna-frd-01.txt Content-Type: text/plain Content-ID: <2006-6-22151044.I-D@ietf.org> --Boundary_(ID_Abb/bXaq6qXxs+vuGuCMaA)-- --Boundary_(ID_W3WqFXBZUkCi0KuzWG1WXg)-- From dna-owner@webcamserver.eng.monash.edu.au Fri Jun 23 15:08:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftr0g-0007Zn-Ks for dna-archive@lists.ietf.org; Fri, 23 Jun 2006 15:08:06 -0400 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftr0e-0003Cc-Rw for dna-archive@lists.ietf.org; Fri, 23 Jun 2006 15:08:06 -0400 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M3ZP490S3W8YJHTO@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 24 Jun 2006 05:07:42 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B2CDA80004; Sat, 24 Jun 2006 05:07:19 +1000 (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 6AA3A3C006; Sat, 24 Jun 2006 05:07:19 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k5NJ5Pl18725 for dna-list; Sat, 24 Jun 2006 05:05:25 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k5NJ5Nu18719 for ; Sat, 24 Jun 2006 05:05:23 +1000 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 <01M3ZP1JBH8Y8WX0AI@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 24 Jun 2006 05:05:08 +1000 Received: by localhost (Postfix, from userid 510) id 8EF8D80002; Sat, 24 Jun 2006 05:05:08 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by larry.its.monash.edu.au (Postfix) with ESMTP id 45ED43C005 for ; Sat, 24 Jun 2006 05:05:07 +1000 (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 k5NJ57tj018357; Fri, 23 Jun 2006 15:05:07 -0400 Received: from [150.169.1.185] ([150.169.1.185]) by redwood.research.panasonic.com (MOS 3.7.4b-GA) with ESMTP id AGK19394; Fri, 23 Jun 2006 15:03:05 -0400 (EDT) Date: Fri, 23 Jun 2006 15:03:55 -0400 From: Sathya Narayanan Subject: Re: [DNA] CONSENSUS CALL : Document merges In-reply-to: <4491E0DA.4000104@ericsson.ca> Sender: owner-dna@ecselists.eng.monash.edu.au To: suresh.krishnan@ericsson.ca Cc: Dna , "Suresh Krishnan (QB/EMC)" , Greg Daley , Jari Arkko Message-id: <449C3B1B.6050605@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-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Junkmail-Status: score=10/57, host=redwood.research.panasonic.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090203.449C399E.0076,ss=1,fgs=0, ip=150.169.1.185, so=2006-02-11 11:31:14, dmn=5.2.4/2006-05-04 References: <4491E0DA.4000104@ericsson.ca> X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 I prefer option A. As I mentioned earlier, I think option A is the more practical option. thanks, Sathya Suresh Krishnan wrote: > Hi Folks, > At the last meeting in Dallas lot of concerns were raised about the > number of documents being produced by the WG. The Consensus was to > reduce the number of documents to keep related information together. > The chairs have identified two possible merger scenarios and would > like to know the opinion of the working group regarding these two. > > > Option A: > ========= > Combine > 1) Detecting Network Attachment in IPv6 Networks (DNAv6) > and > 2) Tentative Options for Link-Layer Addresses in IPv6 Neighbour Discovery > (draft-ietf-dna-protocol-00 + draft-ietf-dna-tentative-00) > > into one document. > > Merge > 3) Detecting Network Attachment in IPv6 - Best Current Practices for > hosts > and > 4) DNA with unmodified routers: Prefix list based approach > (draft-ietf-dna-hosts-03 + draft-ietf-dna-cpl-02) > > into another document. > > Option B: > ========= > > Merge all the above mentioned documents > > * draft-ietf-dna-protocol-00 > * draft-ietf-dna-tentative-00 > * draft-ietf-dna-hosts-03 > * draft-ietf-dna-cpl-02 > > into a single document. > > This consensus call will last for two weeks and will end on the 29th of > June 2006. Please respond to the list whether you > > * Prefer Option A > * Prefer Option B > > If you do not have a preference and you are ok with either option, > please respond with "Don't care ". If we have consensus on the Don't > cares the chairs will make the decision. > > Thanks > Suresh and Greg From dna-owner@webcamserver.eng.monash.edu.au Fri Jun 23 20:05:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftves-0005yh-E5 for dna-archive@lists.ietf.org; Fri, 23 Jun 2006 20:05:54 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftveq-0002I0-ND for dna-archive@lists.ietf.org; Fri, 23 Jun 2006 20:05:54 -0400 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 <01M3ZY63SCLU8Y8SPE@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 24 Jun 2006 09:26:14 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D8E4780008; Sat, 24 Jun 2006 09:26:07 +1000 (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 93C243C003; Sat, 24 Jun 2006 09:26:07 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k5NNP7G21204 for dna-list; Sat, 24 Jun 2006 09:25:07 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k5NNP4u21200 for ; Sat, 24 Jun 2006 09:25:04 +1000 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 <01M3ZY3ZLG6Q8WWZAX@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 24 Jun 2006 09:24:54 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9B0A5AB543; Sat, 24 Jun 2006 09:24:25 +1000 (EST) Received: from [192.168.1.101] (cust1648.vic01.dataco.com.au [202.63.56.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: brett) by moe.its.monash.edu.au (Postfix) with ESMTP id F2E1D4FB03; Sat, 24 Jun 2006 09:24:24 +1000 (EST) Date: Sat, 24 Jun 2006 09:24:21 +1000 From: Brett Pentland Subject: Re: [DNA] CONSENSUS CALL : Document merges In-reply-to: <4491E0DA.4000104@ericsson.ca> Sender: owner-dna@ecselists.eng.monash.edu.au To: suresh.krishnan@ericsson.ca Cc: Dna , "Suresh Krishnan (QB/EMC)" , Greg Daley , Jari Arkko Message-id: <449C7825.6080701@eng.monash.edu.au> 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 1.0.7 (Windows/20050923) References: <4491E0DA.4000104@ericsson.ca> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Though it's more work, I think option B will make it easier for developers to find what they need. Brett. Suresh Krishnan wrote: > Hi Folks, > At the last meeting in Dallas lot of concerns were raised about the > number of documents being produced by the WG. The Consensus was to > reduce the number of documents to keep related information together. > The chairs have identified two possible merger scenarios and would > like to know the opinion of the working group regarding these two. > > > Option A: > ========= > Combine > 1) Detecting Network Attachment in IPv6 Networks (DNAv6) > and > 2) Tentative Options for Link-Layer Addresses in IPv6 Neighbour Discovery > (draft-ietf-dna-protocol-00 + draft-ietf-dna-tentative-00) > > into one document. > > Merge > 3) Detecting Network Attachment in IPv6 - Best Current Practices for hosts > and > 4) DNA with unmodified routers: Prefix list based approach > (draft-ietf-dna-hosts-03 + draft-ietf-dna-cpl-02) > > into another document. > > Option B: > ========= > > Merge all the above mentioned documents > > * draft-ietf-dna-protocol-00 > * draft-ietf-dna-tentative-00 > * draft-ietf-dna-hosts-03 > * draft-ietf-dna-cpl-02 > > into a single document. > > This consensus call will last for two weeks and will end on the 29th of > June 2006. Please respond to the list whether you > > * Prefer Option A > * Prefer Option B > > If you do not have a preference and you are ok with either option, > please respond with "Don't care ". If we have consensus on the Don't > cares the chairs will make the decision. > > Thanks > Suresh and Greg From dna-owner@webcamserver.eng.monash.edu.au Fri Jun 23 22:37:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fty1p-00017P-VE for dna-archive@lists.ietf.org; Fri, 23 Jun 2006 22:37:46 -0400 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fty1n-0007zd-Er for dna-archive@lists.ietf.org; Fri, 23 Jun 2006 22:37:45 -0400 Received: from moe.its.monash.edu.au ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M404R97VRU8XFE8M@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 24 Jun 2006 12:35:19 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 0325EAB544; Sat, 24 Jun 2006 12:34:59 +1000 (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 B684B4FB08; Sat, 24 Jun 2006 12:34:58 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k5O2YBe23066 for dna-list; Sat, 24 Jun 2006 12:34:11 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k5O2Y9u23062 for ; Sat, 24 Jun 2006 12:34:09 +1000 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 <01M404PV2L128WWZH3@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 24 Jun 2006 12:33:54 +1000 Received: by localhost (Postfix, from userid 510) id 7EF1480002; Sat, 24 Jun 2006 12:33:54 +1000 (EST) Received: from hotmail.com (bay106-f22.bay106.hotmail.com [65.54.161.32]) by larry.its.monash.edu.au (Postfix) with ESMTP id CEDE83C005; Sat, 24 Jun 2006 12:33:53 +1000 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 23 Jun 2006 19:33:51 -0700 Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Sat, 24 Jun 2006 02:33:46 +0000 (GMT) Date: Fri, 23 Jun 2006 19:33:46 -0700 From: Bernard Aboba Subject: Re: [DNA] CONSENSUS CALL : Document merges In-reply-to: <449C7825.6080701@eng.monash.edu.au> X-Originating-IP: [71.38.130.70] Sender: owner-dna@ecselists.eng.monash.edu.au X-Sender: bernard_aboba@hotmail.com To: brett.pentland@eng.monash.edu.au, suresh.krishnan@ericsson.ca Cc: dna@eng.monash.edu.au, suresh.krishnan@ericsson.com, gregd@research.panasonic.com, jari.arkko@piuha.net Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Originating-Email: [bernard_aboba@hotmail.com] X-OriginalArrivalTime: 24 Jun 2006 02:33:51.0148 (UTC) FILETIME=[A0FB26C0:01C69736] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 I also agree that option B is preferrable. >Though it's more work, I think option B will make it easier for developers >to find what they need. > >Brett. From dna-owner@webcamserver.eng.monash.edu.au Sat Jun 24 06:24:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu5Jb-00007q-GJ for dna-archive@lists.ietf.org; Sat, 24 Jun 2006 06:24:35 -0400 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fu5JZ-0006KZ-GC for dna-archive@lists.ietf.org; Sat, 24 Jun 2006 06:24:35 -0400 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 <01M40L56Q7A08Y8WVG@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 24 Jun 2006 20:24:23 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A01C180004; Sat, 24 Jun 2006 20:24:20 +1000 (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 681AE3C00B; Sat, 24 Jun 2006 20:24:20 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k5OAN6O27462 for dna-list; Sat, 24 Jun 2006 20:23:06 +1000 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 k5OAN2u27458 for ; Sat, 24 Jun 2006 20:23:02 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M40L38LKDA8YIXHE@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 24 Jun 2006 20:22:46 +1000 Received: by localhost (Postfix, from userid 510) id 821AE80003; Sat, 24 Jun 2006 20:22:46 +1000 (EST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id C49363C008 for ; Sat, 24 Jun 2006 20:22:45 +1000 (EST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k5OAMe9q003747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 24 Jun 2006 06:22:40 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k5OAMpAF183410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 24 Jun 2006 04:22:53 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k5OAMcuc018888 for ; Sat, 24 Jun 2006 04:22:38 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-234-227.mts.ibm.com [9.65.234.227]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k5OAMbGR018852; Sat, 24 Jun 2006 04:22:37 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.6/8.12.5) with ESMTP id k5OAMPWU020347; Sat, 24 Jun 2006 10:22:29 +0000 (GMT) Date: Sat, 24 Jun 2006 10:22:25 +0000 From: Thomas Narten Subject: Re: [DNA] CONSENSUS CALL : Document merges In-reply-to: <449C3B1B.6050605@Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: suresh.krishnan@ericsson.ca, Dna , "Suresh Krishnan (QB/EMC)" , Greg Daley , Jari Arkko Message-id: <200606241022.k5OAMPWU020347@cichlid.raleigh.ibm.com> MIME-version: 1.0 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: References: <4491E0DA.4000104@ericsson.ca> <449C3B1B.6050605@Research.Panasonic.COM> Comments: In-reply-to Sathya Narayanan message dated "Fri, 23 Jun 2006 15:03:55 -0400." X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa > As I mentioned earlier, I think option A is the more practical > option. Can you clarify? Does more practical mean "less work for the current authors", or does it mean something else? Personally, I think we should go the route that makes the most sense for implementors who will be implementing from the RFCs, long after this WG goes away. Even if this is somewhat more work for the WG. > > Option A: > > ========= > > Combine > > 1) Detecting Network Attachment in IPv6 Networks (DNAv6) > > and > > 2) Tentative Options for Link-Layer Addresses in IPv6 Neighbour Discovery > > (draft-ietf-dna-protocol-00 + draft-ietf-dna-tentative-00) > > > > into one document. > > > > Merge > > 3) Detecting Network Attachment in IPv6 - Best Current Practices for > > hosts > > and > > 4) DNA with unmodified routers: Prefix list based approach > > (draft-ietf-dna-hosts-03 + draft-ietf-dna-cpl-02) IMO, there should be one single document that tells implementors what to implement. I don't think it is helpful to have 2 different documents giving guidanace on this point. > > Option B: > > ========= > > > > Merge all the above mentioned documents > > > > * draft-ietf-dna-protocol-00 > > * draft-ietf-dna-tentative-00 > > * draft-ietf-dna-hosts-03 > > * draft-ietf-dna-cpl-02 > > > > into a single document. That would be my preference. Thomasu From dna-owner@webcamserver.eng.monash.edu.au Sat Jun 24 10:06:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu8me-0007sJ-Br for dna-archive@lists.ietf.org; Sat, 24 Jun 2006 10:06:48 -0400 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fu8mb-00005W-1b for dna-archive@lists.ietf.org; Sat, 24 Jun 2006 10:06:48 -0400 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M40OFL9A6A8XFM1Z@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 24 Jun 2006 21:58:35 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 662EAAB546; Sat, 24 Jun 2006 21:58:14 +1000 (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 0EB444FB03; Sat, 24 Jun 2006 21:58:14 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k5OBvZV28384 for dna-list; Sat, 24 Jun 2006 21:57:35 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k5OBvXu28380 for ; Sat, 24 Jun 2006 21:57:33 +1000 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 <01M40OEFGN4K8WX0Y0@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 24 Jun 2006 21:57:20 +1000 Received: by localhost (Postfix, from userid 510) id 2D9FCAB544; Sat, 24 Jun 2006 21:57:20 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by moe.its.monash.edu.au (Postfix) with ESMTP id EE8134FB06 for ; Sat, 24 Jun 2006 21:57:18 +1000 (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 k5OBvJdm031237; Sat, 24 Jun 2006 07:57:19 -0400 Received: from pintlmail.MITL.Research.Panasonic.COM (pintlmail.Research.Panasonic.COM [150.169.1.62]) by redwood.research.panasonic.com (MOS 3.7.4b-GA) with ESMTP id AGK59669; Sat, 24 Jun 2006 07:55:09 -0400 (EDT) Received: from [68.84.59.43] by pintlmail.MITL.Research.Panasonic.COM (mshttpd) ; Sat, 24 Jun 2006 07:57:07 -0400 Date: Sat, 24 Jun 2006 07:57:07 -0400 From: Sathya Narayanan Subject: Re: [DNA] CONSENSUS CALL : Document merges Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten Cc: suresh.krishnan@ericsson.ca, Dna , "Suresh Krishnan (QB/EMC)" , Greg Daley , Jari Arkko Message-id: <10cced7e5.d7e510cce@pintlmail.MITL.Research.Panasonic.COM> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.09 (built Jan 7 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Junkmail-Status: score=10/57, host=redwood.research.panasonic.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090202.449D26D2.0016,ss=1,fgs=0, ip=68.84.59.43, so=2006-02-11 11:31:14, dmn=5.2.4/2006-05-04 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 > > As I mentioned earlier, I think option A is the more practical > > option. > > Can you clarify? Does more practical mean "less work for the current authors", or does it mean something else? Yes - it means "less work for the current authors ang the group". But, my intention is not to reduce work alone, I am just concerned that more work may lead to the work not getting done in a timely manner. > Personally, I think we should go the route that makes the most sense > for implementors who will be implementing from the RFCs, long after this WG goes away. Even if this is somewhat more work for the WG. I agree that we should do what makes the most sense for implementors. I am just not sure "option B" is that much more sensible compared to "option A", hence my preference for "option A". - Sathya > > > > Option A: > > > ========= > > > Combine > > > 1) Detecting Network Attachment in IPv6 Networks (DNAv6) > > > and > > > 2) Tentative Options for Link-Layer Addresses in IPv6 > Neighbour Discovery > > > (draft-ietf-dna-protocol-00 + draft-ietf-dna-tentative-00) > > > > > > into one document. > > > > > > Merge > > > 3) Detecting Network Attachment in IPv6 - Best Current > Practices for > > > hosts > > > and > > > 4) DNA with unmodified routers: Prefix list based approach > > > (draft-ietf-dna-hosts-03 + draft-ietf-dna-cpl-02) > > IMO, there should be one single document that tells implementors what > to implement. I don't think it is helpful to have 2 different > documents giving guidanace on this point. > > > > Option B: > > > ========= > > > > > > Merge all the above mentioned documents > > > > > > * draft-ietf-dna-protocol-00 > > > * draft-ietf-dna-tentative-00 > > > * draft-ietf-dna-hosts-03 > > > * draft-ietf-dna-cpl-02 > > > > > > into a single document. > > That would be my preference. > > Thomasu > From dna-owner@webcamserver.eng.monash.edu.au Sun Jun 25 04:47:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuQHT-00006b-J7 for dna-archive@lists.ietf.org; Sun, 25 Jun 2006 04:47:47 -0400 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuQHR-0007kV-A3 for dna-archive@lists.ietf.org; Sun, 25 Jun 2006 04:47:47 -0400 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M41W1ZAG7E8XEOU1@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sun, 25 Jun 2006 18:47:37 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3A307AB548; Sun, 25 Jun 2006 18:47:07 +1000 (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 DABFB4FB0E; Sun, 25 Jun 2006 18:47:06 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k5P8h9311478 for dna-list; Sun, 25 Jun 2006 18:43:09 +1000 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 k5P8h6u11474 for ; Sun, 25 Jun 2006 18:43:06 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M41VVYLWUY8YJ3TG@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sun, 25 Jun 2006 18:43:03 +1000 Received: by localhost (Postfix, from userid 510) id 2CB9880004; Sun, 25 Jun 2006 18:43:03 +1000 (EST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id 5878F3C00A for ; Sun, 25 Jun 2006 18:43:02 +1000 (EST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k5P8gvkI016851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 25 Jun 2006 04:42:58 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k5P8gved181150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 25 Jun 2006 04:42:57 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k5P8gvpo014162 for ; Sun, 25 Jun 2006 04:42:57 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-48-38-23.mts.ibm.com [9.48.38.23]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k5P8guwl014145; Sun, 25 Jun 2006 04:42:56 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.6/8.12.5) with ESMTP id k5P8gntN023753; Sun, 25 Jun 2006 08:42:50 +0000 (GMT) Date: Sun, 25 Jun 2006 08:42:49 +0000 From: Thomas Narten Subject: Re: [DNA] CONSENSUS CALL : Document merges In-reply-to: <10cced7e5.d7e510cce@pintlmail.MITL.Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: Sathya Narayanan Cc: suresh.krishnan@ericsson.ca, Dna , "Suresh Krishnan (QB/EMC)" , Greg Daley , Jari Arkko Message-id: <200606250842.k5P8gntN023753@cichlid.raleigh.ibm.com> MIME-version: 1.0 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: References: <10cced7e5.d7e510cce@pintlmail.MITL.Research.Panasonic.COM> Comments: In-reply-to Sathya Narayanan message dated "Sat, 24 Jun 2006 07:57:07 -0400." X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 > Yes - it means "less work for the current authors ang the > group". OK > But, my intention is not to reduce work alone, I am just concerned > that more work may lead to the work not getting done in a timely > manner. Personally, I'm already concerned about the progress this WG is making. IMO, not a lot has happened in the last 6+ months or so. In terms of what needs to be done (technology wise), I think that is pretty well understood. But we have too many documents, they overlap in confusing/contradictory ways, but we aren't actually seeing much progress in getting those documents cleaned up. IMO, anyway. As one crude example, how many times have the various IDs been revved in the last 2-3 IETF cycles? if the answer is one revision per IETF cycle, that's not fast enough and indicates slow progress. I would encourage the chairs to take stock of the situation and put together a plan covering the next 3-6 months (with concrete milestones and commitments from document editors) that show us getting done and shipping documents to the IESG. Thomas From dna-owner@webcamserver.eng.monash.edu.au Sun Jun 25 08:57:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuUBI-0007zI-Ak for dna-archive@lists.ietf.org; Sun, 25 Jun 2006 08:57:40 -0400 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuUBG-00023e-R3 for dna-archive@lists.ietf.org; Sun, 25 Jun 2006 08:57:40 -0400 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M424S6QM228XCZBY@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sun, 25 Jun 2006 22:57:33 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 16FB180004; Sun, 25 Jun 2006 22:57:19 +1000 (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 CE4903C003; Sun, 25 Jun 2006 22:57:18 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k5PCuLe13865 for dna-list; Sun, 25 Jun 2006 22:56:21 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k5PCuKu13861 for ; Sun, 25 Jun 2006 22:56:20 +1000 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 <01M424QPJ1QK8WX0OF@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sun, 25 Jun 2006 22:56:07 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A0CE2AB546; Sun, 25 Jun 2006 22:56:07 +1000 (EST) Received: from [192.168.1.100] (cust1648.vic01.dataco.com.au [202.63.56.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: brett) by curly.its.monash.edu.au (Postfix) with ESMTP id 4F8044FB07; Sun, 25 Jun 2006 22:56:07 +1000 (EST) Date: Sun, 25 Jun 2006 22:56:04 +1000 From: Brett Pentland Subject: [DNA] Update to draft-ietf-dna-protocol Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna Message-id: <449E87E4.2010403@eng.monash.edu.au> 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 1.0.7 (Windows/20050923) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi all, While we are deciding how drafts should be brought together, I have posted an update to draft-ietf-dna-protocol. While waiting for it to show up in the archive, it can be found at: http://www.ctie.monash.edu.au/dna-dt/draft-ietf-dna-protocol-01.txt A diff from -00 can be seen at: http://www.ctie.monash.edu.au/dna-dt/draft-ietf-dna-protocol-01-from-0.diff.html The changes reflect the discussion that Sathya initiated on the wording of the section on routers' processing of RSes, and also James' text on Router Reachability Detection and Default Router Selection. Regards, Brett. From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 26 08:31:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuqFx-0002RS-5s for dna-archive@lists.ietf.org; Mon, 26 Jun 2006 08:31:57 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuqFv-0003CJ-5x for dna-archive@lists.ietf.org; Mon, 26 Jun 2006 08:31:57 -0400 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 <01M43I5EEM1U8WWZU8@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 26 Jun 2006 22:30:38 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 10C6D80005; Mon, 26 Jun 2006 22:30:36 +1000 (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 9A3EB3C00A; Mon, 26 Jun 2006 22:30:35 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k5QCSGZ27638 for dna-list; Mon, 26 Jun 2006 22:28:16 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k5QCSEu27634 for ; Mon, 26 Jun 2006 22:28:14 +1000 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 <01M43I26QM9O8Y929T@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 26 Jun 2006 22:28:05 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B653A80003; Mon, 26 Jun 2006 22:28:00 +1000 (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 9C0343C00F; Mon, 26 Jun 2006 22:28:00 +1000 (EST) Received: from [68.36.162.17] by mail-store-2.its.monash.edu.au (mshttpd); Mon, 26 Jun 2006 08:27:59 -0400 Date: Mon, 26 Jun 2006 08:27:59 -0400 From: Greg Daley Subject: Re: [DNA] CONSENSUS CALL : Document merges In-reply-to: <200606250842.k5P8gntN023753@cichlid.raleigh.ibm.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Thomas Narten Cc: Sathya Narayanan , suresh.krishnan@ericsson.ca, Dna , "Suresh Krishnan (QB/EMC)" , Greg Daley , Jari Arkko 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: <10cced7e5.d7e510cce@pintlmail.MITL.Research.Panasonic.COM> <200606250842.k5P8gntN023753@cichlid.raleigh.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Hi Thomas, The problem you highlighted with regard to the document proliferation has been one of the contributory factors which has slowed advancement. The progress had slowed before that though, as you pointed out. I think everyone is at the stage where they would just like to see the documents come out. Suresh and I have talked to Jari about realistic milestones, and will release them as soon as we know what the result of the consensus call is. The new milestones will require an increase in work rate, but not in advance of anything reasonable for a group of this size. Essentially though, the WG and chairs have to put in more effort if we actually want to see the documents come out. Thanks for your input on this. Greg ----- Original Message ----- From: Thomas Narten Date: Sunday, June 25, 2006 4:47 am Subject: Re: [DNA] CONSENSUS CALL : Document merges To: Sathya Narayanan Cc: suresh.krishnan@ericsson.ca, Dna , "Suresh Krishnan (QB/EMC)" , Greg Daley , Jari Arkko > > Yes - it means "less work for the current authors ang the > > group". > > OK > > > But, my intention is not to reduce work alone, I am just concerned > > that more work may lead to the work not getting done in a timely > > manner. > > Personally, I'm already concerned about the progress this WG is > making. IMO, not a lot has happened in the last 6+ months or so. In > terms of what needs to be done (technology wise), I think that is > pretty well understood. But we have too many documents, they overlap > in confusing/contradictory ways, but we aren't actually seeing much > progress in getting those documents cleaned up. IMO, anyway. As one > crude example, how many times have the various IDs been revved in the > last 2-3 IETF cycles? if the answer is one revision per IETF cycle, > that's not fast enough and indicates slow progress. > > I would encourage the chairs to take stock of the situation and put > together a plan covering the next 3-6 months (with concrete milestones > and commitments from document editors) that show us getting done and > shipping documents to the IESG. > > Thomas > From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 26 09:54:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FurYG-0003DC-Br for dna-archive@lists.ietf.org; Mon, 26 Jun 2006 09:54:56 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FurYD-0001Fd-G6 for dna-archive@lists.ietf.org; Mon, 26 Jun 2006 09:54:56 -0400 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 <01M43L23CJQ08WX0H2@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 26 Jun 2006 23:54:18 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E7CFB80004; Mon, 26 Jun 2006 23:54:15 +1000 (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 9DAEC3C00A; Mon, 26 Jun 2006 23:54:15 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k5QDrN228510 for dna-list; Mon, 26 Jun 2006 23:53:24 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k5QDrNu28506 for ; Mon, 26 Jun 2006 23:53:23 +1000 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 <01M43L0QSM4E8Y9AQZ@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 26 Jun 2006 23:53:08 +1000 Received: by localhost (Postfix, from userid 510) id 65FDEAB542; Mon, 26 Jun 2006 23:53:08 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by moe.its.monash.edu.au (Postfix) with ESMTP id B8CF64FB07 for ; Mon, 26 Jun 2006 23:53:06 +1000 (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 k5QDr7v2010656; Mon, 26 Jun 2006 09:53:07 -0400 Received: from [150.169.1.225] ([150.169.1.225]) by redwood.research.panasonic.com (MOS 3.7.4b-GA) with ESMTP id AGL96478; Mon, 26 Jun 2006 09:51:04 -0400 (EDT) Date: Mon, 26 Jun 2006 09:53:18 -0400 From: Greg Daley Subject: [DNA] REMINDER: document merger consensus call runs until end of Thursday Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna , "Suresh Krishnan (QB/EMC)" Message-id: <449FE6CE.2020100@research.panasonic.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Dear WG, If you have not identified which of the proposals for document mergers you prefer, please comment on-list. The consensus call will run until end of Thursday 29 AOE. The thread is available at: http://webcamserver.eng.monash.edu.au/~warchive/dna/2006-06/msg00007.html Greg From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 26 11:45:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FutHD-0004Ri-GI for dna-archive@lists.ietf.org; Mon, 26 Jun 2006 11:45:27 -0400 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FutHB-0002ya-Pp for dna-archive@lists.ietf.org; Mon, 26 Jun 2006 11:45:27 -0400 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M43OVERFRY8YJVQ4@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 27 Jun 2006 01:43:32 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 33378AB549; Tue, 27 Jun 2006 01:43:22 +1000 (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 CE6E84FB11; Tue, 27 Jun 2006 01:43:21 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k5QFgR129629 for dna-list; Tue, 27 Jun 2006 01:42:27 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k5QFgPu29625 for ; Tue, 27 Jun 2006 01:42:25 +1000 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 <01M43OTWGQZO8Y91FY@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 27 Jun 2006 01:42:10 +1000 Received: by localhost (Postfix, from userid 510) id 9F87E80002; Tue, 27 Jun 2006 01:42:10 +1000 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by larry.its.monash.edu.au (Postfix) with ESMTP id 58B4A3C006; Tue, 27 Jun 2006 01:42:09 +1000 (EST) Date: Mon, 26 Jun 2006 08:43:14 -0700 From: James Kempf Subject: Re: [DNA] CONSENSUS CALL : Document merges Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard Aboba , brett.pentland@eng.monash.edu.au, suresh.krishnan@ericsson.ca Cc: dna@eng.monash.edu.au, suresh.krishnan@ericsson.com, gregd@research.panasonic.com, jari.arkko@piuha.net Message-id: <04f601c69937$3cc0d800$026115ac@dcml.docomolabsusa.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: * References: X-Spam-Score: 3.1 (+++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 I agree as well. jak ----- Original Message ----- From: "Bernard Aboba" To: ; Cc: ; ; ; Sent: Friday, June 23, 2006 7:33 PM Subject: Re: [DNA] CONSENSUS CALL : Document merges >I also agree that option B is preferrable. > >>Though it's more work, I think option B will make it easier for developers >>to find what they need. >> >>Brett. > > > From dna-owner@webcamserver.eng.monash.edu.au Mon Jun 26 12:56:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuuON-00074Y-H5 for dna-archive@lists.ietf.org; Mon, 26 Jun 2006 12:56:55 -0400 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuuOL-0001Zr-PT for dna-archive@lists.ietf.org; Mon, 26 Jun 2006 12:56:55 -0400 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M43RFB08Z28XFL8N@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 27 Jun 2006 02:56:49 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A132980003; Tue, 27 Jun 2006 02:56:40 +1000 (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 59ECB3C007; Tue, 27 Jun 2006 02:56:40 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k5QGtor30386 for dna-list; Tue, 27 Jun 2006 02:55:50 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k5QGtmu30382 for ; Tue, 27 Jun 2006 02:55:48 +1000 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 <01M43RDW7P9U8Y912X@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 27 Jun 2006 02:55:33 +1000 Received: by localhost (Postfix, from userid 510) id 9BB1580002; Tue, 27 Jun 2006 02:55:33 +1000 (EST) Received: from mgw-ext13.nokia.com (mgw-ext13.nokia.com [131.228.20.172]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id 77F043C003 for ; Tue, 27 Jun 2006 02:55:32 +1000 (EST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5QGtNfG030612; Mon, 26 Jun 2006 19:55:26 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 19:55:14 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 11:55:11 -0500 Date: Mon, 26 Jun 2006 09:55:09 -0700 From: Mohan.Parthasarathy@nokia.com Subject: RE: [DNA] CONSENSUS CALL : Document merges In-reply-to: <449C3B1B.6050605@Research.Panasonic.COM> Sender: owner-dna@ecselists.eng.monash.edu.au To: sathya@research.panasonic.com, suresh.krishnan@ericsson.ca Cc: dna@eng.monash.edu.au, suresh.krishnan@ericsson.com, gregd@research.panasonic.com, jari.arkko@piuha.net Message-id: <8A76136424391244A5CF01653370853701C33CDD@mvebe101.NOE.Nokia.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [DNA] CONSENSUS CALL : Document merges Thread-Index: AcaW+JLxjyQ+jwh/TAiF+r0dEq9LpgCSG2gg Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: * X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 26 Jun 2006 16:55:11.0879 (UTC) FILETIME=[49EC6170:01C69941] X-Spam-Score: 0.2 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Greg already asked this question once before and i said my preference is option A. -mohan >-----Original Message----- >From: owner-dna@ecselists.eng.monash.edu.au >[mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of >ext Sathya Narayanan >Sent: Friday, June 23, 2006 12:04 PM >To: suresh.krishnan@ericsson.ca >Cc: Dna; Suresh Krishnan (QB/EMC); Greg Daley; Jari Arkko >Subject: Re: [DNA] CONSENSUS CALL : Document merges > >I prefer option A. > >As I mentioned earlier, I think option A is the more practical option. > >thanks, >Sathya > >Suresh Krishnan wrote: > >> Hi Folks, >> At the last meeting in Dallas lot of concerns were raised >about the >> number of documents being produced by the WG. The Consensus was to >> reduce the number of documents to keep related information together. >> The chairs have identified two possible merger scenarios >and would >> like to know the opinion of the working group regarding these two. >> >> >> Option A: >> ========= >> Combine >> 1) Detecting Network Attachment in IPv6 Networks (DNAv6) and >> 2) Tentative Options for Link-Layer Addresses in IPv6 Neighbour >> Discovery (draft-ietf-dna-protocol-00 + draft-ietf-dna-tentative-00) >> >> into one document. >> >> Merge >> 3) Detecting Network Attachment in IPv6 - Best Current Practices for >> hosts and >> 4) DNA with unmodified routers: Prefix list based approach >> (draft-ietf-dna-hosts-03 + draft-ietf-dna-cpl-02) >> >> into another document. >> >> Option B: >> ========= >> >> Merge all the above mentioned documents >> >> * draft-ietf-dna-protocol-00 >> * draft-ietf-dna-tentative-00 >> * draft-ietf-dna-hosts-03 >> * draft-ietf-dna-cpl-02 >> >> into a single document. >> >> This consensus call will last for two weeks and will end on the 29th >> of June 2006. Please respond to the list whether you >> >> * Prefer Option A >> * Prefer Option B >> >> If you do not have a preference and you are ok with either option, >> please respond with "Don't care ". If we have consensus on the Don't >> cares the chairs will make the decision. >> >> Thanks >> Suresh and Greg > > > From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 27 06:06:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvASr-00078e-0y for dna-archive@lists.ietf.org; Tue, 27 Jun 2006 06:06:37 -0400 Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvASo-0004CM-0v for dna-archive@lists.ietf.org; Tue, 27 Jun 2006 06:06:37 -0400 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M44RA3NBVY8XFT0C@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 27 Jun 2006 20:03:38 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6D522AB542; Tue, 27 Jun 2006 20:03:21 +1000 (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 2E3074FB07; Tue, 27 Jun 2006 20:03:21 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k5RA29L08130 for dna-list; Tue, 27 Jun 2006 20:02:09 +1000 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 k5RA28u08126 for ; Tue, 27 Jun 2006 20:02:08 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M44R89FSBW8YJJUX@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 27 Jun 2006 20:01:52 +1000 Received: by localhost (Postfix, from userid 510) id A589F80002; Tue, 27 Jun 2006 20:01:52 +1000 (EST) Received: from galaxy.systems.pipex.net (galaxy.systems.pipex.net [62.241.162.31]) by larry.its.monash.edu.au (Postfix) with ESMTP id 88E6D3C007 for ; Tue, 27 Jun 2006 20:01:51 +1000 (EST) Received: from pc6 (1Cust105.tnt106.lnd4.gbr.da.uu.net [213.116.60.105]) by galaxy.systems.pipex.net (Postfix) with SMTP id D3498E000502; Tue, 27 Jun 2006 11:01:39 +0100 (BST) Date: Tue, 27 Jun 2006 10:03:56 +0200 From: Tom Petch Subject: Re: [DNA] REMINDER: document merger consensus call runs until end of Thursday Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley , Dna , "Suresh Krishnan (QB/EMC)" Reply-to: Tom Petch Message-id: <061401c699c7$c084ad20$0601a8c0@pc6> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: References: <449FE6CE.2020100@research.panasonic.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Option B. I am persuaded that this will be simpler for the long-term users, if not for the short-term producers of it.. Tom Petch ----- Original Message ----- From: "Greg Daley" To: "Dna" ; "Suresh Krishnan (QB/EMC)" Sent: Monday, June 26, 2006 3:53 PM Subject: [DNA] REMINDER: document merger consensus call runs until end of Thursday > Dear WG, > > If you have not identified which of the proposals > for document mergers you prefer, please comment on-list. > > The consensus call will run until end of Thursday 29 AOE. > > The thread is available at: > > http://webcamserver.eng.monash.edu.au/~warchive/dna/2006-06/msg00007.html > > Greg From dna-owner@webcamserver.eng.monash.edu.au Tue Jun 27 16:48:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJdj-0004zs-1S for dna-archive@lists.ietf.org; Tue, 27 Jun 2006 15:54:27 -0400 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvJdf-0002KJ-HF for dna-archive@lists.ietf.org; Tue, 27 Jun 2006 15:54:26 -0400 Received: from curly.its.monash.edu.au ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M45BWRLD3A8YJGMY@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 28 Jun 2006 05:54:20 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A8600AB544; Wed, 28 Jun 2006 05:54:12 +1000 (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 4BD334FB06; Wed, 28 Jun 2006 05:54:12 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k5RJoFP14087 for dna-list; Wed, 28 Jun 2006 05:50:15 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k5RJoFu14083 for ; Wed, 28 Jun 2006 05:50:15 +1000 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 <01M45BRQQHGQ8WX1TH@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 28 Jun 2006 05:50:13 +1000 Received: by localhost (Postfix, from userid 510) id E8C2180002; Wed, 28 Jun 2006 05:50:12 +1000 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id 173223C00C for ; Wed, 28 Jun 2006 05:50:10 +1000 (EST) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5RJo2UA002944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jun 2006 19:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvJZS-0005HQ-CK; Tue, 27 Jun 2006 15:50:02 -0400 Date: Tue, 27 Jun 2006 15:50:02 -0400 From: Internet-Drafts@ietf.org Subject: [DNA] I-D ACTION:draft-ietf-dna-protocol-01.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: i-d-announce@ietf.org Cc: dna@eng.monash.edu.au Message-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_8zFjhavem7Cig3Ybm+ULAA)" X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Spam-Score: 0.2 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --Boundary_(ID_8zFjhavem7Cig3Ybm+ULAA) Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Detecting Network Attachment Working Group of the IETF. Title : Detecting Network Attachment in IPv6 Networks (DNAv6) Author(s) : J. Kempf, et al. Filename : draft-ietf-dna-protocol-01.txt Pages : 35 Date : 2006-6-27 Efficient detection of network attachment in IPv6 needs the following two components: a method for the host to query routers on the link to identify the link (Link Identification) and a method for the routers on the link to consistently respond to such a query with minimal delay (Fast RA). Solving the link identification based strictly on RFC 2461 is difficult because of the flexibility offered to routers in terms of prefixes advertised in a router advertisement (RA) message. Similarly, the random delay in responding to router solicitation messages imposed by RFC 2461 makes to it difficult to receive an RA quickly. In this memo, an integrated solution is presented. Monitoring of prefixes by both hosts and routers is used to achieve link identification while router advertisements are sent rapidly in a deterministic order by combining router solicitation source addresses with hash-based router tokens. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dna-protocol-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dna-protocol-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dna-protocol-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_8zFjhavem7Cig3Ybm+ULAA) Content-type: multipart/alternative; boundary="Boundary_(ID_jiIODo8bge/g93ukrF4zQg)" --Boundary_(ID_jiIODo8bge/g93ukrF4zQg) Content-type: Message/External-body; access-type=mail-server; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-27125643.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dna-protocol-01.txt --Boundary_(ID_jiIODo8bge/g93ukrF4zQg) Content-type: Message/External-body; name=draft-ietf-dna-protocol-01.txt; site=ftp.ietf.org; access-type=anon-ftp; directory=internet-drafts Content-disposition: attachment; filename=draft-ietf-dna-protocol-01.txt Content-Type: text/plain Content-ID: <2006-6-27125643.I-D@ietf.org> --Boundary_(ID_jiIODo8bge/g93ukrF4zQg)-- --Boundary_(ID_8zFjhavem7Cig3Ybm+ULAA)-- From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 29 08:56:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvw49-0004Mb-HK for dna-archive@lists.ietf.org; Thu, 29 Jun 2006 08:56:17 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvw46-0002qw-J1 for dna-archive@lists.ietf.org; Thu, 29 Jun 2006 08:56:17 -0400 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 <01M47PVLIQ7E8WX0ML@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 29 Jun 2006 22:55:55 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B73B380003; Thu, 29 Jun 2006 22:55:50 +1000 (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 7CD9A3C00B; Thu, 29 Jun 2006 22:55:50 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k5TCrrn05605 for dna-list; Thu, 29 Jun 2006 22:53:53 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k5TCrqu05601 for ; Thu, 29 Jun 2006 22:53:52 +1000 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 <01M47PTB2EZ28WX0ML@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 29 Jun 2006 22:53:52 +1000 Received: by localhost (Postfix, from userid 510) id 3277AAB547; Thu, 29 Jun 2006 22:53:52 +1000 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by moe.its.monash.edu.au (Postfix) with ESMTP id 124FA4FB07 for ; Thu, 29 Jun 2006 22:53:51 +1000 (EST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5CE41898BC for ; Thu, 29 Jun 2006 15:53:48 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 18E0E898B6 for ; Thu, 29 Jun 2006 15:53:48 +0300 (EEST) Date: Thu, 29 Jun 2006 15:53:45 +0300 From: Jari Arkko Subject: Re: [DNA] CONSENSUS CALL : Document merges In-reply-to: <04f601c69937$3cc0d800$026115ac@dcml.docomolabsusa.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au Message-id: <44A3CD59.60701@kolumbus.fi> 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.8 (X11/20060502) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Virus-Scanned: ClamAV using ClamSMTP References: <04f601c69937$3cc0d800$026115ac@dcml.docomolabsusa.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 My personal preference is option B. (Just registering one opinion; as an AD I'd be fine with other ways to merge the documents too as long as the group agreed on one. Some merging is indeed needed, however.) --Jari From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 29 09:44:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvwpC-0007QN-TM for dna-archive@lists.ietf.org; Thu, 29 Jun 2006 09:44:54 -0400 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvwpA-00076M-V2 for dna-archive@lists.ietf.org; Thu, 29 Jun 2006 09:44:54 -0400 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 <01M47RKPDC388Y9G6O@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 29 Jun 2006 23:44:16 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CF4C3AB546; Thu, 29 Jun 2006 23:44:11 +1000 (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 889494FB0A; Thu, 29 Jun 2006 23:44:11 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k5TDhrW06127 for dna-list; Thu, 29 Jun 2006 23:43:53 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k5TDhru06123 for ; Thu, 29 Jun 2006 23:43:53 +1000 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 <01M47RK4XX1Q8WX40E@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 29 Jun 2006 23:43:45 +1000 Received: by localhost (Postfix, from userid 510) id EF688AB545; Thu, 29 Jun 2006 23:43:44 +1000 (EST) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by moe.its.monash.edu.au (Postfix) with ESMTP id CC24D4FB0C for ; Thu, 29 Jun 2006 23:43:43 +1000 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k5TDhctc009265; Thu, 29 Jun 2006 15:43:38 +0200 Received: from l1.rennes.enst-bretagne.fr (l1.rennes.enst-bretagne.fr [192.44.77.3]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k5TDhXBQ009261; Thu, 29 Jun 2006 15:43:33 +0200 Received: from nik.rennes.enst-bretagne.fr (nik [192.44.77.137]) (authenticated bits=0) by l1.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k5TDhW0T003385 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 29 Jun 2006 15:43:33 +0200 Date: Thu, 29 Jun 2006 15:40:07 +0200 From: Nicolas Montavont Subject: Re: [DNA] CONSENSUS CALL : Document merges In-reply-to: <4491E0DA.4000104@ericsson.ca> Sender: owner-dna@ecselists.eng.monash.edu.au To: suresh.krishnan@ericsson.ca Cc: Dna Message-id: <1151588407.3012.53.camel@localhost.localdomain> MIME-version: 1.0 X-Mailer: Evolution 2.4.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Virus-Scanned: amavisd-new at enst-bretagne.fr References: <4491E0DA.4000104@ericsson.ca> X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Hi, I prefer option B, I think it is easier for implementers and readers. Nicolas On Thu, 2006-06-15 at 18:36 -0400, Suresh Krishnan wrote: > Hi Folks, > At the last meeting in Dallas lot of concerns were raised about the > number of documents being produced by the WG. The Consensus was to > reduce the number of documents to keep related information together. > The chairs have identified two possible merger scenarios and would > like to know the opinion of the working group regarding these two. > > > Option A: > ========= > Combine > 1) Detecting Network Attachment in IPv6 Networks (DNAv6) > and > 2) Tentative Options for Link-Layer Addresses in IPv6 Neighbour Discovery > (draft-ietf-dna-protocol-00 + draft-ietf-dna-tentative-00) > > into one document. > > Merge > 3) Detecting Network Attachment in IPv6 - Best Current Practices for hosts > and > 4) DNA with unmodified routers: Prefix list based approach > (draft-ietf-dna-hosts-03 + draft-ietf-dna-cpl-02) > > into another document. > > Option B: > ========= > > Merge all the above mentioned documents > > * draft-ietf-dna-protocol-00 > * draft-ietf-dna-tentative-00 > * draft-ietf-dna-hosts-03 > * draft-ietf-dna-cpl-02 > > into a single document. > > This consensus call will last for two weeks and will end on the 29th of > June 2006. Please respond to the list whether you > > * Prefer Option A > * Prefer Option B > > If you do not have a preference and you are ok with either option, > please respond with "Don't care ". If we have consensus on the Don't > cares the chairs will make the decision. > > Thanks > Suresh and Greg From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 29 12:34:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvzTc-0003Rx-8i for dna-archive@lists.ietf.org; Thu, 29 Jun 2006 12:34:48 -0400 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvzTa-000634-GH for dna-archive@lists.ietf.org; Thu, 29 Jun 2006 12:34:48 -0400 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 <01M47XIXGV228WX5CY@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 30 Jun 2006 02:34:36 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EC8B9AB546; Fri, 30 Jun 2006 02:34:33 +1000 (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 A169A4FB03; Fri, 30 Jun 2006 02:34:33 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k5TGXjt07918 for dna-list; Fri, 30 Jun 2006 02:33:45 +1000 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 k5TGXiu07914 for ; Fri, 30 Jun 2006 02:33:44 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M47XHGNIFO8XEAM8@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 30 Jun 2006 02:33:29 +1000 Received: by localhost (Postfix, from userid 510) id F13B780003; Fri, 30 Jun 2006 02:33:28 +1000 (EST) Received: from mgw-ext11.nokia.com (mgw-ext11.nokia.com [131.228.20.170]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id CD4713C005 for ; Fri, 30 Jun 2006 02:33:27 +1000 (EST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5TGXLMq010751; Thu, 29 Jun 2006 19:33:23 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 19:33:18 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 11:33:14 -0500 Date: Thu, 29 Jun 2006 09:33:13 -0700 From: Mohan.Parthasarathy@nokia.com Subject: Option A Vs Option B (RE: [DNA] CONSENSUS CALL : Document merges) In-reply-to: <4491E0DA.4000104@ericsson.ca> Sender: owner-dna@ecselists.eng.monash.edu.au To: suresh.krishnan@ericsson.ca, dna@eng.monash.edu.au Cc: suresh.krishnan@ericsson.com, gregd@research.panasonic.com, jari.arkko@piuha.net Message-id: <8A76136424391244A5CF01653370853701CA227B@mvebe101.NOE.Nokia.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: Option A Vs Option B (RE: [DNA] CONSENSUS CALL : Document merges) Thread-Index: AcaQzO5fNzmEn3vfRUKiuhmbUssGKgKy68Uw Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: * X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 29 Jun 2006 16:33:14.0862 (UTC) FILETIME=[B828C8E0:01C69B99] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac I read these drafts quite sometime back, so can't answer this question myself. If i have to implement the DNA protocol (draft-ietf-dna-protocol), should i need to read the "contents" of all the other three drafts ? Assume the reader is familiar with RFC 2461 which is the basic one without which none of this would make sense. It is still not clear to me how merging will speed up the process ? It will sure slow down the review process because folks are normally good at reviewing smaller documents. -mohan >-----Original Message----- >From: owner-dna@ecselists.eng.monash.edu.au >[mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of >ext Suresh Krishnan >Sent: Thursday, June 15, 2006 3:36 PM >To: Dna >Cc: Suresh Krishnan (QB/EMC); Greg Daley; Jari Arkko >Subject: [DNA] CONSENSUS CALL : Document merges >Importance: High > >Hi Folks, > At the last meeting in Dallas lot of concerns were raised >about the number of documents being produced by the WG. The >Consensus was to reduce the number of documents to keep >related information together. > The chairs have identified two possible merger scenarios >and would like to know the opinion of the working group >regarding these two. > > >Option A: >========= >Combine >1) Detecting Network Attachment in IPv6 Networks (DNAv6) and >2) Tentative Options for Link-Layer Addresses in IPv6 >Neighbour Discovery (draft-ietf-dna-protocol-00 + >draft-ietf-dna-tentative-00) > >into one document. > >Merge >3) Detecting Network Attachment in IPv6 - Best Current >Practices for hosts and >4) DNA with unmodified routers: Prefix list based approach >(draft-ietf-dna-hosts-03 + draft-ietf-dna-cpl-02) > >into another document. > >Option B: >========= > >Merge all the above mentioned documents > >* draft-ietf-dna-protocol-00 >* draft-ietf-dna-tentative-00 >* draft-ietf-dna-hosts-03 >* draft-ietf-dna-cpl-02 > >into a single document. > >This consensus call will last for two weeks and will end on >the 29th of June 2006. Please respond to the list whether you > >* Prefer Option A >* Prefer Option B > >If you do not have a preference and you are ok with either >option, please respond with "Don't care ". If we have >consensus on the Don't cares the chairs will make the decision. > >Thanks >Suresh and Greg > From dna-owner@webcamserver.eng.monash.edu.au Thu Jun 29 14:06:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw0u9-0008LG-L4 for dna-archive@lists.ietf.org; Thu, 29 Jun 2006 14:06:17 -0400 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw0u5-0006U9-QB for dna-archive@lists.ietf.org; Thu, 29 Jun 2006 14:06:17 -0400 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M480PD9CZE8YK0V4@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 30 Jun 2006 04:05:25 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E4DD480006; Fri, 30 Jun 2006 04:05:15 +1000 (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 9253D3C005; Fri, 30 Jun 2006 04:05:15 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k5TI4FP09033 for dna-list; Fri, 30 Jun 2006 04:04:15 +1000 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 k5TI4Bu09029 for ; Fri, 30 Jun 2006 04:04:11 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M480M5SYL48YINGL@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Fri, 30 Jun 2006 04:02:45 +1000 Received: by localhost (Postfix, from userid 510) id A2BB980003; Fri, 30 Jun 2006 04:02:45 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by larry.its.monash.edu.au (Postfix) with ESMTP id 455E33C007 for ; Fri, 30 Jun 2006 04:02:44 +1000 (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 k5TI2jAJ016167; Thu, 29 Jun 2006 14:02:45 -0400 Received: from [150.169.1.225] ([150.169.1.225]) by redwood.research.panasonic.com (MOS 3.7.4b-GA) with ESMTP id AGO06643; Thu, 29 Jun 2006 14:00:39 -0400 (EDT) Date: Thu, 29 Jun 2006 14:02:41 -0400 From: Greg Daley Subject: Re: Option A Vs Option B (RE: [DNA] CONSENSUS CALL : Document merges) In-reply-to: <8A76136424391244A5CF01653370853701CA227B@mvebe101.NOE.Nokia.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Mohan.Parthasarathy@nokia.com Cc: suresh.krishnan@ericsson.ca, dna@eng.monash.edu.au, suresh.krishnan@ericsson.com, jari.arkko@piuha.net Message-id: <44A415C1.90406@research.panasonic.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: References: <8A76136424391244A5CF01653370853701CA227B@mvebe101.NOE.Nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Hi Mohan, Just clarifying the current situation. I don't want to show any bias here, and it's at a fairly important time of the consensus call, so please consider these efforts as personal view only. The host side of draft-ietf-dna-protocol directly relies on CPL today, as required for backward compatibility with unmodified routers. Currently draft-ietf-dna-protocol also relies on draft-ietf-dna-tentative, for interactions with routers while a host is still optimistic. draft-ietf-dna-cpl and draft-ietf-dna-hosts are tackling different aspects of the same problem (host change detection procedures, for unmodified networks). It may be worth thinking about that Neighbour Discovery itself contains both the host and router side information in the same document. This may inform peoples' opinions of the benefits and drawbacks of such a scheme. On the timeliness: I agree that the document review will be longer. In our projected timelines, we have accounted for this, to some extent (for either decision). The point of choice in my guess is some expedition, with a useful merger into two documents, or merger into one document, which some people see as producing a better document at the cost of potential time and effort. I hope this helps, Greg Mohan.Parthasarathy@nokia.com wrote: > > I read these drafts quite sometime back, so can't answer > this question myself. > > If i have to implement the DNA protocol (draft-ietf-dna-protocol), > should i need to read the "contents" of all the other three drafts ? > Assume the reader is familiar with RFC 2461 which is the basic > one without which none of this would make sense. It is still not > clear to me how merging will speed up the process ? It will sure > slow down the review process because folks are normally good at > reviewing smaller documents. > > -mohan > >> -----Original Message----- >> From: owner-dna@ecselists.eng.monash.edu.au >> [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of >> ext Suresh Krishnan >> Sent: Thursday, June 15, 2006 3:36 PM >> To: Dna >> Cc: Suresh Krishnan (QB/EMC); Greg Daley; Jari Arkko >> Subject: [DNA] CONSENSUS CALL : Document merges >> Importance: High >> >> Hi Folks, >> At the last meeting in Dallas lot of concerns were raised >> about the number of documents being produced by the WG. The >> Consensus was to reduce the number of documents to keep >> related information together. >> The chairs have identified two possible merger scenarios >> and would like to know the opinion of the working group >> regarding these two. >> >> >> Option A: >> ========= >> Combine >> 1) Detecting Network Attachment in IPv6 Networks (DNAv6) and >> 2) Tentative Options for Link-Layer Addresses in IPv6 >> Neighbour Discovery (draft-ietf-dna-protocol-00 + >> draft-ietf-dna-tentative-00) >> >> into one document. >> >> Merge >> 3) Detecting Network Attachment in IPv6 - Best Current >> Practices for hosts and >> 4) DNA with unmodified routers: Prefix list based approach >> (draft-ietf-dna-hosts-03 + draft-ietf-dna-cpl-02) >> >> into another document. >> >> Option B: >> ========= >> >> Merge all the above mentioned documents >> >> * draft-ietf-dna-protocol-00 >> * draft-ietf-dna-tentative-00 >> * draft-ietf-dna-hosts-03 >> * draft-ietf-dna-cpl-02 >> >> into a single document. >> >> This consensus call will last for two weeks and will end on >> the 29th of June 2006. Please respond to the list whether you >> >> * Prefer Option A >> * Prefer Option B >> >> If you do not have a preference and you are ok with either >> option, please respond with "Don't care ". If we have >> consensus on the Don't cares the chairs will make the decision. >> >> Thanks >> Suresh and Greg >> From dna-owner@webcamserver.eng.monash.edu.au Fri Jun 30 17:42:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwQlI-0007jU-Jg for dna-archive@lists.ietf.org; Fri, 30 Jun 2006 17:42:52 -0400 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwQlG-0001v2-RN for dna-archive@lists.ietf.org; Fri, 30 Jun 2006 17:42:52 -0400 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 <01M49ML46CFG8WX84R@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 01 Jul 2006 07:42:37 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6B0BFAB544; Sat, 01 Jul 2006 07:42:33 +1000 (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 D069D4FB09; Sat, 01 Jul 2006 07:42:32 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k5ULeXw25331 for dna-list; Sat, 01 Jul 2006 07:40:33 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id k5ULeVu25327 for ; Sat, 01 Jul 2006 07:40:31 +1000 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 <01M49MI9QFJ88WX5KC@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 01 Jul 2006 07:40:16 +1000 Received: by localhost (Postfix, from userid 510) id ED6CBAB542; Sat, 01 Jul 2006 07:40:15 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by moe.its.monash.edu.au (Postfix) with ESMTP id C4A1F4FB09 for ; Sat, 01 Jul 2006 07:40:14 +1000 (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 k5ULeEJh030267; Fri, 30 Jun 2006 17:40:14 -0400 Received: from [150.169.1.225] ([150.169.1.225]) by redwood.research.panasonic.com (MOS 3.7.4b-GA) with ESMTP id AGO66807; Fri, 30 Jun 2006 17:38:08 -0400 (EDT) Date: Fri, 30 Jun 2006 17:40:11 -0400 From: Greg Daley Subject: [DNA] Document merger consensus call results Sender: owner-dna@ecselists.eng.monash.edu.au To: Dna , "Suresh Krishnan (QB/EMC)" , Greg Daley Cc: Jari Arkko Message-id: <44A59A3B.3060409@research.panasonic.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: X-Junkmail-Status: score=10/57, host=redwood.research.panasonic.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090201.44A59844.0033,ss=1,fgs=0, ip=150.169.1.225, so=2006-02-11 11:31:14, dmn=5.2.4/2006-05-04 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Dear WG, The results of the consensus call are that 8 people preferred Option B, which called for combining all four documents. Three people called for Option A. The chairs believe there is rough consensus for Option B. Thanks for your participation. Greg From dna-owner@webcamserver.eng.monash.edu.au Fri Jun 30 20:39:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwTWe-00012I-1R for dna-archive@lists.ietf.org; Fri, 30 Jun 2006 20:39:56 -0400 Received: from alpha1.its.monash.edu.au ([130.194.1.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwTWc-0006IW-7N for dna-archive@lists.ietf.org; Fri, 30 Jun 2006 20:39:56 -0400 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M49SRCXXOW8YKDK3@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 01 Jul 2006 10:39:51 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1659980003; Sat, 01 Jul 2006 10:39:23 +1000 (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 C66B63C006; Sat, 01 Jul 2006 10:39:22 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id k610cYV27091 for dna-list; Sat, 01 Jul 2006 10:38:34 +1000 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 k610cYu27087 for ; Sat, 01 Jul 2006 10:38:34 +1000 Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31276) with ESMTP id <01M49SQ6J9CE8YKDK3@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 01 Jul 2006 10:38:26 +1000 Received: by localhost (Postfix, from userid 510) id 7768080003; Sat, 01 Jul 2006 10:38:26 +1000 (EST) Received: from oak.research.panasonic.com (oak.Research.Panasonic.COM [150.169.1.4]) by larry.its.monash.edu.au (Postfix) with ESMTP id 4BFB43C007 for ; Sat, 01 Jul 2006 10:38:25 +1000 (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 k610cQkG003259; Fri, 30 Jun 2006 20:38:26 -0400 Received: from [150.169.1.225] ([150.169.1.225]) by redwood.research.panasonic.com (MOS 3.7.4b-GA) with ESMTP id AGO72502; Fri, 30 Jun 2006 20:36:19 -0400 (EDT) Date: Fri, 30 Jun 2006 20:38:22 -0400 From: Greg Daley Subject: Re: [DNA] Review of draft-ietf-dna-link-information-03.txt In-reply-to: <0MKoyl-1FqwGx1xjW-0002nr@mrelay.perfora.net> Sender: owner-dna@ecselists.eng.monash.edu.au To: Alper Yegin , 'Bernard Aboba' Cc: dna@eng.monash.edu.au, nicolas.montavont@enst-bretagne.fr Message-id: <44A5C3FE.8070301@research.panasonic.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) X-Spam-Level: References: <0MKoyl-1FqwGx1xjW-0002nr@mrelay.perfora.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Alper Yegin wrote: [cut] >> Section 2.4.2 >> >> " Ethernet networks commonly consist of LANs joined together by >> transparent bridges (usually implemented as switches). Transparent >> bridges require the active topology to be loop free. The Spanning >> Tree Protocol (STP) achieves this by the exchange of Bridge Protocol >> Data Unit (BPDU), as defined in [IEEE-802.1D], which leads to, where >> required, the blocking of ports (i.e., not forwarding)." >> >> I think you need to mention RSTP here as well. How about this? "Ethernet networks commonly consist of LANs joined together by transparent bridges (usually implemented as switches). Transparent bridges require the active topology to be loop free. The Spanning Tree Protocol (STP) and Rapid Spanning Tree Protocol (RSTP) achieve this by the exchange of Bridge Protocol Data Unit (BPDU), as defined in [IEEE-802.1D], which leads to, where required, the blocking of ports (i.e., not forwarding)." >> " Most hosts today do not listen to BPDU frames. For these hosts, >> connectivity to the a port which is potentially bridged (any Ethernet >> port) carries the potential of frame loss if transmissions occur >> before any bridges' ForwardDelay timers have expired twice." >> >> "to the a port" - "to the port" Thanks. >> " If no bridge configuration messages are received within the >> Bridge_Max_Age interval (default 20s), then it is likely that there >> is no visible bridge whose port is enabled for bridging (S8.4.5 of >> [IEEE-802.1D]), since at least two BPDU hello messages would have >> been lost. Upon this timeout, a link up notification MUST be >> generated. >> >> It is not easy for a non-STP host to distinguish between Disabled >> bridge ports and non-bridge ports with no IP nodes on them, as >> Disabled ports will have no traffic on them, and incur 100% sender >> loss. >> >> Upon this Bridge_Max_Age timeout, a link up notification must be >> generated. If an earlier link up was generated with the R-flag set, >> this new one MUST set the A-flag showing that packets sent within the >> prior interval were likely to have traversed the forwarding path >> (unless the port is disabled)." >> >> The next section talks about when to enable the delay, but I think you >> could be more clear about this here as well. For example, are you >> recommending that hosts listen for STP/RSTP messages, or use 802.1AB >> in order to decide on the appropriate delay? Delaying for 20 seconds >> by default probably isn't a good idea now that RSTP is becoming more >> common. I think the problem here can mostly be rectified by modifying prior paragraphs. (paragraph 7) Where it is not known that forwarding operations are available, a host needs to assume that STP is being performed, and may indicate full connectivity only based on timeouts or reception of BPDUs. X The host may send link up indications as soon as the link is viable X for packet transfer, although all such all indications sent until X forwarding confirmation MUST contain the R-flag set to indicate risk X of loss. And: (Paragraph 12) X Where possible, hosts SHOULD monitor for Bridge PDUs, in order to X determine what type of spanning tree may be running on the network. If a BPDU is received, and the adjacent bridge is running the original Spanning Tree Protocol, then a host cannot successfully send packets until at least twice the ForwardDelay value in the received BPDU has elapsed. After this time, a link up notification MUST be generated. If the previous link up notification had the R-flag set, then the B-flag) MUST be set in this notification. The B-flag signifies that the packets sent within the prior interval were lost. >> " Due to the protocol's newness and lack of deployment, it is unclear >> how this protocol will eventually affect DNA in IPv4 or IPv6 >> networks." >> >> DNAv4 does not utilize 802.1AB "hints", so this could be clarified. OK. I don't see why it can't use those hints, but we can modify the text to. Due to the protocol's newness and lack of deployment, it is unclear how this protocol will eventually affect DNA, particularly in IPv6 networks. >> Section 2.4.4 >> >> " Link-Layer indications in Ethernet-like networks are complicated by >> additional unadvertised delays due to Spanning Tree calculations. >> This may cause re-indication (link up with A-flag) or retraction >> (link up with B-flag) of indications previously sent to upper layer >> protocols." >> >> What are the A and B flags? Is this an artifact of a previous revision? >> The A and B flags are described in section 2, first paragraph of page 6. The A and B flags provide an ability to re-indicate after an event with an (R:Risk) flag set. These flags can identify to the upper-layer if the prior related event was associated with an incorrect link-up indication (B: Blocked) or successful indication (A: Allowed). These indications are sent when the uncertainty of the prior indication has passed. The B-Flag is necessary if the host wishes to take corrective action after reacting to the prior indication, for example, resetting Router Solicitation transmission counts or replaying data. The A flag in a second indication may be sent since the initial indication with an R-Flag may be ignored by cautious upper-layer protocols. Do you think it would be worthwhile to include it, or is the description in section 2 OK? Greg