[lp-wan] Fwd: draft-architecture-02 inputs

[Ana Minaburo <[e-mail]>]

Hello,
I'm sending this message to LPWAN mailing list.

Ana

---------- Forwarded message ---------
From: Ana Minaburo <[e-mail]>
Date: Tue, May 9, 2023 at 5:50 PM
Subject: draft-architecture-02 inputs
To: Pascal Thubert (pthubert) <[e-mail]>
Cc: <[e-mail]>


Hello Pascal,
I've read the new version of the draft, and I have some comments and
questions. Please let me know if you want me to send a pull request to the
GitHub.

Ana

1. Terminology
We need to be consistent in the terminology used; for the moment, the
RFC8724 is the base. So while reading, I was wondering what is the meaning
of the following terms:

-set of rules or set of Compression/Decompression (C/D) rules.
Is it the context or something else?
RFC8724 defines "Context: A set of Rules used to compress/decompress
headers, or to fragment/reassemble a packet."

-rule database. I didn't find any definition for it. Does it mean a context
plus something else? or only context?

-Rule set. Do you mean context?

-IOW. I don't know any device of this kind. Can you give the meaning of the
acronym?
(it is used in section 5.1, fifth paragraph.)


2. Section 3. In the Static Context Header Compression, in the first
paragraph, it is mentioned: "The rule that matches best is used to
compress."
It is very ambiguous because it can be misinterpreted. Does it refer to the
Rule that matches the complete header, i.e., the Rule with the same FIDs as
the header format? Or do you mean the best compression residue?
RFC8724 leaves to the implementation the choice of the Rule to be used when
multiple valid Rules match.

3. Section 5.2 SCHC Instances mentions that SCHC maintains a state and
timers associated with that Instance (1st paragraph)
- What state and timers are you referring to?
- This information will be defined or is already defined in which document?

- Is it something the parser or the Rule Manager performs?

4. Section 5.2, the fourth paragraph at the end, says, "The session can be
associated one-to-one with a ... connection."
- What represents a session association? Do you mean the session uses the
IP address?
- Are you thinking of something else?

5. Section 5.2, the fifth paragraph, where you introduce the draft PPP.
"... the rules can be fetched on-demand by both parties from the same URN"
This can be only one option. How about using CORECONF/YANG for discovering,
updating, creating, and deleting Rules?
The CORECONF/YANG provides tools to automate configuration tasks across
heterogeneous devices in a network. It will provide scalability and
consistency.
A URN may be more easily attacked than the yang model, and you will need to
create an infrastructure to create, update and give access to the
information. The Netconf/yang data model proposes all those things.

6. Section 5.3, the first paragraph, "rules cannot be modified during the
session"
I agree with this point defined for the LPWAN applications and star
topology, but how about other topologies like E2E and mesh and other
applications like video on demand, audio, or web browsing? The Rules may
not be fixed during a session, and the context needs to be updated in the
same session.

7. Section 6. SCHC Data Model Last paragraph says, "the tools that generate
the Rules should provide knobs to optimize the Rule set, e.g., more rules
vs. larger residue."
About the 'knobs,' Who define them? What are their uses? Are they in the
Rule?
Can you give some examples? Is this an implementation issue?

8. Section 7.2 Rules publication "Each 'rule set' should have its own URN
and a version"
Who is managing the versioning of the context? Who has all the URN? How
will the URN be known?
We have already worked and published a yang-data model that can keep all
these features. The yang-data model is in each device and gateway, so you
have all the infrastructure to make the management.

9. NITS
-Section 5.1. Fifth paragraph. connection d/c
-Section 5.3. Third paragraph. LPWAN working group/ LPWAN and SCHC working
groups
- Section 6. Second paragraph. to y/t
- Section 6. Second paragraph. to T/t
- Section 7. At the end of the paragraph, a sentence starts with SCHC
- Section 7. At the end of the paragraph, automatic i/o
- Section 7.1. Last paragraph. that r/t
- Section 7.3. First paragraph. touch n/
- Section 7.3. Last paragraph. fetched w/c