|
Lou, On 25/04/2019 16:45, Lou Berger wrote:
And sry for my longer delay replying...Hi Bob, Sorry for the late reply. See below for specific responses. [BB] It's just ambiguous. "Configurable" usually means "capable of having its settings configured". Yes, "the use of" makes it more likely that you mean "the ability to use", but it's just not clearly written.On 4/9/19 7:22 AM, Bob Briscoe via Datatracker wrote:Reviewer: Bob Briscoe Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@xxxxxxxx if you reply to or forward this review. AFAICT, there's nothing technically wrong, but I believe the authors use of normative text does not convey the meaning they intended, in nearly every case. It will be seen below that there seems to be a general misunderstanding of the use of, 'SHOULD do X' when there will never be a case when X should not be done. 'SHOULD' and 'MAY' need to be used judiciously, because they make interoperability harder. ==Inappropriate Normative Text== S.2. "The use of the Multi-Hop Forwarding Extension SHOULD be configurable. " {I think you mean it SHOULD be possible to enable/disable the extension?To me that's what this says. [BB] I think you've missed my point, which is about ambiguous meaning of sentences, not a technical question.On a modem. a router or both?yes, by any node that supports the extension.In what circumstances would it not be configurable (if none, then MUST would be appropriate)?We generally don't stop people from building products that meet their specific market requirements as long as there's no interop issue, hence the SHOULD vs MUST.> What happens if one device uses theextension and another doesn't? This last question also applies for incremental deployment.}This is covered in the base DLEP RFC. But before we get to that, there was a prerequisite question about this sentence in my editorial nits file. The full sentence said: My nit question about this sentence was:The Hop Count Data Item SHOULD be carried in the Destination Up, Destination Update, Destination Announce Response, and Link Characteristics Response messages when the Hop Count to a destination is greater than one (1). "{Does this 'when >1' clause apply to all 4 messages, or just Link Characteristic Response messages?}" You've just ignored this and left the sentence as it was. Did you not understand my question? if so, you could have asked. The grammar of the sentence reads as "The Hop Count Data Item SHOULD be carried in the first three message types (whatever the hop count), and in the fourth message type (when the hop count is >1). I doubt you meant that. If not, the sentence ought to be disambiguated as follows: Next, let's return to the SHOULD. This means that, even when count > 1, it doesn't have to be included in these messages. The next para says:When the Hop Count to a destination is greater than one (1), the Hop Count Data Item SHOULD be carried in the Destination Up, Destination Update, Destination Announce Response, and Link Characteristics Response messages. The absence of the Hop Count Data Item MUST be interpreted by the router as a Hop Count value of one (1).So, when count > 1, you say it doesn't have to be carried in these messages,... so the router will assume it is 1, even tho it isn't. Is that what you intended to say? If so, surely you need to say under what circumstances a hop count >1 would not be carried in these messages. It all seems very vague to me. [BB] Actually, perhaps you didn't mean to use normative text at all. Perhaps you just meant The Hop Control Data Item would be carried in... [BB] You didn't respond to this point. [BB] I meant "This action MUST only be sent for destinations for which ... count >1 & P set ...". I don't think that would cause errors, would it?S.3.2.3 Direction Connectionthis should be Direct Connection Again, my point is about use of English, not technical. I'm picking up every case where you say "SHOULD" and working out what exceptions your English allows. By using "SHOULD only be sent" rather than "MUST only be sent", it allows exceptions to 'only' not to 'sent'. So it means "although this action will normally solely be sent for destinations with count>1 & P set, it could be sent for other destinations..." which, as you say yourself, would cause errors. I don't think you actually need normative text here anyway. I think you used 'SHOULD' because you were trying to say something like: "the action can only be sent for destinations with count > 1 & P set (but for those destinations the action doesn't have to be sent)." Or perhaps you really do need normative text here for interop in order to avoid dlep errors, and you meant to say: "The action MUST NOT be sent for destinations that do not have count>1 & P set ..." This is all becoming rather painful, 'cos you don't seem to be getting that I'm just trying to improve the highly ambiguous English around the normative text. However, it's hard 'cos I'm not sure what you were trying to mean in the first place. [BB] Again, you're not grocking that I am questioning the use of RECOMMENDED, which is equivalent to SHOULD, and therefore weaker than MUST, even with STRONGLY added. (BTW, STRONGLY isn't a normative word defined in RFC2119).S.3.2.4. Suppress Forwarding I suggest that you don't gratuitously switch from 'MUST' to 'SHALL' just for this section? Many implementers search the text for 'MUST'. ==Authentication== S.4. RFC8175 says 'For all "networked deployments" ..., the implementation and use of TLS are STRONGLY RECOMMENDED.' I believe it would be worth identifying which extensions would be unsafe if TLS were not used. Certainly all the Multi-Hop Extensions would be unsafe if not authenticated.umm, I think all of DLEP would be unsafe without TLS, or some other equivalent, e.g., macsec. If you are only saying STRONGLY RECOMMENDED, you are still saying implementers don't have to use TLS. If you really don't want to require them to, then it is always best to explain why you are not saying MUST (e.g. perhaps to allow for deployments in trusted environments). On a quick look, I found a couple of nits still:==General Nits== Inappropriate and/or inconsistent capitalization of certain phrases, like 'Data Item' or 'Action' or 'Message'. ==Specific Nits== I've provided suggested corrections in the following xml files: http://bobbriscoe.net/tmp/draft-ietf-manet-dlep-multi-hop-extension-06_BB.xml http://bobbriscoe.net/tmp/draft-ietf-manet-dlep-multi-hop-extension-06_BB.txt http://bobbriscoe.net/tmp/draft-ietf-manet-dlep-multi-hop-extension-06_BB-DIFF-06.html 3.2.4. Suppress Forwarding s/Impact to destination hop counts are provided to the router by the modem as described above./ /The impact on destination hop counts is provided to the router by the modem as described above./ If you didn't mean that, you can't leave the sentence like it is. Security Considerations: s/Similar attacks are generally possible base DLEP,/ /Similar attacks are generally possible in base DLEP,/ CheersThanks! I've pushed changes to https://github.com/louberger/dlep-extensions and will coordinate an update with the AD. Lou Bob _______________________________________________ manet mailing list manet@xxxxxxxx https://www.ietf.org/mailman/listinfo/manet -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ |
