Bob was going to engage Alissa in a conversation. Bob, have you gotten anywhere? I think she may be on vacation. Yours, Joel
-----Original Message----- From: Ron Bonica <[email protected]> Sent: Thursday, August 15, 2019 9:59 AM To: Brian E Carpenter <[email protected]>; Alissa Cooper <[email protected]>; Tom Herbert <[email protected]> Cc: Joel Halpern <[email protected]>; [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) Folks, Has anyone proposed text that: a) satisfies Alissa's request b) satisfies the WG If not, do we believe that such text could possibly exist? Ron Juniper Business Use Only -----Original Message----- From: Brian E Carpenter <[email protected]> Sent: Tuesday, August 6, 2019 8:55 PM To: Alissa Cooper <[email protected]>; Tom Herbert <[email protected]> Cc: Joel Halpern <[email protected]>; [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) On 07-Aug-19 12:11, 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=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0 >>> UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP >>> 8&m=IUZsPOprgYi_5nBSPGeqNCLb8LwDMKCxRNeEBfcUZ5c&s=c7tAk-Lfr6pcQSMn1x >>> 1tdfjkQsL8F_NryIiq3caZ26k&e= for more information about IESG DISCUSS >>> and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://protect2.fireeye.com/url?k=9735801d-cbbf54dc-9735c086-863d9b >>> cb726f-ce87e2cc217e1c5e&q=1&u=https%3A%2F%2Furldefense.proofpoint.co >>> m%2Fv2%2Furl%3Fu%3Dhttps-3A__datatracker.iet >>> f.org_doc_draft-2Dietf-2Dintarea-2Dfrag-2Dfragile_&d=DwIFaQ&c=HAkYuh >>> 63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF >>> 2EfpHcAwrDThKP8&m=IUZsPOprgYi_5nBSPGeqNCLb8LwDMKCxRNeEBfcUZ5c&s=lb6u >>> 0SVhJIFnTV7TdqeLiDBfadRxJkAxNEDqOvFqhyQ&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). 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 [email protected] https://www.ietf.org/mailman/listinfo/int-area
