Re: [lp-wan] [Schc] draft-architecture-02 inputs

[Ana Minaburo <[e-mail]>]

Hello Pascal,
Here I left the other threads. Please take a look at my comments below.


Ana


> -IOW.  Can you give the meaning of the acronym?
>
> (it is used in section 5.1, fifth paragraph.)
>
> Sorry for this. See https://www.computerhope.com/jargon/i/iow.htm
>
[Ana] I think we need to keep the formal language ;)

>
>
>
>    - 2 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?
>
>
>
> See 8.2.2.4.
> <https://datatracker.ietf.org/doc/html/rfc8724#section-8.2.2.4>Timers and
> Counters
> <https://datatracker.ietf.org/doc/html/rfc8724#name-timers-and-counters> in
> RFC 8724, then whatever else the implementation needs.
>
>
>
> - This information will be defined or is already defined in which
> document?
>
>
>
> The IETF does not define the content and format of internal data of the
> implementation beyond some abstractions. But it has to be there nevertheless
>
>
>
> - Is it something the parser or the Rule Manager performs?
>
>
>
> Sure. That’s the operational context of the instance.
>
[Ana] You are referring to fragmentation parameters in a fragmentation
Rule. This merits to be cleared.

>
>
>
>
>
>
>    - 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?
>
>
>
> Do we need examples? If so, think about a rule that leaves the destination
> address in full in the residue, and then 10 other rules, each with a
> hardcoded prefix of where the destination is usually located. Using the
> first rule only produces a larger residue which is detrimental to
> bandwidth. Using the 10 rules (and then the 1st one as plan B) generates
> more rules which is detrimental to memory. It is a tradeoff. The
> architecture describes the capability for the user to manipulate that
> tradeoff. But we do not want to get into the gory details of how this is
> done in a case by case.
>

[Ana] I see what you mean. This, for me, is an implementation issue. The
number of Rules your device supports will depend on its capabilities. Again
I think an LPWAN device will be much less resilient than one connecting
through a WiFi, PPP, or another network.


>
>
>    - 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?
>
>
>
> Not sure this belongs to the architecture.  It’s probably a concern for
> the deployment per industrial alliance. How far would you like this
> described here?
>
[Ana] I agree with you.


>
>
>
>    - 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
>    -
>
>
>
> Please pull req 😊
>

[Ana] I sent it today.

On Wed, May 17, 2023 at 12:03 PM Pascal Thubert (pthubert) <
[e-mail]> wrote:

> Hello Ana 😊
>
>
>
> Sorry to be late on this. Had hot stuff on my plate.
>
>
>
> A pull request would be nice indeed. Let’s see below
>
>
>
>
>
>    - 1. Terminology
>
>
>
> The big question for terminology is whether RFC 8724 is the reference. We
> need to discuss that. For the new comer, the architecture should be the
> reference. Even if that means impacting RFC 8724.
>
>
>
>
>
> -set of rules or set of Compression/Decompression (C/D) rules.
>
> > Is it the context or something else?
>
>
>
> Yes. My problem is that the real “context”, understood as operational
> environment, should represent all the data associated to a particular
> instance, and each instance should have its own.
>
> RFC 8724 uses “context” for a rule set, which is instantiated for each
> instance, and does not represent the whole context of that instance.
>
>
>
> -rule database. I didn't find any definition for it. Does it mean a
> context plus something else? or only context?
>
>
>
> The text says
>
> “
>
> select from the rule database the set of rules that apply to the SCHC
> Device, and the current state of their exchange, e.g., timers and previous
> fragments.
>
> “
>
> For the lack of a better term we used database. Happy to fix it. That’s
> the operational environment I was talking about and the set of instantiated
> rules is just a component of that. The state includes timers and whatever
> else this instance is manipulating.
>
>
>
> -Rule set. Do you mean context?
>
>
>
> Does context mean instantiated or not? Like the rules could have $IP for
> the source IP and then once instantiated for a device it becomes 2001:dba::1
>
>
>
>
>
> -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.)
>
> Sorry for this. See https://www.computerhope.com/jargon/i/iow.htm
>
>
>
>
>
>
>
>
>
>    - 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.
>
>
>
> Agreed. This should be discussed on the list since it is an attack vector.
> Someone inserting a “better match” can turn a decompressor into a bomber.
> Let us start a thread on this.
>
>
>
>    - 2 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?
>
>
>
> See 8.2.2.4.
> <https://datatracker.ietf.org/doc/html/rfc8724#section-8.2.2.4>Timers and
> Counters
> <https://datatracker.ietf.org/doc/html/rfc8724#name-timers-and-counters>
> in RFC 8724, then whatever else the implementation needs.
>
>
>
> - This information will be defined or is already defined in which
> document?
>
>
>
> The IETF does not define the content and format of internal data of the
> implementation beyond some abstractions. But it has to be there nevertheless
>
>
>
> - Is it something the parser or the Rule Manager performs?
>
>
>
> Sure. That’s the operational context of the instance.
>
>
>
>
>
>
>
>    - 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?
>
>
>
> The text says
>
> “
>
> For instance, the SCHC session can be associated one-to-one with a tunnel,
> a TLS session, or a TCP or a PPP connection.
>
> “
>
> The way to recognize one of those things depends on that thing. The IP
> address is usually part of that. But say you do SCHC over MPLS, then it
> will be the label.
>
>
>
> - Are you thinking of something else?
>
>
>
> Yes.
>
>
>
>
>
>    - 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.
>
>
>
> The model is a “type” descriptor. We need to locate and download
> instances. For that we need names. Think about a node that understands
> coreconf, looking for its rules.
>
> What would be the name and locator? Can we provide a URI/URN/URL for that?
>
>
>
>
>
>    - 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.
>
>
>
> Another good thread to have. How this is done would be left to be defined.
> E.g., exactly when do the new rules apply? It seems safer/simpler to
> negotiate a new “context” and then start a new session with that new
> context.
>
>
>
>
>
>    - 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?
>
>
>
> Do we need examples? If so, think about a rule that leaves the destination
> address in full in the residue, and then 10 other rules, each with a
> hardcoded prefix of where the destination is usually located. Using the
> first rule only produces a larger residue which is detrimental to
> bandwidth. Using the 10 rules (and then the 1st one as plan B) generates
> more rules which is detrimental to memory. It is a tradeoff. The
> architecture describes the capability for the user to manipulate that
> tradeoff. But we do not want to get into the gory details of how this is
> done in a case by case.
>
>
>
>    - 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?
>
>
>
> Not sure this belongs to the architecture.  It’s probably a concern for
> the deployment per industrial alliance. How far would you like this
> described here?
>
>
>
>    - 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.
>
>
>
> Where do you get the instance of the model from? How do you identify it if
> not by URN / version?
>
> The rules be hardcoded in the device, but not in the GW. And it would be
> better that the device can download an update. How will the device identify
> that update and get it?
>
> Even if a network manager pushes the rules on a device or GW, there is
> still a need to identify them, e.g., when the network manager gets them
> from the device vendor.
>
>
>
>    - 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
>    -
>
>
>
> Please pull req 😊
>
>
>
> Pascal
>
>
>
>
>
> *From:* Schc <[e-mail]> *On Behalf Of *Ana Minaburo
> *Sent:* Tuesday, May 9, 2023 5:50 PM
> *To:* Pascal Thubert (pthubert) <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* [Schc] draft-architecture-02 inputs
>
>
>
> 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
>
>
>
>
>