Re: [6lo] FW: [802.15-ALL] Sad news about Dr. Robert F. Heile

[Samita Chakrabarti]

This is a very sad news. Bob Heile used to attend 6lo wg meetings
regularly. It was always a pleasure talking with him.
May his soul rest in peace.
-Samita

On Sat, Sep 26, 2020, 4:10 AM Pascal Thubert (pthubert)  wrote:

> Dear all, I thought you wanted to know. Bob was the chair of IEEE 802.15
> for a great many years.
>
>
>
> *From:* pat.kin...@kinneyconsultingllc.com <
> pat.kin...@kinneyconsultingllc.com>
> *Sent:* vendredi 25 septembre 2020 18:13
> *To:* stds-802-w...@listserv.ieee.org
> *Subject:* [802.15-ALL] Sad news about Dr. Robert F. Heile
>
>
>
> It is with my greatest regrets and deepest sorrow that I must inform you
> of the passing of Dr Robert F Heile’s last night.  As you know Bob’s
> condition was deteriorating rapidly.  He was at home, in no pain, and with
> his wife, Bonnie, and two daughters, Sarah and Beth, when he peacefully
> passed away.
>
>
>
> At this time, I have not heard of the arrangements nor services, I will
> send out additional information as I find out.
>
>
>
> Sincerely,  Pat
>
> Pat Kinney
> *Kinney Consulting LLC*
> IEEE 802.15 WG chair, IEEE 802.15 SCm chair, IEEE 802.15.12 chair
> ISA100 co-chair, ISA100.20 chair
> M: +1.847.997.3775
> O: +1.847.960.3715
> pat.kin...@kinneyconsultingllc.com
> --
>
> To unsubscribe from the STDS-802-WPAN list, click the following link:
> https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-WPAN&A=1
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] 6lo use cases: draft-hong-6lo-use-cases-01

[Samita Chakrabarti]

Hi Carles,

You have made some good points on 6lo and LPWAN.

However, as of today, the focus of this use-case document on the usecases that 
are running IPv6/6lowpan stack today or potentially can run on to others. For 
example, 6lowpan stack with modifications can run on 802.11  networks in the 
future or in LPWAN. Now with ethertype IDs  etc. the potential is higher.

The idea of the usecase document is to give examples of existing 6lo 
implementations/drafts/RFC and deployments.  And at the same time provide a few 
examples on other technologies (ex. LPWAN or some other ) which might be 
applicable for running the basics of the stack or at least evaluate running 6lo 
stack.

The scope of 6lo is about running IPv6 on constrained node devices -- started 
with WPAN,  but could be applicable to WLAN or WAN. Thus it is fine to work on 
the usecases here and then apply to specific SDOs. [ This is my personal view]


Thanks,
-Samita


-Original Message-
From: 6lo [mailto:6lo-boun...@ietf.org] On Behalf Of Carles Gomez Montenegro
Sent: Tuesday, April 12, 2016 2:17 AM
To: Yong-Geun Hong
Cc: josep.parade...@entel.upc.edu; 6lo@ietf.org; jon.crowcr...@cl.cam.ac.uk; 
"Sandra Céspedes U."
Subject: Re: [6lo] 6lo use cases: draft-hong-6lo-use-cases-01

Hi Yong-Geun, Sandra,

Please see some inline comments, below.

> Dear Sandra.
>
> Thanks for your comments.
>
> I agree your comments. At the LP-WAN BoF, I was also there.
>
> In the 6lo use cases document, we tried to describe the use cases that 
> are related to IPv6 over Networks of Resource-constrained Nodes. I am 
> not sure how the current LP-WAN technologies are related to IPv6 and 
> 6lo technologies.

An analysis of IPv6 over LPWAN can be found here:
https://tools.ietf.org/html/draft-gomez-lpwan-ipv6-analysis-00
(This draft will be updated before Berlin...)

There is also a section on the topic here:
https://tools.ietf.org/html/draft-minaburo-lp-wan-gap-analysis-01

Sandra's comment touches an important point, that is: which is (or should
be) the scope of the "6lo use cases" draft?

The "6lo use cases" document may include a wider set of technologies than the 
current "6lo" ones. Then it would transform into a "6lo" and "lpwan"
use cases document. I wonder if this document (currently homed in the 6lo
WG) would then potentially focus on work carried out in more than one WG. 
 I personally would have no problem with that, but coordination between the 
involved WGs would be needed, and it would be good to know the chairs'
opinion on this. (Note that an IETF WG focusing on LPWAN does not yet exist, 
but efforts to create such a WG have already started.)

On the other hand, for the most challenged LPWAN setups/technologies, 
functionality beyond what is currently used in 6lo is actually needed to 
support IPv6 over LPWAN [draft-gomez-lpwan-ipv6-analysis]. In fact, many LPWANs 
fall in the challenged networks category [draft-minaburo-lp-wan-gap-analysis]. 
As of today, the mechanisms for supporting IPv6 over LPWANs are in their early 
stages in the best case...
So today it is already possible to include some example LPWAN technologies and 
use cases in the document, but we'll have to wait a little bit to see how IPv6 
is supported over them.

What does the WG think?

Thanks!

Carles


> In the next revision, we will look at the LP-WAN technologies more 
> detail and try to include the LP-WAN technologies.
>
> If you have related contents, it is appreciate to help.
>
> Best regards.
>
> Yong-Geun.
>
>
> On Tue, Apr 12, 2016 at 6:31 AM, Sandra Céspedes U.
> > wrote:
>
>> Dear Yong-Geun
>>
>> I have a comment regarding this draft:
>>
>> It seems to me that all the use cases presented in the document are 
>> for "short-range" technologies, that would easily follow in the PAN 
>> category.
>> Although most of the current work done in 6lo concentrates in such 
>> technologies, there is no limitation in the scope that indicates that 
>> low-power wide area technologies cannot be considered. I'm referring 
>> to technologies that were discussed during the LP-WAN BOF (they even 
>> have a shared file with an initial list of technologies in 
>> goo.gl/S3uSPU 
>> ).
>>
>>
>> Why aren't we looking into those technologies as 6lo use-cases? I 
>> suggest that if not all the technologies, some examples should relate 
>> to LP-WAN technologies, since they are also restricted networks (some 
>> argue that even more constrained than Low-PAN technologies) and also 
>> need IPv6-over-foo definitions.
>>
>> Looking forward to your opinion.
>>
>> Regards,
>> Sandra Céspedes
>>
>>
>> On 07-04-2016 22:14, Yong-Geun Hong wrote:
>>
>> Dear Michael.
>>
>> Thanks for your valuable comments.
>>
>> I totally agree your comments and it is aligned with other comments 
>> in the 6lo WG meeting today.
>>
>> I will keep in mind your comments and try to revise the document as 
>> you

Re: [6lo] Adoption call for draft-droms-6lo-ethertype-request-01

[Samita Chakrabarti]

The  adoption call  ended on April 15th and  there have been many positive 
responses on adopting the following document.

Draft-droms-6lo-ethertype-request is now a 6lo Wg document.  Ralph and 
co-authors, please move forward with submitting the doc as a WG document and 
let us know when it is ready for Working group LC.  Since this is a short draft 
- we should be able to go for LC quickly.


-Samita

Le 8 avr. 2016 à 11:15, Samita Chakrabarti 
mailto:samita.chakraba...@ericsson.com>> a 
écrit :

At the IETF95 meeting yesterday  this document has been presented and 
previously there has been discussions on the topic and as a result version 01 
has been published. The document RFC is required for  IETF to request a "ether 
type" code-point for LOWPAN IPv6-over-foo technologies.

Use cases:
* IEEE 802.15.9 Multiplexed Data Service
* WiFi Alliance HaLoW
* Other layer 2 technologies such as Ethernet and debugging tools


In the f2f  6lo meeting@IETF95, the response was in favor of adopting this 
document.

This adoption call over the mailing list ends at April 15, Friday pacific time.

https://tools.ietf.org/html/draft-droms-6lo-ethertype-request-01


Best regards,
Gabriel and Samita
___
6lo mailing list
6lo@ietf.org<mailto:6lo@ietf.org>
https://www.ietf.org/mailman/listinfo/6lo
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] WGLC for draft-ietf-6lo-ethertype-request-00.txt

[Samita Chakrabarti]

Hello All:


The WG Last Call for the following document starts today.

Please provide your input on improving the document and comments on proceeding 
towards the next step.

The LC will end on May 4, 2016.



Thank you.

-Samita & Gabriel













>Title   : Assignment of an Ethertype for IPv6 with LoWPAN 
> Encapsulation
>Authors : Ralph Droms
>  Paul Duffy
> Filename: draft-ietf-6lo-ethertype-request-00.txt
> Pages   : 4
> Date: 2016-04-18
>
> Abstract:
>   When carried over layer 2 technologies such as Ethernet, IPv6
>   datagrams using LoWPAN encapsulation as defined in RFC 4944 must be
>   identified so the receiver can correctly interpret the encoded IPv6
>   datagram.  This document requests the assignment of an Ethertype for
>   that purpose.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6lo-ethertype-request/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-6lo-ethertype-request-00


___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] WGLC for draft-ietf-6lo-ethertype-request-00.txt

[Samita Chakrabarti]

Comments :


'Introduction' section of this draft  indicates a few bullet points on how it 
might be useful in 802.15.9 and  wifi/Ethernet technologies , but it is not 
clear to me that if this type is now mandatory for other non-802.15.4  L2 
technologies as well.

Can you please add a section on the document on usage with other L2 
technologies? Or is this draft only limited to Wifi/Ethernet technologies?

If it applies to other foo L2 technologies, then an explanation is requested  
as to when to consider adding this "type" in the solution and whether any 
existing RFCs( bt-le, lowpanz etc.) require any modification.

Best regards,
-Samita


From: Samita Chakrabarti
Sent: Wednesday, April 20, 2016 10:07 AM
To: 6lo@ietf.org
Cc: 6lo-cha...@tools.ietf.org
Subject: WGLC for draft-ietf-6lo-ethertype-request-00.txt

Hello All:


The WG Last Call for the following document starts today.

Please provide your input on improving the document and comments on proceeding 
towards the next step.

The LC will end on May 4, 2016.



Thank you.

-Samita & Gabriel













>Title   : Assignment of an Ethertype for IPv6 with LoWPAN 
> Encapsulation
>Authors : Ralph Droms
>  Paul Duffy
> Filename: draft-ietf-6lo-ethertype-request-00.txt
> Pages   : 4
> Date: 2016-04-18
>
> Abstract:
>   When carried over layer 2 technologies such as Ethernet, IPv6
>   datagrams using LoWPAN encapsulation as defined in RFC 4944 must be
>   identified so the receiver can correctly interpret the encoded IPv6
>   datagram.  This document requests the assignment of an Ethertype for
>   that purpose.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6lo-ethertype-request/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-6lo-ethertype-request-00


___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] WGLC for draft-ietf-6lo-ethertype-request-00.txt

[Samita Chakrabarti]

Hi Paul,

I understand the quoted part of the intro section below.

I have discussed with Ralph to update with  a little more 
information/clarification in favor of other 6lo technologies and documents.

Thanks,
-Samita

From: Paul Duffy [mailto:padu...@cisco.com]
Sent: Wednesday, April 20, 2016 1:17 PM
To: Samita Chakrabarti; Ralph Droms (rdroms) (rdr...@cisco.com)
Cc: 6lo@ietf.org
Subject: Re: WGLC for draft-ietf-6lo-ethertype-request-00.txt

Hi Samita

...

On 4/20/2016 1:25 PM, Samita Chakrabarti wrote:
Comments :


'Introduction' section of this draft  indicates a few bullet points on how it 
might be useful in 802.15.9 and  wifi/Ethernet technologies , but it is not 
clear to me that if this type is now mandatory for other non-802.15.4  L2 
technologies as well.

Can you please add a section on the document on usage with other L2 
technologies? Or is this draft only limited to Wifi/Ethernet technologies?

>From the intro ...

   o  Usage of LoWPAN encapsulation in conjunction with IEEE 802.15.9

  Multiplexed Data Service 
[IEEE802159<https://tools.ietf.org/html/draft-ietf-6lo-ethertype-request-00#ref-IEEE802159>],
 which provides the ability

  to perform upper layer protocol dispatch for IEEE 802.15.4

  networks.  Wi-SUN Alliance intends to use the 15.9 Multiplexed

  Data Information Element to dispatch LoWPAN encapsulation frames

  to upper stack layers.  As specified in IEEE 802.15.9, dispatch of

  LoWPAN encapsulation frames will require an Ethertype be assigned

  for LoWPAN encapsulation.




If it applies to other foo L2 technologies, then an explanation is requested  
as to when to consider adding this "type" in the solution and whether any 
existing RFCs( bt-le, lowpanz etc.) require any modification.

Best regards,
-Samita


From: Samita Chakrabarti
Sent: Wednesday, April 20, 2016 10:07 AM
To: 6lo@ietf.org<mailto:6lo@ietf.org>
Cc: 6lo-cha...@tools.ietf.org<mailto:6lo-cha...@tools.ietf.org>
Subject: WGLC for draft-ietf-6lo-ethertype-request-00.txt

Hello All:


The WG Last Call for the following document starts today.

Please provide your input on improving the document and comments on proceeding 
towards the next step.

The LC will end on May 4, 2016.



Thank you.

-Samita & Gabriel













>Title   : Assignment of an Ethertype for IPv6 with LoWPAN 
> Encapsulation
>Authors : Ralph Droms
>  Paul Duffy
> Filename: draft-ietf-6lo-ethertype-request-00.txt
> Pages   : 4
> Date: 2016-04-18
>
> Abstract:
>   When carried over layer 2 technologies such as Ethernet, IPv6
>   datagrams using LoWPAN encapsulation as defined in RFC 4944 must be
>   identified so the receiver can correctly interpret the encoded IPv6
>   datagram.  This document requests the assignment of an Ethertype for
>   that purpose.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6lo-ethertype-request/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-6lo-ethertype-request-00



___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] FW: s/w update for small devices.... [OT]

[Samita Chakrabarti]

Please note that  there will be a workshop on software update for which the 
position paper due date is May 20th.

Perhaps this is of interest to folks in 6lo as well.

-Samita

-Original Message-
From: Roll [mailto:roll-boun...@ietf.org] On Behalf Of Alvaro Retana (aretana)
Sent: Thursday, April 14, 2016 1:45 PM
To: r...@ietf.org
Subject: [Roll] FW: s/w update for small devices [OT]

FYI...

Might be of interest to some of you.

Alvaro.


https://down.dsg.cs.tcd.ie/iotsu/

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

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] 6lo IETF95 minutes posted

[Samita Chakrabarti]

Hello:

Please check the minutes at  
https://www.ietf.org/proceedings/95/minutes/minutes-95-6lo

Please let us know if change/addition is needed.
Thanks to our minute takers Dominique Barthel and Rashid Sangi. Thanks to Alex 
Pelov for the jabber scribe.


Cheers,
Gabriel and Samita

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] WGLC for draft-ietf-6lo-ethertype-request-00.txt

[Samita Chakrabarti]

Hello:

The LCWG period has ended for draft-ietf-6lo-ethertype-request-00.txt without 
any  objections.

A revised I-D is expected  for a  clarification point as discussed during WGLC. 
After that, I believe the document will be ready for IESG submission.

Thanks,
-Samita



From: Samita Chakrabarti
Sent: Wednesday, April 20, 2016 10:07 AM
To: 6lo@ietf.org
Cc: 6lo-cha...@tools.ietf.org
Subject: WGLC for draft-ietf-6lo-ethertype-request-00.txt

Hello All:


The WG Last Call for the following document starts today.

Please provide your input on improving the document and comments on proceeding 
towards the next step.

The LC will end on May 4, 2016.



Thank you.

-Samita & Gabriel













>Title   : Assignment of an Ethertype for IPv6 with LoWPAN 
> Encapsulation
>Authors : Ralph Droms
>  Paul Duffy
> Filename: draft-ietf-6lo-ethertype-request-00.txt
> Pages   : 4
> Date: 2016-04-18
>
> Abstract:
>   When carried over layer 2 technologies such as Ethernet, IPv6
>   datagrams using LoWPAN encapsulation as defined in RFC 4944 must be
>   identified so the receiver can correctly interpret the encoded IPv6
>   datagram.  This document requests the assignment of an Ethertype for
>   that purpose.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6lo-ethertype-request/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-6lo-ethertype-request-00


___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] Call for 6lo Deployment Scenario Document phone meeting

[Samita Chakrabarti]

Hello All:

At Buenos Aires, we had a very productive discussion on updating 
https://datatracker.ietf.org/doc/draft-hong-6lo-use-cases/
In order to use it more for guidance to other IETF WGs and external SDO as to 
how 6lo WG technologies might be useful to yet another L2 networks that are 
serving constrained devices.
The document already discusses different parameters for different technologies  
and typical deployment.

The goal is to improve the document  and present it as an 6lo Applicability 
document for others to know how to use this technology.

Yong-Geun is heading this effort and  he might need some extra hands to help 
him out.

I plan to arrange a phone meeting next week (Wed/Thurs) @7am PDT to discuss:


* Outline proposal of the updated document

* Nail down the usecase scenarios



Thanks,

-Samita





PS: Please update the Doodle poll for your preference on attendance.

http://doodle.com/poll/y9akcyphnrtvwusa



___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Call for 6lo Deployment Scenario Document phone meeting

[Samita Chakrabarti]

PS: Please update the Doodle poll for your preference on attendance. [ for next 
week]

http://doodle.com/poll/y9akcyphnrtvwusa





Please reply only to '6lo@ietf.org'.  [ Else the mail administrator complains 
about too many recipients]



Thanks,

-Samita

From: Samita Chakrabarti
Sent: Friday, May 13, 2016 5:28 PM
To: Yong-Geun Hong (yonggeun.h...@gmail.com); pthub...@cisco.com; Thomas 
Watteyne (thomas.watte...@inria.fr); ker...@ieee.org; Carsten Bormann 
(c...@tzi.org); Mohit Sethi M; dominique.bart...@orange.com; 'Das, Subir'; 
'carle...@entel.upc.edu'; 'teemu.savolai...@nokia.com'; Alexander Pelov 
(alexan...@ackl.io); Gabriel Montenegro (gabriel.montene...@microsoft.com)
Cc: 6lo@ietf.org
Subject: Call for 6lo Deployment Scenario Document phone meeting

Hello All:

At Buenos Aires, we had a very productive discussion on updating 
https://datatracker.ietf.org/doc/draft-hong-6lo-use-cases/
In order to use it more for guidance to other IETF WGs and external SDO as to 
how 6lo WG technologies might be useful to yet another L2 networks that are 
serving constrained devices.
The document already discusses different parameters for different technologies  
and typical deployment.

The goal is to improve the document  and present it as an 6lo Applicability 
document for others to know how to use this technology.

Yong-Geun is heading this effort and  he might need some extra hands to help 
him out.

I plan to arrange a phone meeting next week (Wed/Thurs) @7am PDT to discuss:


* Outline proposal of the updated document

* Nail down the usecase scenarios



Thanks,

-Samita





PS: Please update the Doodle poll for your preference on attendance.

http://doodle.com/poll/y9akcyphnrtvwusa



___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Call for 6lo Deployment Scenario Document phone meeting

[Samita Chakrabarti]

Hello All:

The Doodle poll has logged  more participants on Wed than Thurs as of now.
Due to the short notice, we have only a handful participants. We will take a 
note and distribute to the list for further discussions.

So, let's have the meeting on Wed at 7am PDT.

I have sent the conf-call information to the participants. If any of you who 
did not sign up yet but still like to join the call, please contact me directly.

Thanks for participating in the poll.

-Samita

From: Samita Chakrabarti
Sent: Friday, May 13, 2016 5:28 PM
To: Yong-Geun Hong (yonggeun.h...@gmail.com); pthub...@cisco.com; Thomas 
Watteyne (thomas.watte...@inria.fr); ker...@ieee.org; Carsten Bormann 
(c...@tzi.org); Mohit Sethi M; dominique.bart...@orange.com; 'Das, Subir'; 
'carle...@entel.upc.edu'; 'teemu.savolai...@nokia.com'; Alexander Pelov 
(alexan...@ackl.io); Gabriel Montenegro (gabriel.montene...@microsoft.com)
Cc: 6lo@ietf.org
Subject: Call for 6lo Deployment Scenario Document phone meeting

Hello All:

At Buenos Aires, we had a very productive discussion on updating 
https://datatracker.ietf.org/doc/draft-hong-6lo-use-cases/
In order to use it more for guidance to other IETF WGs and external SDO as to 
how 6lo WG technologies might be useful to yet another L2 networks that are 
serving constrained devices.
The document already discusses different parameters for different technologies  
and typical deployment.

The goal is to improve the document  and present it as an 6lo Applicability 
document for others to know how to use this technology.

Yong-Geun is heading this effort and  he might need some extra hands to help 
him out.

I plan to arrange a phone meeting next week (Wed/Thurs) @7am PDT to discuss:


* Outline proposal of the updated document

* Nail down the usecase scenarios



Thanks,

-Samita





PS: Please update the Doodle poll for your preference on attendance.

http://doodle.com/poll/y9akcyphnrtvwusa



___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] Request for Agenda items for IETF96 at Berlin

[Samita Chakrabarti]

Hello 6lo colleagues:

It is already June and  6lo-chairs have requested 2.5 hrs  for the 6lo session 
at IETF96.

Please send in your requests for 6lo session before June 20th with the 
following information:
Draftname:
Presenter:
Summary of Presentation & purpose of presentation:
Approximate time:


Note:  There has been activities around 6lo in lp-wan alias/BOF as well.  If 
the draft or presentations are directly applicable on 6lo [ example: 
ipv6-over-LoRA, etc.], it would be good to bring that information to 6lo WG 
attention as well.


As you know, WG documents and the documents driven by SDO will get higher 
priorities than individual submissions that were not discussed in the WG before.
Thanks,
-Samita
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] FW: 6lo Applicability Document Discussion

[Samita Chakrabarti]

FYI: Summary of 6lo Applicability document discussion. [ Please see below 
forwarded message]



Thanks to Yong-Geun all the WG attendees who were present in the meeting and 
contributed to the very productive discussion.

There was a rough consensus among the attendees at May 19th meeting on the new 
name of the document aligning with its purpose:

“IPv6 over Constrained Node Networks(6lo)  Applicability & Use cases”

A new revision of the draft will be expected before IETF96.

Thanks,
-Samita

From: Samita Chakrabarti
Sent: Thursday, May 19, 2016 6:57 PM
To: 'Yong-Geun Hong'
Cc: carle...@entel.upc.edu<mailto:carle...@entel.upc.edu>; Thomas Watteyne 
(thomas.watte...@inria.fr<mailto:thomas.watte...@inria.fr>); AbdurRashidSangi 
(rashid.sa...@huawei.com<mailto:rashid.sa...@huawei.com>); Xavier Vilajosana; 
최영환; Daniel Migault
Subject: RE: 6lo Applicability Document Discussion

Thank you Younhwan for taking the notes.



As for the summary to WG we can do the following based on the meetings and 
discussion:

Attendees: Samita, Yong-Guen, Thomas, Gomez, Younghwan, rashid, Xavier, Daniel

- Yong-Guen's presented an overview, history and quick intro to the I-D, 
draft-hong-6lo-use-case.
  Young-Geun requested to get the following questions to be resolved:
   . what is the main purpose?
   . title changes to what?
   . additional sections and parts in doc.



· Need to decide on the new title of the draft reflecting  purpose and 
content – Young-Geun to discuss and decide in a group of interested 6lo 
participants

· Should we describe  deployment in this document?

o   Concern over distinguishing itself from existing 6lowpan Usecase RFC

o   Some folks see value in describing current deployment with figures (Carles, 
Samita, and previously M. Richardson)

o   Young-Geun to seek contribution on 6lo deployment high-level diagram, 
scale, Applications and L2 technolgies

o   Possible deployment examples: Smart Grid activity in WiSun?  6Tisch area?

o   However the document’s main focus is on per-L2 technology usage, adaptation 
parameters

· Clarification of the purpose of the document

o   Informational RFC

o   Targeting IETF internal WGs and members as well as external SDO 
contemplating a L3 solution for their respective L2 constrained node networks

· Should the document include LPWAN as a usecase? [ IETF95 comments 
from Sandra ]

o   6lowpan can be used definitely on LPWAN with some modification  but the 
consensus in the team is to wait until LPWAN BOF next time

o   Wait until later revision of the document

· What about Security requirement of the usecase scenarios?

o   Should this be considered for each usecase or in general ?

o   Young-Geun has taken this as an AI

==

Please check and let me know if any summary point is missing. After that I can 
post the summary in the mailing list.
Thanks,
-Samita


___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Request for Agenda items for IETF96 at Berlin

[Samita Chakrabarti]

Hello 6lo WG draft authors :

Here is a friendly reminder  about agenda item  request. If you intend to 
present your draft at Berlin 6lo session, please send your request to 
6lo-cha...@ietf.org<mailto:6lo-cha...@ietf.org>  in response to this email.

Please provide the following information along with the request.  Thanks to 
those who already sent your requests.

We have 2.5 hours slot and it is currently scheduled as the first time slot  on 
Monday, July 18th.

10:00-12:30

Monday Morning session I



Potsdam III<https://tools.ietf.org/agenda/96/venue/?room=potsdam-iii>

int

6lo<https://datatracker.ietf.org/group/6lo/charter/>

IPv6 over Networks of Resource-constrained Nodes



Also,  I noticed 6tisch WG  and lpwan BOF are also on Monday right after 6lo WG 
session.

Thanks,
-Samita

From: Samita Chakrabarti
Sent: Monday, June 06, 2016 11:56 AM
To: 6lo@ietf.org
Cc: Gabriel Montenegro (gabriel.montene...@microsoft.com); James Woodyatt 
(j...@nestlabs.com); Ralph Droms (rdroms) (rdr...@cisco.com)
Subject: Request for Agenda items for IETF96 at Berlin

Hello 6lo colleagues:

It is already June and  6lo-chairs have requested 2.5 hrs  for the 6lo session 
at IETF96.

Please send in your requests for 6lo session before June 20th with the 
following information:
Draftname:
Presenter:
Summary of Presentation & purpose of presentation:
Approximate time:


Note:  There has been activities around 6lo in lp-wan alias/BOF as well.  If 
the draft or presentations are directly applicable on 6lo [ example: 
ipv6-over-LoRA, etc.], it would be good to bring that information to 6lo WG 
attention as well.


As you know, WG documents and the documents driven by SDO will get higher 
priorities than individual submissions that were not discussed in the WG before.
Thanks,
-Samita
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] ETSI 6lo-6tisch plugtest event July 15th -17th at berlin-- Registration

[Samita Chakrabarti]

Hi  all:

Miguel asked me to send out a reminder to the list about the registration 
deadline of this event - I,e June 30th.

http://www.etsi.org/news-events/events/1077-6tisch-6lo-plugtests

The plug-test is taking place in the weekend before Berlin IETF jointly with 
6tisch plugtest event.


-Samita
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] WGLC for draft-ietf-6lo-privacy-considerations-02

[Samita Chakrabarti]

Hello 6lo WG:

https://tools.ietf.org/html/draft-ietf-6lo-privacy-considerations-02 has been 
submitted incorporating  WG comments on LL address.

The "Privacy Considerations for IPv6 over Networks of Resource-Constrained 
Nodes" document is now on WG LC.


Abstract

   This document discusses how a number of privacy threats apply to
   technologies designed for IPv6 over networks of resource-constrained
   nodes, and provides advice to protocol designers on how to address
   such threats in adaptation layer specifications for IPv6 over such
   links.

The intended status :  "INFORMATIONAL" .

Please review the document and provide comments  on the privacy guidelines  for 
6lo networks described in this document as it will have impact on all  
ipv6-over-foo documents going forward.

The WGLC for the above document ends on  15th August, 2016.
Please send your comments to the 6lo WG.

Thanks,
-Samita
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] draft-ietf-6lo-dispatch-iana-registry Shepherd comment updates

[Samita Chakrabarti]

Hello WG members and Thierry:

He have made the following changes in the 
draft-ietf-6lo-dispatch-iana-registry-04 document: 
https://tools.ietf.org/html/draft-ietf-6lo-dispatch-iana-registry-04




-  Update  of Abstract

-  New Document title to match the content - "6lowpan ESC Dispatch Code 
Points and Guidelines"

-  IANA section update  which indicates that 'specification required' 
may also require designated  IETF expert review

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-dispatch-iana-registry-04

Please provide your comments if any about these changes by  August 15th, 2016 
after which this document will be submitted to IESG.

Thanks,
-Samita
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] draft-ietf-6lo-dispatch-iana-registry Shepherd comment updates

[Samita Chakrabarti]

Correction:

We have made the following changes in the 
draft-ietf-6lo-dispatch-iana-registry-04 document:
https://tools.ietf.org/html/draft-ietf-6lo-dispatch-iana-registry-04



Thanks.
From: Samita Chakrabarti
Sent: Monday, August 08, 2016 4:23 PM
To: 6lo@ietf.org
Cc: Thierry LYS (thierry@erdf.fr) ; Suresh Krishnan 
(suresh.krish...@ericsson.com) ; Brian Haberman 
(br...@innovationslab.net) ; Gabriel Montenegro 
(gabriel.montene...@microsoft.com) ; Ralph 
Droms (rdroms) (rdr...@cisco.com) ; James Woodyatt 
(j...@nestlabs.com) 
Subject: draft-ietf-6lo-dispatch-iana-registry Shepherd comment updates

Hello WG members and Thierry:

He have made the following changes in the 
draft-ietf-6lo-dispatch-iana-registry-04 document: 
https://tools.ietf.org/html/draft-ietf-6lo-dispatch-iana-registry-04




-  Update  of Abstract

-  New Document title to match the content - "6lowpan ESC Dispatch Code 
Points and Guidelines"

-  IANA section update  which indicates that 'specification required' 
may also require designated  IETF expert review

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-dispatch-iana-registry-04

Please provide your comments if any about these changes by  August 15th, 2016 
after which this document will be submitted to IESG.

Thanks,
-Samita
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] IETF96 6lo WG Minutes posted

[Samita Chakrabarti]

https://www.ietf.org/proceedings/96/minutes/minutes-96-6lo

Thanks to Zach Shelby and Dominique Barthel very much for the detailed notes. 
Gabriel also took some notes which was used to enrich the minutes.

Please take a look and let us know if it requires any correction.

Cheers,
-Gabriel and Samita
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] New Version of draft-sarikaya-6lo-ap-nd-04.txt

[Samita Chakrabarti]

Thanks Behcet and the co-authors  for the headsup.

We will request adoption call soon.

-Samita

-Original Message-
From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com] 
Sent: Monday, August 22, 2016 12:54 PM
To: 6lo@ietf.org; Samita Chakrabarti ; Gabriel 
Montenegro (gabriel.montene...@microsoft.com) 
Cc: Mohit Sethi ; Pascal Thubert 
Subject: New Version of draft-sarikaya-6lo-ap-nd-04.txt

Folks,
We submitted Rev. 04 of AP ND draft.
To chairs: We think that this draft is now ready for an adoption call.

Regards,

Behcet

On Mon, Aug 22, 2016 at 2:00 PM,   wrote:
>
> A new version of I-D, draft-sarikaya-6lo-ap-nd-04.txt has been 
> successfully submitted by Mohit Sethi and posted to the IETF 
> repository.
>
> Name:   draft-sarikaya-6lo-ap-nd
> Revision:   04
> Title:  Address Protected Neighbor Discovery for Low-power and Lossy 
> Networks
> Document date:  2016-08-22
> Group:  Individual Submission
> Pages:  17
> URL:
> https://www.ietf.org/internet-drafts/draft-sarikaya-6lo-ap-nd-04.txt
> Status: https://datatracker.ietf.org/doc/draft-sarikaya-6lo-ap-nd/
> Htmlized:   https://tools.ietf.org/html/draft-sarikaya-6lo-ap-nd-04
> Diff:   https://www.ietf.org/rfcdiff?url2=draft-sarikaya-6lo-ap-nd-04
>
> Abstract:
>This document defines an extension to 6LoWPAN Neighbor Discovery.
>This extension is designed for low-power and lossy network
>environments and it supports multi-hop operation.  Nodes supporting
>this extension compute a Cryptographically Unique Interface ID and
>associate it with one or more of their Registered Addresses.  The
>Cryptographic ID (Crypto-ID) uniquely identifies the owner of the
>Registered Address.  It is used in place of the EUI-64 address that
>is specified in RFC 6775.  Once an address is registered with a
>Cryptographic ID, only the owner of that ID can modify the state
>information of the Registered Address in the 6LR and 6LBR.
>
>
>
>
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at 
> tools.ietf.org.
>
> The IETF Secretariat
>
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] My new email contact information

[Samita Chakrabarti]

Dear WG members:

Please use samitac.i...@gmail.com for all your IETF related correspondence.
My affiliation will change soon.

If you have any questions regarding the above, please contact me directly.

Thanks,
-Samita
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] Fwd: INT area directorate review of draft-ietf-6lo-paging-dispatch

[Samita Chakrabarti]

FYI
-- Forwarded message --
From: Donald Eastlake 
Date: Fri, Aug 26, 2016 at 10:01 PM
Subject: INT area directorate review of draft-ietf-6lo-paging-dispatch
To: int-...@ietf.org, int-...@ietf.org,
draft-ietf-6lo-paging-dispatch@ietf.org


I am an assigned INT directorate reviewer for
draft-ietf-6lo-paging-dispatch. These comments were written primarily
for the benefit of the Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat
comments from any other IETF contributors and resolve them along with
any other Last Call comments that have been received. For more details
on the INT Directorate, see http://www.ietf.org/iesg/directorate.html.

This short draft is a fairly straightforward extension to the encoding
of 6LoWPAN compression that effectively multiplies the code space for
"DispatchType Filed" bytes by a bit less than a factor of 16. Due to
the space constraints of 802.15.4 frames, 6LoWPAN encoding is into
bytes and the draft specifies a block of 16 bytes values which set the
context for the parsing of subsequent bytes until the next such
context setting. It is backwards compatible as existing encoding is in
context zero which is the default. the draft refers to these 16
contexts as Pages in the sense of pages of code values. There are also
some special provisions for Page 1.

After fixing the nits and possibly tweaking the IANA Considerations as
below, I think this document is ready for publication.

IANA Considerations: It seems odd to me to say that 15 additional
registries should be created for Pages (contexts) 1 through 15 when 14
of those will initially be empty except perhaps that the last 16
values in each registry are the Page switch values.. I would have
expanded the existing registry with a "Page" column and added a note
about Page zero being the default and applying if no other Page has
been set. But perhaps this is jus a matter of taste.

Nits:
Section 3, first line of last paragraph, "is is" -> "is".
The nits checker complains about a few missing form feeds.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] privacy enhanced L3 addresses derived from short L2 addresses

[samita Chakrabarti]

Hi Michael,

>>such work does not yet exist.  I think it would be in charter for 6lo at
this time?  It would seem to be an extension to
draft-ietf-6lo-paging-dispatch in >>some way.  I wonder if it worth delay to
do this now?

Right, there is no document on 6lo address formation  that standardizes the
following suggestion made in the privacy document.
It is though covered in the charter as part of the extension of 6lowpan
stack. 

I don't quite relate the connection with 6lo-paging-dispatch...  

Which document to delay ?

Thanks,
-Samita
-Original Message-
From: 6lo [mailto:6lo-boun...@ietf.org] On Behalf Of Michael Richardson
Sent: Tuesday, September 20, 2016 1:12 PM
To: lo <6lo@ietf.org>
Subject: [6lo] privacy enhanced L3 addresses derived from short L2 addresses


draft-ietf-6lo-privacy-considerations says:

   When Short Addresses are desired on links that are not guaranteed to
   have a short enough lifetime, the mechanism for constructing an IPv6
   interface identifier from a Short Address could be designed to
   sufficiently mitigate the problem.  For example, if all nodes on a
   given L2 network have a shared secret (such as the key needed to get
   on the layer-2 network), the 64-bit IID might be generated using a
   one-way hash that includes (at least) the shared secret together
   with the Short Address.  The use of such a hash would result in the IIDs
   being spread out among the full range of IID address space, thus
   mitigating address scans, while still allowing full stateless
   compression/elision.

such work does not yet exist.  I think it would be in charter for 6lo at
this time?  It would seem to be an extension to
draft-ietf-6lo-paging-dispatch in some way.  I wonder if it worth delay to
do this now?

--
Michael Richardson , Sandelman Software Works  -=
IPv6 IoT consulting =-




___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] Adoption call for draft-gomez-6lo-blemesh

[samita Chakrabarti]

 

Hello All:

 

We have discussed 6lo-blemesh at the IETF 96 6lo meeting and there were
interests in the WG to work on this draft.

The draft authors also have been requested to check with BTSIG and BTSIG has
been consulted.

 

We would like to proceed with the WG adoption call for this document:

https://datatracker.ietf.org/doc/draft-gomez-6lo-blemesh/

 

 

Please provide your opinion on the mailing list with  'Yes/No' and a short
note.

 

The adoption call ends on October 7, 2016.

 

Thanks,

Gabriel & Samita 

6lo-chairs

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] Adoption call for 6lo Applicability and Usecases

[samita Chakrabarti]

Hello Folks:

 

We have discussed this document several times and Young-Geun Hong had
presented this document several times at IETF and the WG also met separately
to discuss the use cases and format of the document. We concluded that the
purpose of this document is to show others how 6lo stacks can be used in
different applications and on L2 constrained networks. The information can
be used by external organizations as a guideline of examples for
understanding whether their networks can be suitable to run 6lo stacks. Many
have been co-authored/contributed to this document already.

 

The latest version of the document is available here:

https://datatracker.ietf.org/doc/draft-hong-6lo-use-cases/

 

 

 

Please provide your opinion on the mailing list.

 

The adoption call ends on October 7, 2016.

 

Thanks,

Gabriel and Samita

6lo-co chairs

 

 

 

 

 

 

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Adoption call for draft-gomez-6lo-blemesh

[samita Chakrabarti]

Hi Pascal,

 

Once we adopt the document and discuss changes in the document by WG, the
relevant contributions should be added as a natural process.

If you have any particular ideas or anyone you think would be relevant to
comment on, please let us know. I am not clear on "many areas" you referred
below.  Did you mean that the draft should collect input from detnet WG or
any other group?

Ultimately, we would like BT vendors to adopt the  IETF protocol and for
that  it'd be wise to work closely with BTSIG as you would agree.

 

Thanks,

-Samita

 

From: Pascal Thubert (pthubert) [mailto:pthub...@cisco.com] 
Sent: Wednesday, September 21, 2016 11:09 AM
To: samita Chakrabarti ; 'lo' <6lo@ietf.org>
Subject: RE: [6lo] Adoption call for draft-gomez-6lo-blemesh

 

Hello Samita:

 

This is a good start and the similar effort at detnet is a success. But it
will take multiple (many) contributors from many areas to make it real good.
Do we have them?

 

Cheers,

 

Pascal

 

From: 6lo [mailto:6lo-boun...@ietf.org] On Behalf Of samita Chakrabarti
Sent: mercredi 21 septembre 2016 19:48
To: 'lo' <6lo@ietf.org <mailto:6lo@ietf.org> >
Subject: [6lo] Adoption call for draft-gomez-6lo-blemesh

 

 

Hello All:

 

We have discussed 6lo-blemesh at the IETF 96 6lo meeting and there were
interests in the WG to work on this draft.

The draft authors also have been requested to check with BTSIG and BTSIG has
been consulted.

 

We would like to proceed with the WG adoption call for this document:

https://datatracker.ietf.org/doc/draft-gomez-6lo-blemesh/

 

 

Please provide your opinion on the mailing list with  'Yes/No' and a short
note.

 

The adoption call ends on October 7, 2016.

 

Thanks,

Gabriel & Samita 

6lo-chairs

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] WG adoption call for draft-sarikaya-6lo-ap-nd-04

[samita Chakrabarti]

 

 

Hello 6lo WG:

 

We have discussed the following document at the IETF meetings and mailing
list about the use of cryptographic ID to identify one device with a
particular IPv6 address during the Neighbor Discovery Process. The crypto-ID
association is helpful when MAC-ID or EUI-64 ID may not be used.

There has been fair amount of interest in securing the IP-address owner
authentication using this method, in the WG meetings(IETF95).

 

The co-authors have addressed several WG comments in the 04 version.

 

The adoption call  starts now and ends on Oct 10th, 2016.

 

Please provide your opinion with  yes/no  answer and a short explanation for
this adoption call within the deadline.

 

Thanks and Regards,

-Gabriel and Samita (6lo co-chairs)

 

> 

> 

> Name:   draft-sarikaya-6lo-ap-nd

> Revision:   04

> Title:  Address Protected Neighbor Discovery for Low-power and
Lossy Networks

> Document date:  2016-08-22

> Group:  Individual Submission

> Pages:  17

> URL:
https://www.ietf.org/internet-drafts/draft-sarikaya-6lo-ap-nd-04.txt

> Status: https://datatracker.ietf.org/doc/draft-sarikaya-6lo-ap-nd/

> Htmlized:   https://tools.ietf.org/html/draft-sarikaya-6lo-ap-nd-04

> Diff:
https://www.ietf.org/rfcdiff?url2=draft-sarikaya-6lo-ap-nd-04

> 

> Abstract:

>This document defines an extension to 6LoWPAN Neighbor Discovery.

>This extension is designed for low-power and lossy network

>environments and it supports multi-hop operation.  Nodes supporting

>this extension compute a Cryptographically Unique Interface ID and

>associate it with one or more of their Registered Addresses.  The

>Cryptographic ID (Crypto-ID) uniquely identifies the owner of the

>Registered Address.  It is used in place of the EUI-64 address that

>is specified in RFC 6775.  Once an address is registered with a

>Cryptographic ID, only the owner of that ID can modify the state

>information of the Registered Address in the 6LR and 6LBR.

 

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] Requesting agenda items for IETF97 6lo WG session

[samita Chakrabarti]

Hello All:

 

We have requested 2 hours of session at  IETF97 in Seoul.  

We are going to give priorities to the documents that are  WG documents and
then the other individual documents that have been discussed already.

If you wish to present at 6lo WG, please send your request in the following
format to 6lo-cha...@ietf.org   and  our WG
Secretary James Woodyatt (j...@nestlabs.com  )  by
Oct 31st.

 

*   Draft name and a summary of the presentation.

*   Presenter name

*   Approximate time needed for the presentation 

 

Thanks and Regards,

 

-Samita

 

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Adoption call for 6lo Applicability and Usecases

[Samita Chakrabarti]

As a WG member, I support this draft to become a WG document.
I believe, this document will provide information on the usage and
requirements of using 6lowpan stacks over different Low-power L2 networks
-- which could be useful for the Internet Of Things Community to understand
how IPv6 adaptation might be possible for their L2 implementations.

 +1.

-Samita



On Wed, Oct 5, 2016 at 7:17 AM, Xavier Vilajosana <
xvilajos...@eecs.berkeley.edu> wrote:

> Dear Samita, all,
>
> I support the adoption of this document. I consider necessary a use case
> document that can be used as reference, presenting the current status and
> technologies that support 6lo. I would like to see there the features of
> 6lo that are supported and those that are not for the different underlying
> technologies, information about the current level of maturity and examples
> of existing deployments.
>
> I also support the inclusion of a use case describing the use of 6lo in
> the context of 6TiSCH.
>
> kind regards,
> Xavi
>
>
>
> 2016-09-21 20:00 GMT+02:00 samita Chakrabarti :
>
>> Hello Folks:
>>
>>
>>
>> We have discussed this document several times and Young-Geun Hong had
>> presented this document several times at IETF and the WG also met
>> separately to discuss the use cases and format of the document. We
>> concluded that the purpose of this document is to show others how 6lo
>> stacks can be used in different applications and on L2 constrained
>> networks. The information can be used by external organizations as a
>> guideline of examples for understanding whether their networks can be
>> suitable to run 6lo stacks. Many have been co-authored/contributed to this
>> document already.
>>
>>
>>
>> The latest version of the document is available here:
>>
>> https://datatracker.ietf.org/doc/draft-hong-6lo-use-cases/
>>
>>
>>
>>
>>
>>
>>
>> Please provide your opinion on the mailing list.
>>
>>
>>
>> The adoption call ends on October 7, 2016.
>>
>>
>>
>> Thanks,
>>
>> Gabriel and Samita
>>
>> 6lo-co chairs
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ___
>> 6lo mailing list
>> 6lo@ietf.org
>> https://www.ietf.org/mailman/listinfo/6lo
>>
>>
>
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Adoption call for 6lo Applicability and Usecases

[Samita Chakrabarti]

Thanks Pascal for your comments and pointers.
I agree about the improvement of maturity of the document and the
co-authors should consult your suggestions.

Regards,
-Samita

On Thu, Oct 6, 2016 at 11:56 PM, Pascal Thubert (pthubert) <
pthub...@cisco.com> wrote:

> I support the adoption, Samita, as I recognize the need and value;
>
>
>
> at the same time this document is a lot less mature than others I have
> seen at adoption time, and I see a need for experts in various areas to
> contribute. I hope that the adoption will increase their motivation; maybe
> we’ll try the pull method if we are lacking voluteers. Also I’d suggest we
> consider the detnet use case draft as a reference of what we want to
> achieve; Ethan is doing a fabulous editorial work there, and the group is
> not afraid of welcoming a wealth of authors from many fields:
>
>
>
>
>
> Name:  draft-ietf-detnet-use-cases
>
> Revision:  11
>
> Title:  Deterministic Networking Use Cases
>
> Document date:   2016-10-03
>
> Group:  detnet
>
> Pages:   79
>
> URL:https://www.ietf.org/internet-
> drafts/draft-ietf-detnet-use-cases-11.txt
>
> Status: https://datatracker.ietf.org/doc/draft-ietf-detnet-use-
> cases/
>
> Htmlized:   https://tools.ietf.org/html/draft-ietf-detnet-use-cases-11
>
> Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-use-
> cases-11
>
>
>
>
>
> All the best,
>
>
>
> Pascal
>
>
>
>
>
> *From:* 6lo [mailto:6lo-boun...@ietf.org] *On Behalf Of *samita
> Chakrabarti
> *Sent:* mercredi 21 septembre 2016 20:00
> *To:* 'lo' <6lo@ietf.org>
> *Subject:* [6lo] Adoption call for 6lo Applicability and Usecases
>
>
>
> Hello Folks:
>
>
>
> We have discussed this document several times and Young-Geun Hong had
> presented this document several times at IETF and the WG also met
> separately to discuss the use cases and format of the document. We
> concluded that the purpose of this document is to show others how 6lo
> stacks can be used in different applications and on L2 constrained
> networks. The information can be used by external organizations as a
> guideline of examples for understanding whether their networks can be
> suitable to run 6lo stacks. Many have been co-authored/contributed to this
> document already.
>
>
>
> The latest version of the document is available here:
>
> https://datatracker.ietf.org/doc/draft-hong-6lo-use-cases/
>
>
>
>
>
>
>
> Please provide your opinion on the mailing list.
>
>
>
> The adoption call ends on October 7, 2016.
>
>
>
> Thanks,
>
> Gabriel and Samita
>
> 6lo-co chairs
>
>
>
>
>
>
>
>
>
>
>
>
>
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Adoption call for 6lo Applicability and Usecases

[samita Chakrabarti]

Hi Take,

 

It is great to hear from you on the 6lo list. Input from practical deployment 
is quite valuable especially if your organization is considering  6lo stack. 

There are couple of ways to contribute:

 

1)  Providing suggested text on the draft and working with the co-authors 
and 6lo-chairs  to update the document

OR

2)  Writing a separate short draft with the suggested texts or use-case 
scenarios  which can be used as the input to the 6lo Applicability & usecase 
document

 

I know  we talked sometime ago off-line, if you have any further questions let 
me and Gabriel know.

 

Regards,

-Samita

 

From: Take Aanstoot [mailto:t...@modio.se] 
Sent: Saturday, October 8, 2016 2:21 AM
To: Yong-Geun Hong 
Cc: Samita Chakrabarti ; Pascal Thubert (pthubert) 
; 6lo@ietf.org
Subject: Re: [6lo] Adoption call for 6lo Applicability and Usecases

 

Dear People,

Without the deep technical knowledge as you other people I want to give some 
feedback from the field where we today are trapped in a nightmare of standards, 
telco-standards and "standards". We work with wireless, plc and rs485, knx, 
profibus, M-bus and what have you. 

This is my first post to an IETF mailinglist so please if someone wants to 
guide me on the proper way to submit parts of this if it is not totally bogus.

 

The draft is a really nice oversight over 6lo in diverse use-cases, really nice 
as a quick reference on where to continue. We (modio) will probably make a 
flowchart thing based on this document and rfc6568 where you can put in your 
use-case and based on that get to know what could be appropriate 6lo-solutions 
instead of today's old standards and de facto standards. 

I am missing the following chapters, even though the standards are not there 
yet I feel it should be mentioned so they will not be forgotten.

6loPLC, now primarily G3-PLC and Prime, needs a chapter in 3.foo and 6.foo

LPWAN on low frequency (somewhere between 60-600 Mhz).

People are testing nowadays in Europe on the following available frequencies: 
-2.4GHz, crowded, short range, crowded, worldwide, crowded, poor penetration, 
crowded.

-868 MHz, getting crowded, only 20kHz, poor hardware support.

-433MHz (and in some countries other small bands between 398 - 465 MHz), long 
range, reliable, few channels, frequency allocations are specific to particular 
countries, 10kbit/s, still expensive modules.

27 and 40MHz HF, cheap, simple, long range, crowded, low data rates, crowded, 
large antennas needed

 

For LPWAN to succeed we need more frequencies, both public ones and private 
ones booked through your local radio frequency authority. This should be named 
in the draft and also recommendations of what type of radio to run on these 
frequencies. 

It would be nice to state in this draft that in most part of the world 174-230 
MHz VHF is more or less empty or run a very deprecated radio broadcasting 
standard which will probably be decommissioned during the next few years and 
that it would be nice to reserve a big part of it for IoT use, both public and 
bookable/buyable private channels. That would be the difference between happy 
go lucky LPWAN on existing channels and a worldwide break through for reliable 
serious applications LPWAN.

 

5 Design space:

New bullet:

Update firmware requirements: Most 6 lo uses case will need a mechanism for 
updating firmware. In these cases support for over the are updates are 
required, probably in a broadcast mode when bandwith is low and the number of 
identical devices is high.  

 

Security Requirements: (Actual text: Some 6lo use case can transfer some 
important and personal data between 6lo nodes.  In this case, high-level 
security support is required.) 
6lo will be used for important data between nodes, eventually someone will also 
know how to make today's not important data very important. High level security 
support is required. 

6.4 use case of MS/TP

I can probably write something there if interest exists.

6.6 use case of LTE MTC

Mentions LTE MTC very briefly and then talks mostly about LoRa. Mayby change 
topic.

 

Are you still with me? 

Regards, Take


-- 

Take Aanstoot

CEO 

Modio AB
+254 70 646 2344
+46 13 46 555 62

t...@modio.se <mailto:t...@modio.se> 

 

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] Remote presentation cut-off date Nov 11th

[samita Chakrabarti]

Hello everyone,

 

Meetecho IETF support requests the WG chairs to submit the remote
presentation requests by Nov 11 by filling out a form with details of
presenter's information. 

 

If any of you like to present remotely to 6lo WG this time, please send your
requests to the chairs before Nov 5th to give us a little time to connect
with Meetecho.

 

Thanks,

-Samita

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Adoption call for draft-gomez-6lo-blemesh

[samita Chakrabarti]

 

With many positive responses in the mailing list  on adoption call and the
comments from BT-SIG on this draft, 

 The draft-gomez-6lo-blemish  is now a WG document!

 

Carles, please submit the document as WG -00 document after the IETF.

 

Cheers,

-6lo-chairs

 

From: samita Chakrabarti [mailto:samitac.i...@gmail.com] 
Sent: Wednesday, September 21, 2016 10:48 AM
To: 'lo' <6lo@ietf.org>
Subject: Adoption call for draft-gomez-6lo-blemesh

 

 

Hello All:

 

We have discussed 6lo-blemesh at the IETF 96 6lo meeting and there were
interests in the WG to work on this draft.

The draft authors also have been requested to check with BTSIG and BTSIG has
been consulted.

 

We would like to proceed with the WG adoption call for this document:

https://datatracker.ietf.org/doc/draft-gomez-6lo-blemesh/

 

 

Please provide your opinion on the mailing list with  'Yes/No' and a short
note.

 

The adoption call ends on October 7, 2016.

 

Thanks,

Gabriel & Samita 

6lo-chairs

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] WG adoption call for draft-sarikaya-6lo-ap-nd-04

[samita Chakrabarti]

 

We have received many positive responses in support of the draft  and
draft-sarikaya-6lo-ap-nd document is now a WG draft!

 

Authors , please submit the document as a WG -00 draft after the document
repository opens again.

 

Cheers,

-6lo-cochairs (Gabriel & Samita)

From: samita Chakrabarti [mailto:samitac.i...@gmail.com] 
Sent: Monday, September 26, 2016 6:15 PM
To: 'lo' <6lo@ietf.org>
Cc: 6lo-cha...@ietf.org
Subject: WG adoption call for draft-sarikaya-6lo-ap-nd-04

 

 

 

Hello 6lo WG:

 

We have discussed the following document at the IETF meetings and mailing
list about the use of cryptographic ID to identify one device with a
particular IPv6 address during the Neighbor Discovery Process. The crypto-ID
association is helpful when MAC-ID or EUI-64 ID may not be used.

There has been fair amount of interest in securing the IP-address owner
authentication using this method, in the WG meetings(IETF95).

 

The co-authors have addressed several WG comments in the 04 version.

 

The adoption call  starts now and ends on Oct 10th, 2016.

 

Please provide your opinion with  yes/no  answer and a short explanation for
this adoption call within the deadline.

 

Thanks and Regards,

-Gabriel and Samita (6lo co-chairs)

 

> 

> 

> Name:   draft-sarikaya-6lo-ap-nd

> Revision:   04

> Title:  Address Protected Neighbor Discovery for Low-power and
Lossy Networks

> Document date:  2016-08-22

> Group:  Individual Submission

> Pages:  17

> URL:
https://www.ietf.org/internet-drafts/draft-sarikaya-6lo-ap-nd-04.txt

> Status: https://datatracker.ietf.org/doc/draft-sarikaya-6lo-ap-nd/

> Htmlized:   https://tools.ietf.org/html/draft-sarikaya-6lo-ap-nd-04

> Diff:
https://www.ietf.org/rfcdiff?url2=draft-sarikaya-6lo-ap-nd-04

> 

> Abstract:

>This document defines an extension to 6LoWPAN Neighbor Discovery.

>This extension is designed for low-power and lossy network

>environments and it supports multi-hop operation.  Nodes supporting

>this extension compute a Cryptographically Unique Interface ID and

>associate it with one or more of their Registered Addresses.  The

>Cryptographic ID (Crypto-ID) uniquely identifies the owner of the

>Registered Address.  It is used in place of the EUI-64 address that

>is specified in RFC 6775.  Once an address is registered with a

>Cryptographic ID, only the owner of that ID can modify the state

>information of the Registered Address in the 6LR and 6LBR.

 

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Adoption call for 6lo Applicability and Usecases

[samita Chakrabarti]

Hello WG,

 

We received positive responses in support of the adoption call of
draft-hong-6lo-use-cases and this document now  becomes a  6lo WG.

Young-Geun, please submit this draft as WG -00 document after the IETF.

 

Cheers,

-6lo co-chairs (Gabriel & Samita) 

 

From: samita Chakrabarti [mailto:samitac.i...@gmail.com] 
Sent: Wednesday, September 21, 2016 11:00 AM
To: 'lo' <6lo@ietf.org>
Subject: Adoption call for 6lo Applicability and Usecases

 

Hello Folks:

 

We have discussed this document several times and Young-Geun Hong had
presented this document several times at IETF and the WG also met separately
to discuss the use cases and format of the document. We concluded that the
purpose of this document is to show others how 6lo stacks can be used in
different applications and on L2 constrained networks. The information can
be used by external organizations as a guideline of examples for
understanding whether their networks can be suitable to run 6lo stacks. Many
have been co-authored/contributed to this document already.

 

The latest version of the document is available here:

https://datatracker.ietf.org/doc/draft-hong-6lo-use-cases/

 

 

 

Please provide your opinion on the mailing list.

 

The adoption call ends on October 7, 2016.

 

Thanks,

Gabriel and Samita

6lo-co chairs

 

 

 

 

 

 

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] 6lo IETF97 agenda uploaded

[Samita Chakrabarti]

Hello 6lo WG:

We have uploaded the agenda for 6lo WG meeting at IETF97 based on the
requests received so far. The requesters/presenters, please check if the
agenda time slots reflect your request. Please contact 6lo-chairs if you
have any comments regarding the agenda.

Best regards,
-Samita

PS:  At Seoul IETF, unfortunately I will not be able to attend in person
but I will be attending over meetecho this time.
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] 6lo IETF97 agenda uploaded

[Samita Chakrabarti]

Agenda URL : https://datatracker.ietf.org/meeting/97/agenda/6lo/

-Samita

On Fri, Nov 4, 2016 at 11:46 AM, Samita Chakrabarti 
wrote:

> Hello 6lo WG:
>
> We have uploaded the agenda for 6lo WG meeting at IETF97 based on the
> requests received so far. The requesters/presenters, please check if the
> agenda time slots reflect your request. Please contact 6lo-chairs if you
> have any comments regarding the agenda.
>
> Best regards,
> -Samita
>
> PS:  At Seoul IETF, unfortunately I will not be able to attend in person
> but I will be attending over meetecho this time.
>
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] IETF97 6lo WG Minute takers and Jabber Scribe

[Samita Chakrabarti]

Hello 6lo WG IETF97 attendees:

If you like to help us out with taking notes and being jabber scribes,
please let James and 6lo-chairs know as soon as possible.

Cheers,
-Samita
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] about 6lo-ra-in-ie

[Samita Chakrabarti]

Hi Michael,

Are you proposing that draft-richardson-6lo-ra-in-ie to be discussed and
standardized at 6tisch only?

If this document deals with sending RA over 6loRH, we would like to
understand its relationship with 6lowpan-ND behavior and whether it is
moving away from 6lowpan base requirements.

Thanks,
-Samita




On Sat, Nov 12, 2016 at 12:54 PM, Michael Richardson 
wrote:

>
> A few weeks ago I posted about draft-ietf-richardson-6lo-ra-in-ie, which
> was
> a method for storing 6loRH compressed Routing Advertisements in 802.15.4
> Information Elements.  The mechanism described would have permitted
> arbitrary
> IPv6 packets to be stored there (it was a general mechanism).
>
> The subsequent discussion in the 6tisch-security design team and with the
> 6tisch chairs was that:
>   1) we would make it very specific to storing Routing Advertisements
> Options
>  only.
>   2) as a result, we can do this work entirely in the 6tisch WG.
>
>
>
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>
>
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] AD evaluation: draft-ietf-6lo-dispatch-iana-registry-05

[Samita Chakrabarti]

Hi Suresh,

Thanks for  your review comments and  the good catch. It will be fixed ASAP.

-Samita


On Wed, Nov 16, 2016 at 2:33 PM, Suresh Krishnan <
suresh.krish...@ericsson.com> wrote:

> Hi authors,
>I have gone through the draft and I found a minor issue that needs to be
> fixed before I send it forward
>
> In Section 3, the ESC dispatch byte is described as
>
> ESC: The left-most byte is the ESC dispatch type containing '010'
>
> The actual byte value is incorrect and should be '0100'
>
> Please submit a new rev with the right value and I will progress the
> document.
>
> Thanks
> Suresh
>
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] AD evaluation: draft-ietf-6lo-dispatch-iana-registry-05

[Samita Chakrabarti]

Thanks to Gabe who submitted the draft in a blaze!!

-Samita

On Wed, Nov 16, 2016 at 6:18 PM, Suresh Krishnan <
suresh.krish...@ericsson.com> wrote:

> Thanks for fixing it quickly Samita. I have sent the document to IETF Last
> Call.
>
> Thanks
> Suresh
>
> On 11/17/2016 10:21 AM, Samita Chakrabarti wrote:
> > Hi Suresh,
> >
> > Thanks for  your review comments and  the good catch. It will be fixed
> ASAP.
> >
> > -Samita
> >
> >
> > On Wed, Nov 16, 2016 at 2:33 PM, Suresh Krishnan
> > mailto:suresh.krish...@ericsson.com>>
> wrote:
> >
> > Hi authors,
> >I have gone through the draft and I found a minor issue that
> needs to be
> > fixed before I send it forward
> >
> > In Section 3, the ESC dispatch byte is described as
> >
> > ESC: The left-most byte is the ESC dispatch type containing '010'
> >
> > The actual byte value is incorrect and should be '0100'
> >
> > Please submit a new rev with the right value and I will progress the
> > document.
> >
> > Thanks
> > Suresh
> >
> >
>
>
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] IETF97 6lo WG minutes are available now on the materials page

[samita Chakrabarti]

https://www.ietf.org/proceedings/97/minutes/minutes-97-6lo-00.txt

 

Hello 6lo WG:

 

Please review and let us know of  any concerns or modifications.

 

Thanks to Daniel B. and Thomas W. for the detailed notes. We appreciated
your help.

 

Best regards,

-Samita

 

 

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Gen-art LC review: draft-ietf-6lo-dect-ule-08

[Samita Chakrabarti]

Hi Jens and Robert:

Here are a few ideas for Jens to avoid trouble referring a non-RFC document
in the Normative section:

* It seems Backbone Router is not a requirement of  dect-ule specification
to work. 6BBR has been mentioned to show how it might work with such
 advanced scenarios.

a) Add an Appendix section and show backbone router related examples and
references there.


[Jens, please refer to RFC7428 for an example on the Appendix section.]

b) Another option is to move entire section 3.3 and 2.5 to the Appendix
section [ Not sure if that is a good idea at this point ]

c)  Leave it as it is [ i,e backbone router reference goes into informative
reference]


I'd resort to Suresh's suggestion, it is our AD's call at this time.

Thanks,
-Samita


On Wed, Dec 21, 2016 at 1:26 AM, Jens Toftgaard Petersen  wrote:

> Hi Robert,
>
> Thanks for your useful comment and guidance.
>
> The multi-cell scenario, that the section is addressing, will probably
> only be used rare cases - currently it is definitely not the primary use
> case.
> I believe that even without the reference to 6BBR the draft has all the
> information to ensure interoperability between DECT ULE devices. The
> sentence is rather to remind implementers of "backbone" infrastructure of
> the guidance in ietf-6lo-backbone-router.
> I am fine with current wording, but for me it is also OK changing the
> wording if that makes it clearer - any guidance from AD?
>
> Thanks and best regards,
>   Jens
>
>
> -Original Message-
> From: Robert Sparks [mailto:rjspa...@nostrum.com]
> Sent: 20. december 2016 15:38
> To: Jens Toftgaard Petersen ; General Area Review Team <
> gen-...@ietf.org>; i...@ietf.org; 6lo@ietf.org;
> draft-ietf-6lo-dect-ule@ietf.org
> Subject: Re: Gen-art LC review: draft-ietf-6lo-dect-ule-08
>
>
>
> On 12/20/16 6:26 AM, Jens Toftgaard Petersen wrote:
> > Hi Robert,
> >
> > Thanks for your clarification of normative references to work in
> progress.
> >
> > I would prefer to keep the reference as in the updated version -09:
> >
> > "The FPs in such a scenario should behave as Backbone
> > Routers (6BBR) as defined in [I-D.ietf-6lo-backbone-router]."
> >
> > Are you OK with that?
> Maybe. I'm not the expert here, so all I can do is ask (what are hopefully
> useful) questions:
>
> Here's one way to help figure this out: Would you be ok deleting the
> sentence and the reference? (I'm not asking you to do that, just to
> consider what it would mean to the resulting set of implementations if you
> did.)
>
> If you think people will build the right software with that sentence
> missing, and you'll get the interoperability you're aiming for, then it's
> fine as an Informative reference. This would be the case if what you're
> really doing with that sentence is saying "other documents in the base
> protocol this is building on require you to behave this way, we're just
> pointing at that here to remind you of that fact".
>
> If that's going to leave implementers guessing at what their
> implementation is supposed to do, and interoperability will suffer, then
> it's normative. (What you're really doing with that sentence is telling the
> implementers something _new_ - that they SHOULD behave as a 6BBR in this
> situation, and nothing else tells them to do that, and the reference is
> here to tell them how to do that).
>
> Alternatively, if it's just fine that some large subset _doesn't_ behave
> as a 6BBR, then its fine the way it is. You might consider saying "One good
> way for an FP can behave in such scenarios is as a Backbone Router..."
> instead, to make it clearer that this is just informational guidance rather
> than something that would affect interoperability in the resulting
> implementation base.
>
> Either way, I'm happy leaving it up to you and your ADs at this point.
> >
> > Best regards,
> >Jens
> >
> > -Original Message-
> > From: Robert Sparks [mailto:rjspa...@nostrum.com]
> > Sent: 17. december 2016 00:31
> > To: Jens Toftgaard Petersen ; General Area Review Team
> > ; i...@ietf.org; 6lo@ietf.org;
> > draft-ietf-6lo-dect-ule@ietf.org
> > Subject: Re: Gen-art LC review: draft-ietf-6lo-dect-ule-08
> >
> > Just one comment at the end:
> >
> >
> > On 12/15/16 4:04 PM, Jens Toftgaard Petersen wrote:
> >> Hi Robert,
> >>
> >> Many thanks for your review. See my comments and answers inline below.
> >>
> >> Best regards,
> >> Jens
> >>
> >> -Original Message-
> >> From: Robert Sparks [mailto:rjspa...@nostrum.com]
> >> Sent: 28. november 2016 21:22
> >> To: General Area Review Team ; i...@ietf.org;
> >> 6lo@ietf.org; draft-ietf-6lo-dect-ule@ietf.org
> >> Subject: Gen-art LC review: draft-ietf-6lo-dect-ule-08
> >>
> >> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed by the
> IESG for the IETF Chair.  Please treat these comments just like any other
> last call comments.
> >>
> >> For more information

[6lo] Understanding RFC8025 implementation and page switcihing

[Samita Chakrabarti]

Hello :

I am trying to decipher the RFC 8025  packet header sequence and bit
patterns from reading the document and
http://www.iana.org/assignments/_6lowpan-parameters/.

Sorry, I should have asked these questions before, but it is never too
late...

* I assume the main purpose is to give the implementor tools to go and
parse/interprete additional data carried by original RFC 4944 style packet
or not.

* The document says that the page-switch dispatch type should be always
preceded by mesh and fragment header. I would assume that original pg 0 or
LOWPAN-IPHC dispatch type can precede as well. Can some one confirm if the
following sequences are valid ?

1) [Mesh][page-switch-to-X][New-dispatch-type from page X][Payload]
2) [ESC][ESC-Bytes][LOWPAN_IPHC][page-switch-to-X][Page-X-dispatch][Payload]
3)
[LOWPAN-IPHC][Payload][page-switch-toX][Page-X-dispatch][additional-payload]


If both 2 and 3 are valid sequences, can you please provide two examples of
use-cases ?

I was not sure if we can allow payload with each page and parse multiple
payloads with the same packet [ assuming we have large enough frame size].

Thanks,
-Samita
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] Call for 6lo presentations at Chicago March IETF

[Samita Chakrabarti]

Hello 6lo Colleagues:

Gabriel and I are starting to plan for the upcoming 6lo session at IETF98.

We have requested 2.5 hours slot this time.

Please send us your request to 6lo-cha...@ietf.org on presentations of
drafts with the following information:

Draft name :
Brief description:
Presenter:
Objective :

--
We have successfully completed many drafts to RFC that were on the queue.
New proposals are welcome.

The requests are due on or before March 13th, 2017.

Remember that the draft submission cut-off date is March 13th as well.
Thanks,
-Samita
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] [PATCH v5 6/6] 6lowpan: Fix IID format for Bluetooth

[Samita Chakrabarti]

Hello Alexander,

Glad to hear that folks are trying to implement RFC 7668.

You are right in conclusion that no u or g bit handling is required.

>From RFC 7668, section 3.2.2 -- it says that one should use 48-bit BT
device identification  and form the 64-bit IID  separated by oxFFFE. The BT
identification bits are marked as 'b' in the specification and they stay
unchanged. So U/L considerations are not needed.

This is still following RFC 7136 method of IPv6 address formation as the
48-bit BT device identification is not the same IEEE based 48bit MAC
address.

Thanks,
-Samita



On Sat, Feb 25, 2017 at 10:25 PM, Alexander Aring 
wrote:

>
> Hi,
>
> On 02/26/2017 07:05 AM, Alexander Aring wrote:
> >
> > Hi,
> >
> > On 02/24/2017 01:14 PM, Luiz Augusto von Dentz wrote:
> >> From: Luiz Augusto von Dentz 
> >>
> >> Accourding to RFC 7668 U/L bit shall not be used:
> >>
> >> https://wiki.tools.ietf.org/html/rfc7668#section-3.2.2 [Page 10]:
> >>
> >>In the figure, letter 'b' represents a bit from the
> >>Bluetooth device address, copied as is without any changes on any
> >>bit.  This means that no bit in the IID indicates whether the
> >>underlying Bluetooth device address is public or random.
> >>
> >>|0  1|1  3|3  4|4  6|
> >>|0  5|6  1|2  7|8  3|
> >>++++
> +
> >>|||1110|
> |
> >>++++
> +
> >>
> >> Because of this the code cannot figure out the address type from the IP
> >> address anymore thus it makes no sense to use peer_lookup_ba as it needs
> >> the peer address type.
> >>
> >
> > I am still not quite 100% of this and want to leave my opinion about this
> > handling which can be interpreted in a different way.
> >
> > The RFC says here:
> >
> > Following the guidance of [RFC7136], a 64-bit
> > Interface Identifier (IID) is formed from the 48-bit Bluetooth device
> > address by inserting two octets, with hexadecimal values of 0xFF and
> > 0xFE in the middle of the 48-bit Bluetooth device address as shown in
> > Figure 6.
>
> Okay, they said from IID from the 48-bit address.
>
> And IID is what you need here and what [RFC7136] describes as result,
> so I think you are right.
>
> There is no need for special u/l bitflip or link-layer multicast handling.
>
> - Alex
>
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Understanding RFC8025 implementation and page switching

[Samita Chakrabarti]

Thanks Robert, Pascal and Carsten for clarification and order of pages and
mesh/frag headers in the context of paging dispatch.
Is there a way to capture these information and tag that with RFC page?
This is not an Errata but the order and explanation would be quite useful
for the implementers for future extensions.

Alternatively, updating the 6lo wiki  to contain these information would be
useful. Any suggestions ?

Thanks,
-Samita

On Mon, Feb 27, 2017 at 9:46 AM, Robert Cragie 
wrote:

>
>
> On 27 February 2017 at 13:56, Pascal Thubert (pthubert) <
> pthub...@cisco.com> wrote:
>
>> Dear Samita :
>>
>>
>>
>> *From:* Samita Chakrabarti [mailto:samitac.i...@gmail.com]
>>
>>
>>
>> Hello :
>>
>>
>>
>> I am trying to decipher the RFC 8025  packet header sequence and bit
>> patterns from reading the document and http://www.iana.org/assign
>> ments/_6lowpan-parameters/.
>>
>>
>>
>> Sorry, I should have asked these questions before, but it is never too
>> late...
>>
>>
>>
>> * I assume the main purpose is to give the implementor tools to go and
>> parse/interprete additional data carried by original RFC 4944 style packet
>> or not.
>>
>>
>>
>> *[Pascal] Yes, we have a very large space now.*
>>
>>
>>
>> * The document says that the page-switch dispatch type should be always
>> preceded by mesh and fragment header. I would assume that original pg 0 or
>> LOWPAN-IPHC dispatch type can precede as well. Can some one confirm if the
>> following sequences are valid ?
>>
>>
>>
>> *[Pascal] The page 0 switch is implicit and placed before the mesh
>> header, which is defined in that page. There can be a packet without a mesh
>> or a fragment header, so a page switch is not always preceded by one of
>> those. But if one of those headers is present, then it appears before
>> switching to another page.*
>>
>
> 
> There is nothing stopping definitions for a mesh header equivalent in
> pages 2-14 and fragment header equivalent in pages 1-14. However, in the
> context of RFC 8025, mesh and fragment headers are strictly considered as
> being in page 0, hence having to precede them with a page 0 dispatch, which
> as Pascal says is implicit at the beginning of a frame, i.e. at the moment
> we would have:
>
> [(implicit page 0 dispatch)][MESH][FRAG0][page-switch-to-X][New-dispatch-type
> from page X][Payload]
>
> In the future, one can envisage alternatives however:
>
> [page-switch-to-2][MESH from page 2][FRAG from page 2][New-dispatch-type
> from page 2][Payload]
> 
>
>>
>>
>> 1) [Mesh][page-switch-to-X][New-dispatch-type from page X][Payload]
>>
>> *[Pascal] Valid*
>>
>> 2) [ESC][ESC-Bytes][LOWPAN_IPHC][page-switch-to-X][Page-X-dispatch][Payload]
>>
>>
>> *[Pascal] I expect that this could happen with an update of RFC 6282, but
>> with the current spec you cannot since RFC6282 defines the chain all the
>> way to the payload or at least the end of the compressed piece.*
>>
>>
>>
>> 3) [LOWPAN-IPHC][Payload][page-switch-toX][Page-X-dispatch][add
>> itional-payload]
>>
>> *[Pascal] Then again this could happen but would need new specs *
>>
>>
>>
>>
>>
>> If both 2 and 3 are valid sequences, can you please provide two examples
>> of use-cases ?
>>
>>
>>
>> *[Pascal] It could potentially be used for selectively compressing or
>> signing the payload; but  I’m not aware of anyone trying this. *
>>
>> *It could also be used for packaging separate fragments back together or
>> something. I do hope that no one ever specifies this based on what I heard
>> from MP-TCP and middle box games.*
>>
>> *The most common sequence involving RFC 8025 would be *[page-switch-to-Page1]
>> [6LoRH]* [LOWPAN-IPHC] [IPv6 headers]* [LOWPAN-NHC] [Payload]
>>
>>
>>
>> I was not sure if we can allow payload with each page and parse multiple
>> payloads with the same packet [ assuming we have large enough frame size].
>>
>> *[Pascal] The paging does not say, but new specs using it would.*
>>
>>
>>
>> *Take care, *
>>
>>
>>
>> *Pascal*
>>
>>
>>
>> Thanks,
>>
>> -Samita
>>
>>
>>
>> ___
>> 6lo mailing list
>> 6lo@ietf.org
>> https://www.ietf.org/mailman/listinfo/6lo
>>
>>
>
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Understanding RFC8025 implementation and page switching

[Samita Chakrabarti]

Any volunteers from paging dispatch experts to add a few lines about the
ordering examples and example usage with 6loRH on the 6lo wiki page?
Thanks,
-Samita

On Mar 1, 2017 2:00 AM, "Robert Cragie"  wrote:

> I don't think the RFC is incorrect as it stands and it is arguable that
> future "what if's" shouldn't really be captured in an RFC and it should
> represent only the state of the art. Therefore, I think the Wiki would be
> the right place to do this.
>
> Robert
>
> On 1 March 2017 at 09:03, Pascal Thubert (pthubert) 
> wrote:
>
>> Unsure which format would be best, Samita.
>>
>>
>>
>> There can be a variety of such questions. So maybe a Q&A in the WiKi
>> could collect this sort of questions when they occur?
>>
>> At least this thread is now visible.
>>
>>
>>
>> Take care,
>>
>>
>>
>> Pascal
>>
>>
>>
>> *From:* Samita Chakrabarti [mailto:samitac.i...@gmail.com]
>> *Sent:* mercredi 1 mars 2017 02:47
>> *To:* robert.cra...@gridmerge.com
>> *Cc:* Pascal Thubert (pthubert) ; lo <6lo@ietf.org>
>> *Subject:* Re: [6lo] Understanding RFC8025 implementation and page
>> switching
>>
>>
>>
>> Thanks Robert, Pascal and Carsten for clarification and order of pages
>> and mesh/frag headers in the context of paging dispatch.
>>
>> Is there a way to capture these information and tag that with RFC page?
>> This is not an Errata but the order and explanation would be quite useful
>> for the implementers for future extensions.
>>
>>
>>
>> Alternatively, updating the 6lo wiki  to contain these information would
>> be useful. Any suggestions ?
>>
>>
>>
>> Thanks,
>>
>> -Samita
>>
>>
>>
>> On Mon, Feb 27, 2017 at 9:46 AM, Robert Cragie <
>> robert.cra...@gridmerge.com> wrote:
>>
>>
>>
>>
>>
>> On 27 February 2017 at 13:56, Pascal Thubert (pthubert) <
>> pthub...@cisco.com> wrote:
>>
>> Dear Samita :
>>
>>
>>
>> *From:* Samita Chakrabarti [mailto:samitac.i...@gmail.com]
>>
>>
>>
>> Hello :
>>
>>
>>
>> I am trying to decipher the RFC 8025  packet header sequence and bit
>> patterns from reading the document and http://www.iana.org/assign
>> ments/_6lowpan-parameters/.
>>
>>
>>
>> Sorry, I should have asked these questions before, but it is never too
>> late...
>>
>>
>>
>> * I assume the main purpose is to give the implementor tools to go and
>> parse/interprete additional data carried by original RFC 4944 style packet
>> or not.
>>
>>
>>
>> *[Pascal] Yes, we have a very large space now.*
>>
>>
>>
>> * The document says that the page-switch dispatch type should be always
>> preceded by mesh and fragment header. I would assume that original pg 0 or
>> LOWPAN-IPHC dispatch type can precede as well. Can some one confirm if the
>> following sequences are valid ?
>>
>>
>>
>> *[Pascal] The page 0 switch is implicit and placed before the mesh
>> header, which is defined in that page. There can be a packet without a mesh
>> or a fragment header, so a page switch is not always preceded by one of
>> those. But if one of those headers is present, then it appears before
>> switching to another page.*
>>
>>
>>
>> 
>>
>> There is nothing stopping definitions for a mesh header equivalent in
>> pages 2-14 and fragment header equivalent in pages 1-14. However, in the
>> context of RFC 8025, mesh and fragment headers are strictly considered as
>> being in page 0, hence having to precede them with a page 0 dispatch, which
>> as Pascal says is implicit at the beginning of a frame, i.e. at the moment
>> we would have:
>>
>>
>>
>> [(implicit page 0 dispatch)][MESH][FRAG0][page-switch-to-X][New-dispatch-type
>> from page X][Payload]
>>
>>
>>
>> In the future, one can envisage alternatives however:
>>
>>
>>
>> [page-switch-to-2][MESH from page 2][FRAG from page 2][New-dispatch-type
>> from page 2][Payload]
>>
>> 
>>
>>
>>
>> 1) [Mesh][page-switch-to-X][New-dispatch-type from page X][Payload]
>>
>> *[Pascal] Valid*
>>
>> 2) [ESC][ESC-Bytes][LOWPAN_IPHC][page-switch-to-X][Page-X-dispatch][Payload]
>>
>>
>> *[Pascal] I expect that this could happen with an update of RFC 6282, but
>> with the current spec you cannot since RFC

[6lo] 6lo session on Wednesday

[Samita Chakrabarti]

6lo Session 1 (2:30:00)
Wednesday, Morning Session I 0900-1130
Room Name: Zurich A


FYI.
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] Reminder: Call for 6lo presentations at Chicago March IETF

[Samita Chakrabarti]

Hello all:

Please  respond with your requests for 6lo presentation By March 13th.
Also let us and James know if there will be any remote presenters.

Thanks,
-Samita

On Wed, Feb 22, 2017 at 12:21 PM, Samita Chakrabarti  wrote:

> Hello 6lo Colleagues:
>
> Gabriel and I are starting to plan for the upcoming 6lo session at IETF98.
>
> We have requested 2.5 hours slot this time.
>
> Please send us your request to 6lo-cha...@ietf.org on presentations of
> drafts with the following information:
>
> Draft name :
> Brief description:
> Presenter:
> Objective :
>
> --
> We have successfully completed many drafts to RFC that were on the queue.
> New proposals are welcome.
>
> The requests are due on or before March 13th, 2017.
>
> Remember that the draft submission cut-off date is March 13th as well.
> Thanks,
> -Samita
>
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] IETF98 6lo Agenda uploaded

[Samita Chakrabarti]

Hello 6lo Colleagues:

Based on your requests for slots, here is the preliminary agenda. Please
take a look and let us know if any modifications are needed.

Note, there might be another update of the agenda before March 25th.
https://datatracker.ietf.org/meeting/98/agenda/6lo/



Thanks,
-Gabriel and Samita
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] 转发: New Version Notification for draft-hou-6lo-plc-00.txt

[Samita Chakrabarti]

Hi Jianquiang and co-authors:

I have browsed through the draft and thank you for bringing this work at
IETF.

A few comments and questions:

1) Is it safe to assume that all the nodes in PLC network are line-powered?
2) How does the IPv6 addresses are assigned in the mesh or tree network?
3) In the abstract the document talks about RFC6775, but originally G3-PLC
started using RFC 4861 IPv6-ND, is there a plan to adapt to 6lowpan-nd (RFC
6775)  ARO messages toward the PAN-co-ordinator or LBR ?
4) Section 4.1.3 talks about address mapping for 64-bit MAC address or
16-bit short address and there is one line on possibility of non-MAC
address derived addresses for privacy. Can you please elaborate/recommend
the privacy address procedure based on RFC 8065 ? Also, please indicate
when to use short-addresses and when to use 64bit ID based addresses in PLC
networks (such as local and Internet connectivity)?
5) Section 4.2.6 documents the 6lowpan extension headers and ESC dispatch
type usage. In the appendix or somewhere in the document, please explain
the use of command id and need for the extension in a short paragraph.
Please refer to RFC 8066 in the ESC header byte context and make sure it
follows the guideline described there.
6) Please provide an example of header orders(with diagrams) used in PLC
network from node to the LBR of PLC network. Does it always use Mesh header
along with IPHC?

Thanks,
-Samita



On Mon, Mar 13, 2017 at 11:08 PM, houjianqiang 
wrote:

> Dear all,
>
> We would like to draw your attention that we have submitted a new draft
>  which describes the transmission of IPv6 packets
> over Power Line Communication (PLC) networks. You can access this draft
> from here:
>
> https://tools.ietf.org/id/draft-hou-6lo-plc-00.txt
>
> Your comments are highly appreciated.
>
> Best regards,
> Jianqiang
>
>
> -邮件原件-
> 发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> 发送时间: 2017年3月13日 9:56
> 收件人: houjianqiang ; Yong-Geun Hong <
> ygh...@etri.re.kr>; Yong-Geun Hong ; Xiaojun Tang <
> i...@sgepri.sgcc.com.cn>
> 主题: New Version Notification for draft-hou-6lo-plc-00.txt
>
>
> A new version of I-D, draft-hou-6lo-plc-00.txt has been successfully
> submitted by Jianqiang Hou and posted to the IETF repository.
>
> Name:   draft-hou-6lo-plc
> Revision:   00
> Title:  Transmission of IPv6 Packets over PLC Networks
> Document date:  2017-03-10
> Group:  Individual Submission
> Pages:  17
> URL:https://www.ietf.org/internet-drafts/draft-hou-6lo-plc-00.
> txt
> Status: https://datatracker.ietf.org/doc/draft-hou-6lo-plc/
> Htmlized:   https://tools.ietf.org/html/draft-hou-6lo-plc-00
>
>
> Abstract:
>Power Line Communication (PLC), namely using the electric-power lines
>for indoor and outdoor communications, has been widely applied to
>support Advanced Metering Infrastructure (AMI), especially the smart
>meters for electricity.  With the inherent advantage of existing
>electricity infrastructure, PLC is expanding deployments all over the
>world, indicating the potential demand of IPv6 for future
>applications.  As part of this technology, Narrowband PLC (NBPLC) is
>focused on the low-bandwidth and low-power scenarios, including
>current standards such as IEEE 1901.2 and ITU-T G.9903.  This
>document describes how IPv6 packets are transported over constrained
>PLC networks.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> The IETF Secretariat
>
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] draft-ietf-6lo-use-cases-01.txt - Comments

[Samita Chakrabarti]

Hi Yong-Geun,


Here are some comments on the 6lo-applicability document.
6lo-chairs have been asked to take a close look at the document and I have
volunteered to guide the document content along with you/co-authors and WG.
We can meet before the 6lo meeting and lay out ideas on the modification.

General comment:

1)  The document is growing too big and lost focus a bit : we need to make
it concise and to the point in relevance with 6lo
2) Editorial changes are needed toward the audience who might have heard of
6lowpan and are interested in finding out whether their application/network
is suitable for running 6lo (6lowpan stack with modifications).

3) It talks about LTE MTC and LPWAN technologies as a backhaul gateway
where 6lo-type of networks might be one link in the gateway on the LAN
side. This is a real-life application. We need to work with LPWAN chairs
 and provide diagrams to interconnect both 6lo and LPWAN networks

4)  The Design section gives ideas on different design attributes which are
useful. Now that we have various scenarios with different/TBD attributes, I
am thinking that having the same attributes for all usecases may not be
required. We may pick one or two examples with complete  set of attributes.

5) From the examples, it is not clear where 6lo network and nodes are
running in the example. Clarification required.


The Abstract:
Current Text:

This document describes the applicability of IPv6 over constrained node
networks (6lo) and use cases. It describes the practical deployment
scenarios of 6lo technologies with the consideration of 6lo link layer
technologies and identifies the requirements. In addition to IEEE 802.15.4,
various link layer technologies such as ITU-T G.9959 (Z-Wave), BLE,
DECT-ULE, MS/TP, NFC, LTE MTC, PLC (IEEE 1901), and IEEE 802.15.4e(6tisch)
are widely used at constrained node networks for typical services. Based on
these link layer technologies, IPv6 over networks of resource-constrained
nodes has various and practical use cases. To efficiently implement typical
services, the applicability and consideration of several design space
dimensions are described.

Suggested Text:
This document describes the applicability guideline of IPv6 over
constrained node networks (6lo) specifications and use cases. It describes
the practical deployment scenarios of *multiple* 6lo technologies and
identifies the requirements.  *A consideration on use-case deployment
design dimensions is also described. The aim of this document is to guide
an audience who are new to IPv6 low power constrained network technologies
and want to assess if the 6lowpan stack can be applied to their constrained
L2-technology of interest*.


Editorial comments:
I have many editorial comments; we can discuss them at IETF 'side meeting'.

Other:
Section 5 ( Design Space): Please add a sub section on '6lo adaptation
consideration'. I can help with the text there.
Primarily this subsection may talk about in general what people might think
about when they consider running IP(v6) on their constrained nodes (i,e
IPv6 address mapping, Prefix distribution, Access security, fragmentation
requirements, privacy, L2/L3 topology  etc.)


What do folks think about a tittle " 6lo Applicability Guideline" instead
of " 6lo Applicability and Usecases" ?

The goal is to hand out an IETF document to the non-IETF community to
spread  the word about IETF work on  IPv6 IOT stack for constrained
networks.

Comments are welcome.

Thanks,
-Samita

On Mon, Mar 13, 2017 at 2:20 AM,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IPv6 over Networks of
> Resource-constrained Nodes of the IETF.
>
> Title   : IPv6 over Constrained Node Networks(6lo)
> Applicability & Use cases
> Authors : Yong-Geun Hong
>   Carles Gomez
>   Abdur Rashid Sangi
>   Take Aanstoot
> Filename: draft-ietf-6lo-use-cases-01.txt
> Pages   : 29
> Date: 2017-03-13
>
> Abstract:
>This document describes the applicability of IPv6 over constrained
>node networks (6lo) and use cases.  It describes the practical
>deployment scenarios of 6lo technologies with the consideration of
>6lo link layer technologies and identifies the requirements.  In
>addition to IEEE 802.15.4, various link layer technologies such as
>ITU-T G.9959 (Z-Wave), BLE, DECT-ULE, MS/TP, NFC, LTE MTC, PLC (IEEE
>1901), and IEEE 802.15.4e(6tisch) are widely used at constrained node
>networks for typical services.  Based on these link layer
>technologies, IPv6 over networks of resource-constrained nodes has
>various and practical use cases.  To efficiently implement typical
>services, the applicability and consideration of several design space
>dimensions are described.
>
>
> The IETF datatracker status page for this d

[6lo] Slides for Wed 6lo session due on Monday 27th March

[Samita Chakrabarti]

Dear Presenters,

Please send your slides for 6lo to the chairs 6lo-cha...@ietf.org by Monday
noon Chicago time.

Thanks,
-Samita and Gabriel
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] Today's 6lo meeting + 6lo plugfest question

[Samita Chakrabarti]

A few 'notes and thanks' for the 6lo session this morning.

Thanks to all of you who helped us fixing the initial technical issue of
not being able to display our console on the projector due to some issues
with incompatible adapter and the projector being powered off.

Thanks to Ines for being our jabber scribe and keeping an eye on meetecho
participants.

Many thanks to Dominique for being our consistent minute taker for last few
IETFs!  The etherpad notes are available now while it is being merged with
other notes :
http://etherpad.tools.ietf.org:9000/p/notes-ietf-98-6lo?useMonospaceFont=true

If anyone else has taken notes, please send them to the 6lo-cha...@ietf.org

--Note on-- 6lo plugtest along with 6tisch in Prague---

Kerry asked the question at 6tisch and we were supposed to discuss this at
6lo meeting but we could not get to it due to time shortage.

Here is what we like to ask in the mailing list:

1) If the 6lo implementors like to participate  in 6lo plugfest along with
6tisch, please express your interest to the mailing list and:
Contact: Kerry Lynn, Carsten Bormann and 6lo-chairs

2) Also we invite suggestions on improving the 6lo testing efficiency and
planning if we do participate in the plugfest based on the past experiences



Finally thanks to our AD, Suresh Krishnan for helpful advices during the
meeting today and to all our members who participated the session!

Cheers,
-Samita , Gabriel, Ralph and James (6lo-office)
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] 6lo IETF98 meeting minutes

[Samita Chakrabarti]

Hello all:

The Chicago meeting minutes have been posted:
https://www.ietf.org/proceedings/98/minutes/minutes-98-6lo-00.txt

Please let 6lo-cha...@ietf.org know if any modification is needed by May
10th.

Thanks,
-Samita
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] I-D Action: draft-ietf-6lo-rfc6775-update-04.txt

[Samita Chakrabarti]

ne network terminologies are OK
 d) Add proxy ND defininition


Section 4:

'Extending RFC 7400' seems out-of-context here.

Q1 : Should extension of RFC 7400 belong in this document?
Q2:  If Q1 is yes, then move this section after section 7. POssibly provide
a diagram to
 show the format change


Section 5:
   a) Clarify T-bit usage a bit on detection of mobility. This is going to
be very useful
  feature in general for other link-layers too. Please describe it
without giving a
  specific scenario.  Mobility detection is missing in RFC 6775.


Section 5.2:
a) Please remove all reference of RPL in this section. One does not
need to understand RPL
   mechanism or deploy RPL mechanism in order to use T-bit in
6LOWPAN-ND.
   Please describe usage of T-bit in context of 6lo networks in
general. I understand that
   we want to introduce it in RFC 6775 in order to detect mobility of
the 6LN as opposed to
   retrying.

Section 5.5 : s/Link-Local Address Registration/Link-Local Address
Registration Change/

 a) Please shrink the texts in this section and provide a gist of
change in either
 first or 2nd paragraph. Please try to reduce the texts into 4-5
paragraphs.

Section 5.6:
Remove reference for RPL networks (RFC 6550) please. This draft
does not/should not
depend on one particular routing protocol or configuration


Section 7:
   Backward Compatibility:

   a) Please move up the 7.2 -7.4 ( all legacy nodes behavior)  in the
begining of the section.
   b) Current 7.1 section should follow after the legacy behavior
   c) Please add some text about backward compatibility of legacy nodes
(6LN,6LR and 6LBR in
  any combination) right below section 7.
  Q: How does EARO modification, target address registration and
link-local registration change
  ensure that they are transparent to a legacy 6LBR or legacy
6LR or legacy 6LN ?
   d) It is best to organize section 7 with two main sub-headings and
then insert the appropriate
   sub sub-headings underneath. The suggested two sub headings
could be:
  7.1  Legacy nodes behavior due to changes in this draft
  7.2  Backward compatibility with legacy devices


**  Change in 6CIO format
Please Add RFC 7400 related changes section here. I'd actually prefer a
meaningful heading on RFC 7400
changes rather than " Extending RFC7400"

** Privacy
   Please add a section on 'Privacy Considerations' for 6LoWPAN address
configuration. We can take a look
   at 6loBAC document or RFC 7668 and RFC 8105 and Privacy consideration
RFC 8065 to form a text
   to provide guidance on privacy compliant and temporary address formation
pros and cons here.
   We should use a short parapgraph and point to the relevnt sections of
relevant documents here.



Section 8: Security Connsiderations:

   "As indicated in section Section 2, this protocol does not aim at
   limiting the number of IPv6 addresses that a device can form, either.
   A host should be able to register any address that is topologically
   correct in the subnet(s) advertised by the 6LR/6LBR."

==> Should this document add a one line that the implmentation may consider
limiting registration requests by using different techniques.

   On the other hand, the registration mechanism may be used by a rogue
   node to attack the 6LR or the 6LBR with a Denial-of-Service attack
   against the registry.  It may also happen that the registry of a 6LR
   or a 6LBR is saturated and cannot take any more registration, which
   effectively denies the requesting a node the capability to use a new
   address.  In order to alleviate those concerns, Section 5.6 provides
   a number of recommendations that ensure that a stale registration is
   removed as soon as possible from the 6LR and 6LBR.

===> Does the recommendation in 5.6 alleviate the DOS attack in 6LR and
6LBR?
 The above paragraph is scary. If 5.6 recommendations are useful against
 DOS attack, we must have stronger statement in security.

 Let us revisit the security section and see if we can make it less
vulnerable.


*** Add a section " Example scenario of EARO":
  Here, a section can be added to point to the BBR scenario and proxy
ND operation.
   The text should be only a flavor to provide ideas [ < 10 lines or so
]


On Mon, May 1, 2017 at 11:45 PM,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IPv6 over Networks of
> Resource-constrained Nodes of the IETF.
>
> Title   : An Update to 6LoWPAN ND
> Authors : Pascal Thubert
>   Erik Nordmark
>   Samita Chakrabarti
> Filename: draft-ietf-6lo-rfc6775-update-04.txt
> Pages   : 29
&g

[6lo] Call for comments on requirements: draft-ietf-6lo-rfc6775-update

[Samita Chakrabarti]

Hello  6lo Colleagues:

Please read the 6lo-rfc6775-update draft.

The initial work started by Pascal by documenting requirements updates that
he
experienced during the LLN work on 6lowpan and 6tisch.

The draft will move to LC soon. If there are some more
requirements or valid concerns on backward compatibility with RFC 6775,
please review the document carefully after the next revision and post your
comments.

Thanks,
-Samita

On Mon, May 1, 2017 at 11:45 PM,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IPv6 over Networks of
> Resource-constrained Nodes of the IETF.
>
> Title   : An Update to 6LoWPAN ND
> Authors : Pascal Thubert
>   Erik Nordmark
>       Samita Chakrabarti
> Filename: draft-ietf-6lo-rfc6775-update-04.txt
> Pages   : 29
> Date: 2017-05-01
>
> Abstract:
>This specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to
>clarify the role of the protocol as a registration technique,
>simplify the registration operation in 6LoWPAN routers, and provide
>enhancements to the registration capabilities, in particular for the
>registration to a Backbone Router for proxy ND operations.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6lo-rfc6775-update/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-6lo-rfc6775-update-04
> https://datatracker.ietf.org/doc/html/draft-ietf-6lo-rfc6775-update-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-rfc6775-update-04
>
>
> 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/
>
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] Request for IETF99@Prague 6lo Agenda items

[Samita Chakrabarti]

Hello 6lo WG:

It is the time again for requesting agenda items for Prague IETF meeting.
We have requested  for 2 hour slot this time.

Please send your requests for 6lo agenda items by June 23rd (6-23-2017).
The preliminary IETF agenda will be published around mid-June.

As always please include the following in your request and send the request
to both the chairs.

Draft-name:
Brief summary of description:
Name of presenter:
Purpose of the presentation/discussion:

Cheers,
-Samita
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] Recent RFCs

[Samita Chakrabarti]

FYI:

Congratulations to co-authors, reviewers, shepherds and all involved in
publication of the following new documents since last IETF!

IEEE 802.15.4 Information Element for the IETF - RFC 8137 [ non-WG item ]
Transmission of IPv6 over MS/TP networks - RFC 8163
Transmission of IPv6 over DECT-ULE -  RFC 8105

Thanks to our AD, Suresh as well!
-Samita & Gabriel
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] Review Request for ipv6-over-nfc-07

[Samita Chakrabarti]

Hello Dave, Pascal, James and WG members:

ipv6-over-nfc-07 has just been published and the author mentions that he
had addressed the comments from Pascal and Dave.

 Pascal and Dave,  would you please have sometime to review version 07 to
check if your comments are addressed?

I have appended the excerpt from IETF98 meeting minutes for your reference.
This document is due for WG LC if  it looks okay.

James, you are shepherd for NFC draft -- please let us know if you are okay
with the document's next step.

Thanks,
-Samita

As per IETF98 meeting minutes:


2 IPv6 over NFCYounghwan Choi

  https://tools.ietf.org/wg/6lo/draft-ietf-6lo-nfc-06 was presented by
Younghawn Choi on updates and
  discussed comments from WG and NFC forum. The draft was reviewed by NFC
forum, no more comments
  from NFC forum. The author likes to move to WGLC.

  Dave Thaler:IID generation changed as a result of previous meeting

  Pascal: Replacing 6 bit address with hashing function with fixed
parameters. Scanning is still
  easy. How is it different?
  YC: offset. Dave: offset should be random to add entropy, not predictable.
  Gabriel: offset may not be a right name. Nonce would be better.
  Samita: need reviewers before WGLC. Pascal, Dave, would you volunteer?
  Pascal will do the review and Dave agreed to review the final update.
===
-- Forwarded message --
From: 최영환 
Date: Sun, Jun 4, 2017 at 5:02 PM
Subject: RE: [6lo] Request for IETF99@Prague 6lo Agenda items
To: Samita Chakrabarti 
Cc: Gabriel Montenegro 


Hello Samita,



I’ve submitted the new version of ipv6-over-nfc (-07). The document is
ready for review.

Thanks.



Best regards,

Younghwan Choi
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Review Request for ipv6-over-nfc-07

[Samita Chakrabarti]

The diff file:

https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-nfc-07

-Samita

On Mon, Jun 5, 2017 at 5:15 PM, Samita Chakrabarti 
wrote:

>
>
> Hello Dave, Pascal, James and WG members:
>
> ipv6-over-nfc-07 has just been published and the author mentions that he
> had addressed the comments from Pascal and Dave.
>
>  Pascal and Dave,  would you please have sometime to review version 07 to
> check if your comments are addressed?
>
> I have appended the excerpt from IETF98 meeting minutes for your reference.
> This document is due for WG LC if  it looks okay.
>
> James, you are shepherd for NFC draft -- please let us know if you are
> okay with the document's next step.
>
> Thanks,
> -Samita
>
> As per IETF98 meeting minutes:
> 
>
> 2 IPv6 over NFCYounghwan Choi
>
>   https://tools.ietf.org/wg/6lo/draft-ietf-6lo-nfc-06 was presented by
> Younghawn Choi on updates and
>   discussed comments from WG and NFC forum. The draft was reviewed by NFC
> forum, no more comments
>   from NFC forum. The author likes to move to WGLC.
>
>   Dave Thaler:IID generation changed as a result of previous meeting
>
>   Pascal: Replacing 6 bit address with hashing function with fixed
> parameters. Scanning is still
>   easy. How is it different?
>   YC: offset. Dave: offset should be random to add entropy, not
> predictable.
>   Gabriel: offset may not be a right name. Nonce would be better.
>   Samita: need reviewers before WGLC. Pascal, Dave, would you volunteer?
>   Pascal will do the review and Dave agreed to review the final update.
> ===
> -- Forwarded message --
> From: 최영환 
> Date: Sun, Jun 4, 2017 at 5:02 PM
> Subject: RE: [6lo] Request for IETF99@Prague 6lo Agenda items
> To: Samita Chakrabarti 
> Cc: Gabriel Montenegro 
>
>
> Hello Samita,
>
>
>
> I’ve submitted the new version of ipv6-over-nfc (-07). The document is
> ready for review.
>
> Thanks.
>
>
>
> Best regards,
>
> Younghwan Choi
>
>
>
>
>
>
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] Presence at Prague IETF

[Samita Chakrabarti]

Hi all,
I will be joining remotely at Prague meeting this time while Gabriel will
be there in person.
I believe our secretary James W. will be there as well.
We will miss Ralph Droms this time as he blessed 6lo co-chairs to go
forward without a tech adviser guide.
Thanks to Ralph for holding our hands in early days of 6lo and afterwards
with technical advice!

Our AD Suresh will be at the meeting obviously.

If there is anyone else who might be interested in presenting remotely,
please let me know asap, so the chairs will make the request to meetecho.

I plan to be at Singapore IETF in person.

-Samita
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] Fwd: Cutoff date for requesting remote presentations support at IETF99

[Samita Chakrabarti]

If anyone plans to present remotely at 6lo, please make your request to me
by COB 7/12.

Thanks,
-Samita
-- Forwarded message --
From: Meetecho IETF support 
Date: Wed, Jun 28, 2017 at 8:00 AM
Subject: Cutoff date for requesting remote presentations support at IETF99
To: wgcha...@ietf.org


Dear chairs,

if you plan to have remote _presentations_ in Prague, you're kindly
requested to fill out the following form:

https://ietf99.conf.meetecho.com/index.php/Remote_presentations

*The cutoff date for remote presentations support requests is July 14.*

You can also check scheduled remote presentations here:

https://ietf99.conf.meetecho.com/list.php

Thanks,
the Meetecho team
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] IETF99 6lo Agenda has been uploaded

[Samita Chakrabarti]

https://datatracker.ietf.org/meeting/99/agenda/6lo/

Please take a look and let the chairs know if any modification is needed.

Thanks,
-Samita
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] Requesting for minute takers and jabber scribe

[Samita Chakrabarti]

Hello  All:

Please let 6lo-chairs know if you like to volunteer for minute taking and
jabber scribe.

Thanks a lot!
-Samita
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] Fragmentation discussion for scope determination

[Samita Chakrabarti]

Hi All:

The 6lo chairs like to start a discussion on the 6lo fragmentation
requirements and scope of work based on IETF98 interest  in the WG about
doing further work on  fragmentation.

We are soliciting input from the WG on your thoughts and experiences on
possible 6lowpan fragmentation issue over constrained node networks(6lo)
that we like to work on, in this group.

Based on your input and prior discussions at last IETF (Pascal and Carles),
the chairs will prepare a list of requirements to have a rough consensus
what we should be solving in this workgroup.

Best regards,
-Samita and Gabriel
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Comments of draft-jadhav-lwig-nbr-mgmt-policy-00

[Samita Chakrabarti]

Hi Zhen and Rahul:

Thanks for looping 6lo in the lwig-nbr-mgmt-policy draft discussions.

6lo WG, please review draft-jadhav-lwig-nbr-mgmt-policy  document for any
impact in 6lowpan-nd. Also it is a good place to discuss if anyone else is
aware of any alternative neighbor management methods.
Also please provide feedback for improving neighbor management from 6lo
perspective.

-Samita

On Thu, Jul 13, 2017 at 5:48 PM, Zhen Cao  wrote:

> Dear Rahul and co-authors,
>
> Many thanks for the hard work in contributing this draft to the lwig
> wg. (I am copying roll and 6lo since some discussion will be quite
> relevant)
>
> As I go through the document, I found essentially there are three
> types of different policies discussed:
> a. Trivial neighbor management (FCFS/LRU)
> b. advanced neighbor management (proactive and reactive)
> c. proposed ‘reservation based’ approach
>
> Logically I understand the shortcomings of the trivial approach,
> however in practice, how much this many impact the network stability
> is not convincing enough yet. (what’s the possible size of node
> density/mobility may be impacted? ).
>
> The discussion of reactive and proactive ways of managing the neighbor
> cache entries is helpful. The discussion about the proactive approach
> in Sec.2.5.2 quoted below has some pending relationship with RPL (if
> this is an acknowledged problem by ROLL WG).  Anyway this is something
> we need to discuss with the ROLL wg to see if this a need feature.
>
> Currently there is no standard way of signaling such neighbor cache
>space availability information.  RPL's DIO messages carry metric
>information and can be augmented with neighbor cache space as an
>additional metric.
>
> For the proposed reservation based approach,  I think this is quite a
> practical recommendation (if my concern about a. will be relaxed).
>
> I also found the Contiki RPL implementation has recently used a
> similar way in its rpl-nbr-policy. Shall we link the draft to the open
> source community to see if the document has provided additional help
> to the implementation? (or that’s already done given coauthors Simon
> and Joakim are both active contributors of Contiki)?
>
> Many thanks for discussion.
>
> Cheers,
> Zhen
>
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] FYI: Information Session about IOT app performance over Satellite (Monday@6pm)

[Samita Chakrabarti]

Maria Rita Palattella is  organising  an *Info session about an ongoing
project which she is leading: M2MSAT* (https://artes.esa.int/projects/m2msat
)
The project, funded by ESA, aims to analyse (both via simulations and in a
real test bed), *the performance of IoT application protocols* (*CoAP* and
MQTT) *when communicating over a satellite link*. IoT networks will be soon
integrated with terrestrial networks in the 5G scenarios, and it is
fundamental to design adaptation/improvement of IoT protocols not
originally designed with the satellite network constrains in mind (link
disruption, high packet loss, etc). The project is currently running
performance evaluation using simulators (OpenSAND, Californium CoAP, MQTT
Mosquito). And also setting up a testbed, where  they may collect IoT data
from OpenMote nodes, running 6TiSCH.
This could be of interest of multiple IOT related groups at IETF.

The information session will be held on *Monday July, 17th at 6pm*, in *Paris
Room (Lobby level, L)* in Hilton Hotel in Prague.

For details, please contact Maria Rita:
Senior R&T Associate
Department 'Environmental Research and Innovation' (ERIN)
Luxembourg Institute of Science and Technology (LIST)
41, rue du Brill
L-4422 Belvaux, Grand-duchy of Luxembourg
email: mariarita.palatte...@list.lu , tel: +352
275 888-5055
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] Route-over implementation on 6lowpan

[Samita Chakrabarti]

Hi Carsten,

You mentioned about an implementation that works on route-over for 6lowpan.

Do you have any pointer to that?

Any informational draft or white paper is good - please send that out to
the list.

Thanks,
-Samita
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] 6lowpan Fragmentation design team interest?

[Samita Chakrabarti]

Dear all:

At IETF99 6lo wg meeting 6lo-chairs discussed a few questions in order to
sense WG interests for further work on fragmentation - especially for
route-over topology.
The details charter for the design team will be finalized soon.
However, the 6lo-chairs are collecting names for the interested individuals
for the design team. We might need 4-5 person design team and prior
experience on packet forwarding is helpful.

We are requesting the following :
* Send your ideas to the list on what you want to see resolved by the
fragmentation design team

* If you have any prior experience on 6lowpan fragmentation work on
router-over or mesh-under please send information about it

Thanks,
Gabriel & Samita

Reference slides from today's session:

https://www.ietf.org/proceedings/99/slides/slides-99-6lo-wg-discussion-questions-on-6lo-fragmentation-work-and-scoping-01.pdf

https://www.ietf.org/proceedings/99/slides/slides-99-6lo-6lowpan-fragment-forwarding-in-route-over-multi-hop-topology-00.pdf
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Liaison statement received from ITU-T regarding a "Reference Model of IPv6 Addressing Plan for Internet of Things Deployment"

[Samita Chakrabarti]

Thanks Suresh, for sharing the information. It looks quite relevant to 6lo
WG workarea. We, 6lo-chairs will contact Scott and the ITU-T contact person
provided in the liaison note.
Will discuss with you on a separate email regarding the steps to connect.

-Samita

On Mon, Oct 2, 2017 at 7:53 PM, Suresh Krishnan 
wrote:

> Hi all,
>   The IETF has received a liaison statement from the ITU-T that their
> Study Group SG20 is inviting inputs from the IETF regarding a work item
> titled "Reference Model of IPv6 Addressing Plan for Internet of Things
> Deployment” and the deadline for providing inputs is 2018/01/28. The
> statement can be found at
>
> https://datatracker.ietf.org/liaison/1546/
>
> I have no further info and I am trying to get access to the referenced
> documents. I just want to provide a heads up while that is in process.
>
> Thanks
> Suresh
>
>
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] IETF100 6lo WG meeting agenda request

[Samita Chakrabarti]

Hello  WG:

6lo-office has requested  2-hr session for our working group meeting at
Singapore and we were granted the slot on Thursday, Nov 16th  afternoon,
local time:
 1330-1530  Afternoon Session I
Sophia  INT *** 6lo IPv6 over Networks of Resource-constrained
Nodes WG:


Now the co-chairs are requesting the agenda items with the following
information with your request:
Draft-name:
Brief description of the topic:
Presenter's name:
Requested time for presentation:
Purpose of the presentation:

Please send your request by Oct 31st to both  6lo-cha...@ietf.org + James (
j...@google.com).

Thank you.
-Samita
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] IETF 100 6lo WG agenda

[Samita Chakrabarti]

Hello 6lo WG:

We have uploaded the agenda based on the current requests.
Please take a look and let the co-chairs know about any changes or updates:
https://datatracker.ietf.org/meeting/100/materials/agenda-100-6lo/

Note: Please volunteer for being minute takers and jabber scribe... ; we
would also like new workgroup members to come forward and volunteer for
document reviews and active participation on the document review process.


Thanks,
-Samita

PS: As I am embarking on a new job, I will not be able to attend Singapore
unfortunately but hope to see you at the next one.
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Request for IETF101 London 6lo Agenda items

[samita . chakrabarti]

Hello 6lo members,

If you have not sent all your requests to the chairs already, please do so by, 
March 5th.
Please send your requests to both Gabriel and me.

Also, note that the draft submission deadline is on March 5th as well.

2018-03-05 (Monday): Internet Draft submission cut-off (for all drafts, 
including -00) by UTC 23:59

Thank you.
-Samita



  *   From: Gabriel Montenegro mailto:Gabriel.Montenegro@DOMAIN.HIDDEN>>
  *   To: lo <6lo at ietf.org<mailto:6lo@DOMAIN.HIDDEN>>
  *   Cc: Samita Chakrabarti mailto:samitac.ietf@DOMAIN.HIDDEN>>
  *   Date: Wed, 21 Feb 2018 18:16:19 +
  *   List-id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 
over constrained node networks." <6lo.ietf.org>


Folks,

This is our time slot per the initial draft agenda (so it could change, of 
course):

THURSDAY, March 22, 2018
1330-1530 Afternoon Session I
Buckingham INT 6lo IPv6 over Networks of Resource-constrained Nodes WG

Please send the co-chairs your requests.

Gabriel


___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] 6lo WG meeting agenda has been uploaded

[Samita Chakrabarti]

Hello All,
Please take a look at the agenda  at
https://datatracker.ietf.org/meeting/101/materials/agenda-101-6lo

Please let the chairs know if any modifications needed.

Thanks,
-Samita
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] Fwd: T2TRG hosted side meeting on network coexistence (Mon 17:30-18:00, Waterloo)

[Samita Chakrabarti]

-- Forwarded message --
From: "Ari Keränen" 
Date: Mar 15, 2018 9:17 AM
Subject: Fwd: T2TRG hosted side meeting on network coexistence (Mon
17:30-18:00, Waterloo)
To: "roll-cha...@ietf.org" , "6lo-cha...@ietf.org" <
6lo-cha...@ietf.org>, "6tisch-cha...@ietf.org" <6tisch-cha...@ietf.org>, "
lpwan-cha...@ietf.org" 
Cc: "L M Feeney" , "Carsten Bormann" <
c...@tzi.org>

Hi Chairs,

The T2TRG hosted side meeting about network coexistence may also be
interesting to your WGs (see below). If appropriate, feel free to forward
to your mailing lists.


Thanks,
Ari

> Begin forwarded message:
>
> From: Ari Keränen 
> Subject: T2TRG hosted side meeting on network coexistence (Mon
17:30-18:00, Waterloo)
> Date: 15 March 2018 at 15.09.22 EET
> To: "t2...@irtf.org" 
> Cc: L M Feeney 
>
> T2TRG is hosting a side meeting on "network coexistence and coordination"
17:30-18:00 on Monday March 19th in the IETF hotel meeting room
"Waterloo".  This discussion may also be of interest to roll, 6lo, 6tisch,
and lpwan WGs.
>
> The wireless environment for IoT/LPWAN/SmartFoo applications will consist
of many *administratively independent* networks operating in the same
location and sharing unlicensed spectrum.
>
> This leads to a couple of discussion points:
>
> 1) Recent results (ours and others) have shown that protocol-level
interactions between networks can significantly affect performance. More
generally, the community does not yet have a good sense of how to do
performance evaluation in dense, heterogeneous wireless environments.
>
> 2) Because there is no administrative relationship between networks,
there is no obvious way for them to explicitly coordinate their use of the
shared channel.  Can higher layer protocols contribute in some way?
>
> For more details, please see: https://tools.ietf.org/html/
draft-feeney-t2trg-inter-network-01
>
>
> Best regards,
> Laura & T2TRG chairs
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] 6lo session at IETF101 - request for minute takers and Jabber scribe

[samita . chakrabarti]

Dear fellow members:

As you know we are scheduled to meet at IETF101 on Thursday at  1:30 - 3:30 pm 
(room Buckingham) for the f2f session, we are therefore looking for volunteers 
for minute taking and jabber scribe.

Please send an email to 6lo-cha...@ietf.org if you 
like to volunteer for minute taking and jabber.
Thank you very much!

-Samita & Gabriel
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] Goodbye and Thanks to James Woodyatt

[samita . chakrabarti]

Hello 6lo-WG:

Gabe and I regret to let you know that James Woodyatt will no longer be our 
secretary for the working group as he has decided to move onto other 
responsibilities.

We like to thank James for his service, reviews of documents and contributions 
to the 6lo WG, and wish him best of luck !

James, however promised to continue shepherding NFC WG document - so NFC 
authors should reach out to James if you need any advice on the document.

Best regards,
-Samita
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] IETF 101 6lo WG presentations

[samita . chakrabarti]

Hello presenters:

Please make sure to send your presentations to 
6lo-cha...@ietf.org  by Tuesday (3/20) noon, London 
time.

That will give us enough time to upload and browse through the slides.

Please, submit your presentations on-time.

Sincerely,
Your friendly co-chairs.
(Gabriel and Samita)



___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Status of draft-ietf-6lo-blemesh-02

[Samita Chakrabarti]

Thank you Carles for the implementation update of BLEmesh.
Great work in finding out and sharing the ble existing base implementations
pros and cons. That is helpful for 6lo wg and it is good to know that
Contiki now supports RFC 7668.
 -Samita





On Mar 16, 2018 4:38 AM, "Carles Gomez Montenegro" 
wrote:

Dear WG,

We would like to provide a short report on the status and our activities
related with draft-ietf-6lo-blemesh-02.

As you may recall, while we believe the document to be ready, we wanted to
implement it before proceeding further.

We had planned to implement the draft based on Raspberry Pi devices and
BlueZ. We actually enabled an RFC 7668 scenario with one device as a
master (or a 6LBR), another one as a slave (or a 6LN), and even IPv6-based
communication between the 6LN and a non-BLE interface of the 6LBR was
working well.

However, when we tried to increase the number of 6LNs per 6LBR, we
encountered the issue that communication between the 6LBR and the already
existing 6LN stopped working.

It appears that several concurrent BLE connections are not handled
correctly with BlueZ. This is a problem other people have found, and as
per the BlueZ mailing list, there is not a currently known solution.

Fortunately, we have found another basis for our implementation. Recently,
the BLEach open implementation of RFC 7668 (based on Contiki and CC2650
devices) was released (http://spoerk.github.io/contiki). It is promising,
as in fact results are shown by BLEeach authors on a scenario with one
6LBR and several 6LNs. We are currently in the process of enabling the RFC
7668
scenario based on this platform, and then we plan to modify/extend the
code in order to implement our draft.

Our plan is to have a first prototype implementation by IETF 102
(Montreal), and request to give a report in the 6Lo session of that
meeting.

Meanwhile, please let us know whether you have any comments on the draft.
And, of course, any feedback from implementation experience will be very
much appreciated!

(Note: when the I-D submission tool reopens, we will upload a new version
of the draft as "a refresher".)

Thanks!

Carles, Mahdi, Teemu

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] 6lo plugtest: some materials

[Samita Chakrabarti]

Hi Alain,
Will you be able to post a report of the plugtest at 6lo mailing list or
prepare a few slides for 5min report on our Thursday 6lo meeting?
Thanks,
-Samita


On Wed, Mar 14, 2018, 7:02 PM Alain Ribault 
wrote:

> Dear all,
>
> Here are some materials in advance to give you ideas about the 6lo
> plugtest we'll organize during the hackathon:
> - The 6lowpan testsuite and test environment description:
> http://doc.f-interop.eu/interop/#test-description
> - A video describing how to do the tests: https://youtu.be/3sz3XJC2F0o.
> Of course, we'll help during the plugtest.
>
> Our objectives are to gather your feedbacks in order to take into account
> your new needs and to improve the testing tools.
>
> An I recall that you can register your participation in the doodle
> https://doodle.com/poll/z4bcptmtqdpbbker.
>
> See you on Saturday and Sunday.
>
> Regards,
>
> Alain.
>
>
> Alain Ribault
> Directeur Technique
>
> KEREVAL
> 4, Rue Hélène Boucher
> 35235 Thorigné-Fouillard
>
> Fixe : 0223204188
> Mobile : 0613895589
>
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Warren Kumari's No Objection on draft-ietf-6lo-rfc6775-update-16: (with COMMENT)

[samita . chakrabarti]

I am okay with the changes .

Thanks,
-Samita

From: 6lo [mailto:6lo-boun...@ietf.org] On Behalf Of Pascal Thubert (pthubert)
Sent: Tuesday, April 3, 2018 1:32 PM
To: Dave Thaler ; Warren Kumari ; The 
IESG 
Cc: 6lo-cha...@ietf.org; 6lo@ietf.org; draft-ietf-6lo-rfc6775-upd...@ietf.org; 
Gabriel Montenegro 
Subject: [E] Re: [6lo] Warren Kumari's No Objection on 
draft-ietf-6lo-rfc6775-update-16: (with COMMENT)

Thanks a bunch for clarifying, Dave :

Rev_17 just flew with:

In order to deploy this, network administrators MUST ensure that 6LR/6LBRs
in their network support the number and type of devices that can register to
them, based on the  number of IPv6 addresses that those devices require and
their address renewal rate and behavior.

I understand, then, that we are all OK with this : )

Take care,;

pascal





From: 6lo <6lo-boun...@ietf.org> On Behalf Of Dave 
Thaler
Sent: mardi 3 avril 2018 19:03
To: Pascal Thubert (pthubert) mailto:pthub...@cisco.com>>; 
Warren Kumari mailto:war...@kumari.net>>; The IESG 
mailto:i...@ietf.org>>
Cc: 6lo-cha...@ietf.org; Gabriel Montenegro 
mailto:gabriel.montene...@microsoft.com>>; 
draft-ietf-6lo-rfc6775-upd...@ietf.org;
 6lo@ietf.org
Subject: Re: [6lo] Warren Kumari's No Objection on 
draft-ietf-6lo-rfc6775-update-16: (with COMMENT)


> I'm somewhat uncomfortable with the uppercase MUST in:

> "A network administrator MUST deploy updated 6LR/6LBRs to support the

> number and type of devices in their network, ..." Having an uppercase

> MUST driving operators' design decisions stuff feels weird. I'd be

> perfectly fine with something like "In order to deploy this, network

> administrators MUST..." or "Network Administrators need to ensure that

> 6LR/6LBRs support the number and..."

>

[PT>] This MUST comes from rev-14, based on Dave Thaler's review 
(https://www.microsoft.com/en-us/research/uploads/prod/2017/05/draft-ietf-6lo-rfc6775-update-11.pdf)
 I'm not too keen on rolling back the uppercase, cc'ing Dave to validate.



My comment was about the use of lower case “should” which was ambiguous. I 
asked if you meant SHOULD or MUST.

I’m fine with any unambiguous answer.  Warren’s wordings above are fine, as is 
the one you ask about below.



What about:

"

In order to deploy this, network administrators MUST ensure that 6LR/6LBRs

in their network support the number and type of devices that can register 
to them,

based on the  number of IPv6 addresses that those devices require and their

   address  renewal rate and behavior.

"



Dave
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] 6lo minutes uploaded

[samita . chakrabarti]

https://datatracker.ietf.org/meeting/101/materials/minutes-101-6lo-00

Thanks to Dominique for taking the minutes. If anyone else also took minutes on 
etherpad, please let the chairs know.
If there is any modification need or you like add any missing pieces, please 
send the suggested text.

Thanks,
-Samita
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] Shepherd's comments on draft-ietf-6lo-nfc-09

[Samita Chakrabarti]

Hi Younghawn:

I have volunteered to take over the shepherding job for this document.

Here are my comments:
Please update -10 with these comments. Let me know if you have any further
questions. Though the -09  draft might expire before the submission gate
opens in the IETF week, I believe you should not have issues to submit
version 10.
Let the chairs know if you do have issues for submission of the next
revision.

Thanks,
-Samita
[CC at my work email  for quick attention ]
--Comments

Section 3.2: 2nd para: "an IPv6 packet SHALL be"  -- why SHALL? if this is
the mandate this document
 requires for implementing the draft -- SHALL should be
replaced by "MUST"
Section 3.4: Typo in the first line - s /an IPv6 packet SHALL passed down/
an IPv6 packet MUST be passed down/

 Please refer to RFC 2119 for when to use MUST, SHOULD  and MAY
 Please check all SHALL references in this section (3.4) and
throughout the document to
 appropriately mandate them as per RFC 2119 [i,e if these are
specificed in this document for
 the first time].

 Comment: Use this text for clarification --
   'default MTU value is 128 bytes when no MIUX parameter is
 transmitted by the  NFC LLC layer'.

 CURRENT TEXT:
  Otherwise, the MTU size in NFC LLCP SHALL calculate the MIU
value as follows:

  MIU = 128 + MIUX.

   When the MIUX parameter is encoded as a TLV, the TLV Type
field SHALL
   be 0x02 and the TLV Length field SHALL be 0x02.  The MIUX
parameter
   SHALL be encoded into the least significant 11 bits of the
TLV Value
   field.  The unused bits in the TLV Value field SHALL be set
to zero
   by the sender and SHALL be ignored by the receiver.
However, a
   maximum value of the TLV Value field can be 0x7FF, and a
maximum size
   of the MTU in NFC LLCP is 2176 bytes.

 Samita's Comments:
 Otherwise, the MTU size in NFC LLCP SHOULD be calculated  from
the MIU value as follows: [ is this correct? Not clear from the draft what
is the relationship mapping between MTU and MIU - please clarify]

  MIU = 128 + MIUX.

  1) Clarify length of type and len fields. From the value
example (0x02), it appears
 that they are both 1 byte fields. THus the 0x02 value in
len field means the value
 length is always 2 bytes. Is this what is meant?
   2)  Please replace the SHALL to SHOULD or MUST appropriately
and then provide a min value
 and MAX val (0x7FF). Calculate the breakdown of MTU size
of NFC LLCP(2176 bytes) - does
 it include the 128 byte default value of MIU?

 Section 4.2:
   The last parapgraph in this section and section 4.8 seem to
indicate that this docuemnt
   recommends no FAR over NFC link for simplicity and thus
defines a MIUX extension to avoid
   any fragmentation and reassembly. But the text is very
ambiguous - this will surely create
   interoperability problem.

   I would suggest clarify the 3rd paragraph in section 4.2 and
also clarify section 4.8 that at
   the time of writing this document does NOT RECOMMEND using
FAR over NFC link due to
   simplicity of the protocol and implementation and the
implementation for this specification
   SHOULD (MUST?) use MIUX extension to communicate the MTU of
the link to the peer as defined
   in section 4.2

 Section 4.5:

  Comment-1.
Current text:
Unless they are the same (e.g., different MTU, level of
remaining energy,
 connectivity, etc.)

Suggested text: When the NFC nodes are not of uniform
category (e.g., different MTU, level of remaining energy,
 connectivity, etc.)...
  Comment-2.
Current Text:
  Also, they MAY deliver their own information (e.g., MTU
  and energy level, etc.) to neighbors with NFC LLCP
protocols
  during connection initialization
Suggested Text ( with mandatory requirment for avoiding
FAR):
 Also, they MUST deliver their MTU information to neighbors
with NFC LLCP protocols
 during connection initialization. The router MAY also
communicate other capabilities
 which is out of scope of this document.

 Comment 3.

 Suggestion: Please check with RFC6775-update latest ( and
Pascal) to make sure that the update
 supoorts the NFC draft which is classic RFC 6775 compatible.

  Section 4.8:
   Re-word (if applicable) based on the comments above for
section 4.2

  S

Re: [6lo] An article on 6Lo

[Samita Chakrabarti]

Hi Carles,

Thanks so much for setting the example and spreading words about IETF 6lo
work.
Others, if you have any repository on the open implementations on 6lo
please let this wg know.

I plan to update the wikipedia page with some basic information on 6lo WG
plus documents and will request the WG to update accordingly.


Best regards,
-Samita

On Thu, Jul 5, 2018 at 12:44 AM, Carles Gomez Montenegro <
carle...@entel.upc.edu> wrote:

> Dear all,
>
> In the last IETF meeting, one of the topics discussed during the 6Lo WG
> session was promoting 6Lo.
>
> One thing that hopefully may contribute in this regard is an article we
> published few months ago in IEEE Communications Magazine:
>
>   C. Gomez, J. Paradells, C. Bormann, J. Crowcroft, "From 6LoWPAN to 6Lo:
>   Expanding the Universe of IPv6-Supported Technologies for the Internet of
>   Things", IEEE Communications Magazine, Vol. 55, Issue 2, Dec 2017,
>   pp. 148-155.
>
> The IEEE link to the article is:
> https://ieeexplore.ieee.org/document/8198820
>
> For folks that do not have access to IEEE, a preprint can be found here:
> https://www.researchgate.net/publication/318472017_From_
> 6LoWPAN_to_6Lo_Expanding_the_Universe_of_IPv6-Supported_
> Technologies_for_the_Internet_of_Things
>
> We hope this can be useful to the community.
>
> Cheers,
>
> Carles
>
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] Presentation slides for 6lo

[Samita Chakrabarti]

Hi 6lo wg presenters:
Your slides are due by Mon noon, ET in order for the chairs to prepare for
the meeting.

Thanks to those who already submitted their slides.
-Samita
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] Looking for minute takers + jabber scribe

[Samita Chakrabarti]

Hello all:
Tomorrow we have 6lo session at 1:30p in Duluth.

Still looking for minute takers and a jabber scribe. Please volunteer.

Thanks,
-Samita
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] A short WGLC for https://tools.ietf.org/html/draft-ietf-6lo-nfc-10

[Samita Chakrabarti]

Recently for clarity, this document has changed "SHALL" to  "MUST", SHOULD
etc. -- please review them carefully ( as per RFC2119) and  provide your
feedback in the list, if any.  This short WGLC ends on 30th July, 2018.
https://tools.ietf.org/html/draft-ietf-6lo-nfc-10


Thanks,
-Samita & Gabriel
(6lo co-chairs)
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] FW: [E] Re: working group last call (wg lc) on https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/

[Samita Chakrabarti]

Hi Lijo,

Thanks for your response and clarifications. Will wait for your new
revision of the draft.
Please see in-line.

On Sat, Aug 4, 2018 at 6:07 PM Lijo Thomas  wrote:

>
> Hi Samita,
>
> Thanks for your valuable comments. Please find our replies  (***[LT]  ) 
> inline to your queries (below mail).
>
> Happy to receive your further inputs.
>
> Thanks & Regards
> Lijo Thomas
>
>
> Posting again…
>
> From: Chakrabarti, Samita
> Sent: Tuesday, July 31, 2018 6:32 PM
> To: 'Lijo Thomas'  ;; 'Georgios Z. 
> Papadopoulos'  
> ;
> Cc: draft-ietf-6lo-deadline-t...@ietf.org; an...@ece.iisc.ernet.in; 'Malati 
> Hegde'  ;; 'Samita 
> Chakrabarti'  ;; 'Gabriel 
> Montenegro'  
> ;; 'lo' <6lo@ietf.org> 
> <6lo@ietf.org>>;; 'Charlie Perkins'  
> ;; satishnaid...@gmail.com
> Subject: RE: [E] Re: [6lo] working group last call (wg lc) on 
> https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/Hi Lijo and 
> co-authors:
>
> Here are some more comments on the 6lo-deadline draft:
>
>
> 1.   The abstract of this document says :
>“The deadline time enables forwarding and scheduling decisions for time 
> critical
>IoT M2M applications that need deterministic delay guarantees over
>constrained networks and operate within time-synchronized networks.”
>
> However, the document body seems to indicate that the solution works for 
> 6tisch networks.
> Could this document clarify  where this scenario be applicable?  Only 6tisch 
> or any other Low-power networks with multiple hops?
> 6loRH is a requirement here – so please clarify a typical deployment network 
> where this solution will work [ for example, a Low power network running RPL 
> with 6loRH support on 6lo nodes that create the mesh networks..]
>
> ***[LT] : The scope of the draft is generic so that it can be used in any
> time synchronized 6Lo network, not restricted to 6TiSCH alone. 6TiSCH has
> been used to describe the implementation aspects of the draft as it is
> indeed an instantiation of such a time synchronized 6lo network.
>
>  The draft does not preclude its use in scenarios other than 6TiSCH - for
> instance, 6lo over a BLE mesh network, where there is a growing interest in
> using this technology in industrial IoT. From the academic research side, a
> recent publication titled "Multi-Hop Real-Time Communications Over
> Bluetooth Low Energy Industrial Wireless Mesh Networks" (
> https://ieeexplore.ieee.org/abstract/document/8355905/) indicates the
> interest in this topic. BLE mesh time synchronization is also being
> recently explored by the community. We can also consider using the
> time-zone procedures described to meet packet deadlines.
>
>  Given the above use cases, 6lo for BLE and in particular BLE mesh are
> potential customers of our draft.  But there are other cases under
> consideration in, for instance, Wi-SUN.
>

Samita>  OK please clarify the scope in the abstract and introduction
sections.

>
> 2.   Section 3 – Drop this section and refer to RFC8138 section 4.1
> ***[LT] :  We will remove it.
>
>
> 3.   Always provide Normative reference to 6rLoRHE as 6LoRHE[RFC8138] 
> when you refer to it
>
> ***[LT] :  Yes we agree, will do in the next revision.
>
>
> 4.   Section 4 : the calculation is not clear to me as to how it relates 
> the new network clock difference (delta) and the delay in the previous 
> network ( at the entry point of the new network). Please draw a time line 
> diagram and explain  each point what this value is for and how the delay 
> experienced is calculated.  If your reference time for first network is T1, 
> and the second network clock is T1+d  and the dealy in T1 is D1, then at 
> T1+D1 time, when the packet enters the 2nd network, it will read T1+D1+d1 as 
> the 2nd network entry time or origination time in 2nd network. Second network 
> may add some delay in processing the packet. So, I am not clear what is the 
> purpose of this section. Please clarify.
> ***[LT] : Great suggestion, we will try to put a graph and probably an 
> example to provide more clarity.
>
> Thanks!

>
> 5.   Section 6.2 refers to ietf-ippm-ioam-data – does it have dependency 
> on this draft? What if the border router does not support the ippm draft?  
> Not sure if I understand the assumption that “It encodes the deadline time 
> (and, if available, the origination time) into the In-band OAM header 
> extension and passes the datagram to the IPv6 layer for further routing…”   
> Please clarify or drop this scenario.
>
> ***[LT] :Our draft is not depending on the ioam draft, we will try to remove 
>

[6lo] Publication has been requested for draft-ietf-6lo-nfc-10

[Samita Chakrabarti]

Samita Chakrabarti has requested publication of draft-ietf-6lo-nfc-10 as 
Proposed Standard on behalf of the 6LO working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] I-D Action: draft-ietf-6lo-deadline-time-02.txt

[Samita Chakrabarti]

Thanks Lijo, for the update.
-Samita

On Fri, Aug 31, 2018 at 6:00 AM Lijo Thomas  wrote:

> Hi all,
>
> Published a new version -02 of our  draft
> which addressed the review comments from Georgios and Samita.
>
> Will be happy to receive your feedback and further inputs ...
>
> https://tools.ietf.org/html/draft-ietf-6lo-deadline-time-02
>
>
> Thanks & Regards,
> Lijo Thomas
>
> -Original Message-
> From: 6lo [mailto:6lo-boun...@ietf.org] On Behalf Of
> internet-dra...@ietf.org
> Sent: 31 August 2018 14:48
> To: i-d-annou...@ietf.org
> Cc: 6lo@ietf.org
> Subject: [6lo] I-D Action: draft-ietf-6lo-deadline-time-02.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IPv6 over Networks of Resource-constrained
> Nodes WG of the IETF.
>
> Title   : Packet Delivery Deadline time in 6LoWPAN Routing
> Header
> Authors : Lijo Thomas
>   Satish Anamalamudi
>   S.V.R Anand
>   Malati Hegde
>   Charles E. Perkins
> Filename: draft-ietf-6lo-deadline-time-02.txt
> Pages   : 15
> Date: 2018-08-31
>
> Abstract:
>This document specifies a new type for the 6LoWPAN routing header
>containing the delivery deadline time for data packets.  The deadline
>time enables forwarding and scheduling decisions for time critical
>IoT M2M applications that need deterministic delay guarantees over
>constrained networks and operate within time-synchronized networks.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-6lo-deadline-time-02
> https://datatracker.ietf.org/doc/html/draft-ietf-6lo-deadline-time-02
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-deadline-time-02
>
>
> 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/
>
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>
>
>
> 
> [ C-DAC is on Social-Media too. Kindly follow us at:
> Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]
>
> This e-mail is for the sole use of the intended recipient(s) and may
> contain confidential and privileged information. If you are not the
> intended recipient, please contact the sender by reply e-mail and destroy
> all copies and the original message. Any unauthorized review, use,
> disclosure, dissemination, forwarding, printing or copying of this email
> is strictly prohibited and appropriate legal action will be taken.
>
> 
>
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] I-D Action: draft-ietf-6lo-deadline-time-02.txt

[Samita Chakrabarti]

Hi Lijo and co-authors,

Are you aware of any IPR involving the method described in the 6lo-deadline
draft?

If yes, please record the IPR at
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-6lo-deadline-time
as soon as possible. Shepherd writeup will wait for the  confirmation from
your side.

Thanks,
-Samita

On Fri, Aug 31, 2018 at 6:00 AM Lijo Thomas  wrote:

> Hi all,
>
> Published a new version -02 of our  draft
> which addressed the review comments from Georgios and Samita.
>
> Will be happy to receive your feedback and further inputs ...
>
> https://tools.ietf.org/html/draft-ietf-6lo-deadline-time-02
>
>
> Thanks & Regards,
> Lijo Thomas
>
> -Original Message-
> From: 6lo [mailto:6lo-boun...@ietf.org] On Behalf Of
> internet-dra...@ietf.org
> Sent: 31 August 2018 14:48
> To: i-d-annou...@ietf.org
> Cc: 6lo@ietf.org
> Subject: [6lo] I-D Action: draft-ietf-6lo-deadline-time-02.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IPv6 over Networks of Resource-constrained
> Nodes WG of the IETF.
>
> Title   : Packet Delivery Deadline time in 6LoWPAN Routing
> Header
> Authors : Lijo Thomas
>   Satish Anamalamudi
>   S.V.R Anand
>   Malati Hegde
>   Charles E. Perkins
> Filename: draft-ietf-6lo-deadline-time-02.txt
> Pages   : 15
> Date: 2018-08-31
>
> Abstract:
>This document specifies a new type for the 6LoWPAN routing header
>containing the delivery deadline time for data packets.  The deadline
>time enables forwarding and scheduling decisions for time critical
>IoT M2M applications that need deterministic delay guarantees over
>constrained networks and operate within time-synchronized networks.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-6lo-deadline-time-02
> https://datatracker.ietf.org/doc/html/draft-ietf-6lo-deadline-time-02
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-deadline-time-02
>
>
> 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/
>
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>
>
>
> 
> [ C-DAC is on Social-Media too. Kindly follow us at:
> Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]
>
> This e-mail is for the sole use of the intended recipient(s) and may
> contain confidential and privileged information. If you are not the
> intended recipient, please contact the sender by reply e-mail and destroy
> all copies and the original message. Any unauthorized review, use,
> disclosure, dissemination, forwarding, printing or copying of this email
> is strictly prohibited and appropriate legal action will be taken.
>
> 
>
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] I-D Action: draft-ietf-6lo-deadline-time-02.txt

[Samita Chakrabarti]

Hi Co-authors and Lijo:

The draft 6lo-deadline-time v02 describes in the IANA section (section 6)
that a value of new 6loRH header type to be defined. But it is not clear
whether this will be assigned from the critical or elective part of 6loRH
type or both.
Please clarify that in the next version of the document.

Thanks,
-Samita


On Mon, Sep 3, 2018 at 1:33 PM Samita Chakrabarti 
wrote:

> Hi Lijo and co-authors,
>
> Are you aware of any IPR involving the method described in the
> 6lo-deadline draft?
>
> If yes, please record the IPR at
> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-6lo-deadline-time
> as soon as possible. Shepherd writeup will wait for the  confirmation from
> your side.
>
> Thanks,
> -Samita
>
> On Fri, Aug 31, 2018 at 6:00 AM Lijo Thomas  wrote:
>
>> Hi all,
>>
>> Published a new version -02 of our  draft
>> which addressed the review comments from Georgios and Samita.
>>
>> Will be happy to receive your feedback and further inputs ...
>>
>> https://tools.ietf.org/html/draft-ietf-6lo-deadline-time-02
>>
>>
>> Thanks & Regards,
>> Lijo Thomas
>>
>> -Original Message-
>> From: 6lo [mailto:6lo-boun...@ietf.org] On Behalf Of
>> internet-dra...@ietf.org
>> Sent: 31 August 2018 14:48
>> To: i-d-annou...@ietf.org
>> Cc: 6lo@ietf.org
>> Subject: [6lo] I-D Action: draft-ietf-6lo-deadline-time-02.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the IPv6 over Networks of
>> Resource-constrained
>> Nodes WG of the IETF.
>>
>> Title   : Packet Delivery Deadline time in 6LoWPAN Routing
>> Header
>> Authors : Lijo Thomas
>>   Satish Anamalamudi
>>   S.V.R Anand
>>   Malati Hegde
>>   Charles E. Perkins
>> Filename: draft-ietf-6lo-deadline-time-02.txt
>> Pages   : 15
>> Date: 2018-08-31
>>
>> Abstract:
>>This document specifies a new type for the 6LoWPAN routing header
>>containing the delivery deadline time for data packets.  The deadline
>>time enables forwarding and scheduling decisions for time critical
>>IoT M2M applications that need deterministic delay guarantees over
>>constrained networks and operate within time-synchronized networks.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-6lo-deadline-time-02
>> https://datatracker.ietf.org/doc/html/draft-ietf-6lo-deadline-time-02
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-deadline-time-02
>>
>>
>> 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/
>>
>> ___
>> 6lo mailing list
>> 6lo@ietf.org
>> https://www.ietf.org/mailman/listinfo/6lo
>>
>>
>>
>> 
>> [ C-DAC is on Social-Media too. Kindly follow us at:
>> Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]
>>
>> This e-mail is for the sole use of the intended recipient(s) and may
>> contain confidential and privileged information. If you are not the
>> intended recipient, please contact the sender by reply e-mail and destroy
>> all copies and the original message. Any unauthorized review, use,
>> disclosure, dissemination, forwarding, printing or copying of this email
>> is strictly prohibited and appropriate legal action will be taken.
>>
>> 
>>
>> ___
>> 6lo mailing list
>> 6lo@ietf.org
>> https://www.ietf.org/mailman/listinfo/6lo
>>
>
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] Publication has been requested for draft-ietf-6lo-deadline-time-02

[Samita Chakrabarti]

Samita Chakrabarti has requested publication of draft-ietf-6lo-deadline-time-02 
as Proposed Standard on behalf of the 6LO working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] FYI - 6lo in IOT@IETF blog

[samita . chakrabarti=40verizon . com]

Please check out 
https://www.internetsociety.org/blog/2018/03/rough-guide-ietf-101-internet-things/
for IOT happenings at IETF101.

-Samita
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] 6lo Agenda uploaded for IETF 102

[samita . chakrabarti=40verizon . com]

Hello 6lo group,
Greetings!

https://datatracker.ietf.org/meeting/102/materials/agenda-102-6lo-00

Please take a look at the uploaded agenda and make sure your requests are 
properly noted.
For any changes, updates please send a note to 6lo-chairs.

Thanks!
-Samita

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] 6lo WG meeting - Call for minute taker and jabber scribe

[samita . chakrabarti=40verizon . com]

Hello 6lo:

It's that time again to request help on minute taking and jabber scribe...
Dominique always extends his help in minute taking and the co-chairs really 
appreciate that.

Multiple minute takers are always welcome and the jabber scribe gets a star :)

Thanks,
Samita & Gabriel
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] [E] Looking for minute takers + jabber scribe

[samita . chakrabarti=40verizon . com]

Hi Ryan,

Thank you very much for volunteering for minute taking.

We usually ask the minute takers to use the Etherpad for minute takers.
-Samita

From: 6lo [mailto:6lo-boun...@ietf.org] On Behalf Of Ryan Hu
Sent: Monday, July 16, 2018 3:18 PM
To: Samita Chakrabarti 
Cc: lo <6lo@ietf.org>
Subject: [E] [6lo] Looking for minute takers + jabber scribe

Hi Samita,

I’ll attend tomorrow’s 6lo session and I’d like to be a volunteer minute taker. 
Please feel free to send me some guidelines if possible.

Thanks,
Ryan Hu


> On Jul 16, 2018, at 3:01 PM, Samita Chakrabarti 
> mailto:samitac.i...@gmail.com>> wrote:
>
> Hello all:
> Tomorrow we have 6lo session at 1:30p in Duluth.
>
> Still looking for minute takers and a jabber scribe. Please volunteer.
>
> Thanks,
> -Samita
> ___
> 6lo mailing list
> 6lo@ietf.org<mailto:6lo@ietf.org>
> https://www.ietf.org/mailman/listinfo/6lo<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_6lo&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=pWMzx7FsqijEJPyfMBfn-HJss-wVVTf0K5y-cxCTXL8&m=ZIP_sfccMOXX9rzBMgoARmUtEY6cHCNn4xnWTGjyPOU&s=JoBrZtyjEPrA5q_7J2rjg6hBHe-IsqEKbhVC2Wmo1CA&e=>
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo