Subject: [Int-area] Alissa Cooper's Discuss on draft-ietf-intarea-frag-fragile-15: (with DISCUSS and COMMENT)

From: Alissa Cooper via Datatracker <[email-masked]>
Date: Tue, 06 Aug 2019 13:30:48 -0700

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.

----------------------------------------------------------------------
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/

---

From: Tom Herbert <[email-masked]>
Date: Tue, 6 Aug 2019 14:41:18 -0700

> https://datatracker.ietf.org/doc/draft-ietf-intarea-frag-fragile/
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

> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 6 Aug 2019 20:11:48 -0400

Hi Tom,

> On Aug 6, 2019, at 5:41 PM, Tom Herbert <[email-masked]> wrote:
> 
> 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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 6 Aug 2019 20:49:06 -0400

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Aug 2019 12:55:19 +1200

> 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…

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 6 Aug 2019 21:06:12 -0400

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 6 Aug 2019 18:09:35 -0700

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 <[email-masked]> wrote:
> 
> Brian, I would think the text just above the paragraph Alissa quoted would already cover what you ask for.  It begins:

---

From: Fernando Gont <[email-masked]>
Date: Tue, 6 Aug 2019 23:57:43 +0300

Hello, Alissa,

Thanks for your comments! Inline...

An application (developed in the IETF or elsewhere) might be used in
some controlled domain, where fragmentation may be known to be
supported. The message here is "unless you really know what you are
doing and you're in e.g. a controlled environment where fragmentation is
known to be supported, you shouldn't rely on fragmentation".

I wouldn't mind myself stronger advice, but this is what the wg settled on.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Aug 2019 13:48:30 +1200

>      rely on IP fragmentation.

Well yes, so the "unless" clause would fit right there. Saying both "SHOULD NOT" and "MAY" is redundant, which is why the word "unless" exists. So basically this is editorial (since Fernando is correct about the WG intention).

Although switching to "unless" doesn't exactly resolve Alissa's issue, I think it makes it clear that relying on fragmentation is a risky choice, whereas the MAY formulation makes it seem almost OK.

   Brian

> .

---

From: Tom Herbert <[email-masked]>
Date: Tue, 6 Aug 2019 18:50:17 -0700

On Tue, Aug 6, 2019 at 6:17 PM Fernando Gont <[email-masked]> wrote:
> to be supported, you shouldn't rely on fragmentation".
>
Fernando,

There were several examples given of protocols in use in controlled
environments that use fragmentation and justify that message. In
particular, it is used in some cases of network layer encapsulation.
For instance, consider that a packet entering an SRV6 domain may be
encapsulated with hundreds of bytes of overhead. The possibility that
the tunnel overhead causes the packet to exceed the path MTU of the
tunnel underlay needs to be considered. The typical answer, as pointed
in draft-ietf-6man-segment-routing-header-22, is to just set the MTUs
so that the addition of tunnel overhead doesn't exceed any MTU. For a
large scale domain that may not always be feasible. Using
fragmentation has been good solution in such cases.

Tom

---

From: Fernando Gont <[email-masked]>
Date: Wed, 7 Aug 2019 05:40:32 +0300

Tom,

On 7/8/19 04:50, Tom Herbert wrote:
> encapsulated with hundreds of bytes of overhead. 

Isn't this the same thing I noted? i.e., you might have apps using
fragmentation in controlled domains. OTOH, if you expect to use it on
the public Internet, it is not reliable.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 7 Aug 2019 16:09:12 +0300

> 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.

IN a way, it's the operational reality that has deprecated Fragmention
(and essentially IPv6 EHs, as per RFC7872).

That is: can you reliably use them? --Not at all... expect when you run
the network yourself.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Joe Touch <[email-masked]>
Date: Wed, 7 Aug 2019 06:30:54 -0700

Things that don’t work aren’t always either deprecated or security attacks.

And if we treat them as such, the remainder won’t be useful to anyone for anything.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 7 Aug 2019 17:01:35 +0300

> And if we treat them as such, the remainder won’t be useful to anyone for anything.

What I meant is that, whether one likes it or not, at the point
something does not work (for some meaningful level of failure rate), you
cannot rely on it anymore. (that wrt the "deprecated" (in a colloquial
way) bit).

Regarding security, there are times in which things don't work because
vendors did such a poor job that supporting a given feature opens your
networks or devices to attack. Particularly when a feature is not widely
employed (if at all), it's not surprising that ops people resort to
blocking the feature.

Not that I necessarily like it, but that's what reality seems to indicate.

I leave the "who to blame" for others (SDOs for generating stuff that is
not possible to implement in a meaningful way, vendors for claiming they
support something when they do it in a very poorly way, or ops folks for
solving their problems with what they have at hand (instead of e.g. to
applying pain to vendors or SDOs, if at all possible)). :-)

---

From: Joe Touch <[email-masked]>
Date: Wed, 7 Aug 2019 07:07:39 -0700

> On Aug 7, 2019, at 7:01 AM, Fernando Gont <[email-masked]> wrote:
> 

Sometimes they indicate bugs — often that we ought to encourage be fixed. 

Otherwise, as I’ve said before and again above, we end up with the least of everything.

In this case, warning people that things might not work isn’t the same as “should avoid” or “don’t use”. It could be as simple as “check before relying on”, but let’s face it - the Internet is *best effort* throughout anyway, so even needing to say that seems redundant.

To the IESG: wordsmithing this document is a bad idea unless it comes with a substantial revision explaining the impact of stronger warnings AND is taken back to the WG for consensus.

Joe

---

From: Ron Bonica <[email-masked]>
Date: Wed, 7 Aug 2019 14:12:24 +0000

+1

Juniper Business Use Only

-----Original Message-----
From: Joel M. Halpern <[email-masked]> 
Sent: Tuesday, August 6, 2019 8:49 PM
To: Alissa Cooper <[email-masked]>; Tom Herbert <[email-masked]>
Cc: [email-masked]; int-area <[email-masked]>; IESG <[email-masked]>; intarea-chairs <[email-masked]>
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:
>>> 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.
>>>
>>>
>>> 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=
>>>
>>>
>>>
>>> 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,
>>
>> 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
>>
>>>
>>> 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:
>>>
>>> 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=
> 
> 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=
>

---

From: Fernando Gont <[email-masked]>
Date: Wed, 7 Aug 2019 17:15:59 +0300

On 7/8/19 17:07, Joe Touch wrote:
> 
> 
>> On Aug 7, 2019, at 7:01 AM, Fernando Gont <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
[...]
> 
> To the IESG: wordsmithing this document is a bad idea unless it comes
> with a substantial revision explaining the impact of stronger warnings
> AND is taken back to the WG for consensus.

Agree with this. This is what the wg agreed on. It's always possible to
go for stronger advice in the future, if warranted. No need to boil the
ocean now.

---

From: Ron Bonica <[email-masked]>
Date: Wed, 7 Aug 2019 14:20:07 +0000

Folks,

Will the reader parse our words with the same exactitude that we are parsing them? If not, we may be splitting a hair four ways.

                                                    Ron

See http://www.worldwidewords.org/weirdwords/ww-tet1.htm 

-----Original Message-----
From: Brian E Carpenter <[email-masked]> 
Sent: Tuesday, August 6, 2019 9:49 PM
To: Joel M. Halpern <[email-masked]>
Cc: [email-masked]; int-area <[email-masked]>; IESG <[email-masked]>; intarea-chairs <[email-masked]>
Subject: Re: [Int-area] Alissa Cooper's Discuss on draft-ietf-intarea-frag-fragile-15: (with DISCUSS and COMMENT)

   Brian

>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_
>>>>> iesg_statement_discuss-2Dcriteria.html&d=DwIFaQ&c=HAkYuh63rsuhr6Sc
>>>>> bfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAw
>>>>> rDThKP8&m=K6K-bQH0NFtxwfR_HDSHaATU6qP7wumqjFA21F7nzGE&s=zs-b6MBeMn
>>>>> vgAL0TshG4Kx_unK7Cl3tyMEv2oCsXScI&e=
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.i
>>>>> etf.org_doc_draft-2Dietf-2Dintarea-2Dfrag-2Dfragile_&d=DwIFaQ&c=HA
>>>>> kYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuK
>>>>> wl-AWF2EfpHcAwrDThKP8&m=K6K-bQH0NFtxwfR_HDSHaATU6qP7wumqjFA21F7nzG
>>>>> E&s=ubWRgb5Vzj9_HxwhYq0wzsnEJkiCkZDDW2_3dnm41j8&e=
>>>>>
>>>>>
>>>>>
>>>>> 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,
>>>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai
>> lman_listinfo_int-2Darea&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3v
>> oDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=K6K-bQH0NF
>> txwfR_HDSHaATU6qP7wumqjFA21F7nzGE&s=EhshdFZJpNYRPc_qn3UUvezPoaAeXPs1w
>> mT53wz2Jtg&e=
>>
> .
>

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 7 Aug 2019 08:16:37 -0700

On August 7, 2019 at 10:20:24 AM, Ron Bonica (
rbonica=[email-masked]) wrote:

Will the reader parse our words with the same exactitude that we are
parsing them? If not, we may be splitting a hair four ways.

Right…but given that this document is a BCP, if the text is not clear in
its intent we may end up splitting that hair in many more ways for a long
time to come. <sigh>

Alvaro.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 7 Aug 2019 08:49:46 -0700

Fernando,

Neither is IPv6 reliable on the public Internet :-) The fact that a
protocol isn't "reliable" isn't the same thing as it being deprecated.

We know that fragmentation is difficult to use on the public Internet,
and have already accounted for that in deployment. It IPv6 it's easy
enough to restrict packet to packets to 1280 bytes when sending into
the Interner.

Controlled environments, which is the subject of Alissa's comment, is
a very different story. There's a great diversity of MTUs and
applications. Fragmentation has been integrated to the stack and has
been the standard for years and it's in use. We don't know how much
it's in use since the mechanism is transparent, probably the only time
we'd hear about it is when there's a problem. So fragmentation is
used, possibly even in widespread use for years, working for some
subset of users, and people might not even realize they are relying on
it. This isn't a bad thing, that's the protocol working as intended!
To say that applications need to reevaluate that on the basis that
IETF thinks is risky or some vendors don't want to support is long
after the fact. In other words, if it's not broke, why fix it?

In any case, my view of the draft is that it's describing the current
state of affairs and in no way deprecating fragmentation. If someone
is productively using fragmentation, they can continue to use it. When
the draft says protocols SHOULD not be developed that rely on
fragmentation is reasonable. The requirement is broad enough to allow
the necessary leeway. For instance, I checked the network
encapsulations in Linux, I don't believe any of them go out of their
way to avoid "relying" on fragmentation. UDP encapsulations don't set
DONTFRAG so if the user configures a larger MTU then the underlay MTU
then fragmentation will be done (if an application or protocol is
serious about avoiding fragmentation that would either set DONTFRAG or
enforce packet size is less than minimum MTU in the implementation).
So encapsulation protocols do rely on fragmentation in some
circumstances, but usually provide guidance in the specification that
it should be avoided (e.g. by manipulating MTUs). I think that is
reasonable.

Tom

---

From: Ron Bonica <[email-masked]>
Date: Thu, 15 Aug 2019 13:59:18 +0000

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

-----Original Message-----
From: Brian E Carpenter <[email-masked]> 
Sent: Tuesday, August 6, 2019 8:55 PM
To: Alissa Cooper <[email-masked]>; Tom Herbert <[email-masked]>
Cc: Joel Halpern <[email-masked]>; [email-masked]; int-area <[email-masked]>; IESG <[email-masked]>; intarea-chairs <[email-masked]>
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:
>>> sg_statement_discuss-2Dcriteria.html&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0
>>> 8&m=IUZsPOprgYi_5nBSPGeqNCLb8LwDMKCxRNeEBfcUZ5c&s=c7tAk-Lfr6pcQSMn1x
>>> 1tdfjkQsL8F_NryIiq3caZ26k&e= for more information about IESG DISCUSS 
>>> and COMMENT positions.
>>>
>>>
>>> f.org_doc_draft-2Dietf-2Dintarea-2Dfrag-2Dfragile_&d=DwIFaQ&c=HAkYuh
>>> 2EfpHcAwrDThKP8&m=IUZsPOprgYi_5nBSPGeqNCLb8LwDMKCxRNeEBfcUZ5c&s=lb6u
>>> 0SVhJIFnTV7TdqeLiDBfadRxJkAxNEDqOvFqhyQ&e=
>>>
>>>
>>>

   Brian

---

From: Joel Halpern <[email-masked]>
Date: Thu, 15 Aug 2019 14:00:48 +0000

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-masked]> 
Sent: Thursday, August 15, 2019 9:59 AM
To: Brian E Carpenter <[email-masked]>; Alissa Cooper <[email-masked]>; Tom Herbert <[email-masked]>
Cc: Joel Halpern <[email-masked]>; [email-masked]; int-area <[email-masked]>; IESG <[email-masked]>; intarea-chairs <[email-masked]>
Subject: RE: [Int-area] Alissa Cooper's Discuss on draft-ietf-intarea-frag-fragile-15: (with DISCUSS and COMMENT)

Folks,

                                              Ron

-----Original Message-----
From: Brian E Carpenter <[email-masked]>
Sent: Tuesday, August 6, 2019 8:55 PM
To: Alissa Cooper <[email-masked]>; Tom Herbert <[email-masked]>
Cc: Joel Halpern <[email-masked]>; [email-masked]; int-area <[email-masked]>; IESG <[email-masked]>; intarea-chairs <[email-masked]>
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:
>>> 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

   Brian

---

From: Joe Touch <[email-masked]>
Date: Thu, 15 Aug 2019 07:20:59 -0700

Well, there’s the tautology that “it worked when it worked”.

Given that’s basically the rule that defines *everything* in the Internet, it’s baffling we need to say it again here, but if we did, we could simply state:

“The Internet is a best-effort system and lacks a formal validation or conformance mechanism. Like any other protocol feature, IP fragmentation is useful only when it actually works - both by successfully traversing routers and other in-network devices and when it is correctly supported by endpoints. As a consequence, like any other protocol feature, IP fragmentation MAY be used by new protocols that validate its successful traversal and provide an alternate as a backup.”

(and yes, if we’re going to try to imply that frag is limited, it really should be clear that this is *no different than any other protocol feature* in the Internet)

Joe

> On Aug 15, 2019, at 6:59 AM, Ron Bonica <rbonica=[email-masked]> wrote:
> 
> Folks,
>

---

From: Ron Bonica <[email-masked]>
Date: Thu, 15 Aug 2019 14:26:28 +0000

Joe,

All things are fragile. That's one of life's realities.

But some things are more fragile than others.

                                                           Ron

-----Original Message-----
From: Joe Touch <[email-masked]> 
Sent: Thursday, August 15, 2019 10:21 AM
To: Ron Bonica <rbonica=[email-masked]>
Cc: Brian E Carpenter <[email-masked]>; Alissa Cooper <[email-masked]>; Tom Herbert <[email-masked]>; Joel Halpern <[email-masked]>; [email-masked]; int-area <[email-masked]>; IESG <[email-masked]>; intarea-chairs <[email-masked]>
Subject: Re: [Int-area] Alissa Cooper's Discuss on draft-ietf-intarea-frag-fragile-15: (with DISCUSS and COMMENT)

Joe

> Cc: Joel Halpern <[email-masked]>; 
> [email-masked]; int-area 
> <[email-masked]>; IESG <[email-masked]>; intarea-chairs 
> <[email-masked]>
> Subject: Re: [Int-area] Alissa Cooper's Discuss on 
> draft-ietf-intarea-frag-fragile-15: (with DISCUSS and COMMENT)
> 
>>>> 8&m=IUZsPOprgYi_5nBSPGeqNCLb8LwDMKCxRNeEBfcUZ5c&s=c7tAk-Lfr6pcQSMn1
>>>> x 1tdfjkQsL8F_NryIiq3caZ26k&e= for more information about IESG 
>>>> DISCUSS and COMMENT positions.
>>>> 
>>>> 
>>>> 2EfpHcAwrDThKP8&m=IUZsPOprgYi_5nBSPGeqNCLb8LwDMKCxRNeEBfcUZ5c&s=lb6
>>>> u 0SVhJIFnTV7TdqeLiDBfadRxJkAxNEDqOvFqhyQ&e=
>>>> 
>>>> 
>>>> 
>>>> -------------------------------------------------------------------
>>>> -
>>>> --
>>>> DISCUSS:
>>>> -------------------------------------------------------------------
>>>> -
>>>> --
>>>> 
>>>> "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."
>>>> 
> man_listinfo_int-2Darea&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=eXUulHqfbw3R3myfDaucAqDwAy7RLoWhE407vuTA0Mo&s=VMkjr7T57NEpDAKpUz6DP8lDN3K2Q69yenoxF6WUtDU&e=

---

From: Joe Touch <[email-masked]>
Date: Thu, 15 Aug 2019 08:28:28 -0700

> On Aug 15, 2019, at 7:26 AM, Ron Bonica <[email-masked]> wrote:
> 
> Joe,
> 

Sure, but what is the measure of “more”, esp. vs how many other features are fragile and break *all* communication?

Unless we ever get serious about protocol compliance, it’s a huge waste of time to focus on levels of non-compliance.

Regardless, what’s wrong or inaccurate about my suggested revision?

Joe

---

From: Bob Hinden <[email-masked]>
Date: Thu, 15 Aug 2019 08:33:16 -0700

Joel,

> On Aug 15, 2019, at 7:00 AM, Joel Halpern <[email-masked]> wrote:
> 

I sent Alissa some proposed text, but got back what I interpreted as a vacation email.   I note there is an IESG call a week from today, so I suspect we will hear back next week.

Bob

---

From: Fernando Gont <[email-masked]>
Date: Thu, 15 Aug 2019 23:03:44 +0300

Folks,

+1

On 15/8/19 20:45, Ron Bonica wrote:
> Joe,
> 
> I am fine with this text if everybody else is.
> 
>                                     Ron
> 
> 
>