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

Reply via email to