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

From: <[email-masked]>
Date: Thu, 6 Feb 2020 12:51:13 +0000

My vote is for A.4 B.1
Best regards

Dominique

De : lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of Dominique Barthel <[email-masked]<mailto:[email-masked]>>
Date : Thursday 6 February 2020 10:55
À : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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.

---

From: Alexander Pelov <[email-masked]>
Date: Thu, 6 Feb 2020 15:01:07 +0100

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 ).
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 <[email-masked]> wrote:

> My vote is for A.4 B.1
> Best regards
>
> Dominique
>
> De : lp-wan <[email-masked]> on behalf of Dominique Barthel <
> [email-masked]>
> À : "[email-masked]" <[email-masked]>
> 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*".
>    - 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.
>
> 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:
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Thu, 6 Feb 2020 11:13:11 -0300

All,
My vote is A1 B5.
Regards,

             Diego

Le jeu. 6 févr. 2020 à 11:01, Alexander Pelov <[email-masked]> a écrit :

> For a short example - take a look at the RFC page of Wikipedia still
> states that RFC means "Request for Comments" (
>>    - 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.
>> A.1 remains an acronym meaning "Static Context Header Compression", and
>> we live with the tension described above.

-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125

---

From: <[email-masked]>
Date: Thu, 6 Feb 2020 14:24:00 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date : Thursday 6 February 2020 15:01
À : Dominique Barthel <[email-masked]<mailto:[email-masked]>>
Cc : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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 ).
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 ;)

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 <[email-masked]<mailto:[email-masked]>> wrote:
My vote is for A.4 B.1
Best regards

Dominique

Hello all,

A) "SCHC"

B) RFC title:

_______________________________________________
lp-wan mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lp-wan

---

From: Olivier Gimenez <[email-masked]>
Date: Thu, 6 Feb 2020 14:24:26 +0000

Hi,

I vote for A3 B1.
Even if B1 might be easier to read as “SCHC: generic framework for fragmentation and header compression using a static context” because the is no ambiguity that fragmentation applies to all packet and not only the header

Olivier

To view our privacy policy, including the types of personal information we collect, process and share, and the rights and options you have in this respect, see www.semtech.com/legal.

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Thu, 6 Feb 2020 14:47:58 +0000

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 <[email-masked]> On Behalf Of [email-masked]
Sent: February 6, 2020 9:24 AM
To: Alexander Pelov <[email-masked]>
Cc: [email-masked]
Subject: Re: [lp-wan] SCHC RFC-to-be title?

Hello Alex,

Dominique

Hi all,

Thanks Dominique !

(chair hat off)

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 ;)

Cheers,
Alexander

Dominique

Hello all,

A) "SCHC"

B) RFC title:

Thank you.

Thank you.
_______________________________________________
lp-wan mailing list
[email-masked]<mailto:[email-masked]>
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>

Thank you.

---

From: Julien CATALANO <[email-masked]>
Date: Thu, 6 Feb 2020 17:36:06 +0100

Dear all,

My votes goes for A.1 B.1* as stated by Olivier: "SCHC: generic
framework for fragmentation and header compression using a static context".

Cheers
Julien

Le 06/02/2020 à 15:24, Olivier Gimenez a écrit :
>
> Hi,
>
>  
>
> I vote for A3 B1.
>
> Even if B1 might be easier to read as “SCHC: generic framework for
> fragmentation and header compression using a static context” because
> the is no ambiguity that fragmentation applies to all packet and not
> only the header
>
>  
>
> Olivier
>
>
> To view our privacy policy, including the types of personal
> information we collect, process and share, and the rights and options
> you have in this respect, see www.semtech.com/legal.
>

---

From: Ivaylo Petrov <[email-masked]>
Date: Fri, 7 Feb 2020 08:58:05 +0100

Dear all,

My vote goes for A1 and B1* as stated by Olivier.

Cheers,
Ivaylo