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

I agree we have to redefine clearly the terminology, as you say there is 3
level:

- Set of Rule which contains the compression rules and the fragmentation
parameters and their associated Rule ID used by a pair of nodes and the
should be exactly the same in both position (that the main axiom of SCHC)
- Set of Rule + way to identify the other end : this is not clear how to
name it, let's call it X. X could be
   - context to have a context since context is in the SCHC acronym,
   - session or instance since they can differ in time for instance if for
example TCP is used to carry SCHC message and a new connection is open
(that's just an example)
- Set of X, all the thing a SCHC entity have to talk with the other pairs.
I like Rule Database.

Laurent

On Wed, Jun 7, 2023 at 2:00 PM Ivan Martinez Bolivar (Nokia) <
ivan.martinez_bolivar@nokia-bell-labs.com> wrote:

> Hello Ana, SCHCers.
>
> Thanks for bringing this to our attention,
>
> I think we should keep things as simple as we can because introducing more
> terms would just make it more difficult.
>
> What if we consider a context to be a "set of instantiated rules"?.
> Therefore, this context consists of a set of rules plus the necessary
> metadata (timers, ... ) to identify the other end and stablish the SCHC
> instance (session).  If the instance is not used, we only have context as
> the Set of Rules (i.e no metadata just the information required to make the
> C/D and F/R)
>
> The Set of Rules gives the information required to make the C/D and F/R
>
> Since this meta data might vary during the same session (for example, TCP
> Flow or modifying rules using CORECONF, which are new cases where SCHC can
> be applied, ...), this new understanding of context is different from that
> in 8724.
>
> Then we just have two terms: Context and Set of Rules and we forget about
> "Rule set", "Rule Database"
>
> Ivan.
>
> ---
>
> Hello Pascal,
>
> I've divided my mail into different threads to discuss each point
> individually.
>
> I've copied the initial discussion.
> ---
>
> The big question for terminology is whether RFC 8724 is the reference.
> We'll need to talk about that. For the newcomer, the architecture should be
> the reference, even if that means impacting RFC 8724.
>
>
>
> [Ana] We need to make this draft the reference and agree if the
> terminology of RFC8724 is used, which could be a good thing for those that
> have already read it and implemented it. For the newcomers, at least until
> we find a consensus, they must read RFC8724, and follow this discussion. Of
> course, I'm for finding a consensus and using it. Let's try to agree and
> find good terminology.
>
>
>
> -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 an operational
> environment, should represent all the data associated with 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 a 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
>
>
> [Ana] Do we need to introduce the instance parameter in the definition of
> context?
>
> You use it, so we must differentiate each instance from the whole.
>
> Introducing the instantiating parameter makes us three terms.
>
> - Context. In an operational environment should represent all the data
> associated with a particular instance, and each instance should have its
> own.
>
> - Set of Rules. Is the context instantiated for each instance
>
> - Rule set. Is the instance used in a device
>
>
> For instance, if the instance is not used, we only have context as the
> information required to make the C/D and F/R.
>
>
> How are things most precise? With or without this instance parameter?
>
> In my opinion it is easier to only have context.
>
>
>
> Ana
>
>
>
>
>
> _______________________________________________
> lp-wan mailing list
> lp-wan@ietf.org
> https://www.ietf.org/mailman/listinfo/lp-wan
>
>
> --
> Gracias
> Ivan Marino
> --
> Schc mailing list
> Schc@ietf.org
> https://www.ietf.org/mailman/listinfo/schc
>

-- 
Laurent Toutain
+------ VoIP (recommended) ---+--- Télécom Bretagne --- +
| Tel: +33 2 22 06 8156             | Tel: + 33 2 99 12 7026    | Visit :
| Fax: +33 2 22 06 8445            | Fax: +33 2 99 12 7030   |
http://class.touta.in
| Laurent@Touta.in                   | Laurent.Toutain@Telecom-Bretagne.eu
+----------------------------------------+--------------------------------+