Re: Ben Campbell's No Objection on draft-ietf-mboned-mtrace-v2-22: (with COMMENT)
Hitoshi Asaeda <[email protected]>
| Newsgroups | gmane.ietf.mboned |
|---|---|
| Message-ID | <[email protected]> |
Hi Ben, > 2018/01/25 14:08, Ben Campbell <[email protected]> wrote: > >> On Jan 24, 2018, at 8:25 PM, Hitoshi Asaeda <[email protected]> wrote: >> >> Hi Ben, >> >> Thanks for your review and comments. >> >>> 2018/01/24 11:17, Ben Campbell <[email protected]> wrote: >>> >>> Ben Campbell has entered the following ballot position for >>> draft-ietf-mboned-mtrace-v2-22: No Objection >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-mboned-mtrace-v2/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> -3.1. Length: "Length SHOULD NOT exceed the available MTU" >>> How does that interact with the previous "MUST NOT be fragmented" requirement? >> >> If the length exceeds the available MTU, the packet is considered invalid and is discarded. This sounds “SHOULD NOT”, and it is done in accordance with the requirement that the packet MUST NOT be fragmented. > > I guess my confusion is that these two requirements seem like opposite sides of the same coin, so it seems odd for them to be at different requirement levels. Can you envision situations where it might make sense to violate the SHOULD NOT? I see. Then, simply changing the sentence from "however the entire Mtrace2 packet length SHOULD NOT exceed the available MTU." to "however the entire Mtrace2 packet length should not exceed the available MTU." makes sense? (Yes, we’ll consider 8174 in the revision entirely.) >> >>> -2: There are lower case versions of the 2119 keywords. Unless those were meant >>> to be capitalized, please consider using the boilerplate from 8174. >> >> Yes, we’ll do for the next revision. Thanks. >> >> Best regards, >> -- >> Hitoshi Asaeda Best regards, -- Hitoshi Asaeda _______________________________________________ MBONED mailing list [email protected] https://www.ietf.org/mailman/listinfo/mboned