From nobody Wed Mar 4 13:39:05 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 ECFBE1A8966 for ; Wed, 4 Mar 2015 13:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 g8gZaWZf4PC2 for ; Wed, 4 Mar 2015 13:39:02 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F6171A8965 for ; Wed, 4 Mar 2015 13:39:02 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t24Lcm0s030003; Wed, 4 Mar 2015 21:38:49 GMT Received: from 950129200 (089144230044.atnat0039.highway.a1.net [89.144.230.44]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t24LcjYi029994 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2015 21:38:46 GMT From: "Adrian Farrel" To: , , , Date: Wed, 4 Mar 2015 21:38:46 -0000 Message-ID: <02ee01d056c3$9ad9f090$d08dd1b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBWw5DfyPmk4H9ZRQmdTE1K1htzlQ== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21376.000 X-TM-AS-Result: No--6.150-10.0-31-10 X-imss-scan-details: No--6.150-10.0-31-10 X-TMASE-MatchedRID: mVGzGnVbja4Qaipp+dGzb3BRIrj8R47F7yWPaQc4INTIs4CjQ/C5uTVk axwyOBfMQbOFXEEclEFLrzGOL1BrhG0AffdZMVlDW7gz/Gbgpl4ZbpN+hw0Ke9zOQo7mTgA+DFU +SD6gXjHbpOUT6D/xyGZjopFngc7Obx+xmQHMNIMIVoCLGbl5Ty7LAGznNYRea0TOsL14A2lzLi ypTPAGO91y2r32DMbvJu6v9wN0CtiYGUZbgkFG0h3EEAbn+GRbGYkyyELuGKTXLn2SCFOsbzWQZ YhfbX7wNJnt9TW/xwarqZpeZNqTSFbXOr5vDtxCr3X9gdfSLWV9LQinZ4QefL6qvLNjDYTwfY9h sM0xN70qtq5d3cxkNaCnS+on7MKrDondZn2uDw0Lrh67G9dQ0uPC4O8YJ2A/6eKEkY40QtbAvpL E+mvX8g== Archived-At: Cc: roll@ietf.org, roll-chairs@tools.ietf.org Subject: [Roll] AD review of draft-ietf-roll-applicability-home-building X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk, 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, 04 Mar 2015 21:39:05 -0000 Thanks for this really nice document. I found it an easy read. I have done my usual AD review to catch issues before IETF last call and IESG evaluation. I only have a handful of small issues, but I think it would be worth resolving them with a new revision before we go to last call. I have marked the datatracker to show "Revised I-D needed" and I'll wait to see you post a new version. Thanks for the work, Adrian === The chairs and I have discussed moving this document onto the Standards Track in accordance with the description of an Applicability Statement in Section 32 of RFC 2026. The only thing you need to do is update the "Intended status" to say "Proposed Standard". The Shepherd will also need to update the write-up and flip the field in the datatracker. --- In 1.1. you have The ROLL working group has specified a set of routing protocols for Lossy and Low- resource Networks (LLN) [RFC6550] Yet 6550 defines Low-Power and Lossy Networks (LLNs) --- Section 1.2 seems to only be necessary for a use of "MUST" in section 7. I am comfortable with you having used normal case ("must", "should", "recommended") in the text. Could Section 7 also drop this to "must" and then you could remove Section 1.2? --- 2.2.7 mentions AODV without expanding the abbreviation and without a reference. --- A few abbreviations need to be expanded on first use: DIO DAG MPL DAO RA ULA DODAG ETX --- 4.1.7 has... Repetition of the message can be inhibited by a small value of k. I think this is lacking a little context. What is k? --- Please mark Section 11 "To be deleted by the RFC Editor before publication." From nobody Wed Mar 4 13:41:07 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 53B331A893E; Wed, 4 Mar 2015 13:41:04 -0800 (PST) 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 0JpRwrebzYhq; Wed, 4 Mar 2015 13:41:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AC51A8963; Wed, 4 Mar 2015 13:41:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150304214101.9011.50757.idtracker@ietfa.amsl.com> Date: Wed, 04 Mar 2015 13:41:01 -0800 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: Wed, 04 Mar 2015 21:41:04 -0000 IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation AD review ===== Thanks for this really nice document. I found it an easy read. I have done my usual AD review to catch issues before IETF last call and IESG evaluation. I only have a handful of small issues, but I think it would be worth resolving them with a new revision before we go to last call. I have marked the datatracker to show "Revised I-D needed" and I'll wait to see you post a new version. Thanks for the work, Adrian === The chairs and I have discussed moving this document onto the Standards Track in accordance with the description of an Applicability Statement in Section 32 of RFC 2026. The only thing you need to do is update the "Intended status" to say "Proposed Standard". The Shepherd will also need to update the write-up and flip the field in the datatracker. --- In 1.1. you have The ROLL working group has specified a set of routing protocols for Lossy and Low- resource Networks (LLN) [RFC6550] Yet 6550 defines Low-Power and Lossy Networks (LLNs) --- Section 1.2 seems to only be necessary for a use of "MUST" in section 7. I am comfortable with you having used normal case ("must", "should", "recommended") in the text. Could Section 7 also drop this to "must" and then you could remove Section 1.2? --- 2.2.7 mentions AODV without expanding the abbreviation and without a reference. --- A few abbreviations need to be expanded on first use: DIO DAG MPL DAO RA ULA DODAG ETX --- 4.1.7 has... Repetition of the message can be inhibited by a small value of k. I think this is lacking a little context. What is k? --- Please mark Section 11 "To be deleted by the RFC Editor before publication." ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ From nobody Thu Mar 5 01:45: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 E6A221A0451 for ; Thu, 5 Mar 2015 01:45:01 -0800 (PST) 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_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001] 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 PZ4RWYV3LDJY for ; Thu, 5 Mar 2015 01:45:00 -0800 (PST) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F22661A039B for ; Thu, 5 Mar 2015 01:44:59 -0800 (PST) Received: from roundcube.xs4all.nl ([194.109.20.199]) by smtp-cloud6.xs4all.net with ESMTP id zlkw1p00B4Hiz6i01lkwN4; Thu, 05 Mar 2015 10:44:58 +0100 Received: from AMontpellier-654-1-137-205.w90-0.abo.wanadoo.fr ([90.0.120.205]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 05 Mar 2015 10:44:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 05 Mar 2015 10:44:56 +0100 From: peter van der Stok To: adrian@olddog.co.uk Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <02ee01d056c3$9ad9f090$d08dd1b0$@olddog.co.uk> References: <02ee01d056c3$9ad9f090$d08dd1b0$@olddog.co.uk> Message-ID: X-Sender: stokcons@xs4all.nl (vAVxJaH3UKVH+QLoQ9Ov0WUOzQ3JewGZ) User-Agent: XS4ALL Webmail Archived-At: Cc: abr@sdesigns.dk, roll-chairs@tools.ietf.org, roll@ietf.org Subject: Re: [Roll] AD review of draft-ietf-roll-applicability-home-building X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.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: Thu, 05 Mar 2015 09:45:02 -0000 Dear Adrian, thanks for your encouragement. A new version will be prepared in the coming 1-2 weeks, addressing all issues mentioned below. Greetings, Peter Adrian Farrel schreef op 2015-03-04 22:38: > Thanks for this really nice document. I found it an easy read. > > I have done my usual AD review to catch issues before IETF last call > and > IESG evaluation. > > I only have a handful of small issues, but I think it would be worth > resolving them with a new revision before we go to last call. I have > marked the datatracker to show "Revised I-D needed" and I'll wait to > see you post a new version. > > Thanks for the work, > Adrian > > === > > The chairs and I have discussed moving this document onto the Standards > Track in accordance with the description of an Applicability Statement > in > Section 32 of RFC 2026. The only thing you need to do is update the > "Intended status" to say "Proposed Standard". > > The Shepherd will also need to update the write-up and flip the field > in > the datatracker. > > --- > > In 1.1. you have > > The ROLL working group has specified a set of routing protocols for > Lossy and Low- resource Networks (LLN) [RFC6550] > > Yet 6550 defines > > Low-Power and Lossy Networks (LLNs) > > --- > > Section 1.2 seems to only be necessary for a use of "MUST" in section > 7. I am comfortable with you having used normal case ("must", "should", > "recommended") in the text. Could Section 7 also drop this to "must" > and then you could remove Section 1.2? > > --- > > 2.2.7 mentions AODV without expanding the abbreviation and without a > reference. > > --- > > A few abbreviations need to be expanded on first use: > DIO > DAG > MPL > DAO > RA > ULA > DODAG > ETX > > --- > > 4.1.7 has... > > Repetition of the message can be inhibited by a small > value of k. > > I think this is lacking a little context. What is k? > > --- > > Please mark Section 11 "To be deleted by the RFC Editor before > publication." From nobody Thu Mar 5 04:50:31 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 2FB471B2C6C; Thu, 5 Mar 2015 04:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 sz-PiJwXyDHP; Thu, 5 Mar 2015 04:49:29 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::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 678E31B2C4D; Thu, 5 Mar 2015 04:49:23 -0800 (PST) Received: by lbiv13 with SMTP id v13so32386909lbi.1; Thu, 05 Mar 2015 04:49:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=A0CgrmUtcpKL69nRHbfV2UXnbJqs+DIIX2aLpKdW3hg=; b=GWn1yWuXSBpvvShKydU3YyTTIbO8wj7F+IQCIRg3I+w3OMSbL6bAFoxX19uQCbbJS+ qxKg7mcuXsSj2EyIQVuX3CP5yjp7c/T845Afek1Z2CE1VPoa7qYt1uuQNumEbnPn6x1x 6Ngf7McgUAfJ87yNN0f5aAI0ZGUdkdc1QTW3CqLxG9Avgcj1+q9o9U3DpCwNxgSa8ejJ IQ10lw/0r0BnLFszjViHHvP+2y/qYgjiaMyur4VY/Z3VN8EWvX3g7zMJm0IdQWKXR2VE bQGYWoYVBCSZwV3jRcj0kNBYrhwzK6knStjJ3zjQKVrsVfMA8oi2cqfzlR2V9r56K897 TXfg== X-Received: by 10.112.42.164 with SMTP id p4mr1477155lbl.119.1425559761842; Thu, 05 Mar 2015 04:49:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.13.10 with HTTP; Thu, 5 Mar 2015 04:49:01 -0800 (PST) In-Reply-To: <20150304214101.9011.50757.idtracker@ietfa.amsl.com> References: <20150304214101.9011.50757.idtracker@ietfa.amsl.com> From: Yvonne-Anne Pignolet Date: Thu, 5 Mar 2015 13:49:01 +0100 Message-ID: To: IETF Secretariat Content-Type: multipart/alternative; boundary=001a1134d13c35f677051089ff55 Archived-At: X-Mailman-Approved-At: Thu, 05 Mar 2015 04:50:30 -0800 Cc: roll-chairs@ietf.org, roll@ietf.org, draft-ietf-roll-applicability-home-building.ad@ietf.org, draft-ietf-roll-applicability-home-building@ietf.org, draft-ietf-roll-applicability-home-building.shepherd@ietf.org Subject: Re: [Roll] ID Tracker State Update Notice: 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, 05 Mar 2015 12:49:32 -0000 --001a1134d13c35f677051089ff55 Content-Type: text/plain; charset=UTF-8 Dear all I updated the shepherd write-up accordingly. Best Regards Yvonne-Anne On 4 March 2015 at 22:41, IETF Secretariat wrote: > IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation > AD review > ===== > > Thanks for this really nice document. I found it an easy read. > > I have done my usual AD review to catch issues before IETF last call and > IESG evaluation. > > I only have a handful of small issues, but I think it would be worth > resolving them with a new revision before we go to last call. I have > marked the datatracker to show "Revised I-D needed" and I'll wait to > see you post a new version. > > Thanks for the work, > Adrian > > === > > The chairs and I have discussed moving this document onto the Standards > Track in accordance with the description of an Applicability Statement in > Section 32 of RFC 2026. The only thing you need to do is update the > "Intended status" to say "Proposed Standard". > > The Shepherd will also need to update the write-up and flip the field in > the datatracker. > > --- > > In 1.1. you have > > The ROLL working group has specified a set of routing protocols for > Lossy and Low- resource Networks (LLN) [RFC6550] > > Yet 6550 defines > > Low-Power and Lossy Networks (LLNs) > > --- > > Section 1.2 seems to only be necessary for a use of "MUST" in section > 7. I am comfortable with you having used normal case ("must", "should", > "recommended") in the text. Could Section 7 also drop this to "must" > and then you could remove Section 1.2? > > --- > > 2.2.7 mentions AODV without expanding the abbreviation and without a > reference. > > --- > > A few abbreviations need to be expanded on first use: > DIO > DAG > MPL > DAO > RA > ULA > DODAG > ETX > > --- > > 4.1.7 has... > > Repetition of the message can be inhibited by a small > value of k. > > I think this is lacking a little context. What is k? > > --- > > Please mark Section 11 "To be deleted by the RFC Editor before > publication." > ID Tracker URL: > http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ > > --001a1134d13c35f677051089ff55 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all

I updated the shepherd write-u= p accordingly.

Best Regards
Yvonne-Anne<= /div>

On 4 M= arch 2015 at 22:41, IETF Secretariat <ietf-secretariat-reply= @ietf.org> wrote:
IESG sta= te changed to AD Evaluation::Revised I-D Needed from AD Evaluation
AD review
=3D=3D=3D=3D=3D

Thanks for this really nice document. I found it an easy read.

I have done my usual AD review to catch issues before IETF last call and IESG evaluation.

I only have a handful of small issues, but I think it would be worth
resolving them with a new revision before we go to last call. I have
marked the datatracker to show "Revised I-D needed" and I'll = wait to
see you post a new version.

Thanks for the work,
Adrian

=3D=3D=3D

The chairs and I have discussed moving this document onto the Standards
Track in accordance with the description of an Applicability Statement in Section 32 of RFC 2026. The only thing you need to do is update the
"Intended status" to say "Proposed Standard".

The Shepherd will also need to update the write-up and flip the field in the datatracker.

---

In 1.1. you have

=C2=A0 =C2=A0The ROLL working group has specified a set of routing protocol= s for
=C2=A0 =C2=A0Lossy and Low- resource Networks (LLN) [RFC6550]

Yet 6550 defines

=C2=A0 =C2=A0Low-Power and Lossy Networks (LLNs)

---

Section 1.2 seems to only be necessary for a use of "MUST" in sec= tion
7. I am comfortable with you having used normal case ("must", &qu= ot;should",
"recommended") in the text. Could Section 7 also drop this to &qu= ot;must"
and then you could remove Section 1.2?

---

2.2.7 mentions AODV without expanding the abbreviation and without a
reference.

---

A few abbreviations need to be expanded on first use:
DIO
DAG
MPL
DAO
RA
ULA
DODAG
ETX

---

4.1.7 has...

=C2=A0 =C2=A0Repetition of the message can be inhibited by a small
=C2=A0 =C2=A0value of k.

I think this is lacking a little context. What is k?

---

Please mark Section 11 "To be deleted by the RFC Editor before
publication."
ID Tracker URL: http://datatracker.ietf.org= /doc/draft-ietf-roll-applicability-home-building/


--001a1134d13c35f677051089ff55-- From nobody Sun Mar 8 04:44:34 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 297431A702D; Sun, 8 Mar 2015 04:44:32 -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 fyWDQg4UuSKn; Sun, 8 Mar 2015 04:44:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 925931A702B; Sun, 8 Mar 2015 04:44:29 -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: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150308114429.24064.74017.idtracker@ietfa.amsl.com> Date: Sun, 08 Mar 2015 04:44:29 -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: Sun, 08 Mar 2015 11:44:32 -0000 IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ From nobody Sun Mar 8 04:44:35 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-admin-local-policy.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 4A7151A702E; Sun, 8 Mar 2015 04:44:32 -0700 (PDT) X-Original-To: xfilter-draft-ietf-roll-admin-local-policy.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-admin-local-policy.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297431A702D; Sun, 8 Mar 2015 04:44:32 -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 fyWDQg4UuSKn; Sun, 8 Mar 2015 04:44:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 925931A702B; Sun, 8 Mar 2015 04:44:29 -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: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150308114429.24064.74017.idtracker@ietfa.amsl.com> Date: Sun, 08 Mar 2015 04:44:29 -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: Sun, 08 Mar 2015 11:44:32 -0000 IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ From nobody Mon Mar 9 03:41: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 C4F841A0354; Mon, 9 Mar 2015 03:40:57 -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 pho5_OxVzv1H; Mon, 9 Mar 2015 03:40:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8001A87A5; Mon, 9 Mar 2015 03:40:51 -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: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309104051.18468.68998.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 03:40:51 -0700 Archived-At: Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-applicability-home-building-08.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, 09 Mar 2015 10:40:58 -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 : Applicability Statement: The use of the RPL protocol suite in Home Automation and Building Control Authors : Anders Brandt Emmanuel Baccelli Robert Cragie Peter van der Stok Filename : draft-ietf-roll-applicability-home-building-08.txt Pages : 31 Date : 2015-03-09 Abstract: The purpose of this document is to provide guidance in the selection and use of protocols from the RPL protocol suite to implement the features required for control in building and home environments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-applicability-home-building-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-home-building-08 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 Mon Mar 9 03:41: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 4416F1A8787; Mon, 9 Mar 2015 03:40: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 q4PppeAmXwLy; Mon, 9 Mar 2015 03:40:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEC61A87A8; Mon, 9 Mar 2015 03:40:51 -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: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309104051.18468.82492.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 03:40:51 -0700 Archived-At: Subject: [Roll] New Version Notification - draft-ietf-roll-applicability-home-building-08.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, 09 Mar 2015 10:40:59 -0000 A new version (-08) has been submitted for draft-ietf-roll-applicability-home-building: http://www.ietf.org/internet-drafts/draft-ietf-roll-applicability-home-building-08.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-home-building-08 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. IETF Secretariat. From nobody Mon Mar 9 05:05:31 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 E671E1A8820; Mon, 9 Mar 2015 05:05:30 -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 TokdI9JxBdq4; Mon, 9 Mar 2015 05:05:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6F41A87E8; Mon, 9 Mar 2015 05:05:19 -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: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309120519.2806.34538.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 05:05:19 -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: Mon, 09 Mar 2015 12:05:31 -0000 IESG state changed to Last Call Requested from AD Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ From nobody Mon Mar 9 07:41: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 AA5471A8A3E; Mon, 9 Mar 2015 07:41:25 -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 iojq9CKVPldM; Mon, 9 Mar 2015 07:41:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EFB1A8A4E; Mon, 9 Mar 2015 07:38:45 -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: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150309143845.25982.86726.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 07:38:45 -0700 Archived-At: Cc: roll@ietf.org Subject: [Roll] Last Call: (Applicability Statement: The use of the RPL protocol suite in Home Automation and Building Control) 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: Mon, 09 Mar 2015 14:41:25 -0000 The IESG has received a request from the Routing Over Low power and Lossy networks WG (roll) to consider the following document: - 'Applicability Statement: The use of the RPL protocol suite in Home Automation and Building Control' 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-03-23. 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 The purpose of this document is to provide guidance in the selection and use of protocols from the RPL protocol suite to implement the features required for control in building and home environments. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2413/ This document makes the following downward references (downrefs): ** Downref: Normative reference to an Experimental RFC: RFC 4764 ** Downref: Normative reference to an Informational RFC: RFC 5548 ** Downref: Normative reference to an Informational RFC: RFC 5673 ** Downref: Normative reference to an Informational RFC: RFC 5826 ** Downref: Normative reference to an Informational RFC: RFC 5867 ** Downref: Normative reference to an Experimental RFC: RFC 6997 ** Downref: Normative reference to an Experimental RFC: RFC 6998 ** Downref: Normative reference to an Informational RFC: RFC 7102 ** Downref: Normative reference to an Informational RFC: RFC 7416 From nobody Mon Mar 9 07:41: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 EBE0B1A8ADF; Mon, 9 Mar 2015 07:41:46 -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 ydd_wp9W84kr; Mon, 9 Mar 2015 07:41:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C93E51A8A76; Mon, 9 Mar 2015 07:38:46 -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: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309143846.25982.63972.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 07:38:46 -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: Mon, 09 Mar 2015 14:41:47 -0000 Last call has been made for draft-ietf-roll-applicability-home-building and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ From nobody Mon Mar 9 09:57:20 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 F05FF1A8AF7; Mon, 9 Mar 2015 09:57:18 -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 kf4EusnLn3wH; Mon, 9 Mar 2015 09:57:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 642F91A904C; Mon, 9 Mar 2015 09:57:11 -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: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309165711.11218.481.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 09:57:11 -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: Mon, 09 Mar 2015 16:57:19 -0000 IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ From nobody Mon Mar 9 09:57:22 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-admin-local-policy.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 1BA1B1A9034; Mon, 9 Mar 2015 09:57:19 -0700 (PDT) X-Original-To: xfilter-draft-ietf-roll-admin-local-policy.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-admin-local-policy.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05FF1A8AF7; Mon, 9 Mar 2015 09:57:18 -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 kf4EusnLn3wH; Mon, 9 Mar 2015 09:57:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 642F91A904C; Mon, 9 Mar 2015 09:57:11 -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: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309165711.11218.481.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 09:57:11 -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: Mon, 09 Mar 2015 16:57:19 -0000 IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ From nobody Mon Mar 9 09:57: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 53F781A9069; Mon, 9 Mar 2015 09:57:21 -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 oqEo3ny2QSz2; Mon, 9 Mar 2015 09:57:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A74C1A9060; Mon, 9 Mar 2015 09:57:11 -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: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309165711.11218.69907.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 09:57:11 -0700 Archived-At: Cc: roll mailing list , roll chair , RFC Editor Subject: [Roll] Document Action: 'Forwarder policy for multicast with admin-local scope in the Multicast Protocol for Low power and Lossy Networks (MPL)' to Informational RFC (draft-ietf-roll-admin-local-policy-03.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, 09 Mar 2015 16:57:21 -0000 The IESG has approved the following document: - 'Forwarder policy for multicast with admin-local scope in the Multicast Protocol for Low power and Lossy Networks (MPL)' (draft-ietf-roll-admin-local-policy-03.txt) as Informational RFC This document is the product of the Routing Over Low power and Lossy networks Working Group. The IESG contact persons are Alia Atlas and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ Technical Summary The purpose of this document is to specify an automated policy for the routing of Multicast Protocol for Low power and Lossy Networks (MPL) multicast messages with admin-local scope in a border router. Working Group Summary The working group discussion of this document was relatively quiet and there were no comments for or against this document during working group last call. Document Quality No information about implementations of the policy described in this document is available. The IETF last call was brought to the attention of the PIM, 6lo, and Homenet working groups. Personnel Ines Robles is the Document Shepherd Adrian Farrel is the Responsible Area Director RFC Editor Note Please change... Front page OLD R. Cragie Gridmerge NEW R. Cragie ARM Ltd. END Authors' Addresses OLD Robert Cragie Gridmerge Email: robert.cragie@gridmerge.com NEW Robert Cragie ARM Ltd. 110 Fulbourn Road Cambridge CB1 9NJ UK Email: robert.cragie@gridmerge.com END (Note: retention of old email address is intentional) From nobody Mon Mar 9 12:01: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 56E631AC3B3; Mon, 9 Mar 2015 12:01:17 -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 BMDeZlQmly6w; Mon, 9 Mar 2015 12:01:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E84741AC436; Mon, 9 Mar 2015 12:00:59 -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: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309190059.6340.1714.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 12:00:59 -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: Mon, 09 Mar 2015 19:01:17 -0000 IESG state changed to RFC Ed Queue from Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ From nobody Mon Mar 9 12:01:22 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-admin-local-policy.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id A01CE1AC3BF; Mon, 9 Mar 2015 12:01:17 -0700 (PDT) X-Original-To: xfilter-draft-ietf-roll-admin-local-policy.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-admin-local-policy.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E631AC3B3; Mon, 9 Mar 2015 12:01:17 -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 BMDeZlQmly6w; Mon, 9 Mar 2015 12:01:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E84741AC436; Mon, 9 Mar 2015 12:00:59 -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: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309190059.6340.1714.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 12:00:59 -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: Mon, 09 Mar 2015 19:01:17 -0000 IESG state changed to RFC Ed Queue from Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ From nobody Tue Mar 10 15:06:15 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 C51031A9062; Tue, 10 Mar 2015 15:06:14 -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 NK4337ggV6sD; Tue, 10 Mar 2015 15:06:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B52891A9075; Tue, 10 Mar 2015 15:06: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: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150310220605.21595.2937.idtracker@ietfa.amsl.com> Date: Tue, 10 Mar 2015 15:06: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, 10 Mar 2015 22:06:14 -0000 IANA action state changed to In Progress ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ From nobody Tue Mar 10 15:06:17 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-admin-local-policy.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id F051C1A9068; Tue, 10 Mar 2015 15:06:14 -0700 (PDT) X-Original-To: xfilter-draft-ietf-roll-admin-local-policy.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-admin-local-policy.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51031A9062; Tue, 10 Mar 2015 15:06:14 -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 NK4337ggV6sD; Tue, 10 Mar 2015 15:06:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B52891A9075; Tue, 10 Mar 2015 15:06: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: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150310220605.21595.2937.idtracker@ietfa.amsl.com> Date: Tue, 10 Mar 2015 15:06: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, 10 Mar 2015 22:06:15 -0000 IANA action state changed to In Progress ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ From nobody Wed Mar 11 08:40:09 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 2CEE51A8AB6 for ; Wed, 11 Mar 2015 08:40:08 -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 1nmR-IAxW8Ke for ; Wed, 11 Mar 2015 08:40:07 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::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 DFC7D1A9022 for ; Wed, 11 Mar 2015 08:40:04 -0700 (PDT) Received: by lbdu14 with SMTP id u14so9805651lbd.0 for ; Wed, 11 Mar 2015 08:40:03 -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=313lMs0Q5FyHgpwzJZij/q+iBVxv3cmrMxGMXzFltCc=; b=CE0gAPNj0GltB2/r1dM6DpnhXO6gBtZmmLS17KPiGXRzoHdrIUTLgbHJyXHCTavuhw LDlsFGNKk33lmOo4bMnDhcADA98NRyajnTRtlS/En7PXMQVLJ+lN3hqpN4z6gxOVQb2m OkFVxwx2p9AmmiqmXuB1XPM54jnP1C9U71y2vKJ1+31fZQg1aq4wgrqbEfmgIHQ8O5UL 54EvV0LxwGGcUB+41Qgm7v9163zfyOqgZRE/lA3v7D5dl8zFkRB5VwtJ640dJoaWGqEV frHYKZx2SqQOKFqQwzqBsVfcL3F7xT0I2thgHraee3Aib3mGtkQdSJPAl6QTThfvvmr1 C1PA== MIME-Version: 1.0 X-Received: by 10.152.45.37 with SMTP id j5mr35611172lam.31.1426088403213; Wed, 11 Mar 2015 08:40:03 -0700 (PDT) Received: by 10.25.212.8 with HTTP; Wed, 11 Mar 2015 08:40:03 -0700 (PDT) Date: Wed, 11 Mar 2015 17:40:03 +0200 Message-ID: From: Ines Robles To: roll Content-Type: multipart/alternative; boundary=001a11c28c10b123ae05110514b3 Archived-At: Cc: Michael Richardson Subject: [Roll] WGLC for 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, 11 Mar 2015 15:40:08 -0000 --001a11c28c10b123ae05110514b3 Content-Type: text/plain; charset=UTF-8 Dear all, A Working Group Last call (WGLC) starts today (03/11) until 03/30/2015 for draft-ietf-roll-mpl-parameter-configuration The draft is available here: *https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ * *http://tools.ietf.org/html/draft-ietf-roll-mpl-parameter-configuration-03 * Please review this draft to see if you think it is ready for publication and send comments to the list stating your view. Thank you very much in advance, Michael and Ines. --001a11c28c10b123ae05110514b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,=C2=A0

= A Working Group Last call (WGLC) starts today (03/11) until 03/30/2015 for=C2=A0draft-ietf-roll-mpl-p= arameter-configuration

The draft is available here:=C2=A0

Please review t= his draft to see if you think it is ready for publication and send comments= to the list stating your view.

Thank you very much in advance,

Michael and= Ines.

--001a11c28c10b123ae05110514b3-- From nobody Wed Mar 11 15:06:07 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 0BCFA1A887D; Wed, 11 Mar 2015 15:06:07 -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 jOJbacKdiVCB; Wed, 11 Mar 2015 15:06:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0ED51A87A5; Wed, 11 Mar 2015 15:06:03 -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: 5.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150311220603.10255.24574.idtracker@ietfa.amsl.com> Date: Wed, 11 Mar 2015 15:06:03 -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: Wed, 11 Mar 2015 22:06:07 -0000 IANA action state changed to No IC ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ From nobody Wed Mar 11 15:06:09 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-admin-local-policy.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 279641A88A1; Wed, 11 Mar 2015 15:06:07 -0700 (PDT) X-Original-To: xfilter-draft-ietf-roll-admin-local-policy.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-admin-local-policy.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCFA1A887D; Wed, 11 Mar 2015 15:06:07 -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 jOJbacKdiVCB; Wed, 11 Mar 2015 15:06:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0ED51A87A5; Wed, 11 Mar 2015 15:06:03 -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: 5.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150311220603.10255.24574.idtracker@ietfa.amsl.com> Date: Wed, 11 Mar 2015 15:06:03 -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: Wed, 11 Mar 2015 22:06:07 -0000 IANA action state changed to No IC ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-admin-local-policy/ From nobody Wed Mar 18 11:06: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 4E0231A9005; Wed, 18 Mar 2015 11:06:08 -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 xAvbda-4GfgP; Wed, 18 Mar 2015 11:06:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 414871A8FD4; Wed, 18 Mar 2015 11:06:06 -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: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150318180606.14721.91566.idtracker@ietfa.amsl.com> Date: Wed, 18 Mar 2015 11:06:06 -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: Wed, 18 Mar 2015 18:06:08 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ From nobody Thu Mar 19 06:15:22 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 674A61A87A2; Wed, 18 Mar 2015 10:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, 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 Afvv8jrbh7PK; Wed, 18 Mar 2015 10:42:45 -0700 (PDT) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C98391A8792; Wed, 18 Mar 2015 10:42:45 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t2IHgjUk020112; Wed, 18 Mar 2015 17:42:45 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 9B0F0C20682; Wed, 18 Mar 2015 17:42:45 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <20150309143845.25982.24958.idtracker@ietfa.amsl.com> References: <20150309143845.25982.24958.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #812029 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Wed, 18 Mar 2015 17:42:45 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Thu, 19 Mar 2015 06:15:21 -0700 Cc: roll-chairs@ietf.org, roll@ietf.org, draft-ietf-roll-applicability-home-building.ad@ietf.org, iesg@ietf.org, draft-ietf-roll-applicability-home-building.shepherd@ietf.org, draft-ietf-roll-applicability-home-building@ietf.org Subject: [Roll] [IANA #812029] Last Call: (Applicability Statement: The use of the RPL protocol suite in Home Automation and Building Control) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.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: Wed, 18 Mar 2015 17:42:47 -0000 (BEGIN IANA LAST CALL COMMENTS) IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-roll-applicability-home-building-08, which is currently in Last Call, and has the following comments: We understand that, upon approval of this document, there are no IANA Actions that need completion. While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object. If this assessment is not accurate, please respond as soon as possible. Thanks, Pearl Liang ICANN (END IANA LAST CALL COMMENTS) On Mon Mar 09 14:41:50 2015, iesg-secretary@ietf.org wrote: > The IESG has received a request from the Routing Over Low power and > Lossy > networks WG (roll) to consider the following document: > - 'Applicability Statement: The use of the RPL protocol suite in Home > Automation and Building Control' > 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-03-23. 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 > > The purpose of this document is to provide guidance in the selection > and use of protocols from the RPL protocol suite to implement the > features required for control in building and home environments. > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home- > building/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home- > building/ballot/ > > > The following IPR Declarations may be related to this I-D: > http://datatracker.ietf.org/ipr/2413/ > > This document makes the following downward references (downrefs): > ** Downref: Normative reference to an Experimental RFC: RFC 4764 > ** Downref: Normative reference to an Informational RFC: RFC 5548 > ** Downref: Normative reference to an Informational RFC: RFC 5673 > ** Downref: Normative reference to an Informational RFC: RFC 5826 > ** Downref: Normative reference to an Informational RFC: RFC 5867 > ** Downref: Normative reference to an Experimental RFC: RFC 6997 > ** Downref: Normative reference to an Experimental RFC: RFC 6998 > ** Downref: Normative reference to an Informational RFC: RFC 7102 > ** Downref: Normative reference to an Informational RFC: RFC 7416 From nobody Fri Mar 20 10:49:22 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 1AFDF1A1A8F; Fri, 20 Mar 2015 10:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 4pX85OFeOQtK; Fri, 20 Mar 2015 10:49:16 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D53661A1B7C; Fri, 20 Mar 2015 10:49:15 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t2KHmq2Y003576; Fri, 20 Mar 2015 17:48:52 GMT Received: from 950129200 (089144227101.atnat0036.highway.a1.net [89.144.227.101]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t2KHmmE6003489 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 20 Mar 2015 17:48:51 GMT From: "Adrian Farrel" To: References: In-Reply-To: Date: Fri, 20 Mar 2015 17:48:50 -0000 Message-ID: <003101d06336$21e9ab10$65bd0130$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLvBZ3a8cT2PsltzJa5vwTedh6lUgGQ/+VMAemtaUaazIscAA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21412.000 X-TM-AS-Result: No--27.167-10.0-31-10 X-imss-scan-details: No--27.167-10.0-31-10 X-TMASE-MatchedRID: z5DqD3Ob671un2nNLO3qwTYTypjB3iDVuikHZcC6ceATVJPv0YKEKbwo sMBsCF616vjDExcLUHewh3iVFqtjhBPQOu7473es8eIMPsyq0qe3dp6DuD+6wC62hjZS0WoYwqK BAza4rVvI3c0zKmL/c0wL7//qtJzDG2VEF4WD2MxoMLOoNHsM9rGWPb1NnSDwRJWmeOMHa+SPSl uH97C5gPsyTbb7aasl65iyUHoPkxIUYPAcUK4BNCa1MaKuob8PfjJOgArMOCZGhLlz15UeakH0c 1tBpl+lsGkktmU/yVki0GCHu3pGtThVCZZdryTUii1t8tzTcSrzWqWqi0pBAWv8A7jMYNJSLIHZ B0nMVDHMFpAohY3PAcWVFKrQPdA0Ig0gReBxZ22yBjDX4sGuTXhcs0GMz0PkxoPBsbUp4gc1QM6 JpEKx+b1NYJCimgwyFCnxqnZr01mtNaMkWG3/bfnCl+sgkNd7IWrhso05H/XOxDyJFXIPjlbaMt AmvAiEAnlFQbsJzLTHqDILKq++5zCnU2UCF36yuyM3OnG9pAoXjfGTDxEzLWYo1JnKj52CXX4q1 252JzgldGcRGMgoNNRkgfXwQXSRjhrauEcC25l3vIzA7XyIiBCAX4XPOvyZmyiLZetSf8my5/tF Zu9S3Ku6xVHLhqfxvECLuM+h4RB+3BndfXUhXQ== Archived-At: Cc: roll-chairs@ietf.org, roll@ietf.org, draft-ietf-roll-applicability-home-building.ad@ietf.org, iesg@ietf.org, draft-ietf-roll-applicability-home-building.shepherd@ietf.org, draft-ietf-roll-applicability-home-building@ietf.org Subject: Re: [Roll] [IANA #814289] FW: Undeliverable: Last Call: (Applicability Statement: The use of the RPL protocol suite in Home Automation and Building Control) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk, 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, 20 Mar 2015 17:49:19 -0000 Thanks Pearl, I don't know what to do about this except suggest copying the authors = names manually from the I-D. There seems to be a bug at AMS because you used the correct alias and it = expanded it to something meaningless. A > -----Original Message----- > From: Pearl Liang via RT [mailto:iana-questions@iana.org] > Sent: 20 March 2015 17:28 > Cc: roll-chairs@ietf.org; roll@ietf.org; = draft-ietf-roll-applicability-home- > building.ad@ietf.org; = draft-ietf-roll-applicability-home-building@ietf.org; draft- > ietf-roll-applicability-home-building.shepherd@ietf.org; iesg@ietf.org > Subject: [IANA #814289] FW: Undeliverable: Last Call: = home-building-08.txt> (Applicability Statement: The use of the RPL = protocol suite > in Home Automation and Building Control) to Proposed Standard >=20 > Hello, >=20 > FYI, we received a bounce from draft-ietf-roll-applicability-home- > building@ietf.org. > See below. The IANA Last Call Comments is logged in the tracker. >=20 > Thanks, > ~pl >=20 > Pearl Liang > ICANN >=20 >=20 >=20 > On Thu Mar 19 20:37:14 2015, iana-shared@icann.org wrote: > > > > > > From: Mail Delivery System > DAEMON@ietfa.amsl.com> > > Date: Thursday, March 19, 2015Anno Domini at 10:47 AM > > To: "expand-draft-ietf-roll-applicability-home- > > = building@virtual.ietf.org > home-building@virtual.ietf.org>" > = applicability-home-building@virtual.ietf.org > roll-applicability-home-building@virtual.ietf.org>> > > Subject: Undeliverable: [IANA #812029] Last Call: > applicability-home-building-08.txt> (Applicability Statement: The = use > > of the RPL protocol suite in Home Automation and Building Control) = to > > Proposed Standard > > > > > > Delivery has failed to these recipients or groups: > > > > expand-draft-ietf-roll-applicability-home- > > = building@virtual.ietf.org > home-building@virtual.ietf.org> > > A communication failure occurred during the delivery of this = message. > > Please try resending the message later. If the problem continues, > > contact your helpdesk. > > > > > > > > > > > > > > > > Diagnostic information for administrators: > > > > Generating server: ietfa.amsl.com > > > > expand-draft-ietf-roll-applicability-home- > > = building@virtual.ietf.org > home-building@virtual.ietf.org> > > Remote Server returned '< #4.4.1 X-Postfix; connect to > > mail.sdesigns.com[173.254.186.196]:25: Connection timed out>' > > > > Original message headers: > > > > Return-Path: > > > Received: by ietfa.amsl.com (Postfix, from userid 65534) id > > 8CEAE1A87A7; Wed, > > 18 Mar 2015 10:42:47 -0700 (PDT) > > X-Original-To: xfilter-draft-ietf-roll-applicability-home- > > = building@ietfa.amsl.com > home-building@ietfa.amsl.com> > > Delivered-To: xfilter-draft-ietf-roll-applicability-home- > > = building@ietfa.amsl.com > home-building@ietfa.amsl.com> > > Received: from localhost (ietfa.amsl.com [127.0.0.1]) by > > ietfa.amsl.com > > (Postfix) with ESMTP id 674A61A87A2; Wed, 18 Mar 2015 10:42:47 = -0700 > > (PDT) > > X-Virus-Scanned: amavisd-new at amsl.com > > X-Spam-Flag: NO > > X-Spam-Score: -3.19 > > X-Spam-Level: > > X-Spam-Status: No, score=3D-3.19 tagged_above=3D-999 required=3D5 > > tests=3D[BAYES_00=3D-1.9, MISSING_HEADERS=3D1.021, = RCVD_IN_DNSWL_MED=3D- > 2.3, > > SPF_PASS=3D-0.001, T_RP_MATCHES_RCVD=3D-0.01] autolearn=3Dham > > 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 Afvv8jrbh7PK; > > Wed, 18 > > Mar 2015 10:42:45 -0700 (PDT) > > Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) > > (using > > TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client > > certificate > > requested) by ietfa.amsl.com (Postfix) with ESMTPS id C98391A8792; > > Wed, 18 > > Mar 2015 10:42:45 -0700 (PDT) > > Received: from request3.lax.icann.org (request1.lax.icann.org > > [10.32.11.221]) > > by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id = t2IHgjUk020112; > > Wed, 18 > > Mar 2015 17:42:45 GMT > > Received: by request3.lax.icann.org (Postfix, from userid 48) id > > 9B0F0C20682; > > Wed, 18 Mar 2015 17:42:45 +0000 (UTC) > > RT-Owner: pearl.liang > > Subject: [IANA #812029] Last Call: > > (Applicability > > Statement: The use of the RPL protocol suite in Home Automation and > > Building > > Control) to Proposed Standard > > From: Pearl Liang via RT > lastcall@iana.org>> > > Reply-To: = > > > In-Reply-To: > > > = <20150309143845.25982.24958.idtracker@ietfa.amsl.com .25982.24958.idtracker@ietfa.amsl.com>> > > References: > 812029@icann.org>> > > > = <20150309143845.25982.24958.idtracker@ietfa.amsl.com .25982.24958.idtracker@ietfa.amsl.com>> > > Message-ID: > 0@icann.org > 0@icann.org>> > > X-RT-Loop-Prevention: IANA > > X-RT-Ticket: IANA #812029 > > X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) > > X-RT-Originator: pearl.liang@icann.org > > CC: >, > > >, > > > building.ad@ietf.org > building.ad@ietf.org>>, > > > building@ietf.org > building@ietf.org>>, > > > = building.shepherd@ietf.org > building.shepherd@ietf.org>>, > > > > > Content-Type: text/plain; charset=3D"utf-8" > > X-RT-Original-Encoding: utf-8 > > Precedence: bulk > > Date: Wed, 18 Mar 2015 17:42:45 +0000 > > MIME-Version: 1.0 > > Content-Transfer-Encoding: 8bit > > >=20 From nobody Fri Mar 20 14:33:55 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 EAF931A88AE; Fri, 20 Mar 2015 14:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.411 X-Spam-Level: X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-5, 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 5KtZ178Aw6iE; Fri, 20 Mar 2015 14:33:51 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06751A88D7; Fri, 20 Mar 2015 14:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1426887232; x=1458423232; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=yahSMttCrlwUKxQMGTwgniCYIAQfBIfrdSR2JaJH/ew=; b=YzitYgNjFWeYCn+Wy7a+27o1p9GKuJoNpLTFZfUQWlZqmR1YIeL5b1e2 Z1NXTnL2ROZEzak7PZ2MSKtNIcSKTrtuC/zRiIUHGmtb8spOZSx1FRwiD 97qSzs+m4prTLFPIIKq/k+LsyG6Qnr+sKlymcvggQunD3PNssNlP+Wbmw g=; X-IronPort-AV: E=McAfee;i="5600,1067,7746"; a="86314361" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 20 Mar 2015 14:33:51 -0700 X-IronPort-AV: E=Sophos;i="5.11,439,1422950400"; d="scan'208";a="32055435" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 20 Mar 2015 14:33:48 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 20 Mar 2015 14:33:36 -0700 Message-ID: <550C922F.5080603@qti.qualcomm.com> Date: Fri, 20 Mar 2015 16:33:35 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: References: <003101d06336$21e9ab10$65bd0130$@olddog.co.uk> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (10.85.0.81) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: roll-chairs@ietf.org, roll@ietf.org, draft-ietf-roll-applicability-home-building.ad@ietf.org, draft-ietf-roll-applicability-home-building@ietf.org, draft-ietf-roll-applicability-home-building.shepherd@ietf.org, iesg@ietf.org Subject: Re: [Roll] [IANA #814462] RE: FW: Undeliverable: Last Call: (Applicability Statement: The use of the RPL protocol suite in Home Automation and Building Control) to Proposed Standard 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: Fri, 20 Mar 2015 21:33:54 -0000 I'll forward it. pr On 3/20/15 4:30 PM, Pearl Liang via RT wrote: > Hi Adrian, > > i hope just one-off system glitch thing. Though i suggest to chat with Henrik > and Robert and see if there is any server glitches recently. > > Thanks, > ~pl > > > On Fri Mar 20 17:49:16 2015, adrian@olddog.co.uk wrote: > >> Thanks Pearl, >> >> I don't know what to do about this except suggest copying the authors >> names manually from the I-D. >> >> There seems to be a bug at AMS because you used the correct alias and >> it expanded it to something meaningless. >> >> A >> >> >>> -----Original Message----- >>> From: Pearl Liang via RT [mailto:iana-questions@iana.org] >>> Sent: 20 March 2015 17:28 >>> Cc: roll-chairs@ietf.org; roll@ietf.org; draft-ietf-roll- >>> applicability-home- >>> building.ad@ietf.org; draft-ietf-roll-applicability-home- >>> building@ietf.org; draft- >>> ietf-roll-applicability-home-building.shepherd@ietf.org; >>> iesg@ietf.org >>> Subject: [IANA #814289] FW: Undeliverable: Last Call:>> roll-applicability- >>> home-building-08.txt> (Applicability Statement: The use of the RPL >>> protocol suite >>> in Home Automation and Building Control) to Proposed Standard >>> >>> Hello, >>> >>> FYI, we received a bounce from draft-ietf-roll-applicability-home- >>> building@ietf.org. >>> See below. The IANA Last Call Comments is logged in the tracker. >>> >>> Thanks, >>> ~pl >>> >>> Pearl Liang >>> ICANN >>> >>> >>> >>> On Thu Mar 19 20:37:14 2015, iana-shared@icann.org wrote: >>> >>>> >>>> From: Mail Delivery System>>> DAEMON@ietfa.amsl.com> >>>> Date: Thursday, March 19, 2015Anno Domini at 10:47 AM >>>> To: "expand-draft-ietf-roll-applicability-home- >>>> building@virtual.ietf.org>>> applicability- >>>> home-building@virtual.ietf.org>">>> applicability-home-building@virtual.ietf.org>>> ietf- >>>> roll-applicability-home-building@virtual.ietf.org>> >>>> Subject: Undeliverable: [IANA #812029] Last Call:>>> applicability-home-building-08.txt> (Applicability Statement: The >>>> use >>>> of the RPL protocol suite in Home Automation and Building Control) >>>> to >>>> Proposed Standard >>>> >>>> >>>> Delivery has failed to these recipients or groups: >>>> >>>> expand-draft-ietf-roll-applicability-home- >>>> building@virtual.ietf.org>>> applicability- >>>> home-building@virtual.ietf.org> >>>> A communication failure occurred during the delivery of this >>>> message. >>>> Please try resending the message later. If the problem continues, >>>> contact your helpdesk. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Diagnostic information for administrators: >>>> >>>> Generating server: ietfa.amsl.com >>>> >>>> expand-draft-ietf-roll-applicability-home- >>>> building@virtual.ietf.org>>> applicability- >>>> home-building@virtual.ietf.org> >>>> Remote Server returned '< #4.4.1 X-Postfix; connect to >>>> mail.sdesigns.com[173.254.186.196]:25: Connection timed out>' >>>> >>>> Original message headers: >>>> >>>> Return-Path:> >>>> Received: by ietfa.amsl.com (Postfix, from userid 65534) id >>>> 8CEAE1A87A7; Wed, >>>> 18 Mar 2015 10:42:47 -0700 (PDT) >>>> X-Original-To: xfilter-draft-ietf-roll-applicability-home- >>>> building@ietfa.amsl.com>>> applicability- >>>> home-building@ietfa.amsl.com> >>>> Delivered-To: xfilter-draft-ietf-roll-applicability-home- >>>> building@ietfa.amsl.com>>> applicability- >>>> home-building@ietfa.amsl.com> >>>> Received: from localhost (ietfa.amsl.com [127.0.0.1]) by >>>> ietfa.amsl.com >>>> (Postfix) with ESMTP id 674A61A87A2; Wed, 18 Mar 2015 10:42:47 >>>> -0700 >>>> (PDT) >>>> X-Virus-Scanned: amavisd-new at amsl.com >>>> X-Spam-Flag: NO >>>> X-Spam-Score: -3.19 >>>> X-Spam-Level: >>>> X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 >>>> tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=- >>>> >>> 2.3, >>> >>>> 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 Afvv8jrbh7PK; >>>> Wed, 18 >>>> Mar 2015 10:42:45 -0700 (PDT) >>>> Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) >>>> (using >>>> TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client >>>> certificate >>>> requested) by ietfa.amsl.com (Postfix) with ESMTPS id C98391A8792; >>>> Wed, 18 >>>> Mar 2015 10:42:45 -0700 (PDT) >>>> Received: from request3.lax.icann.org (request1.lax.icann.org >>>> [10.32.11.221]) >>>> by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id >>>> t2IHgjUk020112; >>>> Wed, 18 >>>> Mar 2015 17:42:45 GMT >>>> Received: by request3.lax.icann.org (Postfix, from userid 48) id >>>> 9B0F0C20682; >>>> Wed, 18 Mar 2015 17:42:45 +0000 (UTC) >>>> RT-Owner: pearl.liang >>>> Subject: [IANA #812029] Last Call: >>>> (Applicability >>>> Statement: The use of the RPL protocol suite in Home Automation and >>>> Building >>>> Control) to Proposed Standard >>>> From: Pearl Liang via RT>>> lastcall@iana.org>> >>>> Reply-To:>>> lastcall@iana.org>> >>>> In-Reply-To: >>>> >>>> >>> <20150309143845.25982.24958.idtracker@ietfa.amsl.com>> .25982.24958.idtracker@ietfa.amsl.com>> >>> >>>> References:>>> 812029@icann.org>> >>>> >>>> >>> <20150309143845.25982.24958.idtracker@ietfa.amsl.com>> .25982.24958.idtracker@ietfa.amsl.com>> >>> >>>> Message-ID:>>> 0@icann.org>>> 0@icann.org>> >>>> X-RT-Loop-Prevention: IANA >>>> X-RT-Ticket: IANA #812029 >>>> X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) >>>> X-RT-Originator: >>>> pearl.liang@icann.org >>>> CC:>, >>>> >, >>>> >>> building.ad@ietf.org>>> building.ad@ietf.org>>, >>>> >>> building@ietf.org>>> building@ietf.org>>, >>>> >>> building.shepherd@ietf.org>>> home- >>>> building.shepherd@ietf.org>>, >>>> > >>>> Content-Type: text/plain; charset="utf-8" >>>> X-RT-Original-Encoding: utf-8 >>>> Precedence: bulk >>>> Date: Wed, 18 Mar 2015 17:42:45 +0000 >>>> MIME-Version: 1.0 >>>> Content-Transfer-Encoding: 8bit >>>> >>>> >>> > > > -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Sun Mar 22 14:28:10 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-applicability-home-building.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id C30591A1B13; Sun, 22 Mar 2015 13:29:08 -0700 (PDT) X-Original-To: xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32731A1B12 for ; Sun, 22 Mar 2015 13:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] 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 1Tja0jTzufQ1 for ; Sun, 22 Mar 2015 13:29:06 -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 CDE161A1B07 for ; Sun, 22 Mar 2015 13:29:03 -0700 (PDT) Received: from usevmg20.ericsson.net ([198.24.6.45]:46703) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YZmUY-00030r-Gq for draft-ietf-roll-applicability-home-building.all@tools.ietf.org; Sun, 22 Mar 2015 13:29:03 -0700 X-AuditID: c618062d-f79686d0000030a8-d1-550ed0619d58 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 47.2E.12456.160DE055; Sun, 22 Mar 2015 15:23:29 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0210.002; Sun, 22 Mar 2015 16:28:53 -0400 From: Meral Shirazipour To: "draft-ietf-roll-applicability-home-building.all@tools.ietf.org" , "gen-art@ietf.org" Thread-Topic: Gen-ART Last Call review of draft-ietf-roll-applicability-home-building-08 Thread-Index: AdBk3qxllYz4F6enSIOijLT2ACZOxg== Date: Sun, 22 Mar 2015 20:28:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyuXRPgm7iBb5Qg08vNS2uHt7EanH11WcW ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugStj59W5jAV/BCuWtMQ1MN7n62Lk5JAQMJFY O3UbE4QtJnHh3nq2LkYuDiGBI4wSUx8sZIJwljNKfJ+xmB2kik3AQmL77+esIAkRgQ2MEkvP LmMGSQgLhEpseDiJFcQWEYiS+Ht3FhuErSdx7OkFRhCbRUBVomH6NRYQm1fAV2L55+dgNiPQ 6u+n1oCdwSwgLnHryXyokwQkluw5zwxhi0q8fPyPFcJWkpjz+hozRL2OxILdn9ggbG2JZQtf M0PMF5Q4OfMJywRG4VlIxs5C0jILScssJC0LGFlWMXKUFqeW5aYbGWxiBIb3MQk23R2Me15a HmIU4GBU4uE1MOALFWJNLCuuzD3EKM3BoiTOu+jBwRAhgfTEktTs1NSC1KL4otKc1OJDjEwc nFINjCYv2GY8X/9uV13XgTunBOZrBcQxnLb/cvro33NXxPd/NepdOeHRgwTVzpvNXCv9ndZ1 +Z9lYznXm36naErMD/2/V9RF/ASaM3ln6Zz5JCR5ZGf2ujO6W+e/Pfwv65sx+1V9teBwl+uO AoynfDKO/t67tLCY5+Bi/WP5n8SLU6f2mjTM3jb9xV4lluKMREMt5qLiRACYsUU+UAIAAA== X-SA-Exim-Connect-IP: 198.24.6.45 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-home-building.all@tools.ietf.org X-SA-Exim-Mail-From: meral.shirazipour@ericsson.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-applicability-home-building.all@ietf.org Resent-Message-Id: <20150322202906.CDE161A1B07@ietfa.amsl.com> Resent-Date: Sun, 22 Mar 2015 13:29:03 -0700 (PDT) Resent-From: meral.shirazipour@ericsson.com Archived-At: Archived-At: X-Mailman-Approved-At: Sun, 22 Mar 2015 14:28:06 -0700 Subject: [Roll] Gen-ART Last Call review of draft-ietf-roll-applicability-home-building-08 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, 22 Mar 2015 20:29:08 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenA= rtfaq.=20 Please resolve these comments along with any other Last Call comments you m= ay receive. Document: draft-ietf-roll-applicability-home-building-08 Reviewer: Meral Shirazipour Review Date: 2015-03-21 IETF LC End Date: 2015-03-23 IESG Telechat date: NA Summary: This draft is ready to be published as Standards Track RFC but I have some = comments. Major issues: Minor issues: Nits/editorial comments: -[Page 1], "RPL" first used in title/abstract, Would be good to spell it ou= t. -[Page 5], Section 2, "Monitoring of functional correctness is at least as = important.". As important as what? (not clear) -[Page 5], Section 2, "Devices typically communicate their status regularly= and send alarm messages notifying a malfunction of equipment or network." Not clear what equipment is? network node is an equipment? -[Page 6], Section 2.1, "for large installation"--->"for a large installati= on" -[Page 8], Section 2.2.2, "fire detectors and the smoke dampers need to be = put in place to meet the stringent delay requirements." Where can we find a value for the delay requirement of fire detectors? A va= lue or reference would be good. -[Page 9], Section 2.2.4,"advanced scene and group control". Not clear what= "scene" means. -[Page 13], Section 4.1, "assumes the role as authoritative"--->"assumes th= e role of authoritative" -[Page 16], section 4.1.8, please spell out first use CBC-MAC (Cipher Block= Chaining Message Authentication Code) -[Page 16], section 4.1.10, it would be good to give the RFCs. -[Page 16], section 4.2.4, MLE to spell out at first use "mesh link establi= shment" -[Page 22], "CoAp" first used in section 7.4, but spelled out in section 8. -[Page 18], section 5.1.1., "to throw away too late messages", how are too = late messages identified? -[Page 27], [I-D.ietf-6lo-lowpanz] to be replaced by RFC7428=20 -[Page 28], link to [occuswitch] to be verified. -Through the document both "ms" and "msec" are used. Selecting one for cons= istency would be better. Best Regards, Meral --- Meral Shirazipour Ericsson Research www.ericsson.com From nobody Sun Mar 22 14:28:12 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 72AF91A1BFA; Fri, 20 Mar 2015 10:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_55=0.6, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, 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 JIa3LjOy0VDT; Fri, 20 Mar 2015 10:28:02 -0700 (PDT) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00DDD1A1BF3; Fri, 20 Mar 2015 10:28:00 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t2KHS0H4001513; Fri, 20 Mar 2015 17:28:00 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id B725FC2016C; Fri, 20 Mar 2015 17:28:00 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: References: Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #814289 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Fri, 20 Mar 2015 17:28:00 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Sun, 22 Mar 2015 14:28:06 -0700 Cc: roll-chairs@ietf.org, roll@ietf.org, draft-ietf-roll-applicability-home-building.ad@ietf.org, iesg@ietf.org, draft-ietf-roll-applicability-home-building.shepherd@ietf.org, draft-ietf-roll-applicability-home-building@ietf.org Subject: [Roll] [IANA #814289] FW: Undeliverable: Last Call: (Applicability Statement: The use of the RPL protocol suite in Home Automation and Building Control) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: iana-questions@iana.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: Fri, 20 Mar 2015 17:28:04 -0000 Hello, FYI, we received a bounce from draft-ietf-roll-applicability-home-building@ietf.org. See below. The IANA Last Call Comments is logged in the tracker. Thanks, ~pl Pearl Liang ICANN On Thu Mar 19 20:37:14 2015, iana-shared@icann.org wrote: > > > From: Mail Delivery System DAEMON@ietfa.amsl.com> > Date: Thursday, March 19, 2015Anno Domini at 10:47 AM > To: "expand-draft-ietf-roll-applicability-home- > building@virtual.ietf.org home-building@virtual.ietf.org>" applicability-home-building@virtual.ietf.org roll-applicability-home-building@virtual.ietf.org>> > Subject: Undeliverable: [IANA #812029] Last Call: applicability-home-building-08.txt> (Applicability Statement: The use > of the RPL protocol suite in Home Automation and Building Control) to > Proposed Standard > > > Delivery has failed to these recipients or groups: > > expand-draft-ietf-roll-applicability-home- > building@virtual.ietf.org home-building@virtual.ietf.org> > A communication failure occurred during the delivery of this message. > Please try resending the message later. If the problem continues, > contact your helpdesk. > > > > > > > > Diagnostic information for administrators: > > Generating server: ietfa.amsl.com > > expand-draft-ietf-roll-applicability-home- > building@virtual.ietf.org home-building@virtual.ietf.org> > Remote Server returned '< #4.4.1 X-Postfix; connect to > mail.sdesigns.com[173.254.186.196]:25: Connection timed out>' > > Original message headers: > > Return-Path: > > Received: by ietfa.amsl.com (Postfix, from userid 65534) id > 8CEAE1A87A7; Wed, > 18 Mar 2015 10:42:47 -0700 (PDT) > X-Original-To: xfilter-draft-ietf-roll-applicability-home- > building@ietfa.amsl.com home-building@ietfa.amsl.com> > Delivered-To: xfilter-draft-ietf-roll-applicability-home- > building@ietfa.amsl.com home-building@ietfa.amsl.com> > Received: from localhost (ietfa.amsl.com [127.0.0.1]) by > ietfa.amsl.com > (Postfix) with ESMTP id 674A61A87A2; Wed, 18 Mar 2015 10:42:47 -0700 > (PDT) > X-Virus-Scanned: amavisd-new at amsl.com > X-Spam-Flag: NO > X-Spam-Score: -3.19 > X-Spam-Level: > X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 > tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, > 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 Afvv8jrbh7PK; > Wed, 18 > Mar 2015 10:42:45 -0700 (PDT) > Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) > (using > TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client > certificate > requested) by ietfa.amsl.com (Postfix) with ESMTPS id C98391A8792; > Wed, 18 > Mar 2015 10:42:45 -0700 (PDT) > Received: from request3.lax.icann.org (request1.lax.icann.org > [10.32.11.221]) > by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t2IHgjUk020112; > Wed, 18 > Mar 2015 17:42:45 GMT > Received: by request3.lax.icann.org (Postfix, from userid 48) id > 9B0F0C20682; > Wed, 18 Mar 2015 17:42:45 +0000 (UTC) > RT-Owner: pearl.liang > Subject: [IANA #812029] Last Call: > (Applicability > Statement: The use of the RPL protocol suite in Home Automation and > Building > Control) to Proposed Standard > From: Pearl Liang via RT lastcall@iana.org>> > Reply-To: > > In-Reply-To: > <20150309143845.25982.24958.idtracker@ietfa.amsl.com> > References: 812029@icann.org>> > <20150309143845.25982.24958.idtracker@ietfa.amsl.com> > Message-ID: 0@icann.org 0@icann.org>> > X-RT-Loop-Prevention: IANA > X-RT-Ticket: IANA #812029 > X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) > X-RT-Originator: pearl.liang@icann.org > CC: >, > >, > building.ad@ietf.org building.ad@ietf.org>>, > building@ietf.org building@ietf.org>>, > building.shepherd@ietf.org building.shepherd@ietf.org>>, > > > Content-Type: text/plain; charset="utf-8" > X-RT-Original-Encoding: utf-8 > Precedence: bulk > Date: Wed, 18 Mar 2015 17:42:45 +0000 > MIME-Version: 1.0 > Content-Transfer-Encoding: 8bit > From nobody Sun Mar 22 14:28: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 B4BDB1A9064; Fri, 20 Mar 2015 14:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_55=0.6, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, 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 PUjaOaP9cpnM; Fri, 20 Mar 2015 14:30:46 -0700 (PDT) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65B0A1A905E; Fri, 20 Mar 2015 14:30:46 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t2KLUjpc012363; Fri, 20 Mar 2015 21:30:46 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id F26B7C203E9; Fri, 20 Mar 2015 21:30:45 +0000 (UTC) RT-Owner: Nobody From: "Pearl Liang via RT" In-Reply-To: <003101d06336$21e9ab10$65bd0130$@olddog.co.uk> References: <003101d06336$21e9ab10$65bd0130$@olddog.co.uk> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #814462 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Fri, 20 Mar 2015 21:30:45 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Sun, 22 Mar 2015 14:28:06 -0700 Cc: roll-chairs@ietf.org, roll@ietf.org, draft-ietf-roll-applicability-home-building.ad@ietf.org, draft-ietf-roll-applicability-home-building@ietf.org, iesg@ietf.org, draft-ietf-roll-applicability-home-building.shepherd@ietf.org Subject: [Roll] [IANA #814462] RE: FW: Undeliverable: Last Call: (Applicability Statement: The use of the RPL protocol suite in Home Automation and Building Control) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: iana-questions@iana.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: Fri, 20 Mar 2015 21:30:48 -0000 Hi Adrian, i hope just one-off system glitch thing. Though i suggest to chat with Henrik and Robert and see if there is any server glitches recently. Thanks, ~pl On Fri Mar 20 17:49:16 2015, adrian@olddog.co.uk wrote: > Thanks Pearl, > > I don't know what to do about this except suggest copying the authors > names manually from the I-D. > > There seems to be a bug at AMS because you used the correct alias and > it expanded it to something meaningless. > > A > > > -----Original Message----- > > From: Pearl Liang via RT [mailto:iana-questions@iana.org] > > Sent: 20 March 2015 17:28 > > Cc: roll-chairs@ietf.org; roll@ietf.org; draft-ietf-roll- > > applicability-home- > > building.ad@ietf.org; draft-ietf-roll-applicability-home- > > building@ietf.org; draft- > > ietf-roll-applicability-home-building.shepherd@ietf.org; > > iesg@ietf.org > > Subject: [IANA #814289] FW: Undeliverable: Last Call: > roll-applicability- > > home-building-08.txt> (Applicability Statement: The use of the RPL > > protocol suite > > in Home Automation and Building Control) to Proposed Standard > > > > Hello, > > > > FYI, we received a bounce from draft-ietf-roll-applicability-home- > > building@ietf.org. > > See below. The IANA Last Call Comments is logged in the tracker. > > > > Thanks, > > ~pl > > > > Pearl Liang > > ICANN > > > > > > > > On Thu Mar 19 20:37:14 2015, iana-shared@icann.org wrote: > > > > > > > > > From: Mail Delivery System > > DAEMON@ietfa.amsl.com> > > > Date: Thursday, March 19, 2015Anno Domini at 10:47 AM > > > To: "expand-draft-ietf-roll-applicability-home- > > > building@virtual.ietf.org > > applicability- > > > home-building@virtual.ietf.org>" > > applicability-home-building@virtual.ietf.org > > ietf- > > > roll-applicability-home-building@virtual.ietf.org>> > > > Subject: Undeliverable: [IANA #812029] Last Call: > > applicability-home-building-08.txt> (Applicability Statement: The > > > use > > > of the RPL protocol suite in Home Automation and Building Control) > > > to > > > Proposed Standard > > > > > > > > > Delivery has failed to these recipients or groups: > > > > > > expand-draft-ietf-roll-applicability-home- > > > building@virtual.ietf.org > > applicability- > > > home-building@virtual.ietf.org> > > > A communication failure occurred during the delivery of this > > > message. > > > Please try resending the message later. If the problem continues, > > > contact your helpdesk. > > > > > > > > > > > > > > > > > > > > > > > > Diagnostic information for administrators: > > > > > > Generating server: ietfa.amsl.com > > > > > > expand-draft-ietf-roll-applicability-home- > > > building@virtual.ietf.org > > applicability- > > > home-building@virtual.ietf.org> > > > Remote Server returned '< #4.4.1 X-Postfix; connect to > > > mail.sdesigns.com[173.254.186.196]:25: Connection timed out>' > > > > > > Original message headers: > > > > > > Return-Path: > > > > Received: by ietfa.amsl.com (Postfix, from userid 65534) id > > > 8CEAE1A87A7; Wed, > > > 18 Mar 2015 10:42:47 -0700 (PDT) > > > X-Original-To: xfilter-draft-ietf-roll-applicability-home- > > > building@ietfa.amsl.com > > applicability- > > > home-building@ietfa.amsl.com> > > > Delivered-To: xfilter-draft-ietf-roll-applicability-home- > > > building@ietfa.amsl.com > > applicability- > > > home-building@ietfa.amsl.com> > > > Received: from localhost (ietfa.amsl.com [127.0.0.1]) by > > > ietfa.amsl.com > > > (Postfix) with ESMTP id 674A61A87A2; Wed, 18 Mar 2015 10:42:47 > > > -0700 > > > (PDT) > > > X-Virus-Scanned: amavisd-new at amsl.com > > > X-Spam-Flag: NO > > > X-Spam-Score: -3.19 > > > X-Spam-Level: > > > X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 > > > tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=- > > 2.3, > > > 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 Afvv8jrbh7PK; > > > Wed, 18 > > > Mar 2015 10:42:45 -0700 (PDT) > > > Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) > > > (using > > > TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client > > > certificate > > > requested) by ietfa.amsl.com (Postfix) with ESMTPS id C98391A8792; > > > Wed, 18 > > > Mar 2015 10:42:45 -0700 (PDT) > > > Received: from request3.lax.icann.org (request1.lax.icann.org > > > [10.32.11.221]) > > > by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id > > > t2IHgjUk020112; > > > Wed, 18 > > > Mar 2015 17:42:45 GMT > > > Received: by request3.lax.icann.org (Postfix, from userid 48) id > > > 9B0F0C20682; > > > Wed, 18 Mar 2015 17:42:45 +0000 (UTC) > > > RT-Owner: pearl.liang > > > Subject: [IANA #812029] Last Call: > > > (Applicability > > > Statement: The use of the RPL protocol suite in Home Automation and > > > Building > > > Control) to Proposed Standard > > > From: Pearl Liang via RT > > lastcall@iana.org>> > > > Reply-To: > > lastcall@iana.org>> > > > In-Reply-To: > > > > > <20150309143845.25982.24958.idtracker@ietfa.amsl.com > .25982.24958.idtracker@ietfa.amsl.com>> > > > References: > > 812029@icann.org>> > > > > > <20150309143845.25982.24958.idtracker@ietfa.amsl.com > .25982.24958.idtracker@ietfa.amsl.com>> > > > Message-ID: > > 0@icann.org > > 0@icann.org>> > > > X-RT-Loop-Prevention: IANA > > > X-RT-Ticket: IANA #812029 > > > X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) > > > X-RT-Originator: > > > pearl.liang@icann.org > > > CC: >, > > > >, > > > > > building.ad@ietf.org > > building.ad@ietf.org>>, > > > > > building@ietf.org > > building@ietf.org>>, > > > > > building.shepherd@ietf.org > > home- > > > building.shepherd@ietf.org>>, > > > > > > > Content-Type: text/plain; charset="utf-8" > > > X-RT-Original-Encoding: utf-8 > > > Precedence: bulk > > > Date: Wed, 18 Mar 2015 17:42:45 +0000 > > > MIME-Version: 1.0 > > > Content-Transfer-Encoding: 8bit > > > > > From nobody Mon Mar 23 00:09: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 1ABEE1A8909; Mon, 23 Mar 2015 00:08:59 -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 w0_85RbgukWk; Mon, 23 Mar 2015 00:08:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 979B21A890B; Mon, 23 Mar 2015 00:08:51 -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: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150323070851.3007.24404.idtracker@ietfa.amsl.com> Date: Mon, 23 Mar 2015 00:08:51 -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: Mon, 23 Mar 2015 07:08:59 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Mon Mar 23 08:00:33 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-applicability-home-building.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 8C5621A8BC2; Mon, 23 Mar 2015 07:49:53 -0700 (PDT) X-Original-To: xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706F81A8BC1 for ; Mon, 23 Mar 2015 07:49:53 -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 jKGiKjFF0eys for ; Mon, 23 Mar 2015 07:49:52 -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 2E83B1A8BBF for ; Mon, 23 Mar 2015 07:49:52 -0700 (PDT) Received: from lb2-smtp-cloud2.xs4all.net ([194.109.24.25]:54661) by merlot.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.84) (envelope-from ) id 1Ya3fo-0002I4-VG for draft-ietf-roll-applicability-home-building.all@tools.ietf.org; Mon, 23 Mar 2015 15:49:50 +0100 Received: from roundcube.xs4all.nl ([194.109.20.209]) by smtp-cloud2.xs4all.net with ESMTP id 72p41q00J4WfiVN012p4it; Mon, 23 Mar 2015 15:49:08 +0100 Received: from [2001:67c:370:160:d513:7d2a:a738:f71] by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 23 Mar 2015 15:49:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 23 Mar 2015 15:49:04 +0100 From: peter van der Stok To: Meral Shirazipour Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: X-Sender: stokcons@xs4all.nl (cO8FBEHntcgf2jGfjt0ZVNhSgVSrT31p) User-Agent: XS4ALL Webmail X-SA-Exim-Connect-IP: 194.109.24.25 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-home-building.all@tools.ietf.org X-SA-Exim-Mail-From: stokcons@xs4all.nl 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-applicability-home-building.all@ietf.org Resent-Message-Id: <20150323144952.2E83B1A8BBF@ietfa.amsl.com> Resent-Date: Mon, 23 Mar 2015 07:49:52 -0700 (PDT) Resent-From: stokcons@xs4all.nl Archived-At: Archived-At: X-Mailman-Approved-At: Mon, 23 Mar 2015 08:00:31 -0700 Cc: gen-art@ietf.org, draft-ietf-roll-applicability-home-building.all@tools.ietf.org Subject: Re: [Roll] Gen-ART Last Call review of draft-ietf-roll-applicability-home-building-08 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.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: Mon, 23 Mar 2015 14:49:53 -0000 HI Meral, Thanks for the suggestions. I have no problem with any of them. I think they are quite justified. Thank you very much for pointing them out. Concerning scene and group control. I may suppress the word "scene". About [occuswitch] I have to look for a valid alternative. However, these links are maintained by a company, which changes information frequently. Sorry for missing out some of the acronyms. I thought I caught them out all. Greetings, Peter Meral Shirazipour schreef op 2015-03-22 21:28: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-roll-applicability-home-building-08 > Reviewer: Meral Shirazipour > Review Date: 2015-03-21 > IETF LC End Date: 2015-03-23 > IESG Telechat date: NA > > > Summary: > This draft is ready to be published as Standards Track RFC but I have > some comments. > > Major issues: > > Minor issues: > > Nits/editorial comments: > -[Page 1], "RPL" first used in title/abstract, Would be good to spell > it out. > -[Page 5], Section 2, "Monitoring of functional correctness is at > least as important.". As important as what? (not clear) > -[Page 5], Section 2, "Devices typically communicate their status > regularly and send alarm messages notifying a malfunction of equipment > or network." > Not clear what equipment is? network node is an equipment? > -[Page 6], Section 2.1, "for large installation"--->"for a large > installation" > -[Page 8], Section 2.2.2, "fire detectors and the smoke dampers need > to be put in place to meet the stringent delay requirements." > Where can we find a value for the delay requirement of fire detectors? > A value or reference would be good. > -[Page 9], Section 2.2.4,"advanced scene and group control". Not clear > what "scene" means. > -[Page 13], Section 4.1, "assumes the role as > authoritative"--->"assumes the role of authoritative" > -[Page 16], section 4.1.8, please spell out first use CBC-MAC (Cipher > Block Chaining Message Authentication Code) > -[Page 16], section 4.1.10, it would be good to give the RFCs. > -[Page 16], section 4.2.4, MLE to spell out at first use "mesh link > establishment" > -[Page 22], "CoAp" first used in section 7.4, but spelled out in > section 8. > -[Page 18], section 5.1.1., "to throw away too late messages", how are > too late messages identified? > -[Page 27], [I-D.ietf-6lo-lowpanz] to be replaced by RFC7428 > -[Page 28], link to [occuswitch] to be verified. > -Through the document both "ms" and "msec" are used. Selecting one for > consistency would be better. > > Best Regards, > Meral > --- > Meral Shirazipour > Ericsson > Research > www.ericsson.com From nobody Mon Mar 23 11:41:16 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 439DA1AD289 for ; Mon, 23 Mar 2015 11:41:15 -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 N6dP-w09AdxT for ; Mon, 23 Mar 2015 11:41:12 -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 918311AD069 for ; Mon, 23 Mar 2015 11:41:12 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 09319E00C for ; Mon, 23 Mar 2015 14:50:59 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 2335863B76; Mon, 23 Mar 2015 14:41:11 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0FFCB636A2 for ; Mon, 23 Mar 2015 14:41:11 -0400 (EDT) From: Michael Richardson To: roll@ietf.org X-Attribution: mcr 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: Subject: [Roll] proposed amendments to ROLL charter 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, 23 Mar 2015 18:41:15 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable The following changes are proposed for the ROLL charter to include the work to profile 6553/6554/IPIP, and to compress it. To the pre-amble: After: - In most cases, LLNs will be employed over link layers with restricted frame-sizes, thus a routing protocol for LLNs should be specifically adapted for such link layers. Add: +- LLN routing protocols have to be very careful when trading off efficiency + for generality; many LLN nodes do not have resources to waste. After:=20 The solution must include unicast and multicast considerations. Add: +The Working Group will document how non-control packets are routed when th= ey +cross the LLN, and when they enter and exit the LLN: the appropriate use of +RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how routing +loops are detected. In consultation with the 6lo WG, the Working Group will +design a method to these routing headers into a single block. The result +will have a shared WGLC with 6lo. To Work Items, add: + - A document detailing when to use RFC6553, RFC6554 and IPIP + encapsulation. + + - A document detailing how to compress RFC6553, RFC6554 and IP headers + in the 6lowPAN HC context. The resulting charter (after reformatting of some of the ugly text wrapping on the web site) is: =2D--- Low power and Lossy networks (LLNs) are made up of many embedded devices with limited power, memory, and processing resources. They are interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline Communication) links. LLNs are transitioning to an end-to-end IP-based solution to avoid the problem of non-interoperable networks interconnected by protocol translation gateways and proxies. Generally speaking, LLNs have at least five distinguishing characteristics: =2D LLNs operate with a hard, very small bound on state. =2D In most cases, LLN optimize for saving energy. =2D Typical traffic patterns are not simply unicast flows (e.g. in some cas= es most if not all traffic can be point to multipoint). =2D In most cases, LLNs will be employed over link layers with restricted frame-sizes, thus a routing protocol for LLNs should be specifically adapted for such link layers. =2D LLN routing protocols have to be very careful when trading off efficien= cy for generality; many LLN nodes do not have resources to waste. These specific properties cause LLNs to have specific routing requirements. Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been evaluated by the working group and have in their current form been found to not satisfy all of these specific routing requirements. The Working Group is focused on routing issues for LLN. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (HVAC, lighting, access control, fire), connected homes, healthcare, environmental monitoring, urban sensor networks (e.g. Smart Grid), asset tracking. The Working Group focuses on routing solutions for a subset of these: industrial, connected home, building and urban sensor networks for which routing requirements have been specified. These application-specific routing requirement documents will be used for protocol design. The Working Group focuses only on IPv6 routing architectural framework for these application scenarios. The Framework will take into consideration various aspects including high reliability in the presence of time varying loss characteristics and connectivity while permitting low-power operation with very modest memory and CPU pressure in networks potentially comprising= a very large number (several thousands) of nodes. The Working Group will pay particular attention to routing security and manageability (e.g., self routing configuration) issues. It will also need = to consider the transport characteristic the routing protocol messages will experience. Mechanisms that protect an LLN from congestion collapse or that establish some degree of fairness between concurrent communication sessions are out of scope of the Working Group. It is expected that upper-layer applications utilizing LLNs define appropriate mechanisms.=20 The solution must include unicast and multicast considerations. The Working Group will document how non-control packets are routed when they cross the LLN, and when they enter and exit the LLN: the appropriate use of RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how routing loops are detected. In consultation with the 6lo WG, the Working Group will design a method to these routing headers into a single block. The result will have a shared WGLC with 6lo. Work Items: - Specification of routing metrics used in path calculation. This includes static and dynamic link/node attributes required for routin= g in LLNs. - Provide an architectural framework for routing and path selection at Layer 3 (Routing for LLN Architecture) that addresses such issues as whether LLN routing require a distributed and/or centralized path computation models, whether additional hierarchy is necessary and ho= w it is applied. Manageability will be considered with each approach, along with vari= ous trade-offs for maintaining low power operation, including the presen= ce of non-trivial loss and networks with a very large number of nodes. - Produce a routing security framework for routing in LLNs. - Protocol work: The Working Group will consider specific routing requirements from the four application documents collectively, and specify either a new protocol or extend an existing routing protocol in cooperation with the relevant Working Group. If requirements from the four target application areas cannot be met with a single protocol, the WG may choose to specify or extend more = than one protocol (this will require a recharter of the WG). - Documentation of applicability statement of ROLL routing protocols. - A document detailing when to use RFC6553, RFC6554 and IPIP encapsulation. - A document detailing how to compress RFC6553, RFC6554 and IP headers in the 6lowPAN HC context. $Id: charter.txt,v 1.3 2015/03/23 18:33:38 mcr Exp $ =2D-=20 Michael Richardson , Sandelman Software Works=20 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) iQEVAwUBVRBdG4CLcPvd0N1lAQJfIwgAsTiNK6KJ6dvKz7anD2d3y0Sh+O1zdyii BXRU2hUHXU+QWWk9N07X5LO+J1s0MmbPK5CYFJC+O7L3g/Kse1Z0H+o8NRidTdVM 24JkKMSPpcKSzgnPQx3/QPQkeAbMbx2aIvUAq5ShCUJGVbmmWy0bVcYYwyTJ7l6E 7sxFYnT9cm7HefozkisfMAFFQDEgrp56i/0yOe618I7MU/YAhAs0c8zvU7C1pbEC 1FiShdOhBccVzHLpoMJM8kqDo3hv1/0so3URzGhZ4sTLdI7SNt6xJYcrqSbB+mjs Govv84lHPHA69M6gjO/uW6yEV4acy5YEZntgiNgjJdtZboViXJET3Q== =DVQ2 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 23 11:44:12 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 8058E1AD0CE for ; Mon, 23 Mar 2015 11:44: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 qFhuNzof0HNM for ; Mon, 23 Mar 2015 11:44:07 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (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 0B45E1AD0C3 for ; Mon, 23 Mar 2015 11:44:07 -0700 (PDT) Received: by wixw10 with SMTP id w10so71888616wix.0 for ; Mon, 23 Mar 2015 11:44:05 -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=SAnbp9GHtkmAYDhWRAn/ufuaLvd8T1LwCZOEV33NMoA=; b=Z/FPiGlp+ymZsKCAMl0ROZKQ9WBY0n3FAUx17p1C+7aRIxyXrtyfIMk3lSc0y5LqN5 KpLhDJcK6cfXtk9WaCYPV0VkMqB0VOhSYiQBlsRiSZKZHeibetUPMpFCg8Uy+ZQgjC5V mwZ5udGfsopqAnB3VigJw4Eapo8PVEPR6SsA1R0pt3ct6S/lXWtNv7NWD5ms+msHT9rw gL7TaPOa3jjICzWwOzPhbcdyE0E1yzFT9V1cirepfKTPVupGP9jbexEVapUsZtOVD6xm 1yulzM387G57HdYt/osYE0/NNukkng7xFyWSgYeuOPGhlwfWlly7Wpn9bED2zZjDOdMo V+xQ== X-Received: by 10.180.76.147 with SMTP id k19mr21118529wiw.92.1427136245682; Mon, 23 Mar 2015 11:44:05 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.28.157.206 with HTTP; Mon, 23 Mar 2015 11:43:45 -0700 (PDT) In-Reply-To: <30526.1427136071@sandelman.ca> References: <30526.1427136071@sandelman.ca> From: Thomas Watteyne Date: Mon, 23 Mar 2015 13:43:45 -0500 X-Google-Sender-Auth: OfKWMYFdXVjqJ1hxUTUGMz3bHlc Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=f46d04388eb3f856ff0511f90c78 Archived-At: Subject: Re: [Roll] proposed amendments to ROLL charter 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, 23 Mar 2015 18:44:10 -0000 --f46d04388eb3f856ff0511f90c78 Content-Type: text/plain; charset=UTF-8 +1 on adding these items to ROLL charter. Editorial: "IP-in-IP encapsulation" might clearer than IPIP (your choice, not a strong opinion) On Mon, Mar 23, 2015 at 1:41 PM, Michael Richardson wrote: > > The following changes are proposed for the ROLL charter to include the work > to profile 6553/6554/IPIP, and to compress it. > > To the pre-amble: > > After: > - In most cases, LLNs will be employed over link layers with restricted > frame-sizes, thus a routing protocol for LLNs should be specifically > adapted for such link layers. > > Add: > +- LLN routing protocols have to be very careful when trading off > efficiency > + for generality; many LLN nodes do not have resources to waste. > > After: > The solution must include unicast and multicast considerations. > > Add: > +The Working Group will document how non-control packets are routed when > they > +cross the LLN, and when they enter and exit the LLN: the appropriate use > of > +RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how routing > +loops are detected. In consultation with the 6lo WG, the Working Group > will > +design a method to these routing headers into a single block. The result > +will have a shared WGLC with 6lo. > > To Work Items, add: > + - A document detailing when to use RFC6553, RFC6554 and IPIP > + encapsulation. > + > + - A document detailing how to compress RFC6553, RFC6554 and IP > headers > + in the 6lowPAN HC context. > > > The resulting charter (after reformatting of some of the ugly text wrapping > on the web site) is: > > ---- > Low power and Lossy networks (LLNs) are made up of many > embedded devices with limited power, memory, and processing > resources. They are interconnected by a variety of links, such as > IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low > power PLC (Powerline Communication) links. LLNs are transitioning > to an end-to-end IP-based solution to avoid the problem of > non-interoperable networks interconnected by protocol translation > gateways and proxies. > > Generally speaking, LLNs have at least five distinguishing > characteristics: > - LLNs operate with a hard, very small bound on state. > - In most cases, LLN optimize for saving energy. > - Typical traffic patterns are not simply unicast flows (e.g. in some > cases most if not all traffic can be point to multipoint). > - In most cases, LLNs will be employed over link layers with restricted > frame-sizes, thus a routing protocol for LLNs should be specifically > adapted for such link layers. > - LLN routing protocols have to be very careful when trading off efficiency > for generality; many LLN nodes do not have resources to waste. > > These specific properties cause LLNs to have specific routing > requirements. > > Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been > evaluated by the working group and have in their current form been found to > not satisfy all of these specific routing requirements. > > The Working Group is focused on routing issues for LLN. > > There is a wide scope of application areas for LLNs, including industrial > monitoring, building automation (HVAC, lighting, access control, fire), > connected homes, healthcare, environmental monitoring, urban sensor > networks > (e.g. Smart Grid), asset tracking. The Working Group focuses on routing > solutions for a subset of these: industrial, connected home, building and > urban sensor networks for which routing requirements have been > specified. These application-specific routing requirement documents will be > used for protocol design. > > The Working Group focuses only on IPv6 routing architectural framework for > these application scenarios. The Framework will take into consideration > various aspects including high reliability in the presence of time varying > loss characteristics and connectivity while permitting low-power operation > with very modest memory and CPU pressure in networks potentially > comprising a > very large number (several thousands) of nodes. > > The Working Group will pay particular attention to routing security and > manageability (e.g., self routing configuration) issues. It will also need > to > consider the transport characteristic the routing protocol messages will > experience. Mechanisms that protect an LLN from congestion collapse or that > establish some degree of fairness between concurrent communication sessions > are out of scope of the Working Group. It is expected that upper-layer > applications utilizing LLNs define appropriate mechanisms. > > The solution must include unicast and multicast considerations. > > The Working Group will document how non-control packets are routed when > they > cross the LLN, and when they enter and exit the LLN: the appropriate use of > RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how routing > loops are detected. In consultation with the 6lo WG, the Working Group will > design a method to these routing headers into a single block. The result > will have a shared WGLC with 6lo. > > Work Items: > > - Specification of routing metrics used in path calculation. This > includes static and dynamic link/node attributes required for > routing in > LLNs. > > - Provide an architectural framework for routing and path selection at > Layer 3 (Routing for LLN Architecture) that addresses such issues as > whether LLN routing require a distributed and/or centralized path > computation models, whether additional hierarchy is necessary and > how it > is applied. > > Manageability will be considered with each approach, along with > various > trade-offs for maintaining low power operation, including the > presence of > non-trivial loss and networks with a very large number of nodes. > > - Produce a routing security framework for routing in LLNs. > > - Protocol work: The Working Group will consider specific routing > requirements from the four application documents collectively, and > specify either a new protocol or extend an existing routing protocol > in cooperation with the relevant Working Group. > If requirements from the four target application areas cannot be met > with a single protocol, the WG may choose to specify or extend more > than > one protocol (this will require a recharter of the WG). > > - Documentation of applicability statement of ROLL routing protocols. > > - A document detailing when to use RFC6553, RFC6554 and IPIP > encapsulation. > > - A document detailing how to compress RFC6553, RFC6554 and IP headers > in the 6lowPAN HC context. > > > > $Id: charter.txt,v 1.3 2015/03/23 18:33:38 mcr Exp $ > > > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --f46d04388eb3f856ff0511f90c78 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 on adding these items to ROLL charter.

Editorial: "IP-in-IP encapsulation" might clear= er than IPIP (your choice, not a strong opinion)

On Mon, Mar 23, 2015 at 1:41 PM,= Michael Richardson <mcr+ietf@sandelman.ca> wrote:

The following changes are proposed for the ROLL charter to include the work=
to profile 6553/6554/IPIP, and to compress it.

To the pre-amble:

After:
=C2=A0- In most cases, LLNs will be employed over link layers with restrict= ed
=C2=A0 =C2=A0frame-sizes, thus a routing protocol for LLNs should be specif= ically
=C2=A0 =C2=A0adapted for such link layers.

Add:
+- LLN routing protocols have to be very careful when trading off efficienc= y
+=C2=A0 for generality; many LLN nodes do not have resources to waste.

After:
=C2=A0The solution must include unicast and multicast considerations.

Add:
+The Working Group will document how non-control packets are routed when th= ey
+cross the LLN, and when they enter and exit the LLN: the appropriate use o= f
+RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how routing<= br> +loops are detected. In consultation with the 6lo WG, the Working Group wil= l
+design a method to these routing headers into a single block.=C2=A0 The re= sult
+will have a shared WGLC with 6lo.

To=C2=A0 Work Items, add:
+=C2=A0 =C2=A0 =C2=A0- A document detailing when to use RFC6553, RFC6554 an= d IPIP
+=C2=A0 =C2=A0 =C2=A0 =C2=A0encapsulation.
+
+=C2=A0 =C2=A0 =C2=A0- A document detailing how to compress RFC6553, RFC655= 4 and IP headers
+=C2=A0 =C2=A0 =C2=A0 =C2=A0in the 6lowPAN HC context.


The resulting charter (after reformatting of some of the ugly text wrapping=
on the web site) is:

----
Low power and Lossy networks (LLNs) are made up of many
embedded devices with limited power, memory, and processing
resources. They are interconnected by a variety of links, such as
IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low
power PLC (Powerline Communication) links. LLNs are transitioning
to an end-to-end IP-based solution to avoid the problem of
non-interoperable networks interconnected by protocol translation
gateways and proxies.

Generally speaking, LLNs have at least five distinguishing
characteristics:
- LLNs operate with a hard, very small bound on state.
- In most cases, LLN optimize for saving energy.
- Typical traffic patterns are not simply unicast flows (e.g. in some cases= most if not all traffic can be point to multipoint).
- In most cases, LLNs will be employed over link layers with restricted
=C2=A0 frame-sizes, thus a routing protocol for LLNs should be specifically=
=C2=A0 adapted for such link layers.
- LLN routing protocols have to be very careful when trading off efficiency=
=C2=A0 for generality; many LLN nodes do not have resources to waste.

These specific properties cause LLNs to have specific routing
requirements.

Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been evaluated by the working group and have in their current form been found to=
not satisfy all of these specific routing requirements.

The Working Group is focused on routing issues for LLN.

There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (HVAC, lighting, access control, fire),
connected homes, healthcare, environmental monitoring, urban sensor network= s
(e.g. Smart Grid), asset tracking. The Working Group focuses on routing
solutions for a subset of these: industrial, connected home, building and urban sensor networks for which routing requirements have been
specified. These application-specific routing requirement documents will be=
used for protocol design.

The Working Group focuses only on IPv6 routing architectural framework for<= br> these application scenarios. The Framework will take into consideration
various aspects including high reliability in the presence of time varying<= br> loss characteristics and connectivity while permitting low-power operation<= br> with very modest memory and CPU pressure in networks potentially comprising= a
very large number (several thousands) of nodes.

The Working Group will pay particular attention to routing security and
manageability (e.g., self routing configuration) issues. It will also need = to
consider the transport characteristic the routing protocol messages will experience. Mechanisms that protect an LLN from congestion collapse or that=
establish some degree of fairness between concurrent communication sessions=
are out of scope of the Working Group. It is expected that upper-layer
applications utilizing LLNs define appropriate mechanisms.

The solution must include unicast and multicast considerations.

The Working Group will document how non-control packets are routed when the= y
cross the LLN, and when they enter and exit the LLN: the appropriate use of=
RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how routing loops are detected. In consultation with the 6lo WG, the Working Group will=
design a method to these routing headers into a single block.=C2=A0 The res= ult
will have a shared WGLC with 6lo.

Work Items:

=C2=A0 =C2=A0 =C2=A0- Specification of routing metrics used in path calcula= tion. This
=C2=A0 =C2=A0 =C2=A0 =C2=A0includes static and dynamic link/node attributes= required for routing in
=C2=A0 =C2=A0 =C2=A0 =C2=A0LLNs.

=C2=A0 =C2=A0 =C2=A0- Provide an architectural framework for routing and pa= th selection at
=C2=A0 =C2=A0 =C2=A0 =C2=A0Layer 3 (Routing for LLN Architecture) that addr= esses such issues as
=C2=A0 =C2=A0 =C2=A0 =C2=A0whether LLN routing require a distributed and/or= centralized path
=C2=A0 =C2=A0 =C2=A0 =C2=A0computation models, whether additional hierarchy= is necessary and how it
=C2=A0 =C2=A0 =C2=A0 =C2=A0is applied.

=C2=A0 =C2=A0 =C2=A0 =C2=A0Manageability will be considered with each appro= ach, along with various
=C2=A0 =C2=A0 =C2=A0 =C2=A0trade-offs for maintaining low power operation, = including the presence of
=C2=A0 =C2=A0 =C2=A0 =C2=A0non-trivial loss and networks with a very large = number of nodes.

=C2=A0 =C2=A0 =C2=A0- Produce a routing security framework for routing in L= LNs.

=C2=A0 =C2=A0 =C2=A0- Protocol work: The Working Group will consider specif= ic routing
=C2=A0 =C2=A0 =C2=A0 =C2=A0requirements from the four application documents= collectively, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0specify either a new protocol or extend an exist= ing routing protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0in cooperation with the relevant Working Group.<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0If requirements from the four target application= areas cannot be met
=C2=A0 =C2=A0 =C2=A0 =C2=A0with a single protocol, the WG may choose to spe= cify or extend more than
=C2=A0 =C2=A0 =C2=A0 =C2=A0one protocol (this will require a recharter of t= he WG).

=C2=A0 =C2=A0 =C2=A0- Documentation of applicability statement of ROLL rout= ing protocols.

=C2=A0 =C2=A0 =C2=A0- A document detailing when to use RFC6553, RFC6554 and= IPIP
=C2=A0 =C2=A0 =C2=A0 =C2=A0encapsulation.

=C2=A0 =C2=A0 =C2=A0- A document detailing how to compress RFC6553, RFC6554= and IP headers
=C2=A0 =C2=A0 =C2=A0 =C2=A0in the 6lowPAN HC context.



$Id: charter.txt,v 1.3 2015/03/23 18:33:38 mcr Exp $



--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
IETF ROLL WG co-chair.=C2=A0 =C2=A0 http://datatracker.ietf.org/wg/roll/cha= rter/


_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll


--f46d04388eb3f856ff0511f90c78-- From nobody Mon Mar 23 11:51: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 658CA1AD0CE for ; Mon, 23 Mar 2015 11:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 p5wtTw6h4Pjt for ; Mon, 23 Mar 2015 11:51:07 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0740.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::740]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 449F81AD2C0 for ; Mon, 23 Mar 2015 11:51:06 -0700 (PDT) Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com (10.242.221.22) by DB4PR01MB0430.eurprd01.prod.exchangelabs.com (10.242.221.21) with Microsoft SMTP Server (TLS) id 15.1.118.21; Mon, 23 Mar 2015 18:50:48 +0000 Received: from DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) by DB4PR01MB0431.eurprd01.prod.exchangelabs.com ([10.242.221.22]) with mapi id 15.01.0118.021; Mon, 23 Mar 2015 18:50:47 +0000 From: "Turner, Randy" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] proposed amendments to ROLL charter Thread-Index: AQHQZZj1v7J7klL7k0mqWWPDm9kW/50qZ2OA//++5QA= Date: Mon, 23 Mar 2015 18:50:47 +0000 Message-ID: References: <30526.1427136071@sandelman.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [31.133.136.167] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR01MB0430; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(24454002)(377454003)(479174004)(66066001)(102836002)(15975445007)(77096005)(122556002)(110136001)(2950100001)(36756003)(19617315012)(92566002)(50986999)(46102003)(2900100001)(87936001)(40100003)(450100001)(107886001)(5890100001)(62966003)(77156002)(16297215004)(106116001)(86362001)(83506001)(19580405001)(54356999)(16236675004)(2656002)(19580395003)(76176999)(24704002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR01MB0430; H:DB4PR01MB0431.eurprd01.prod.exchangelabs.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:DB4PR01MB0430; BCL:0; PCL:0; RULEID:; SRVR:DB4PR01MB0430; x-forefront-prvs: 05245CA661 Content-Type: multipart/alternative; boundary="_000_D135D88C6C06randyturnerlandisgyrcom_" MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2015 18:50:47.3072 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ee2cd48b-958f-4be4-9852-b8f104c001b9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR01MB0430 Archived-At: Subject: Re: [Roll] proposed amendments to ROLL charter 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, 23 Mar 2015 18:51:10 -0000 --_000_D135D88C6C06randyturnerlandisgyrcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 on detailing when/why/how ip-in-ip tunnels should be used in, out, throu= gh LLNs R. From: Thomas Watteyne > Reply-To: "roll@ietf.org" > Date: Monday, March 23, 2015 at 2:43 PM To: "roll@ietf.org" > Subject: Re: [Roll] proposed amendments to ROLL charter +1 on adding these items to ROLL charter. Editorial: "IP-in-IP encapsulation" might clearer than IPIP (your choice, n= ot a strong opinion) On Mon, Mar 23, 2015 at 1:41 PM, Michael Richardson > wrote: The following changes are proposed for the ROLL charter to include the work to profile 6553/6554/IPIP, and to compress it. To the pre-amble: After: - In most cases, LLNs will be employed over link layers with restricted frame-sizes, thus a routing protocol for LLNs should be specifically adapted for such link layers. Add: +- LLN routing protocols have to be very careful when trading off efficienc= y + for generality; many LLN nodes do not have resources to waste. After: The solution must include unicast and multicast considerations. Add: +The Working Group will document how non-control packets are routed when th= ey +cross the LLN, and when they enter and exit the LLN: the appropriate use o= f +RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how routing +loops are detected. In consultation with the 6lo WG, the Working Group wil= l +design a method to these routing headers into a single block. The result +will have a shared WGLC with 6lo. To Work Items, add: + - A document detailing when to use RFC6553, RFC6554 and IPIP + encapsulation. + + - A document detailing how to compress RFC6553, RFC6554 and IP header= s + in the 6lowPAN HC context. The resulting charter (after reformatting of some of the ugly text wrapping on the web site) is: ---- Low power and Lossy networks (LLNs) are made up of many embedded devices with limited power, memory, and processing resources. They are interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline Communication) links. LLNs are transitioning to an end-to-end IP-based solution to avoid the problem of non-interoperable networks interconnected by protocol translation gateways and proxies. Generally speaking, LLNs have at least five distinguishing characteristics: - LLNs operate with a hard, very small bound on state. - In most cases, LLN optimize for saving energy. - Typical traffic patterns are not simply unicast flows (e.g. in some cases= most if not all traffic can be point to multipoint). - In most cases, LLNs will be employed over link layers with restricted frame-sizes, thus a routing protocol for LLNs should be specifically adapted for such link layers. - LLN routing protocols have to be very careful when trading off efficiency for generality; many LLN nodes do not have resources to waste. These specific properties cause LLNs to have specific routing requirements. Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been evaluated by the working group and have in their current form been found to not satisfy all of these specific routing requirements. The Working Group is focused on routing issues for LLN. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (HVAC, lighting, access control, fire), connected homes, healthcare, environmental monitoring, urban sensor network= s (e.g. Smart Grid), asset tracking. The Working Group focuses on routing solutions for a subset of these: industrial, connected home, building and urban sensor networks for which routing requirements have been specified. These application-specific routing requirement documents will be used for protocol design. The Working Group focuses only on IPv6 routing architectural framework for these application scenarios. The Framework will take into consideration various aspects including high reliability in the presence of time varying loss characteristics and connectivity while permitting low-power operation with very modest memory and CPU pressure in networks potentially comprising= a very large number (several thousands) of nodes. The Working Group will pay particular attention to routing security and manageability (e.g., self routing configuration) issues. It will also need = to consider the transport characteristic the routing protocol messages will experience. Mechanisms that protect an LLN from congestion collapse or that establish some degree of fairness between concurrent communication sessions are out of scope of the Working Group. It is expected that upper-layer applications utilizing LLNs define appropriate mechanisms. The solution must include unicast and multicast considerations. The Working Group will document how non-control packets are routed when the= y cross the LLN, and when they enter and exit the LLN: the appropriate use of RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how routing loops are detected. In consultation with the 6lo WG, the Working Group will design a method to these routing headers into a single block. The result will have a shared WGLC with 6lo. Work Items: - Specification of routing metrics used in path calculation. This includes static and dynamic link/node attributes required for routin= g in LLNs. - Provide an architectural framework for routing and path selection at Layer 3 (Routing for LLN Architecture) that addresses such issues as whether LLN routing require a distributed and/or centralized path computation models, whether additional hierarchy is necessary and ho= w it is applied. Manageability will be considered with each approach, along with vari= ous trade-offs for maintaining low power operation, including the presen= ce of non-trivial loss and networks with a very large number of nodes. - Produce a routing security framework for routing in LLNs. - Protocol work: The Working Group will consider specific routing requirements from the four application documents collectively, and specify either a new protocol or extend an existing routing protocol in cooperation with the relevant Working Group. If requirements from the four target application areas cannot be met with a single protocol, the WG may choose to specify or extend more = than one protocol (this will require a recharter of the WG). - Documentation of applicability statement of ROLL routing protocols. - A document detailing when to use RFC6553, RFC6554 and IPIP encapsulation. - A document detailing how to compress RFC6553, RFC6554 and IP headers in the 6lowPAN HC context. $Id: charter.txt,v 1.3 2015/03/23 18:33:38 mcr Exp $ -- Michael Richardson >,= Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be legally = privileged. If you are not an intended recipient or an authorized represent= ative of an intended recipient, you are prohibited from using, copying or d= istributing the information in this e-mail or its attachments. If you have = received this e-mail in error, please notify the sender immediately by retu= rn e-mail and delete all copies of this message and any attachments. Thank = you. --_000_D135D88C6C06randyturnerlandisgyrcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
+1 on detailing when/why/how ip-in-ip tunnels should be used in, o= ut, through LLNs 

R.

From: Thomas Watteyne <watteyne@eecs.berkeley.edu> Reply-To: "roll@ietf.org" <= roll@ietf.org>
Date: Monday, March 23, 2015 at 2:4= 3 PM
To: "roll@ietf.org" <roll@i= etf.org>
Subject: Re: [Roll] proposed amendm= ents to ROLL charter

+1 on adding these items to ROLL charter.

Editorial: "IP-in-IP encapsulation" might clearer than IPIP = (your choice, not a strong opinion)

On Mon, Mar 23, 2015 at 1:41 PM, Michael Richard= son <mcr+= ietf@sandelman.ca> wrote:

The following changes are proposed for the ROLL charter to include the work=
to profile 6553/6554/IPIP, and to compress it.

To the pre-amble:

After:
 - In most cases, LLNs will be employed over link layers with restrict= ed
   frame-sizes, thus a routing protocol for LLNs should be specif= ically
   adapted for such link layers.

Add:
+- LLN routing protocols have to be very careful when trading off effic= iency
+  for generality; many LLN nodes do not have resources to waste.<= br>
After:
 The solution must include unicast and multicast considerations.

Add:
+The Working Group will document how non-control packets are routed whe= n they
+cross the LLN, and when they enter and exit the LLN: the appropriate u= se of
+RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how rout= ing
+loops are detected. In consultation with the 6lo WG, the Working Group= will
+design a method to these routing headers into a single block.  Th= e result
+will have a shared WGLC with 6lo.

To  Work Items, add:
+     - A document detailing when to use RFC6553, RFC655= 4 and IPIP
+       encapsulation.
+
+     - A document detailing how to compress RFC6553, RF= C6554 and IP headers
+       in the 6lowPAN HC context.


The resulting charter (after reformatting of some of the ugly text wrapping=
on the web site) is:

----
Low power and Lossy networks (LLNs) are made up of many
embedded devices with limited power, memory, and processing
resources. They are interconnected by a variety of links, such as
IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low
power PLC (Powerline Communication) links. LLNs are transitioning
to an end-to-end IP-based solution to avoid the problem of
non-interoperable networks interconnected by protocol translation
gateways and proxies.

Generally speaking, LLNs have at least five distinguishing
characteristics:
- LLNs operate with a hard, very small bound on state.
- In most cases, LLN optimize for saving energy.
- Typical traffic patterns are not simply unicast flows (e.g. in some cases= most if not all traffic can be point to multipoint).
- In most cases, LLNs will be employed over link layers with restricted
  frame-sizes, thus a routing protocol for LLNs should be specifically=
  adapted for such link layers.
- LLN routing protocols have to be very careful when trading off efficiency=
  for generality; many LLN nodes do not have resources to waste.

These specific properties cause LLNs to have specific routing
requirements.

Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been evaluated by the working group and have in their current form been found to=
not satisfy all of these specific routing requirements.

The Working Group is focused on routing issues for LLN.

There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (HVAC, lighting, access control, fire),
connected homes, healthcare, environmental monitoring, urban sensor network= s
(e.g. Smart Grid), asset tracking. The Working Group focuses on routing
solutions for a subset of these: industrial, connected home, building and urban sensor networks for which routing requirements have been
specified. These application-specific routing requirement documents will be=
used for protocol design.

The Working Group focuses only on IPv6 routing architectural framework for<= br> these application scenarios. The Framework will take into consideration
various aspects including high reliability in the presence of time varying<= br> loss characteristics and connectivity while permitting low-power operation<= br> with very modest memory and CPU pressure in networks potentially comprising= a
very large number (several thousands) of nodes.

The Working Group will pay particular attention to routing security and
manageability (e.g., self routing configuration) issues. It will also need = to
consider the transport characteristic the routing protocol messages will experience. Mechanisms that protect an LLN from congestion collapse or that=
establish some degree of fairness between concurrent communication sessions=
are out of scope of the Working Group. It is expected that upper-layer
applications utilizing LLNs define appropriate mechanisms.

The solution must include unicast and multicast considerations.

The Working Group will document how non-control packets are routed when the= y
cross the LLN, and when they enter and exit the LLN: the appropriate use of=
RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how routing loops are detected. In consultation with the 6lo WG, the Working Group will=
design a method to these routing headers into a single block.  The res= ult
will have a shared WGLC with 6lo.

Work Items:

     - Specification of routing metrics used in path calcula= tion. This
       includes static and dynamic link/node attributes= required for routing in
       LLNs.

     - Provide an architectural framework for routing and pa= th selection at
       Layer 3 (Routing for LLN Architecture) that addr= esses such issues as
       whether LLN routing require a distributed and/or= centralized path
       computation models, whether additional hierarchy= is necessary and how it
       is applied.

       Manageability will be considered with each appro= ach, along with various
       trade-offs for maintaining low power operation, = including the presence of
       non-trivial loss and networks with a very large = number of nodes.

     - Produce a routing security framework for routing in L= LNs.

     - Protocol work: The Working Group will consider specif= ic routing
       requirements from the four application documents= collectively, and
       specify either a new protocol or extend an exist= ing routing protocol
       in cooperation with the relevant Working Group.<= br>        If requirements from the four target application= areas cannot be met
       with a single protocol, the WG may choose to spe= cify or extend more than
       one protocol (this will require a recharter of t= he WG).

     - Documentation of applicability statement of ROLL rout= ing protocols.

     - A document detailing when to use RFC6553, RFC6554 and= IPIP
       encapsulation.

     - A document detailing how to compress RFC6553, RFC6554= and IP headers
       in the 6lowPAN HC context.



$Id: charter.txt,v 1.3 2015/03/23 18:33:38 mcr Exp $



--
Michael Richardson <mcr+I= ETF@sandelman.ca>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/


_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

P PLEA= SE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is con= fidential and may be legally privileged. If you are not an intended recipie= nt or an authorized representative of an intended recipient, you are prohib= ited from using, copying or distributing the information in this e-mail or its attachments. If you have received th= is e-mail in error, please notify the sender immediately by return e-mail a= nd delete all copies of this message and any attachments. Thank you.

--_000_D135D88C6C06randyturnerlandisgyrcom_-- From nobody Mon Mar 23 12:12: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 EF8251A005C; Mon, 23 Mar 2015 12:12:44 -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 n0Qr-6LceuRk; Mon, 23 Mar 2015 12:12:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A631A005F; Mon, 23 Mar 2015 12:12: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: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150323191242.11868.80849.idtracker@ietfa.amsl.com> Date: Mon, 23 Mar 2015 12:12: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: Mon, 23 Mar 2015 19:12:45 -0000 IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead Just need to pick up some minor GenArt review points. ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ From nobody Mon Mar 23 12:22:11 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-applicability-home-building.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 4E61B1A0063; Mon, 23 Mar 2015 12:12:25 -0700 (PDT) X-Original-To: xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B231AD2C0 for ; Mon, 23 Mar 2015 12:12:25 -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=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 gH9W1FKTW5CV for ; Mon, 23 Mar 2015 12:12:21 -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 DDE001A005C for ; Mon, 23 Mar 2015 12:12:19 -0700 (PDT) Received: from asmtp4.iomartmail.com ([62.128.201.175]:55242) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Ya7lq-0003x2-5c for draft-ietf-roll-applicability-home-building.all@tools.ietf.org; Mon, 23 Mar 2015 12:12:19 -0700 Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t2NJC593009089; Mon, 23 Mar 2015 19:12:05 GMT Received: from 950129200 (dhcp-b383.meeting.ietf.org [31.133.179.131]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t2NJC1Mp008971 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2015 19:12:03 GMT From: "Adrian Farrel" To: , "'Meral Shirazipour'" References: In-Reply-To: Date: Mon, 23 Mar 2015 19:12:00 -0000 Message-ID: <034001d0659d$3f922e80$beb68b80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEY62HJIfSX+k8Ggf3dWVdc7CCiGAH6kfQ5nomOs4A= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21420.001 X-TM-AS-Result: No--24.465-10.0-31-10 X-imss-scan-details: No--24.465-10.0-31-10 X-TMASE-MatchedRID: EMyCvCfVN1Hfk3h2g6+qcLiMC5wdwKqd1WWRh/D0YAAM74Nf6tTB9gC+ sRw3LkeYqqWackuRwGg9Lf0kHQYluKMb9ZRAzSYj8eSmTJSmEv23uToEMyUHWFeSjsrUUh2RPoP IZOsDa27FOK/wVLIhcrElmVtHhdr2ZF6ysdFjt0rY5KPiokD1BmWuy5Lm0L4/RfmFzyKgHb7inP xDc1PMX1xJteLegn0S1FvdD28YZvXTmkhQne/OJCGwgpQxZIDmnaX53Dhf9FnkMnUVL5d0E/6Qk uR+7My9NqsbRxgjTNkBCtgvuWiKA/xQj1NmxcbEoiN8YTmq+csZbpN+hw0Ke4aKwv8Fn/09wHX2 /CN/35uqCRTto1npm/oERG0Wa3yX82znWvTf6dG5OP59hhqaSJZ6zKu0q4rtOrPlhEXymRkI1Vj kwG8ptrJ+6dTRvlC2Ve/hbtrzRSsbWzRVg8ssDLMjW/sniEQKgHzgwy8qV5ocQXgzaVXEcl1vhP 4olLdxezpYyIGH5Cv5/RJEIHFkjP4Tv2b0QtTAQr2qXCJMSV99LQinZ4QefL6qvLNjDYTwzz3je hzeneyrusVRy4an8bxAi7jPoeEQftwZ3X11IV0= X-SA-Exim-Connect-IP: 62.128.201.175 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-home-building.all@tools.ietf.org X-SA-Exim-Mail-From: adrian@olddog.co.uk 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-applicability-home-building.all@ietf.org Resent-Message-Id: <20150323191219.DDE001A005C@ietfa.amsl.com> Resent-Date: Mon, 23 Mar 2015 12:12:19 -0700 (PDT) Resent-From: adrian@olddog.co.uk Archived-At: Archived-At: X-Mailman-Approved-At: Mon, 23 Mar 2015 12:22:09 -0700 Cc: gen-art@ietf.org, draft-ietf-roll-applicability-home-building.all@tools.ietf.org Subject: Re: [Roll] Gen-ART Last Call review of draft-ietf-roll-applicability-home-building-08 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk, 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, 23 Mar 2015 19:12:25 -0000 Hi Peter, This all looks good. The changes are small, but it would be worth catching them in a new revision. Please post it when you have it, no need to check with me. Once you've done that, we'll hand it over to Alvaro as the incoming AD, and he can put it on an IESG telechat. Cheers, Adrian > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: 23 March 2015 14:49 > To: Meral Shirazipour > Cc: draft-ietf-roll-applicability-home-building.all@tools.ietf.org; gen-art@ietf.org > Subject: Re: Gen-ART Last Call review of draft-ietf-roll-applicability-home- > building-08 > > HI Meral, > > Thanks for the suggestions. > I have no problem with any of them. I think they are quite justified. > Thank you very much for pointing them out. > Concerning scene and group control. I may suppress the word "scene". > About [occuswitch] I have to look for a valid alternative. However, > these links are maintained by a company, which changes information > frequently. > Sorry for missing out some of the acronyms. I thought I caught them out > all. > > Greetings, > > Peter > > > Meral Shirazipour schreef op 2015-03-22 21:28: > > I am the assigned Gen-ART reviewer for this draft. For background on > > Gen-ART, please see the FAQ at > > http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. > > > > Please resolve these comments along with any other Last Call comments > > you may receive. > > > > Document: draft-ietf-roll-applicability-home-building-08 > > Reviewer: Meral Shirazipour > > Review Date: 2015-03-21 > > IETF LC End Date: 2015-03-23 > > IESG Telechat date: NA > > > > > > Summary: > > This draft is ready to be published as Standards Track RFC but I have > > some comments. > > > > Major issues: > > > > Minor issues: > > > > Nits/editorial comments: > > -[Page 1], "RPL" first used in title/abstract, Would be good to spell > > it out. > > -[Page 5], Section 2, "Monitoring of functional correctness is at > > least as important.". As important as what? (not clear) > > -[Page 5], Section 2, "Devices typically communicate their status > > regularly and send alarm messages notifying a malfunction of equipment > > or network." > > Not clear what equipment is? network node is an equipment? > > -[Page 6], Section 2.1, "for large installation"--->"for a large > > installation" > > -[Page 8], Section 2.2.2, "fire detectors and the smoke dampers need > > to be put in place to meet the stringent delay requirements." > > Where can we find a value for the delay requirement of fire detectors? > > A value or reference would be good. > > -[Page 9], Section 2.2.4,"advanced scene and group control". Not clear > > what "scene" means. > > -[Page 13], Section 4.1, "assumes the role as > > authoritative"--->"assumes the role of authoritative" > > -[Page 16], section 4.1.8, please spell out first use CBC-MAC (Cipher > > Block Chaining Message Authentication Code) > > -[Page 16], section 4.1.10, it would be good to give the RFCs. > > -[Page 16], section 4.2.4, MLE to spell out at first use "mesh link > > establishment" > > -[Page 22], "CoAp" first used in section 7.4, but spelled out in > > section 8. > > -[Page 18], section 5.1.1., "to throw away too late messages", how are > > too late messages identified? > > -[Page 27], [I-D.ietf-6lo-lowpanz] to be replaced by RFC7428 > > -[Page 28], link to [occuswitch] to be verified. > > -Through the document both "ms" and "msec" are used. Selecting one for > > consistency would be better. > > > > Best Regards, > > Meral > > --- > > Meral Shirazipour > > Ericsson > > Research > > www.ericsson.com From nobody Mon Mar 23 12:22:13 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-applicability-home-building.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id A07681B29A9; Mon, 23 Mar 2015 12:19:43 -0700 (PDT) X-Original-To: xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852131A000D for ; Mon, 23 Mar 2015 12:19:43 -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 h1-zHNOxObNi for ; Mon, 23 Mar 2015 12:19:42 -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 AB6821AD47E for ; Mon, 23 Mar 2015 12:19:26 -0700 (PDT) Received: from lb1-smtp-cloud3.xs4all.net ([194.109.24.22]:55525) by merlot.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.84) (envelope-from ) id 1Ya7sE-0007bH-Cg for draft-ietf-roll-applicability-home-building.all@tools.ietf.org; Mon, 23 Mar 2015 20:19:04 +0100 Received: from roundcube.xs4all.nl ([194.109.20.209]) by smtp-cloud3.xs4all.net with ESMTP id 77JE1q0054WfiVN017JEDS; Mon, 23 Mar 2015 20:18:15 +0100 Received: from [2001:67c:370:160:d513:7d2a:a738:f71] by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 23 Mar 2015 20:18:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 23 Mar 2015 20:18:14 +0100 From: peter van der Stok To: adrian@olddog.co.uk Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <034001d0659d$3f922e80$beb68b80$@olddog.co.uk> References: <034001d0659d$3f922e80$beb68b80$@olddog.co.uk> Message-ID: <77422d9da91623e83c5f62bd1451fb63@xs4all.nl> X-Sender: stokcons@xs4all.nl (rP/SZ08caKzFr6sVOhmZ+O7m+EpbzZrl) User-Agent: XS4ALL Webmail X-SA-Exim-Connect-IP: 194.109.24.22 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-home-building.all@tools.ietf.org X-SA-Exim-Mail-From: stokcons@xs4all.nl 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-applicability-home-building.all@ietf.org Resent-Message-Id: <20150323191926.AB6821AD47E@ietfa.amsl.com> Resent-Date: Mon, 23 Mar 2015 12:19:26 -0700 (PDT) Resent-From: stokcons@xs4all.nl Archived-At: Archived-At: X-Mailman-Approved-At: Mon, 23 Mar 2015 12:22:09 -0700 Cc: 'Meral Shirazipour' , gen-art@ietf.org, draft-ietf-roll-applicability-home-building.all@tools.ietf.org Subject: Re: [Roll] Gen-ART Last Call review of draft-ietf-roll-applicability-home-building-08 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.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: Mon, 23 Mar 2015 19:19:43 -0000 Hi Adrian, good news. I try to do the update this week. Greetings, thanks, Peter Adrian Farrel schreef op 2015-03-23 20:12: > Hi Peter, > > This all looks good. > The changes are small, but it would be worth catching them in a new > revision. > Please post it when you have it, no need to check with me. > > Once you've done that, we'll hand it over to Alvaro as the incoming AD, > and he > can put it on an IESG telechat. > > Cheers, > Adrian > > >> -----Original Message----- >> From: peter van der Stok [mailto:stokcons@xs4all.nl] >> Sent: 23 March 2015 14:49 >> To: Meral Shirazipour >> Cc: draft-ietf-roll-applicability-home-building.all@tools.ietf.org; > gen-art@ietf.org >> Subject: Re: Gen-ART Last Call review of >> draft-ietf-roll-applicability-home- >> building-08 >> >> HI Meral, >> >> Thanks for the suggestions. >> I have no problem with any of them. I think they are quite justified. >> Thank you very much for pointing them out. >> Concerning scene and group control. I may suppress the word "scene". >> About [occuswitch] I have to look for a valid alternative. However, >> these links are maintained by a company, which changes information >> frequently. >> Sorry for missing out some of the acronyms. I thought I caught them >> out >> all. >> >> Greetings, >> >> Peter >> >> >> Meral Shirazipour schreef op 2015-03-22 21:28: >> > I am the assigned Gen-ART reviewer for this draft. For background on >> > Gen-ART, please see the FAQ at >> > http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. >> > >> > Please resolve these comments along with any other Last Call comments >> > you may receive. >> > >> > Document: draft-ietf-roll-applicability-home-building-08 >> > Reviewer: Meral Shirazipour >> > Review Date: 2015-03-21 >> > IETF LC End Date: 2015-03-23 >> > IESG Telechat date: NA >> > >> > >> > Summary: >> > This draft is ready to be published as Standards Track RFC but I have >> > some comments. >> > >> > Major issues: >> > >> > Minor issues: >> > >> > Nits/editorial comments: >> > -[Page 1], "RPL" first used in title/abstract, Would be good to spell >> > it out. >> > -[Page 5], Section 2, "Monitoring of functional correctness is at >> > least as important.". As important as what? (not clear) >> > -[Page 5], Section 2, "Devices typically communicate their status >> > regularly and send alarm messages notifying a malfunction of equipment >> > or network." >> > Not clear what equipment is? network node is an equipment? >> > -[Page 6], Section 2.1, "for large installation"--->"for a large >> > installation" >> > -[Page 8], Section 2.2.2, "fire detectors and the smoke dampers need >> > to be put in place to meet the stringent delay requirements." >> > Where can we find a value for the delay requirement of fire detectors? >> > A value or reference would be good. >> > -[Page 9], Section 2.2.4,"advanced scene and group control". Not clear >> > what "scene" means. >> > -[Page 13], Section 4.1, "assumes the role as >> > authoritative"--->"assumes the role of authoritative" >> > -[Page 16], section 4.1.8, please spell out first use CBC-MAC (Cipher >> > Block Chaining Message Authentication Code) >> > -[Page 16], section 4.1.10, it would be good to give the RFCs. >> > -[Page 16], section 4.2.4, MLE to spell out at first use "mesh link >> > establishment" >> > -[Page 22], "CoAp" first used in section 7.4, but spelled out in >> > section 8. >> > -[Page 18], section 5.1.1., "to throw away too late messages", how are >> > too late messages identified? >> > -[Page 27], [I-D.ietf-6lo-lowpanz] to be replaced by RFC7428 >> > -[Page 28], link to [occuswitch] to be verified. >> > -Through the document both "ms" and "msec" are used. Selecting one for >> > consistency would be better. >> > >> > Best Regards, >> > Meral >> > --- >> > Meral Shirazipour >> > Ericsson >> > Research >> > www.ericsson.com From nobody Mon Mar 23 12:40: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 31BBA1B29EB for ; Mon, 23 Mar 2015 12:40:53 -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 jQ3H_qT75DzW for ; Mon, 23 Mar 2015 12:40:51 -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 ADF241B29E2 for ; Mon, 23 Mar 2015 12:40:51 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 03E91203BD for ; Mon, 23 Mar 2015 15:50:39 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id F2E9F63B76; Mon, 23 Mar 2015 15:40:50 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E3E93636A2 for ; Mon, 23 Mar 2015 15:40:50 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: <30526.1427136071@sandelman.ca> 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: Subject: Re: [Roll] proposed amendments to ROLL charter 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, 23 Mar 2015 19:40:53 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Thomas Watteyne wrote: > Editorial: "IP-in-IP encapsulation" might clearer than IPIP (your > choice, not a strong opinion) Done. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVRBsP4CLcPvd0N1lAQLD8Qf/f8JmYRkkMrDDVeI30E4BMHTSDdfCOgMu VWD+IEgbriMmZbySEvNwEGZ8oC/qIfa7PwUdwhBilttgZDWmQf5uBvUtEB11qdKS 9cnkeDc+OXLbGgHXfBvwUmcrTdJ+4uWD2BSH4QBcUQWxqOnUAWvcyGRQSEI8KjIK rODh3E7oqfs2at25A/qt+iHc05ZY/2MY89ncmx9wwzLJNp9l1xQUMYWftXvpW0Rp e0PzxkB3hrfmpSR887tLIP8udZJmq5LnFtAztahN4T3voY33PwsGpD3dN8dwG5Pd VbVOUqc42II1+lWwfljIQXlpVoX9SjnWSSKtETQpYTz0IaY5AJnj0w== =WEpF -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 23 13:10:36 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 C638B1B29B6 for ; Mon, 23 Mar 2015 13:10:31 -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 FkKh9LWePOSW for ; Mon, 23 Mar 2015 13:10:24 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (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 CB7AF1ACC81 for ; Mon, 23 Mar 2015 13:10:23 -0700 (PDT) Received: by wixw10 with SMTP id w10so74055550wix.0 for ; Mon, 23 Mar 2015 13:10:22 -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:date:message-id:subject :from:to:content-type; bh=ioYGFYitU5/nGDcPDZfpY/B7/15ONQi0zV9R8+gux/8=; b=Hulpa+rUl2m5ruweVFEzmBc+YzKkrDyEvIYg8mJBR2ZeBWumMaO+Z0Ci+y2e7nFchh GAnslymWLfHix0NzmhKIAp4HvDw0NQYhxjPb526UE4rOt/lgpJq/3BQ98FxKPeJQbmQg 1pjMu4C8lFHWNivr8k/n8MxXUGxUnIPul0O42HmxM4kad3ChBc+sQIOtj0KMhG7ZUzMO n93glA9f9cvMKE6GWWko1/1ybI7plaij43FBNGzjsw9GKJc7a3XChFgYgLlaOAWooqGP zQaOR+DKF+0h0lTvpBQNUjalLu04I/aI5d/fSMHaPLR9TQrr1c/FZmGVzWZ28V1ZrV4w efag== MIME-Version: 1.0 X-Received: by 10.194.76.69 with SMTP id i5mr1489039wjw.3.1427141422569; Mon, 23 Mar 2015 13:10:22 -0700 (PDT) Sender: xvilajosana@gmail.com Received: by 10.27.146.212 with HTTP; Mon, 23 Mar 2015 13:10:22 -0700 (PDT) In-Reply-To: <10802.1427139650@sandelman.ca> References: <30526.1427136071@sandelman.ca> <10802.1427139650@sandelman.ca> Date: Mon, 23 Mar 2015 21:10:22 +0100 X-Google-Sender-Auth: lr3xhobvzCBIYmpPl6MtJo-_dH0 Message-ID: From: Xavier Vilajosana To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=047d7bb042be895f430511fa4171 Archived-At: Subject: Re: [Roll] proposed amendments to ROLL charter 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, 23 Mar 2015 20:10:32 -0000 --047d7bb042be895f430511fa4171 Content-Type: text/plain; charset=UTF-8 I am in favor to add this items to the ROLL Charter. This is absolutely needed. regards, Xavi 2015-03-23 20:40 GMT+01:00 Michael Richardson : > > Thomas Watteyne wrote: > > Editorial: "IP-in-IP encapsulation" might clearer than IPIP (your > > choice, not a strong opinion) > > Done. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --047d7bb042be895f430511fa4171 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am in favor to add this items to the ROLL Charter. This = is absolutely needed.
regards,
Xavi

2015-03-23 20:40 GMT+01:00 Mich= ael Richardson <mcr+ietf@sandelman.ca>:

Thomas Watteyne <watteyne@= eecs.berkeley.edu> wrote:
=C2=A0 =C2=A0 > Editorial: "IP-in-IP encapsulation" might clea= rer than IPIP (your
=C2=A0 =C2=A0 > choice, not a strong opinion)

Done.

--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-




_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll


--047d7bb042be895f430511fa4171-- From nobody Mon Mar 23 13:12:51 2015 Return-Path: X-Original-To: expand-draft-ietf-roll-applicability-home-building.all@virtual.ietf.org Delivered-To: roll@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 8A0221A0181; Mon, 23 Mar 2015 13:03:36 -0700 (PDT) X-Original-To: xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8731A0181 for ; Mon, 23 Mar 2015 13:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] 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 Zq-NiaQ-H8xn for ; Mon, 23 Mar 2015 13:03:34 -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 806701AD35B for ; Mon, 23 Mar 2015 13:03:34 -0700 (PDT) Received: from usevmg20.ericsson.net ([198.24.6.45]:56850) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Ya8ZR-00011H-AJ for draft-ietf-roll-applicability-home-building.all@tools.ietf.org; Mon, 23 Mar 2015 13:03:34 -0700 X-AuditID: c618062d-f79686d0000030a8-bc-55101bdc1308 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 93.2F.12456.CDB10155; Mon, 23 Mar 2015 14:57:49 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0210.002; Mon, 23 Mar 2015 16:03:25 -0400 From: Meral Shirazipour To: "consultancy@vanderstok.org" Thread-Topic: Gen-ART Last Call review of draft-ietf-roll-applicability-home-building-08 Thread-Index: AdBk3qxllYz4F6enSIOijLT2ACZOxgH6kfQ5nomOs4DhaF6qAIAAN3kQ Date: Mon, 23 Mar 2015 20:03:24 +0000 Message-ID: References: <034001d0659d$3f922e80$beb68b80$@olddog.co.uk> <77422d9da91623e83c5f62bd1451fb63@xs4all.nl> In-Reply-To: <77422d9da91623e83c5f62bd1451fb63@xs4all.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZXLonRPeutECoQdsLTosfPTeYLf7+3Mpo 8Wj/KjaLq4c3sVpcffWZxYHVY8rvjaweS5b8ZPJYsXklo8eXy5/ZPE40bGcPYI3isklJzcks Sy3St0vgynh8ppe94L9KxbrFTcwNjA1yXYycHBICJhIzz7xngbDFJC7cW8/WxcjFISRwhFGi sWkRO4SznFHixPYFbCBVbAIWEtt/P2cFsUUEbCXm/93PBFLELNDEJDH7wx9mkISwQKTE1Cl7 oIqiJP7encUGYbtJzPzwGKyGRUBVYsrF0+wgNq+Ar8SCe4egVt9hlLi09CdYM6eApUTbqeVM IDYj0H3fT60Bs5kFxCVuPZnPBHG3gMSSPeeZIWxRiZeP/7FC2EoSk5aeY4Wo15FYsPsTG4St LbFs4WtmiMWCEidnPmGZwCg2C8nYWUhaZiFpmYWkZQEjyypGjtLi1LLcdCODTYzAODsmwaa7 g3HPS8tDjAIcjEo8vAaC/KFCrIllxZW5hxilOViUxHkXPTgYIiSQnliSmp2aWpBaFF9UmpNa fIiRiYNTqoFx5lurU93CsVZ84c+tLk/kFj9wpsJmR21x03qXlifSK48b3qlg8gw+fDZy1WIB xx6zebvi3vnv0w7mFlr3uOrh64CQwqMyZa9+Xmk5dWG2+oqnK7Nu9df/dSyUKfvJ6WVprnLy 5u/vR/ZdfyWh4DL9s0+/9HSxm8s2Ftyuarmqud337j5RvQ8dSizFGYmGWsxFxYkAD+tYd5QC AAA= X-SA-Exim-Connect-IP: 198.24.6.45 X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-home-building.all@tools.ietf.org X-SA-Exim-Mail-From: meral.shirazipour@ericsson.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-applicability-home-building.all@ietf.org Resent-Message-Id: <20150323200334.806701AD35B@ietfa.amsl.com> Resent-Date: Mon, 23 Mar 2015 13:03:34 -0700 (PDT) Resent-From: meral.shirazipour@ericsson.com Archived-At: Archived-At: X-Mailman-Approved-At: Mon, 23 Mar 2015 13:12:50 -0700 Cc: "gen-art@ietf.org" , "draft-ietf-roll-applicability-home-building.all@tools.ietf.org" Subject: Re: [Roll] Gen-ART Last Call review of draft-ietf-roll-applicability-home-building-08 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, 23 Mar 2015 20:03:36 -0000 Hi, Thanks for considering the comments. The link is ok I think, some spaces = within the url were causing an error.=20 This works: [occuswitch] http://www.philipslightingcontrols.com/assets/cms/uploads/file= s/osw/MK_OSWNETBROC_5.pdf, May 2012. Best, Meral -----Original Message----- From: peter van der Stok [mailto:stokcons@xs4all.nl]=20 Sent: Monday, March 23, 2015 12:18 PM To: adrian@olddog.co.uk Cc: consultancy@vanderstok.org; Meral Shirazipour; draft-ietf-roll-applicab= ility-home-building.all@tools.ietf.org; gen-art@ietf.org; Alvaro Retana Subject: RE: Gen-ART Last Call review of draft-ietf-roll-applicability-home= -building-08 Hi Adrian, good news. I try to do the update this week. Greetings, thanks, Peter Adrian Farrel schreef op 2015-03-23 20:12: > Hi Peter, >=20 > This all looks good. > The changes are small, but it would be worth catching them in a new=20 > revision. > Please post it when you have it, no need to check with me. >=20 > Once you've done that, we'll hand it over to Alvaro as the incoming=20 > AD, and he can put it on an IESG telechat. >=20 > Cheers, > Adrian >=20 >=20 >> -----Original Message----- >> From: peter van der Stok [mailto:stokcons@xs4all.nl] >> Sent: 23 March 2015 14:49 >> To: Meral Shirazipour >> Cc: draft-ietf-roll-applicability-home-building.all@tools.ietf.org; > gen-art@ietf.org >> Subject: Re: Gen-ART Last Call review of >> draft-ietf-roll-applicability-home- >> building-08 >>=20 >> HI Meral, >>=20 >> Thanks for the suggestions. >> I have no problem with any of them. I think they are quite justified. >> Thank you very much for pointing them out. >> Concerning scene and group control. I may suppress the word "scene". >> About [occuswitch] I have to look for a valid alternative. However,=20 >> these links are maintained by a company, which changes information=20 >> frequently. >> Sorry for missing out some of the acronyms. I thought I caught them=20 >> out all. >>=20 >> Greetings, >>=20 >> Peter >>=20 >>=20 >> Meral Shirazipour schreef op 2015-03-22 21:28: >> > I am the assigned Gen-ART reviewer for this draft. For background=20 >> > on Gen-ART, please see the FAQ at=20 >> > http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. >> > >> > Please resolve these comments along with any other Last Call=20 >> > comments you may receive. >> > >> > Document: draft-ietf-roll-applicability-home-building-08 >> > Reviewer: Meral Shirazipour >> > Review Date: 2015-03-21 >> > IETF LC End Date: 2015-03-23 >> > IESG Telechat date: NA >> > >> > >> > Summary: >> > This draft is ready to be published as Standards Track RFC but I=20 >> > have some comments. >> > >> > Major issues: >> > >> > Minor issues: >> > >> > Nits/editorial comments: >> > -[Page 1], "RPL" first used in title/abstract, Would be good to=20 >> > spell it out. >> > -[Page 5], Section 2, "Monitoring of functional correctness is at=20 >> > least as important.". As important as what? (not clear) -[Page 5],=20 >> > Section 2, "Devices typically communicate their status regularly=20 >> > and send alarm messages notifying a malfunction of equipment or=20 >> > network." >> > Not clear what equipment is? network node is an equipment? >> > -[Page 6], Section 2.1, "for large installation"--->"for a large=20 >> > installation" >> > -[Page 8], Section 2.2.2, "fire detectors and the smoke dampers=20 >> > need to be put in place to meet the stringent delay requirements." >> > Where can we find a value for the delay requirement of fire detectors? >> > A value or reference would be good. >> > -[Page 9], Section 2.2.4,"advanced scene and group control". Not=20 >> > clear what "scene" means. >> > -[Page 13], Section 4.1, "assumes the role as=20 >> > authoritative"--->"assumes the role of authoritative" >> > -[Page 16], section 4.1.8, please spell out first use CBC-MAC=20 >> > (Cipher Block Chaining Message Authentication Code) -[Page 16],=20 >> > section 4.1.10, it would be good to give the RFCs. >> > -[Page 16], section 4.2.4, MLE to spell out at first use "mesh link=20 >> > establishment" >> > -[Page 22], "CoAp" first used in section 7.4, but spelled out in=20 >> > section 8. >> > -[Page 18], section 5.1.1., "to throw away too late messages", how=20 >> > are too late messages identified? >> > -[Page 27], [I-D.ietf-6lo-lowpanz] to be replaced by RFC7428 -[Page=20 >> > 28], link to [occuswitch] to be verified. >> > -Through the document both "ms" and "msec" are used. Selecting one=20 >> > for consistency would be better. >> > >> > Best Regards, >> > Meral >> > --- >> > Meral Shirazipour >> > Ericsson >> > Research >> > www.ericsson.com From nobody Mon Mar 23 13:40: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 52EA01B2A05; Mon, 23 Mar 2015 13:40:21 -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 iiX-fi0o7R9U; Mon, 23 Mar 2015 13:40:19 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F9BB1B29E7; Mon, 23 Mar 2015 13:40:19 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 59809203BD; Mon, 23 Mar 2015 16:50:06 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 260F663B76; Mon, 23 Mar 2015 16:40:18 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 14479636A2; Mon, 23 Mar 2015 16:40:18 -0400 (EDT) From: Michael Richardson To: "6lo\@ietf.org" <6lo@ietf.org> 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@ietf.org Subject: Re: [Roll] [6lo] RPL artifact compression discussion 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, 23 Mar 2015 20:40:21 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable There are three important parts of this problem. 1) what headers ("artifacts") are actually required. This is subject to a not-yet created ROLL document that the virtual interim meeting revealed was missing. The summary is we need RPI (RFC6553) on the way up and dow= n, in order to find loops, and carry the RPL InstanceID. The InstanceID is an extra input to the routing process, and distinguishes one DAG from another. We need to have the RH3 on downward traffic in the non-storing case, as this header provides the source routes. As the RPI and RH3 are inserted, in order to do this an IPIP header is required.=20 2) there are various proposals as to the method to compress the artifacts themselves, and this part is subject to various discussion. 3) the 6lo part is that we need a way to signal that the compression in part (2) is actually being used. =20=20=20 There are three options on how to introduce new compression mechanisms into the 6lowPAN/ROLL data plane. 1) draft-thubert-6lo-rpl-nhc originally proposal to add a new 6282 Next Header Compression for just 6= 553. from that document: (Discuss: Is this really an update of RFC 6282 or a straightforward addition to it?) the answer is that RFC6282 has an IANA registry, and the allocation poli= cy is IETF Review. In this document, I would suggest that the Greedy approach probably is more a simple allocation (it's an update!), as it uses so much. =20=20=20 The conservative approach is a simple registration, it takes a single value from the 11111000 to 11111110 range for the 6554. (Note 6lo-rpl-nhc-02 says "Section 4.2 of [RFC6553] defines LOWPAN_NHC encodings", but actually it's defined in 6282) The efficient approach, I guess, optimizes some common cases at the cost of one or more bytes extra for the non-common cases. 1b) NHC++ as noted below, there is no method defined to compress the IPv6 inner header, and no method to compress the RH3 (RFC6554) header was defined. The NHC++ proposal suggests to expand this proposal to do this. It can perhaps be done in the greedy approach with some thought, but it seems unlikely to fit, and the conservative approach would be required. =20=20=20=20=20=20=20 Note that there aren't enough EIDs to encode each of IPIP, RH3 and RPI, but as the IPIP is not seen unless there is also an RH3 and/or RPI, the IPIP pieces that would follow could perhaps be implied=20 2) draft-thubert-6lo-routingdispatch The NHC method above adds additional nexthops, but does not change anything about the outer IPv6 header. It would continue to be compressed with 6282's LOWPAN_IPHC, and unfortunately, as there is no Next Header=3DLOWPAN_IPHC, the second (inner from the wild, likely more rand= om), header can not be compressed. =20=20=20 This method instead replaces the LOWPAN_IPHC with a new compression of the IPv6 header, plus 6553, plus 6554, plus inner IPv6. This occurs at the "dispatch" level, which also is where the 6LowPAN fragmentation occurs, which means that in theory with this method, one could route 6lo fragments individually, across the LLN rather than having to reassemble them hop-by-hop. To do this optimally, it takes the 10xxxxx encodings which are defined in rfc4944 Figure 2, and re-defines them. It does this with the knowledge from above that mesh-under and route-over networks will never occur on the same PANID. Whether or not this is acceptable is THE significant question for the 6lo WG. Note that this is not entirely necessary: we can instead use the 011 111111 "ESC" header, which lets us have another byte for dispatch headers. Summary: 1) NHC++ method using conservative approach costs the 1 or 2 code points from the NHC EID space (there are only 2 left). Using 1 code point means adding adjusting the format to switch on next header being RPI, RH3 or (compressed) IPIP [LOWPAN_IPHC]. There are three reserved bits show in 6low-nhc-02, section 4.3.2. 2) routingdispatch section is much more flexible, and at the cost of the additional byte, there is no conflict with existing users. But this is in some sense a forklift upgrade on RFC6282. =2D-=20 Michael Richardson , Sandelman Software Works=20 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) iQEVAwUBVRB58oCLcPvd0N1lAQIYCQgAjrXV4WgGarMP487XPBtR+QTo3V1O0xqV RULdSy6VAs2wfRKEEVFdtRBh5r6m/TR4WnbwHZxMnnuiecAr8qa4205227jD3Tph Y0AgMgyPGu6e7PLNmNMW3nwhqJYWo+GAMvsYKwlbYlXnd1js9be084xts1Y7zV06 mKKqrDRdSnlYdJhW8y+S8BV5iKvtx76kIoIMEtqOqsa/BS0H4ctk55Eo3vfctafW M/3Jj2L8rUKpoDeVFW/aiKpU4jqjIASRueu9RJYAG4c0v47SsMo+P7T/DgbzaZOB ztLnOyVr+sSQeSfLzsYyMBrE/sjrkl7Ho+j2f/TYgxac84Xo/EHnJQ== =/FHV -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 23 13:50:37 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 94CA91B2A39 for ; Mon, 23 Mar 2015 13:50:36 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 hcfMfds4DWZE for ; Mon, 23 Mar 2015 13:50:31 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.202]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 594CA1B2A16 for ; Mon, 23 Mar 2015 13:50:31 -0700 (PDT) Received: from [216.82.242.115] by server-10.bemta-8.messagelabs.com id E6/B6-07114-69C70155; Mon, 23 Mar 2015 20:50:30 +0000 X-Env-Sender: thirou@CONVERGENCEWIRELESS.COM X-Msg-Ref: server-14.tower-132.messagelabs.com!1427143827!17350374!5 X-Originating-IP: [199.119.192.75] X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31263 invoked from network); 23 Mar 2015 20:50:29 -0000 Received: from out001.apptixemail.net (HELO out001.apptixemail.net) (199.119.192.75) by server-14.tower-132.messagelabs.com with AES128-SHA encrypted SMTP; 23 Mar 2015 20:50:29 -0000 Received: from AUSP01DAG0302.collaborationhost.net ([169.254.2.167]) by AUSP01MHUB15.collaborationhost.net ([10.2.68.87]) with mapi id 14.03.0195.001; Mon, 23 Mar 2015 15:49:52 -0500 From: "Timothy L. Hirou" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] proposed amendments to ROLL charter Thread-Index: AQHQZZj07GCLgU7o+kuoG9EPv7wjD50qiozA Date: Mon, 23 Mar 2015 20:49:51 +0000 Message-ID: References: <30526.1427136071@sandelman.ca> In-Reply-To: <30526.1427136071@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.211.210.18] Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] proposed amendments to ROLL charter 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, 23 Mar 2015 20:50:36 -0000 I agree with this proposal. Best Regards, Timothy L. Hirou President & CEO Convergence Wireless, Inc. 3334 E. Coast Highway Corona Del Mar, CA 92625 (800) 519-9820 Office (949) 444-1723 Cell (949) 258-5592 Fax thirou@convergencewireless.com www.convergencewireless.com=FD Privileged And Confidential Communication This electronic transmission, and= any documents attached hereto, (a) are protected by the Electronic Communi= cations privacy Act (18 USC =A7=A7 2510- 2521),(b)may contain confidential = and or legally privileged information , and (c) are for the sole use of the= intended recipient(s) named above.=A0 If you have received this electronic= message in error, please notify the sender and delete the electronic messa= ge and destroy any physical copies of the information that may have been ge= nerated. Any disclosure, copying, distribution, or use of the contents of t= he information received in error is strictly prohibited.=20 -----Original Message----- From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Michael Richardson Sent: Monday, March 23, 2015 11:41 AM To: roll@ietf.org Subject: [Roll] proposed amendments to ROLL charter The following changes are proposed for the ROLL charter to include the work= to profile 6553/6554/IPIP, and to compress it. To the pre-amble: After: - In most cases, LLNs will be employed over link layers with restricted frame-sizes, thus a routing protocol for LLNs should be specifically adapted for such link layers. Add: +- LLN routing protocols have to be very careful when trading off=20 +efficiency + for generality; many LLN nodes do not have resources to waste. After:=20 The solution must include unicast and multicast considerations. Add: +The Working Group will document how non-control packets are routed when=20 +they cross the LLN, and when they enter and exit the LLN: the=20 +appropriate use of +RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how=20 +routing loops are detected. In consultation with the 6lo WG, the=20 +Working Group will design a method to these routing headers into a=20 +single block. The result will have a shared WGLC with 6lo. To Work Items, add: + - A document detailing when to use RFC6553, RFC6554 and IPIP + encapsulation. + + - A document detailing how to compress RFC6553, RFC6554 and IP header= s + in the 6lowPAN HC context. The resulting charter (after reformatting of some of the ugly text wrapping= on the web site) is: ---- Low power and Lossy networks (LLNs) are made up of many embedded devices wi= th limited power, memory, and processing resources. They are interconnected= by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, w= ired or other low power PLC (Powerline Communication) links. LLNs are trans= itioning to an end-to-end IP-based solution to avoid the problem of non-int= eroperable networks interconnected by protocol translation gateways and pro= xies. Generally speaking, LLNs have at least five distinguishing characteristics: - LLNs operate with a hard, very small bound on state. - In most cases, LLN optimize for saving energy. - Typical traffic patterns are not simply unicast flows (e.g. in some cases= most if not all traffic can be point to multipoint). - In most cases, LLNs will be employed over link layers with restricted frame-sizes, thus a routing protocol for LLNs should be specifically adapted for such link layers. - LLN routing protocols have to be very careful when trading off efficiency for generality; many LLN nodes do not have resources to waste. These specific properties cause LLNs to have specific routing requirements. Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been ev= aluated by the working group and have in their current form been found to n= ot satisfy all of these specific routing requirements. The Working Group is focused on routing issues for LLN. There is a wide scope of application areas for LLNs, including industrial m= onitoring, building automation (HVAC, lighting, access control, fire), conn= ected homes, healthcare, environmental monitoring, urban sensor networks (e= .g. Smart Grid), asset tracking. The Working Group focuses on routing solut= ions for a subset of these: industrial, connected home, building and urban = sensor networks for which routing requirements have been specified. These a= pplication-specific routing requirement documents will be used for protocol= design. The Working Group focuses only on IPv6 routing architectural framework for = these application scenarios. The Framework will take into consideration var= ious aspects including high reliability in the presence of time varying los= s characteristics and connectivity while permitting low-power operation wit= h very modest memory and CPU pressure in networks potentially comprising a = very large number (several thousands) of nodes. The Working Group will pay particular attention to routing security and man= ageability (e.g., self routing configuration) issues. It will also need to = consider the transport characteristic the routing protocol messages will ex= perience. Mechanisms that protect an LLN from congestion collapse or that e= stablish some degree of fairness between concurrent communication sessions = are out of scope of the Working Group. It is expected that upper-layer appl= ications utilizing LLNs define appropriate mechanisms.=20 The solution must include unicast and multicast considerations. The Working Group will document how non-control packets are routed when the= y cross the LLN, and when they enter and exit the LLN: the appropriate use = of RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how routing l= oops are detected. In consultation with the 6lo WG, the Working Group will = design a method to these routing headers into a single block. The result w= ill have a shared WGLC with 6lo. Work Items: - Specification of routing metrics used in path calculation. This includes static and dynamic link/node attributes required for routin= g in LLNs. - Provide an architectural framework for routing and path selection at Layer 3 (Routing for LLN Architecture) that addresses such issues as whether LLN routing require a distributed and/or centralized path computation models, whether additional hierarchy is necessary and ho= w it is applied. Manageability will be considered with each approach, along with vari= ous trade-offs for maintaining low power operation, including the presen= ce of non-trivial loss and networks with a very large number of nodes. - Produce a routing security framework for routing in LLNs. - Protocol work: The Working Group will consider specific routing requirements from the four application documents collectively, and specify either a new protocol or extend an existing routing protocol in cooperation with the relevant Working Group. If requirements from the four target application areas cannot be met with a single protocol, the WG may choose to specify or extend more = than one protocol (this will require a recharter of the WG). - Documentation of applicability statement of ROLL routing protocols. - A document detailing when to use RFC6553, RFC6554 and IPIP encapsulation. - A document detailing how to compress RFC6553, RFC6554 and IP headers in the 6lowPAN HC context. $Id: charter.txt,v 1.3 2015/03/23 18:33:38 mcr Exp $ -- Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ From nobody Mon Mar 23 14:01: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 CC6901B2A4D; Mon, 23 Mar 2015 14:01:32 -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 gp7SbcQYQQ9s; Mon, 23 Mar 2015 14:01:31 -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 583ED1A1A98; Mon, 23 Mar 2015 14:01: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 t2NL1SP2016635; Mon, 23 Mar 2015 22:01:28 +0100 (CET) Received: from alma.local (unknown [IPv6:2001:67c:370:152:3562:b79f:4a08:c877]) (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 3l9p6H0czCz2pRw; Mon, 23 Mar 2015 22:01:26 +0100 (CET) Message-ID: <55107F25.3070902@tzi.org> Date: Mon, 23 Mar 2015 16:01:25 -0500 From: Carsten Bormann User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Michael Richardson References: <22866.1427143218@sandelman.ca> In-Reply-To: <22866.1427143218@sandelman.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: roll@ietf.org, "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] RPL artifact compression discussion 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, 23 Mar 2015 21:01:33 -0000 Michael Richardson wrote: > (Discuss: Is this really an update of RFC 6282 or a straightforward > addition to it?) No need to discuss, it is just an extension. Grüße, Carsten From nobody Mon Mar 23 14:51:51 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 B17A01B2AAD; Mon, 23 Mar 2015 14:51:50 -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 NoyMZM4VkHji; Mon, 23 Mar 2015 14:51:48 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (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 AAA5C1A1A2F; Mon, 23 Mar 2015 14:51:48 -0700 (PDT) Received: by obbgg8 with SMTP id gg8so133773164obb.1; Mon, 23 Mar 2015 14:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=bqLPVs8zTkTflRD9OwQvQ0DYUsYCgRpsMFYKWKxKhYI=; b=VU51qY03y5a7nCUMRPsPkTRLvcU/1rVXoBNwTsKAKPzec2qQ7+9mBP2iVstAzjoZWo vS+6np7akuN0lt1t+kkUSlJ3ZhfFehdbZ1UrZyPS8nMbdCenbld3m0AqdX2ye3qmFaye RcMQBCr13UkZdzqDlcBeEcO8TGivg8dJsym2bTcmDhrWvSwrNHcAx0zuj0bdNKSYrmnG RYvdTs1+heQWT2TnR58KGCLfITC55kINdhWHlh4cKUzZcH//MTJoNvRhL4N2F20npS6g m72P52kmxdMnKh2S9Mav90iQdjjo/rUSOmWmXvaG2cp7MB1Ct8eOcWgNqGHW4XJ/vSHb RXtw== MIME-Version: 1.0 X-Received: by 10.60.112.65 with SMTP id io1mr990938oeb.66.1427147508183; Mon, 23 Mar 2015 14:51:48 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.202.80.18 with HTTP; Mon, 23 Mar 2015 14:51:48 -0700 (PDT) In-Reply-To: <22866.1427143218@sandelman.ca> References: <22866.1427143218@sandelman.ca> Date: Mon, 23 Mar 2015 21:51:48 +0000 X-Google-Sender-Auth: nqia9AYM6blPOwGNkHXkZyhYyX8 Message-ID: From: Robert Cragie To: Michael Richardson Content-Type: multipart/alternative; boundary=001a1130d2fa4476580511fbac14 Archived-At: Cc: "roll@ietf.org WG" , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] RPL artifact compression discussion X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com, 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, 23 Mar 2015 21:51:50 -0000 --001a1130d2fa4476580511fbac14 Content-Type: text/plain; charset=UTF-8 Hi Michael, Comments inline. Robert On 23 March 2015 at 20:40, Michael Richardson wrote: > > 1) draft-thubert-6lo-rpl-nhc > originally proposal to add a new 6282 Next Header Compression for just > 6553. > from that document: > (Discuss: Is this really an update of RFC 6282 or a straightforward > addition to it?) > It's an extension as Carsten says. > 1b) NHC++ as noted below, there is no method defined to compress the > IPv6 > inner header, There is - it's IPHC. You can use IPHC twice as we discussed in the recent call. and no method to compress the RH3 (RFC6554) header > was defined. Yes - this is missing. > The NHC++ proposal suggests to expand this proposal to > do this. It can perhaps be done in the greedy approach with > some thought, but it seems unlikely to fit, and the conservative > approach would be required. > It is possible the efficient approach can be used as well as that would be aimed mainly at RPI. Perhaps there is scope for applying the same method to RH3. > > 2) draft-thubert-6lo-routingdispatch > > The NHC method above adds additional nexthops, but does not change > anything about the outer IPv6 header. It would continue to be > compressed > with 6282's LOWPAN_IPHC, and unfortunately, as there is no Next > Header=LOWPAN_IPHC, the second (inner from the wild, likely more > random), > header can not be compressed. > It can, as shown in the recent call --001a1130d2fa4476580511fbac14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Michael,

Comments inline.
=
Robert

On 23 March 2015 at 20:40, Michael Richardson <= ;mcr+ietf@sandel= man.ca> wrote:

1) draft= -thubert-6lo-rpl-nhc
=C2=A0 =C2=A0originally proposal to add a new 6282 Next Header Compression = for just 6553.
=C2=A0 =C2=A0from that document:
=C2=A0 =C2=A0 =C2=A0 (Discuss: Is this really an update of RFC 6282 or a st= raightforward
=C2=A0 =C2=A0 =C2=A0 =C2=A0addition to it?)
=C2=A0
<RCC>It's an extension as Carsten says.</RCC>
<= div>=C2=A0
=C2=A0 =C2=A01b) NHC++ as no= ted below, there is no method defined to compress the IPv6
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0inner header,

&l= t;RCC>There is - it's IPHC. You can use IPHC twice as we discussed i= n the recent call.</RCC>=C2=A0

and no method to compress the RH3 (RFC6554) header
=C2=A0 =C2=A0 =C2=A0 =C2=A0was defined.
=C2=A0
&= lt;RCC>Yes - this is missing.</RCC>
=C2=A0
The NHC++ proposal suggests to expand this proposal= to
=C2=A0 =C2=A0 =C2=A0 =C2=A0do this.=C2=A0 It can perhaps be done in the gre= edy approach with
=C2=A0 =C2=A0 =C2=A0 =C2=A0some thought, but it seems unlikely to fit, and = the conservative
=C2=A0 =C2=A0 =C2=A0 =C2=A0approach would be required.
=C2=A0
<RCC>It is possible the efficient approach can be u= sed as well as that would be aimed mainly at RPI. Perhaps there is scope fo= r applying the same method to RH3.</RCC>

2) draft-thubert-6lo-routingdispatch

=C2=A0 =C2=A0The NHC method above adds additional nexthops, but does not ch= ange
=C2=A0 =C2=A0anything about the outer IPv6 header.=C2=A0 It would continue = to be compressed
=C2=A0 =C2=A0with 6282's LOWPAN_IPHC, and unfortunately, as there is no= Next
=C2=A0 =C2=A0Header=3DLOWPAN_IPHC,=C2=A0 the second (inner from the wild, l= ikely more random),
=C2=A0 =C2=A0header can not be compressed.

<= div><RCC>It can, as shown in the recent call</RCC>
<= /div>
--001a1130d2fa4476580511fbac14-- From nobody Mon Mar 23 15:48:53 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 5D5C51A00FA; Mon, 23 Mar 2015 15:48:51 -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 Ov6E6BOSd7yw; Mon, 23 Mar 2015 15:48:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 738BC1A0022; Mon, 23 Mar 2015 15:48:49 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C7D13200A1; Mon, 23 Mar 2015 18:58:36 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 388BA63B76; Mon, 23 Mar 2015 18:48:48 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1F2C3636A2; Mon, 23 Mar 2015 18:48:48 -0400 (EDT) From: Michael Richardson To: "6lo\@ietf.org" <6lo@ietf.org>, "roll\@ietf.org WG" In-Reply-To: References: <22866.1427143218@sandelman.ca> 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: Subject: Re: [Roll] [6lo] RPL artifact compression discussion 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, 23 Mar 2015 22:48:51 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Robert Cragie wrote: > There is - it's IPHC. You can use IPHC twice as we discussed in > the recent call.=20 Thank you for your reply, and reminding me that I didn't followup with you = on this question. So, I'm not really sure how you signal this. This is what I see at this time: 15.4 header stuff. Dispatch =3D LOWPAN_IPHC (0b1110 111N). (rfc6282. section 4/5) here we want to put another compress header, so N=3D1. base format, with "NH=3D1" NHC_1=3D0b1110 EID NH EID=3D5,NH=3D1 =3D here we would have RPI NHC_2=3D??? Now if NHC_2 =3D 7, then an IPIP header follows. If the NHC_1's NH=3D0, then an entire byte follows for something that doesn't fit into the EID (e.g. IPsec ESP). I don't know I signal that what follows the RPI isn't an IPv6 header (uncompressed), but rather another LOWPAN_IPHC. Maybe you have a better way of presenting this detail. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVRCYTICLcPvd0N1lAQIhoQgAr1W0ypMJUVCYqzgV4EH29VifHWvpegoC m9bG50ejyAY0TELNm4c9VEUYsnrZ4ZyoRuTQeKef2eIvath7V4/j1+dH8Y0A1fTz Wi3n26L/SlV1Z3HXB7T/v5TV9QhlggqLLn3hBieXraX7CmAIXhkzLf5NUBRE3FAs UnPrW1IPzlSZ8BG/ji6w7D8PPUlJNWKXsUSyrJG0HSSrOKokUx/cAvNsNETBuUUb PVKZmjzpNCWY8asIQ2oUineLUg10xaGxF8MkNJ1xe7L8QuKjFo3MbAUhuPrubDse ZsxVAgDAH0uEgD9Yu1gdhC4wJTR9D+SYZRrbWhTxePf8mjfl/HL3vA== =A1BJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 23 17:03:12 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 8246E1A6F34; Mon, 23 Mar 2015 17:03:09 -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 F9selw44wMbc; Mon, 23 Mar 2015 17:03:06 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 1FBFB1A7022; Mon, 23 Mar 2015 17:03:06 -0700 (PDT) Received: by oigv203 with SMTP id v203so154770715oig.3; Mon, 23 Mar 2015 17:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aKGznLnv3UyiIlGqsV4FxsFKZKDPqRoHXJP9nHMpXCM=; b=fnlRA5y46dLHyZcYgglFA4I1zGuTo240Fc3zwAy8vbrBgUrBe+iqeh/b37PT3OF/xy 7IlMaO0TdFlEPF0l/xQquAsRq3yln9PuAXotS3EgJalE4YZoGpoBqR5vkrOrsFZdkZjC n4eUN9gfQ+GQa8KAzkB2DlzyZCyo9GxYy4P0DfGKOqkzCEYQk/r3GL+CXYsAQ4UL84pm 7LoifLeEmR8RyVfd9ZzCMUyzApZHVfB95Bd7nlzCzHI9+O+/CQh1YGW0q/CzLC2J2QGh +29V1aoaF8+9OBw2mZdf+3HXfIU6quV05GiWIppkH2/WttNv8wIkA8aOcC0wJttlrinL 80pA== MIME-Version: 1.0 X-Received: by 10.202.3.65 with SMTP id 62mr1158602oid.11.1427155385586; Mon, 23 Mar 2015 17:03:05 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.202.80.18 with HTTP; Mon, 23 Mar 2015 17:03:05 -0700 (PDT) In-Reply-To: <17230.1427150928@sandelman.ca> References: <22866.1427143218@sandelman.ca> <17230.1427150928@sandelman.ca> Date: Tue, 24 Mar 2015 00:03:05 +0000 X-Google-Sender-Auth: n9I9HQGbSQctoPjD8lWru-84Fjg Message-ID: From: Robert Cragie To: Michael Richardson Content-Type: multipart/alternative; boundary=001a113ba080cc1c4e0511fd81f6 Archived-At: Cc: "roll@ietf.org WG" , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] RPL artifact compression discussion X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com, 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, 24 Mar 2015 00:03:09 -0000 --001a113ba080cc1c4e0511fd81f6 Content-Type: text/plain; charset=UTF-8 The best way I can think of is to show what Wireshark shows: 6LoWPAN IPHC Header 011. .... = Pattern: IP header compression (0x03) ...1 1... .... .... = Traffic class and flow label: Version, traffic class, and flow label compressed (0x0003) .... .1.. .... .... = Next header: Compressed .... ..00 .... .... = Hop limit: Inline (0x0000) .... .... 0... .... = Context identifier extension: False .... .... .0.. .... = Source address compression: Stateless .... .... ..11 .... = Source address mode: Compressed (0x0003) .... .... .... 0... = Multicast address compression: False .... .... .... .0.. = Destination address compression: Stateless .... .... .... ..11 = Destination address mode: Compressed (0x0003) [Source context: fe80:: (fe80::)] [Destination context: fe80:: (fe80::)] Hop limit: 255 Source: fe80::ff:fe00:3344 (fe80::ff:fe00:3344) Destination: fe80::ff:fe00:1122 (fe80::ff:fe00:1122) IPv6 extension header 1110 .... = Pattern: IPv6 extension header (0x0e) .... 000. = Header ID: IPv6 hop-by-hop options (0x00) .... ...1 = Next header: Compressed Header length: 6 Data (6 bytes) 0000 63 04 00 01 00 02 c..... IPv6 extension header 1110 .... = Pattern: IPv6 extension header (0x0e) .... 111. = Header ID: IPv6 header (0x07) .... ...0 = Next header: Inline IPHC Header 011. .... = Pattern: IP header compression (0x03) ...1 1... .... .... = Traffic class and flow label: Version, traffic class, and flow label compressed (0x0003) .... .0.. .... .... = Next header: Inline .... ..00 .... .... = Hop limit: Inline (0x0000) .... .... 0... .... = Context identifier extension: False .... .... .1.. .... = Source address compression: Stateful .... .... ..10 .... = Source address mode: 16-bits inline (0x0002) .... .... .... 0... = Multicast address compression: False .... .... .... .1.. = Destination address compression: Stateful .... .... .... ..10 = Destination address mode: 16-bits inline (0x0002) [Source context: 2002:db8:: (2002:db8::)] [Origin: 144] [Destination context: 2002:db8:: (2002:db8::)] [Origin: 144] Next header: ICMPv6 (0x3a) Hop limit: 63 Source: 2002:db8::ff:fe00:5566 (2002:db8::ff:fe00:5566) Destination: 2002:db8::ff:fe00:1122 (2002:db8::ff:fe00:1122) Internet Protocol Version 6, Src: fe80::ff:fe00:3344 (fe80::ff:fe00:3344), Dst: fe80::ff:fe00:1122 (fe80::ff:fe00:1122) Internet Protocol Version 6, Src: 2002:db8::ff:fe00:5566 (2002:db8::ff:fe00:5566), Dst: 2002:db8::ff:fe00:1122 (2002:db8::ff:fe00:1122) Not sure if that helps but at least you should be able to work through it. In essence, in this particular case (ZigBee IP going up the DODAG), it looks like: | IPHC outer, NHC = RPI | RPI, NHC = IPV6 | IPHC inner, NH inline | ICMPv6 | Payload | There is the following text at the end of section 4.2 in RFC6282: "When the identified next header is an IPv6 Header (EID=7), the NH bit of the LOWPAN_NHC encoding is unused and MUST be set to zero. The following bytes MUST be encoded using LOWPAN_IPHC as defined in Section 3." This allows IP-in-IP using IPHC compression. Robert On 23 March 2015 at 22:48, Michael Richardson wrote: > > Robert Cragie wrote: > > There is - it's IPHC. You can use IPHC twice as we discussed in > > the recent call. > > Thank you for your reply, and reminding me that I didn't followup with you > on > this question. So, I'm not really sure how you signal this. > > This is what I see at this time: > > 15.4 header stuff. > Dispatch = LOWPAN_IPHC (0b1110 111N). (rfc6282. section 4/5) > here we want to put another compress header, so N=1. > base format, with "NH=1" > NHC_1=0b1110 EID NH EID=5,NH=1 > = here we would have RPI > NHC_2=??? > > Now if NHC_2 = 7, then an IPIP header follows. > If the NHC_1's NH=0, then an entire byte follows for something that > doesn't fit into the EID (e.g. IPsec ESP). > > I don't know I signal that what follows the RPI isn't an IPv6 header > (uncompressed), but rather another LOWPAN_IPHC. > > Maybe you have a better way of presenting this detail. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > > --001a113ba080cc1c4e0511fd81f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The best way I can think of is to show what Wireshark show= s:

6LoWPAN
=C2=A0 =C2=A0 IPHC Header
=C2=A0 =C2=A0 =C2=A0 =C2=A0 011. .... =3D Pattern: IP header compress= ion (0x03)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...1 1... .... .... =3D Tr= affic class and flow label: Version, traffic class, and flow label compress= ed (0x0003)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 .... .1.. .... .... =3D N= ext header: Compressed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 .... ..00 ....= .... =3D Hop limit: Inline (0x0000)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = .... .... 0... .... =3D Context identifier extension: False
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 .... .... .0.. .... =3D Source address compression= : Stateless
=C2=A0 =C2=A0 =C2=A0 =C2=A0 .... .... ..11 .... =3D S= ource address mode: Compressed (0x0003)
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 .... .... .... 0... =3D Multicast address compression: False
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 .... .... .... .0.. =3D Destination address com= pression: Stateless
=C2=A0 =C2=A0 =C2=A0 =C2=A0 .... .... .... ..= 11 =3D Destination address mode: Compressed (0x0003)
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 [Source context: fe80:: (fe80::)]
=C2=A0 =C2=A0= =C2=A0 =C2=A0 [Destination context: fe80:: (fe80::)]
=C2=A0 =C2= =A0 Hop limit: 255
=C2=A0 =C2=A0 Source: fe80::ff:fe00:3344 (fe80= ::ff:fe00:3344)
=C2=A0 =C2=A0 Destination: fe80::ff:fe00:1122 (fe= 80::ff:fe00:1122)
=C2=A0 =C2=A0 IPv6 extension header
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 1110 .... =3D Pattern: IPv6 extension header (0= x0e)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 .... 000. =3D Header ID: IPv6 ho= p-by-hop options (0x00)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 .... ...1 =3D= Next header: Compressed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Header lengt= h: 6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Data (6 bytes)

0000 =C2=A063 04 00 01 00 02 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 c= .....
=C2=A0 =C2=A0 IPv6 extension header
=C2=A0 =C2=A0= =C2=A0 =C2=A0 1110 .... =3D Pattern: IPv6 extension header (0x0e)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 .... 111. =3D Header ID: IPv6 header (0x07)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 .... ...0 =3D Next header: Inline
=C2=A0 =C2=A0 IPHC Header
=C2=A0 =C2=A0 =C2=A0 =C2=A0 011. = .... =3D Pattern: IP header compression (0x03)
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 ...1 1... .... .... =3D Traffic class and flow label: Version, t= raffic class, and flow label compressed (0x0003)
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 .... .0.. .... .... =3D Next header: Inline
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 .... ..00 .... .... =3D Hop limit: Inline (0x0000)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 .... .... 0... .... =3D Context identifi= er extension: False
=C2=A0 =C2=A0 =C2=A0 =C2=A0 .... .... .1.. ..= .. =3D Source address compression: Stateful
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 .... .... ..10 .... =3D Source address mode: 16-bits inline (0x0002)=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 .... .... .... 0... =3D Multicast ad= dress compression: False
=C2=A0 =C2=A0 =C2=A0 =C2=A0 .... .... ..= .. .1.. =3D Destination address compression: Stateful
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 .... .... .... ..10 =3D Destination address mode: 16-bits= inline (0x0002)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [Source context: 200= 2:db8:: (2002:db8::)]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [Origin: 144]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [Destination context: 2002:db8:: (2002= :db8::)]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [Origin: 144]
=C2= =A0 =C2=A0 Next header: ICMPv6 (0x3a)
=C2=A0 =C2=A0 Hop limit: 63=
=C2=A0 =C2=A0 Source: 2002:db8::ff:fe00:5566 (2002:db8::ff:fe00:= 5566)
=C2=A0 =C2=A0 Destination: 2002:db8::ff:fe00:1122 (2002:db8= ::ff:fe00:1122)
Internet Protocol Version 6, Src: fe80::ff:fe00:3= 344 (fe80::ff:fe00:3344), Dst: fe80::ff:fe00:1122 (fe80::ff:fe00:1122)
Internet Protocol Version 6, Src: 2002:db8::ff:fe00:5566 (2002:db8::f= f:fe00:5566), Dst: 2002:db8::ff:fe00:1122 (2002:db8::ff:fe00:1122)


Not sure if that helps but at least y= ou should be able to work through it. In essence, in this particular case (= ZigBee IP going up the DODAG), it looks like:

| IP= HC outer, NHC =3D RPI | RPI, NHC =3D IPV6 | IPHC inner, NH inline | ICMPv6 = | Payload |

There is the following text at the end= of section 4.2 in RFC6282:

"When the identif= ied next header is an IPv6 Header (EID=3D7), the NH bit of the LOWPAN_NHC e= ncoding is unused and MUST be set to zero.=C2=A0 The following bytes MUST b= e encoded using LOWPAN_IPHC as defined in Section 3."

This allows IP-in-IP using IPHC compression.

<= div>Robert

On 23 March 2015 at 22:48, Michael Richardson <mcr+ietf@sandelman= .ca> wrote:

Robert Cragie <robert.cra= gie@gridmerge.com> wrote:
=C2=A0 =C2=A0 > <RCC>There is - it's IPHC. You can use IPHC tw= ice as we discussed in
=C2=A0 =C2=A0 > the recent call.</RCC>

Thank you for your reply, and reminding me that I didn't followu= p with you on
this question.=C2=A0 =C2=A0So, I'm not really sure how you signal this.=

This is what I see at this time:

15.4 header stuff.
Dispatch=C2=A0 =C2=A0 =3D LOWPAN_IPHC (0b1110 111N).=C2=A0 =C2=A0 =C2=A0 (r= fc6282. section 4/5)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 here we want to put another compr= ess header, so N=3D1.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 base format, with "NH=3D1&qu= ot;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0NHC_1=3D0b111= 0 EID NH=C2=A0 =C2=A0 =C2=A0 EID=3D5,NH=3D1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D here we would have RPI
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0NHC_2=3D???
Now if NHC_2 =3D 7, then an IPIP header follows.
If the NHC_1's NH=3D0, then an entire byte follows for something that doesn't fit into the EID (e.g. IPsec ESP).

I don't know I signal that what follows the RPI isn't an IPv6 heade= r
(uncompressed), but rather another LOWPAN_IPHC.

Maybe you have a better way of presenting this detail.

--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulti= ng =3D-




_______________________________________________
6lo mailing list
6lo@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/6lo


--001a113ba080cc1c4e0511fd81f6-- From nobody Tue Mar 24 07:26:42 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 38DDC1A8776; Tue, 24 Mar 2015 07:26:41 -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 HduqMeJvGpnP; Tue, 24 Mar 2015 07:26:39 -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 C8BE31A8766; Tue, 24 Mar 2015 07:26:39 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id CF6E7203CB; Tue, 24 Mar 2015 10:36:29 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 093DE63B76; Tue, 24 Mar 2015 10:26:38 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E5138636A2; Tue, 24 Mar 2015 10:26:38 -0400 (EDT) From: Michael Richardson To: robert.cragie@gridmerge.com In-Reply-To: References: <22866.1427143218@sandelman.ca> <17230.1427150928@sandelman.ca> 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@ietf.org WG" , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [Roll] [6lo] RPL artifact compression discussion 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, 24 Mar 2015 14:26:41 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Robert Cragie wrote: > 0000 63 04 00 01 00 02 c..... > IPv6 extension header > 1110 .... =3D Pattern: IPv6 extension header (0x0e) > .... 111. =3D Header ID: IPv6 header (0x07) > .... ...0 =3D Next header: Inline What I see here is that when EID=3D7, that the thing following is a compressed IPHC. Is it even possible to have a non-compressed IPv6 header? Maybe one can do NH=3D1, and then have an explicit NH=3D41 byte? > This allows IP-in-IP using IPHC compression. So, in the NHC+ case, we could just define a way to compress RH3, which wou= ld consume the remaining EID value (along with using EID=3D5 for RPI). That w= ould result in a chain of four seperately compressed artifacts. In my view, the ideal NHC++ proposal (not yet described), might compress all of the artifacts in a single pass, potentially saving many more bytes. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVRF0G4CLcPvd0N1lAQL/5AgAllbsJo6heE2Vy0YwQLOUgTZ6ogKpU0bD ENE5+Zh8dR818hX8XMiJt6np8Ab6V9O0Z+YLiGohDf69agqjSxQnwcPITtYmJAHJ J484fJKaVY78UGyLMLL9hKXaNlAqFHyLHhVAEdig1XnrdAdk2x6xsMCXPtM/URVz gVj68RrimHk6vSKDYbbybzz85dmHPDQrjrK00XZR8LEYmicspvcygMCrBf6ckM9l eIBp8rQ3C8tQ7ftUu/aSARcmagzGMU1QfWMR16z6oHeVNCAf0EvUVrpoFHxVQaVq hO0iWFcV26a0g7xpp0S0kJXsi8JdjY7KY8I5M8RqlJiH19onARl8cQ== =uGy/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Mar 24 17:10: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 2B9C81A1B45 for ; Tue, 24 Mar 2015 17:10:38 -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 uehnwyy3Mt7H for ; Tue, 24 Mar 2015 17:10:35 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 973BB1A1B3D for ; Tue, 24 Mar 2015 17:10:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14280; q=dns/txt; s=iport; t=1427242235; x=1428451835; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=PMva3JArq5YYCmeolD1Qbc4yQNVCpfYV8P/M4jWA22M=; b=EkJktGRSlwTloOqL718nfmeGI+Zu8B0p0eZrzuzICjRR8fjv33o5/8dE WXEfYEoXP+8Gz2PUjHhBD47CZcPjDNxFlqjFB7iHj7i69YBiUExj6huuu xnZ+kMzO83tHxU5PrqNEbP2nXjmTpm5YF8uCKaTXR+mMZneZAIWMdxYPr A=; X-Files: smime.p7s : 4831 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C6BwB6/BFV/5tdJa1cgwZSWgTEDoI7hXUCgUtMAQEBAQEBfYQUAQEBBIEFBAIBCBEBAwEBCx0HAjAUAwYIAgQTCAYNiBQNyH4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXiyGEHgodFiIGgxGBFgWEUot+gWmBMlSEAIIBgVSSVyKCAhyBUG+BAkJ/AQEB X-IronPort-AV: E=Sophos;i="5.11,461,1422921600"; d="p7s'?scan'208";a="135111640" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP; 25 Mar 2015 00:10:34 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t2P0AYIt021438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 25 Mar 2015 00:10:34 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.225]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Tue, 24 Mar 2015 19:10:34 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] proposed amendments to ROLL charter Thread-Index: AQHQZZj1TlAC6v55Kk6GWqyOVvIIHp0sVFQA Date: Wed, 25 Mar 2015 00:10:34 +0000 Deferred-Delivery: Wed, 25 Mar 2015 00:10:00 +0000 Message-ID: References: <30526.1427136071@sandelman.ca> In-Reply-To: <30526.1427136071@sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.223.232] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0054_01D0665D.A6B11840" MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] proposed amendments to ROLL charter 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, 25 Mar 2015 00:10:38 -0000 ------=_NextPart_000_0054_01D0665D.A6B11840 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All in favor. Do I understand that the 6loRH draft should become a ROLL document after 6lo approval of the dispatch method, then? Cheers, Pascal > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Michael Richardson > Sent: lundi 23 mars 2015 12:41 > To: roll@ietf.org > Subject: [Roll] proposed amendments to ROLL charter > > > The following changes are proposed for the ROLL charter to include the work to > profile 6553/6554/IPIP, and to compress it. > > To the pre-amble: > > After: > - In most cases, LLNs will be employed over link layers with restricted > frame-sizes, thus a routing protocol for LLNs should be specifically > adapted for such link layers. > > Add: > +- LLN routing protocols have to be very careful when trading off > +efficiency > + for generality; many LLN nodes do not have resources to waste. > > After: > The solution must include unicast and multicast considerations. > > Add: > +The Working Group will document how non-control packets are routed when > +they cross the LLN, and when they enter and exit the LLN: the > +appropriate use of > +RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how > +routing loops are detected. In consultation with the 6lo WG, the > +Working Group will design a method to these routing headers into a > +single block. The result will have a shared WGLC with 6lo. > > To Work Items, add: > + - A document detailing when to use RFC6553, RFC6554 and IPIP > + encapsulation. > + > + - A document detailing how to compress RFC6553, RFC6554 and IP headers > + in the 6lowPAN HC context. > > > The resulting charter (after reformatting of some of the ugly text wrapping on > the web site) is: > > ---- > Low power and Lossy networks (LLNs) are made up of many embedded devices > with limited power, memory, and processing resources. They are interconnected > by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or > other low power PLC (Powerline Communication) links. LLNs are transitioning to > an end-to-end IP-based solution to avoid the problem of non-interoperable > networks interconnected by protocol translation gateways and proxies. > > Generally speaking, LLNs have at least five distinguishing > characteristics: > - LLNs operate with a hard, very small bound on state. > - In most cases, LLN optimize for saving energy. > - Typical traffic patterns are not simply unicast flows (e.g. in some cases most if > not all traffic can be point to multipoint). > - In most cases, LLNs will be employed over link layers with restricted > frame-sizes, thus a routing protocol for LLNs should be specifically > adapted for such link layers. > - LLN routing protocols have to be very careful when trading off efficiency > for generality; many LLN nodes do not have resources to waste. > > These specific properties cause LLNs to have specific routing requirements. > > Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been > evaluated by the working group and have in their current form been found to > not satisfy all of these specific routing requirements. > > The Working Group is focused on routing issues for LLN. > > There is a wide scope of application areas for LLNs, including industrial > monitoring, building automation (HVAC, lighting, access control, fire), > connected homes, healthcare, environmental monitoring, urban sensor > networks (e.g. Smart Grid), asset tracking. The Working Group focuses on > routing solutions for a subset of these: industrial, connected home, building and > urban sensor networks for which routing requirements have been specified. > These application-specific routing requirement documents will be used for > protocol design. > > The Working Group focuses only on IPv6 routing architectural framework for > these application scenarios. The Framework will take into consideration various > aspects including high reliability in the presence of time varying loss > characteristics and connectivity while permitting low-power operation with very > modest memory and CPU pressure in networks potentially comprising a very > large number (several thousands) of nodes. > > The Working Group will pay particular attention to routing security and > manageability (e.g., self routing configuration) issues. It will also need to > consider the transport characteristic the routing protocol messages will > experience. Mechanisms that protect an LLN from congestion collapse or that > establish some degree of fairness between concurrent communication sessions > are out of scope of the Working Group. It is expected that upper-layer > applications utilizing LLNs define appropriate mechanisms. > > The solution must include unicast and multicast considerations. > > The Working Group will document how non-control packets are routed when > they cross the LLN, and when they enter and exit the LLN: the appropriate use of > RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how routing > loops are detected. In consultation with the 6lo WG, the Working Group will > design a method to these routing headers into a single block. The result will > have a shared WGLC with 6lo. > > Work Items: > > - Specification of routing metrics used in path calculation. This > includes static and dynamic link/node attributes required for routing in > LLNs. > > - Provide an architectural framework for routing and path selection at > Layer 3 (Routing for LLN Architecture) that addresses such issues as > whether LLN routing require a distributed and/or centralized path > computation models, whether additional hierarchy is necessary and how it > is applied. > > Manageability will be considered with each approach, along with various > trade-offs for maintaining low power operation, including the presence of > non-trivial loss and networks with a very large number of nodes. > > - Produce a routing security framework for routing in LLNs. > > - Protocol work: The Working Group will consider specific routing > requirements from the four application documents collectively, and > specify either a new protocol or extend an existing routing protocol > in cooperation with the relevant Working Group. > If requirements from the four target application areas cannot be met > with a single protocol, the WG may choose to specify or extend more than > one protocol (this will require a recharter of the WG). > > - Documentation of applicability statement of ROLL routing protocols. > > - A document detailing when to use RFC6553, RFC6554 and IPIP > encapsulation. > > - A document detailing how to compress RFC6553, RFC6554 and IP headers > in the 6lowPAN HC context. > > > > $Id: charter.txt,v 1.3 2015/03/23 18:33:38 mcr Exp $ > > > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ ------=_NextPart_000_0054_01D0665D.A6B11840 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOLTCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIErzCC A5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEyMjIwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxWpgYmt7hJ4Jbn Uavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW/qGHqS5DUkMW fK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8GsLGsk0C5tQiT OpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAtMX9ZvVI3sDNp LUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5GOld0YVC+xkA/ y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtUGjAdBgNV HQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYB Af8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBE BgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5h bENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2Vy dHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2ErwAkQI5kPxWZq b7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9YG+MiY5xS+LsF Nqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENumNzToe+ABEKWc yjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqGNAe5LMrmHErY mQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2ShAaJvp8ivub MIIFPDCCBCSgAwIBAgIRAImdrrrSrE1TMdXIyvE0qYEwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDMwMDAwMDBaFw0xNjAy MDMyMzU5NTlaMCMxITAfBgkqhkiG9w0BCQEWEnB0aHViZXJ0QGNpc2NvLmNvbTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBALTqoFHH36vHzOLhXp5Wv28HBpYWouQolX/OzHVrZbIEblHp NAxFdrnNSWULDP5gT8hp/t4P0XO3YEnaQxpPUu0wWFlLrDC690s0y3T0hATowmfycNcLX+hddBDL 8ChyZdJAVhxl0vnxORmcciJmXmWOJ+4lzEqaDbm5lZUHgi3kc0t9/IFOOJ6yq1kjttHu1MFPZZUc lUnlpXmD+2/GzxeCHlQgLvw232No6lrAS34PQxbu7rnfw25Spd3CFP7RymWZnNL26rIvt3J4rpv8 xy0EedfU3AUo5scNpr7Mb1npOgVU7N+K07atmjh71wpvfnpvwIxPA+OOHcXwOS5JsosCAwEAAaOC AfAwggHsMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBS2xFsxMSdl ViqpYN1OZcdW6Bg4OTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYB BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0G A1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFgG CCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRo ZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wHQYDVR0RBBYwFIEScHRodWJlcnRAY2lzY28uY29tMA0GCSqGSIb3DQEBCwUA A4IBAQABMkoJZJ5HHnG3Sl0jOpl8Emhb5fjpyW2eK26Zy8e62uqUL7ExSBChD97N1lCYUFY4TqIR zCmaObFC+fDgG3IDQ7ZOJDVu6ZK8TAGiBF6sSYcg5rSfIKPxJUQvTciSrTE+XHEVONmU6xQrMIYY 4/T4iho50oQmNpTSNmGc19ZZ9mQtbRGsjdwILm5NvIyI3X088GidfVJqifQ9dRmSikzELdvlmdBs TFdAM1zx3CscylrUPQyy3lrLuvWf9arpPHV7sex+cwkLKOGHl26mXMoOPwvEYcpJJ3phmR/aqxbC mZwz4LugVrqvC0sFERLSjfarSBQxKL7XSxxS6JYEL3LpMYIEdDCCBHACAQEwgbEwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAImdrrrSrE1TMdXIyvE0qYEwCQYF Kw4DAhoFAKCCApcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUw MzI1MDAwOTIwWjAjBgkqhkiG9w0BCQQxFgQUdsIuF/FYonp68I7fBOYKWwH5LPowgasGCSqGSIb3 DQEJDzGBnTCBmjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFl AwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwIC ASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwgcIGCSsG AQQBgjcQBDGBtDCBsTCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEAiZ2uutKsTVMx1cjK8TSpgTCBxAYLKoZIhvcNAQkQAgsxgbSggbEwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAImdrrrSrE1TMdXIyvE0qYEwDQYJKoZIhvcN AQEBBQAEggEAk2G6w6djLev/qqPyYfGg9VaBkUoSgD59OPxUCysyPzh3m4bfFuGiE3bB64YZuehp p4lZyitpeq4IuJvdmW1EHpPxTekPrRwJz1qV+1I/6R5SrKGkmP9O5X8fTMUH/AvaJPe7/l+N9gqG Ok/rA0j7zFHld6fDmouEJzWnzzi0kbAZfYbu0WD6cA0Yz97ysKXNLqnyxBBq2K+BgvHHk7RUUNIC LO/IDVROhPS2p/57GUf4dGlPkIR2jQkwMLDyKsAGd6SH5dBxCTv9YY/Yzfqe7MCQoYrDueyGLlMp LBc1iHszO9rkD9Dcm1fpmDx2iuBd8Uov5dXHws32WMJnGzfRLgAAAAAAAA== ------=_NextPart_000_0054_01D0665D.A6B11840-- From nobody Tue Mar 24 17:35: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 6419A1A1B20 for ; Tue, 24 Mar 2015 17:35:44 -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 nYIZiUGQRVYi for ; Tue, 24 Mar 2015 17:35:41 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97FBF1A1B3D for ; Tue, 24 Mar 2015 17:35:41 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D8160203B2 for ; Tue, 24 Mar 2015 20:45:32 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 9DFFE63B76; Tue, 24 Mar 2015 20:35:40 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 84C61636A2 for ; Tue, 24 Mar 2015 20:35:40 -0400 (EDT) From: Michael Richardson to: roll@ietf.org In-Reply-To: <30526.1427136071@sandelman.ca> References: <30526.1427136071@sandelman.ca> 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: Subject: Re: [Roll] proposed amendments to ROLL charter 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, 25 Mar 2015 00:35:44 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable There are two additional minor typos to deal with: =2Ddesign a method to these routing headers into a single block. The result =2Dwill have a shared WGLC with 6lo. +design a method to compress these routing headers. The result will have a +shared WGLC with 6lo. The charter discussion will remain open until March 30. This will put it on the telechat for April 9. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ =3D=3D=3D=3D Low power and Lossy networks (LLNs) are made up of many embedded devices with limited power, memory, and processing resources. They are interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline Communication) links. LLNs are transitioning to an end-to-end IP-based solution to avoid the problem of non-interoperable networks interconnected by protocol translation gateways and proxies. Generally speaking, LLNs have at least five distinguishing characteristics: =2D LLNs operate with a hard, very small bound on state. =2D In most cases, LLN optimize for saving energy. =2D Typical traffic patterns are not simply unicast flows (e.g. in some cas= es most if not all traffic can be point to multipoint). =2D In most cases, LLNs will be employed over link layers with restricted frame-sizes, thus a routing protocol for LLNs should be specifically adapted for such link layers. =2D LLN routing protocols have to be very careful when trading off efficien= cy for generality; many LLN nodes do not have resources to waste. These specific properties cause LLNs to have specific routing requirements. Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been evaluated by the working group and have in their current form been found to not satisfy all of these specific routing requirements. The Working Group is focused on routing issues for LLN. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (HVAC, lighting, access control, fire), connected homes, healthcare, environmental monitoring, urban sensor networks (e.g. Smart Grid), asset tracking. The Working Group focuses on routing solutions for a subset of these: industrial, connected home, building and urban sensor networks for which routing requirements have been specified. These application-specific routing requirement documents will be used for protocol design. The Working Group focuses only on IPv6 routing architectural framework for these application scenarios. The Framework will take into consideration various aspects including high reliability in the presence of time varying loss characteristics and connectivity while permitting low-power operation with very modest memory and CPU pressure in networks potentially comprising= a very large number (several thousands) of nodes. The Working Group will pay particular attention to routing security and manageability (e.g., self routing configuration) issues. It will also need = to consider the transport characteristic the routing protocol messages will experience. Mechanisms that protect an LLN from congestion collapse or that establish some degree of fairness between concurrent communication sessions are out of scope of the Working Group. It is expected that upper-layer applications utilizing LLNs define appropriate mechanisms. The solution must include unicast and multicast considerations. The Working Group will document how non-control packets are routed when they cross the LLN, and when they enter and exit the LLN: the appropriate use of RH3 (RFC6553), RPI (RFC6554) and IP-in-IP encapsulation including how routi= ng loops are detected. In consultation with the 6lo WG, the Working Group will design a method to compress these routing headers. The result will have a shared WGLC with 6lo. Work Items: - Specification of routing metrics used in path calculation. This includes static and dynamic link/node attributes required for routin= g in LLNs. - Provide an architectural framework for routing and path selection at Layer 3 (Routing for LLN Architecture) that addresses such issues as whether LLN routing require a distributed and/or centralized path computation models, whether additional hierarchy is necessary and ho= w it is applied. Manageability will be considered with each approach, along with vari= ous trade-offs for maintaining low power operation, including the presen= ce of non-trivial loss and networks with a very large number of nodes. - Produce a routing security framework for routing in LLNs. - Protocol work: The Working Group will consider specific routing requirements from the four application documents collectively, and specify either a new protocol or extend an existing routing protocol in cooperation with the relevant Working Group. If requirements from the four target application areas cannot be met with a single protocol, the WG may choose to specify or extend more = than one protocol (this will require a recharter of the WG). - Documentation of applicability statement of ROLL routing protocols. - A document detailing when to use RFC6553, RFC6554 and IPIP encapsulation. - A document detailing how to compress RFC6553, RFC6554 and IP headers in the 6lowPAN HC context. $Id: charter.txt,v 1.5 2015/03/25 00:34:00 mcr Exp mcr $ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVRIC2YCLcPvd0N1lAQLm2Af8C0TmwchHy7dn4eqe3yyOBzQtPrBzd5i0 rXz9hyUsrsOSDUqFIK4rIQ8iKd1mrGqJFhJF+BO4LOkHQexd7tyUtXJyyWCp4tPq 5xS7AfhL4YEJxehgrxnRhhrDFGDGpo5Zv7PQfXukicrzwIar2z7xBPJhS2Ce8PxD 6bpczGEZnYGtkofz7J6plITDQ1S2QZtCn5nkzqQKJjsiphSRsnm8VQVyQfw1xcS9 N4hFVJZn8mzuzu/d8rabIfxvO3ZXiEgaEKZf9fqqKRKYuXETf9lc0uEmOC/35SHZ 9pCipeVACRutY1XsI2gyh7gQRuocybsgnYAiqjJw4A0q/s5dX9d68g== =jV4e -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 25 06:51:22 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 D13401AD06D; Wed, 25 Mar 2015 06:51:20 -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 6CXrWqKJ-Q9P; Wed, 25 Mar 2015 06:51:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F471AD0A0; Wed, 25 Mar 2015 06:51:07 -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: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150325135107.19088.23529.idtracker@ietfa.amsl.com> Date: Wed, 25 Mar 2015 06:51:07 -0700 Archived-At: Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-applicability-home-building-09.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: Wed, 25 Mar 2015 13:51:21 -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 : Applicability Statement: The use of the RPL protocol suite in Home Automation and Building Control Authors : Anders Brandt Emmanuel Baccelli Robert Cragie Peter van der Stok Filename : draft-ietf-roll-applicability-home-building-09.txt Pages : 31 Date : 2015-03-25 Abstract: The purpose of this document is to provide guidance in the selection and use of protocols from the RPL protocol suite to implement the features required for control in building and home environments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-applicability-home-building-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-home-building-09 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 Wed Mar 25 06:51:31 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 3849D1AD074; Wed, 25 Mar 2015 06:51:22 -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 vzWUud6KcEPW; Wed, 25 Mar 2015 06:51:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E81661AD0A2; Wed, 25 Mar 2015 06:51:07 -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: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150325135107.19088.6535.idtracker@ietfa.amsl.com> Date: Wed, 25 Mar 2015 06:51:07 -0700 Archived-At: Subject: [Roll] New Version Notification - draft-ietf-roll-applicability-home-building-09.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: Wed, 25 Mar 2015 13:51:22 -0000 A new version (-09) has been submitted for draft-ietf-roll-applicability-home-building: http://www.ietf.org/internet-drafts/draft-ietf-roll-applicability-home-building-09.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-home-building-09 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. IETF Secretariat. From nobody Wed Mar 25 06:59: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 DA59B1AD0AB for ; Wed, 25 Mar 2015 06:59:43 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 yRHJHbA6bp9R for ; Wed, 25 Mar 2015 06:59:42 -0700 (PDT) Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E776D1AD0AD for ; Wed, 25 Mar 2015 06:59:41 -0700 (PDT) Received: from roundcube.xs4all.nl ([194.109.20.208]) by smtp-cloud3.xs4all.net with ESMTP id 7pzf1q00E4VN29601pzfhp; Wed, 25 Mar 2015 14:59:40 +0100 Received: from [2001:67c:370:136:bc56:56c0:3916:3f35] by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 25 Mar 2015 14:59:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 25 Mar 2015 14:59:39 +0100 From: peter van der Stok To: Roll Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: X-Sender: stokcons@xs4all.nl (qbFJpD8pEW2t4Gv2e6eWv1/W+c/N7VnK) User-Agent: XS4ALL Webmail Archived-At: Subject: [Roll] Fwd: I-D Action: draft-ietf-roll-applicability-home-building-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.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: Wed, 25 Mar 2015 13:59:44 -0000 Hi all, this version addresses the issues raised by the GEN-ART review. Greetings, Peter 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 : Applicability Statement: The use of the RPL protocol suite in Home Automation and Building Control Authors : Anders Brandt Emmanuel Baccelli Robert Cragie Peter van der Stok Filename : draft-ietf-roll-applicability-home-building-09.txt Pages : 31 Date : 2015-03-25 Abstract: The purpose of this document is to provide guidance in the selection and use of protocols from the RPL protocol suite to implement the features required for control in building and home environments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-applicability-home-building-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-home-building-09 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/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From nobody Wed Mar 25 08:36:22 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 AF9261B2A50; Wed, 25 Mar 2015 08:36:18 -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 OD2fzNNY6OB2; Wed, 25 Mar 2015 08:36:17 -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 5EAD91B2A48; Wed, 25 Mar 2015 08:36:17 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2039320455; Wed, 25 Mar 2015 11:46:11 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 9848763B76; Wed, 25 Mar 2015 11:36:16 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7AD30636A2; Wed, 25 Mar 2015 11:36:16 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks , 6lo@ietf.org In-Reply-To: References: <30526.1427136071@sandelman.ca> 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: Subject: Re: [Roll] proposed amendments to ROLL charter 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, 25 Mar 2015 15:36:18 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Pascal Thubert (pthubert) wrote: > Do I understand that the 6loRH draft should become a ROLL document af= ter 6lo > approval of the dispatch method, then? 6loRH can become a ROLL document. During the WG process of that document, 6lo will recommend on what the dispatch mechanism/values will be.... We can't hit WGLC without 6lo approval, but I don't think we need to do it sequentially. =2D-=20 Michael Richardson , Sandelman Software Works=20 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) iQEVAwUBVRLV7YCLcPvd0N1lAQL8lQf/aw0qkWOKWZFAU5P8+cwZHMDIBGcC+lbR 0i5Wp927Kbr1vjT9HPiW50LDqS5Pt8Az/ak/22Oy1VY3kRpx3DzrWm+UHnqnCgNP T2kE86MR7ZvQntiKb6NBo0yMk2i3jeBQjI3aSTpi3fB7Kc6DBrxzSbxjndkHTFjB rS9uwQAWnRGgNkzp7jUyWq1XjTHzKbrl5PI+Rlfa61EJGYVn8VqvEw7oFtiYE+BH fF+meV0z+Zj/8n4iF+uyjQId3RR5OG2Lssv4bSEf90ulEgPCUFnojEa/W2joP223 B2/2FDNxgp1IeLL8amXD9K7/c8fiSDAWXcLz+7veeZWfyAlVtvwE0w== =WoLc -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 25 12:39:55 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 470141A89AD; Wed, 25 Mar 2015 12:39: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 QWqCj-wrzMyR; Wed, 25 Mar 2015 12:39:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 16ABD1A8A0F; Wed, 25 Mar 2015 12:39:47 -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: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150325193947.4305.49567.idtracker@ietfa.amsl.com> Date: Wed, 25 Mar 2015 12:39:47 -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: Wed, 25 Mar 2015 19:39:54 -0000 Placed on agenda for telechat - 2015-04-09 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ From nobody Wed Mar 25 12:41: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 0C6CF1A89FA; Wed, 25 Mar 2015 12:41:20 -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 tUWbSwTPLD0J; Wed, 25 Mar 2015 12:41:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2F51A89FC; Wed, 25 Mar 2015 12:41:17 -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: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150325194117.829.11487.idtracker@ietfa.amsl.com> Date: Wed, 25 Mar 2015 12:41:17 -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: Wed, 25 Mar 2015 19:41:20 -0000 IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ From nobody Wed Mar 25 15:56:03 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 4CB771AC3CA for ; Wed, 25 Mar 2015 15:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 6Sb_Xh70TT2q for ; Wed, 25 Mar 2015 15:55:59 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3DD21AC3B3 for ; Wed, 25 Mar 2015 15:55:58 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t2PMtuMw031763; Wed, 25 Mar 2015 22:55:56 GMT Received: from 950129200 (dhcp-b383.meeting.ietf.org [31.133.179.131]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t2PMtrnE031752 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 25 Mar 2015 22:55:55 GMT From: "Adrian Farrel" To: , "'Routing Over Low power and Lossy networks'" References: In-Reply-To: Date: Wed, 25 Mar 2015 22:55:52 -0000 Message-ID: <0b3601d0674e$d978b160$8c6a1420$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHiDv5cRmAyMgzwBkbIt+PccgeFuJ0KfqyA Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21426.002 X-TM-AS-Result: No--11.607-10.0-31-10 X-imss-scan-details: No--11.607-10.0-31-10 X-TMASE-MatchedRID: 1GZI+iG+MteqMZyz/RcGLuYAh37ZsBDC2MmowBCx0sFklcn7rbO3m8Lm p4jPUF8tRIcGhc38yHnrM5KjWHdzQHz5lEEBuvacrvcVVSKYsc8UnXiHKcH7S94BdLPuCvrOaVt vYPBkvgPjwIdTpLUhIc4JGyAngPORVyi2q9SFnKqzI1v7J4hECoLsLasl5ROhVS4uT97CBm3og7 gEsLtz5zGn4QfzXG6ueEFGMNsyI8VLa9v9GH70hZ1U1lojafr/mGSSol4Uei1NgRWQyN9HdYMDv FclzIUY7IUTjinsz8MOYLFb+3JssQ8rMzVfGoV9qbg9uWhLYLd1k+gP1XamtJsoi2XrUn/JyeMt MD9QOgAfACoClnjRoWLHjeGkjh9X3QfwsVk0UbtuRXh7bFKB7vkI6VxHOgg+9RE4a0mTgSBYOqL hWcO6tM5APwjuoc0/aAZk0sEcY14= Archived-At: Subject: Re: [Roll] Fwd: I-D Action: draft-ietf-roll-applicability-home-building-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk, 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, 25 Mar 2015 22:56:01 -0000 Many thanks Peter and authors. It got to me just in time and I have moved it on as much as I can. Alvaro will pick it up for the next step. Adrian > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of peter van der Stok > Sent: 25 March 2015 14:00 > To: Roll > Subject: [Roll] Fwd: I-D Action: draft-ietf-roll-applicability-home-building-09.txt > > Hi all, > > this version addresses the issues raised by the GEN-ART review. > > Greetings, > > Peter > > > > 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 : Applicability Statement: The use of the RPL > protocol suite in Home Automation and Building Control > Authors : Anders Brandt > Emmanuel Baccelli > Robert Cragie > Peter van der Stok > Filename : draft-ietf-roll-applicability-home-building-09.txt > Pages : 31 > Date : 2015-03-25 > > Abstract: > The purpose of this document is to provide guidance in the selection > and use of protocols from the RPL protocol suite to implement the > features required for control in building and home environments. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-roll-applicability-home-building-09 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-home-building-09 > > > 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/ > > _______________________________________________ > 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 From nobody Thu Mar 26 14:05:34 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 5B45E1B2F26; Thu, 26 Mar 2015 14:05:32 -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 heK4o0WFNUwr; Thu, 26 Mar 2015 14:05:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A311B2F18; Thu, 26 Mar 2015 14:05:30 -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: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150326210530.8751.45664.idtracker@ietfa.amsl.com> Date: Thu, 26 Mar 2015 14:05:30 -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, 26 Mar 2015 21:05:32 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ From nobody Mon Mar 30 14:28: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 C17FD1A012D for ; Mon, 30 Mar 2015 14:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 98_xo7v9y0my for ; Mon, 30 Mar 2015 14:28:11 -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 CF9711A016A for ; Mon, 30 Mar 2015 14:28:09 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 31E8F203B8 for ; Mon, 30 Mar 2015 17:38:21 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 5913D63B76; Mon, 30 Mar 2015 17:28:08 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 46D9963784 for ; Mon, 30 Mar 2015 17:28:08 -0400 (EDT) From: Michael Richardson to: roll@ietf.org In-Reply-To: <10807.1427243740@sandelman.ca> References: <30526.1427136071@sandelman.ca> <10807.1427243740@sandelman.ca> 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: Subject: Re: [Roll] proposed amendments to ROLL charter 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, 30 Mar 2015 21:28:12 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Michael Richardson wrote: > The charter discussion will remain open until March 30. This will put > it on the telechat for April 9. Last change to say something + or - about this charter update. =2D-=20 Michael Richardson , Sandelman Software Works=20 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) iQEVAwUBVRm/6ICLcPvd0N1lAQJ5PQf/e/dK1l9aHycXaQoNxoPbeNBtbGRTs3sT zk3hNC31Xr95MWQ8kShTQ6QQsGsNcO6dRxdGzqiJe3uhBC57Uf7d5lhE9AM4r001 S22h8BMLuSDpXKPD5mjjAx0DKXQXToiNvJj8RJEraLeTtvrhITYhQ2Z+/2H56LCG S+zXem55P0odpC/te/3c+6MluB58ClqpIlVUba7MwEXsFIHnzSj/Kf4+CCHUo2L6 Utg1CUPPZe4vYHCoDSpvsZ3bO4GrYmb6qlzltgB3jGvRlf2Pfl6ok8smUJzBMUBY eY+HVaZSzrJ5wyE7tdDLGHPYW26uAUgpLIefmVr4GVd4z5P8vx65XA== =9ORV -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 30 18:57: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 D6D301A033B for ; Mon, 30 Mar 2015 18:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 oCjigLv0EdAq for ; Mon, 30 Mar 2015 18:57:51 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (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 C10A81A02BE for ; Mon, 30 Mar 2015 18:57:51 -0700 (PDT) Received: by obvd1 with SMTP id d1so5455700obv.0 for ; Mon, 30 Mar 2015 18:57:51 -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:date:message-id:subject :from:to:content-type; bh=OAdmtc7/YCCjXRrjDV3wNGK4/01cydTJlcQ+6hxlEr8=; b=Wz84VK/CQMMzoYyTxWGVPmcllQjiowgDcFh2DPLSLggJOHQfDQJPC6aXJ1B4ohRp/C Od4jxX7xsM5QHxK1FFLCNqJU9hFy6qfMVjHBzOiPOVlG0si+Q7kPUr0kGA+Xn7uQlgaU DMhuhRqWIh2Jm5pbbaJjB2YUnM0eTHYXoRWx5b4kP/mUSYazlA0x6fSJU9i6CF3V8I7m uO68Z0BRF0vt1XFy6rPN/ZybpPOjIleZvnP9tE/L8ebVqRA7GZtvFs/X68MLVmWZTeHM ZEjiZsbxfi2qV/KwDDXikXYJoAxDrWc9IxJe75zt0zEQfo9WK1jvisegCyGOGVs9eP1O u0LA== MIME-Version: 1.0 X-Received: by 10.60.63.99 with SMTP id f3mr10457390oes.9.1427767071277; Mon, 30 Mar 2015 18:57:51 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.83.178 with HTTP; Mon, 30 Mar 2015 18:57:51 -0700 (PDT) In-Reply-To: <11436.1427750888@sandelman.ca> References: <30526.1427136071@sandelman.ca> <10807.1427243740@sandelman.ca> <11436.1427750888@sandelman.ca> Date: Mon, 30 Mar 2015 21:57:51 -0400 X-Google-Sender-Auth: Wc-kZuAfxNuTawdeq4Yk2K7bJOA Message-ID: From: Kerry Lynn To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=001a11c2578a1b087105128bedb9 Archived-At: Subject: Re: [Roll] proposed amendments to ROLL charter 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, 31 Mar 2015 01:57:53 -0000 --001a11c2578a1b087105128bedb9 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 30, 2015 at 5:28 PM, Michael Richardson wrote: > > Michael Richardson wrote: > > The charter discussion will remain open until March 30. This will put > > it on the telechat for April 9. > > Last change to say something + or - about this charter update. > > > +1 (after the typo fixes) Kerry -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --001a11c2578a1b087105128bedb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 30, 2015 at 5:28 PM, Michael Richardson <= mcr+ietf@sandelman.ca> wrote:
<= div class=3D"gmail_quote">
<= br> Michael Richardson <mcr+ietf@= sandelman.ca> wrote:
=C2=A0 =C2=A0 > The charter discussion will remain open until March 30. = This will put
=C2=A0 =C2=A0 > it on the telechat for April 9.

Last change to say something + or - about this charter update.


+1 (after the typo fixes)
<= br>
Kerry

--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
IETF ROLL WG co-chair.=C2=A0 =C2=A0 http://datatracker.ietf.org/wg/roll/cha= rter/


_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll


--001a11c2578a1b087105128bedb9-- From nobody Tue Mar 31 00:42:38 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 314921A1EF2 for ; Tue, 31 Mar 2015 00:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 g6vTldb-3Hb7 for ; Tue, 31 Mar 2015 00:42:35 -0700 (PDT) Received: from mailscan1.extendcp.co.uk (mailscan6.extendcp.co.uk [79.170.43.52]) (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 DEABB1A875A for ; Tue, 31 Mar 2015 00:42:34 -0700 (PDT) Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan2.hi.local) by mailscan-g64.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1Ycqoj-000574-6X for roll@ietf.org; Tue, 31 Mar 2015 08:42:33 +0100 Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail41.extendcp.co.uk) by mailscan2.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1Ycqog-00078W-FR for roll@ietf.org; Tue, 31 Mar 2015 08:42:33 +0100 Received: from host86-156-208-9.range86-156.btcentralplus.com ([86.156.208.9] helo=[192.168.0.6]) by mail41.extendcp.com with esmtpsa (UNKNOWN:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1Ycqof-000290-4H for roll@ietf.org; Tue, 31 Mar 2015 08:42:29 +0100 Message-ID: <551A4FDF.4040000@gridmerge.com> Date: Tue, 31 Mar 2015 08:42:23 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: roll@ietf.org References: <30526.1427136071@sandelman.ca> <10807.1427243740@sandelman.ca> <11436.1427750888@sandelman.ca> In-Reply-To: <11436.1427750888@sandelman.ca> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010106010501020500030809" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: Subject: Re: [Roll] proposed amendments to ROLL charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com, 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, 31 Mar 2015 07:42:37 -0000 This is a cryptographically signed message in MIME format. --------------ms010106010501020500030809 Content-Type: multipart/alternative; boundary="------------020102020900010301060101" This is a multi-part message in MIME format. --------------020102020900010301060101 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hope I'm not too late... I support the charter update. Just a couple of suggestions: * Change "IPv6-in-IPv6 encapsulation" to "IPIP encapsulation" as also=20 suggested by Thomas. AFAICT "IPIP" is not widely used and when it is, it = refers more to IPv4. * Change "in the 6lowpan HC context" to "in the 6LoWPAN adaptation layer = context". This generalises it to include dispatch-based solutions as=20 well, otherwise it could be read as only looking at NHC-based variants. Robert On 30/03/2015 22:28, Michael Richardson wrote: > Michael Richardson wrote: > > The charter discussion will remain open until March 30. This wil= l put > > it on the telechat for April 9. > > Last change to say something + or - about this charter update. > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --------------020102020900010301060101 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hope I'm not too late...

I support the charter update. Just a couple of suggestions:

* Change "IPv6-in-IPv6 encapsulation" to "IPIP encapsulation" as also suggested by Thomas. AFAICT "IPIP" is not widely used and when it is, it refers more to IPv4.
* Change "in the 6lowpan HC context" to "in the 6LoWPAN adaptation layer context". This generalises it to include dispatch-based solutions as well, otherwise it could be read as only looking at NHC-based variants.

Robert


On 30/03/2015 22:28, Michael Richardso= n wrote:
= 
Michael Richardson <mcr+ietf@sandelman.ca> wrote:
    > The charter discussion will remain open until March 30. This wil=
l put
    > it on the telechat for April 9.

Last change to say something + or - about this charter update.





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

--------------020102020900010301060101-- --------------ms010106010501020500030809 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRnzCC BXQwggRcoAMCAQICECdm7lbrSfOOq9dwovyE3iIwDQYJKoZIhvcNAQEMBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w MDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4MzhaMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJHoVJLSClaxrA0k3cXPRGd0mSs3 o30jcABxvFPfxPoqEo9LfxBWvZ9wcrdhf8lLDxenPeOwBGHu/xGXx/SGPgr6Plz5k+Y0etkU a+ecs4Wggnp2r3GQ1+z9DfqcbPrfsIL0FH75vsSmL09/mX+1/GdDcr0MANaJ62ss0+2PmBwU q37l42782KjkkiTaQ2tiuFX96sG8bLaL8w6NmuSbbGmZ+HhIMEXVreENPEVg/DKWUSe8Z8PK LrZr6kbHxyCgsR9l3kgIuqROqfKDRjeE6+jMgUhDZ05yKptcvUwbKIpcInu0q5jZ7uBRg8MJ Rk5tPpn6lRfafDNXQTyNUe0LtlyvLGMa31fIP7zpXcSbr0WZ4qNaJLS6qVY9z2+q/0lYvvCo //S4rek3+7q49As6+ehDQh6J2ITLE/HZu+GJYLiMKFasFB2cCudx688O3T2plqFIvTz3r7UN IkzAEYHsVjv206LiW7eyBCJSlYCTaeiOTGXxkQMtcHQC6otnFSlpUgK7199QalVGv6CjKGF/ cNDDoqosIapHziicBkV2v4IYJ7TVrrTLUOZr9EyGcTDppt8WhuDY/0Dd+9BCiH+jMzouXB5B EYFjzhhxayvspoq3MVw6akfgw3lZ1iAar/JqmKpyvFdK0kuduxD8sExB5e0dPV4onZzMv7NR 2qdH5YRTAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFLuvfgI9+qbxPISOre44mOzZMjLUMA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMBAf8E BTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3Js LnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEE KTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEB DAUAA4IBAQBkv4PxX5qF0M24oSlXDeha99HpPvJ2BG7xUnC7Hjz/TQ10asyBgiXTw6AqXUz1 uouhbcRUCXXH4ycOXYR5N0ATd/W0rBzQO6sXEtbvNBh+K+l506tXRQyvKPrQ2+VQlYi734VX aX2S2FLKc4G/HPPmuG5mEQWzHpQtf5GVklnxTM6jkXFMfEcMOwsZ9qGxbIY+XKrELoLL+QeW ukhNkPKUyKlzousGeyOd3qLzTVWfemFFmBhox15AayP1eXrvjLVri7dvRvR78T1LBNiTgFla 4EEkHbKPFWBYR9vvbkb9FfXZX5qz29i45ECzzZc5roW7HY683Ieb0abv8TtvEDhvMIIF5jCC A86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n 9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgz KlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikF lgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9t GKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNV HQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQI MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEG CCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09N T0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81 zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIa l9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwp WZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNM UH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfW CcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X 72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60 ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQv dVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDN XFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIwggY5 MIIFIaADAgECAhEAkJNVgmy0T3j/sFnejfTMyTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTQwOTE2MDAwMDAwWhcN MTcwOTE1MjM1OTU5WjCCATcxCzAJBgNVBAYTAkdCMRAwDgYDVQQREwdXRjQgNFdBMRcwFQYD VQQIEw5XZXN0IFlvcmtzaGlyZTESMBAGA1UEBxMJV2FrZWZpZWxkMRQwEgYDVQQJEwtHcmFu Z2UgTW9vcjEfMB0GA1UECRMWODkgR3JlZW5maWVsZCBDcmVzY2VudDEXMBUGA1UEChMOR3Jp ZG1lcmdlIEx0ZC4xNDAyBgNVBAsTK0lzc3VlZCB0aHJvdWdoIEdyaWRtZXJnZSBMdGQuIEUt UEtJIE1hbmFnZXIxHzAdBgNVBAsTFkNvcnBvcmF0ZSBTZWN1cmUgRW1haWwxFjAUBgNVBAMT DVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALTtrEYc/EYQZDn+/Byj786j qzQJukVnEZ0qu6G8Y/QZphmITLPJJCxlCvJhRGCt5zRDfwG1lM0k77mTVP166mrPMKfEbhAF mhW54app3f02j/E0T73Wkwqhc2xj+vs6ox+kXRZIiEa/VY1TXd8ALZZAJ2uPQm+3QByE0cO6 7Q7jr5dmZuXAuygh5Q7MvzxL0vKmxhJ1n0veVDwk+BifimRX+HHU3XTGrqySkiN4Amdm7ESD qdO7UAoezIGZoA/fTJE9CS4f4tVXcKhfGlp/Tw3K9q9cp6cjYD802hnFoiSQ9PgLviP20lcH CIGn91WkYhuYG9u8Fzgzmu0yVK5L0kkCAwEAAaOCAdswggHXMB8GA1UdIwQYMBaAFIKvbIz4 xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBTSD2iG48824eEQkBLu4BgdWzh49TAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw RgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAwUwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1 cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9j YS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy bDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNv bS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0 LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAq8C9mIiSV9Nj9ZjHa 1kupbDGYy57v5fCk9lT++uiwGBP9yIFd9Gr8wISOl+96l9OLo8E+5CcPLyt96H4ez/ksXjC1 5EhzuhUB7HNi2b9GLDenjiHW4vBmSoIAbt9Pnz6zZsPH7eBPBcqkIWLFuqKBYUoXKLpzrVtr Kgv6PM3t2+4YakBnMWjpcqzinurEeGq4mh3gHTv03wcyT6eQVCu5k4yaJxoQReYtYIjv+W+m LmT/ZW61ZATZb2adV8xPejUlWSq4+2bpRbXZpD9FAmomNC8fSvGUUhMfYq5t5IUPHfP0kEH5 WQVWgVfpcf6Q8rnpWznsMiJrucUpJf8ZenHtMYIEKDCCBCQCAQEwga0wgZcxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTAJ BgUrDgMCGgUAoIICTzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTAzMzEwNzQyMjNaMCMGCSqGSIb3DQEJBDEWBBRPIYoxtIRAe4ryDphCAuIcW+pQcTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG+BgkrBgEEAYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTCBwAYLKoZIhvcNAQkQAgsxgbCgga0w gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0 T3j/sFnejfTMyTANBgkqhkiG9w0BAQEFAASCAQCQ1jKGBFDxVnv1uOEHN+4sf1rimTh49CtA 5p3lz+l+QvaxobhmDsULZ51MarHPMMbrJ95bO/eBh1bNSrksDVDulLGvvXb5sba4iA48uSr7 t8cGim0Nu1mHYlgwNEPjKnP2+prh3S1WkRVSSHJXZ7chltLb15koLFc/InMNhibAZJ5Whwvc 9UtfuT6FEBV/Y3JIGCevFmWUut5sZG9mlEFH6t/4nUZso0l+2eOpUke887ZrMyiFtFaoDIEg 3zKlN1Xtwy9+GELn8SZkELjR6LpVOwNO8SkyQ9JeqbNohpF0EHP/aLzXbb4ZZ+5I4ow9VMT8 R2TfIA3vIHVSmAOS7Wo/AAAAAAAA --------------ms010106010501020500030809-- From nobody Tue Mar 31 00:45:51 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 0A8B01B2B21 for ; Tue, 31 Mar 2015 00:45:51 -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 5cc1Kg9Ojknz for ; Tue, 31 Mar 2015 00:45:49 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::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 C3A671B2B17 for ; Tue, 31 Mar 2015 00:45:49 -0700 (PDT) Received: by pddn5 with SMTP id n5so12447011pdd.2 for ; Tue, 31 Mar 2015 00:45:49 -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=RCcbDxsNmPjnDvTUlbsd3ivh7rH/a2VHRCUTiu3y6x4=; b=N8OhPE7QE5YOiNcunVZgeFzZ923SdEgHQL/bKrvxw5Cp1WfU+5E4jRZR9+psHXhaUg SKrThuOOpBa9+IhMZ0rlGMVPo5nvPafP1wbHflyjA8dcoeiJO+Nh/RbvInxo0r/kYiaL H7BUO6rS0vr82x75MowRggxKFiVZr6nTzgvyWA7z/pDWbheTzXfqNZmA6uO09iqIA6nC 6E3wyIckkYITCuXMbF3mmVDU/OK9yn1ZrPj7GxFCqUSmbXhit+G8e8+IaFZ20gPKZwW2 RHmCHZQLLdSaTMUC+jqybpNdQ7sauMNS2t0yYVcKYvoDBtv2qeFWNYATi+4VJv7Pax3V Fxkg== X-Received: by 10.70.129.108 with SMTP id nv12mr66400046pdb.71.1427787949455; Tue, 31 Mar 2015 00:45:49 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.76.100 with HTTP; Tue, 31 Mar 2015 00:45:29 -0700 (PDT) In-Reply-To: <551A4FDF.4040000@gridmerge.com> References: <30526.1427136071@sandelman.ca> <10807.1427243740@sandelman.ca> <11436.1427750888@sandelman.ca> <551A4FDF.4040000@gridmerge.com> From: Thomas Watteyne Date: Tue, 31 Mar 2015 09:45:29 +0200 X-Google-Sender-Auth: HvtArWm9uvpwwJZeSNutIe2lfuE Message-ID: To: "robert.cragie@gridmerge.com" , Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=001a11c317d08abd81051290c9a3 Archived-At: Subject: Re: [Roll] proposed amendments to ROLL charter 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, 31 Mar 2015 07:45:51 -0000 --001a11c317d08abd81051290c9a3 Content-Type: text/plain; charset=UTF-8 Robert, Change "IPv6-in-IPv6 encapsulation" to "IPIP encapsulation" Do you mean the reverse? Thomas On Tue, Mar 31, 2015 at 9:42 AM, Robert Cragie wrote: > Hope I'm not too late... > > I support the charter update. Just a couple of suggestions: > > * Change "IPv6-in-IPv6 encapsulation" to "IPIP encapsulation" as also > suggested by Thomas. AFAICT "IPIP" is not widely used and when it is, it > refers more to IPv4. > * Change "in the 6lowpan HC context" to "in the 6LoWPAN adaptation layer > context". This generalises it to include dispatch-based solutions as well, > otherwise it could be read as only looking at NHC-based variants. > > Robert > > > On 30/03/2015 22:28, Michael Richardson wrote: > > Michael Richardson wrote: > > The charter discussion will remain open until March 30. This will put > > it on the telechat for April 9. > > Last change to say something + or - about this charter update. > > > > > > _______________________________________________ > Roll mailing listRoll@ietf.orghttps://www.ietf.org/mailman/listinfo/roll > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --001a11c317d08abd81051290c9a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Robert,

Change "IPv6-i= n-IPv6 encapsulation" to "IPIP encapsulation"

Do you mean the reverse?

Thomas<= /div>


On Tue, Mar 31, 2015 at 9:42 AM, Robert Cragie <robert.cragie= @gridmerge.com> wrote:
=20 =20 =20
Hope I'm not too late...

I support the charter update. Just a couple of suggestions:

* Change "IPv6-in-IPv6 encapsulation" to "IPIP encapsula= tion" as also suggested by Thomas. AFAICT "IPIP" is not widely used an= d when it is, it refers more to IPv4.
* Change "in the 6lowpan HC context" to "in the 6LoWPAN = adaptation layer context". This generalises it to include dispatch-based solutions as well, otherwise it could be read as only looking at NHC-based variants.

Robert


On 30/03/2015 22:28, Michael Richardson wrote:
Michael Richardson <mcr+ietf@sandelman.ca> wrote:
    > The charter discussion will remain open until March 30. This will =
put
    > it on the telechat for April 9.

Last change to say something + or - about this charter update.





________________________________________=
_______
Roll mailing list
Roll@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/roll


_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll


--001a11c317d08abd81051290c9a3-- From nobody Tue Mar 31 02:05:46 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 234CA1A036E for ; Tue, 31 Mar 2015 02:05:45 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 IRFXGjcRt511 for ; Tue, 31 Mar 2015 02:05:43 -0700 (PDT) Received: from mailscan1.extendcp.co.uk (mailscan6.extendcp.co.uk [79.170.43.52]) (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 2C18B1A037A for ; Tue, 31 Mar 2015 02:05:43 -0700 (PDT) Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan2.hi.local) by mailscan-g64.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1Ycs7B-0004cM-4L; Tue, 31 Mar 2015 10:05:41 +0100 Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail41.extendcp.co.uk) by mailscan2.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1Ycs79-0006xr-4C; Tue, 31 Mar 2015 10:05:41 +0100 Received: from host86-156-208-9.range86-156.btcentralplus.com ([86.156.208.9] helo=[192.168.0.6]) by mail41.extendcp.com with esmtpsa (UNKNOWN:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1Ycs74-0006d4-Du; Tue, 31 Mar 2015 10:05:34 +0100 Message-ID: <551A6358.4010003@gridmerge.com> Date: Tue, 31 Mar 2015 10:05:28 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Thomas Watteyne , Routing Over Low power and Lossy networks References: <30526.1427136071@sandelman.ca> <10807.1427243740@sandelman.ca> <11436.1427750888@sandelman.ca> <551A4FDF.4040000@gridmerge.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010703030404050006080102" X-Authenticated-As: robert.cragie@gridmerge.com X-Extend-Src: mailout Archived-At: Subject: Re: [Roll] proposed amendments to ROLL charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com, 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, 31 Mar 2015 09:05:45 -0000 This is a cryptographically signed message in MIME format. --------------ms010703030404050006080102 Content-Type: multipart/alternative; boundary="------------040105090101030204000705" This is a multi-part message in MIME format. --------------040105090101030204000705 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Er yes, apologies for the poor editing! Robert On 31/03/2015 08:45, Thomas Watteyne wrote: > Robert, > > Change "IPv6-in-IPv6 encapsulation" to "IPIP encapsulation" > > > Do you mean the reverse? > > Thomas > > > On Tue, Mar 31, 2015 at 9:42 AM, Robert Cragie=20 > > wrot= e: > > Hope I'm not too late... > > I support the charter update. Just a couple of suggestions: > > * Change "IPv6-in-IPv6 encapsulation" to "IPIP encapsulation" as > also suggested by Thomas. AFAICT "IPIP" is not widely used and > when it is, it refers more to IPv4. > * Change "in the 6lowpan HC context" to "in the 6LoWPAN adaptation > layer context". This generalises it to include dispatch-based > solutions as well, otherwise it could be read as only looking at > NHC-based variants. > > Robert > > > On 30/03/2015 22:28, Michael Richardson wrote: >> Michael Richardson wrote: >> > The charter discussion will remain open until March 30. Thi= s will put >> > it on the telechat for April 9. >> >> Last change to say something + or - about this charter update. >> >> >> >> >> _______________________________________________ >> 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 > > --------------040105090101030204000705 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Er yes, apologies for the poor editing!

Robert

On 31/03/2015 08:45, Thomas Watteyne wrote:
Robert,

Change "IPv6-in-IPv6 encapsulation" to "IPIP encapsulation"

Do you mean the reverse?

Thomas


On Tue, Mar 31, 2015 at 9:42 AM, Robert Cragie <robert.cragie@gridmerge.com> wrote:
Hope I'm not too= late...

I support the charter update. Just a couple of suggestions:

* Change "IPv6-in-IPv6 encapsulation" to "IPIP encapsulation" as also suggested by Thomas. AFAICT "IPIP" is not widely used and when it is, it refers more to IPv4.
* Change "in the 6lowpan HC context" to "in the 6LoWPAN adaptation layer context". This generalises it to include dispatch-based solutions as well, otherwise it could be read as only looking at NHC-based variants.

Robert


On 30/03/2015 22:28, Michael Richardson wrote:
= 
Michael Richardson <mcr+ietf@sande=
lman.ca> wrote:
    > The charter discussion will remain open until March 30. This wil=
l put
    > it on the telechat for April 9.

Last change to say something + or - about this charter update.





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


_______________________________________________
Roll mailing list
R= oll@ietf.org
https://www.ietf.org/mailman/listinfo/r= oll



--------------040105090101030204000705-- --------------ms010703030404050006080102 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRnzCC BXQwggRcoAMCAQICECdm7lbrSfOOq9dwovyE3iIwDQYJKoZIhvcNAQEMBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w MDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4MzhaMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJHoVJLSClaxrA0k3cXPRGd0mSs3 o30jcABxvFPfxPoqEo9LfxBWvZ9wcrdhf8lLDxenPeOwBGHu/xGXx/SGPgr6Plz5k+Y0etkU a+ecs4Wggnp2r3GQ1+z9DfqcbPrfsIL0FH75vsSmL09/mX+1/GdDcr0MANaJ62ss0+2PmBwU q37l42782KjkkiTaQ2tiuFX96sG8bLaL8w6NmuSbbGmZ+HhIMEXVreENPEVg/DKWUSe8Z8PK LrZr6kbHxyCgsR9l3kgIuqROqfKDRjeE6+jMgUhDZ05yKptcvUwbKIpcInu0q5jZ7uBRg8MJ Rk5tPpn6lRfafDNXQTyNUe0LtlyvLGMa31fIP7zpXcSbr0WZ4qNaJLS6qVY9z2+q/0lYvvCo //S4rek3+7q49As6+ehDQh6J2ITLE/HZu+GJYLiMKFasFB2cCudx688O3T2plqFIvTz3r7UN IkzAEYHsVjv206LiW7eyBCJSlYCTaeiOTGXxkQMtcHQC6otnFSlpUgK7199QalVGv6CjKGF/ cNDDoqosIapHziicBkV2v4IYJ7TVrrTLUOZr9EyGcTDppt8WhuDY/0Dd+9BCiH+jMzouXB5B EYFjzhhxayvspoq3MVw6akfgw3lZ1iAar/JqmKpyvFdK0kuduxD8sExB5e0dPV4onZzMv7NR 2qdH5YRTAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFLuvfgI9+qbxPISOre44mOzZMjLUMA4GA1UdDwEB/wQEAwIBhjAPBgNVHRMBAf8E BTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3Js LnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEE KTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEB DAUAA4IBAQBkv4PxX5qF0M24oSlXDeha99HpPvJ2BG7xUnC7Hjz/TQ10asyBgiXTw6AqXUz1 uouhbcRUCXXH4ycOXYR5N0ATd/W0rBzQO6sXEtbvNBh+K+l506tXRQyvKPrQ2+VQlYi734VX aX2S2FLKc4G/HPPmuG5mEQWzHpQtf5GVklnxTM6jkXFMfEcMOwsZ9qGxbIY+XKrELoLL+QeW ukhNkPKUyKlzousGeyOd3qLzTVWfemFFmBhox15AayP1eXrvjLVri7dvRvR78T1LBNiTgFla 4EEkHbKPFWBYR9vvbkb9FfXZX5qz29i45ECzzZc5roW7HY683Ieb0abv8TtvEDhvMIIF5jCC A86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n 9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgz KlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikF lgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9t GKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK +xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNV HQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQI MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9j cmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEG CCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09N T0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81 zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIa l9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwp WZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNM UH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfW CcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X 72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60 ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQv dVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDN XFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIwggY5 MIIFIaADAgECAhEAkJNVgmy0T3j/sFnejfTMyTANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTQwOTE2MDAwMDAwWhcN MTcwOTE1MjM1OTU5WjCCATcxCzAJBgNVBAYTAkdCMRAwDgYDVQQREwdXRjQgNFdBMRcwFQYD VQQIEw5XZXN0IFlvcmtzaGlyZTESMBAGA1UEBxMJV2FrZWZpZWxkMRQwEgYDVQQJEwtHcmFu Z2UgTW9vcjEfMB0GA1UECRMWODkgR3JlZW5maWVsZCBDcmVzY2VudDEXMBUGA1UEChMOR3Jp ZG1lcmdlIEx0ZC4xNDAyBgNVBAsTK0lzc3VlZCB0aHJvdWdoIEdyaWRtZXJnZSBMdGQuIEUt UEtJIE1hbmFnZXIxHzAdBgNVBAsTFkNvcnBvcmF0ZSBTZWN1cmUgRW1haWwxFjAUBgNVBAMT DVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALTtrEYc/EYQZDn+/Byj786j qzQJukVnEZ0qu6G8Y/QZphmITLPJJCxlCvJhRGCt5zRDfwG1lM0k77mTVP166mrPMKfEbhAF mhW54app3f02j/E0T73Wkwqhc2xj+vs6ox+kXRZIiEa/VY1TXd8ALZZAJ2uPQm+3QByE0cO6 7Q7jr5dmZuXAuygh5Q7MvzxL0vKmxhJ1n0veVDwk+BifimRX+HHU3XTGrqySkiN4Amdm7ESD qdO7UAoezIGZoA/fTJE9CS4f4tVXcKhfGlp/Tw3K9q9cp6cjYD802hnFoiSQ9PgLviP20lcH CIGn91WkYhuYG9u8Fzgzmu0yVK5L0kkCAwEAAaOCAdswggHXMB8GA1UdIwQYMBaAFIKvbIz4 xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBTSD2iG48824eEQkBLu4BgdWzh49TAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw RgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAwUwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1 cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9j YS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy bDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LmNvbW9kb2NhLmNv bS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0 LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAq8C9mIiSV9Nj9ZjHa 1kupbDGYy57v5fCk9lT++uiwGBP9yIFd9Gr8wISOl+96l9OLo8E+5CcPLyt96H4ez/ksXjC1 5EhzuhUB7HNi2b9GLDenjiHW4vBmSoIAbt9Pnz6zZsPH7eBPBcqkIWLFuqKBYUoXKLpzrVtr Kgv6PM3t2+4YakBnMWjpcqzinurEeGq4mh3gHTv03wcyT6eQVCu5k4yaJxoQReYtYIjv+W+m LmT/ZW61ZATZb2adV8xPejUlWSq4+2bpRbXZpD9FAmomNC8fSvGUUhMfYq5t5IUPHfP0kEH5 WQVWgVfpcf6Q8rnpWznsMiJrucUpJf8ZenHtMYIEKDCCBCQCAQEwga0wgZcxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTAJ BgUrDgMCGgUAoIICTzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTAzMzEwOTA1MjhaMCMGCSqGSIb3DQEJBDEWBBRUL3CnPrjHGfdkpsLjrps5uKKB/zBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG+BgkrBgEEAYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhEAkJNVgmy0T3j/sFnejfTMyTCBwAYLKoZIhvcNAQkQAgsxgbCgga0w gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkJNVgmy0 T3j/sFnejfTMyTANBgkqhkiG9w0BAQEFAASCAQAC/GOBx/7xvz/tSKnb1TMWBGGOj8lgpztr VmfmKCOeQWUE7YJBfKVr16SbYdrBSiZCzGTFVbuY1THuJAscwQZuGkFS1jb+RQTme0JCUhXX FIRnxcooHAgaK8JRhJPCZeStUw4bDW0IYiJR7X8xJItJW+PvYQXkF/gPCwep+PIRLRba9Y+g T375Fj2Wl2+DI/3t77MH6uRD6PcpBGZSDFJZEy9AuNcLc2tzb7SvNR5lXGyemEtY0kxHbjjE 9cFR/YGdSs+GpeEOcHr6MMKzzDzVz1g/Gu5QWPDBeVuVCe/5uJE3JbOIgS57F5NiV0HusadZ jeKcwqVryG1gRY4WTSq4AAAAAAAA --------------ms010703030404050006080102-- From nobody Tue Mar 31 03:50: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 5724F1A908F for ; Tue, 31 Mar 2015 03:49:58 -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 ckw9JpgTKdvA for ; Tue, 31 Mar 2015 03:49:55 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D0501A907C for ; Tue, 31 Mar 2015 03:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8800; q=dns/txt; s=iport; t=1427798996; x=1429008596; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VeHOsB+iBJq5dLXPKkqcMcBPQ+5YTOCNIDCDqiKkxtw=; b=CjwY6PbFHKyXJNAS7B8PTLhpeRjSWW0R61LHI4Mh/3YsyOtLaDH+bq5J hnFUFJD3E2wESKBmbGnv1dD8gsSYNB7WX030+W66Dz+VeraKFPHlHuD93 oH603qbDEjNfE4aLntHRUu8slKyyFdqo2ggi4uuJnM0K+2OWiUW1JC1bo o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DbCAC8ehpV/5ldJa1cgwZSXAXDLoI8hXMCgT9MAQEBAQEBfYQUAQEBBDo/DAQCAQgRAQMBAQsUCQcyFAMGCAIEDgUIE4gUDcxzAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sphCAKHTEHBoMRgRYFhFaMDINyhAOCAYEcOoVTjREiggIcgVBvgQJCfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,500,1422921600"; d="scan'208";a="404905435" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 31 Mar 2015 10:49:54 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t2VAnsMk012233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Mar 2015 10:49:54 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.104]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Tue, 31 Mar 2015 05:49:54 -0500 From: "Pascal Thubert (pthubert)" To: Michael Richardson Thread-Topic: [Roll] proposed amendments to ROLL charter Thread-Index: AQHQZZj1TlAC6v55Kk6GWqyOVvIIHp02cOHg Date: Tue, 31 Mar 2015 10:49:53 +0000 Deferred-Delivery: Tue, 31 Mar 2015 10:49:00 +0000 Message-ID: References: <30526.1427136071@sandelman.ca> In-Reply-To: <30526.1427136071@sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.23] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Routing Over Low power and Lossy networks Subject: Re: [Roll] proposed amendments to ROLL charter 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, 31 Mar 2015 10:49:58 -0000 Hello Michael (and all): I fully support the additions. Since you are at it, I would like to explore= a deeper realignment. ROLL is now in charge of the maintenance of RPL, isn't it?=20 - I think that this should be a work item in the charter.=20 - this should replace elements that were or are being delivered such as met= rics, security, and RPL itself And if that's so, wouldn't it make sense to study how RPL works outside LLN= s and in mixed environments?=20 - I'd like to see work on RPL over foo where foo is Ethernet or Wi-Fi. Appl= icability of RPL in various environments outside LLN would be of interest, = e.g. to build a Wi-Fi mesh or an unmanaged network. It seems that a DT will= form at HOMENET to select a routing protocol, and an applicability stateme= nt of RPL for that case would be a good read if we can produce it in time. - From our experience of actually doing RPL over Ethernet, it is mostly a m= atter of *not* using the packet artifacts, probably not using the stretch i= n local repair, and reacting immediately to changes in link state. This is = a very small spec indeed, mostly guidance on what to use and what not to us= e from RFC 6550, how to tune some parameters, which OF to use and how.=20 - The work should also detail the mode where there is a backbone and a virt= ual root. I think that the current charter does not cover work outside LLN = but considering that we are the group that knows RPL best, that work should= happen here. What do you think? Pascal > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Michael Richardson > Sent: lundi 23 mars 2015 19:41 > To: roll@ietf.org > Subject: [Roll] proposed amendments to ROLL charter >=20 >=20 > The following changes are proposed for the ROLL charter to include the wo= rk to > profile 6553/6554/IPIP, and to compress it. >=20 > To the pre-amble: >=20 > After: > - In most cases, LLNs will be employed over link layers with restricted > frame-sizes, thus a routing protocol for LLNs should be specifically > adapted for such link layers. >=20 > Add: > +- LLN routing protocols have to be very careful when trading off > +efficiency > + for generality; many LLN nodes do not have resources to waste. >=20 > After: > The solution must include unicast and multicast considerations. >=20 > Add: > +The Working Group will document how non-control packets are routed when > +they cross the LLN, and when they enter and exit the LLN: the > +appropriate use of > +RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how > +routing loops are detected. In consultation with the 6lo WG, the > +Working Group will design a method to these routing headers into a > +single block. The result will have a shared WGLC with 6lo. >=20 > To Work Items, add: > + - A document detailing when to use RFC6553, RFC6554 and IPIP > + encapsulation. > + > + - A document detailing how to compress RFC6553, RFC6554 and IP head= ers > + in the 6lowPAN HC context. >=20 >=20 > The resulting charter (after reformatting of some of the ugly text wrappi= ng on > the web site) is: >=20 > ---- > Low power and Lossy networks (LLNs) are made up of many embedded devices > with limited power, memory, and processing resources. They are interconne= cted > by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, = wired or > other low power PLC (Powerline Communication) links. LLNs are transitioni= ng to > an end-to-end IP-based solution to avoid the problem of non-interoperable > networks interconnected by protocol translation gateways and proxies. >=20 > Generally speaking, LLNs have at least five distinguishing > characteristics: > - LLNs operate with a hard, very small bound on state. > - In most cases, LLN optimize for saving energy. > - Typical traffic patterns are not simply unicast flows (e.g. in some cas= es most if > not all traffic can be point to multipoint). > - In most cases, LLNs will be employed over link layers with restricted > frame-sizes, thus a routing protocol for LLNs should be specifically > adapted for such link layers. > - LLN routing protocols have to be very careful when trading off efficien= cy > for generality; many LLN nodes do not have resources to waste. >=20 > These specific properties cause LLNs to have specific routing requirement= s. >=20 > Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been > evaluated by the working group and have in their current form been found = to > not satisfy all of these specific routing requirements. >=20 > The Working Group is focused on routing issues for LLN. >=20 > There is a wide scope of application areas for LLNs, including industrial > monitoring, building automation (HVAC, lighting, access control, fire), > connected homes, healthcare, environmental monitoring, urban sensor > networks (e.g. Smart Grid), asset tracking. The Working Group focuses on > routing solutions for a subset of these: industrial, connected home, buil= ding and > urban sensor networks for which routing requirements have been specified. > These application-specific routing requirement documents will be used for > protocol design. >=20 > The Working Group focuses only on IPv6 routing architectural framework fo= r > these application scenarios. The Framework will take into consideration v= arious > aspects including high reliability in the presence of time varying loss > characteristics and connectivity while permitting low-power operation wit= h very > modest memory and CPU pressure in networks potentially comprising a very > large number (several thousands) of nodes. >=20 > The Working Group will pay particular attention to routing security and > manageability (e.g., self routing configuration) issues. It will also nee= d to > consider the transport characteristic the routing protocol messages will > experience. Mechanisms that protect an LLN from congestion collapse or th= at > establish some degree of fairness between concurrent communication sessio= ns > are out of scope of the Working Group. It is expected that upper-layer > applications utilizing LLNs define appropriate mechanisms. >=20 > The solution must include unicast and multicast considerations. >=20 > The Working Group will document how non-control packets are routed when > they cross the LLN, and when they enter and exit the LLN: the appropriate= use of > RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how routing > loops are detected. In consultation with the 6lo WG, the Working Group wi= ll > design a method to these routing headers into a single block. The result= will > have a shared WGLC with 6lo. >=20 > Work Items: >=20 > - Specification of routing metrics used in path calculation. This > includes static and dynamic link/node attributes required for rout= ing in > LLNs. >=20 > - Provide an architectural framework for routing and path selection = at > Layer 3 (Routing for LLN Architecture) that addresses such issues = as > whether LLN routing require a distributed and/or centralized path > computation models, whether additional hierarchy is necessary and = how it > is applied. >=20 > Manageability will be considered with each approach, along with va= rious > trade-offs for maintaining low power operation, including the pres= ence of > non-trivial loss and networks with a very large number of nodes. >=20 > - Produce a routing security framework for routing in LLNs. >=20 > - Protocol work: The Working Group will consider specific routing > requirements from the four application documents collectively, and > specify either a new protocol or extend an existing routing protoc= ol > in cooperation with the relevant Working Group. > If requirements from the four target application areas cannot be m= et > with a single protocol, the WG may choose to specify or extend mor= e than > one protocol (this will require a recharter of the WG). >=20 > - Documentation of applicability statement of ROLL routing protocols= . >=20 > - A document detailing when to use RFC6553, RFC6554 and IPIP > encapsulation. >=20 > - A document detailing how to compress RFC6553, RFC6554 and IP heade= rs > in the 6lowPAN HC context. >=20 >=20 >=20 > $Id: charter.txt,v 1.3 2015/03/23 18:33:38 mcr Exp $ >=20 >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ From nobody Tue Mar 31 07:10:09 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 D97631ACD6B for ; Tue, 31 Mar 2015 07:10:07 -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 49rH0Do83Jzm for ; Tue, 31 Mar 2015 07:10:04 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (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 E62C31ACD60 for ; Tue, 31 Mar 2015 07:10:03 -0700 (PDT) Received: by lbdc10 with SMTP id c10so13262613lbd.2 for ; Tue, 31 Mar 2015 07:10:02 -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=qz8Qjs6s0A3luGnMQZtIPuQFlZYaJwco0QOgXQxsqNQ=; b=tm00tVHdniru9rT/5VX9o/pRfSqIUAJUhmtGgyxl5DGyXPHu1tJ8Vrud4kEalXztpG 6pk1+DIj0IYfW/JMuLDKaLSyA+3NGVuNfb/5O53A6fS0mAE+YV+lOkMyIDZKPkK2kcCZ MQN+qY20ywLsu3r1DEV/Qh7tjHOgPcc8F2tCutxnWTiOyYbEOb/ExR6EntvXZJfdabJX MXp3BjZ2jvEC5+H7mYL7yJ2BeL0x7+58zgNvZI82wb5/gpnl+bvvKeKa2A3afqVMGaDa sLpTzRRF8XxqWGOD7bbSEt57ElGEe7S1Th5jUnvUvPVDkmxTvBU0cgtxm6d7am8Pk9qc UwZg== MIME-Version: 1.0 X-Received: by 10.112.10.197 with SMTP id k5mr3691307lbb.86.1427811002380; Tue, 31 Mar 2015 07:10:02 -0700 (PDT) Received: by 10.25.212.8 with HTTP; Tue, 31 Mar 2015 07:10:02 -0700 (PDT) In-Reply-To: References: <30526.1427136071@sandelman.ca> Date: Tue, 31 Mar 2015 17:10:02 +0300 Message-ID: From: Ines Robles To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=001a1134cb8a9a78400512962719 Archived-At: Cc: Michael Richardson Subject: Re: [Roll] proposed amendments to ROLL charter 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, 31 Mar 2015 14:10:08 -0000 --001a1134cb8a9a78400512962719 Content-Type: text/plain; charset=UTF-8 Hi Pascal, Thank you very much for your comments, we are going to include them in our meeting. To all, There are additional topics that you would like to include in the charter? Please justify. Thank you very much, Michael and Ines 2015-03-31 13:49 GMT+03:00 Pascal Thubert (pthubert) : > Hello Michael (and all): > > I fully support the additions. Since you are at it, I would like to > explore a deeper realignment. > > ROLL is now in charge of the maintenance of RPL, isn't it? > - I think that this should be a work item in the charter. > - this should replace elements that were or are being delivered such as > metrics, security, and RPL itself > > And if that's so, wouldn't it make sense to study how RPL works outside > LLNs and in mixed environments? > - I'd like to see work on RPL over foo where foo is Ethernet or Wi-Fi. > Applicability of RPL in various environments outside LLN would be of > interest, e.g. to build a Wi-Fi mesh or an unmanaged network. It seems that > a DT will form at HOMENET to select a routing protocol, and an > applicability statement of RPL for that case would be a good read if we can > produce it in time. > - From our experience of actually doing RPL over Ethernet, it is mostly a > matter of *not* using the packet artifacts, probably not using the stretch > in local repair, and reacting immediately to changes in link state. This is > a very small spec indeed, mostly guidance on what to use and what not to > use from RFC 6550, how to tune some parameters, which OF to use and how. > - The work should also detail the mode where there is a backbone and a > virtual root. I think that the current charter does not cover work outside > LLN but considering that we are the group that knows RPL best, that work > should happen here. > > What do you think? > > Pascal > > > > -----Original Message----- > > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Michael > Richardson > > Sent: lundi 23 mars 2015 19:41 > > To: roll@ietf.org > > Subject: [Roll] proposed amendments to ROLL charter > > > > > > The following changes are proposed for the ROLL charter to include the > work to > > profile 6553/6554/IPIP, and to compress it. > > > > To the pre-amble: > > > > After: > > - In most cases, LLNs will be employed over link layers with restricted > > frame-sizes, thus a routing protocol for LLNs should be specifically > > adapted for such link layers. > > > > Add: > > +- LLN routing protocols have to be very careful when trading off > > +efficiency > > + for generality; many LLN nodes do not have resources to waste. > > > > After: > > The solution must include unicast and multicast considerations. > > > > Add: > > +The Working Group will document how non-control packets are routed when > > +they cross the LLN, and when they enter and exit the LLN: the > > +appropriate use of > > +RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how > > +routing loops are detected. In consultation with the 6lo WG, the > > +Working Group will design a method to these routing headers into a > > +single block. The result will have a shared WGLC with 6lo. > > > > To Work Items, add: > > + - A document detailing when to use RFC6553, RFC6554 and IPIP > > + encapsulation. > > + > > + - A document detailing how to compress RFC6553, RFC6554 and IP > headers > > + in the 6lowPAN HC context. > > > > > > The resulting charter (after reformatting of some of the ugly text > wrapping on > > the web site) is: > > > > ---- > > Low power and Lossy networks (LLNs) are made up of many embedded devices > > with limited power, memory, and processing resources. They are > interconnected > > by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, > wired or > > other low power PLC (Powerline Communication) links. LLNs are > transitioning to > > an end-to-end IP-based solution to avoid the problem of non-interoperable > > networks interconnected by protocol translation gateways and proxies. > > > > Generally speaking, LLNs have at least five distinguishing > > characteristics: > > - LLNs operate with a hard, very small bound on state. > > - In most cases, LLN optimize for saving energy. > > - Typical traffic patterns are not simply unicast flows (e.g. in some > cases most if > > not all traffic can be point to multipoint). > > - In most cases, LLNs will be employed over link layers with restricted > > frame-sizes, thus a routing protocol for LLNs should be specifically > > adapted for such link layers. > > - LLN routing protocols have to be very careful when trading off > efficiency > > for generality; many LLN nodes do not have resources to waste. > > > > These specific properties cause LLNs to have specific routing > requirements. > > > > Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been > > evaluated by the working group and have in their current form been found > to > > not satisfy all of these specific routing requirements. > > > > The Working Group is focused on routing issues for LLN. > > > > There is a wide scope of application areas for LLNs, including industrial > > monitoring, building automation (HVAC, lighting, access control, fire), > > connected homes, healthcare, environmental monitoring, urban sensor > > networks (e.g. Smart Grid), asset tracking. The Working Group focuses on > > routing solutions for a subset of these: industrial, connected home, > building and > > urban sensor networks for which routing requirements have been specified. > > These application-specific routing requirement documents will be used for > > protocol design. > > > > The Working Group focuses only on IPv6 routing architectural framework > for > > these application scenarios. The Framework will take into consideration > various > > aspects including high reliability in the presence of time varying loss > > characteristics and connectivity while permitting low-power operation > with very > > modest memory and CPU pressure in networks potentially comprising a very > > large number (several thousands) of nodes. > > > > The Working Group will pay particular attention to routing security and > > manageability (e.g., self routing configuration) issues. It will also > need to > > consider the transport characteristic the routing protocol messages will > > experience. Mechanisms that protect an LLN from congestion collapse or > that > > establish some degree of fairness between concurrent communication > sessions > > are out of scope of the Working Group. It is expected that upper-layer > > applications utilizing LLNs define appropriate mechanisms. > > > > The solution must include unicast and multicast considerations. > > > > The Working Group will document how non-control packets are routed when > > they cross the LLN, and when they enter and exit the LLN: the > appropriate use of > > RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how routing > > loops are detected. In consultation with the 6lo WG, the Working Group > will > > design a method to these routing headers into a single block. The > result will > > have a shared WGLC with 6lo. > > > > Work Items: > > > > - Specification of routing metrics used in path calculation. This > > includes static and dynamic link/node attributes required for > routing in > > LLNs. > > > > - Provide an architectural framework for routing and path selection > at > > Layer 3 (Routing for LLN Architecture) that addresses such issues > as > > whether LLN routing require a distributed and/or centralized path > > computation models, whether additional hierarchy is necessary and > how it > > is applied. > > > > Manageability will be considered with each approach, along with > various > > trade-offs for maintaining low power operation, including the > presence of > > non-trivial loss and networks with a very large number of nodes. > > > > - Produce a routing security framework for routing in LLNs. > > > > - Protocol work: The Working Group will consider specific routing > > requirements from the four application documents collectively, and > > specify either a new protocol or extend an existing routing > protocol > > in cooperation with the relevant Working Group. > > If requirements from the four target application areas cannot be > met > > with a single protocol, the WG may choose to specify or extend > more than > > one protocol (this will require a recharter of the WG). > > > > - Documentation of applicability statement of ROLL routing > protocols. > > > > - A document detailing when to use RFC6553, RFC6554 and IPIP > > encapsulation. > > > > - A document detailing how to compress RFC6553, RFC6554 and IP > headers > > in the 6lowPAN HC context. > > > > > > > > $Id: charter.txt,v 1.3 2015/03/23 18:33:38 mcr Exp $ > > > > > > > > -- > > Michael Richardson , Sandelman Software Works > > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --001a1134cb8a9a78400512962719 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Pascal,

Thank you very much for your= comments, we are going to include them in our meeting.=C2=A0
To all, There are additional topics that you would like to incl= ude in the charter? Please justify.

Thank you very= much,

Michael and Ines

2015-03-31 13:49 GMT+03:00 Pascal Thub= ert (pthubert) <pthubert@cisco.com>:
Hello Michael (and all):

I fully support the additions. Since you are at it, I would like to explore= a deeper realignment.

ROLL is now in charge of the maintenance of RPL, isn't it?
- I think that this should be a work item in the charter.
- this should replace elements that were or are being delivered such as met= rics, security, and RPL itself

And if that's so, wouldn't it make sense to study how RPL works out= side LLNs and in mixed environments?
- I'd like to see work on RPL over foo where foo is Ethernet or Wi-Fi. = Applicability of RPL in various environments outside LLN would be of intere= st, e.g. to build a Wi-Fi mesh or an unmanaged network. It seems that a DT = will form at HOMENET to select a routing protocol, and an applicability sta= tement of RPL for that case would be a good read if we can produce it in ti= me.
- From our experience of actually doing RPL over Ethernet, it is mostly a m= atter of *not* using the packet artifacts, probably not using the stretch i= n local repair, and reacting immediately to changes in link state. This is = a very small spec indeed, mostly guidance on what to use and what not to us= e from RFC 6550, how to tune some parameters, which OF to use and how.
- The work should also detail the mode where there is a backbone and a virt= ual root. I think that the current charter does not cover work outside LLN = but considering that we are the group that knows RPL best, that work should= happen here.

What do you think?

Pascal


> -----Original Message-----
> From: Roll [mailto:roll-bounc= es@ietf.org] On Behalf Of Michael Richardson
> Sent: lundi 23 mars 2015 19:41
> To: roll@ietf.org
> Subject: [Roll] proposed amendments to ROLL charter
>
>
> The following changes are proposed for the ROL= L charter to include the work to
> profile 6553/6554/IPIP, and to compress it.
>
> To the pre-amble:
>
> After:
>=C2=A0 - In most cases, LLNs will be employed over link layers with res= tricted
>=C2=A0 =C2=A0 frame-sizes, thus a routing protocol for LLNs should be s= pecifically
>=C2=A0 =C2=A0 adapted for such link layers.
>
> Add:
> +- LLN routing protocols have to be very careful when trading off
> +efficiency
> +=C2=A0 for generality; many LLN nodes do not have re= sources to waste.
>
> After:
>=C2=A0 The solution must include unicast and multicast considerations.<= br> >
> Add:
> +The Working Group will document how non-control packets are routed wh= en
> +they cross the LLN, and when they enter and exit the LLN: the<= br> > +appropriate use of
> +RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation = including how
> +routing loops are detected. In consultation with the 6lo WG, t= he
> +Working Group will design a method to these routing headers into a > +single block.=C2=A0 The result will have a shared WGLC with 6lo.
>
> To=C2=A0 Work Items, add:
> +=C2=A0 =C2=A0 =C2=A0- A document detailing when to use RFC6553, RFC65= 54 and IPIP
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0encapsulation.
> +
> +=C2=A0 =C2=A0 =C2=A0- A document detailing how to compress RFC6553, R= FC6554 and IP headers
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0in the 6lowPAN HC context.
>
>
> The resulting charter (after reformatting of some of the ugly text wra= pping on
> the web site) is:
>
> ----
> Low power and Lossy networks (LLNs) are made up of many embedded devic= es
> with limited power, memory, and processing resources. They are interco= nnected
> by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiF= i, wired or
> other low power PLC (Powerline Communication) links. LLNs are transiti= oning to
> an end-to-end IP-based solution to avoid the problem of non-interopera= ble
> networks interconnected by protocol translation gateways and proxies.<= br> >
> Generally speaking, LLNs have at least five distinguishing
> characteristics:
> - LLNs operate with a hard, very small bound on state.
> - In most cases, LLN optimize for saving energy.
> - Typical traffic patterns are not simply unicast flows (e.g. in some = cases most if
> not all traffic can be point to multipoint).
> - In most cases, LLNs will be employed over link layers with restricte= d
>=C2=A0 =C2=A0frame-sizes, thus a routing protocol for LLNs should be sp= ecifically
>=C2=A0 =C2=A0adapted for such link layers.
> - LLN routing protocols have to be very careful when trading off effic= iency
>=C2=A0 =C2=A0for generality; many LLN nodes do not have resources to wa= ste.
>
> These specific properties cause LLNs to have specific routing requirem= ents.
>
> Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have be= en
> evaluated by the working group and have in their current form been fou= nd to
> not satisfy all of these specific routing requirements.
>
> The Working Group is focused on routing issues for LLN.
>
> There is a wide scope of application areas for LLNs, including industr= ial
> monitoring, building automation (HVAC, lighting, access control, fire)= ,
> connected homes, healthcare, environmental monitoring, urban sensor > networks (e.g. Smart Grid), asset tracking. The Working Group focuses = on
> routing solutions for a subset of these: industrial, connected home, b= uilding and
> urban sensor networks for which routing requirements have been specifi= ed.
> These application-specific routing requirement documents will be used = for
> protocol design.
>
> The Working Group focuses only on IPv6 routing architectural framework= for
> these application scenarios. The Framework will take into consideratio= n various
> aspects including high reliability in the presence of time varying los= s
> characteristics and connectivity while permitting low-power operation = with very
> modest memory and CPU pressure in networks potentially comprising a ve= ry
> large number (several thousands) of nodes.
>
> The Working Group will pay particular attention to routing security an= d
> manageability (e.g., self routing configuration) issues. It will also = need to
> consider the transport characteristic the routing protocol messages wi= ll
> experience. Mechanisms that protect an LLN from congestion collapse or= that
> establish some degree of fairness between concurrent communication ses= sions
> are out of scope of the Working Group. It is expected that upper-layer=
> applications utilizing LLNs define appropriate mechanisms.
>
> The solution must include unicast and multicast considerations.
>
> The Working Group will document how non-control packets are routed whe= n
> they cross the LLN, and when they enter and exit the LLN: the appropri= ate use of
> RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how rout= ing
> loops are detected. In consultation with the 6lo WG, the Working Group= will
> design a method to these routing headers into a single block.=C2=A0 Th= e result will
> have a shared WGLC with 6lo.
>
> Work Items:
>
>=C2=A0 =C2=A0 =C2=A0 - Specification of routing metrics used in path ca= lculation. This
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 includes static and dynamic link/node attri= butes required for routing in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 LLNs.
>
>=C2=A0 =C2=A0 =C2=A0 - Provide an architectural framework for routing a= nd path selection at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Layer 3 (Routing for LLN Architecture) that= addresses such issues as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 whether LLN routing require a distributed a= nd/or centralized path
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 computation models, whether additional hier= archy is necessary and how it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 is applied.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Manageability will be considered with each = approach, along with various
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 trade-offs for maintaining low power operat= ion, including the presence of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 non-trivial loss and networks with a very l= arge number of nodes.
>
>=C2=A0 =C2=A0 =C2=A0 - Produce a routing security framework for routing= in LLNs.
>
>=C2=A0 =C2=A0 =C2=A0 - Protocol work: The Working Group will consider s= pecific routing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 requirements from the four application docu= ments collectively, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 specify either a new protocol or extend an = existing routing protocol
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 in cooperation with the relevant Working Gr= oup.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 If requirements from the four target applic= ation areas cannot be met
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 with a single protocol, the WG may choose t= o specify or extend more than
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 one protocol (this will require a recharter= of the WG).
>
>=C2=A0 =C2=A0 =C2=A0 - Documentation of applicability statement of ROLL= routing protocols.
>
>=C2=A0 =C2=A0 =C2=A0 - A document detailing when to use RFC6553, RFC655= 4 and IPIP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 encapsulation.
>
>=C2=A0 =C2=A0 =C2=A0 - A document detailing how to compress RFC6553, RF= C6554 and IP headers
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 in the 6lowPAN HC context.
>
>
>
> $Id: charter.txt,v 1.3 2015/03/23 18:33:38 mcr Exp $
>
>
>
> --
> Michael Richardson <mcr+= IETF@sandelman.ca>, Sandelman Software Works
> IETF ROLL WG co-chair.=C2=A0 =C2=A0 http://datatracker.ietf.org/wg/rol= l/charter/

_______________________= ________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

--001a1134cb8a9a78400512962719-- From nobody Tue Mar 31 11:27:55 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 CF3F01A904E for ; Tue, 31 Mar 2015 11:27:49 -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 flWYJzcAXSsB for ; Tue, 31 Mar 2015 11:27:48 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22D991A8BAF for ; Tue, 31 Mar 2015 11:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=587; q=dns/txt; s=iport; t=1427826468; x=1429036068; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=TNFq+C5HjmChnPRNFeEPtb7Qsl2jnI4++EVjCEfiJaA=; b=Y0HqArd4QXCDuLGTRws9OjPywXBeR4ROXDl1fzDoK97ML8jpLqAcZP0z irJYOVGSWSyM4cDzuWCtshDsQHwT5KRsOrwyAkYwZq2h0jn6R5MQNjAe6 28ro4Wmfzx1xtKXJMnCBp01B4qhgLh5rIcvGJ4wO6xoBrD/u+Lb+nljdj A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BiBQDY5hpV/4wNJK1cgwaBLgXLcAKBREwBAQEBAQF9hBUBAQSBCQIBCEYyJQIEARKIL84PAQEBAQEBAQMBAQEBAR2LKYRFOoQtAQSKbYNmgg+JdYEdhg2NESKDbm+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,502,1422921600"; d="scan'208";a="137012275" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-1.cisco.com with ESMTP; 31 Mar 2015 18:27:36 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t2VIRaJk021129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Mar 2015 18:27:36 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.109]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Tue, 31 Mar 2015 13:27:36 -0500 From: "Alvaro Retana (aretana)" To: Routing Over Low power and Lossy networks , "Michael Richardson" Thread-Topic: [Roll] proposed amendments to ROLL charter Thread-Index: AQHQZZj1lbhrFG1lckmeAq7xt0JO+Z02yXaAgAA8vYA= Date: Tue, 31 Mar 2015 18:27:35 +0000 Message-ID: References: <30526.1427136071@sandelman.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.222.102] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] proposed amendments to ROLL charter 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, 31 Mar 2015 18:27:50 -0000 On 3/31/15, 6:49 AM, "Pascal Thubert (pthubert)" wrote: Pascal: Hi! >It seems that a DT will form at HOMENET to select a routing protocol, and >an applicability statement of RPL for that case would be a good read if >we can produce it in time. Just a quick comment.. The deliverable for the homenet DT is =B3by July 2015=B2, which I=B9m interpreting as =B3we want to discuss in Prague=B2. T= he document that you=B9re proposing for the DT doesn=B9t need to be a WG item = or even chartered for you (individually) to make it happen. Alvaro.