Agenda: on datatracker
Meeting material: on datatracker
Meeting link: Meetecho Link
Live Minutes: CODIMD Link
Pascal : add a securtity section to the architecture about possible attacks based on compromised model installed in the router
Laurent : add a securtity section to the yang data model about possible attacks based on compromised model installed in the router, noting that there is no method for an infinite writing loop
Sergio to publish 05 and chairs will start WGLC
See slides, Laurent explains the fixes he made as written
Laurent: removed excerpts of YANG model from body of text, so doc should be easier to read now
asking Eric about hos commentr on convention. Useless to retain "Convention for" in every 3.X sub section, just use it in 3.
TargetValue: now only a binary value, text says string has to be converted to binary, but does not say how.
Do we have to make it more explicit?
Dominique: need to say "as encoded in the header of the protocol being compressed".
Tom (on mailing list): All1 is hard to read. Laurent: sugegst to use ALL1
Pascal: RFC 8724 uses All-0 and All-1
Éric: the dash is very important. And usually all lowercase is used in YANG models.
Security considerations: need to reference NETCONF/RESTCONF?
Éric: the security considerations template recurring issue with YANG models. Need to copy first paragraphs of template into doc.
This (security considerations) needs to go into the arch doc as well.
Sergio: handling the reviews from Dominique. The latest version is not yet on the Datatracker.
Removed any reference to SCHC receiver abort.
Added the padding bit specification - so that you only have M bits "0" in order to signal the end of the compound ack.
Removed refs to RFC 9011
Sergio: presents the changes
Pascal: do you think it is ready for WGLC?
Sergio: yes, after this version is published, it is ready
How to know in-band that ESP is SCHC-compressed?
Diet-ESP does some compression but want to go to full SCHC. How do we know it is SCHC? We can't count on spoofing and trying to guess this is SCHC.
SCHC as a new IP protocol? Next header is SCHC rule. Makes implmeentation much cleaner. Especially for end-to-end SCHC, across several (potentially parallel) networks.
Pascal: there is the work on SCHC-over-PPP
Bob: this is about signaling that the payload is SCHC
Laurent: could be useful for 6LoWPAN as well. If we have an upper layer protocol that is SCHC
Bob: having SCHC's own tunneling and see where it goes from there.
Pascal: there is a question about the session - there might be several sessions between two endpoints.
Bob: you can handle sessions, as in DTLS with CID.
Pascal: you need to negociate
Bob: how do you recognize
Bob: IKE and SPY - they figure out how the sessions work.
Alex: if there is a use case, explore it
Pascal: do you need IPv4 / IPv6 ?
Bob: rough out a draft and start a discussion, but maybe both
Pascal: if it's only IPv6 then that could be done with Next Header
Laurent; if we have a new Next Header, do we need to have a L4 protocol ?
Bob: Next Header SCHC (0 Bytes) and then you see UDP compressed to 0 and DTLS
Laurent; something we discussed with Carles, which could be related - SCHC on Mesh networks