Re: [lp-wan] [Schc] Draf on OAM

Hello Laurent and Dominique,

I've read the new version of the OAM draft. I got some comments.

This document introduces some elements to the architecture that are not
defined in the draft-architecture. We need to discuss about this problem,
because I think you are developing a use case dedicated to a special type
of device. And so, how to introduce these proxies in a very general
architecture?

Moreover, the solution you are describing is dedicated to LPWANs, more
exactly a very restrictly device with few connectivity, memory, etc. Which
bring another issues that have not been solved yet. There are some big
security questions, and how much time the security-relation is alived? how
many devices the proxy may serve ?

- In the yang data model you have put all the options of the ICMPv6
protocol but for the moment in the document you only develop the Echo
Request/Reply. It will be difficult to make the difference between these
legacy devices and the other to use the icmpv6 protocol. Are you planning
to develop a ICMPv6 document for non-LPWAN legacy devices?
-In section 3. Usecase second bullet, the core SCHC may use or not the
proxy. How to manage these possibilities for not receiving two packets?
-In section 4.1. You recommend 3-bits for SN, this is only in the ping
case? or in general? How does this interoperates with a node sending a 16
bits SN, the Rule will not match?
-In section 4.1.1. Rule example (table1). The rule you are describing is
not complete, isn't it? Instead of Value the correct name if Target Value
and also why the SN with FL=16 has an MSB(24)?
[Ana] While using SCHC with the Echo Reques/Reply you may have the complete
IPv6 packet because the compression reduce the size of the packet and you
will have more MTU. So you may compress the payload with SCHC and got more
place?
-Section 4.2 "... so CDAs are not necessary and set to "not-sent"." I don't
understand this sentence, do you mean the target value is necessarily and
the CDA is not-sent?
-Table2 same comment as table 1
- Section 4.2.1 After table 2. you say that type and code are elided and
the identifier has to be sent, but in the Rule you put it as not-sent
- Section 4.3 after Figure 3. "... assume no rule matches the incoming
packet (i.e. there is no co-compression rule). Do you mean that for this
device the no-compression rule that is mandatory in RFC8724 is not used?
- In table 3. same comment as table 1 and 2 and also you have not define
Checksum nor Value/Unused fields
- After Table 4. you talk about a Value field. But it is very confusing you
are talking about Target Value or the Vaue field?

Ana

On Tue, Jun 27, 2023 at 5:17 PM Laurent Toutain <
laurent.toutain@imt-atlantique.fr> wrote:

> Hi,
>
> With Dominique we issued a new version of the draft on OAM with the change
> we presented last interim meeting. I forgot to adjust the meta data and it
> has been published on lpwan with version 5 and schc with version 0. They
> are similar, but, of course, the one in the schc wg which matter.
>
> Laurent and Dominique
> --
> Schc mailing list
> Schc@ietf.org
> https://www.ietf.org/mailman/listinfo/schc
>