Thanks Pete, then I prefer to keep it as it is, i.e., use the term 'should'.
Best wishes, Haomian -----邮件原件----- 发件人: Pete Resnick [mailto:[email protected]] 发送时间: 2017年2月13日 9:54 收件人: Zhenghaomian 抄送: [email protected]; [email protected]; [email protected] 主题: Re: Review of draft-ietf-ccamp-flexible-grid-ospf-ext-08 [Trimming down] On 12 Feb 2017, at 19:22, Zhenghaomian wrote: > 3.2: > > Hence, in order to support all possible applications and > implementations the following information should be advertised for > a flexi-grid DWDM link: > > Is that "should" in there meant to be normative? That is, do bad > things happen if I don't advertise one of those items? Or do you just > mean "the following information is advertised..."? > > [Haomian] I feel weird if replace 'should be' with 'is', as you cannot > support some application/implementation (rather than do bad things) if > you don't advertise... How about following change? > > OLD > Hence, in order to support all possible applications and > implementations the following information should be advertised for > a flexi-grid DWDM link: > NEW > Hence, in order to support all possible applications and > implementations the following information is required to be > advertised > for a flexi-grid DWDM link: Well, that's starting to feel like a SHOULD or a MUST. That is to say, some applications/implementations will not work if you don't advertise these things, so if you're not going to advertise one or more of them, you'd better know what you're doing and understand the consequences. That's the 2119 definition of SHOULD. On the other hand, if it's really always required because you really have to support all of those applications/implementations, and there are no good reasons to fail to advertise any of these things, then that's a MUST. As I said before, I'm someone who doesn't like putting in MUSTs and SHOULDs (I've even written protocol documents where they never appear), but if you really mean "required" or "required unless you know what you're doing", I see no harm in putting them in. pr -- Pete Resnick <http://www.qualcomm.com/~presnick/> Qualcomm Technologies, Inc. - +1 (858)651-4478 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
