Subject: [lp-wan] Closed: Ticket #19: Fragmentation Terminology

From: Ana Minaburo <[email-masked]>
Date: Tue, 22 May 2018 14:56:16 +0200

Hello,

I've closed this ticket, you will find the details:

https://trac.ietf.org/trac/lpwan/ticket/19

Ana

On Wed, May 16, 2018 at 2:22 PM, Ana Minaburo <[email-masked]> wrote:

> Hello,
>
> Thanks for your answer, I agree with you, and I think that was my first
> idea to put them separetely, and then I changed if idea and I global all
> the byte boundary stuff in one ticket. If you prefer to have two tickets
> open that works for me.
>
> One for the boundary after the first 8-bit chunk and the other ( the
> ticket 11) with a boundary in consecutive chunks
>
> Ana
>
> On Tue, May 15, 2018 at 6:03 PM, <[email-masked]> wrote:
>
>> Hello Ana, all,
>>
>> I think that the first two items in the list below are covered.
>> Hoverever, in version –11 of the draft, I still see "byte boundary",
>> which you described as "wrong" in the Ticket.
>> I'm not too sure it's actually wrong. To me, a byte boundary within a
>> flow of bits means a boundary between any consecutive chunks of 8 bits in
>> the flow, not just the boundary after the first 8-bit chunk.
>>
>> Anyway, we could replace
>> |<------ byte boundary ------->|
>> with
>> |         next byte boundary ->|
>> To show that all we are interested in is locating the upcoming boundary,
>> not the size of this chunk from the beginning of the header.
>>
>> What do you think?
>>
>> Dominique
>>
>> De : lp-wan <[email-masked]> on behalf of Ana Minaburo <
>> [email-masked]>
>> Répondre à : "[email-masked]" <[email-masked]>
>> Date : Monday 26 February 2018 22:39
>> À : lp-wan <[email-masked]>
>> Cc : "[email-masked]" <[email-masked]>
>> Objet : [lp-wan] Ticket #19: Fragmentation Terminology
>>
>>
>>    - Fragmentation Modes: No-ACK, ACK-Always, and ACK-on-Error eliminate
>>    the Window separation
>>
>>
>>    - In order to avoid confusion about Bitmap optimization, which could
>>    be seen as optional we would like to use the term Bitmap encoding
>>
>>
>>    - We need to define a term to be used for the byte boundary. Because
>>    we need to express an integer number of bytes, we put wrongly byte boundary
>>    which means 1 byte but could be more than one but complete bytes
>>
>>
>> _________________________________________________________________________________________________________________________
>>
>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/lp-wan
>>
>>
>