Date: 05/11/2024 13:00 (GMT)
Room: Liffy Meeting Room 2
Chairs: Dirk Kutcher, Dave Oran
Notetaker(s): Ryo Yanagida, Rod Van Meter (add yourself)
Speaker(s): Chairs
Speaker: Marc Mosko
Document: draft-irtf-icnrg-flic-06
Dirk: We would like to get this published, so happy to push this
forward today.
(introduces Marc)
Marc: reviews changes to the draft.
Implementation should be caught up with draft "very soon".
David: Has been going on for some time, so we would like to wrap
this up because others are depending on it. We'll move to last-call if
there are no objections.
Hitoshi Asaeda: Currently Cefore does not support nameless because
we have not found usecase for nameless objects. It's great that you
implement using Cefore. But is it really crucial that the nameless is
supported?
Marc: Would be good to discuss further. Old CCNx supported nameless.
David: This warrants some context around history around nameless
objects. Maybe this is worth documenting
Marc: Agreed — Nameless objects are super-compact, powerful and
might be important.
David: Let's take this offline
Marc: Agreed
Dirk:: Do you plan to make the implementation available?
Marc: I will request to merge the FLIC in Cefore implementation once
it's done. CCNPy doesn't involve any changes to Cefore code.
Speaker: Marc Mosko
Document: draft-mosko-icnrg-ccnxchunking-03
Marc: Reviews history of segmentation, inc. 2018 email from Marc on
ndn-interest mailing list (URL in slides).
Chunk IDs start at 0, FinalChunkID included in every packets. All Chunks
except last are fixed size to facilitate seek. FCID can be changed in
the sequence of Chunks. In cases where the sequence shrink mid chunking,
send a correcponding set of chunks to longest chunks to make sure it is
not hijacked.
Rod Van Meter: In the slides, there are ChunkID, last chunk, Final
Chunk etc. various terms. Will the terms be consistent in the draft?
Marc: The draft might contain some inconsistencies
Rod: I'm not sure if it's a good idea to allow variable final chunk
id
Marc: Main reason to allow it was if there are other fields to put
in, [...]
Dave: I'd like to see experiments where people use variable chunk
size to see if it needs to be disallowed or allowed, this is
experimental anyways. Let's not put it in until it's needed
Marc: Okay
Dave: The chunk number is not mandated to be the low-order part of
the name, if it is not, what would be the consequence of not having it
mandated?
Marc:
Dave: So we could have multiple chunk ids in a name?
Marc: That's possible; but the 'rightmost' chunk-id is the
'operative' ChunkID
Dave: but that might not be the 'lowest-order' part of the name
though
Mark: Correct but 'right-most' chunk-id is the one and it doesn't
have to be the lowest-order
Dave: Perhaps it should be mandated
Mark: Possibly but there are examples where it might make sense not
to...
Dave: Let's be clear about how this name segment should be
Marc: Q: Why not use FLIC? A: You should use FLIC.
Conclusion: We want to adopt this as an RG document, hope it will sail
through, there's not much too it.
Dave: We'll do an adoption call over ML soon, no need to delay on
it.
Speakers: Dave Oran and Hitoshi Asaeda
Document: draft-irtf-icnrg-reflexive-forwarding-00
Dave: Background introduction. One message sequence diagram; does
this match one from the draft?
Hitoshi: Details on spec, inc. terminology, etc. Slides contain
Trigger Interest/Data Message format; included in draft? Next steps: Fix
open issues, TODOs. Please read & comment on draft. Try the in-progress
implementation on Cefore.
Dirk: Please go back to the To-Do slide? We should discuss in the
group about these issues. Perhaps chunking/FLIC is useful if multiple
data is needed from the consumer. Another things to discuss is RPC might
warrant caching TD, we should discuss these things.
Rod: Question about documentation; there were diagrams with packet
formats and message sequence in the slides, it doesn't seem to be
included in the draft, should that be perhaps included in the documents?
Dave: There are pointers back to the existing RFCs wrt the packet
diagrams. If anyone feels anything is missing after looking at those
diagrams in other RFCs, please do suggest!
Hitoshi: Did you see the latest? It is still ASCII but it should be
there already
Rod: I saw it from the link in the agenda so it should be the
latest. The one I saw in the draft was consumer-forwarder-producer but
did not contain c-f-f-p case, should that be in it to clarify?
Authors: Agreed
Christian Amsüss: Is the RNP_ID consistent end-to-end?
Hitoshi: Correct, for same stream. But each stream should be
different. RNP_ID is like a temp content name. Multiple things are sent
over mulitiple RNP_IDs should be used.
Speaker: Jungha Hong
Document: draft-hong-icn-metaverse-interoperability-00
Jungha: Introduces document fairly linearly.
Aijun Wang: Do you have a plan to solve the interoperability issue
for the Metaverse?
Jungha: We don't have an ongoing plan but we are developing a
service scenarios in ITU-T etc. maybe we can collaborate with them in
the future.
Dave: Please do send comments over ML.
Speaker: Aijun Wang
Document: draft-li-icnrg-damc-02
Aijun: Proposes creation of IETF DMSC WG as outgrowth of icnrg, "to
industrialize the ICN".
Daniel Huang: Good idea to bring ICN work to IETF for microservice,
but keep in mind that we need to keep delicate balance between benefit
and cost. We may also need a new name.
Ryo Yanagida: Are you soliciting any work from icnrg? Do you think
it's ready to be brought into IETF? I think maybe some more work in
icnrg.
Aijun: I think it's ready. Certainly we need more research work.
Will hold several BoF meetings.
Speakers: Chairs