+1
Juniper Business Use Only -----Original Message----- From: Joel M. Halpern <[email protected]> Sent: Tuesday, August 6, 2019 8:49 PM To: Alissa Cooper <[email protected]>; Tom Herbert <[email protected]> Cc: [email protected]; int-area <[email protected]>; IESG <[email protected]>; intarea-chairs <[email protected]> Subject: Re: [Int-area] Alissa Cooper's Discuss on draft-ietf-intarea-frag-fragile-15: (with DISCUSS and COMMENT) As far as I can tell (as a mostly observer who is now shepherding this document) the working group seemed very reluctant to get too specific about what were or were not constrained environments where fragmentation might (reasonably?) be expected (or not expected) to work. I fear that trying to get more specific would open a complex discussion which might well never converge. Yours, Joel On 8/6/2019 8:11 PM, Alissa Cooper wrote: > Hi Tom, > >> On Aug 6, 2019, at 5:41 PM, Tom Herbert <[email protected]> wrote: >> >> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_ie >>> sg_statement_discuss-2Dcriteria.html&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0 >>> UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP >>> 8&m=IbZPoTgcEK6RwyHLQ79tJGzMwOqKKMb_w_FmN0M1bDk&s=8_h-E-r99pa3oIp7-a >>> MseaY_FUaWxTKCEpNOLYG6wpE&e= for more information about IESG DISCUSS >>> and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.iet >>> f.org_doc_draft-2Dietf-2Dintarea-2Dfrag-2Dfragile_&d=DwIDaQ&c=HAkYuh >>> 63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF >>> 2EfpHcAwrDThKP8&m=IbZPoTgcEK6RwyHLQ79tJGzMwOqKKMb_w_FmN0M1bDk&s=apQD >>> 80NdWb1y5N0zMO5oVrP0xEzJbn76nwUtVdDT6pY&e= >>> >>> >>> >>> -------------------------------------------------------------------- >>> -- >>> 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). > > Thanks, > Alissa > > >> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_ma >>> ilman_listinfo_int-2Darea&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb >>> 3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=IbZPoTg >>> cEK6RwyHLQ79tJGzMwOqKKMb_w_FmN0M1bDk&s=2svslKHTwY1Eci6xdBs-Q_WwvEPJh >>> N5T3hFaeBUOmro&e= > > _______________________________________________ > Int-area mailing list > [email protected] > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail > man_listinfo_int-2Darea&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voD > TXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=IbZPoTgcEK6Rw > yHLQ79tJGzMwOqKKMb_w_FmN0M1bDk&s=2svslKHTwY1Eci6xdBs-Q_WwvEPJhN5T3hFae > BUOmro&e= > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
