It looks like we have convergence - in theory. The question is what text, if any, needs to change?
-----Original Message----- From: Gen-art [mailto:[email protected]] On Behalf Of Huub van Helvoort Sent: Wednesday, February 26, 2014 3:22 PM To: [email protected]; [email protected] Cc: [email protected]; [email protected] Subject: Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt Shwmae Adrian, You wrote: > [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. Please excuse me for giving the impression that this draft is an ITU-T document. You are absolutely right that both are IETF documents. I should have used "PSC in ITU-T mode" to refer to this draft. > 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. Indeed. >> 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. Again: correct. I tried to simplify too much and used the wrong word (invalid, instead of unsupported). > 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. Indeed (not supported). > OTOH, when someone writes the new RFC describing that mode, you might enhance > your implementation to support it as well. Yes, and initially advertise your own capabilities, compare to the capabilities received from the far-end and attempt to converge. > (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. OK. Cheers, Huub. -- ***************************************************************** 请记住，你是独一无二的，就像其他每一个人一样 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
