Sut mae, Elwyn-gwas, [snip]
> Politics! OK - How about we add to either s9.1.1 or s9.2 something like: I don't think it is politics at all, and I don't really like that Huub referenced this as IETF and ITU-T since both documents are IETF standards track work. There are some people who want to deploy one set of options (the empty set) and they have an RFC. There is another set of people who want to deploy a different set of options (all 5 of them) and they will have this RFC. > Only combinations of capabilities specified by a mode are allowed. > Capability TLVs with other combinations will be treated as invalid > PSC messages. But this is not true. What we have is: A node knows which options it supports, and those options are expressed as bundles (modes). A node that tries to communicate with you must offer a set of options (a mode). Either you support the mode or you don't. If you support it, off you go. If you don't support it, you reject the message saying "unsupported" as described in this document. The message that offers a different set of options (i.e. a different mode) is not invalid, it is just that you don't understand it. You can't accept it because you don't know how to behave in that mode. OTOH, when someone writes the new RFC describing that mode, you might enhance your implementation to support it as well. (Hint: it really helps to think in modes. A mode is expressed as a bit-flag with plenty-bits of which five currently have meaning.) I agree with you that there is some distinction to be made between "invalid message" and "protocol error". But "no valid message" does not mean "protocol error" or "invalid message" was received. It is a composite of possibilities that reflects the negation of receiving a message that was small and perfectly formed. Ciao, Adrian _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
