Re: [lp-wan] Small point about calling it a "MIC"

+1 for RCS

On Thu, Mar 28, 2019 at 3:39 PM Juan Carlos Zuniga <
juancarlos.zuniga@sigfox.com> wrote:

> +1
>
>
>
> *From:* lp-wan <lp-wan-bounces@ietf.org> *On Behalf Of *Laurent Toutain
> *Sent:* March 28, 2019 2:59 PM
> *To:* ana minaburo <ana@ackl.io>
> *Cc:* Charlie Perkins <charles.perkins@earthlink.net>; lp-wan <
> lp-wan@ietf.org>; Carsten Bormann <cabo@tzi.org>; carlesgo@entel.upc.edu;
> BARTHEL Dominique IMT/OLPS <dominique.barthel@orange.com>
> *Subject:* Re: [lp-wan] Small point about calling it a "MIC"
>
>
>
> +1
>
>
>
> On Thu, Mar 28, 2019 at 2:54 PM ana minaburo <ana@ackl.io> wrote:
>
> +1 for RCS
>
>
>
> Ana
>
>
>
> On Thu 28 Mar 2019 at 11:27, <dominique.barthel@orange.com> wrote:
>
> I was leaning towards something similar to what Carles just suggested.
> More specifically, in order to emphasise the fact the our "MIC" *only*
> protects the Fragmentation/Reassembly process, I was thinking RCS
> (Reassembly Check Sequence).
> I believe it does not convey the wrong impression that an unfragmented
> SCHC Packet is somehow covered by it.
> I trust it looks close enough to FCS for IEEE to feel comfortable with it,
> and it's easier to pronounce than SPCS.
>
> Opinions?
>
> Dominique
>
> Le 28/03/19 10:56, « lp-wan on behalf of Carles Gomez Montenegro »
> <lp-wan-bounces@ietf.org on behalf of carlesgo@entel.upc.edu> a écrit :
>
> >Hi,
> >
> >Strictly speaking, our current "MIC" allows to validate the correctness of
> >a reassembled "SCHC Packet" (which is a term defined by the SCHC draft).
> >
> >Perhaps we could talk in terms of a "SCHC Packet Check Sequence".
> >
> >The acronym could be "SCS" or "SPCS", or even "PCS".
> >
> >Thoughts?
> >
> >Cheers,
> >
> >Carles
> >
> >
> >> What are we protecting?
> >>
> >> [_] Message [_] Frame [_] Packet [X] Datagram
> >>
> >> What is it being used for? Toâ€¦
> >>
> >> [X] Check [_] Integrity check [as in security]
> >>
> >> What is it?
> >>
> >> [_] Sum [X] Sequence [x] Word [X] Bits [X] Value
> >>
> >> What should we pick?
> >>
> >> GrÃ¼ÃŸe, Carsten
> >>
> >>
> >>> On Mar 27, 2019, at 15:21, Charlie Perkins
> >>> <charles.perkins@earthlink.net> wrote:
> >>>
> >>> Hello folks,
> >>>
> >>> Yesterday I tried to describe some conversation about MIC versus FCS
> >>> which happened during the recent IEEE 802.15 meeting.  The conclusion
> >>> there, was that "MIC" isn't a good name for what SCHC specifies,
> >>>because
> >>> a MIC is considered to be something that offers a stronger guarantee of
> >>> integrity than can be provided by the checksums recommended in the SCHC
> >>> document.
> >>>
> >>> I don't think FCS (i.e., "Frame Check Sequence") is exactly right
> >>> either, because what is being checked is a reassembled packet, not a
> >>> frame.  That is, if you think a frame is a layer-2 bitstring versus a
> >>> packet being a layer-3 bitstring (I'm running out of words).
> >>>
> >>> One possibility is to simply call it a checksum (abbreviated CHK?).
> >>>
> >>> Regards,
> >>> Charlie P.
> >>>
> >>> _______________________________________________
> >>> lp-wan mailing list
> >>> lp-wan@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/lp-wan
> >>>
> >>>
> >>
> >> _______________________________________________
> >> lp-wan mailing list
> >> lp-wan@ietf.org
> >> https://www.ietf.org/mailman/listinfo/lp-wan
> >>
> >
> >
> >_______________________________________________
> >lp-wan mailing list
> >lp-wan@ietf.org
> >https://www.ietf.org/mailman/listinfo/lp-wan
>
>
>
> _________________________________________________________________________________________________________________________
>
> 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
> lp-wan@ietf.org
> https://www.ietf.org/mailman/listinfo/lp-wan
>
> _______________________________________________
> lp-wan mailing list
> lp-wan@ietf.org
> https://www.ietf.org/mailman/listinfo/lp-wan
>
> _______________________________________________
> lp-wan mailing list
> lp-wan@ietf.org
> https://www.ietf.org/mailman/listinfo/lp-wan
>