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
Juniper Business Use Only
-----Original Message-----
From: Brian E Carpenter <[email protected]>
Sent: Tuesday, August 6, 2019 9:49 PM
To: Joel M. Halpern <[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)
On 07-Aug-19 13:06, Joel M. Halpern 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.
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
>
> 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 <[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_
>>>>> 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=
>>>>> 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.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=
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> ----
>>>>> 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://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=
>>
> .
>
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
