[Lwip] Agenda Call for IETF109 Online

[Zhen Cao]

Hi Everyone,

Please drop us a note if you need to present at the upcoming lwig
meeting, which will take place at:

Friday, November 20, 2020 UTC+7
14:30-15:30 Friday Session II

All the best,
Mohit & Zhen

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] IPR poll for draft-ietrf-lwig-tcp-constrained-node-networks-09

[Zhen Cao]

Dear Authors of draft-ietrf-lwig-tcp-constrained-node-networks,

Can each of the author/co-author confirm if any and all appropriate
IPR disclosures required for full conformance with the provisions of
BCP 78 and BCP 79 have already been filed for the most update version.

This is needed as part of shepherd writeup.

Many thanks,
Zhen

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] LWIG Agenda 00 published and still

[Zhen Cao]

Hi Folks,

The agenda of LWIG @ IETF 106 has been published.
https://datatracker.ietf.org/doc/agenda-106-lwig/

Let us know if you have any questions.

Cheers,
Mohit & Zhen

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Lwig session presentation slides

[Zhen Cao]

Dear Presenters,

Thank you very much for giving talks at the upcoming LWIG session on Friday.

Could you help send us slides of your talk if you have not done yet,
by Thursday evening.  I plan to upload the consolidated slides then.

Cheers,
Mohit 

Ref to LWIG Agenda:
--

2.  Carlos: TCP Usage Guidance in the Internet of Things (IoT) (10 min)
https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks

3.  Rahul: Neighbor Management Policy for 6LoWPAN  (10 min)
https://tools.ietf.org/html/draft-ietf-lwig-nbr-mgmt-policy

4.  Carsten: Virtual reassembly buffers in 6LoWPAN (10 min)
https://tools.ietf.org/html/draft-ietf-lwig-6lowpan-virtual-reassembly

5.  Olaf: CoAP Implementation Guidance (10 min)
https://tools.ietf.org/html/draft-ietf-lwig-coap-06

6.  Carsten/Ari: Terminology for Constrained-Node Networks (10 min)
https://tools.ietf.org/html/draft-bormann-lwig-7228bis-03

7.  Daniel: Minimal ESP (10 min)
https://tools.ietf.org/html/draft-mglt-lwig-minimal-esp-06

8.  Rene: Alternative Curve Representations (10 min)
https://tools.ietf.org/html/draft-struik-lwig-curve-representations-00

9.  Francesca: Comparison of CoAP Security Protocols (10 min)
https://tools.ietf.org/html/draft-ietf-lwig-security-protocol-comparison-01

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] 6LoWPAN Virtual Reassembly

[Zhen Cao]

Hi Carsten,

Thanks for the draft.  This is quite related to LWIG, and could you
present this draft at IETF 101 lwig session?  Would a 10-15 min slot
suffice?

Thanks and regards,
Zhen

On Fri, Jan 26, 2018 at 6:06 AM, Carsten Bormann  wrote:
> I finally wrote up the last paragraph of Section 2.5.2 of the 6LoWPAN book:
>
> https://tools.ietf.org/html/draft-bormann-lwig-6lowpan-virtual-reassembly-00
>
> While the need for this document has been discussed in 6Lo, this is an 
> implementation technique (geared towards constrained implementations), so I 
> believe it ultimately should be discussed in LWIG.
>
> It is a short document.  Enjoy!
>
> Grüße, Carsten
>
> ___
> Lwip mailing list
> Lwip@ietf.org
> https://www.ietf.org/mailman/listinfo/lwip
On Fri, Jan 26,
2018 at 6:06 AM, Carsten Bormann mailto:c...@tzi.org; target="_blank">c...@tzi.org
wrote:I finally wrote up
the last paragraph of Section 2.5.2 of the 6LoWPAN book:

https://tools.ietf.org/html/draft-bormann-lwig-6lowpan-virtual-reassembly-00;
data-saferedirecturl="https://www.google.com/url?hl=enq=https://tools.ietf.org/html/draft-bormann-lwig-6lowpan-virtual-reassembly-00source=gmailust=1520918396356000usg=AFQjCNHmEkuAlEl6ICx-lk9HObrLxbaWfQ;
rel="noreferrer"
target="_blank">https://tools.ietf.org/html/draft-bormann-lwig-6lowpan-virtual-reassembly-00

While the need for this document has been discussed in 6Lo, this is an
implementation technique (geared towards constrained implementations),
so I believe it ultimately should be discussed in LWIG.

It is a short document. Enjoy!

Grüße, Carsten

___
Lwip mailing list
mailto:Lwip@ietf.org;>Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip;
data-saferedirecturl="https://www.google.com/url?hl=enq=https://www.ietf.org/mailman/listinfo/lwipsource=gmailust=1520918396356000usg=AFQjCNGQWmOprG_dkQTPccdaA1K46lHLlQ;
rel="noreferrer"
target="_blank">https://www.ietf.org/mailman/listinfo/lwip


___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] Intdir early review of draft-ietf-lwig-crypto-sensors-04

[Zhen Cao]

Hi Tim,

Thank you again for reviewing this document, and a very happy new year
of 2018 :)

Could you help review the update according to Mohit's update and see
if you have further concerns? so that as shepherd I can see if I can
move it further.

Many thanks and regards,
Zhen

On Tue, Dec 26, 2017 at 12:49 AM, Mohit Sethi
 wrote:
> Dear Tim,
>
> Thanks for the detailed review and positive comments. We have now submitted
> an updated version which can be found here:
> https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-05. The diff from
> the previous version can be found here:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-crypto-sensors-05.
>
> Please find our responses to your specific comments inline. Let us know if
> the modifications are not sufficient.
>
> --Mohit
>
> On 10/30/2017 12:03 AM, Tim Chown wrote:
>>
>> Reviewer: Tim Chown
>> Review result: Ready
>>
>> Hi,
>>
>> This Informational draft describes the challenges in securing
>> resource-constrained smart object / IoT devices, documenting the
>> associated
>> tradeoffs, and discussing the availability of appropriate cryptographic
>> libraries for such devices.
>>
>> I have reviewed this document, and overall find it generally ready for
>> publication, though I have some minor nits / comments for consideration
>> below;
>> these are just suggested changes / improvements, and I would not object
>> strongly if all were ignored.
>>
>> General comments:
>>
>> The document is very easy and enjoyable to read, and the quality of the
>> writing
>> is very good.  The authors have clear expertise in the field.
>>
>> It may be worth considering teasing apart the evaluation and the
>> architectural
>> aspects of the document; these are somewhat interwoven as currently
>> written.
>>
>> Related, there are some rather nice recommendations made throughout the
>> document; these could perhaps be summarised either at the start or perhaps
>> better the close of the document, e.g. on page 4 regarding selecting the
>> hardware after determining the security requirements for a device, and not
>> necessarily simply picking the most lightweight algorithm, or on page 7
>> regarding appropriate layers for tasks, or on page 9 regarding elliptic
>> curve
>> vs RSA, or on page 11 on real deployments using 32-bit microcontrollers,
>> or the
>> recommendation to the IETF community on page 14, or on planning for
>> firmware
>> updates on page 16, etc.
>
> We have now added a summary of important security recommendations from our
> implementation experience in section 9.
>>
>>
>> Comments by page:
>>
>> On page 5, in the first paragraph on provisioning, there is no hint of any
>> bootstrap process for identities; this follows later on page 6, but a hint
>> here, or just adding "as discussed on page 6 or in section x.y" might be
>> nice.
>>
>> Also on page 5, I'd be interested in seeing some brief text added on the
>> "remaining vulnerabilities" that are mentioned near the foot of the page.
>
> We have added new text here. "leap-of-faith or trust-on-first-use based
> pairing methods assume that the attacker is not present during the initial
> setup and are vulnerable to eavesdropping or man-in-the-middle (MitM)
> attacks."
>>
>>
>> On page 6, is it worth adding a little text on privacy somewhere?  We've
>> been
>> doing some work through Christian Huitema and Daniel Kaiser on anonymous
>> device
>> pairing in the DNSSD WG, and a similar requirement might be desirable in
>> some
>> scenarios here?
>
> Christian had provided detailed feedback on privacy and identifiers. To
> address this, we have added new text in section 3 (Challenges), section 4.1
> (Provisioning) and section 8.1 (Feasibility).
>>
>>
>> On page 7, having said earlier you should pick the hardware after
>> determining
>> requirements, you then decide to pick an Arduino platform and see what you
>> can
>> manage to run on it. I fully understand why (and I'd be equally curious),
>> but
>> you should probably clarify the "conflict" further.
>
> There was missing text here. We have now completed the sentence. "Our choice
> of a 8-bit platform may seem surprising since cheaper and more
> energy-efficient 32-bit platforms are available. However, our intention was
> to evaluate the performance of public-key cryptography on the smallest
> platforms available. It is reasonable to expect better performance results
> from 32-bit microcontrollers.
>>
>>
>> On page 12, would a little more detail on RNG requirements, esp. for
>> devices of
>> this type, be worthwhile?
>
> We have also added a pointer to RFC4086 that provides a detailed discussion
> on requirements and best practices for cryptographic-quality randomness.
>>
>>
>> On page 16, you're hardcoding the IP address?  Is it not possible to use
>> RD?
>> We've been comparing that and looking at interoperability with classic
>> DNSSD in
>> the DNSSD WG.
>
> The IP address of the resource-directory was hardcoded. The location of 

[Lwip] Minutes of IETF100

[Zhen Cao]

Hi Everyone,

Minutes of lwig session at IETF100 uploaded here:
https://datatracker.ietf.org/meeting/100/materials/minutes-100-lwig/

Let me know if you have any concern.

Thank Jaime a lot for taking the minutes, and crafting this ASCII art
of LWIG :)

Many thanks,
Mohit & Zhen

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] Lwig Session Agenda Update -Starting from 11am

[Zhen Cao]

Hi Folks,

To repeat, the lwig session will start from 11am this morning.

I came across some last night and realize that no all are aware of the
agenda update online.
See you soon.

Thanks,
Zhen

On Mon, Nov 13, 2017 at 4:13 PM, Zhen Cao <zhencao.i...@gmail.com> wrote:
> Hi All,
>
> Please be aware that the Lwig session on Wednesday will start from
> 11am till noon, and the printed agenda does not indicate that.
>
> The online agenda always has the ground truth.
> https://datatracker.ietf.org/meeting/100/agenda.html (You may have
> already received the email from the IETF Agenda.  )
>
> Here is the current version of the agenda.
>
> 11:00-12:00 Wednesday Morning session
> Room: Olivia
>
> 0. Agenda bashing 5 min
>
> 1.  TCP Usage Guidance in the Internet of Things (IoT)   Carles Gomez
> Montenegro  20min
> https://tools.ietf.org/wg/lwig/draft-ietf-lwig-tcp-constrained-node-networks/
>
>
> 2. Message Size Overhead of CoAP Security Protocols
> John Mattsson
> https://www.ietf.org/internet-drafts/draft-mattsson-core-security-overhead-02.txt
>  15min
>
> 3. Neighbor Management Policy  10 min
> Rahul A. Jadhav
> https://tools.ietf.org/html/draft-ietf-lwig-nbr-mgmt-policy
>
> Thanks,
> co-chairs

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Lwig Session Agenda Update

[Zhen Cao]

Hi All,

Please be aware that the Lwig session on Wednesday will start from
11am till noon, and the printed agenda does not indicate that.

The online agenda always has the ground truth.
https://datatracker.ietf.org/meeting/100/agenda.html (You may have
already received the email from the IETF Agenda.  )

Here is the current version of the agenda.

11:00-12:00 Wednesday Morning session
Room: Olivia

0. Agenda bashing 5 min

1.  TCP Usage Guidance in the Internet of Things (IoT)   Carles Gomez
Montenegro  20min
https://tools.ietf.org/wg/lwig/draft-ietf-lwig-tcp-constrained-node-networks/


2. Message Size Overhead of CoAP Security Protocols
John Mattsson
https://www.ietf.org/internet-drafts/draft-mattsson-core-security-overhead-02.txt
 15min

3. Neighbor Management Policy  10 min
Rahul A. Jadhav
https://tools.ietf.org/html/draft-ietf-lwig-nbr-mgmt-policy

Thanks,
co-chairs

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Agenda Call for Lwig@IETF100

[Zhen Cao]

Dear All,

Lwig is supposed to meet at  IETF100 for one hour.

Could you please let us know if you need to present any thing on this meeting?

Please include the following information: Title/Presenter/time/
goal.  Report from relevant opensource or hackathon events will be
welcome.

Cheers,
Mohit

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] Chair replacement for lwig

[Zhen Cao]

Thank you, Suresh for the message.

Thank you Robert, greatly appreciate all your contributions in making
Lwig a great place.  Wish you all the best for your challenges and
always welcome back home.

Thank you Mohit for accepting this role and welcome you on board, it
will be my great pleasure to work with you in the coming years.

Many thanks, all the contributors and observers for your long term
presence. You are most valuable to lwig and the IETF.

BR,
Zhen

On Wed, Sep 20, 2017 at 3:15 AM, Suresh Krishnan
<suresh.krish...@gmail.com> wrote:
> Hi all,
>   Robert Cragie has informed me that his work has taken him away from IETF 
> activities and he is no longer able to continue as lwig chair. I would like 
> to thank him for his substantial contributions to lwig WG right from its 
> formation, and to wish him the very best in his future endeavors.
>
> After consultation with Zhen Cao, I have asked Mohit Sethi to serve as 
> co-chair for lwig. Mohit has been an active author, contributor and document 
> shepherd in this WG and I am confident that he will do an excellent job in 
> this new role. Welcome Mohit and thank you for taking this on.
>
> Regards
> Suresh
>

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] Iotdir early review of draft-ietf-lwig-energy-efficient-07

[Zhen Cao]

Thank you so much, Charlies, for the review, and the valuable comments
for us to improve the draft.

We will come up with wording proposals shortly.

Many thanks,
Zhen

On Thu, Jul 27, 2017 at 10:48 PM, Charles Perkins
 wrote:
> Reviewer: Charles Perkins
> Review result: On the Right Track
>
> [Please excuse if this is a duplicate.  I got an error from datatracker on my 
> first attempt.]
>
> Overall comments:
>
> I think that some important techniques for energy efficiency deserve mention
> or significant enlargement:
>
> - Packet bundling
> - Data aggregation
> - Power management / range reduction
> - Fragmentation is more energy-efficient at lower layers than at higher layers
> - Compression, on the other hand, is more efficient at higher layers,
>   particularly before encryption.
>
> The document needs a concise statement of purpose.  Maybe insert the
> following after the first paragraph of the Introduction:
>
>In this document we describe techniques that are in common use at Layer 2
>and at Layer 3, and we indicate the need for higher-layer awareness of
>lower-layer features.
>
> Also in the introduction, some discussion is needed about cross-layer design.
> Is cross-layer design in scope for the [lwig] Working Group?
>
> In figure 1 and elsewhere, it should not be assumed that RPL is the only
> choice for routing in energy-efficient networks.  So, for instance,
> "RPL" could be replaced by "RTG" in Figure 1.
>
> Shouldn't there be an entry for synchronized reception in Figure 2?  Isn't
> Figure 2 actually a table, and thus should be labeled Table 1?
>
> Section 3.3 (Throughput) does not seem to add much if anything to the
> discussion.  The conclusion about the trade-off is quite obvious.
>
> Particularly in section 3.5.2, but also elsewhere, some examples would
> be very helpful.
>
> Section 6.3 (CoAP timers) seems to be only about one timer.
> Are there more?  What about interactions with TCP timers, etc.?
>
> Section 7 should be entitled "Summary and Conclusions".
> In section 7, it would be nice to offer cross references for each
> conclusion, referring the reader to the relevant section of the document.
> Each conclusion should follow from some previous section of the document.
> Unfortunately that currently isn't quite the case.
>
> The citation [Announcementlayer] does not appear in the body of the article.
>
> There are weird line breaks appearing at certain random points in the
> document.
>
> I have editorial suggestions and corrections which I will
> supply as an rfcdiff file under separate email.
>
> Regards,
> Charlie P.
>

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] The LWIG WG has placed draft-gomez-lwig-tcp-constrained-node-networks in state "Call For Adoption By WG Issued"

[Zhen Cao]

Thank you ALL, for the feedback.

This concludes the call and I have sent the message via the
datatracker to inform the authors to upload this draft as a wg-doc.
Thank the authors for the valuable contribution.

BR,
Zhen

On Mon, Aug 28, 2017 at 11:00 PM, Hannes Tschofenig
<hannes.tschofe...@gmx.net> wrote:
> Sorry for my late response (due to vacation).
>
> As mentioned in my review posted to the list (see
> https://www.ietf.org/mail-archive/web/lwip/current/msg00792.html), I
> believe that this draft is a good starting point for a working group
> document.
>
> Ciao
> Hannes
>
>
> On 08/11/2017 10:34 AM, IETF Secretariat wrote:
>>
>> The LWIG WG has placed draft-gomez-lwig-tcp-constrained-node-networks in 
>> state
>> Call For Adoption By WG Issued (entered by Zhen Cao)
>>
>> The document is available at
>> https://datatracker.ietf.org/doc/draft-gomez-lwig-tcp-constrained-node-networks/
>>
>> Comment:
>> The document has received sufficient support of adoption at both IETF98 and
>> IETF99 meetings.  The document has got many reviews with comments and
>> questions, which is good because many people care.  The call would like to
>> confirm that this document is heading at the right direction, and can be
>> served as the basis for future work.
>>
>> ___
>> Lwip mailing list
>> Lwip@ietf.org
>> https://www.ietf.org/mailman/listinfo/lwip
>>

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Issues of CoAP with DTLS

[Zhen Cao]

Hi Authors of draft-lwig-coap,

Thank you for the draft.  I have a question related to CoAP-over-DTLS.
Section 5.4 of the draft
(https://tools.ietf.org/html/draft-ietf-lwig-coap-04#section-5.4) has
some discussion over the problem, it however does not help with the
case below.

Say, the client and server is talking over a CoAP-DTLS session with a
NAT between.   Then the NAT session expires because of an idle period
when no traffic re-enforce the NAT state.  Assume afterwards the
client would like to send a new CoAP-CON message towards the server.
With the NAT outgoing  pair changed, the server will not
be able to resume the previous DTLS session and will discard this
message.  Sad though, it is not that serious because NAT problems is
everywhere.

What's worse is however, under such scenario, the client is unclear if
it needs to retransmit the CoAP-over-DTLS message or re-negotiate a
new DTLS (isn't it? because it does not know whether it is a network
issue or DTLS failure).   If it takes it as a network issue, it will
keep trying to retransmit the CoAP-CON, until it reaches the retry
limit (4 defined in RFC7252). This is very costly because of the
exponential backoff may sum to more than 10s.  In this case, it will
be more efficient in this case to have the client re-negotiates the
DTLS with server immediately.

a) So my first question will be :
Is this an issue with the current implementation and shall we make
some recommendations?

b) With regards to a better solution,
draft-fossati-tls-iot-optimizations-00 will be a direct solution by
including a connection ID in the DTLS record layer,  but I do not know
why this draft expires.   @Hannes, could you help me with some
background.

Many thanks for discussion.

BR,
Zhen

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] WGLC for draft-ietf-lwig-crypto-sensors-03

[Zhen Cao]

e some numbers for that are available?
>>>> It would be useful to include them in order to motivate the use of
>>>> forward secure key agreement.
>>>>
>>>> Grüße, Carsten
>>>>
>>>>
>>>>> On Aug 6, 2017, at 12:18, Mohit Sethi <mohit.m.se...@ericsson.com>
>>>>> wrote:
>>>>>
>>>>> Hi all
>>>>>
>>>>> The authors of the document believe that it is ready to move forward.
>>>>> During the previous last call we had already received support from several
>>>>> working group members.
>>>>>
>>>>> Based on the feedback during the previous last call, we removed the
>>>>> performance measurements of RSA key sizes smaller than 2048 bits. We also
>>>>> added performance measurements of ECDSA sign operation on ARM 32-bit
>>>>> platforms. Additionally, we improved the text on the need for a random
>>>>> number generator, more guidance on choosing the right platform, and why
>>>>> larger flash memory size is needed for firmware updates. We also removed
>>>>> some extraneous text from the background section. Any further comments are
>>>>> welcome.
>>>>>
>>>>> --Mohit
>>>>>
>>>>>
>>>>> On 07/31/2017 04:23 AM, Zhen Cao wrote:
>>>>>>
>>>>>> Hello Everyone,
>>>>>>
>>>>>> This email starts the WGLC for draft-ietf-lwig-crypto-sensors-03
>>>>>> https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-03
>>>>>>
>>>>>> This is a second WGLC with the new draft resolving the comments
>>>>>> received from last round.
>>>>>>
>>>>>> We still appreciate very much if could you help review the document
>>>>>> and send your comments to the mailing list. Thank you in advance.
>>>>>>
>>>>>> The WGLC will end in ONE week till August 7th, 2017.
>>>>>>
>>>>>> Thank the authors for their hard work again.
>>>>>>
>>>>>> Best regards,
>>>>>> Zhen
>>>>>>
>>>>>> On Wed, Feb 22, 2017 at 11:15 AM, Zhen Cao <zhencao.i...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hello everyone,
>>>>>>>
>>>>>>> This email starts the WGLC for draft-ietf-lwig-crypto-sensors-02
>>>>>>> (https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-02)
>>>>>>>
>>>>>>> Could you help review the document and send your comments to the
>>>>>>> mailing list. Thank you in advance.
>>>>>>>
>>>>>>> The WGLC will end in two weeks from now.
>>>>>>>
>>>>>>> BR,
>>>>>>> Zhen
>>>>>>
>>>>>> ___
>>>>>> Lwip mailing list
>>>>>> Lwip@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/lwip
>>>>>
>>>>> ___
>>>>> Lwip mailing list
>>>>> Lwip@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/lwip
>>>>>
>>> ___
>>> Lwip mailing list
>>> Lwip@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lwip
>>>
>>
>
> ___
> Lwip mailing list
> Lwip@ietf.org
> https://www.ietf.org/mailman/listinfo/lwip

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Presentation slides ready

[Zhen Cao]

Hi All,

Please take a look at the slides for tomorrow's presentation, linked below.

Thank all the presenters for their hard work.

1 - Minimal ESP
https://www.ietf.org/proceedings/99/slides/slides-99-lwig-1-minimal-esp-00.pdf

2 - TCP Over Constrained Net
https://www.ietf.org/proceedings/99/slides/slides-99-lwig-2-tcp-over-constrained-net-00.pdf

3 - Neighbor Management Policy
https://www.ietf.org/proceedings/99/slides/slides-99-lwig-3-neighbor-management-policy-00.pdf

4 - Minimal g-ikev2
https://www.ietf.org/proceedings/99/slides/slides-99-lwig-4-minimal-g-ikev2-00.pdf

Best regards,
Zhen

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Comments of draft-jadhav-lwig-nbr-mgmt-policy-00

[Zhen Cao]

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

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Drafts review request

[Zhen Cao]

Dear All,

To make the f2f meeting more efficient, could you kindly help review
the drafts that will be discussed:

https://tools.ietf.org/id/draft-gomez-lwig-tcp-constrained-node-networks-03.txt
https://tools.ietf.org/html/draft-jadhav-lwig-nbr-mgmt-policy-00.txt
https://tools.ietf.org/html/draft-mglt-lwig-minimal-esp-05.txt

All these three drafts have been presented before, and this time the
primary goal at the f2f meeting will be collections of reviews so that
we can see if we can issue call for adoptions.

Thank you so much for your time and contribution.

BR,
Co-chairs

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Lwig Agenda for IETF99

[Zhen Cao]

Hi Everyone,

Please check the agenda for the coming LWIG session next week.

https://datatracker.ietf.org/meeting/99/agenda/lwig/

In the meantime, I will issue several adoption call for the relevant drafts.
Please bring your questions/comments to the authors/presenters for the
f2f meeting.

BR,
Zhen

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Call for Agenda Items @IETF99

[Zhen Cao]

Dear All,

Lwig is supposed to meet at  18:10-19:10 Thursday Afternoon session
III of the Prague meeting.

Could you please let me know if you need to present any thing on this meeting?

Please include the following information: Title/Presenter/F2F meeting
goal.  Report from relevant opensource or hackathon events will be
welcome.

Thank you,
Co-chairs

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Minutes of Lwig at IETF98

[Zhen Cao]

Hi Everyone,

Meeting minutes have been posted here:
https://datatracker.ietf.org/doc/minutes-98-lwig/
Please let me know if there is anything not appropriate.

Thank you, @Mohit, for taking them.

Best regards,
Zhen

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] WGLC for draft-ietf-lwig-crypto-sensors-02

[Zhen Cao]

Hi Hannes,

Thanks for the frank points, which are helpful to make documents more
impactful.  Please see my discussion in-line.

On Mon, Mar 6, 2017 at 9:36 PM, Hannes Tschofenig <hannes.tschofe...@gmx.net
> wrote:

> Hi all,
>
> as I mentioned in the past I consider this document problematic.
>
> The selected hardware gives the impression that IoT devices need very
> low requirements. This gives inexperienced readers the wrong impression.
>

I do not think this leads to any incorrect impressions.  It clearly states
the platform that this work has been carried out, and by informed selection
of crypto libraries, security functions can be enabled on such IoT
devices.  It's much better than the other opposite impression that security
is costly and could be avoid as far as we can.


> At no point in the document it explains why a typical software stack
> required for an IoT device would fit on hardware that has 2 kB of SRAM,
> and 32 kB of flash memory. What did you put on that device? (CoAP, DTLS,
> Resource Directory, SENML -- protocol talk about in Section 9) I suspect
> that there is no firmware update mechanism in place, which is a
> typically demanded feature for IoT devices in order to address bugs.
>
> Other IETF publications recommend key sizes of at least 112 bits
> (symmetric). Here is the relevant table from RFC 4492:
>

Is this 112 bits of symmetric encryption mandatory for even tiny devices?
If this is only a recommended value, we can encourage the contributors to
generate some reference benchmarks for longer asymmetric key values.


>
>Symmetric  |   ECC   |  DH/DSA/RSA
>   +-+-
>80 |   163   | 1024
>   112 |   233   | 2048
>   128 |   283   | 3072
>   192 |   409   | 7680
>   256 |   571   |15360
>
> The document, however, describes RSA key sizes of 64, 128, 512 and 2014
> bits! It makes no sense to illustrate performance, and memory
> requirements of key sizes that shouldn't be used in today's IoT hardware.
>
> The document says that it describes smart object implementation
> experience but clearly this is far away from real world product
> experience. The need for a random number generator is essentially
> missing and a reference to a software library does not help either.
>
> I believe you have started with some hardware and then created the
> software & performance measurements. The recommended approach is,
> however, to first think about security and the requirements and
> subsequently think about what hardware supports the security
> requirements and therefore mitigates the threats.
>

The recommended approach is definitely right for any product design.  But
considering the various requirements with different security needs, it is
pretty hard to cover all of them in one draft.   How about to also include
some discussion of the limitations of doing this in other scenarios that
may break security.


>
> The document references several work in progress specifications. Also
> the pointers to specifications like HIP or IPsec for use with IoT
> devices is misleading since they are not reflecting industry practice.
> They are at best university research projects.


Thanks for checking this.  I think Mohit can try to figure out and change
these inappropriate citations .

Will wait for @Mohit's response anyway.

Best regards,
Zhen


> Ciao
> Hannes
>
>
> On 03/06/2017 10:35 AM, Mudugodu Seetarama Raghavendra wrote:
> > +1
> >
> >
> > Regards,
> >
> > Raghavendra
> >
> >
> >
> > 
> > *From:* Lwip <lwip-boun...@ietf.org> on behalf of Rahul Jadhav
> > <rahul.i...@gmail.com>
> > *Sent:* Saturday, March 4, 2017 7:30 PM
> > *To:* lwip@ietf.org
> > *Subject:* Re: [Lwip] WGLC for draft-ietf-lwig-crypto-sensors-02
> >
> > The draft provides useful information to implementors about different
> > challenges related to security aspects especially towards using low-end
> > hardware. The deployment model described with the experiences will prove
> > helpful to implementors. Will be helpful to take this work forward.
> >
> > Regards,
> > Rahul
> >
> > On 22 February 2017 at 08:45, Zhen Cao <zhencao.i...@gmail.com
> > <mailto:zhencao.i...@gmail.com>> wrote:
> >
> > Hello everyone,
> >
> > This email starts the WGLC for draft-ietf-lwig-crypto-sensors-02
> > (https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-02
> > 

[Lwip] Agenda call for IETF98

[Zhen Cao]

Hi All,

Please drop us a message if you would like a slot in the Lwig session of
the coming IETF98 meeting.

The LWIG session details as below:
1710-1810  Afternoon Session III
Zurich DINT *** lwigLight-Weight Implementation Guidance WG

Best regards,
Co-chairs
___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] WGLC for draft-ietf-lwig-crypto-sensors-02

[Zhen Cao]

Hello everyone,

This email starts the WGLC for draft-ietf-lwig-crypto-sensors-02
(https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-02)

Could you help review the document and send your comments to the
mailing list. Thank you in advance.

The WGLC will end in two weeks from now.

BR,
Zhen

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] Call for adoption of draft-aks-lwig-crypto-sensors-01

[Zhen Cao]

As an individual (co-chair hat off), I read the draft and find a lot
useful information, that why I'd like to support the adoption.

Thanks for the work.

Cheers,
Zhen

On Mon, Jul 25, 2016 at 8:30 AM, Zhen Cao <zhencao.i...@gmail.com> wrote:
> Deal All,
>
> At Lwig Berlin IETF96 session, the poll for the adoption of
> draft-aks-lwig-crypto-sensors-01 is pretty positive.  ( around 20
> people voiced the support and there was no objection ).
>
> This message starts a TWO week call for adoption of this draft (in
> case people will be on vocations after their IETF week).
>
> Kind note: it is definitely necessary to express your opinion again on
> this list even though you have already done that on the session.
>
> Please state your opinion before August 8th, 2016.
>
> Many thanks,
> Zhen

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Call for adoption of draft-aks-lwig-crypto-sensors-01

[Zhen Cao]

Deal All,

At Lwig Berlin IETF96 session, the poll for the adoption of
draft-aks-lwig-crypto-sensors-01 is pretty positive.  ( around 20
people voiced the support and there was no objection ).

This message starts a TWO week call for adoption of this draft (in
case people will be on vocations after their IETF week).

Kind note: it is definitely necessary to express your opinion again on
this list even though you have already done that on the session.

Please state your opinion before August 8th, 2016.

Many thanks,
Zhen

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Slides solicitation

[Zhen Cao]

Dear Presenters,

Please send your slides to me by Thursday night.  Enjoy your IETF week of
course.

Thanks,
Zhen
___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Agenda @IETF96

[Zhen Cao]

Hi All,

The current agenda goes as below.  There may be some changes of 4&5.

https://www.ietf.org/proceedings/96/agenda/agenda-96-lwig


12:20-13:20 Friday Afternoon session I
Room: Schoeneberg

1. Agenda bashing 5 min

2. TCP over Constrained NodesCarles Gomez Montenegro
https://tools.ietf.org/html/draft-gomez-core-tcp-constrained-node 20 min

3. Implementation experiences of public-key cryptography on 8-bit
micro-controllers  Mohit Sethi
https://tools.ietf.org/html/draft-aks-lwig-crypto-sensors-01  15 min

4. Minimal ESP   Daniel Migault
https://tools.ietf.org/html/draft-mglt-lwig-minimal-esp  10 min

5. If time allows :
Lwig terminology update discussion  10 min
https://tools.ietf.org/html/RFC7228

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] [core] Fwd: FW: I-D Action: draft-zheng-core-coap-lantency-evaluation-00.txt

[Zhen Cao]

Hi Carles,

Thanks for feedback.

On Mon, Jul 4, 2016 at 4:58 PM, Carles Gomez Montenegro
<carle...@entel.upc.edu> wrote:
> Hi Zhen,
>
> Thanks a lot for this draft!
>
> A few comments/questions:
>
> - Did you measure the native packet loss rate?

not really.  many paper has studied this, native packet loss rate for
cellular network is rather low in steady environment, because 3gpp
stack is very good at fast retransmission.

>
> - In Table 3 (Wi-Fi), latency of CoAP-CoCoA is the same regardless of the
> manually introduced packet loss rate. I would expect some C-RTT increase
> with packet loss rate increase... Which is the reason why C-RTT increase
> does not happen? Or is there maybe some increase below the millisecond
> granularity?

We only notice sub-ms increase in this set of data.  Because the data
is averaged for the 100 rounds, several retransmissions do not account
much probably.


>
> - I noticed that ICMP RTT for GPRS is 572 ms, while obtained C-RTT is
> often lower than that value. I guess that is due to the size of the ICMP
> packets used to measure the ICMP RTT? (It would be good to indicate the
> size of such packets)

ICMP packet size is smaller than CoAP+UDP.   ICMP Ping request is 40 bytes.

>
> - In GPRS, we also observed a slight retry ratio increase for CoAP-CoCoA
> in low congestion GPRS scenarios. However, the retry ratio was
> significantly lower for CoAP-CoCoA (compared to CoAP-RAW) in moderate to
> high congestion conditions. It would be interesting to measure what
> happens for different offered loads.

CoAP-RAW by default retries after 2 seconds.  If the RTT is higher
than 2s, CoAP-RAW will definitely be more aggressive than CoAP-CoCoA
which calculates RTO based on SmoothedRTT. So what's your RTT?

>
> - Which window size did you use for TCP?

Default on Android, which is TEN.

>
> Minor:
>
> - Is the CoAP client (over UDP) encapsulating the messages as CONs?

Yes,.
>
> - Apparently there is a jump from section 4.2 to 4.4.
>
> - Section 4.4:  s/as composed to/as opposed to
>
> - Reference [COAPCC]: s/Networks magazine/Communications magazine

we will correct the above three nits.

Many thanks,
Zhen

>
> Cheers,
>
> Carles
>
>
>> FYI.
>>
>>
>> -Original Message-
>> From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On Behalf Of
>> internet-dra...@ietf.org
>> Sent: Monday, July 04, 2016 11:16 AM
>> To: i-d-annou...@ietf.org
>> Subject: I-D Action: draft-zheng-core-coap-lantency-evaluation-00.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>> Title   : CoAP Latency Evaluation
>> Authors : Fei Zheng
>>   Baicheng Fu
>>   Zhen Cao
>> Filename: draft-zheng-core-coap-lantency-evaluation-00.txt
>> Pages   : 9
>> Date: 2016-07-03
>>
>> Abstract:
>>This document presents the evaluation results of CoAP in terms of
>>various latency metrics over UDP/TCP under different network
>>environments.  We conduct experiments via both GPRS and WiFi.  We
>>also evaluate how the latency metrics are impacted by the background
>>traffic.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-zheng-core-coap-lantency-evaluation/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-zheng-core-coap-lantency-evaluation-00
>>
>>
>> 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/
>>
>> ___
>> I-D-Announce mailing list
>> i-d-annou...@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> ___
>> core mailing list
>> c...@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
>>
>
>

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] Fwd: New Version Notification for draft-aks-lwig-crypto-sensors-01.txt

[Zhen Cao]

Hi Mohit ,

Nice draft with a lot of reference data

one quick question: do you have any data around AES/tinyAES, and DTLS
memory footprint?

Many thanks,
Zhen

On Thu, Jun 30, 2016 at 6:11 PM, Mohit Sethi  wrote:
> Dear all,
>
> We have uploaded the next version of our draft documenting the
> implementation experiences of public-key cryptography on 8-bit
> micro-controllers. The draft is available here:
> https://tools.ietf.org/html/draft-aks-lwig-crypto-sensors-01
>
> In this updated version, we have included the implementation results from
> the performance analysis of Ed25519 (the crypto forum research group is
> currently specifying the recommended parameters) signature generation on the
> same 8-bit micro-controller.
>
> The informational document also provides design patterns and guidelines for
> ensuring integrity protection and freshness of messages that might be
> helpful when deploying such devices in practice.
>
> We look forward to your feedback. We also request the chairs to allocate a
> short slot (10/12 mins) for presenting this updated version.
>
> Thanks
> /--Mohit
>
>
>  Forwarded Message 
> Subject:New Version Notification for
> draft-aks-lwig-crypto-sensors-01.txt
> Date:   Thu, 30 Jun 2016 02:48:04 -0700
> From:   internet-dra...@ietf.org
> To: Mohit Sethi , Heidi-Maria Back
> , Jari Arkko , Ari
> Keranen 
>
>
>
> A new version of I-D, draft-aks-lwig-crypto-sensors-01.txt
> has been successfully submitted by Mohit Sethi and posted to the
> IETF repository.
>
> Name:   draft-aks-lwig-crypto-sensors
> Revision:   01
> Title:  Practical Considerations and Implementation Experiences in
> Securing Smart Object Networks
> Document date:  2016-06-30
> Group:  Individual Submission
> Pages:  31
> URL:https://www.ietf.org/internet-drafts/draft-aks-lwig-crypto-sensors-01.txt
> Status:https://datatracker.ietf.org/doc/draft-aks-lwig-crypto-sensors/
> Htmlized:https://tools.ietf.org/html/draft-aks-lwig-crypto-sensors-01
> Diff:https://www.ietf.org/rfcdiff?url2=draft-aks-lwig-crypto-sensors-01
>
> Abstract:
>This memo describes challenges associated with securing smart object
>devices in constrained implementations and environments.  The memo
>describes a possible deployment model suitable for these
>environments, discusses the availability of cryptographic libraries
>for small devices, presents some preliminary experiences in
>implementing small devices using those libraries, and discusses
>trade-offs involving different types of approaches.
>
>
>
> 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
>
>
>
>
> ___
> Lwip mailing list
> Lwip@ietf.org
> https://www.ietf.org/mailman/listinfo/lwip

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] WGLC for draft-ietf-lwig-energy-efficient-04

[Zhen Cao]

Hi Folks,

We discussed the draft-ietf-lwig-energy-efficient in Prague meeting
,and the consensus was to proceed to WGLC.

This is another round of confirming the consensus on the mailing list.

This email starts the WGLC for draft-ietf-lwig-energy-efficient-04.
https://tools.ietf.org/html/draft-ietf-lwig-energy-efficient-04

Please express your opinion before next Friday, i.e., March. 25, 2016.

Many thanks,
cochairs

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] WGLC for draft-ietf-lwig-energy-efficient

[Zhen Cao]

Hi Folks,

As an editor of this document, I go through the document again, and
have the following comments.

Generally, this document is useful and interesting, and has been
confirmed on several f2f meeting.  Thank the contributors for the
work.

However, I believe there is still space for improvement.  Shamed as an
editor though, I will polish the text with my best.

>Section.1
   In many scenarios, the network systems comprise many battery-powered
   or energy-harvesting devices.  For example, in an environmental
   monitoring system or a temperature and humidity monitoring system in
   a data center, there are no always-on and handy sustained power
   supplies for the potentially large number of constrained devices.  In
   such deployment environments, it is necessary to optimize the energy
   consumption of the entire system, including computing, application
   layer behavior, and lower layer communication.


Comments: This paragraph needs some improvement for clarity.


>3.3.  Throughput

   Although throughput is not typically a key concern in constrained
   node network applications, it is indeed important in some services in
   this kind of networks, such as over-the-air software updates or when
   off-line sensors accumulate measurements that have to be quickly
   transferred when there is a connectivity opportunity.


Comments: this sounds  not useful text.  Readers are expected to know
how to improve the throughput while keeping the devices energy
efficient.


>7 Summary.
This section is very useful in understanding this document.
I do not see a summary of Section. 5, which is an important technique
part of this document.



Best regards
Zhen



On Thu, Oct 15, 2015 at 6:52 PM, Zhen Cao <zhencao.i...@gmail.com> wrote:
> Hi Everyone,
>
> We discussed the draft-ietf-lwig-energy-efficient in Prague meeting
> ,and the consensus was to proceed to WGLC.
>
> This email starts the WGLC for draft-ietf-lwig-energy-efficient.
> Please express your opinion before next Friday, i.e., Oct. 23, 2015.
>
> Many thanks,
> Zhen

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] minutes of ietf93

[Zhen Cao]

Dear All,

Please check the minutes of Lwig session at IETF93.  If you have any
comments, please let us know before next Wednesday (August 12).

https://www.ietf.org/proceedings/93/minutes/minutes-93-lwig


Thank Matthias again for help taking minutes.

Many thanks,
Zhen

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Agenda of Prague

[Zhen Cao]

Greetings, all

This time in Prague, Lwig will experience an experimental round table
discussion, focusing on how to proceed.

For working group document, we mainly discuss the plan to proceed and boost
discussion and solicit reviews, so that we can move appropriately.

For other topics, we will have an open mic.


Best regards,
Zhen
___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Agenda @ IETF91

[Zhen Cao]

Dear All,

Please check the agenda draft version here:

http://www.ietf.org/proceedings/91/agenda/agenda-91-lwig



*WG Items and waiting for actions *
draft-ietf-lwig-coap

draft-ietf-lwig-cellular

draft-ietf-lwig-energy-efficient-01



*Presentation to collect opinions: *
1. draft-fu-lwig-iot-usecase
2. draft-rizzo-6lo-6legacy-02

Please take a look and let us know any comments.

Regards,
Co-chairs.
___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] Fwd: WebEx meeting info: How to Select Hardware for IoT Systems?

[Zhen Cao]

Hello Hannes,

Thanks for the message. I am going to join this discussion.

On Thu, Sep 11, 2014 at 4:39 PM, Hannes Tschofenig 
hannes.tschofe...@gmx.net wrote:


 Hi all,

 here is the webex information for our conference call tomorrow.
 We am looking forward to an interesting discussion.

 Ciao
 Hannes  Kepeng

 ---

 *How to Select Hardware for IoT Systems?*
 Friday, September 12, 2014
 1:00 pm  |  GMT Summer Time (London, GMT+01:00)  |  1 hr

 Join WebEx meeting
 https://ietf.webex.com/ietf/j.php?MTID=m1b9d0bcee385ebb169b4fb5631b7ab53

 Meeting number: 642 573 373
 Meeting password:   foobar


 Join by phone:
 +1-877-668-4493* Call-in toll free number (US/Canada)
 +1-650-479-3208* Call-in toll number (US/Canada)
 Access code: 642 573 373

 Toll-free calling restrictions:
 http://www.webex.com/pdf/tollfree_restrictions.pdf


 Add this meeting to your calendar:
 https://ietf.webex.com/ietf/j.php?MTID=m5e23b4523c843310775c5e9c55f2f8e4

 Can't join the meeting? Contact support:
 https://ietf.webex.com/ietf/mc



 ___
 Lwip mailing list
 Lwip@ietf.org
 https://www.ietf.org/mailman/listinfo/lwip


___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] [core] draft-arkko-core-cellular

[Zhen Cao]

Dear Authors

I read the draft and found it very interesting and useful for me to
understand how to build energy efficient cellular M2M devices, not
only CoAP devices.

Although the draft is entitled with “CoAP devices”, its provided
recommendations are generally workable for any M2M devices that
provide sensing or actuator service. As what’s stated in Section 1.
   The recommendations in this memo should be taken as complementary to
   device hardware optimization, microelectronics improvements, and
   further evolution of the underlying link and radio layers.  Further
   gains in power efficiency can certainly be gained on several fronts;
   the approach that we take in this memo is to do what can be done at
   the IP, transport, and application layers to provide the best
   possible power efficiency…


I like the style of section 3, the analysis of the link layer
implications for energy-efficient application development. Some
questions and comments are listed separately as below.
- Public network. Is it just used as the adverse of “private network”?
- Point to point link. As analyzed in the draft, this is a normal case
for cellular connection, no way and no need to consider third party
devices. As to achieve energy efficient is always contradictory of
handling multicast/broadcast packets, it is relatively easier to be
efficient with PPP link. Or shall we make such recommendations?
- Radio technology. Radio proved to be the most energy consuming part,
and L2 mechanisms are most efficient in the optimization space. I
turned to believe that there is no need to optimize the upper layers
before I encounter the idea of message coordination. That is to reduce
the frequency of trigger link up by coordinating the send/recv
behavior of different protocols. For example, 6LOWPAN-ND advertises
sometime and wake the radio, and then radio/MAC layer optimization
turns it off before COAP protocol triggers a groupcomm afterwards. If
these send/recv of different protocols can be coordinated, I guess the
situation will be much better.

Section 7 on the “Real-time reachable device”.  For cellular devices,
there is one characterize to utilize: they are always reachable from
the circuit-switch side.  Take the CoAP protocol as an example, if it
is difficult to reach the device (as a CoAP server, or to initiate the
observe mode) from the packet side, we can trigger it via a SMS
message and let it behave as a client.  This is a rather special case
for cellular devices that developers can take advantage of.  I heard
of some usage in this regards.

Again, I believe the description and analysis in this document is
useful for the cellular M2M devices. Guidelines for CoAP and other
IETF protocols can be derived from it.

Best regards,
CZ

On Mon, Jul 9, 2012 at 4:43 AM, Jari Arkko jari.ar...@piuha.net wrote:
 Hi,

 We have written a draft that talks about how to apply CoAP in smart objects
 attached to the Internet via the cellular networks.

 Comments appreciated.

 Jari

 On 09.07.2012 14:37, internet-dra...@ietf.org wrote:

 A new version of I-D, draft-arkko-core-cellular-00.txt
 has been successfully submitted by Jari Arkko and posted to the
 IETF repository.

 Filename:draft-arkko-core-cellular
 Revision:00
 Title:   Building Power-Efficient CoAP Devices for Cellular
 Networks
 Creation date:   2012-07-09
 WG ID:   Individual Submission
 Number of pages: 17
 URL:
 http://www.ietf.org/internet-drafts/draft-arkko-core-cellular-00.txt
 Status:  http://datatracker.ietf.org/doc/draft-arkko-core-cellular
 Htmlized:http://tools.ietf.org/html/draft-arkko-core-cellular-00


 Abstract:
 This memo discusses the use of the Constrained Application Protocol
 (CoAP) protocol in building sensors and other devices that employ
 cellular networks as a communications medium.  Building communicating
 devices that employ these networks is obviously well known, but this
 memo focuses specifically on techniques necessary to minimize power
 consumption.



 The IETF Secretariat



 ___
 core mailing list
 c...@ietf.org
 https://www.ietf.org/mailman/listinfo/core
___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Agenda Call - IETF84 Lwig session

[Zhen Cao]

Hi All,

The Lwig session of IETF84 is on Thursday, August 2, 17:30-18:30

If you would like to present something on the meeting, please send a
message to the co-chairs, including the name of the draft/topic, time
needed.

See you in Vancouver.

-- 
Best regards,
Zhen
___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Fwd: lwig - Requested session has been scheduled for IETF 84

[Zhen Cao]

Hi All,

For your information:

lwig Session 1 (1:00:00)
Thursday, Afternoon Session III 1730-1830
Room Name: Regency D

-- 
Best regards,
Zhen
___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Agenda and Slides

[Zhen Cao]

Hi All,

I have uploaded the version 02 of the agenda, per
http://www.ietf.org/proceedings/83/agenda/agenda-83-lwig.txt

Presenters:

Appreciate if you could send us the slides by tomorrow (Wedn) 6 PM
-Paris time.

-- 
Best regards,
Zhen
___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

[Lwip] Agenda call

[Zhen Cao]

Hi All,

The Lwig session of IETF83 is on Thursday, March 29, 1520-1720
Afternoon Session II.

If you would like to present something in the meeting, please send a
message to Robert or me.  Thank you in advance.

-- 
Best regards,
Zhen
___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip