Re: [lp-wan] SCHC RFC-to-be title?

[Juan Carlos Zuniga <[e-mail]>]

Hello,

I agree with the points that Dominique is raising. Coincidentally, I’ve had to explain about 3 times over the past two weeks to people not familiar with the WG the fact that the SCHC framework is generic and does not require IPv6 to be applicable to other data services.

I wanted to give an example about the many IETF specs that we use where we refer to them as noun (e.g. SIP, ICMP, DHCP, TCP) where we sometimes forget about the meaning of each letter, but I prefer to keep the BMW example (and goal) from Dominique ;)

I also like the idea of using “framework” in the title, as most IETF specs mention if they describe a protocol, algorithm, data model, etc.

Hence my vote is for:

A4 – no expansion in title, but explained in the doc, and,
B1 – where I also agree with the proposal from Olivier to invert the words to add clarity.

Best,

Juan Carlos

From: lp-wan <[e-mail]> On Behalf Of [e-mail]
Sent: February 6, 2020 9:24 AM
To: Alexander Pelov <[e-mail]>
Cc: [e-mail]
Subject: Re: [lp-wan] SCHC RFC-to-be title?

Hello Alex,

Thanks for your contribution to the discussion.
- Point taken for SCHCF. It had not vote for it so far anyway.
- Regarding the title: in light of recent experience, I'm afraid that if one is casually told "hey, maybe you should look at RFC8724, it could solve your problem", one will pull up the RFC, look at the title and think "oh, UDP/IPv6, LPWAN, this is not addressing my problem" and drop it.
- Regarding SCHC becoming a name, no longer an acronym: your (future?) car is a BMW, a fine reliable car or whatever you mentally associate with this brand. Hardly anybody knows that is used to mean Bayerische Motor Werke (i.e. Bavarian Motor Workshops). I suggest we start using SCHC as a name associated with "a generic framework for header compression and fragmentation that uses a static context", and downplay the acronym. The sooner the better. AUTH48 is a good time. Don't you want SCHC to become a BMW among the networking protocols ;-) ?

Anyway, your vote is taken into account.
Thanks again,

Dominique

De : Alexander Pelov <[e-mail]<mailto:[e-mail]>>
Date : Thursday 6 February 2020 15:01
À : Dominique Barthel <[e-mail]<mailto:[e-mail]>>
Cc : "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Objet : Re: [lp-wan] SCHC RFC-to-be title?

Hi all,

Thanks Dominique !

(chair hat off)

A side observation - I think that SCHC cannot be changed at that point, as it has already been used across other organizations and standardisation bodies. So, that ship has definitely sailed, and SCHCF is not an option in my opinion.
Another observation - although I feel that we might come up with something different, I do not have problems with the current title.

Then, on the point of "can SCHC become a noun?" - is something I am not sure we can decide. How does something stop being an acronym and becomes a widely-accepted term?
For a short example - take a look at the RFC page of Wikipedia still states that RFC means "Request for Comments" ( https://en.wikipedia.org/wiki/Request_for_Comments<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FRequest_for_Comments&data=02%7C01%7Cjuancarlos.zuniga%40sigfox.com%7C2c547d73fa1d4e1cb55d08d7ab105912%7Cfcbc8bb1061e4b949f703ad917b0c8d3%7C0%7C0%7C637165959021695920&sdata=46JaH1Ej3RDnYHs8rvvxVm1sbklguAZ8brQe8zIz7m4%3D&reserved=0> ).
Also, I feel that for the sake of a title, it is not worth it to have to explain every time that SCHC is not an abbreviation, but it used to mean Static Context Header Compression, but because we have also fragmentation, we made it a noun.
In all future references I personally will be referring it to The SCHC standard, or RFC 8724. I don't expect it to ever get into a long discussion with anyone about what is in the title ;)

I would therefore vote for a simplicity - A.1.

On the title, I actually like the new proposals, and if need be would go with a variant of B.1, where SCHC is expanded;
"Generic Framework for Static Context Header Compression (SCHC) and Fragmentation"


So, in order of preference, I would add:
A.1 SCHC is Static Context Header Compression
B.5 Generic Framework for Static Context Header Compression (SCHC) and Fragmentation
B.6 Static Context Header Compression (SCHC) and fragmentation for LPWAN, application to UDP/IPv6

Cheers,
Alexander



On Thu, Feb 6, 2020 at 1:51 PM <[e-mail]<mailto:[e-mail]>> wrote:
My vote is for A.4 B.1
Best regards

Dominique

De : lp-wan <[e-mail]<mailto:[e-mail]>> on behalf of Dominique Barthel <[e-mail]<mailto:[e-mail]>>
Date : Thursday 6 February 2020 10:55
À : "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Objet : [lp-wan] SCHC RFC-to-be title?

Hello all,

This was discussed yesterday at the interim meeting and I want to give everybody a chance to chime in.
The SCHC draft is currently in AUTH48 stage, with the RFC Editor, and now is the time to do the last editorial changes.

One thing we want to do right is the RFC title. It currently says "Static Context Header Compression (SCHC) and fragmentation for LPWAN, application to UDP/IPv6".
We want to change it for a better title, one that reflects the most important contributions of this RFC.

  *   I believe the UDP/IPv6 section is secondary, it's more of an example of application. Having UDP/IPv6 in the title distracts from the fact that the rest of the draft is a generic mechanism, IMHO.
  *    We have a little tension between using SCHC as an acronym (expliciting Compression) and the use of expressions like "'SCHC Fragmentation" and "SCHC Compression".
  *   Thoughts have been expressed that the applicability of the generic SCHC algorithm is not limited to LPWANs, therefore it should not appear in the title. The rest of the text could still say that "SCHC was originally developed with LPWANs in mind".
  *   Thoughts have been expressed that "static context" is a distinguishing feature, and as such, it should stay in the title.
Can I please get your votes about the following two points:

A) "SCHC"
A.1 remains an acronym meaning "Static Context Header Compression", and we live with the tension described above.
A.2 becomes the acronym to mean "Static Context Header Compression and fragmentation", even though the F does not show in the acronym
A.3 becomes SCHCF and means "Static Context Header Compression and Fragmentation", and we will later figure a pronunciation for it.
A.4 becomes a proper noun, a name that is not spelled out. The text can still mention that the name originated as an acronym for "Static Context Header Compression".

B) RFC title:
B.1 "SCHC: generic framework for header compression and fragmentation using a static context"
B.2 "SCHC: static context header compression and fragmentation for Low-Power Wide Area Networks (LPWANs)"
B.3 ""Static Context Header Compression and fragmentation (SCHC)"
B.4 ""Static Context Header Compression and fragmentation (SCHC) for Low-Power Wide Area Networks (LPWANs)"
B.5 suggest your own!

Your votes by the end of the week would be very much appreciated!
Thanks

Dominique & the co-authors gang

_________________________________________________________________________________________________________________________



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.

_________________________________________________________________________________________________________________________



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.
_______________________________________________
lp-wan mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lp-wan<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flp-wan&data=02%7C01%7Cjuancarlos.zuniga%40sigfox.com%7C2c547d73fa1d4e1cb55d08d7ab105912%7Cfcbc8bb1061e4b949f703ad917b0c8d3%7C0%7C0%7C637165959021695920&sdata=NEBSi1P6hsW%2BPfHfVPw3vPymxMBsiGOYAbb3buk6vbs%3D&reserved=0>

_________________________________________________________________________________________________________________________



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.