>> Is a passive node allowed to use a non-standard port? If so, which TLVs >> are to be honoured from a non-standard port? I suggest: only requests, >> with NODE-ENDPOINT ignored.
> The draft - in its current version - does not really mandate that, so at > the moment implementations must be ready to receive replies on the > HNCP-PORT instead of the source port they used. I'm not sure if its > worth it to change that. Yes, it is. I feel very strongly about it. One thing that people often overlook is that a protocol's success is reliant on ease of implementation and ease of debugging. In the MANET space, for example, OLSR has taken over the world while AODV is languishing because the former can reasonably be implemented and debugged. DNCP profiles are challenging to debug (trust me, I know), since in steady state they only exchanges hashes -- a packet trace gives you very little information. In order to debug a HNCP implementation, you need a way to get it to dump its state, which is easy enough if you can send it a series of requests and get at the replies. What I'm asking is simply the ability to dump the state of a buggy, closed-source HNCP speaker by doing e.g.: hncp-dumper fe80::dead:beef%eth0 without having to bind a reserved port and therefore interfering with other HNCP speakers on the local node. This cannot be done unless the spec mandates replying to requests on the port they were sent from. >> A passive node is not allowed to use global unicast (Section 3). Even >> when using security? > HNCP only specifies link-local communication, i.e. any communication from > non link-local addresses is ignored independent if security is enabled or > not. I don't feel very strongly about this particular issue. What I am asking here is the ability to do: hncp-dumper buggy-router.home without having to fool with interfaces and link-local addresses. -- Juliusz _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
