On Oct 11, 2014, at 2:02 PM, Tomek Mrugalski <[email protected]> wrote: > A well defined protocol should leave certain aspects up to implementors.
Yes, a well-defined protocol _can_ leave certain aspects up to implementors, or to administrator control. But obviously some aspects need to be well-defined, or it's not a well-defined protocol. My objection to this feature is that (a) there is no actual use case for it, as witness the fact that in the twenty years DHCP has been around, nobody has _ever_ used it in a real-world deployment, and (b) it's so completely underspecified that it is impossible to even say specifically what it does. I tend to agree with you that there is probably no harm in allowing this, because nobody will be able to figure out what to do with it. However, your text spoke of it as if there was a use case for it, which I think would have been confusing to implementors, since there is no identified use case for it. So I appreciate your willingness to specify it differently. If you want to preserve the possibility of using this, you could change the MUST NOT in my proposed text to a SHOULD NOT, and that would then no longer prohibit using this feature if a use case were identified later on. I would not object to this. _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
