On Tue, Aug 6, 2019 at 1:30 PM Alissa Cooper via Datatracker <[email protected]> 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? For instance, as written the requirements would allow a UDP application developer to send 64K datagrams which might work perfectly fine and be the best solution in their environment that they know properly supports fragmentation. Tom > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 3.8.2: If there is any chance we think this situation might improve > before this RFC-to-be gets obsoleted one day, I might suggest: > > s/The security policy described above is implemented incorrectly on > many consumer CPE routers./The security policy described above has been > implemented incorrectly on many consumer CPE routers./ > > Section 3.9: s/Another recent study/Another study/ > > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
