Yeah, but that’s the rub. If we accept the status-quo of a failure to deploy devices that allow a valid protocol capability this way, we’ve basically deprecated it.
That’s the bad idea that we’ve tried hard to avoid, IMO. Joe > On Aug 6, 2019, at 6:06 PM, Joel M. Halpern <j...@joelhalpern.com> wrote: > > Brian, I would think the text just above the paragraph Alissa quoted would > already cover what you ask for. It begins: > Developers SHOULD NOT develop new protocols or applications that > rely on IP fragmentation. > > Yours, > Joel > > On 8/6/2019 8:55 PM, Brian E Carpenter wrote: >> On 07-Aug-19 12:11, Alissa Cooper wrote: >>> Hi Tom, >>> >>>> On Aug 6, 2019, at 5:41 PM, Tom Herbert <t...@herbertland.com> wrote: >>>> >>>> On Tue, Aug 6, 2019 at 1:30 PM Alissa Cooper via Datatracker >>>> <nore...@ietf.org> wrote: >>>>> >>>>> Alissa Cooper has entered the following ballot position for >>>>> draft-ietf-intarea-frag-fragile-15: Discuss >>>>> >>>>> 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-intarea-frag-fragile/ >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> Thanks for writing this document. >>>>> >>>>> Section 6.1 says: >>>>> >>>>> "Developers MAY develop new protocols or applications that rely on IP >>>>> fragmentation if the protocol or application is to be run only in >>>>> environments where IP fragmentation is known to be supported." >>>>> >>>>> I'm wondering if there should be a bit more nuance here to make the >>>>> recommendation clearer. Do we think there is a case where an application >>>>> protocol developed in the IETF will be known to only run in environments >>>>> where >>>>> fragmentation is supported? If we don't think developing such a protocol >>>>> would >>>>> be in scope for the IETF, then I'm wondering if that case should be >>>>> called out >>>>> explicitly with a stronger normative requirement. >>>>> >>>> Alissa, >>>> >>>> Are you distinguishing between protocol development and application >>>> development? >>> >>> I’m specifically wondering about application protocols (as distinct from >>> other protocols) developed in the IETF (as distinct from developed >>> elsewhere). Sometimes we use BCPs to guide future work in the IETF >>> specifically, and it seemed to me that in that specific slice — >>> IETF-developed application protocols — we may be able to make a stronger >>> recommendation since we can’t be sure of the environment in which any given >>> application protocol would be deployed (I think, but would be open to >>> arguments otherwise). >> fwiw, I agree with what I think Alissa is saying. Unless we actually >> *implement* a mechanism to define and support limited domains >> (draft-carpenter-limited-domains) protocol designers cannot safely make >> assumptions such as "fragmentation works". >> Maybe this paragraph needs to be more of a health warning than a somewhat >> dubious RFC2119 statement. At least, "should not ... unless" might be a >> better formulation than "MAY ... if". >> Brian >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
