Re: [lp-wan] augment coupond-ack

yes

On Mon, Nov 15, 2021 at 9:08 AM Alexander Pelov <a@ackl.io> wrote:

> Dear Laurent,
>
> Thanks for getting the ball rolling on this one so quickly after the IETF!
>
> On 1) - when you say "ignore the compound-ack from RFC8724" - there is no
> compound-ack in RFC8724.
> Do you mean this to be - keep the Yang Data Model aligned with RFC8724 and
> not include compound-ack in it?
>
> (and thus -> define an extension in the SCHC-Compound-Ack draft ?)
>
> Cheers,
> Alex
>
>
>
> On Mon, Nov 15, 2021 at 8:51 AM Laurent Toutain <
> laurent.toutain@imt-atlantique.fr> wrote:
>
>> Dear lpwaners,
>>
>> During the last IETF meeting, it was asked to detach the compound-ack
>> from the RFC8724 model. I see to ways of doing it.
>>
>> 1) ignore completely the compound-ack from the RFC8724 data model and
>> augment this model such as:
>>
>> augment
>> "/schc:schc/schc:rule/schc:nature/schc:fragmentation/schc:mode/schc:ack-on-error"
>> {
>> leaf bitmap-format {
>> type compound-ack:bitmap-format-type;
>> when "derived-from(../schc:fragmentation-mode,
>> 'schc:fragmentation-mode-ack-on-error')";
>> default "compound-ack:bitmap-RFC8724";
>> description
>> "How the bitmaps are included in the Ack message.";
>> }
>> }
>>
>>
>> Where we create the leaf and a specific identityref for compound-ack.
>>
>> 2) create the leaf in RFC8724 datamodel but just a default value and just
>> define the compound ack value in the compound ack model.
>>
>> Personally, I prefer the first approach, since we cannot guess all the
>> time what will be extended, but I would like to have your point of view on
>> the subject.
>>
>> Laurent
>> _______________________________________________
>> lp-wan mailing list
>> lp-wan@ietf.org
>> https://www.ietf.org/mailman/listinfo/lp-wan
>>
>