From nobody Tue Jun 2 09:22:02 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1921ACD60; Tue, 2 Jun 2015 09:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2itEUoOtfH1Q; Tue, 2 Jun 2015 09:21:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A87A1ACE58; Tue, 2 Jun 2015 09:21:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150602162154.19539.37724.idtracker@ietfa.amsl.com> Date: Tue, 02 Jun 2015 09:21:54 -0700 Archived-At: Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-12.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 16:22:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Multicast Protocol for Low power and Lossy Networks (MPL) Authors : Jonathan W. Hui Richard Kelsey Filename : draft-ietf-roll-trickle-mcast-12.txt Pages : 26 Date : 2015-06-02 Abstract: This document specifies the Multicast Protocol for Low power and Lossy Networks (MPL) that provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating messages to all MPL Forwarders in a MPL Domain. MPL has two modes of operation. One mode uses the Trickle algorithm to manage control- and data-plane message transmissions, and is applicable for deployments with few multicast sources. The other mode uses classic flooding. By providing both modes and parameterization of the Trickle algorithm, a MPL implementation can be used in a variety of multicast deployments and can trade between dissemination latency and transmission efficiency. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-trickle-mcast-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 12 04:55:27 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974831A90C6; Fri, 12 Jun 2015 04:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8kbBAzEBA89; Fri, 12 Jun 2015 04:55:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6676F1A90E5; Fri, 12 Jun 2015 04:55:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150612115523.5468.25994.idtracker@ietfa.amsl.com> Date: Fri, 12 Jun 2015 04:55:23 -0700 Archived-At: Cc: roll-chairs@ietf.org, draft-ietf-roll-trickle-mcast@ietf.org, roll@ietf.org Subject: [Roll] Brian Haberman's No Objection on draft-ietf-roll-trickle-mcast-12: (with COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 11:55:24 -0000 Brian Haberman has entered the following ballot position for draft-ietf-roll-trickle-mcast-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the updated text on the multicast addresses in section 4.1. I will leave it up to you and your AD as to whether the text in section 5.1 needs to be updated in a similar fashion. From nobody Mon Jun 15 10:38:47 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74BBC1A0049; Mon, 15 Jun 2015 10:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFpvYMpMuzRw; Mon, 15 Jun 2015 10:38:42 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBA6F1A0047; Mon, 15 Jun 2015 10:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=518; q=dns/txt; s=iport; t=1434389921; x=1435599521; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bZLJ+XqWHE/SQtdewd48yflA7EDl1RSUAW0SPd3g0zs=; b=Kkuk170ZlwiX6upOl8zpqTPgwRC96l3HW5tOmGeJeLobSUNsHqoMbiXN AMt9PUgmvRFpC/Aw0PZaBtS5MfsdlYsC49Ex7if0MrXWgxBDGYilecQhf wPD0Ar7T1tHOoEdQJpCXHxJp2QaJdDnv23OeS1ErF9liSn3zDS4bJx++/ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BcBQChDH9V/4kNJK1cgxCBMwbFRgKBPDsRAQEBAQEBAYEKhCMBAQQ6PxACAQg2EDIlAgQBDQWIL8tTAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tEhQYHhC0BBIZ6ig2CVAGLQYEzkwKDWyZjgVmBPW+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,620,1427760000"; d="scan'208";a="3705065" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-4.cisco.com with ESMTP; 15 Jun 2015 17:38:41 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t5FHcf1o003073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Jun 2015 17:38:41 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.106]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Mon, 15 Jun 2015 12:38:40 -0500 From: "Alvaro Retana (aretana)" To: Brian Haberman , "draft-ietf-roll-trickle-mcast@ietf.org" Thread-Topic: Brian Haberman's No Objection on draft-ietf-roll-trickle-mcast-12: (with COMMENT) Thread-Index: AQHQpQatMnCB2ljWgEm+8p59p5K1HJ2t+7GA Date: Mon, 15 Jun 2015 17:38:40 +0000 Message-ID: References: <20150612115523.5468.25994.idtracker@ietfa.amsl.com> In-Reply-To: <20150612115523.5468.25994.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "roll-chairs@ietf.org" , "roll@ietf.org" , The IESG Subject: Re: [Roll] Brian Haberman's No Objection on draft-ietf-roll-trickle-mcast-12: (with COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 17:38:43 -0000 On 6/12/15, 7:55 AM, "Brian Haberman" wrote: >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >Thank you for the updated text on the multicast addresses in section 4.1. >I will leave it up to you and your AD as to whether the text in section >5.1 needs to be updated in a similar fashion. I just looked at 5.1 and I think the text there is fine. Thanks!! Alvaro. From nobody Mon Jun 15 17:31:48 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8EE1ACCF4; Mon, 15 Jun 2015 17:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_tqULH9dwUt; Mon, 15 Jun 2015 17:31:44 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94B9E1B37F0; Mon, 15 Jun 2015 17:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12710; q=dns/txt; s=iport; t=1434414704; x=1435624304; h=from:to:cc:subject:date:message-id:mime-version; bh=3lsoZem72j+G+HwtYGWjJGvXzZULNK3PYd4GIxhQt7g=; b=enA8jI5xhtLVWE8vWTHpCWxuRKb4/Hpo2W4rXK9evez9OgEkNKue98M4 QAhH5QHcXzuhztzVEHeKXqnx3V407jDKhZZJ/+RFS6c66Bab/+hzFSik1 atp9TYmGH02AGdP/ydIglPsBsvZwvaCBduxHdOhji0TQVT8CpryrQxu2L E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AiBADfbX9V/5JdJa1bgkVLgTm9awmHWYE8OBQBAQEBAQEBgQqEJQR5EgGBACcEDiSIEMwrAQEBAQEBBAEBAQEBARyPf0uENAWRB4JUAYtBgTOEBJJZJoN5gjWBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,622,1427760000"; d="scan'208,217";a="159755872" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-5.cisco.com with ESMTP; 16 Jun 2015 00:31:43 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t5G0Vhje001260 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jun 2015 00:31:43 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.106]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Mon, 15 Jun 2015 19:31:43 -0500 From: "Alvaro Retana (aretana)" To: "draft-ietf-roll-mpl-parameter-configuration@tools.ietf.org" Thread-Topic: AD Review of draft-ietf-roll-mpl-parameter-configuration Thread-Index: AQHQp8vRQMajtavr+EaCvSKBOhrHTg== Date: Tue, 16 Jun 2015 00:31:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.164] Content-Type: multipart/alternative; boundary="_000_D1A4F4BAB8391aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "roll-chairs@ietf.org" , "roll@ietf.org" , Ines Robles Subject: [Roll] AD Review of draft-ietf-roll-mpl-parameter-configuration X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 00:31:47 -0000 --_000_D1A4F4BAB8391aretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi! I just finished reading this document. I think the document is almost ready to move forward =97 I have one major c= omment (below) related to sending the Option as it relates to the potential= of mismatched options. I am going to start the IETF Last Call, but expect= at least a discussion about that comment before putting the draft in front= of the IESG. Thanks! Alvaro. Major: 1. Sending this Option. It is "RECOMMENDED that all MPL Interfaces atta= ched to the same link of a given MPL Domain use the same values for the Tri= ckle Parameters=94 (I=92m quoting draft-ietf-roll-trickle-mcast because it = is not a MUST, even though rfc6206 talks about =93unintended behaviors=94).= This document says (Section 2.4) that "the server will send MPL Paramet= er Configuration Option only if configured=85and the client requested it=94= ..and (Section 2.2) says that a client "MAY request MPL Parameter Configura= tion Option=94. In summary, the server won=92t send the Option unless the = client requests it; is that what is intended? Furthermore, the request is = optional (I=92m assuming there may be resource considerations here), so the= re may be cases in which not all clients request the Option, resulting in p= otentially mismatched parameters. Am I interpreting the text correctly? I= f so, why was it specified this way (instead of having the server send the = Option (when configured for a specific MPL Domain) always? Does the client= then require configuration to be able to request the additional configurat= ion parameters? * I don=92t necessarily want to change the behavior proposed, as I= =92m assuming it has been discussed in the WG and there are good reasons be= hind it. * Instead, I would like to see some discussion about it in the Oper= ational Considerations section. Pointing to rfc6206 may be enough to remin= d people who are implementing this Option. * Related to this point: I recommend moving the discussion in Append= ix B to the Operational Considerations section. Minor: 1. Section 1 (Introduction): "Some managed wireless mesh networks may ha= ve a DHCP server to configure network parameters.=94 How common is the use= of DHCP? =93Some..may=94 doesn=92t sound like this extension will be used= a lot. How do other networks configure their parameters? I=92m assuming = manually.. 2. Section 2.1. (MPL Parameter Configuration Option Format). The descri= ptions of the fields need to be very specific, specially if invalid content= s are to be discarded (per 2.2 and rfc7227). * When is P set? It may be obvious that it is set when PROACTIVE_FO= RWARDING is TRUE, but please specify it. * TUNIT: "Unit time of times=94, what does that mean? * DM_T_EXP/C_T_EXP: DATA_MESSAGE_TIMER_EXPIRATIONS/CONTROL_MESSAGE_T= IMER_EXPIRATIONS are defined as the number of expirations, so how do you en= d with ms? * The "MPL Domain Address=94 field is not defined. 3. Section 2.3 (MPL Forwarder Behavior) Joining and leaving the domain.= I must be missing something.. * "the node MAY join the MPL domain given by the option=94 Why woul= d the client request the Option and then not join the domain? * "A node MAY leave from an MPL domain..=94 The conditions seem to = say that the domain in the Option changed, is that true? If the domain in = the option changed, why would the node not leave the domain? 4. Section 4. (Security Considerations) Please include references and c= omments (where needed) to the security considerations in rfc3315 and rfc722= 7. Nits: 1. The word =93draft=94 is used in a couple of places to refer to this d= ocument and MPL; use =93document=94 instead. 2. Section 2 (MPL Parameter Configuration Option) s/there are following = 10 parameters/there are the following 10 parameters 3. 2.5. (DHCPv6 Relay Behavior). A reference to rfc6422 would be nice. 4. Section 2.6. (Operational Considerations) "A parameter set for an MPL= domain SHOULD NOT be updated more often than two times of expected refresh= interval.=94 I=92m assuming that the =93expected refresh interval=94 is I= nformation Refresh Time, right? If so, please call it what it is. 5. I would consider rfc7227 a Normative Reference. --_000_D1A4F4BAB8391aretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9913B078E6195C44B7116B7FFFEC37AD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi!

I just finished reading this document.  

I think the document is almost ready to move forward =97 I have one major c= omment (below) related to sending the Option as it relates to the potential= of mismatched options.  I am going to start the IETF Last Call, but e= xpect at least a discussion about that comment before putting the draft in front of the IESG.

Thanks!

Alvaro.


Major:
  1. Sending this Option.  It is "RECOMMENDED = that all MPL Interfaces attached to the same link of a given MPL Domain use= the same values for the Trickle Parameters=94 (I=92m quoting draft-ietf-roll-trickle-mcast because it is not a MUST, eve= n though rfc6206 talks about =93unintended behaviors=94).   This docum= ent says  (Section 2.4) that "the server will send MPL Parameter = Configuration Option only if configured=85and the client requested it=94..and (Section 2.2) says that a client "MAY request MP= L Parameter Configuration Option=94.  In summary, the server won=92t s= end the Option unless the client requests it; is that what is intended? &nb= sp;Furthermore, the request is optional (I=92m assuming there may be resource considerations here), so there may be cases in which= not all clients request the Option, resulting in potentially mismatched pa= rameters.  Am I interpreting the text correctly?  If so, why was = it specified this way (instead of having the server send the Option (when configured for a specific MPL Domain) always?=  Does the client then require configuration to be able to request the= additional configuration parameters?
    • I don=92t necessarily want to change the behavior proposed, as I=92m as= suming it has been discussed in the WG and there are good reasons behind it= .
    • Instead, I would like to see some discussion about it  in th= e Operational Considerations section.  Pointing to rfc6206 may be enou= gh to remind people who are implementing this Option.
    • Related to th= is point: I recommend moving the discussion in Appendix B to the Operationa= l Considerations section.
Minor:
  1. Section 1 (Introduction): "Some managed wireless mesh networks may hav= e a DHCP server to configure network parameters.=94  How common is the= use of DHCP?  =93Some..may=94 doesn=92t sound like this extension wil= l be used a lot.  How do other networks configure their parameters?  I=92m assuming manually..
  2. Section 2.1. (MPL Parameter Configuration Option Format).  The de= scriptions of the fields need to be very specific, specially if invalid con= tents are to be discarded (per 2.2 and rfc7227).
    • When is P set?  It may be obvious that it is set when PROACTIVE_F= ORWARDING is TRUE, but please specify it.
    • TUNIT: "Unit time of times=94, what does that mean?
    • DM_T_EXP/C_T_EXP: DATA_MESSAGE_TIMER_EXPIRATIONS/CONTROL_MESSAGE_TIMER_EXPIRATIO= NS are defined as the number of expirations, so how do you end with ms?
    • The "MPL Domain Address= =94 field is not defined.
  3. Section 2.3 (MPL Forwarder Behav= ior)  Joining and leaving the domain.  I must be missing somethin= g..
    • "the node MAY join the MPL domain given by the option=94  Why= would the client request the Option and then not join the domain?
    • "A node MAY leave from an MPL domain..=94  The conditions = seem to say that the domain in the Option changed, is that true?  If t= he domain in the option changed, why would the node not leave the domain?
  4. Section 4. (Secu= rity Considerations)  Please include references and comments (where ne= eded) to the security considerations in rfc3315 and rfc7227.
    5. Nits:
    1. The word =93draft=94 is used in a couple of places to refer to this documen= t and MPL; use =93document=94 instead.
    2. Section 2 (MPL Parameter Configuration Option) s/there are following 10 par= ameters/there are the following 10 parameters
    3. 2.5. (DHCPv6 Relay Behavior).  A reference to rfc<= font face=3D"Calibri,sans-serif">6422 would be nice.
    4. Section 2.6. (Operational Considerations) "= A parameter set for an MPL domain = SHOULD NOT be updated more often than two times of expected refresh interval.=94  I=92m assuming that the&n= bsp;=93expected refresh interval=94 is Information Refresh Time, right?  If so, please call it= what it is.
    5. I would consi= der rfc7227 a Normative Reference.
    --_000_D1A4F4BAB8391aretanaciscocom_-- From nobody Mon Jun 15 17:32:11 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1131ACCF3; Mon, 15 Jun 2015 17:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YK09QSXbGVwo; Mon, 15 Jun 2015 17:32:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDFA1B37F3; Mon, 15 Jun 2015 17:32:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150616003205.22515.97827.idtracker@ietfa.amsl.com> Date: Mon, 15 Jun 2015 17:32:05 -0700 From: IETF Secretariat Archived-At: Subject: [Roll] ID Tracker State Update Notice: X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 00:32:10 -0000 IESG state changed to Last Call Requested from AD Evaluation ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ From nobody Mon Jun 15 17:32:58 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76F61B37F3; Mon, 15 Jun 2015 17:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbUwtJZ4fpVI; Mon, 15 Jun 2015 17:32:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA221B37F0; Mon, 15 Jun 2015 17:32:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150616003251.5819.18613.idtracker@ietfa.amsl.com> Date: Mon, 15 Jun 2015 17:32:51 -0700 From: IETF Secretariat Archived-At: Subject: [Roll] Telechat update notice: X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 00:32:55 -0000 Placed on agenda for telechat - 2015-07-09 ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ From nobody Tue Jun 16 06:27:44 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2CA91B34F6; Tue, 16 Jun 2015 06:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbNN6XxDVa4U; Tue, 16 Jun 2015 06:27:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0E91B34C5; Tue, 16 Jun 2015 06:27:39 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150616132739.29107.22768.idtracker@ietfa.amsl.com> Date: Tue, 16 Jun 2015 06:27:39 -0700 Archived-At: Cc: roll@ietf.org Subject: [Roll] Last Call: (MPL Parameter Configuration Option for DHCPv6) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 13:27:41 -0000 The IESG has received a request from the Routing Over Low power and Lossy networks WG (roll) to consider the following document: - 'MPL Parameter Configuration Option for DHCPv6' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-06-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This draft defines a way to configure a parameter set of MPL (Multicast Protocol for Low power and Lossy Networks) via DHCPv6 option. MPL has a set of parameters to control its behavior, and the parameter set is often configured as a network-wide parameter because the parameter set should be identical for each MPL forwarder in an MPL domain. Using the MPL Parameter Configuration Option defined in this document, a network can be configured with a single set of MPL parameter easily. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Jun 16 06:28:00 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3360F1B350B; Tue, 16 Jun 2015 06:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PS_MDcOYgpNS; Tue, 16 Jun 2015 06:27:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B65821B3501; Tue, 16 Jun 2015 06:27:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150616132742.29107.21277.idtracker@ietfa.amsl.com> Date: Tue, 16 Jun 2015 06:27:42 -0700 From: IETF Secretariat Archived-At: Subject: [Roll] ID Tracker State Update Notice: X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 13:27:59 -0000 Last call has been made for draft-ietf-roll-mpl-parameter-configuration and state has been changed to In Last Call ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ From nobody Tue Jun 16 06:35:47 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3FA1B353D; Tue, 16 Jun 2015 06:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xdQ4I_FFmEl; Tue, 16 Jun 2015 06:35:44 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981C61B3544; Tue, 16 Jun 2015 06:35:09 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 90028200A1; Tue, 16 Jun 2015 09:49:49 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 45E5363B10; Tue, 16 Jun 2015 09:35:07 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 336C063AE8; Tue, 16 Jun 2015 09:35:07 -0400 (EDT) From: Michael Richardson To: "Alvaro Retana \(aretana\)" In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: "roll-chairs@ietf.org" , "roll@ietf.org" , Ines Robles , "draft-ietf-roll-mpl-parameter-configuration@tools.ietf.org" Subject: Re: [Roll] AD Review of draft-ietf-roll-mpl-parameter-configuration X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 13:35:46 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Alvaro Retana (aretana) wrote: > I just finished reading this document. > I think the document is almost ready to move forward =E2=80=94 I have= one > major comment (below) related to sending the Option as it relates to > the potential of mismatched options. I am going to start the IETF Last > Call, but expect at least a discussion about that comment before > putting the draft in front of the IESG. Do you mean, if different parts of the network have different parameters? I had that same question, and I asked it here: https://tools.ietf.org/wg/roll/trac/ticket/157 > rfc6206 talks about =E2=80=9Cunintended behaviors=E2=80=9D). This doc= ument says > (Section 2.4) that "the server will send MPL Parameter Configuration > Option only if configured=E2=80=A6and the client requested it=E2=80= =9D..and (Section > 2.2) says that a client "MAY request MPL Parameter Configuration > Option=E2=80=9D. In summary, the server won=E2=80=99t send the Option= unless the > client requests it; is that what is intended? Furthermore, the > request is optional (I=E2=80=99m assuming there may be resource > considerations here), so there may be cases in which not all clients > request the Option, resulting in potentially mismatched parameters. Clients that don't ask for the option probably don't support it.... > Am I interpreting the text correctly? If so, why was it specified > this way (instead of having the server send the Option (when > configured for a specific MPL Domain) always? Does the client then > require configuration to be able to request the additional > configuration parameters? That's mostly how DHCPv6 works. The client sends a list of options it cares about, and the server answers them. That seems the right thing to do with constrained nodes on a challenged network. > * Instead, I would like to see some discussion about it in the > Operational Considerations section. Pointing to rfc6206 may be > enough to remind people who are implementing this Option. > * Related to this point: I recommend moving the discussion in > Appendix B to the Operational Considerations section. okay. =2D- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVYAmCoCLcPvd0N1lAQJUVgf/ef3ymeEVSQOOTD2jdleSqp4AbgDDkgk4 Lg3ZCty4ykDSLgUAM07JBJ5r9HnkokBb5mhGKAgy0mx1OX9A/TJ5yJihztMMt+tD t4pqSBjkW5VaGQr177BSzqXA3aC7lFCIhCiHorxa8Tng3Obtk1Z0IxTpWSNq1Fsf zurWXTgdF+rcK2HrDbEExZvxpmvcG+rheQsbTA3QxmCze9z6RvJzAGJGhRZH0q2P ovwGLc8TLV6Yf6H70RFn5r6ehnAYpfXVWmiQg7WmBKbNdUk5e+j9o5nfmGg/2Vlh KUbsim8F8d/s2YnrZXnEAG/uhIOo2p9w65i6lpM/nq1J+WtsSyLOcw== =qwPj -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 17 09:44:08 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144C51B2A70; Wed, 17 Jun 2015 09:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.497 X-Spam-Level: ** X-Spam-Status: No, score=2.497 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3x6taG2622Ql; Wed, 17 Jun 2015 09:44:04 -0700 (PDT) Received: from imx2.toshiba.co.jp (imx2.toshiba.co.jp [106.186.93.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A443E1B2A56; Wed, 17 Jun 2015 09:43:34 -0700 (PDT) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id t5HGhVeS015821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jun 2015 01:43:31 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t5HGhVxh024607; Thu, 18 Jun 2015 01:43:31 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 280; Thu, 18 Jun 2015 01:43:31 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id t5HGhVjm024598; Thu, 18 Jun 2015 01:43:31 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id t5HGhV44010091; Thu, 18 Jun 2015 01:43:31 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id BAA10088; Thu, 18 Jun 2015 01:43:31 +0900 Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id t5HGhUqJ017102; Thu, 18 Jun 2015 01:43:30 +0900 (JST) Received: from spiffy20.isl.rdc.toshiba.co.jp by toshiba.co.jp id t5HGhUk8024934; Thu, 18 Jun 2015 01:43:30 +0900 (JST) Received: from [133.199.16.46] (ivpn-1-46.mobile.toshiba.co.jp [133.199.16.46]) by spiffy20.isl.rdc.toshiba.co.jp (Postfix) with ESMTPSA id 593F518F4D8; Thu, 18 Jun 2015 01:43:28 +0900 (JST) Message-ID: <5581A3AD.8060309@toshiba.co.jp> Date: Thu, 18 Jun 2015 01:43:25 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Alvaro Retana (aretana)" , "draft-ietf-roll-mpl-parameter-configuration@tools.ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp id t5HGhVjm024598 Archived-At: Cc: "roll-chairs@ietf.org" , "roll@ietf.org" , Ines Robles Subject: Re: [Roll] AD Review of draft-ietf-roll-mpl-parameter-configuration X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 16:44:07 -0000 Hi Alvaro, Thank you for the review, (Chairs, it's first time to go throught the process for me. Shall I update the document accordingly as soon as possible? or shall I wait for further discussion?) On 2015-06-16 9:31, Alvaro Retana (aretana) wrote: > Major: > > 1. Sending this Option. It is "RECOMMENDED that all MPL Interfaces > attached to the same link of a given MPL Domain use the same values > for the Trickle Parameters=94 (I=92m quoting > draft-ietf-roll-trickle-mcast because it is not a MUST, even though > rfc6206 talks about =93unintended behaviors=94). This document sa= ys > (Section 2.4) that "the server will send MPL Parameter > Configuration Option only if configured=85and the client requested > it=94..and (Section 2.2) says that a client "MAY request MPL Parame= ter > Configuration Option=94. In summary, the server won=92t send the O= ption > unless the client requests it; is that what is intended? > Furthermore, the request is optional (I=92m assuming there may be > resource considerations here), so there may be cases in which not > all clients request the Option, resulting in potentially mismatched > parameters. Am I interpreting the text correctly? If so, why was > it specified this way (instead of having the server send the Option > (when configured for a specific MPL Domain) always? Does the clien= t > then require configuration to be able to request the additional > configuration parameters? > * I don=92t necessarily want to change the behavior proposed, as = I=92m > assuming it has been discussed in the WG and there are good > reasons behind it. > * Instead, I would like to see some discussion about it in the > Operational Considerations section. Pointing to rfc6206 may be > enough to remind people who are implementing this Option. > * Related to this point: I recommend moving the discussion in > Appendix B to the Operational Considerations section. As Michael stated, I think this is normal behavior and intended behavior. 'unintended behaviors' are mostly unbalanced (unfair) data relay or loss=20 of message. I think the reason is not critical enough to mandate the opti= on. > Minor: > > 1. Section 1 (Introduction): "Some managed wireless mesh networks may > have a DHCP server to configure network parameters.=94 How common = is > the use of DHCP? =93Some..may=94 doesn=92t sound like this extensi= on will > be used a lot. How do other networks configure their parameters? > I=92m assuming manually.. I have no other experience, but I assume the configuration will be done=20 manually... > 2. Section 2.1. (MPL Parameter Configuration Option Format). The > descriptions of the fields need to be very specific, specially if > invalid contents are to be discarded (per 2.2 and rfc7227). > * When is P set? It may be obvious that it is set > when PROACTIVE_FORWARDING is TRUE, but please specify it. > * TUNIT: "Unit time of times=94, what does that mean? > * DM_T_EXP/C_T_EXP: > DATA_MESSAGE_TIMER_EXPIRATIONS/CONTROL_MESSAGE_TIMER_EXPIRATION= S > are defined as the number of expirations, so how do you end wit= h ms? > * The "MPL Domain Address=94 field is not defined. Thanks, I'll fix them. *_EXP are mistakes. It should be just integers as=20 defined in MPL. > 3. Section 2.3 (MPL Forwarder Behavior) Joining and leaving the > domain. I must be missing something.. > * "the node MAY join the MPL domain given by the option=94 Why > would the client request the Option and then not join the domai= n? One reason is resource constraint. As joining to a MPL domain requires=20 certain amount of buffers allocated, a node may fail to join all of the=20 domains given by the option. > * "A node MAY leave from an MPL domain..=94 The conditions seem = to > say that the domain in the Option changed, is that true? If th= e > domain in the option changed, why would the node not leave the > domain? There's no reason except the domain is configured manually at the same=20 time (the first condition is not met). If there are a manual=20 configuration, implementation may consider it's overriding the DHCPv6=20 Option. Is this clear?: """ A node SHOULD leave from a MPL domain if the node received a new option=20 without configuration for the MPL domain, unless it has overriding=20 external configuration on the MPL domain. """ > 4. Section 4. (Security Considerations) Please include references and > comments (where needed) to the security considerations in rfc3315 > and rfc7227. Thanks. I'll add this. > Nits: > > 1. The word =93draft=94 is used in a couple of places to refer to this > document and MPL; use =93document=94 instead. > 2. Section 2 (MPL Parameter Configuration Option) s/there are followin= g > 10 parameters/there are the following 10 parameters > 3. 2.5. (DHCPv6 Relay Behavior). A reference to rfc6422 would be nice. > 4. Section 2.6. (Operational Considerations) "A parameter set for an > MPL domain SHOULD NOT be updated more often than two times of > expected refresh interval.=94 I=92m assuming that the =93expected = refresh > interval=94 is Information Refresh Time, right? If so, please call= it > what it is. > 5. I would consider rfc7227 a Normative Reference. Thanks for pointing it out. Best Regards, Yusuke From nobody Wed Jun 17 13:01:17 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C6F1B2DB6; Wed, 17 Jun 2015 13:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rX56T9ssPO9a; Wed, 17 Jun 2015 13:01:13 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9AB91B2DB1; Wed, 17 Jun 2015 13:01:10 -0700 (PDT) Received: by labbc20 with SMTP id bc20so40730100lab.1; Wed, 17 Jun 2015 13:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kqt8qRnzb9GSzyxMW7wKNrlVUbq19iMPRysrVx6YSCY=; b=Oer9eD+c7vwA1CxdVi9PVgXTlUxih8wVNFEXzEHbU1Imonn6i7JbbVppMUi85Kng7f IqiRC/KUtytkCQrMyjg05a+rpv3bRC3Gg6DNQLkZZ99pPFDxiDoCwn4pCHiHtDBNg7zd 8kc+OkmmmPi5RLXiUv5j7oKViP89sJV4KLgm4J1C747rhW3wzC0WgHH1pnPkfes/HvtO iUdtKmukXXxp9v4S2HKVeFNj468vlbaxRmuLo7FG3pG0xkNGid56SI9DrnSTaTq8XVBR jpj86Lwud2Gqx/q1WUpUPF/bQUA+ubBnt/qUXfBrYw3yNhREYqRYCIDOQAN4TuKu+BnS DeJQ== MIME-Version: 1.0 X-Received: by 10.152.1.4 with SMTP id 4mr9608090lai.25.1434571269314; Wed, 17 Jun 2015 13:01:09 -0700 (PDT) Received: by 10.25.208.70 with HTTP; Wed, 17 Jun 2015 13:01:09 -0700 (PDT) Received: by 10.25.208.70 with HTTP; Wed, 17 Jun 2015 13:01:09 -0700 (PDT) In-Reply-To: <5581A3AD.8060309@toshiba.co.jp> References: <5581A3AD.8060309@toshiba.co.jp> Date: Wed, 17 Jun 2015 23:01:09 +0300 Message-ID: From: Ines Robles To: roll , Yusuke DOI Content-Type: multipart/alternative; boundary=089e013c66a8e9a09b0518bc2658 Archived-At: Cc: roll-chairs@ietf.org, MARIA INES ROBLES , draft-ietf-roll-mpl-parameter-configuration@tools.ietf.org Subject: Re: [Roll] AD Review of draft-ietf-roll-mpl-parameter-configuration X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 20:01:15 -0000 --089e013c66a8e9a09b0518bc2658 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yusuke, you could update the document in a couple of days. Thank you very much On 17 Jun 2015 19:44, "Yusuke DOI" wrote: > Hi Alvaro, > > Thank you for the review, > > (Chairs, it's first time to go throught the process for me. > Shall I update the document accordingly as soon as possible? > or shall I wait for further discussion?) > > > On 2015-06-16 9:31, Alvaro Retana (aretana) wrote: > >> Major: >> >> 1. Sending this Option. It is "RECOMMENDED that all MPL Interfaces >> attached to the same link of a given MPL Domain use the same values >> for the Trickle Parameters=E2=80=9D (I=E2=80=99m quoting >> draft-ietf-roll-trickle-mcast because it is not a MUST, even though >> rfc6206 talks about =E2=80=9Cunintended behaviors=E2=80=9D). This = document says >> (Section 2.4) that "the server will send MPL Parameter >> Configuration Option only if configured=E2=80=A6and the client reque= sted >> it=E2=80=9D..and (Section 2.2) says that a client "MAY request MPL P= arameter >> Configuration Option=E2=80=9D. In summary, the server won=E2=80=99t= send the Option >> unless the client requests it; is that what is intended? >> Furthermore, the request is optional (I=E2=80=99m assuming there m= ay be >> resource considerations here), so there may be cases in which not >> all clients request the Option, resulting in potentially mismatched >> parameters. Am I interpreting the text correctly? If so, why was >> it specified this way (instead of having the server send the Option >> (when configured for a specific MPL Domain) always? Does the client >> then require configuration to be able to request the additional >> configuration parameters? >> * I don=E2=80=99t necessarily want to change the behavior proposed= , as I=E2=80=99m >> assuming it has been discussed in the WG and there are good >> reasons behind it. >> * Instead, I would like to see some discussion about it in the >> Operational Considerations section. Pointing to rfc6206 may be >> enough to remind people who are implementing this Option. >> * Related to this point: I recommend moving the discussion in >> Appendix B to the Operational Considerations section. >> > > As Michael stated, I think this is normal behavior and intended behavior. > > 'unintended behaviors' are mostly unbalanced (unfair) data relay or loss > of message. I think the reason is not critical enough to mandate the opti= on. > > Minor: >> >> 1. Section 1 (Introduction): "Some managed wireless mesh networks may >> have a DHCP server to configure network parameters.=E2=80=9D How co= mmon is >> the use of DHCP? =E2=80=9CSome..may=E2=80=9D doesn=E2=80=99t sound = like this extension will >> be used a lot. How do other networks configure their parameters? >> I=E2=80=99m assuming manually.. >> > > I have no other experience, but I assume the configuration will be done > manually... > > 2. Section 2.1. (MPL Parameter Configuration Option Format). The >> descriptions of the fields need to be very specific, specially if >> invalid contents are to be discarded (per 2.2 and rfc7227). >> * When is P set? It may be obvious that it is set >> when PROACTIVE_FORWARDING is TRUE, but please specify it. >> * TUNIT: "Unit time of times=E2=80=9D, what does that mean? >> * DM_T_EXP/C_T_EXP: >> DATA_MESSAGE_TIMER_EXPIRATIONS/CONTROL_MESSAGE_TIMER_EXPIRATIONS >> are defined as the number of expirations, so how do you end with >> ms? >> * The "MPL Domain Address=E2=80=9D field is not defined. >> > > Thanks, I'll fix them. *_EXP are mistakes. It should be just integers as > defined in MPL. > > 3. Section 2.3 (MPL Forwarder Behavior) Joining and leaving the >> domain. I must be missing something.. >> * "the node MAY join the MPL domain given by the option=E2=80=9D = Why >> would the client request the Option and then not join the domain= ? >> > > One reason is resource constraint. As joining to a MPL domain requires > certain amount of buffers allocated, a node may fail to join all of the > domains given by the option. > > * "A node MAY leave from an MPL domain..=E2=80=9D The conditions = seem to >> say that the domain in the Option changed, is that true? If the >> domain in the option changed, why would the node not leave the >> domain? >> > > There's no reason except the domain is configured manually at the same > time (the first condition is not met). If there are a manual configuratio= n, > implementation may consider it's overriding the DHCPv6 Option. > > Is this clear?: > > """ > A node SHOULD leave from a MPL domain if the node received a new option > without configuration for the MPL domain, unless it has overriding extern= al > configuration on the MPL domain. > """ > > > 4. Section 4. (Security Considerations) Please include references and >> comments (where needed) to the security considerations in rfc3315 >> and rfc7227. >> > > Thanks. I'll add this. > > Nits: >> >> 1. The word =E2=80=9Cdraft=E2=80=9D is used in a couple of places to re= fer to this >> document and MPL; use =E2=80=9Cdocument=E2=80=9D instead. >> 2. Section 2 (MPL Parameter Configuration Option) s/there are following >> 10 parameters/there are the following 10 parameters >> 3. 2.5. (DHCPv6 Relay Behavior). A reference to rfc6422 would be nice. >> 4. Section 2.6. (Operational Considerations) "A parameter set for an >> MPL domain SHOULD NOT be updated more often than two times of >> expected refresh interval.=E2=80=9D I=E2=80=99m assuming that the = =E2=80=9Cexpected refresh >> interval=E2=80=9D is Information Refresh Time, right? If so, please= call it >> what it is. >> 5. I would consider rfc7227 a Normative Reference. >> > > Thanks for pointing it out. > > Best Regards, > > Yusuke > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --089e013c66a8e9a09b0518bc2658 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

    Hi Yusuke,
    you could update the document in a couple of days.
    Thank you very much

    On 17 Jun 2015 19:44, "Yusuke DOI" <= ;yusuke.doi@toshiba.co.jp&g= t; wrote:
    Hi Alvar= o,

    Thank you for the review,

    (Chairs, it's first time to go throught the process for me.
    =C2=A0Shall I update the document accordingly as soon as possible?
    =C2=A0or shall I wait for further discussion?)


    On 2015-06-16 9:31, Alvaro Retana (aretana) wrote:
    Major:

    =C2=A01. Sending this Option.=C2=A0 It is "RECOMMENDED that all MPL In= terfaces
    =C2=A0 =C2=A0 attached to the same link of a given MPL Domain use the same = values
    =C2=A0 =C2=A0 for the Trickle Parameters=E2=80=9D (I=E2=80=99m quoting
    =C2=A0 =C2=A0 draft-ietf-roll-trickle-mcast because it is not a MUST, even = though
    =C2=A0 =C2=A0 rfc6206 talks about =E2=80=9Cunintended behaviors=E2=80=9D).= =C2=A0 =C2=A0This document says
    =C2=A0 =C2=A0 =C2=A0 (Section 2.4) that "the server will send MPL Para= meter
    =C2=A0 =C2=A0 Configuration Option only if configured=E2=80=A6and the clien= t requested
    =C2=A0 =C2=A0 it=E2=80=9D..and (Section 2.2) says that a client "MAY r= equest MPL Parameter
    =C2=A0 =C2=A0 Configuration Option=E2=80=9D.=C2=A0 In summary, the server w= on=E2=80=99t send the Option
    =C2=A0 =C2=A0 unless the client requests it; is that what is intended?
    =C2=A0 =C2=A0 =C2=A0 Furthermore, the request is optional (I=E2=80=99m assu= ming there may be
    =C2=A0 =C2=A0 resource considerations here), so there may be cases in which= not
    =C2=A0 =C2=A0 all clients request the Option, resulting in potentially mism= atched
    =C2=A0 =C2=A0 parameters.=C2=A0 Am I interpreting the text correctly?=C2=A0= If so, why was
    =C2=A0 =C2=A0 it specified this way (instead of having the server send the = Option
    =C2=A0 =C2=A0 (when configured for a specific MPL Domain) always?=C2=A0 Doe= s the client
    =C2=A0 =C2=A0 then require configuration to be able to request the addition= al
    =C2=A0 =C2=A0 configuration parameters?
    =C2=A0 =C2=A0 =C2=A0 * I don=E2=80=99t necessarily want to change the behav= ior proposed, as I=E2=80=99m
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 assuming it has been discussed in the WG and th= ere are good
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 reasons behind it.
    =C2=A0 =C2=A0 =C2=A0 * Instead, I would like to see some discussion about i= t=C2=A0 in the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Operational Considerations section.=C2=A0 Point= ing to rfc6206 may be
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 enough to remind people who are implementing th= is Option.
    =C2=A0 =C2=A0 =C2=A0 * Related to this point: I recommend moving the discus= sion in
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Appendix B to the Operational Considerations se= ction.

    As Michael stated, I think this is normal behavior and intended behavior.
    'unintended behaviors' are mostly unbalanced (unfair) data relay or= loss of message. I think the reason is not critical enough to mandate the = option.

    Minor:

    =C2=A01. Section 1 (Introduction): "Some managed wireless mesh network= s may
    =C2=A0 =C2=A0 have a DHCP server to configure network parameters.=E2=80=9D= =C2=A0 How common is
    =C2=A0 =C2=A0 the use of DHCP?=C2=A0 =E2=80=9CSome..may=E2=80=9D doesn=E2= =80=99t sound like this extension will
    =C2=A0 =C2=A0 be used a lot.=C2=A0 How do other networks configure their pa= rameters?
    =C2=A0 =C2=A0 =C2=A0 I=E2=80=99m assuming manually..

    I have no other experience, but I assume the configuration will be done man= ually...

    =C2=A02. Section 2.1. (MPL Parameter Configuration Option Format).=C2=A0 Th= e
    =C2=A0 =C2=A0 descriptions of the fields need to be very specific, speciall= y if
    =C2=A0 =C2=A0 invalid contents are to be discarded (per 2.2 and rfc7227). =C2=A0 =C2=A0 =C2=A0 * When is P set?=C2=A0 It may be obvious that it is se= t
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 when PROACTIVE_FORWARDING is TRUE, but please s= pecify it.
    =C2=A0 =C2=A0 =C2=A0 * TUNIT: "Unit time of times=E2=80=9D, what does = that mean?
    =C2=A0 =C2=A0 =C2=A0 * DM_T_EXP/C_T_EXP:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 DATA_MESSAGE_TIMER_EXPIRATIONS/CONTROL_MESSAGE_= TIMER_EXPIRATIONS
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 are defined as the number of expirations, so ho= w do you end with ms?
    =C2=A0 =C2=A0 =C2=A0 * The "MPL Domain Address=E2=80=9D field is not d= efined.

    Thanks, I'll fix them. *_EXP are mistakes. It should be just integers a= s defined in MPL.

    =C2=A03. Section 2.3 (MPL Forwarder Behavior)=C2=A0 Joining and leaving the=
    =C2=A0 =C2=A0 domain.=C2=A0 I must be missing something..
    =C2=A0 =C2=A0 =C2=A0 * "the node MAY join the MPL domain given by the = option=E2=80=9D=C2=A0 Why
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 would the client request the Option and then no= t join the domain?

    One reason is resource constraint. As joining to a MPL domain requires cert= ain amount of buffers allocated, a node may fail to join all of the domains= given by the option.

    =C2=A0 =C2=A0 =C2=A0 * "A node MAY leave from an MPL domain..=E2=80=9D= =C2=A0 The conditions seem to
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 say that the domain in the Option changed, is t= hat true?=C2=A0 If the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 domain in the option changed, why would the nod= e not leave the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 domain?

    There's no reason except the domain is configured manually at the same = time (the first condition is not met). If there are a manual configuration,= implementation may consider it's overriding the DHCPv6 Option.

    Is this clear?:

    """
    A node SHOULD leave from a MPL domain if the node received a new option wit= hout configuration for the MPL domain, unless it has overriding external co= nfiguration on the MPL domain.
    """


    =C2=A04. Section 4. (Security Considerations)=C2=A0 Please include referenc= es and
    =C2=A0 =C2=A0 comments (where needed) to the security considerations in rfc= 3315
    =C2=A0 =C2=A0 and rfc7227.

    Thanks. I'll add this.

    Nits:

    =C2=A01. The word =E2=80=9Cdraft=E2=80=9D is used in a couple of places to = refer to this
    =C2=A0 =C2=A0 document and MPL; use =E2=80=9Cdocument=E2=80=9D instead.
    =C2=A02. Section 2 (MPL Parameter Configuration Option) s/there are followi= ng
    =C2=A0 =C2=A0 10 parameters/there are the following 10 parameters
    =C2=A03. 2.5. (DHCPv6 Relay Behavior).=C2=A0 A reference to rfc6422 would b= e nice.
    =C2=A04. Section 2.6. (Operational Considerations) "A parameter set fo= r an
    =C2=A0 =C2=A0 MPL domain SHOULD NOT be updated more often than two times of=
    =C2=A0 =C2=A0 expected refresh interval.=E2=80=9D=C2=A0 I=E2=80=99m assumin= g that the =E2=80=9Cexpected refresh
    =C2=A0 =C2=A0 interval=E2=80=9D is Information Refresh Time, right?=C2=A0 I= f so, please call it
    =C2=A0 =C2=A0 what it is.
    =C2=A05. I would consider rfc7227 a Normative Reference.

    Thanks for pointing it out.

    Best Regards,

    Yusuke

    _______________________________________________
    Roll mailing list
    Roll@ietf.org
    https://www.ietf.org/mailman/listinfo/roll
    --089e013c66a8e9a09b0518bc2658-- From nobody Thu Jun 18 09:49:21 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFC61B29AB; Thu, 18 Jun 2015 09:49:20 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains text/plain,.exe X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IA63SRsZlMO1; Thu, 18 Jun 2015 09:49:18 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35C441AD47E; Thu, 18 Jun 2015 09:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3429; q=dns/txt; s=iport; t=1434646158; x=1435855758; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/xL9x7tls5rKUqjG+PHrEzG7LrFLjCbzbkIJGqIyan8=; b=I6xMUzCOhwDT/nzYVtP6WT+WBKh359dmJfi9C2QPwS+bwFVQhdd6mLIb OS9KHOTUnXEaPAVvG0/0kvRKMw6kARe+s1zz71N5kdAvRg0nl+CyiKnOG lFLWWLvw+5fpcIxmYkbQ+g8LPrM88z0VScV0SaPpzJJzKtUQsv5O9xhki A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AYBQCg9YJV/5JdJa1cgxCBMwbFWAKBOjsRAQEBAQEBAYEKhCMBAQR5EAIBCEYyJQIEAQ0FiC/GCAEBAQEBAQEBAQEBAQEBAQEBAQEZi0WEOxgzB4QrAQSMPIRbglkBi0qYJiaDeW+BRoECAQEB X-IronPort-AV: E=Sophos;i="5.13,640,1427760000"; d="scan'208";a="160608419" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP; 18 Jun 2015 16:49:17 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t5IGnHn2027075 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jun 2015 16:49:17 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.106]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Thu, 18 Jun 2015 11:49:17 -0500 From: "Alvaro Retana (aretana)" To: Yusuke DOI , "draft-ietf-roll-mpl-parameter-configuration@tools.ietf.org" Thread-Topic: AD Review of draft-ietf-roll-mpl-parameter-configuration Thread-Index: AQHQp8vRQMajtavr+EaCvSKBOhrHTp2xPa+AgAFhqYA= Date: Thu, 18 Jun 2015 16:49:17 +0000 Message-ID: References: <5581A3AD.8060309@toshiba.co.jp> In-Reply-To: <5581A3AD.8060309@toshiba.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.242.9] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "roll-chairs@ietf.org" , "roll@ietf.org" , Ines Robles Subject: Re: [Roll] AD Review of draft-ietf-roll-mpl-parameter-configuration X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 16:49:20 -0000 On 6/17/15, 1:43 PM, "Yusuke DOI" wrote: Yusuke: Hi! . . . >> Minor: >> >> 1. Section 1 (Introduction): "Some managed wireless mesh networks may >> have a DHCP server to configure network parameters.=B2 How common i= s >> the use of DHCP? =B3Some..may=B2 doesn=B9t sound like this extensio= n will >> be used a lot. How do other networks configure their parameters? >> I=B9m assuming manually.. > >I have no other experience, but I assume the configuration will be done >manually... . . . > >> 3. Section 2.3 (MPL Forwarder Behavior) Joining and leaving the >> domain. I must be missing something.. >> * "the node MAY join the MPL domain given by the option=B2 Why >> would the client request the Option and then not join the >>domain? > >One reason is resource constraint. As joining to a MPL domain requires >certain amount of buffers allocated, a node may fail to join all of the >domains given by the option. The use of =B3MAY=B2 above gives the impression that joining is optional. = But you=B9re saying that even if the node wants to join it may not be able to, which is different. Suggestion: OLD> If a DHCPv6 client requests and receives MPL Parameter Configuration Option, the node MAY join the MPL domain given by the option and act as an MPL forwarder. NEW> If a DHCPv6 client requests and receives MPL Parameter Configuration Option, the node SHOULD join the MPL domain given by the option and act as an MPL forwarder. Note that there may be cases in which a node may fail is to join a domain (or domains) due to local resource constraints. I=B9m not sure if you/the WG want to add something else to that paragraph.. >> * "A node MAY leave from an MPL domain..=B2 The conditions seem t= o >> say that the domain in the Option changed, is that true? If the >> domain in the option changed, why would the node not leave the >> domain? > >There's no reason except the domain is configured manually at the same >time (the first condition is not met). If there are a manual >configuration, implementation may consider it's overriding the DHCPv6 >Option. > >Is this clear?: > >""" >A node SHOULD leave from a MPL domain if the node received a new option >without configuration for the MPL domain, unless it has overriding >external configuration on the MPL domain. >""" How about this instead: NEW> A node SHOULD leave an MPL domain if it receives an updated MPL Parameter Configuration Option without a configuration for the MPL domain, unless it has overriding external configuration. I=B9m not sure if =B3external=B2 is the right word..or if =B3manual=B2 migh= t be better. Look at the point #1 above about how other nodes may be configured. In this section (2.3) there=B9s a priority of configuration shown: The priority of MPL Parameter Configuration applied for an MPL Domain is as follows (high to low). o Specific MPL Parameter Configuration to the MPL Domain (optlen=3D34) o Wildcard MPL Parameter Configuration (optlen=3D18) o Default configuration given in the MPL specification. But there is no mention anywhere in the document to external/manual configuration. Where in that priority list should it fit? Thanks! Alvaro. From nobody Fri Jun 19 17:14:35 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5721B2B33; Fri, 19 Jun 2015 17:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kd7RF_qsP8He; Fri, 19 Jun 2015 17:14:28 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F68C1B2A7F; Fri, 19 Jun 2015 17:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t5K0EPbl005234; Sat, 20 Jun 2015 02:14:25 +0200 (CEST) Received: from alma.local (p5DC7EA60.dip0.t-ipconnect.de [93.199.234.96]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3mCyDJ5jbNz99SV; Sat, 20 Jun 2015 02:14:24 +0200 (CEST) Message-ID: <5584B05F.4030307@tzi.org> Date: Sat, 20 Jun 2015 02:14:23 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: roll@ietf.org, 6tisch@ietf.org, lwip@ietf.org, 6lo@ietf.org References: <5584AFFA.7030507@tzi.org> In-Reply-To: <5584AFFA.7030507@tzi.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Roll] Fwd: Constrained Node/Network Cluster @ IETF93, early draft version X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 00:14:30 -0000 A first draft version of the IETF93 agenda is out. ** THIS IS GOING TO CHANGE ** for conflict resolution, so please don't make travel arrangements based on it. Here is my usual eclectic condensed agenda built from that. (Bye, bye, appsawg. lwig over roll is interesting; at least we do have a roll meeting at all.) Note that the t2trg meeting on Monday is a "summary" meeting for those who haven't been able to join during the weekend (conflicts with Hackathon, ICNRG, etc.) All times are CEST (UTC+0200) (the browser timezone function appears to have vanished from https://datatracker.ietf.org/meeting/agenda-utc, but maybe we can reinstate that for those who want to listen from remote). Sorry for the duplicate posting, the IETF mail system does not allow sending to all 9 mailing lists at the same time. Grüße, Carsten SATURDAY, July 18, 2015 1000-1800 Session I (TBD) IRTF*** t2trg Proposed Thing-to-thing Research Group 0900-2100 IETF Hackathon - Chez Louis SUNDAY, July 19, 2015 0900-1600 Session II (TBD) IRTF*** t2trg Proposed Thing-to-thing Research Group 1000-1800 IETF Hackathon - Chez Louis 1600-1700 Newcomers' Meet and Greet (open to Newcomers and WG chairs only) - Garden Terrace 1700-1900 Welcome Reception - Grand Hilton Ballroom MONDAY, July 20, 2015 0900-1130 Morning Session I Grand Hilton BR ART appsawg Applications Area Working Group WG Karlin I/II OPS anima Autonomic Networking Integrated Model and Approach WG Berlin/Brussels SEC *** cose CBOR Object Signing and Encryption WG Congress H II TSV rmcat RTP Media Congestion Avoidance Techniques WG 1300-1500 Afternoon Session I Congress H III INT 6man IPv6 Maintenance WG Grand Hilton BR RTG detnet Deterministic Networking BOF 1520-1720 Afternoon Session II Berlin/Brussels IRTF*** t2trg Proposed Thing-to-Thing Research Group Congress H III TSV tcpinc TCP Increased Security WG 1740-1840 Afternoon Session III Congress H II INT *** 6lo IPv6 over Networks of Resource-constrained Nodes WG Karlin I/II SEC httpauth Hypertext Transfer Protocol Authentication WG 1850-1950 Afternoon Session IV Congress H I INT intarea Internet Area Working Group WG TUESDAY, July 21, 2015 1300-1500 Afternoon Session I Karlin I/II ART httpbis Hypertext Transfer Protocol WG Congress H II INT *** 6lo IPv6 over Networks of Resource-constrained Nodes WG Grand Hilton BR OPS v6ops IPv6 Operations WG 1520-1720 Afternoon Session II Karlin I/II ART *** core Constrained RESTful Environments WG Congress H II RTG rtgarea Routing Area Open Meeting Congress H III SEC tls Transport Layer Security WG 1740-1840 Afternoon Session III Congress H III ART uta Using TLS in Applications WG Berlin/Brussels INT *** lwig Light-Weight Implementation Guidance WG Congress H I RTG *** roll Routing Over Low power and Lossy networks WG WEDNESDAY, July 22, 2015 0900-1130 Morning Session I Athens/Barcel. INT dnssd Extensions for Scalable DNS Service Discovery WG Karlin I/II SEC *** ace Authentication and Authorization for Constrained Environments WG Grand Hilton BR SEC tls Transport Layer Security WG 1300-1530 Afternoon Session I Grand Hilton BR INT homenet Home Networking WG Berlin/Brussels RTG bier Bit Indexed Explicit Replication WG 1740-1940 Afternoon Session III Athens/Barcel. SEC oauth Web Authorization Protocol WG Congress H III TSV tsvwg Transport Area Working Group WG THURSDAY, July 23, 2015 1300-1500 Afternoon Session I Congress H II SEC saag Security Area Open Meeting Karlin I/II TSV taps Transport Services WG 1520-1720 Afternoon Session II Athens/Barcel. INT *** 6tisch IPv6 over the TSCH mode of IEEE 802.15.4e WG Congress H III SEC acme Automated Certificate Management Environment WG Grand Hilton BR TSV tsvwg Transport Area Working Group WG 1740-1910 Afternoon Session III Athens/Barcel. ART webpush Web-Based Push Notifications WG Karlin I/II OPS anima Autonomic Networking Integrated Model and Approach WG Grand Hilton BR TSV tsvarea Transport Area Open Meeting FRIDAY, July 24, 2015 0900-1130 Morning Session I Grand Hilton BR OPS v6ops IPv6 Operations WG Karlin I/II SEC openpgp Open Specification for Pretty Good Privacy WG 1150-1320 Afternoon Session I Karlin I/II ART *** core Constrained RESTful Environments WG Congress H I SEC tokbind Token Binding WG From nobody Mon Jun 22 07:47:14 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A630C1A03E3; Mon, 22 Jun 2015 07:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcERNvFrXr5o; Mon, 22 Jun 2015 07:47:08 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD65A1A1B00; Mon, 22 Jun 2015 07:47:08 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id AC17B880ED; Mon, 22 Jun 2015 07:47:08 -0700 (PDT) Received: from brians-mbp.jhuapl.edu (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 22C73136833E; Mon, 22 Jun 2015 07:47:08 -0700 (PDT) Message-ID: <55881FE6.9030700@innovationslab.net> Date: Mon, 22 Jun 2015 10:47:02 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Carsten Bormann , roll@ietf.org, 6tisch@ietf.org, lwip@ietf.org, 6lo@ietf.org References: <5584AFFA.7030507@tzi.org> <5584B05F.4030307@tzi.org> In-Reply-To: <5584B05F.4030307@tzi.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cElibchOaToVrmulAJhdg5d60IBIMq8SA" Archived-At: Subject: Re: [Roll] [6lo] Fwd: Constrained Node/Network Cluster @ IETF93, early draft version X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 14:47:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cElibchOaToVrmulAJhdg5d60IBIMq8SA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, Just one point... On 6/19/15 8:14 PM, Carsten Bormann wrote: >=20 > Here is my usual eclectic condensed agenda built from that. > (Bye, bye, appsawg. lwig over roll is interesting; at least we do > have a roll meeting at all.) LWIG and ROLL do not list each other as conflicts to avoid. If folks think this is an issue, please discuss it with the LWIG and ROLL chairs to see if they will add the appropriate entries in their conflicts-to-avoid list. Regards, Brian --cElibchOaToVrmulAJhdg5d60IBIMq8SA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJViB/rAAoJEBOZRqCi7goqej8IALWsqa/KMDw5d8tbE86G9QGx AtM1bsarhy9ll0j0Plx2v8c1Q876WFR4UV20nlwlC/hTkKB39kG1WJlQwYna5J8C g6Vylgu8rMiv2AOrnxan87smRxoAocsUfagWdpWFQpnT+umWK82XaGZrwfqmOLhI EO9G7mauPPZooqRq/eFYU1m0FVROIYsB7u+2wvknE5T4QFPxEml1PmzxnI7K976q pAPo+BggVhy/JS1KG0PvTtNANZ7oB7dBvcPi/0X0bjdih8ztzN/ukOjj88zzy5Ea Zj8eWulIY0jiRXROg3lZQ/XmV21rpzbEexUSKhMpCKUfUGMfoDGBez+zn46rIYA= =6r// -----END PGP SIGNATURE----- --cElibchOaToVrmulAJhdg5d60IBIMq8SA-- From nobody Thu Jun 25 11:06:30 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49BCD1AC409; Thu, 25 Jun 2015 11:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfDVn8Uz4L7W; Thu, 25 Jun 2015 11:06:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 752DD1A8767; Thu, 25 Jun 2015 11:06:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150625180625.18868.37851.idtracker@ietfa.amsl.com> Date: Thu, 25 Jun 2015 11:06:25 -0700 From: IETF Secretariat Archived-At: Subject: [Roll] ID Tracker State Update Notice: X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 18:06:29 -0000 IANA review state changed to IANA - Not OK ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ From nobody Thu Jun 25 21:45:47 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-mpl-parameter-configuration.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 9561C1ACECB; Thu, 25 Jun 2015 13:18:14 -0700 (PDT) X-Original-To: xfilter-draft-ietf-roll-mpl-parameter-configuration.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-mpl-parameter-configuration.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7299B1ACEBF for ; Thu, 25 Jun 2015 13:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.5 X-Spam-Level: X-Spam-Status: No, score=-9.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42KMQZVjlU1Q for ; Thu, 25 Jun 2015 13:18:13 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38AEB1ACEC7 for ; Thu, 25 Jun 2015 13:18:13 -0700 (PDT) Received: from alln-iport-4.cisco.com ([173.37.142.91]:60237) by zinfandel.tools.ietf.org with esmtps (TLS1.0:RSA_ARCFOUR_128_SHA1:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z8DbA-0003Lr-8J for draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org; Thu, 25 Jun 2015 13:18:12 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1617; q=dns/txt; s=iport; t=1435263492; x=1436473092; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=EM/NiGa/xG10Ws5MNWZ5BB1wdpMVQ4YFSJa79rbKDFs=; b=aLOAbJ4zt5RGshhbqy2cmSaY8r0WZ7VaWZr7m+w2D71Z8YnWuBbPptef bnmK8B7UywKs5TrfRKXDrTtTzHyrP2Dq2FLK/j9502c/MbP3dvtn7TMoM l/aM0nzXt9bqfM7Tq1VJDXft5yYprz73UvnikQNnGoCc7C6MAb46qZQSt A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BOBQBTYYxV/40NJK1cgxGBOb0Wh16BQjoSAQEBAQEBAYEKhCUEeRIBgQAnBAENiDTMIAEBAQEBAQEBAQEBAQEBAQEBAQEZkAEES4MegRQFlAYBhy+EIpg5JoN6gjWBAgEBAQ X-IronPort-AV: E=Sophos;i="5.13,679,1427760000"; d="scan'208";a="162983272" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-4.cisco.com with ESMTP; 25 Jun 2015 20:18:05 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t5PKI4uT008493 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Jun 2015 20:18:05 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.136]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Thu, 25 Jun 2015 15:18:05 -0500 From: "Brian Weis (bew)" To: The IESG , "secdir@ietf.org" Thread-Topic: Secdir review of draft-ietf-roll-mpl-parameter-configuration-04 Thread-Index: AQHQr4QKL7yMzuQ4YkCLPi20wdm6Hg== Date: Thu, 25 Jun 2015 20:18:04 +0000 Message-ID: <5BE572AB-D17A-4890-8385-B0F9A16C2A3F@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.49.63] Content-Type: text/plain; charset="Windows-1252" Content-ID: <55559D70BC1BA741BF320287835EF8D6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SA-Exim-Connect-IP: 173.37.142.91 X-SA-Exim-Rcpt-To: draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org X-SA-Exim-Mail-From: bew@cisco.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-roll-mpl-parameter-configuration.all@ietf.org Resent-Message-Id: <20150625201813.38AEB1ACEC7@ietfa.amsl.com> Resent-Date: Thu, 25 Jun 2015 13:18:13 -0700 (PDT) Resent-From: bew@cisco.com Archived-At: Archived-At: X-Mailman-Approved-At: Thu, 25 Jun 2015 21:45:45 -0700 Cc: "draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org" Subject: [Roll] Secdir review of draft-ietf-roll-mpl-parameter-configuration-04 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 20:18:14 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any = other last call comments. This draft defines a new DHCPv6 option, whereby a DHCP server can configure= a client with Multicast Protocol for Low power and Lossy Networks (MPL) p= olicy. The option definition seems straightforward. Security Considerations= outlines three items which seem useful: 1. Describing a resource consumption threat ("excessive layer-2 broadcastin= g=93) resulting from a man-in-the-middle modifying policy sent within an op= tion. If there is a suggested mitigation (e.g., a means of integrity protec= ting the DHCPv6 traffic between the client and server) this would be worth = noting. But I=92m not sure if there any available mitigation in a ROLL envi= ronment. 2. Making a requirement that a server implementation choose reasonable poli= cy values. This might be more useful if it were phrased as a threat, someth= ing like =93Server implementations need to take care in setting reasonable = bounds for each parameter in order to avoid overloading the network." 3. Making a requirement that the "DHCP server or the network itself shall b= e trusted by some means including network access control or DHCP authentica= tion=94. Is this this =93shall=94 intended to be an RFC 2119 =93MUST=94? I consider this draft to be Ready with nits. Brian From nobody Thu Jun 25 21:45:48 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-mpl-parameter-configuration.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 08FAD1B2C8B; Thu, 25 Jun 2015 16:16:27 -0700 (PDT) X-Original-To: xfilter-draft-ietf-roll-mpl-parameter-configuration.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-mpl-parameter-configuration.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3BF1B2C89 for ; Thu, 25 Jun 2015 16:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.566 X-Spam-Level: ** X-Spam-Status: No, score=2.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, MANGLED_LIST=2.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIrYzsixYK6q for ; Thu, 25 Jun 2015 16:16:25 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [IPv6:2a01:3f0:0:31::14]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D5381A8ABF for ; Thu, 25 Jun 2015 16:16:13 -0700 (PDT) Received: from p3plsmtpa12-06.prod.phx3.secureserver.net ([68.178.252.235]:49467) by merlot.tools.ietf.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.84) (envelope-from ) id 1Z8GNL-0005PB-Ly for draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org; Fri, 26 Jun 2015 01:16:10 +0200 Received: from spectre ([173.8.184.78]) by p3plsmtpa12-06.prod.phx3.secureserver.net with id knFg1q00C1huGat01nFgAz; Thu, 25 Jun 2015 16:15:41 -0700 From: "Peter Yee" To: Date: Thu, 25 Jun 2015 16:15:46 -0700 Message-ID: <01ea01d0af9c$de6319e0$9b294da0$@akayla.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCvkB/lbb0hWybkRGeIl4cumPBEbw== Content-Language: en-us X-SA-Exim-Connect-IP: 68.178.252.235 X-SA-Exim-Rcpt-To: draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org X-SA-Exim-Mail-From: peter@akayla.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:57:07 +0000) X-SA-Exim-Scanned: Yes (on merlot.tools.ietf.org) Resent-To: draft-ietf-roll-mpl-parameter-configuration.all@ietf.org Resent-Message-Id: <20150625231616.6D5381A8ABF@ietfa.amsl.com> Resent-Date: Thu, 25 Jun 2015 16:16:13 -0700 (PDT) Resent-From: peter@akayla.com Archived-At: Archived-At: X-Mailman-Approved-At: Thu, 25 Jun 2015 21:45:45 -0700 Cc: gen-art@ietf.org, ietf@ietf.org Subject: [Roll] Gen-ART LC review for draft-ietf-roll-mpl-parameter-configuration-04 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 23:16:27 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-roll-mpl-parameter-configuration-04 Reviewer: Peter Yee Review Date: Jun-25-2015 IETF LC End Date: Jun-30-2015 IESG Telechat date: Jul-09-2015 Summary: This draft is basically ready for publication as an Internet Standard, but has nits that should be fixed before publication. [Ready with nits.] (I'm discounting the severity of the minor issue mentioned below.) This draft describes a DHCPv6 option used to request MPL configuration parameter sets. Major Issues: None. Minor Issues: Some of the parameters are described with their bit lengths, others are not. Lengths are listed haphazardly. Be consistent in either including them or not. Timer lengths are listed as n-bit integers, but this may be confusing given that the document says "Short floating point format is used to describe the wide range of timer values". So, are the timer values floating point or integer? Is the combined implication supposed to be that the numbers are formatted as floating point (for greater range), but only take on integer values? Given that the values in this document are all given in reference to division by the value of TUNIT, it's possible that values might not be integers. If that happens and only integers are desired, is rounding or truncation preferred? Also note that Appendix A indicates that "short unsigned floating point" was dropped. It's not completely clear if that means that "short [signed?] floating point" was adopted in its stead or whether actual short integers were preferred. Nits: -General: Append a comma after "e.g.". Change things like "8 bit integer" to "8-bit integer" and do similarly for "16 bit integer". -Specific: Page 1, Abstract, 1st sentence: change "of" to "for". Insert "a" before "DHCPv6". Page 1, Abstract, last sentence: change the last "parameter" to "parameters". Page 2, section 1, 1st paragraph, 1st sentence: change "low power" to "low-power". Change "lossy network" to "lossy networks,". (Note the trailing comma after "networks".) Page 2, section 1, 1st paragraph, 3rd sentence: change "parameter" to "parameters". Change "controls" to "control". Insert "the" before "trade-off". Page 2, section 1, 1st paragraph, 6th sentence: insert "the" before "same". Replace the period at the end of the sentence with a comma. Page 2, section 1, 1st paragraph, 7th sentence: change "And" to "but" to join this sentence with the previous one. Page 2, section 1, 2nd paragraph, 2nd sentence: change the first "set" to "sets". Page 2, section 1, 2nd paragraph, 3rd sentence: change "are" to "is". Page 2, section 1, 3rd paragraph, 1st sentence: change "is to define" to "defines". Page 2, section 1, 3rd paragraph, 2nd sentence: change "guideline [RFC7227]" to "[RFC7227] guidelines". Page 3, section 2, 1st paragraph, 1st sentence: insert "the" before "following". Page 3, section 2, last paragraph, last sentence: change "from" to "by". Page 3, section 2.1, 1st paragraph, last sentence: change "floating point" to "floating-point". However, see discussion in Minor Issues regarding the actual format and meaning of these numbers. Page 4, "option_len" and "P" definitions: add a period to the end of each. Page 5, section 2.2, 1st paragraph, 1st sentence: insert "the" before "MPL". Delete the first "RFC3315". Add a comma after "18.1.5". Page 5, section 2.2, 1st paragraph, last sentence: insert "the" before the first "Option". Page 5, section 2.2, 2nd paragraph, 1st sentence: insert "the" before "MPL". Clarify whether the "Unsigned Short Floating Point" discussion should be present here given the note in Appendix A and my discussion in Minor Issues. Page 5, section 2.3, 1st paragraph, 1st sentence: insert "the" before the first "MPL". Page 5, section 2.3, 2nd paragraph: consider changing "Configuration" to "Configurations". Change "for" to "to". Change the period to a colon. Page 5, section 2.3, 1st and 2nd bullet items: change "optlen" to "option_len". Page 6, section 2.3, 1st paragraph: change "a" to "an" before "MPL". Page 6, section 2.3, 2nd paragraph: delete "from". Page 6, section 2.3, 3rd paragraph, 1st sentence: change "parameter" to "parameters". Page 6, section 2.3, 3rd paragraph, last sentence: change "forwarders" to "forwarder". Page 6, section 2.3, 4th paragraph, 1st sentence: change "periodical" to "periodic". Append a comma after "traffic". Insert "a" before "very". Page 6, section 2.3, 4th paragraph, last sentence: change "message" to "messages". Page 6, section 2.4, 1st paragraph, 1st sentence: delete the first "RFC3315". Page 6, section 2.4, 1st paragraph, 2nd sentence: insert "the" before "MPL" in both places in the sentence. Append "it was" after "if". Change "value" to "values". Page 6, section 2.4, 2nd paragraph: insert "an" before "incoming". Page 6, section 2.6, 1st paragraph: change "two times of" to "twice the". Question: does this restriction apply even when the client is using a "very long interval between updates"? Page 6, section 2.6, 2nd paragraph, 1st sentence: insert "an" before the first "MPL". Insert "the" before the second "MPL". Capitalize "configuration". Change "for two times" to "within twice the". Change "time" to "interval". Insert "the" before the fourth "MPL". Page 7, section 4, 2nd sentence: insert "DM_" directly before "K" and "IMIN". Page 7, section 4, last sentence: insert "The" at the beginning of the sentence. Change "authentications" to "authentication". Page 7, Normative References: update the reference for "draft-ietf-roll-trickle-mcast-11" to "draft-ietf-roll-trickle-mcast-12" (June 2015). Page 8, Appendix B, 1st paragraph, last sentence: change "set" to "sets". Page 8, Appendix B, 2nd paragraph, 1st sentence: append "set" after "parameter". Page 8, Appendix B, 2nd paragraph, 2nd sentence: change "it" to "this situation". Consider changing "shall work" to either "should work" or "works" or "will work". Change both occurrences of "set" to "sets". Page 8, Appendix B, 2nd paragraph, last sentence: insert "the" before "motivations". Consider changing "are" to "include". Change "on" to "of the". Insert "the" before "expected". From nobody Thu Jun 25 21:45:50 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-mpl-parameter-configuration.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 727831B2CB2; Thu, 25 Jun 2015 16:20:17 -0700 (PDT) X-Original-To: xfilter-draft-ietf-roll-mpl-parameter-configuration.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-mpl-parameter-configuration.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 449BD1B2CAE for ; Thu, 25 Jun 2015 16:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iudGY8oKL4MI for ; Thu, 25 Jun 2015 16:20:15 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [IPv6:2a01:3f0:0:31::14]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0B5E1B2CA9 for ; Thu, 25 Jun 2015 16:20:15 -0700 (PDT) Received: from p3plsmtpa12-06.prod.phx3.secureserver.net ([68.178.252.235]:50512) by merlot.tools.ietf.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.84) (envelope-from ) id 1Z8GQ2-0005Ts-HP for draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org; Fri, 26 Jun 2015 01:19:54 +0200 Received: from spectre ([173.8.184.78]) by p3plsmtpa12-06.prod.phx3.secureserver.net with id knJS1q0041huGat01nJSHw; Thu, 25 Jun 2015 16:18:26 -0700 From: "Peter Yee" To: References: <01ea01d0af9c$de6319e0$9b294da0$@akayla.com> In-Reply-To: <01ea01d0af9c$de6319e0$9b294da0$@akayla.com> Date: Thu, 25 Jun 2015 16:18:32 -0700 Message-ID: <01eb01d0af9d$40d15010$c273f030$@akayla.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJJAmMUhr19xy2VoHn/tZzhuQEvQJzNNVxA Content-Language: en-us X-SA-Exim-Connect-IP: 68.178.252.235 X-SA-Exim-Rcpt-To: draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org X-SA-Exim-Mail-From: peter@akayla.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:57:07 +0000) X-SA-Exim-Scanned: Yes (on merlot.tools.ietf.org) Resent-To: draft-ietf-roll-mpl-parameter-configuration.all@ietf.org Resent-Message-Id: <20150625232015.B0B5E1B2CA9@ietfa.amsl.com> Resent-Date: Thu, 25 Jun 2015 16:20:15 -0700 (PDT) Resent-From: peter@akayla.com Archived-At: Archived-At: X-Mailman-Approved-At: Thu, 25 Jun 2015 21:45:45 -0700 Cc: gen-art@ietf.org, ietf@ietf.org Subject: Re: [Roll] [Gen-art] Gen-ART LC review for draft-ietf-roll-mpl-parameter-configuration-04 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 23:20:17 -0000 I suppose I should really phrase that as "a Standards Track RFC". It's not old enough to jump directly to "Internet Standard". ;-) -Peter -----Original Message----- From: Gen-art [mailto:gen-art-bounces@ietf.org] On Behalf Of Peter Yee Sent: Thursday, June 25, 2015 4:16 PM To: draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org Cc: gen-art@ietf.org; ietf@ietf.org Subject: [Gen-art] Gen-ART LC review for draft-ietf-roll-mpl-parameter-configuration-04 Summary: This draft is basically ready for publication as an Internet Standard, but has nits that should be fixed before publication. [Ready with nits.] (I'm discounting the severity of the minor issue mentioned below.) From nobody Sat Jun 27 00:18:13 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDAD1B3164 for ; Sat, 27 Jun 2015 00:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6i3FifjJr1d for ; Sat, 27 Jun 2015 00:18:09 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 507281B2F9F for ; Sat, 27 Jun 2015 00:18:09 -0700 (PDT) Received: by laar3 with SMTP id r3so15679749laa.0 for ; Sat, 27 Jun 2015 00:18:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=uedBYXwW82zfh/gNRQEd4GTdFBIaWYBRbCmGUWUXJSQ=; b=Ity+CTqaN2m9u6SBRrrxpyTGthNgPZVaJpnFl5unszzorK4ymBzaTsDMZgQ8nZ5BNw oaRaU1MFqjbwn8ZB1sP5disMFKl2njOFGnNeDnPCXrhtLS2rM+1QxibAl86TwOXDF5N2 sCsOd4RlfGRytg7nd9OU/+H/70A7oPL7q+Y0FI2/GS5HbXIlWYa0pTFh8CSweUxiFlQu MsufBDOnximDXJ8IvGaJQ+8qfLVHuVAxfDlW7s6SL+2ifise8iX6TBLBx5dBLOwz2/oo OkQIcXLysLE5AKYTGkLz/lLlkqB6rhqQLi4BxqAAbn9Lo7yv+VYuW1ltDdJTSNJq/pO/ K0HA== MIME-Version: 1.0 X-Received: by 10.152.1.4 with SMTP id 4mr4983401lai.25.1435389487698; Sat, 27 Jun 2015 00:18:07 -0700 (PDT) Received: by 10.25.208.70 with HTTP; Sat, 27 Jun 2015 00:18:07 -0700 (PDT) Date: Sat, 27 Jun 2015 10:18:07 +0300 Message-ID: From: Ines Robles To: roll Content-Type: multipart/alternative; boundary=089e013c66a88758c305197aa883 Archived-At: Cc: Michael Richardson Subject: [Roll] I-D When to use RFC 6553, 6554 and IPv6-in-IPv6- X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2015 07:18:11 -0000 --089e013c66a88758c305197aa883 Content-Type: text/plain; charset=UTF-8 Dear all, Please find a draft related to our work item: "- Details about when to use RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation." We are requesting for comments and for additional authors. Thank you very much in advance, Michael and Ines. -------- Forwarded Message -------- Subject: New Version Notification for draft-robles-roll-useofrplinfo-00.txtDate: Sat, 27 Jun 2015 00:09:29 -0700From: internet-drafts@ietf.orgTo: Ines Robles , Michael C. Richardson , Maria Ines Robles < maria.ines.robles@ericsson.com>, Michael Richardson A new version of I-D, draft-robles-roll-useofrplinfo-00.txt has been successfully submitted by Maria Ines Robles and posted to the IETF repository. Name: draft-robles-roll-useofrplinfo Revision: 00 Title: When to use RFC 6553, 6554 and IPv6-in-IPv6 Document date: 2015-06-27 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-robles-roll-useofrplinfo-00.txt Status: https://datatracker.ietf.org/doc/draft-robles-roll-useofrplinfo/ Htmlized: https://tools.ietf.org/html/draft-robles-roll-useofrplinfo-00 Abstract: This document states different cases where RFC 6553, RFC 6554 and IPv6-in-IPv6 encapsulation is required to set the bases to help defining the compression of RPL routing information in LLN environments. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --089e013c66a88758c305197aa883 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Dear all,

    Please find a draf= t related to our work item:

    "- Details about = when to use RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation."

    We are requesting for comments and for additional authors= .

    Thank you very much in advance,

    Michael and Ines.



    -------- Forwarded Message -------- New Version Notification for draft-robles-roll-useofrplinfo-00.txt
    Subject:
    Date: Sat, 27= Jun 2015 00:09:29 -0700
    From: intern= et-drafts@ietf.org
    To: Ines Robles <maria.ines.ro= bles@ericsson.com>, Michael C. Richardson=20 <mcr+ietf@sandelman.ca>= ;, Maria Ines Robles=20 <maria.ines.robles@eri= csson.com>, Michael Richardson=20 <mcr+ietf@sandelman.ca>= ;
     


    A new version of I-D, draft-robles-roll-useofrplinfo-00.txt
has been successfully submitted by Maria Ines Robles and posted to the
IETF repository.

Name:		draft-robles-roll-useofrplinfo
Revision:	00
Title:		When to use RFC 6553, 6554 and IPv6-in-IPv6
Document date:	2015-06-27
Group:		Individual Submission
Pages:		9
URL:            https://www.ietf.org/internet-drafts/draft-robl=
es-roll-useofrplinfo-00.txt
Status:         https://datatracker.ietf.org/doc/draft-robles-roll-useofr=
plinfo/
Htmlized:       https://tools.ietf.org/html/draft-robles-roll-useofrplinfo-0=
0


Abstract:
   This document states different cases where RFC 6553, RFC 6554 and
   IPv6-in-IPv6 encapsulation is required to set the bases to help
   defining the compression of RPL routing information in LLN
   environments.

                                                                           =
      =20


Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

    --089e013c66a88758c305197aa883-- From nobody Sat Jun 27 02:47:13 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293251B3322; Sat, 27 Jun 2015 02:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MY4y9CRh2dVL; Sat, 27 Jun 2015 02:47:08 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2235E1B331F; Sat, 27 Jun 2015 02:47:08 -0700 (PDT) Received: by wgjx7 with SMTP id x7so32224361wgj.2; Sat, 27 Jun 2015 02:47:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=Suos764IX40JKY5QtGn7pXnFlZzMYFabPLcJ25jz2tU=; b=BfRHcXoQ8/7POkojWnstelMzJFCstyVrsXs1JMMATL9pj2gJ7WF1lkxQ8SkeZi3mhu tFQmplkClo3Kta6Vu3+o+gPVa37WSzAItntqyojUGH+WjsH8tzE/jCfUw4UNZ4hzu0WL k5l0DxracHfw0WgLGGEBoffpQjH2cTrxIYalY7abGn3tggAKgtTb/04kc0o8CuUcfNSs AqJUHFbs3armVfiNkCy27ZeU7T/TqQIrYMY3dKC/gtUs3NOKLtAjg++YicC1sgSHWKS9 yT9ELCnpcSo/e7/f0TbJ02VTqEonp5ao5mLtn/upXrWFRoL8uo8U5pfFr7U/j4dI2MQb 4Iqg== X-Received: by 10.194.234.40 with SMTP id ub8mr10819354wjc.21.1435398426722; Sat, 27 Jun 2015 02:47:06 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.28.134.146 with HTTP; Sat, 27 Jun 2015 02:46:47 -0700 (PDT) In-Reply-To: References: From: Thomas Watteyne Date: Sat, 27 Jun 2015 11:46:47 +0200 X-Google-Sender-Auth: aqPH0i44O66NC9DrHVPtngN_aMU Message-ID: To: Routing Over Low power and Lossy networks , "6tisch@ietf.org" <6tisch@ietf.org> Content-Type: multipart/alternative; boundary=089e01493c7c560a2905197cbd1c Archived-At: Subject: Re: [Roll] I-D When to use RFC 6553, 6554 and IPv6-in-IPv6- X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2015 09:47:10 -0000 --089e01493c7c560a2905197cbd1c Content-Type: text/plain; charset=UTF-8 Ines, Great to see this I-D exists! CC'ing the 6TISCH ML, as these questions have been discussed extensively there as well. We will verify that the rules you describe as followed in draft-ietf-6tisch-minimal and in the test specifications for the upcoming 6TiSCH plugtest. Give us a couple of days to review and provide feedback. Thomas On Sat, Jun 27, 2015 at 9:18 AM, Ines Robles wrote: > Dear all, > > Please find a draft related to our work item: > > "- Details about when to use RFC6553, RFC6554, and IPv6-in-IPv6 > encapsulation." > > We are requesting for comments and for additional authors. > > Thank you very much in advance, > > Michael and Ines. > > > > -------- Forwarded Message -------- Subject: New Version Notification for > draft-robles-roll-useofrplinfo-00.txtDate: Sat, 27 Jun 2015 00:09:29 -0700From: > internet-drafts@ietf.orgTo: Ines Robles , > Michael C. Richardson , Maria Ines Robles < > maria.ines.robles@ericsson.com>, Michael Richardson > > > A new version of I-D, draft-robles-roll-useofrplinfo-00.txt > has been successfully submitted by Maria Ines Robles and posted to the > IETF repository. > > Name: draft-robles-roll-useofrplinfo > Revision: 00 > Title: When to use RFC 6553, 6554 and IPv6-in-IPv6 > Document date: 2015-06-27 > Group: Individual Submission > Pages: 9 > URL: https://www.ietf.org/internet-drafts/draft-robles-roll-useofrplinfo-00.txt > Status: https://datatracker.ietf.org/doc/draft-robles-roll-useofrplinfo/ > Htmlized: https://tools.ietf.org/html/draft-robles-roll-useofrplinfo-00 > > > Abstract: > This document states different cases where RFC 6553, RFC 6554 and > IPv6-in-IPv6 encapsulation is required to set the bases to help > defining the compression of RPL routing information in LLN > environments. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --089e01493c7c560a2905197cbd1c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Ines,

    Great to see this I-D exists!

    CC'ing the 6TISCH ML, as these questions have bee= n discussed extensively there as well.
    We will verify that the ru= les you describe as followed in=C2=A0draft-ietf-6tisch-minimal and in the t= est specifications for the upcoming 6TiSCH plugtest.
    Give us a co= uple of days to review and provide feedback.

    Thoma= s

    On S= at, Jun 27, 2015 at 9:18 AM, Ines Robles <mariainesrobles@go= oglemail.com> wrote:
    Dear all,

    Please find a draft rela= ted to our work item:

    "- Details about when t= o use RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation."
    We are requesting for comments and for additional authors.

    Thank you very much in advance,

    Michael and Ines.



    -------- Forwarded Message -------- New Version Notification for draft-robles-roll-useofrplinfo-00.txt
    Subject:
    Date: Sat, 27= Jun 2015 00:09:29 -0700
    From: internet-drafts@ietf.org
    To: Ines Robles <maria.ines.robles@ericsson.com>, Michael C. Richardson=20 <mcr+ietf@s= andelman.ca>, Maria Ines Robles=20 <mar= ia.ines.robles@ericsson.com>, Michael Richardson=20 <mcr+ietf@s= andelman.ca>
     


    A new version of I-D, draft-robles-roll-useofrplinfo-00.txt
has been successfully submitted by Maria Ines Robles and posted to the
IETF repository.

Name:		draft-robles-roll-useofrplinfo
Revision:	00
Title:		When to use RFC 6553, 6554 and IPv6-in-IPv6
Document date:	2015-06-27
Group:		Individual Submission
Pages:		9
URL:            https://www.ietf.org/internet=
-drafts/draft-robles-roll-useofrplinfo-00.txt
Status:         https://datatracker.ietf.org/doc/draft-=
robles-roll-useofrplinfo/
Htmlized:       https://tools.ietf.org/html/draft-robles-r=
oll-useofrplinfo-00


Abstract:
   This document states different cases where RFC 6553, RFC 6554 and
   IPv6-in-IPv6 encapsulation is required to set the bases to help
   defining the compression of RPL routing information in LLN
   environments.

                                                                           =
      =20


Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


    _______________________________________________
    Roll mailing list
    Roll@ietf.org
    https://www.ietf.org/mailman/listinfo/roll


    --089e01493c7c560a2905197cbd1c-- From nobody Sat Jun 27 03:52:41 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15611AC3CB; Sat, 27 Jun 2015 03:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kG-RLv1cLcHp; Sat, 27 Jun 2015 03:52:34 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928CA1A8AC4; Sat, 27 Jun 2015 03:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t5RAqRxF024645; Sat, 27 Jun 2015 12:52:27 +0200 (CEST) Received: from alma.local (p5DC7EA60.dip0.t-ipconnect.de [93.199.234.96]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3mJX3G5xcsz9904; Sat, 27 Jun 2015 12:52:26 +0200 (CEST) Message-ID: <558E8068.1080705@tzi.org> Date: Sat, 27 Jun 2015 12:52:24 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: Routing Over Low power and Lossy networks , 6lo@ietf.org, lwip@ietf.org, 6tisch@ietf.org X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Roll] Constrained Node/Network Cluster @ IETF93, "final" version X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2015 10:52:37 -0000 Below is the "final" version of the eclectic IoT agenda (I have filled in the T2TRG Sat/Sun meeting, which is waiting for its room assignment). Again, there is still some potential for changes. Apart from a dozen room changes, the main difference from the early version is that the second 6lo and 6tisch meetings were swapped. Grüße, Carsten Carsten Bormann wrote: > A first draft version of the IETF93 agenda is out. > ** THIS IS GOING TO CHANGE ** for conflict resolution, > so please don't make travel arrangements based on it. > > Here is my usual eclectic condensed agenda built from that. > (Bye, bye, appsawg. lwig over roll is interesting; at least we do > have a roll meeting at all.) > Note that the t2trg meeting on Monday is a "summary" meeting for those > who haven't been able to join during the weekend (conflicts with > Hackathon, ICNRG, etc.) > > All times are CEST (UTC+0200) (the browser timezone function appears > to have vanished from https://datatracker.ietf.org/meeting/agenda-utc, > but maybe we can reinstate that for those who want to listen from > remote). > > Sorry for the duplicate posting, the IETF mail system does not allow > sending to all 9 mailing lists at the same time. SATURDAY, July 18, 2015 1000-1800 Session I (TBD) IRTF*** t2trg Proposed Thing-to-thing Research Group 0900-2100 IETF Hackathon - Chez Louis SUNDAY, July 19, 2015 0900-1600 Session II (TBD) IRTF*** t2trg Proposed Thing-to-thing Research Group 0900-1800 IETF Hackathon - Chez Louis 1600-1700 Newcomers' Meet and Greet (open to Newcomers and WG chairs only) - Garden Terrace 1700-1900 Welcome Reception - Grand Hilton Ballroom MONDAY, July 20, 2015 0900-1130 Morning Session I Grand Hilton BR ART appsawg ART Area General Applications Working Group WG Karlin I/II OPS anima Autonomic Networking Integrated Model and Approach WG Berlin/Brussels SEC *** cose CBOR Object Signing and Encryption WG - 10:00 - 11:30 Congress H II TSV rmcat RTP Media Congestion Avoidance Techniques WG 1300-1500 Afternoon Session I Congress H III INT 6man IPv6 Maintenance WG Grand Hilton BR RTG detnet Deterministic Networking BOF 1520-1720 Afternoon Session II Berlin/Brussels IRTF*** t2trg Proposed Thing-to-Thing Research Group Congress H III TSV tcpinc TCP Increased Security WG 1740-1840 Afternoon Session III Congress H II INT *** 6lo IPv6 over Networks of Resource-constrained Nodes WG Congress H I OPS opsarea Operations & Management Area Open Meeting Karlin I/II SEC httpauth Hypertext Transfer Protocol Authentication WG 1850-1950 Afternoon Session IV Congress H III INT intarea Internet Area Working Group WG TUESDAY, July 21, 2015 1300-1500 Afternoon Session I Congress H I ART httpbis Hypertext Transfer Protocol WG Athens/Barcel. INT *** 6tisch IPv6 over the TSCH mode of IEEE 802.15.4e WG Congress H II OPS v6ops IPv6 Operations WG - Joint Session with SUNSET4 1520-1720 Afternoon Session II Karlin I/II ART *** core Constrained RESTful Environments WG Congress H II RTG rtgarea Routing Area Open Meeting Congress H III SEC tls Transport Layer Security WG 1740-1840 Afternoon Session III Congress H III ART uta Using TLS in Applications WG Berlin/Brussels INT *** lwig Light-Weight Implementation Guidance WG Congress H I RTG *** roll Routing Over Low power and Lossy networks WG WEDNESDAY, July 22, 2015 0900-1130 Morning Session I Athens/Barcel. INT dnssd Extensions for Scalable DNS Service Discovery WG Karlin I/II SEC *** ace Authentication and Authorization for Constrained Environments WG Grand Hilton BR SEC tls Transport Layer Security WG 1300-1530 Afternoon Session I Grand Hilton BR INT homenet Home Networking WG Berlin/Brussels RTG bier Bit Indexed Explicit Replication WG 1740-1940 Afternoon Session III Athens/Barcel. SEC oauth Web Authorization Protocol WG Congress H III TSV tsvwg Transport Area Working Group WG THURSDAY, July 23, 2015 1300-1500 Afternoon Session I Congress H II SEC saag Security Area Open Meeting Karlin I/II TSV taps Transport Services WG 1520-1720 Afternoon Session II Congress H I INT *** 6lo IPv6 over Networks of Resource-constrained Nodes WG Congress H III SEC acme Automated Certificate Management Environment WG Karlin I/II TSV tsvwg Transport Area Working Group WG 1740-1910 Afternoon Session III Karlin I/II ART webpush Web-Based Push Notifications WG Congress H I OPS anima Autonomic Networking Integrated Model and Approach WG Grand Hilton BR TSV tsvarea Transport Area Open Meeting FRIDAY, July 24, 2015 0900-1130 Morning Session I Grand Hilton BR OPS v6ops IPv6 Operations WG - Joint Session with SUNSET4 Congress H I SEC openpgp Open Specification for Pretty Good Privacy WG 1150-1320 Afternoon Session I Karlin I/II ART *** core Constrained RESTful Environments WG Congress H I SEC tokbind Token Binding WG From nobody Sun Jun 28 03:21:26 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1C71A21B8; Sun, 28 Jun 2015 03:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CopwnJm_g8r2; Sun, 28 Jun 2015 03:21:22 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62A0C1A0545; Sun, 28 Jun 2015 03:21:20 -0700 (PDT) Received: by lacny3 with SMTP id ny3so96401366lac.3; Sun, 28 Jun 2015 03:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F4svrnMqY8FAQBMe+TunhjtLzxPbT5VQDTla1bVfXRc=; b=SJ+jLOgI6Wm0ZmAt5fh1F3Vjew4ed3o5U2SD3vxk/DH7IP95YL2okBUc4zsapsADqT +l2Hid2NHNgc86CV1xUjeAUTXkEVHji+WOE/RALwzKUYFVDLBKhjbzpbQ3yFhvSmEb0R hCknpM/Qwj2NspHOQIfDSgxADlFqVx1Vh61d18GYmyAtP9nDCZsMDYmgn3bsFFC/uxl1 IvOpNX7Z1ze3fZj+67AsJuI0tCgXTF4tqWbFj2Jdx6SlcfzD9U/dsTbUPsP+qouqzYWX hOz5jTtAqE2cuLvXB7inB/LpSMppPTBnBycaoZCa/9cLUNCdTsfnT/YKxDQS3LAA9jr1 kEOw== MIME-Version: 1.0 X-Received: by 10.152.9.5 with SMTP id v5mr9140011laa.111.1435486878824; Sun, 28 Jun 2015 03:21:18 -0700 (PDT) Received: by 10.25.208.70 with HTTP; Sun, 28 Jun 2015 03:21:18 -0700 (PDT) In-Reply-To: References: Date: Sun, 28 Jun 2015 13:21:18 +0300 Message-ID: From: Ines Robles To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=089e014944f67dfefe05199155bd Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [Roll] I-D When to use RFC 6553, 6554 and IPv6-in-IPv6- X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2015 10:21:24 -0000 --089e014944f67dfefe05199155bd Content-Type: text/plain; charset=UTF-8 Great! Thanks a lot :-) On 27 Jun 2015 12:47, "Thomas Watteyne" wrote: > Ines, > > Great to see this I-D exists! > > CC'ing the 6TISCH ML, as these questions have been discussed extensively > there as well. > We will verify that the rules you describe as followed > in draft-ietf-6tisch-minimal and in the test specifications for the > upcoming 6TiSCH plugtest. > Give us a couple of days to review and provide feedback. > > Thomas > > On Sat, Jun 27, 2015 at 9:18 AM, Ines Robles < > mariainesrobles@googlemail.com> wrote: > >> Dear all, >> >> Please find a draft related to our work item: >> >> "- Details about when to use RFC6553, RFC6554, and IPv6-in-IPv6 >> encapsulation." >> >> We are requesting for comments and for additional authors. >> >> Thank you very much in advance, >> >> Michael and Ines. >> >> >> >> -------- Forwarded Message -------- Subject: New Version Notification >> for draft-robles-roll-useofrplinfo-00.txtDate: Sat, 27 Jun 2015 00:09:29 >> -0700From: internet-drafts@ietf.orgTo: Ines Robles < >> maria.ines.robles@ericsson.com>, Michael C. Richardson < >> mcr+ietf@sandelman.ca>, Maria Ines Robles , >> Michael Richardson >> >> A new version of I-D, draft-robles-roll-useofrplinfo-00.txt >> has been successfully submitted by Maria Ines Robles and posted to the >> IETF repository. >> >> Name: draft-robles-roll-useofrplinfo >> Revision: 00 >> Title: When to use RFC 6553, 6554 and IPv6-in-IPv6 >> Document date: 2015-06-27 >> Group: Individual Submission >> Pages: 9 >> URL: https://www.ietf.org/internet-drafts/draft-robles-roll-useofrplinfo-00.txt >> Status: https://datatracker.ietf.org/doc/draft-robles-roll-useofrplinfo/ >> Htmlized: https://tools.ietf.org/html/draft-robles-roll-useofrplinfo-00 >> >> >> Abstract: >> This document states different cases where RFC 6553, RFC 6554 and >> IPv6-in-IPv6 encapsulation is required to set the bases to help >> defining the compression of RPL routing information in LLN >> environments. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --089e014944f67dfefe05199155bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Great! Thanks a lot :-)

    On 27 Jun 201= 5 12:47, "Thomas Watteyne" <watteyne@eecs.berkeley.edu> wrote:
    Ines,<= div>
    Great to see this I-D exists!

    C= C'ing the 6TISCH ML, as these questions have been discussed extensively= there as well.
    We will verify that the rules you describe as fol= lowed in=C2=A0draft-ietf-6tisch-minimal and in the test specifications for = the upcoming 6TiSCH plugtest.
    Give us a couple of days to review = and provide feedback.

    Thomas

    On Sat, Jun 27, 2015 at 9:1= 8 AM, Ines Robles <mariainesrobles@googlemail.com> wrote:
    Dear al= l,

    Please find a draft related to our work item:

    "- Details about when to use RFC6553, RFC6554,= and IPv6-in-IPv6 encapsulation."

    We are requ= esting for comments and for additional authors.

    Th= ank you very much in advance,

    Michael and Ines.



    -------- Forwarded Message -------- New Version Notification for draft-robles-roll-useofrplinfo-00.txt
    Subject:
    Date: Sat, 27= Jun 2015 00:09:29 -0700
    From: internet-drafts@ietf.org
    To: Ines Robles <maria.ines.robles@ericsson.com>, Michael C. Richardson=20 <mcr+ietf@s= andelman.ca>, Maria Ines Robles=20 <mar= ia.ines.robles@ericsson.com>, Michael Richardson=20 <mcr+ietf@s= andelman.ca>
     


    A new version of I-D, draft-robles-roll-useofrplinfo-00.txt
has been successfully submitted by Maria Ines Robles and posted to the
IETF repository.

Name:		draft-robles-roll-useofrplinfo
Revision:	00
Title:		When to use RFC 6553, 6554 and IPv6-in-IPv6
Document date:	2015-06-27
Group:		Individual Submission
Pages:		9
URL:            https://www.ietf.org/internet=
-drafts/draft-robles-roll-useofrplinfo-00.txt
Status:         https://datatracker.ietf.org/doc/draft-=
robles-roll-useofrplinfo/
Htmlized:       https://tools.ietf.org/html/draft-robles-r=
oll-useofrplinfo-00


Abstract:
   This document states different cases where RFC 6553, RFC 6554 and
   IPv6-in-IPv6 encapsulation is required to set the bases to help
   defining the compression of RPL routing information in LLN
   environments.

                                                                           =
      =20


Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


    _______________________________________________
    Roll mailing list
    Roll@ietf.org
    https://www.ietf.org/mailman/listinfo/roll



    _______________________________________________
    Roll mailing list
    Roll@ietf.org
    https://www.ietf.org/mailman/listinfo/roll

    --089e014944f67dfefe05199155bd-- From nobody Mon Jun 29 09:22:59 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8276D1AD0D7; Mon, 29 Jun 2015 09:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2Q8H037PjfA; Mon, 29 Jun 2015 09:22:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFFB1AD0CD; Mon, 29 Jun 2015 09:22:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150629162255.28006.44010.idtracker@ietfa.amsl.com> Date: Mon, 29 Jun 2015 09:22:55 -0700 Archived-At: Cc: roll-chairs@ietf.org, draft-ietf-roll-trickle-mcast@ietf.org, roll@ietf.org Subject: [Roll] Stephen Farrell's No Objection on draft-ietf-roll-trickle-mcast-12: (with COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 16:22:56 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-roll-trickle-mcast-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for adding the new text saying that this shouldn't be used if those authorised to access the n/w can be a source of attacks. I think you could improve the way you say that though, it'd be better to s/attack vector/threat model/ in both the intro and in the security considerations. But that's really a nit and is ok to fix (or not) at AUTH-48 IMO. From nobody Mon Jun 29 12:55:54 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323231B32C8; Mon, 29 Jun 2015 12:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AcWtdZibqs4; Mon, 29 Jun 2015 12:55:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCBF1B32D1; Mon, 29 Jun 2015 12:55:25 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150629195525.27173.90612.idtracker@ietfa.amsl.com> Date: Mon, 29 Jun 2015 12:55:25 -0700 Archived-At: Cc: roll mailing list , roll chair , RFC Editor Subject: [Roll] Protocol Action: 'Multicast Protocol for Low power and Lossy Networks (MPL)' to Proposed Standard (draft-ietf-roll-trickle-mcast-12.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 19:55:50 -0000 The IESG has approved the following document: - 'Multicast Protocol for Low power and Lossy Networks (MPL)' (draft-ietf-roll-trickle-mcast-12.txt) as Proposed Standard This document is the product of the Routing Over Low power and Lossy networks Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast/ Technical Summary This document specifies the Multicast Protocol for Low power and Lossy Networks (MPL) that provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating messages to all MPL Forwarders in an MPL Domain. MPL uses the Trickle algorithm to manage message transmissions for both control and data-plane messages. Different Trickle parameter configurations allow MPL to trade between dissemination latency and transmission efficiency. Working Group Summary This document had a somewhat lumpy late stage process. It was submitted for AD review and IETF last call was started, but then a significant issue was spotted, last call was abandoned, and the document was sent back to the working group. After discussion and work a new revision was now presented with working group consensus. IETF last call raised a few small issues that were worked on the WG mailing list. It also produced an extensive review that was sent privately to the AD with a request that it remain private. This review took considerable effort to managed and close down. Note that early allocation of a codepoint was made to enable reference to this work by the ZigBee Alliance. Please note the IANA Note, below, for additional comments about early allocation. Document Quality There are existing implementations of this specification. Personnel Ines Robles is the Document Shepherd. Alvaro Retana is the Responsible Area Director. IANA Note Please note that an early allocation was made from the "Destination Options and Hop-by-Hop Options" registry in accordance with Section 13.1 of this I-D. However, the value requested in this I-D is different from the one allocated. Currently allocated 0x4D 01 0 01101 Trickle Multicast Option [draft-ietf-roll-trickle-mcast] To be allocated 0x6D 01 1 01101 MPL Option [draft-ietf-roll-trickle-mcast] The value 0x4D is no longer required for this document, however, it is suggested that IANA will want to mark 0x4D so that it cannot be re-allocated. --- Please also note that IANA has made an early allocation for the IPv6 multicast address as requested in Section 13.3 of this I-D. The value allocated can stand. From nobody Mon Jun 29 23:46:49 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89EE41B3704 for ; Mon, 29 Jun 2015 23:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCr_9Fnd52NP for ; Mon, 29 Jun 2015 23:46:46 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 118E61B36FE for ; Mon, 29 Jun 2015 23:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2226; q=dns/txt; s=iport; t=1435646806; x=1436856406; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=YUbK7viL28lePWxQjAmSG1d4plWwWnESdt52JbnbW0c=; b=Gyyvr2c5+F7u5IKEYWnuNh6GxhOVtM9i4XknTQBmaWFsDRhc/pACwQol D809Ogc/ai7pApjwZOK7RVaRv25v0Cwb/tK073Go44CgJpLg8IRc3slQh aMgX8xSHAZWLOVK6jkgtODyLhjHOTwrmESc02hM0YnomUiKmD+jHnyR5Y E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DVAwB8OpJV/5pdJa1bgxFUXwaDGLoTCYFphXYCHIEgOBQBAQEBAQEBgQqEIgEBAQQjEUMOBAIBCBEEAQEDAgYdAwICAjAUAQYBAQUDAgQTCIgnDbNJlnkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGKKYQtKDgGgmIvgRQFjBKHcgGEWIZ9gTlCg0+ScCaDem8BgQJDgQIBAQE X-IronPort-AV: E=Sophos;i="5.15,375,1432598400"; d="scan'208";a="164015652" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP; 30 Jun 2015 06:46:45 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t5U6kjkk025882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 30 Jun 2015 06:46:45 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.76]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Tue, 30 Jun 2015 01:46:45 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: New Version Notification for draft-thubert-dao-projection-00.txt Thread-Index: AQHQsv8cXxMN1L+rpk+SkMbcXTb8x53Emi/g Date: Tue, 30 Jun 2015 06:46:44 +0000 Deferred-Delivery: Tue, 30 Jun 2015 06:46:16 +0000 Message-ID: References: <20150630063630.9499.53083.idtracker@ietfa.amsl.com> In-Reply-To: <20150630063630.9499.53083.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.97.24] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Roll] FW: New Version Notification for draft-thubert-dao-projection-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 06:46:47 -0000 RGVhciBhbGw6DQoNClBsZWFzZSBub3RlIHRoYXQgd2UgcHVibGlzaGVkIGEgbmV3IGRyYWZ0IHRo YXQgc3VnZ2VzdHMgdGhhdCB0aGUgcm9vdCBjb3VsZCBpbnN0YWxsIG9wcG9ydHVuaXN0aWNhbGx5 IHNvbWUgc3RvcmluZy1tb2RlLWxpa2Ugc3RhdGUgaW4gbm9uLXN0b3JpbmcgbW9kZSwgc28gYXMg dG8gZW5hYmxlIHBpbi1wb2ludGVkIG9wdGltaXphdGlvbiBieSBsb29zZSBzb3VyY2Ugcm91dGlu Zy4NCg0KQ2hlZXJzLA0KDQpQYXNjYWwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZ10gDQpTZW50OiBtYXJkaSAzMCBqdWluIDIwMTUgMDg6MzcNClRvOiBKYW1lcyBQeWxha3V0 dHkgKG11bmRlbm1hKTsgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KTsgUGFzY2FsIFRodWJlcnQg KHB0aHViZXJ0KTsgSmFtZXMgUHlsYWt1dHR5IChtdW5kZW5tYSkNClN1YmplY3Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdGh1YmVydC1kYW8tcHJvamVjdGlvbi0wMC50eHQN Cg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdGh1YmVydC1kYW8tcHJvamVjdGlvbi0w MC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUGFzY2FsIFRodWJlcnQg YW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtdGh1YmVy dC1kYW8tcHJvamVjdGlvbg0KUmV2aXNpb246CTAwDQpUaXRsZToJCVJvb3QgaW5pdGlhdGVkIHJv dXRpbmcgc3RhdGUgaW4gUlBMDQpEb2N1bWVudCBkYXRlOgkyMDE1LTA2LTI5DQpHcm91cDoJCUlu ZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxMQ0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC10aHViZXJ0LWRhby1wcm9qZWN0aW9u LTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LXRodWJlcnQtZGFvLXByb2plY3Rpb24vDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRodWJlcnQtZGFvLXByb2plY3Rpb24tMDANCg0KDQpB YnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgYSByb290LWluaXRpYXRlZCBwcm90 b2NvbCBleHRlbnNpb24gdG8gUlBMDQogICB0aGF0IGVuYWJsZXMgdG8gaW5zdGFsbCBhIGxpbWl0 ZWQgYW1vdW50IG9mIGRvd253YXJkIHJvdXRlcyBpbiBub24tDQogICBzdG9yaW5nIG1vZGUuICBU aGlzIGVuYWJsZXMgbG9vc2Ugc291cmNlIHJvdXRpbmcgZG93biB0aGUgRE9EQUcuDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu DQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Tue Jun 30 00:08:39 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 084A11B36F6; Tue, 30 Jun 2015 00:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FD10750rh0di; Tue, 30 Jun 2015 00:08:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EF91B36D1; Tue, 30 Jun 2015 00:08:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: , , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150630070837.28847.73210.idtracker@ietfa.amsl.com> Date: Tue, 30 Jun 2015 00:08:37 -0700 Archived-At: Cc: iesg-secretary@ietf.org Subject: [Roll] Last Call Expired: X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 07:08:39 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ IETF Last Call has ended, and the state has been changed to Waiting for Writeup. From nobody Tue Jun 30 00:11:45 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8651AD1BA for ; Tue, 30 Jun 2015 00:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.023 X-Spam-Level: X-Spam-Status: No, score=0.023 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1nRp9gfBA2Q for ; Tue, 30 Jun 2015 00:11:42 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E73A1B354F for ; Tue, 30 Jun 2015 00:11:42 -0700 (PDT) Received: by lagc2 with SMTP id c2so1547056lag.3 for ; Tue, 30 Jun 2015 00:11:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=jdrXSQxojxlevMorcVdTb2P59awoGnAwznoKOIf5Iso=; b=Offuca9SCJ1pFrtxuAb8gAcc5Z61awk+epcyExY0DDMKs/XNiiVnYRv8GCM+9+LVGj Lbj4qT2oeXDDU6jml6AstWLm0FZTnWir9bFJJa1v5ccWVBJLB9gDb+8Wy1tuNiRYU6IN KertpDxt+BS8unkJUKMDbsdTliBfTdvE9qTvfgTc6s8FC6GYW4oVTOvunFKWg0QRK1QT aMRlYsdSPZk1hhnxdgOcQEGlTUVLqotV3eOl8SbjGhN8rjdOZNXxlUvFK3jTBOLYSvBe LgKzdEFnhMpYOWx26CoYQ3YIoBg4Bu1ZzPiMH0mWriwc6t4CKhopzl+AVyng4VG5/hGI cWDQ== MIME-Version: 1.0 X-Received: by 10.152.234.42 with SMTP id ub10mr17772743lac.60.1435648300660; Tue, 30 Jun 2015 00:11:40 -0700 (PDT) Received: by 10.25.208.70 with HTTP; Tue, 30 Jun 2015 00:11:40 -0700 (PDT) Date: Tue, 30 Jun 2015 10:11:40 +0300 Message-ID: From: Ines Robles To: roll Content-Type: multipart/alternative; boundary=001a113438a0fbbfdb0519b6ea35 Archived-At: Cc: Michael Richardson Subject: [Roll] IETF 93 - Call For Drafts X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 07:11:43 -0000 --001a113438a0fbbfdb0519b6ea35 Content-Type: text/plain; charset=UTF-8 Dear all, ROLL is going to have a meeting in IETF 93. We would like to know please which topics do you want to present in the IETF This CFD has deadline: 5th July. Thank you very much, Michael and Ines. --001a113438a0fbbfdb0519b6ea35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Dear all,

    ROLL is going to have a meeti= ng in IETF 93.

    We would like to know please which = topics do you want to present in the IETF=C2=A0

    Th= is CFD has deadline: 5th July.

    Thank you very much= ,

    Michael and Ines.
    --001a113438a0fbbfdb0519b6ea35-- From nobody Tue Jun 30 10:05:29 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC351B31EB; Tue, 30 Jun 2015 10:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CriMKA8q5zN6; Tue, 30 Jun 2015 10:05:10 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DC901B321B; Tue, 30 Jun 2015 10:05:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2834; q=dns/txt; s=iport; t=1435683911; x=1436893511; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=GCQBFZ49UvA224XU1ju0Er8CAsrsmbIaCr+VBbj68v0=; b=iGZrCTmLVs4OYKT4zu3zCxu2lt03HJ+SS8+cA9sFg2MYktWIxFZMkDBb K3C3o8L+Bu9sJ+MgOpf+y2MBXUE4qpp4hfZazRH+64hyx/e4U19EitHTp LqeDex9wxezkq21BtKjzfA0OueJHVcTFhJf9HI0gZ2xBG8zuYXYsUyDtu c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D1AwDRy5JV/5RdJa1bgxFUXwaDGLolCYFthXYCHIE1OBQBAQEBAQEBgQqEIgEBAQQjEUMOBAIBCBEEAQEDAgYdAwICAjAUAQYBAQUDAgQBEgiIJw2xU5cEAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiimEVTgGgmIvgRQBBIwUh3MBhFmGfoE5RINOknEmg3pvAYFFgQIBAQE X-IronPort-AV: E=Sophos;i="5.15,379,1432598400"; d="scan'208";a="7808434" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-5.cisco.com with ESMTP; 30 Jun 2015 17:05:10 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t5UH58Xq024540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jun 2015 17:05:08 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.76]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Tue, 30 Jun 2015 12:05:08 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks , "6lo@ietf.org" <6lo@ietf.org> Thread-Topic: New Version Notification for draft-thubert-6lo-routing-dispatch-04.txt Thread-Index: AQHQs1XApl1qaVb6L0KeY9/7tpYI8J3FRnPA Date: Tue, 30 Jun 2015 17:05:07 +0000 Deferred-Delivery: Tue, 30 Jun 2015 17:04:45 +0000 Message-ID: References: <20150630165644.26795.43642.idtracker@ietfa.amsl.com> In-Reply-To: <20150630165644.26795.43642.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Roll] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 17:05:17 -0000 RGVhciBhbGw6DQoNClRoaXMgbmV3IHZlcnNpb24gcHJvcG9zZXMgaW4gc2VjdGlvbiAzIHNvbWUg YWx0ZXJuYXRlcyB0byB0aGUgcmV1c2Ugb2YgdGhlIG1lc2ggaGVhZGVyLiBDb21tZW50cyB3ZWxj b21lLg0KDQpDaGVlcnMsDQoNClBhc2NhbA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnXSANClNlbnQ6IG1hcmRpIDMwIGp1aW4gMjAxNSAxODo1Nw0KVG86IFJvYmVydCBDcmFn aWU7IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCk7IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCk7 IExhdXJlbnQgVG91dGFpbjsgQ2Fyc3RlbiBCb3JtYW5uOyBMYXVyZW50IFRvdXRhaW47IERyLiBD YXJzdGVuIEJvcm1hbm47IFJvYmVydCBDcmFnaWUNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtdGh1YmVydC02bG8tcm91dGluZy1kaXNwYXRjaC0wNC50eHQNCg0K DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdGh1YmVydC02bG8tcm91dGluZy1kaXNwYXRj aC0wNC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUGFzY2FsIFRodWJl cnQgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtdGh1 YmVydC02bG8tcm91dGluZy1kaXNwYXRjaA0KUmV2aXNpb246CTA0DQpUaXRsZToJCUEgUm91dGlu ZyBIZWFkZXIgRGlzcGF0Y2ggZm9yIDZMb1dQQU4NCkRvY3VtZW50IGRhdGU6CTIwMTUtMDYtMzAN Ckdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTIzDQpVUkw6ICAgICAgICAg ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXRodWJlcnQtNmxv LXJvdXRpbmctZGlzcGF0Y2gtMDQudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGh1YmVydC02bG8tcm91dGluZy1kaXNwYXRjaC8NCkh0 bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGh1YmVydC02 bG8tcm91dGluZy1kaXNwYXRjaC0wNA0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC10aHViZXJ0LTZsby1yb3V0aW5nLWRpc3BhdGNoLTA0DQoN CkFic3RyYWN0Og0KICAgVGhpcyBzcGVjaWZpY2F0aW9uIHByb3ZpZGVzIGEgbmV3IDZMb1dQQU4g ZGlzcGF0Y2ggdHlwZSBmb3IgdXNlIGluDQogICBSb3V0ZS1vdmVyIGFuZCBtaXhlZCBNZXNoLXVu ZGVyIGFuZCBSb3V0ZS1vdmVyIHRvcG9sb2dpZXMsIHRoYXQNCiAgIHJldXNlcyB0aGUgZW5jb2Rp bmcgb2YgdGhlIG1lc2ggdHlwZSBkZWZpbmVkIGluIFJGQyA0OTQ0IGZvciBwdXJlDQogICBNZXNo LXVuZGVyIHRvcG9sb2dpZXMuICBUaGlzIHNwZWNpZmljYXRpb24gYWxzbyBkZWZpbmVzIGEgbWV0 aG9kIHRvDQogICBjb21wcmVzcyBSUEwgT3B0aW9uIChSRkM2NTUzKSBpbmZvcm1hdGlvbiBhbmQg Um91dGluZyBIZWFkZXIgdHlwZSAzDQogICAoUkZDNjU1NCksIGFuIGVmZmljaWVudCBJUC1pbi1J UCB0ZWNobmlxdWUgYW5kIG9wZW5zIHRoZSB3YXkgZm9yDQogICBmdXJ0aGVyIHJvdXRpbmcgdGVj aG5pcXVlcy4gIFRoaXMgZXh0ZW5kcyA2TG9XUEFOIFRyYW5zbWlzc2lvbiBvZg0KICAgSVB2NiBQ YWNrZXRzIChSRkM0OTQ0KSwgYW5kIGlzIGFwcGxpY2FibGUgdG8gbmV3IGxpbmstbGF5ZXIgdHlw ZXMNCiAgIHdoZXJlIDZMb1dQQU4gaXMgYmVpbmcgZGVmaW5lZC4NCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElF VEYgU2VjcmV0YXJpYXQNCg0K From nobody Tue Jun 30 10:14:52 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA0D1B29A8 for ; Tue, 30 Jun 2015 10:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syRet7tCSEl3 for ; Tue, 30 Jun 2015 10:14:50 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE25B1AD374 for ; Tue, 30 Jun 2015 10:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1996; q=dns/txt; s=iport; t=1435684490; x=1436894090; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=r4JHAxy1y7ZT0EeJxhE7nTHBHc1CBb5+zuhnNexP6Gg=; b=NlY39igf/tIXa9zlRll5MviublLEnY0WzD1xmZGd3D5FT43WKpH+rWzX g039B5TP4ofCgtJMFiwL9S4HBv+8Za+rWTCb1J+BO08y4i+dOU6KXcMIg 2iwSk7d88ie2WWvMlY1tWguqw5ylfHt7qbJdQdeR4fAICbeMMERpU+Mqv I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D1AwAvzpJV/4MNJK1bgxFUXwaDGLolCYFthXYCHIE1OBQBAQEBAQEBgQqEIgEBAQQjEUMOBAIBCBEEAQEDAgYdAwICAjAUAQYBAQUDAgQTCIgnDbFllwQBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGKKYQtKDgGgmIvgRQFjBSHcwGEWYZ+gTlEg06ScSaDem8BgQJDgQIBAQE X-IronPort-AV: E=Sophos;i="5.15,379,1432598400"; d="scan'208";a="164257430" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP; 30 Jun 2015 17:14:49 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t5UHEmvS021939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 30 Jun 2015 17:14:48 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.76]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Tue, 30 Jun 2015 12:14:48 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: New Version Notification for draft-thubert-roll-dao-projection-00.txt Thread-Index: AQHQs1fK6fa93Ev7/UaI3o90QZkE3Z3FSUnQ Date: Tue, 30 Jun 2015 17:14:47 +0000 Deferred-Delivery: Tue, 30 Jun 2015 17:14:07 +0000 Message-ID: References: <20150630171120.10187.44313.idtracker@ietfa.amsl.com> In-Reply-To: <20150630171120.10187.44313.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Roll] FW: New Version Notification for draft-thubert-roll-dao-projection-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 17:14:51 -0000 Tm93IHdpdGggdGhlIHByb3BlciBmaWxlIG5hbWUuLi4NCg0KQ2hlZXJzLA0KDQpQYXNjYWwNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBtYXJkaSAzMCBqdWlu IDIwMTUgMTk6MTENClRvOiBKYW1lcyBQeWxha3V0dHkgKG11bmRlbm1hKTsgUGFzY2FsIFRodWJl cnQgKHB0aHViZXJ0KTsgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KTsgSmFtZXMgUHlsYWt1dHR5 IChtdW5kZW5tYSkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt dGh1YmVydC1yb2xsLWRhby1wcm9qZWN0aW9uLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC10aHViZXJ0LXJvbGwtZGFvLXByb2plY3Rpb24tMDAudHh0DQpoYXMgYmVlbiBz dWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFBhc2NhbCBUaHViZXJ0IGFuZCBwb3N0ZWQgdG8gdGhl IElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LXRodWJlcnQtcm9sbC1kYW8tcHJvamVj dGlvbg0KUmV2aXNpb246CTAwDQpUaXRsZToJCVJvb3QgaW5pdGlhdGVkIHJvdXRpbmcgc3RhdGUg aW4gUlBMDQpEb2N1bWVudCBkYXRlOgkyMDE1LTA2LTI5DQpHcm91cDoJCUluZGl2aWR1YWwgU3Vi bWlzc2lvbg0KUGFnZXM6CQkxMQ0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC10aHViZXJ0LXJvbGwtZGFvLXByb2plY3Rpb24tMDAudHh0 DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt dGh1YmVydC1yb2xsLWRhby1wcm9qZWN0aW9uLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10aHViZXJ0LXJvbGwtZGFvLXByb2plY3Rpb24tMDANCg0K DQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgYSByb290LWluaXRpYXRlZCBw cm90b2NvbCBleHRlbnNpb24gdG8gUlBMDQogICB0aGF0IGVuYWJsZXMgdG8gaW5zdGFsbCBhIGxp bWl0ZWQgYW1vdW50IG9mIGRvd253YXJkIHJvdXRlcyBpbiBub24tDQogICBzdG9yaW5nIG1vZGUu ICBUaGlzIGVuYWJsZXMgbG9vc2Ugc291cmNlIHJvdXRpbmcgZG93biB0aGUgRE9EQUcuDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRo ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5v cmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Tue Jun 30 12:09:40 2015 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C753A1A872F; Tue, 30 Jun 2015 12:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOrBMFWHJ2b8; Tue, 30 Jun 2015 12:09:35 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0724.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:724]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E136A1A871F; Tue, 30 Jun 2015 12:09:34 -0700 (PDT) Received: from BN1PR03MB072.namprd03.prod.outlook.com (10.255.225.156) by BN1PR03MB072.namprd03.prod.outlook.com (10.255.225.156) with Microsoft SMTP Server (TLS) id 15.1.195.15; Tue, 30 Jun 2015 19:09:26 +0000 Received: from BN1PR03MB072.namprd03.prod.outlook.com ([169.254.9.150]) by BN1PR03MB072.namprd03.prod.outlook.com ([169.254.9.150]) with mapi id 15.01.0195.005; Tue, 30 Jun 2015 19:09:26 +0000 From: Gabriel Montenegro To: "Pascal Thubert (pthubert)" , "Routing Over Low power and Lossy networks" , "6lo@ietf.org" <6lo@ietf.org> Thread-Topic: New Version Notification for draft-thubert-6lo-routing-dispatch-04.txt Thread-Index: AQHQs1XApl1qaVb6L0KeY9/7tpYI8J3FRnPAgAAha2A= Date: Tue, 30 Jun 2015 19:09:25 +0000 Message-ID: References: <20150630165644.26795.43642.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e0:ee43::2] x-microsoft-exchange-diagnostics: 1; BN1PR03MB072; 5:JPeBO3Wh7AGIfTO44dlU9tP2YbFQawjnpfr7A/EEa42qCMiK3ke1E5zcHEQ4GPk962QQaNijrsTXucJwC/K2CZzvSZuM8a998itWgyIkaN9RYzT6uq2aUt5KCA54KUGo7CffF27bkRKxa4oUH3jbaw==; 24:9U1iXjFpZFGcLOfI8zgAFnG426TQvCmuz4NRNtX+13kuU1IXHu0t+5VOxeGLmiXAg3IxItoR9E4srJ/8zRtap/a+mDkCALpW9isV5zhHRio=; 20:siaH7E24o+3x8x4po39ihF953ibB6RNNmT83OaLEZCLmxcq2/IRXqEwhrJyoYn7J0FaoZn1MHpPR5wduzCHH3Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR03MB072; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BN1PR03MB072; BCL:0; PCL:0; RULEID:; SRVR:BN1PR03MB072; x-forefront-prvs: 06237E4555 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51704005)(164054003)(377424004)(5003600100002)(86362001)(87936001)(19580395003)(99286002)(19580405001)(230783001)(106116001)(2656002)(50986999)(92566002)(62966003)(77156002)(54356999)(76176999)(122556002)(33656002)(74316001)(5001960100002)(107886002)(46102003)(76576001)(5002640100001)(2501003)(15975445007)(102836002)(2950100001)(2900100001)(5001770100001)(189998001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR03MB072; H:BN1PR03MB072.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2015 19:09:25.7551 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR03MB072 Archived-At: Subject: Re: [Roll] New Version Notification for draft-thubert-6lo-routing-dispatch-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 19:09:38 -0000 Thanks, Pascal. I see that options 1 and 2 reuse the mesh header. And option 3 reuses NALP.= All three of these reuse previously assigned values.=20 I was under the impression that one of the options was going to use a new t= ype out of the ESC+ space. Sure, as you mention in the new draft revi= sion, that is not defined clearly yet (though there is something being prep= ared), but neither is any of the stuff in the draft.=20 The point is that it would be good to have at least one option that does no= t reuse anything previously assigned (other than ESC, which is there for th= at purpose and is in our control to further define). =20 Oh, and request noted. It would definitely be good to discuss this in Pragu= e. Thanks, Gabriel > -----Original Message----- > From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Pascal Thubert > (pthubert) > Sent: Tuesday, June 30, 2015 10:05 > To: Routing Over Low power and Lossy networks; 6lo@ietf.org > Subject: [6lo] FW: New Version Notification for draft-thubert-6lo-routing= - > dispatch-04.txt >=20 > Dear all: >=20 > This new version proposes in section 3 some alternates to the reuse of th= e > mesh header. Comments welcome. >=20 > Cheers, >=20 > Pascal >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: mardi 30 juin 2015 18:57 > To: Robert Cragie; Pascal Thubert (pthubert); Pascal Thubert (pthubert); > Laurent Toutain; Carsten Bormann; Laurent Toutain; Dr. Carsten Bormann; > Robert Cragie > Subject: New Version Notification for draft-thubert-6lo-routing-dispatch- > 04.txt >=20 >=20 > A new version of I-D, draft-thubert-6lo-routing-dispatch-04.txt > has been successfully submitted by Pascal Thubert and posted to the IETF > repository. >=20 > Name: draft-thubert-6lo-routing-dispatch > Revision: 04 > Title: A Routing Header Dispatch for 6LoWPAN > Document date: 2015-06-30 > Group: Individual Submission > Pages: 23 > URL: https://www.ietf.org/internet-drafts/draft-thubert-6lo-ro= uting- > dispatch-04.txt > Status: https://datatracker.ietf.org/doc/draft-thubert-6lo-routin= g- > dispatch/ > Htmlized: https://tools.ietf.org/html/draft-thubert-6lo-routing-dis= patch- > 04 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-thubert-6lo-rou= ting- > dispatch-04 >=20 > Abstract: > This specification provides a new 6LoWPAN dispatch type for use in > Route-over and mixed Mesh-under and Route-over topologies, that > reuses the encoding of the mesh type defined in RFC 4944 for pure > Mesh-under topologies. This specification also defines a method to > compress RPL Option (RFC6553) information and Routing Header type 3 > (RFC6554), an efficient IP-in-IP technique and opens the way for > further routing techniques. This extends 6LoWPAN Transmission of > IPv6 Packets (RFC4944), and is applicable to new link-layer types > where 6LoWPAN is being defined. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo