Re: ietf Digest, Vol 117, Issue 30

[Alfonso Guillen <[e-mail]>]

Some one, can support me how can I help in this Vol ?
 Regards 
Alfonso   

      De: "[e-mail]" <[e-mail]>
 Para: [e-mail] 
 Enviado: Martes 6 de febrero de 2018 9:11
 Asunto: ietf Digest, Vol 117, Issue 30
   
Send ietf mailing list submissions to
    [e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
    https://www.ietf.org/mailman/listinfo/ietf
or, via email, send a message with subject or body 'help' to
    [e-mail]

You can reach the person managing the list at
    [e-mail]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ietf digest..."


Today's Topics:

  1. Re: [IoT-DIR] Iotdir early review of
      draft-ietf-lpwan-overview-08 (Abdussalam Baryun)
  2. Re: [lp-wan] [IoT-DIR] Iotdir early review of
      draft-ietf-lpwan-overview-08 (Stephen Farrell)


----------------------------------------------------------------------

Message: 1
Date: Tue, 6 Feb 2018 16:58:09 +0200
From: Abdussalam Baryun <[e-mail]>
To: [e-mail]
Cc: ietf <[e-mail]>, [e-mail]
Subject: Re: [IoT-DIR] Iotdir early review of
    draft-ietf-lpwan-overview-08
Message-ID:
    <CADnDZ887zBQo90FZpAAJFaN1+Rhvo+w=[e-mail]>
Content-Type: text/plain; charset="utf-8"

Hi Samita,

Thanks for your review, but not sure why you say early review in the
subject? I send my review earlier [1] but got [2]. However, I support your
comments 100% while don't support some replies in the editor's [2].

 I tried in my review in the IETF Last call but not much reasonable
replies, even the WG chair said [3]  in one reply to my review that they
don't take my comments because IESG was already processing draft, I was
earlier than your comment, but was surprised that IESG had no much involve.

The other problem IMHO is that our IESG may not be following procedures (or
maybe one new comer may say the ietf is not serious, which I said sometime
maybe). The IESG should consider individual comments mentioned in the RFC,
but I got no respond from IESG/ADs. Is that methodology changed maybe?

In my previous experience with the serious-IETF, the past IESG were
responding to me, as I can get a respond from the AD saying ok, I will let
the author respond, but this IESG/ADs are not replying. I will say most of
our RFCs may be not easy to read.

AB


[1]  http://www.ietf.org/mail-archive/web/lp-wan/current/msg01227.html
[2] http://www.ietf.org/mail-archive/web/lp-wan/current/msg01230.html
[3] http://www.ietf.org/mail-archive/web/lp-wan/current/msg01232.html

On Mon, Feb 5, 2018 at 9:08 PM, Samita Chakrabarti <samitac.ietf at
gmail.com> wrote:

> Reviewer: Samita Chakrabarti
> Review result: Almost Ready
>
> Hi Stephen,
> First of all, thank you for writing up the comprehensive overview of LPWAN
> technologies and their characteristics. I have read the document and the
> following are my comments for IOT-DIR review.
>
> General : Please fix the formatting and paging of the document. Some of the
> figures are split between pages. The document uses loads of acronyms from
> multiple technologies. A glossary of terms are useful for reference in the
> beginning of the decument. Section 2:  :?Note that some?. Of this
> document? ?
> please make sure that only RFC and WG approved documents are referenced in
> the
> reference section and remove any reference that are still individual
> document
> at the time of publication/IESG review.
>
> Section 2.4 ? Please move the acknowledgement texts to the ACKNOWLEDGEMENT
> section at the end of the draft Section 2.1.2 ? Table 1 records data rate
> for
> LORA .3 ? 5Kbps. For 868MHZ band; Later Table 2 records 50,000 kbps data
> rate
> for the same band.  Is this a typo ? If not please provide explanation
> Table 4
> and page 9 talks about DEVEUI ? how are they obtained/configured/assigned
> on
> the end-device? I suggest adding definition of terms for each technology
> at the
> beginning of the document for easy reference. Page 12 calls out PSM, eDRX
> etc.
> ? please add their definition in the definition of terms Fig 3: labels eNB
> but
> the document talks about eNodeB. Please make them consistent
>
> Page 14 ? describes control function and RRC function. Please provide the
> RRC
> description/definition when RRC is first referenced in page 12. [ move this
> description to earlier sections ] Also notr that section 2.2.2 is extremely
> long; I would suggest breaking the section into different subsections such
> as
> ?network components?, ?Network Architecture?, ?Control plane? etc. Remove
> section 3 and combine the content of section 3 with section 2.1.2. They
> seem to
> have duplicate information. Fig 8 may be moved in section 2.1.2  as well.
> Combine fig 9 with fig 1.
>
> Pg 26 ? refers to I.D-hong-6lo-use-cases ? but I did not find it in the
> reference section. Please fix. What is ?Very low layer tow payload?. ? ?
> please
> fix Note ID-hong-6lo-use-case document not only support 6lowpan, but it
> supports 6lo use-cases as well. Section 4.2,2 ? The statement  Header
> compression and privacy address IID is not quite true. There is guideline
> for
> supporting privacy in 6lo. Please refer to RFC 8065. Section 4.3 -implies
> that
> 6lowpan and 6lo support star topologies only. That is NOT true. Both
> 6lowpan
> and 6lo can support both star and mesh topologies. Besides 6lo supports
> many
> different constrained networks including NFC and PLC. Please fix the
> section
> 4.3 .
>
> Thanks,
> -Samita
>
> _______________________________________________
> IoT-DIR mailing list
> IoT-DIR at ietf.org
> https://www.ietf.org/mailman/listinfo/iot-dir
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/ietf/attachments/20180206/3b7a5690/attachment.html>

------------------------------

Message: 2
Date: Tue, 6 Feb 2018 15:10:05 +0000
From: Stephen Farrell <[e-mail]>
To: Samita Chakrabarti <[e-mail]>, Suresh Krishnan
    <[e-mail]>
Cc: iot-dir <[e-mail]>, [e-mail],
    [e-mail], [e-mail]
Subject: Re: [lp-wan] [IoT-DIR] Iotdir early review of
    draft-ietf-lpwan-overview-08
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="utf-8"


Hi Samita,

Thanks for the review. As this document has at this stage been
through IESG evaluation, I think it's best to avoid changes if
possible, but I'll be guided by the responsible AD, (i.e. if
Suresh tells me he thinks some change is needed, I'll do it.)
For such cases below I just say I think it's a bit late for
the change suggested.

On 06/02/18 05:18, Samita Chakrabarti wrote:
> I see the formatting of the sent text is meesed up, here is another try:
> 
> Hi Stephen,
> 
> First of all, thank you for writing up the comprehensive overview of LPWAN
> technologies and their characteristics. I have read the document and the
> following are my comments for IOT-DIR review.
> 
> 
> 
> General : Please fix the formatting and paging of the document. Some of the
> figures are split between pages. 

That's for the RFC editor to do. (And doing it now wouldn't help,
as the pagination will change as the RFC editor do their work.)

> The document uses loads of acronyms from
> multiple technologies. A glossary of terms are useful for reference in the
> beginning of the decument.

I think it's a bit late for such a change.

> Section 2:  :?Note that some?. Of this document? ? please make sure that
> only RFC and WG approved documents are referenced in the reference section
> and remove any reference that are still individual document at the time of
> publication/IESG review.

It's fine to include informational references to drafts in a
document such as this when those drafts provide useful background,
which I think is the case here.

> Section 2.4 ? Please move the acknowledgement texts to the ACKNOWLEDGEMENT
> section at the end of the draft

I think it's a bit late for such a change.

> Section 2.1.2 ? Table 1 records data rate for LORA .3 ? 5Kbps. For 868MHZ
> band; Later Table 2 records 50,000 kbps data rate for the same band.  Is
> this a typo ? If not please provide explanation

Good catch! Table 1 is based on the join-req channel list
(DR0-DR5) whilst the 50000 from table 2 is for DR7 and I
guess only applies after an end-device has joined a n/w.
(Those numbers are in different tables in the LoRa spec,
so I guess I screwed up reading those:-)

I propose to change table 1 to say 50000bps.

If someone more familiar with LoRa wants to tell me that's
wrong (e.g. if DR7 is rarely usable) I'll gladly fix it
to better match reality.

That change is made in my editor's copy. [1] If I don't
get feedback from the WG or AD that that's wrong, I'll
push out -09 in a day or so with that change and the
ones below.

> Table 4 and page 9 talks about DEVEUI ? how are they
> obtained/configured/assigned on the end-device?

Those need to be provisioned. IIUC, that's done by the
device makers in whatever way they choose.

> 
> I suggest adding definition of terms for each technology at the beginning
> of the document for easy reference.

I think it's a bit late for such a change.

> 
> Page 12 calls out PSM, eDRX etc. ? please add their definition in the
> definition of terms

I think it's a bit late for such a change.

> 
> Fig 3: labels eNB but the document talks about eNodeB. Please make them
> consistent

Fair enough. Done in editor's copy.

> Page 14 ? describes control function and RRC function. Please provide the
> RRC description/definition when RRC is first referenced in page 12. [ move
> this description to earlier sections ] 

RRC is expanded on p11.

> Also notr that section 2.2.2 is
> extremely long; I would suggest breaking the section into different
> subsections such as ?network components?, ?Network Architecture?, ?Control
> plane? etc.

I think it's a bit late for such a change.

> Remove section 3 and combine the content of section 3 with section 2.1.2.
> They seem to have duplicate information. Fig 8 may be moved in section 2.1.2
> as well. Combine fig 9 with fig 1.

I think it's a bit late for such a change.


> Pg 26 ? refers to I.D-hong-6lo-use-cases ? but I did not find it in the
> reference section. Please fix.

Good catch again. Fixed in editor's copy. (It's always amazing
how such things make it past so many eyeballs!)

> 
> What is ?Very low layer tow payload?. ? ? please fix

s/very low/tiny/ in editor's copy.

> 
> Note ID-hong-6lo-use-case document not only support 6lowpan, but it
> supports 6lo use-cases as well.
> 
> Section 4.2,2 ? The statement  Header compression and privacy address IID
> is not quite true. There is guideline for supporting privacy in 6lo. Please
> refer to RFC 8065.

I think that's a good addition to make, thanks. I've
added this to the end of 4.2.2 in the editor's copy:

 "[RFC8065] provides guidance on better methods for
  generating IIDs."

> Section 4.3 -implies that 6lowpan and 6lo support star topologies only.
> That is NOT true. Both 6lowpan and 6lo can support both star and mesh
> topologies. Besides 6lo supports many different constrained networks
> including NFC and PLC. Please fix the section 4.3 .

I don't see that implication in 4.3, but would be happy
to consider better wording if you want to offer some.

The editor's copy for a pre-09 is at [1], the diff vs.
-08 is at [2].

Cheers,
S.

[1] https://github.com/sftcd/lpwan-ov/
[2]
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-lpwan-overview-08.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-lpwan-overview.txt

> 
> 
> On Mon, Feb 5, 2018 at 9:08 PM, Samita Chakrabarti <[e-mail]>
> wrote:
> 
>> Reviewer: Samita Chakrabarti
>> Review result: Almost Ready
>>
>> Hi Stephen,
>> First of all, thank you for writing up the comprehensive overview of LPWAN
>> technologies and their characteristics. I have read the document and the
>> following are my comments for IOT-DIR review.
>>
>> General : Please fix the formatting and paging of the document. Some of the
>> figures are split between pages. The document uses loads of acronyms from
>> multiple technologies. A glossary of terms are useful for reference in the
>> beginning of the decument. Section 2:  :?Note that some?. Of this
>> document? ?
>> please make sure that only RFC and WG approved documents are referenced in
>> the
>> reference section and remove any reference that are still individual
>> document
>> at the time of publication/IESG review.
>>
>> Section 2.4 ? Please move the acknowledgement texts to the ACKNOWLEDGEMENT
>> section at the end of the draft Section 2.1.2 ? Table 1 records data rate
>> for
>> LORA .3 ? 5Kbps. For 868MHZ band; Later Table 2 records 50,000 kbps data
>> rate
>> for the same band.  Is this a typo ? If not please provide explanation
>> Table 4
>> and page 9 talks about DEVEUI ? how are they obtained/configured/assigned
>> on
>> the end-device? I suggest adding definition of terms for each technology
>> at the
>> beginning of the document for easy reference. Page 12 calls out PSM, eDRX
>> etc.
>> ? please add their definition in the definition of terms Fig 3: labels eNB
>> but
>> the document talks about eNodeB. Please make them consistent
>>
>> Page 14 ? describes control function and RRC function. Please provide the
>> RRC
>> description/definition when RRC is first referenced in page 12. [ move this
>> description to earlier sections ] Also notr that section 2.2.2 is extremely
>> long; I would suggest breaking the section into different subsections such
>> as
>> ?network components?, ?Network Architecture?, ?Control plane? etc. Remove
>> section 3 and combine the content of section 3 with section 2.1.2. They
>> seem to
>> have duplicate information. Fig 8 may be moved in section 2.1.2  as well.
>> Combine fig 9 with fig 1.
>>
>> Pg 26 ? refers to I.D-hong-6lo-use-cases ? but I did not find it in the
>> reference section. Please fix. What is ?Very low layer tow payload?. ? ?
>> please
>> fix Note ID-hong-6lo-use-case document not only support 6lowpan, but it
>> supports 6lo use-cases as well. Section 4.2,2 ? The statement  Header
>> compression and privacy address IID is not quite true. There is guideline
>> for
>> supporting privacy in 6lo. Please refer to RFC 8065. Section 4.3 -implies
>> that
>> 6lowpan and 6lo support star topologies only. That is NOT true. Both
>> 6lowpan
>> and 6lo can support both star and mesh topologies. Besides 6lo supports
>> many
>> different constrained networks including NFC and PLC. Please fix the
>> section
>> 4.3 .
>>
>> Thanks,
>> -Samita
>>
>> _______________________________________________
>> IoT-DIR mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/iot-dir
>>
> 
> 
> 
> _______________________________________________
> lp-wan mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lp-wan
> 

-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x7B172BEA.asc
Type: application/pgp-keys
Size: 5950 bytes
Desc: not available
URL: <https://mailarchive.ietf.org/arch/browse/ietf/attachments/20180206/c682ea1a/attachment.skr>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://mailarchive.ietf.org/arch/browse/ietf/attachments/20180206/c682ea1a/attachment.asc>

------------------------------

Subject: Digest Footer

_______________________________________________
ietf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf


------------------------------

End of ietf Digest, Vol 117, Issue 30
*************************************