From lanwang at memphis.edu  Fri May  1 11:54:20 2026
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Fri, 1 May 2026 18:54:20 +0000
Subject: [Nfd-dev] 
 =?utf-8?q?Named_Data_Networking_Community_Meeting_2026?=
 =?utf-8?b?LCBNYXkgMTjigJMxOSwgMjAyNiAoVmlydHVhbCBFdmVudCk=?=
In-Reply-To: <MN0PR16MB6532424DE525F97F3EC2195FBB202@MN0PR16MB6532.namprd16.prod.outlook.com>
References: <MN0PR16MB6532424DE525F97F3EC2195FBB202@MN0PR16MB6532.namprd16.prod.outlook.com>
Message-ID: <7EC8E83D-9784-455E-B8E1-5389132486B4@memphis.edu>

Just a gentle reminder that the deadline for abstract submission is Monday, May 4, 2026.

Lan

On Apr 17, 2026, at 17:09, Lan Wang (lanwang) <lanwang at memphis.edu> wrote:

Dear Colleagues,
We are pleased to announce that the Named Data Networking Community Meeting 2026 (NDNcomm?26) will be held virtually on May 18?19, 2026 (https://ndncomm2026.named-data.net/). The organizing committee invites researchers, developers, practitioners, and users to participate in and contribute to this year?s meeting.
NDNcomm is an annual gathering of the NDN community, bringing together participants from academia, industry, and government to exchange ideas, share recent progress, and discuss challenges in advancing NDN technology and its applications. We welcome contributions on all aspects of NDN, including but not limited to

  *
NDN in edge, IoT, mobile, and ad hoc environments
  *
 Applications in scientific data, smart cities, and tactical edge systems
  *
 Network management, measurement, and performance evaluation
  *
Experimental deployments and operational experience
  *
 Approaches to advancing NDN development and adoption


This year, we are also particularly interested in contributions from the following emerging areas:

  *
Agentic AI and Networking The rise of autonomous AI agents brings new networking challenges, including naming and identity, dynamic coordination, and trust in open, multi-agent environments. We welcome contributions exploring how agentic AI may shape future networking architectures and how NDN can serve as a principled substrate for agent communication and coordination.
  *
A Trust Plane for Zero-Trust Systems  A decade of NDN development has led to the identification of the trust plane ? a principled framework for establishing and managing security relations across distributed systems. We invite contributions on trust management architectures, trust plane design, and the use of NDN to build and support zero-trust systems.
  *
Secure, Decentralized Systems and Applications NDN enables decentralized applications built on named, secured data, peer-to-peer synchronization, and in-network storage, as exemplified by Ownly.work<https://ownly.work/>. We welcome contributions on system design, application development, and platforms that support secure, decentralized, and resilient applications.

Submissions
We invite proposals for presentations and panels. Submissions should consist of a one-page abstract including title and authors. Please indicate the submission type by beginning the title with one of: "Presentation:" or "Panel:".
Submit via: <https://ndncomm2026.named-data.net/> https://ndncomm2026.hotcrp.named-data.net/
Submission deadline: May 4, 2026.  Late submissions may be considered if space permits.
Participation Submission is not required to attend. All interested participants are welcome. Registration details are available at https://ndncomm2026.named-data.net/registration.html.
We look forward to your participation in NDNComm 2026.
NDNComm'26 Organizing Committee
??--
Lan Wang
Faudree University Professor
Department of Computer Science
The University of Memphis


<CFP NDNComm'26.pdf>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20260501/d3fe2818/attachment-0001.htm>

From ownly.agent at gmail.com  Thu May  7 20:02:28 2026
From: ownly.agent at gmail.com (ownly.agent at gmail.com)
Date: Fri, 08 May 2026 03:02:28 +0000
Subject: [Nfd-dev] NDN Weekly Call
Message-ID: <73ca1ddc-a8f5-8d1e-9b95-cdbdeb7326f8@gmail.com>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20260508/78992488/attachment.htm>

From ownly.agent at gmail.com  Thu May 14 23:11:14 2026
From: ownly.agent at gmail.com (ownly.agent at gmail.com)
Date: Fri, 15 May 2026 06:11:14 +0000
Subject: [Nfd-dev] NDN Weekly Call
Message-ID: <87a0539f-19ab-65c6-018c-586ca141cc1f@gmail.com>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20260515/0d1f91af/attachment.htm>

From haoguangyu at chorustek.com  Wed May 20 10:18:40 2026
From: haoguangyu at chorustek.com (=?utf-8?B?6YOd5bm/5a6H?=)
Date: Thu, 21 May 2026 01:18:40 +0800
Subject: [Nfd-dev] IncomingFaceIdTag is null
Message-ID: <tencent_0F4EB5D8294671940D5690FB@qq.com>

Dear team,
Below, egw and igw implement intranet/extranet access penetration by creating a TCP link between&nbsp; egw and igw NFD. Now we encounter a problem: igw always gets faceid as 0 when calling `interest.getTag<ndn::lp::IncomingFaceIdTag&gt;`. Therefore, we cannot obtain the faceid of the TCP link between egw and igw from the interest packet. We want to know why `ndn::lp::IncomingFaceIdTag` is not working. We have confirmed that the interest packet is received via the TCP link. Could it be that support for `IncomingFaceIdTag` is disabled in the compilation of NFD or ndn-cxx, or is there another reason? We need this feature to work. Thank you very much!



BR.
GuangYu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20260521/861168c4/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: igw.cpp
Type: application/octet-stream
Size: 4439 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20260521/861168c4/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: egw.cpp
Type: application/octet-stream
Size: 14006 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20260521/861168c4/attachment-0003.obj>

From shijunxiao at arizona.edu  Thu May 21 09:19:10 2026
From: shijunxiao at arizona.edu (Shi, Junxiao - (shijunxiao))
Date: Thu, 21 May 2026 16:19:10 +0000
Subject: [Nfd-dev] [EXT]  IncomingFaceIdTag is null
In-Reply-To: <tencent_0F4EB5D8294671940D5690FB@qq.com>
References: <tencent_0F4EB5D8294671940D5690FB@qq.com>
Message-ID: <PH8PR19MB7760F1556D5CE9C87F7DB503DC0E2@PH8PR19MB7760.namprd19.prod.outlook.com>

Hi Guangyu

ndn6-facemon has IncomingFaceId usage:
https://github.com/yoursunny/ndn6-tools/blob/af7d60160bad1608040ca75b54c24c48e4519f4a/facemon.md
https://github.com/yoursunny/ndn6-tools/blob/af7d60160bad1608040ca75b54c24c48e4519f4a/facemon.cpp

You can try this program to see whether your NFD build supports IncomingFaceId.
You can compare your code to this program to see whether any step is missing.

Yours, Junxiao
________________________________
From: Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu> on behalf of ??? <haoguangyu at chorustek.com>
Sent: Wednesday, May 20, 2026 1:18 PM
To: nfd-dev <nfd-dev at lists.cs.ucla.edu>
Subject: [EXT] [Nfd-dev] IncomingFaceIdTag is null


External Email

________________________________
Dear team,
Below, egw and igw implement intranet/extranet access penetration by creating a TCP link between  egw and igw NFD. Now we encounter a problem: igw always gets faceid as 0 when calling `interest.getTag<ndn::lp::IncomingFaceIdTag>`. Therefore, we cannot obtain the faceid of the TCP link between egw and igw from the interest packet. We want to know why `ndn::lp::IncomingFaceIdTag` is not working. We have confirmed that the interest packet is received via the TCP link. Could it be that support for `IncomingFaceIdTag` is disabled in the compilation of NFD or ndn-cxx, or is there another reason? We need this feature to work. Thank you very much!

BR.
GuangYu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20260521/51e01e6b/attachment.htm>

From davidepesa at gmail.com  Thu May 21 12:41:28 2026
From: davidepesa at gmail.com (Davide Pesavento)
Date: Thu, 21 May 2026 15:41:28 -0400
Subject: [Nfd-dev] IncomingFaceIdTag is null
In-Reply-To: <tencent_0F4EB5D8294671940D5690FB@qq.com>
References: <tencent_0F4EB5D8294671940D5690FB@qq.com>
Message-ID: <CADfzvvYgjHB86t6qpy243Ph0KqQX3SVn=JJhW_MfG5_Hvo3z=g@mail.gmail.com>

Hi,

Make sure that the "local fields" flag is enabled on the
application-side face. To enable the flag you need to send a
FaceUpdateCommand. You can check how the RIB manager does that for
reference: https://github.com/named-data/NFD/blob/76784d7333a0219309681ba4bc04da59c955fcc9/daemon/mgmt/rib-manager.cpp#L122

Regards,
Davide

On Wed, May 20, 2026 at 1:19?PM ??? <haoguangyu at chorustek.com> wrote:
>
> Dear team,
> Below, egw and igw implement intranet/extranet access penetration by creating a TCP link between  egw and igw NFD. Now we encounter a problem: igw always gets faceid as 0 when calling `interest.getTag<ndn::lp::IncomingFaceIdTag>`. Therefore, we cannot obtain the faceid of the TCP link between egw and igw from the interest packet. We want to know why `ndn::lp::IncomingFaceIdTag` is not working. We have confirmed that the interest packet is received via the TCP link. Could it be that support for `IncomingFaceIdTag` is disabled in the compilation of NFD or ndn-cxx, or is there another reason? We need this feature to work. Thank you very much!
>
> BR.
> GuangYu
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> https://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

From ownly.agent at gmail.com  Thu May 21 22:01:07 2026
From: ownly.agent at gmail.com (ownly.agent at gmail.com)
Date: Fri, 22 May 2026 05:01:07 +0000
Subject: [Nfd-dev] NDN Weekly Call
Message-ID: <ba7f68b0-aa14-f869-78b3-83b0586900d5@gmail.com>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20260522/7a619b40/attachment-0001.htm>

From haoguangyu at chorustek.com  Fri May 22 22:50:54 2026
From: haoguangyu at chorustek.com (=?utf-8?B?6YOd5bm/5a6H?=)
Date: Sat, 23 May 2026 13:50:54 +0800
Subject: [Nfd-dev] IncomingFaceIdTag is null
In-Reply-To: <CADfzvvYgjHB86t6qpy243Ph0KqQX3SVn=JJhW_MfG5_Hvo3z=g@mail.gmail.com>
References: <tencent_0F4EB5D8294671940D5690FB@qq.com>
 <CADfzvvYgjHB86t6qpy243Ph0KqQX3SVn=JJhW_MfG5_Hvo3z=g@mail.gmail.com>
Message-ID: <tencent_7653D4307C35525E01137344@qq.com>

Thank you everyone for your help. The problem is solved.
&nbsp;
&nbsp;
------------------&nbsp;Original&nbsp;------------------
From: &nbsp;"Davide&nbsp;Pesavento"<davidepesa at gmail.com&gt;;
Date: &nbsp;Fri, May 22, 2026 03:41 AM
To: &nbsp;"???"<haoguangyu at chorustek.com&gt;; 
Cc: &nbsp;"nfd-dev"<nfd-dev at lists.cs.ucla.edu&gt;; 
Subject: &nbsp;Re: [Nfd-dev] IncomingFaceIdTag is null

&nbsp;

Hi,

Make sure that the "local fields" flag is enabled on the
application-side face. To enable the flag you need to send a
FaceUpdateCommand. You can check how the RIB manager does that for
reference: https://github.com/named-data/NFD/blob/76784d7333a0219309681ba4bc04da59c955fcc9/daemon/mgmt/rib-manager.cpp#L122

Regards,
Davide

On Wed, May 20, 2026 at 1:19?PM ??? <haoguangyu at chorustek.com&gt; wrote:
&gt;
&gt; Dear team,
&gt; Below, egw and igw implement intranet/extranet access penetration by creating a TCP link between&nbsp; egw and igw NFD. Now we encounter a problem: igw always gets faceid as 0 when calling `interest.getTag<ndn::lp::IncomingFaceIdTag&gt;`. Therefore, we cannot obtain the faceid of the TCP link between egw and igw from the interest packet. We want to know why `ndn::lp::IncomingFaceIdTag` is not working. We have confirmed that the interest packet is received via the TCP link. Could it be that support for `IncomingFaceIdTag` is disabled in the compilation of NFD or ndn-cxx, or is there another reason? We need this feature to work. Thank you very much!
&gt;
&gt; BR.
&gt; GuangYu
&gt; _______________________________________________
&gt; Nfd-dev mailing list
&gt; Nfd-dev at lists.cs.ucla.edu
&gt; https://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20260523/073f72e9/attachment.htm>

From haoguangyu at chorustek.com  Fri May 22 22:59:31 2026
From: haoguangyu at chorustek.com (=?utf-8?B?6YOd5bm/5a6H?=)
Date: Sat, 23 May 2026 13:59:31 +0800
Subject: [Nfd-dev] How to restrict NFD data plane face creation (via nfdc
 face create tcp://) only to nodes with trusted certificates?
Message-ID: <tencent_39017DDE419CA5AF51674730@qq.com>

Dear NDN community,


We are facing an access control issue in our NDN testbed and would appreciate your advice.


Environment:


We have an NFD node C3 (IP address c3ip) listening on TCP port 6363.


Multiple remote nodes (e.g., A, B, ?) exist. Some possess NDN certificates issued by a trusted CA, others do not.


On C3, we have configured trust anchors in the authorizations and rib sections to trust only a specific certificate (e.g., /ndn/cedge). Remote management Interests (e.g., nfdc -r tcp://c3ip face create ...) are correctly validated ? only nodes with the trusted certificate can succeed.


Problem:
We observe that even a remote node without any trusted certificate can still run nfdc face create tcp://c3ip:6363 (without -r) and successfully create a data plane face on C3. This is because nfdc face create tcp://... instructs the local NFD to actively initiate a TCP connection to C3:6363, and C3, acting as a TCP server, accepts the connection and automatically creates a face ? without any NDN signature or certificate check.


Desired behavior:
We want C3 to reject TCP connections from unauthorized remote nodes. Only nodes that hold a certificate trusted by C3 (i.e., have the private key of /ndn/cedge) should be able to successfully create a face using nfdc face create tcp://c3ip:6363. In other words, we would like to enforce certificate-based authorization for data?plane face creation, or at least implement IP?based whitelisting.


Questions:


Does NFD natively support certificate verification for incoming TCP data?plane connections? If yes, how should we configure it?


If not, is the recommended solution to use network?layer firewalls (e.g., iptables) to restrict access by source IP? Are there any more NDN?idiomatic approaches (e.g., creating all faces via management Interests and disabling automatic face creation from passive TCP accepts)?


Thank you for your insights.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20260523/043e8f13/attachment.htm>

From shijunxiao at arizona.edu  Sat May 23 03:33:27 2026
From: shijunxiao at arizona.edu (Shi, Junxiao - (shijunxiao))
Date: Sat, 23 May 2026 10:33:27 +0000
Subject: [Nfd-dev] [EXT] How to restrict NFD data plane face creation
 (via nfdc face create tcp://) only to nodes with trusted certificates?
In-Reply-To: <tencent_39017DDE419CA5AF51674730@qq.com>
References: <tencent_39017DDE419CA5AF51674730@qq.com>
Message-ID: <PH8PR19MB77600C77547997657E14B907DC0C2@PH8PR19MB7760.namprd19.prod.outlook.com>

Hi Guangyu

This feature is still in design phase.
See prior discussion here:
https://redmine.named-data.net/issues/1285

?> creating all faces via management Interests and disabling automatic face creation from passive TCP accepts

That's the approach taken by NDN-DPDK, which uses an out of band management protocol.

Yours, Junxiao


________________________________
From: Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu> on behalf of ??? <haoguangyu at chorustek.com>
Sent: Saturday, May 23, 2026 1:59 AM
To: nfd-dev <nfd-dev at lists.cs.ucla.edu>
Subject: [EXT] [Nfd-dev] How to restrict NFD data plane face creation (via nfdc face create tcp://) only to nodes with trusted certificates?


External Email

________________________________
Dear NDN community,

We are facing an access control issue in our NDN testbed and would appreciate your advice.

Environment:

We have an NFD node C3 (IP address c3ip) listening on TCP port 6363.

Multiple remote nodes (e.g., A, B, ?) exist. Some possess NDN certificates issued by a trusted CA, others do not.

On C3, we have configured trust anchors in the authorizations and rib sections to trust only a specific certificate (e.g., /ndn/cedge). Remote management Interests (e.g., nfdc -r tcp://c3ip face create ...) are correctly validated ? only nodes with the trusted certificate can succeed.

Problem:
We observe that even a remote node without any trusted certificate can still run nfdc face create tcp://c3ip:6363 (without -r) and successfully create a data plane face on C3. This is because nfdc face create tcp://... instructs the local NFD to actively initiate a TCP connection to C3:6363, and C3, acting as a TCP server, accepts the connection and automatically creates a face ? without any NDN signature or certificate check.

Desired behavior:
We want C3 to reject TCP connections from unauthorized remote nodes. Only nodes that hold a certificate trusted by C3 (i.e., have the private key of /ndn/cedge) should be able to successfully create a face using nfdc face create tcp://c3ip:6363. In other words, we would like to enforce certificate-based authorization for data?plane face creation, or at least implement IP?based whitelisting.

Questions:

Does NFD natively support certificate verification for incoming TCP data?plane connections? If yes, how should we configure it?

If not, is the recommended solution to use network?layer firewalls (e.g., iptables) to restrict access by source IP? Are there any more NDN?idiomatic approaches (e.g., creating all faces via management Interests and disabling automatic face creation from passive TCP accepts)?

Thank you for your insights.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20260523/b4620766/attachment-0001.htm>

From ownly.agent at gmail.com  Thu May 28 22:02:51 2026
From: ownly.agent at gmail.com (ownly.agent at gmail.com)
Date: Fri, 29 May 2026 05:02:51 +0000
Subject: [Nfd-dev] NDN Weekly Call
Message-ID: <f0ef1b17-77a9-2ae6-2a66-14d0158d9ca0@gmail.com>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20260529/323b9cbc/attachment.htm>