Subject: Re: [Lwip] WGLC for lwig-terminology

From: <[email-masked]>
Date: Mon, 8 Apr 2013 12:19:22 +0000

I'm in favor of this document becoming a WG draft.
It is useful to have a common langage and references we can point newcomers to.

Dominique

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Cao Zhen (CZ)
Envoyé : dimanche 7 avril 2013 10:23
À : [email-masked]
Objet : [Lwip] WGLC for lwig-terminology

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

Dear All,

Discussion of lwig-terminology appears to have completed. The authors think this document is ready for working-group last call.

This is a two-week working-group last call for draft-ietf-lwig-terminology, for publication as an informational RFC. The working group last call ends at _April 20_

Please send your reviews and comments to the mailing list.  If you have reviewed the document, please do indicate whether you think it should go forward.

Thanks and regards,
Co-chairs

_______________________________________________
Lwip mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lwip

_________________________________________________________________________________________________________________________

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,
France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Mon, 8 Apr 2013 13:06:37 +0000

Sorry I was too quick in responding :-)
Now that I had coffee, I'm in favor of this WG draft becoming an Informational RFC.

Giving it a last browse, I have the following suggestions
- Section 2: "economically" -> "economically"
- Section 2.1, regarding the multiple facets: "- constraints on the maximum code size (ROM/Flash);", ..., "- constraints on the available electrical power". Do we want to mention CPU computational power as a possible constraint? RAM size is usually a limit before CPU power nowaday, but who knows.
- Section 2.2.1: what about explicating the MSL acronym as done for DTN in the following paragraph. I assume TCP does not need explicating.
- Section 3: Ki is not a standard prefix notation. K has traditionally been used for 1024 even though it is the SI unit for temperature. What about writing "kilobytes" in extenso, there seems to be room in the table anyway.
That's it folks

Dominique

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : lundi 8 avril 2013 14:19
À : Cao Zhen (CZ); [email-masked]
Objet : Re: [Lwip] WGLC for lwig-terminology

Dominique

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Cao Zhen (CZ) Envoyé : dimanche 7 avril 2013 10:23 À : [email-masked] Objet : [Lwip] WGLC for lwig-terminology

Dear All,

Thanks and regards,
Co-chairs

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, France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 8 Apr 2013 15:52:52 +0200

Hi Dominique,

thanks for the review and the good suggestions.

> - Section 2.2.1: what about explicating the MSL acronym as done for DTN in the following paragraph. I assume TCP does not need explicating.

I have performed these editorial changes in the SVN.  I also added a reference to RFC 793 for those people who want to look up the definition of the MSL.

(See http://trac.tools.ietf.org/wg/lwig/trac/changeset/11 for the complete set of changes I propose based on your comments.)

> - Section 3: Ki is not a standard prefix notation. K has traditionally been used for 1024 even though it is the SI unit for temperature. 

This used to be true, but is now outdated information.

IEC 80000-13:2008 (part of the series of standards documenting the SI system, which defines things like the meter and the prefixes like kilo and mega) defines "Prefixes for binary multiples", including Kibi, abbreviated Ki, and the Byte (8 bits, abbreviated o or B) *).

In the last decade, this terminology has found a home in most operating systems, and it behooves a terminology document to use the current terminology where it already has been accepted into the mainstream.

Of course, the reader may not be familiar with something that became the standard way of naming things only 5 years ago, so I also added a short explanation to the caption of the table.

> - Section 2.1, regarding the multiple facets: "- constraints on the maximum code size (ROM/Flash);", ..., "- constraints on the available electrical power". Do we want to mention CPU computational…

CPU "power" may be a proxy for 
1) the amount of complexity a CPU can handle, or
2) for its speed.

1 is pretty much limited by its addressable RAM/ROM, which is covered.

Re 2: We haven't tried to provide terminology for CPU speed, and I doubt that we could come up with something very useful here.  The set of facets listed is intended as a lead-in to the next sections (I notice that we failed to provide a pointer to section 4 here, which I also added).
I also think that CPU speed is rarely by itself a limiting factor creating a "constrained device".

So I'm not as sure that we should add CPU speed to this list.  What do other reviewers think?

Grüße, Carsten

*) B is well-known, but also the SI abbreviation for Bel, and it also violates one rule for SI unit naming (there never was a Mrs. or Mr. Byte, which is a prerequisite to upper-case unit abbreviations).  o would be better in this respect, but, while o is the usual abbreviation in France, it is virtually unheard of in English-speaking countries.  Bel also only ever occurs in dB, and decibytes never occur.  So B is likely to remain the mainstream abbreviation for byte, much as we'd like otherwise.

---

From: peter van der Stok <[email-masked]>
Date: Mon, 08 Apr 2013 17:06:15 +0200

without coffee,
I agree,

peter

[email-masked] schreef op 2013-04-08 14:19:
> Discussion of lwig-terminology appears to have completed. The authors
> think this document is ready for working-group last call.
> 
> This is a two-week working-group last call for
> draft-ietf-lwig-terminology, for publication as an informational RFC.
> The working group last call ends at _April 20_
> 
> Please send your reviews and comments to the mailing list.  If you
> have reviewed the document, please do indicate whether you think it
> should go forward.
> 
> Thanks and regards,
> Co-chairs
> 
> 
> 
> 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,
> This message and its attachments may contain confidential or
> privileged information that may be protected by law;
> If you have received this email in error, please notify the sender
> and delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for
> messages that have been modified, changed or falsified.
> Thank you.
>

---

From: "Cao Zhen \(CZ\)" <[email-masked]>
Date: Mon, 8 Apr 2013 23:36:22 +0800

> Re 2: We haven't tried to provide terminology for CPU speed, and I doubt
that we could come up
> with something very useful here.  The set of facets listed is intended as
a lead-in to the next
> sections (I notice that we failed to provide a pointer to section 4 here,
which I also added).
> So I'm not as sure that we should add CPU speed to this list.  What do
other reviewers think?
I prefer to make what it is now. Communication costs more than computing,
that's why 6lowpan swaps computing with communication by compression. So
focusing on communication part is most valuable. 
Thanks,
zhen

---

From: ma yc <[email-masked]>
Date: Tue, 16 Apr 2013 15:39:59 +0800

I support this document to go forward.

Yuanchen

2013/4/8 peter van der Stok <[email-masked]>

>> ------------------------------**------------------------------**
>> ------------------------------**------------------------------**
>> ------------------------------**-
>> ------
>>
>>
>> Dear All,
>>
>> ______________________________**_________________
>> Lwip mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/lwip<https://www.ietf.org/mailman/listinfo/lwip>
>>
>> ______________________________**______________________________**
>> ______________________________**______________________________**_
>>
>> ______________________________**_________________
>> Lwip mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/lwip<https://www.ietf.org/mailman/listinfo/lwip>
>>
> ______________________________**_________________
> Lwip mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/lwip<https://www.ietf.org/mailman/listinfo/lwip>
>