Re: [lp-wan] SCHC Yang module review

[Laurent Toutain <[e-mail]>]

Thank you Dominique for the review.

My comments in line:

On Mon, Dec 13, 2021 at 3:40 PM <[e-mail]> wrote:

> Dear LPWAN WG,
>
>
> Following our interim meeting last week, I gave a look at the current SCHC
> Yang model with respect to RFC 8724 Appendix D. Here are my comments:
>
> - the fragmentation-content grouping describes all the parameters needed
> by any of the fragmentation modes. It could be more specific as to which
> are mandatory for each mode, and which are not required (irrelevant) for
> each mode (e.g. Retransmission Timer or MAX_ACK_REQUESTS in No-ACK mode).
> This might help catching errors early.
>

That's a good point, we can add When statement for this one.

> - the support for interleaved fragmented packet transmission is not
> described in the yang model. Do we need it? The DTag size (T) is an
> indication that interleaving might be supported or not, but a profile might
> want to specify e.g. that interleaving 3 packets is mandatory, while T==2
> says that up to 4 packets could be interleaved.
>
Good discussion for the group, we try to implement just what is defined in
RFC8{7|8}24, do you introduce more specific and useful information in the
model?


> - similarly, the "lifetime of DTag at the receiver" is not in the Yang
> model. Shall it be? Or is it part of a priori knowledge from the profile?
>

I don't catch this point, isn't it linked to inactivity timer?

> - Appendix D says that a profile, if Ack-on-Error is used, must define "if
> the penultimate tile of a SCHC Packet is of the regular size only or if it
> can also be one L2 Word shorter". I haven't found such information in the
> Yang model. Shall it be? Or is it part of a priori knowledge from the
> profile? I would assume that this would depend on the tile size,
> therefore vary by rule, therefore should be in the Yang model.
>

For me there was not option, it is always done.

> - I'm unclear that ack-behavior in the Yang model captures the intention
> of RFC8724. The description of ack-behavior-after-All0 says that an ACK
> is expected after an All-0, and the description of ack-behavior-after-All1
> says that an ACK is expected after an All-1, but the two are not exclusive,
> while ack-behavior cannot be equal to both. Likewise ack-behavior-always is
> described like an ACK is expected after every fragment, I think it wanted
> to say after every window. These pertain to different fragmentation modes
> (Ack-on-Error and Ack-Always).
>

May be the erm always is not well chosen and need more explanation, It is
more the ack are sent when the L2 allowed it.

>
> - WINDOW_SIZE [RFC8724] is incorrectly described as maximum-window-size
> (Yang model). The window_size is the max tile index + 1, while the max
> window size is 2^M-1
>

The goal was to limit the maximum value for FCN and not always having
2^M-2

> - typo in the description : fcn-size is M, not N
>
>
> ok

> There are another few features I'm unsure about, I'm still learning Yang.
>
> I think a little more work is needed on the SCHC Yang module.
>

I agree and your review is extremely valuable.

Thank you

Laurent

>
> Best regards
>
>
> Dominique
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>