Re: [6lo] review of 6lo use cases draft

Yong-Geun Hong <yonggeun.hong@gmail.com> Tue, 03 March 2020 01:53 UTC

Return-Path: <yonggeun.hong@gmail.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314583A15DA; Mon, 2 Mar 2020 17:53:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6O4oVTnhsZF; Mon, 2 Mar 2020 17:53:14 -0800 (PST)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 137D43A15DB; Mon, 2 Mar 2020 17:53:14 -0800 (PST)
Received: by mail-lj1-x22b.google.com with SMTP id a10so1633778ljp.11; Mon, 02 Mar 2020 17:53:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GW3X4qsh2z/sHs9/+2sDaFzW3E7JjmxayaKyVbChDgc=; b=DJwcjaZfsOaAam2jwfsiUob/OftxCs6YDiTFFF3T7GnCWA6gBNqUsChOHESRHYuaTr iVCQHVoZuarY8cLokxUaEt7ySLSUOkNk9mD2QxvLy8NwQaKHtx+RQXarLkUd500y69DK uCOtTB/HCKmWwwBPuV0LllVa1UcgQOPNtmvnnMMFDF+oeNoU7huWuYFoY4knjMMwkNh8 yqFUKsO0r9yYYijud5bYXfm14q+nTeCGVbEMHlEnvmhb0NMBpEEclmQJBOkVePGVrrRI e08zeaGZKkHOAnpQC21rQghAy+iioZGL0oz1Y9OkScHoKtGS2WmTqgNK5BigpgMe+iB0 rFKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GW3X4qsh2z/sHs9/+2sDaFzW3E7JjmxayaKyVbChDgc=; b=F7nmmCNHYmNLARIVHf15Gogd1831jdtXt3XBMvo1P9XsWtdqwYHCQqpq7VJGOerCI0 QMZiBgoOH6rZlOmn/uBCbVj6vFCFz+HhErR4a3pcV5ynvS99UpkIP1/e0P7jBWsArWOI DsUxq1DUGP3UwnGwWqHhEykPuhdcjgvt9wZdQPa2OoIHnhBmWAejDCOQn3E9otGyn0U3 edttcjt2UJeo7+zgNtYIlXS786RQA/0DMgC+KcdGYzXN6PA1MvKp3smgR3WSexPx3h90 UOJhOV74ngoSv51lnTMW9tc65JeYdLCiRiGXcLhzF0ns0UC0VlB2UoE7xmglIJPTTmFo KTkA==
X-Gm-Message-State: ANhLgQ2ubc2eI/uX5wUdJCdZjf/oyWTzNaiF0BZN+e/GeBwqbkFpCTBG zPfF7j+f/X/cTmQkT2vDi1DsRLsYKJrOmvoxg2Q=
X-Google-Smtp-Source: ADFU+vsT4VxSGS+qdSjX4wayFHr6wXV3VRNzRMNM0HbUQsmU2eOaHZk2eBC+huuf0VA8vy+8zG6AwQ/gdah0CUxZcNE=
X-Received: by 2002:a2e:9013:: with SMTP id h19mr974234ljg.223.1583200392143; Mon, 02 Mar 2020 17:53:12 -0800 (PST)
MIME-Version: 1.0
References: <23993_1582532152_5E538638_23993_304_12_DA7944B3.70DB2%dominique.barthel@orange.com> <CACt2foEaPegJOJuKgQzau057AJUipA2NTii8z+j9CR0Nbeey7A@mail.gmail.com> <CABONVQYseqGLEXbqUDauDDAZc-5rCgZ2cbnbDPLzDgS_uQjGZw@mail.gmail.com>
In-Reply-To: <CABONVQYseqGLEXbqUDauDDAZc-5rCgZ2cbnbDPLzDgS_uQjGZw@mail.gmail.com>
From: Yong-Geun Hong <yonggeun.hong@gmail.com>
Date: Tue, 03 Mar 2020 10:53:00 +0900
Message-ID: <CACt2foFk4YuYaW7B5tPXeQcL2=+8iz4=C0av=8aHjkwvdt2O2A@mail.gmail.com>
To: Laurent Toutain <laurent.toutain@imt-atlantique.fr>
Cc: BARTHEL Dominique IMT/OLPS <dominique.barthel@orange.com>, "draft-ietf-6lo-use-cases@ietf.org" <draft-ietf-6lo-use-cases@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fb6946059fe99032"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/np_9ue1Xs3c6P-ZvcE-8L10IRqA>
Subject: Re: [6lo] review of 6lo use cases draft
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Mar 2020 01:53:17 -0000

Dear Laurent Toutain.

Thanks for your comments. Your valuable comments are helpful to improve the
draft.

I guess you reviewed both of 6lo use cases draft(draft-ietf-6lo-use-cases)
and 6lo PLC draft (draft-ietf-6lo-plc) and your comments are mixed between
two drafts.

Although this email thread is related to 6lo use cases draft, I try to
reply your comments and deliver your comments for the regarding of 6lo PLC
draft to other authors of 6lo PLC draft. Please, find my answers inlines.

Best regards.

Yong-Geun.

On Mon, Mar 2, 2020 at 6:42 PM Laurent Toutain <
laurent.toutain@imt-atlantique.fr> wrote:

> Hi YongGeun,
>
> Here is my review of the PLC document. It is a valuable document with a
> good synthesize of different standards.It helps to understand the
> environment and apply 6lo.
>
[Yong-Geun] Thanks for your comments. That is the motivation of the 6lo use
cases draft.


> § 3.3 MTU
>
> As you say, L2 hides frame size through its own fragmentation procedure,
> maybe it good be good to remind that these protocols offer different
> modulations and MTU associated with these modulations.
> It may have an impact on performance.
>
[Yong-Geun] Thanks. I agree to remind. It will be better to apply this
sentence both of two drafts.


> $ 3.4 Routing Protocols
>
> I don't understand the classification, RPL and LOADng can be compared, but
> the middle item is more linked to a specification than a protocol.
>
[Yong-Geun] Thanks. I guess this comment is only related to 6lo PLC draft.
I understand your point. It will be more better to find another approach of
classification or description.

>
> § 4.4 ND
>
> This part seems to focus on a PLC network with route-over. Is mesh-under
> behavior is still accurate? will it change the ND behavior?
>
[Yong-Geun] Thanks. I guess this comment is only related to 6lo PLC draft.
I will check again.

>
> §5 Internet Connectivity.
>
> I don't understand the use of LPWAN for Internet connectivity. It does not
> appear in figure 5.
>
[Yong-Geun] Thanks. This comment is only related to 6lo PLC draft. I guess
the usage of LPWAN is for description of the connection to the outside
networks such as Ethernet. As you comment, it will be more better to note
LPWAN in the Figure 5 or modify the content.


> Hope it helps,
>
> See you
>
> Laurent
>
> On Tue, Feb 25, 2020 at 3:56 AM Yong-Geun Hong <yonggeun.hong@gmail.com>
> wrote:
>
>> Dear Dominique.
>>
>> Thanks for your valuable comments.
>> These comments will be helpful to improve the draft.
>>
>> Please, find my response inlines.
>>
>> I will update the draft to resolve the comments in a next revision.
>>
>> Best regards.
>>
>> Yong-Geun.
>>
>> On Mon, Feb 24, 2020 at 5:16 PM <dominique.barthel@orange.com> wrote:
>>
>>> Hello all,
>>>
>>> I have read https://tools.ietf.org/html/draft-ietf-6lo-use-cases-08 .
>>> I found it easy to read and informative.
>>> Here are a few comments for your consideration:
>>>
>>>    - I don't think there should be any RFC2116 language in this draft,
>>>    since it describes use cases. I spotted MAY and SHOULD in Sections 1 and 5.
>>>
>>>              [Yong-Geun] Yes, in Section 1 and 5, you can find MAY and
>> SHOULD. As you mention that it describes use cases, we will update the
>> usage of MAY and SHOULD.
>>
>>>
>>>    - The bullet list at the end of section 1 is unbalanced: 2 items are
>>>    full sentences, 2 are just nominal groups
>>>
>>>              [Yong-Geun]  Yes, the current four items are unbalanced. I
>> will balance the four items.
>>
>>>
>>>    - Section 3.6 PLC: "wired technologies are more susceptible to cause
>>>    interference". More than what technologies? Since wires are meant to guide
>>>    energy, I would say that wired technologies cause less interference to the
>>>    radio medium than wireless technologies, all other things being equal.
>>>
>>>               [Yong-Geun] Yes, you are right. I guess the existing
>> sentence looks like a little ambiguous. The sentence you proposed looks
>> like a more better. I will check again with PLC experts and update the
>> sentence based on your suggestion.
>>
>>
>>>    - Section 3.7 "In above clauses, various 6lo Link layer technologies
>>>    and a possible candidate are described". Unclear which ones are the
>>>    genuine 6lo technologies, which one is the possible candidate? Does it
>>>    matter that one is only  "candidate"?
>>>
>>>              [Yong-Geun] Sorry, I forget the update of ‘possible
>> candidate’ expression. In previous version (04) of this draft, it includes
>> LTE MTC as one of example of a potential candidate but we decided to delete
>> the potential candidate and focus on current 6lo link layer technologies. I
>> will update the paragraph based on your comments.
>>
>>
>>>
>>>    - Section 3.7 "The following table shows that dominant paramters of
>>>    each use case corresponding to the 6lo link layer technology".
>>>    Incorrect sentence.
>>>
>>>              [Yong-Geun] Yes, this sentence includes typos and unclear
>> expression. I will update.
>>
>>
>>>
>>>    - Table 2: looks like a mixture of technologies and applications.
>>>    E.g. latency requirement = low for DECT-ULE, but only true for
>>>    smart-metering, not for some other DECT-ULE use cases (home automation).
>>>    Providing only one example of usage is a mis-representation of the
>>>    technology.
>>>
>>>              [Yong-Geun] Thanks for your correction. To provide more
>> correct information, it will be better to describe common (general)
>> characteristics of each technology. But, in some point, we have a
>> difficulty to capture common characteristics of each technology for
>> different application in limited space. That is the reason why we mentioned
>> the usage of each technology in the first row.. I will discuss other
>> authors and try to find best way.
>>
>>
>>>
>>>    - In what respect are section 4 and 6 different? They both have
>>>    descriptions of technology and use cases. Could they be merged?
>>>
>>>              [Yong-Geun] I agree that you can guess the section 4 and
>> section 6 had no big difference. The main intention of section 6 is to
>> provide 6lo use case examples of each 6lo link layer technology. But, in
>> the section 6, we cannot guarantee the real deployment of described use
>> case examples. That’s the reason why we provided the section 4. The main
>> intention of section 4 is to provide *real* and *real* 6lo deployment
>> scenarios and it includes G3-PLC and Netricity. So, the purpose of section
>> 4 and section 6 is different. In my opinion, it is better to keep the
>> separated sections.
>>
>>
>>
>>>
>>>    - Section 10.1, Normative References. I wonder if this draft, being
>>>    a use case description, should have any normative reference at all (except
>>>    maybe for RFC2119). I'm not sure, seek advice.
>>>
>>>              [Yong-Geun] Thanks for your suggestion. The main Normative
>> reference are related in section 5 Guidelines for adopting IPv6 stack. As
>> you suggest, I will check again and seek advice.
>>
>>
>>
>>> Best regards
>>>
>>> Dominique
>>>
>>> _________________________________________________________________________________________________________________________
>>>
>>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>
>>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>>> they should not be distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>>> Thank you.
>>>
>>> _______________________________________________
>>> 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
>>
>