Sorry for the delay, I needed to think this over. >> In the light of the above figures -- can I trust an IETF working group >> to understand that a huge amount of effort has been put into removing >> mechanisms from this protocol, and to respect that work?
> Yes, I think that the requirement for minimal mechanisms and a simple > easy to implement and troubleshoot protocol can be clearly expressed. Here's some initial and incomplete input. I'm just thinking aloud, and perhaps taking my God-given right to say something stupid. I'd like the charter to clearly state that no mechanism will be added unless there is experimental data to show that it is necessary in realistic situations. For example, should people believe that an additional congestion control mechanism is needed, they will need to show experimental data that prove their point. I'd like the charter to clearly state that security considerations are outside the scope of the base spec. The base spec says "This is a completely insecure protocol" and I much prefer this frank admission of failure to a half-baked solution, which would then prevent better security mechanisms from being developed. (I am not a security specialist, and while I'm really glad about RFC 7298 (HMAC auth for Babel), I am not competent to judge whether it is the only solution.) I'd like the suggested metrics to remain informative appendices, contrary to Ted's opinion. Babel's main claim to fame is that it's an extremely flexible protocol, and putting the suggested metrics in the body of the document is contrary with the main goal. I'd also like the other metrics (as well as source-specific routing) to remain separate documents, since they require extensions to the packet format. There is only one mechanism in the base spec that is not currently used by implementations -- it's the reliable transport building block defined in Section 3.3. It has very low cost (20 lines of code or so in the C version), so it's a MUST, since it is only useful if implemented by all nodes. I have no strong feelings about whether it should stay. It is not clear to me whether the extension mechanism should be merged into the base spec. I think the answer is yes, but in the meantime this should not delay the publication of draft-chroboczek-babel-extension-mechanism-04 as an Experimental RFC. Sorry for the underfull hbox. The packet format is a little messy, but extremely compact, which is useful in meshy places. I believe that Joel Halpern dislikes it, I'm not so sure I like it myself. I hold no opinion whether it should be replaced by a cleaner but more costly format -- it's a difficult choice. -- Juliusz _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
