>> HNCP is a standards track protocol, and there's nobody left who's
>> willing and competent to work on a new revision.
> Yes, of course. We can never change a standards track protocol. That
> would be wrong. :)
My wording was perhaps badly chosen. Sorry for that.
I meant to say that I don't currently see anyone who would be both willing
and able to (1) change the HNCP spec to add application-layer
fragmentation, (2) update the hnetd implementation to obey the new
protocol, and (3) go through the somewhat time- and energy-consuming
process required to publish a new Standards Track protocol.
(To be clear -- as far as I'm concerned, I declare myself incompetent on
all three points above. The most I could conceivably do would be to review
a new spec and update shncpd so it interoperates with a new revision of hnetd.)
> What I’m trying to understand is how bad a problem this is.
My understanding is that while HNCP should have no trouble scaling to
large networks, it is not designed to carry large amounts of per-node data.
This could cause trouble in the following cases:
- if a single node has hundreds of HNCP neighbours (e.g. because it is
connected to a large switch or serves as a tunnel server);
- if a single node announces large numbers (dozens) of external
connections; or
- if a protocol extension dumps large binary blobs into HNCP.
-- Juliusz
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
