Hello Daniel
we are cancelling the next SCHC interim but the one on Feb 25th is
open and if you like we can have that discussion then?
all the best
Pascal
Le lun. 27 janv. 2025 à 21:14, Daniel Migault <mglt.i...@gmail.com> a
écrit :
Hi,
For clarification we do acknowledge that SCHC required additional
work. We are definitely willing to be more aligned to SCHC and
more than happy to work on it with you. We will contact you to
arrange a meeting.
Yours,
Daniel
On Mon, Jan 27, 2025 at 3:40 AM Laurent Toutain <laur...@touta.in>
wrote:
Hi Daniel,
May be it is clear from a IPsec perspective, but not from a
SCHC perspective.
I think that to be called SCHC, the compression description in
your draft must be aligned with the vocabulary on RFC8724 and
forthcoming architecture. The notion of rule looks ambiguous
in your draft, looks more like an entry in the SCHC
terminology, making hard to follow where you are going. Same
thing for the tables, in RFC 8724 and 8824 you have an
"unformal" way to describe how the header fields are
compressed. This has to be defined. This helps also to create
the augmentation the RFC9363 Data Model to add the FID and
MO/CDA you are defining in your draft.
We can work on it if you want.
Laurent
On Mon, Jan 27, 2025 at 3:03 AM Daniel Migault
<mglt.i...@gmail.com> wrote:
Hi,
This iteration has taken into account a considerable
number of comments that have been received to date. While
some comments related to SCHC are still pending
resolution, those concerning IPsec appear to have been
addressed. Consequently, this version can serve as a solid
foundation for subsequent reviews.
The current version is available here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-diet-esp/
The diff can be seen here:
https://author-tools.ietf.org/diff?doc_1=draft-ietf-ipsecme-diet-esp-04&doc_2=draft-ietf-ipsecme-diet-esp-03
<https://author-tools.ietf.org/diff?doc_1=draft-ietf-ipsecme-diet-esp-04&doc_2=draft-ietf-ipsecme-diet-esp-03>
Yours,
Daniel
On 2025-01-23 14:51, Ana Minaburo wrote:
Dear Daniel,
Thank you for sharing this work. I appreciate the thought
you've put into it, and it provides us with a good
starting point for further development.
I have found some points for discussion
1. the Strata
In your document, you need 3 strata to compress the
complete stack. And anywhere in the document, you define
the SCHC Header Instance of each stratum.
I understand that for EEC and CTEC strata use a
compressed SCHC Header where there is only one Rule and
the length is zero,
for instance for the IIP strata you must define a SCHC
Header to identify the next protocol in the stack.
2. Terminology
- You need to read the new architecture version and
update your terminology.
- SCHC Context has been removed, and there is only SCHC
SoR for each instance.
In the SoR there is only Rules, there is no context.
- You need to add the SCHC Strata
- You need to define the SCHC Header Instances
- You need to align your terminology section to
draft-architecture
3. SCHC SoR initialization
You talk about a SA (Security Association) that will
generate the corresponding SCHC rules.
For me is not clear what you mean. Will the SA use the
yang data model together with the SA for this generation?
4. SCHC Profile
Until now, a SCHC Profile has been defined for Layer Two
fragmentation parameters.
I'm not sure you are using the correct term for SCHC
profile because you are not doing fragmentation.
It will be good to discuss and see what you mean by Profile.
5. Padding
I'm not a security specialist, but I see you are doing
double padding, one in SCHC compression and the other in
the ESP.
Is it a security reason to do this way? If not SCHC does
not require alignment, so perhaps you can eliminate one
padding
6. SoR and Rules
There is a confusion between Rule and FID. A Rule is a
description of the header fields, all the header fields!
the Rule does not have a direction by itself but each FID
in the Rule has it.
7. Identification of SoR
The architecture draft does not give any way to do this
identification, if you need it, you have to provide the
way to do it. (Section 4.2)
8. Table 1
This table is very confusing, you are defining
parameters, and at the same time, you are inventing TVs.
But in your 'possible values' you mixed between CDAs and
values.
So this Table gives a different approach that is not used
in SCHC
9. New MO / CDA and functions
There are 3 new MO/CDA, I'm not sure you need all of
them. They have not been defined in the RFCs 8724, or
8824, nor the architecture, so you need to present the
need for these new MO/CDA to see their feasibility
We can discuss but the "lower" CDA must be a "compute*"
The "generate" may also be a "compute*"
The MSB(start,end) and LSB (strat,end) functions, as I
understand you are using them for the range. It is
another way to do it, that needs consensus
Ana
On Thu, Jan 9, 2025 at 6:01 PM Daniel Migault
<mglt.i...@gmail.com> wrote:
Hi,
Please find the WGLC for our compressed ESP based on
SCHC. Feel free to share your reviews/comments.
Yours,
Daniel
---------- Forwarded message ---------
From: *Tero Kivinen* <kivi...@iki.fi>
Date: Wed, Jan 8, 2025 at 6:15 PM
Subject: [IPsec] WGLC for draft-ietf-ipsecme-diet-esp
To: <ipsec@ietf.org>
This will start two week WGLC for the
draft-ietf-ipsecme-diet-esp [1].
This last call will end at 2025-01-23. If you have
any comments about
the draft send them to the WG list.
[1]
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-diet-esp/
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
--
Daniel Migault
Ericsson
--
Schc mailing list -- s...@ietf.org
To unsubscribe send an email to schc-le...@ietf.org
--
Schc mailing list -- s...@ietf.org
To unsubscribe send an email to schc-le...@ietf.org
--
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
| laur...@touta.in |
laurent.tout...@telecom-bretagne.eu
+----------------------------------------+--------------------------------+
--
Daniel Migault
Ericsson
--
Schc mailing list -- s...@ietf.org
To unsubscribe send an email to schc-le...@ietf.org
--
Pascal
