Re: [tcpm] WGLC for UTO

[Joe Touch <[e-mail]>]

Pasi Sarolahti wrote:
> 
> On Oct 15, 2007, at 14:48, ext Mark Allman wrote:
> 
>>> Regarding the Proposed Standard vs. Experimental issue, I think this
>>> draft, like the other new TCP extensions, should first go to
>>> Experimental as a rule of thumb. 

I don't agree. Whether something goes to experimental is determined by
whether there is an experiment needed. The standards track has phases
for us to gain confidence with extensions - that's why things don't just
go straight to Standard.

There are three choices, BTW:

	- standards track
		should be for things we think are useful to the
		Internet as a whole, and not harmful to the Internet
		as a whole if widely deployed

	- experimental
		things for which an experiment in deployment will help
		either gain confidence in group behavior or parameter
		determination

	- informational
		things which are not harmful to the Internet as a
		whole if widely deployed, but may be useful in
		specific environments

Anything that is harmful to the Internet as a whole should be documented
more as something to avoid, IMO.

>>> I'm concerned about the increasing
>>> complexity and size of "the standards track" TCP implementation. 

That should be a consideration for all items in the standards track, and
is largely - AFAICT - determined by the MUST/SHOULD/MAY designations.

I will note, as others have as well, that there's a problem with the
menu of choices out there. Many choices are intermingled, and the
roadmap should be clear on which current choices are related. The same
relationship can be true for items within a mechanism, as we've discused
on this list as well.

Perhaps it would be useful for us to adopt an informal requirement that
TCP mods come with three clear summaries:

1) whether the proposed mechanism is, as a whole, MUST/SHOULD/MAY

2) which components of the proposed mechanism are MUST/SHOULD/MAY

3) what other dependent choices are MUST/SHOULD/MAY

It'd be useful to have a section that lists these succinctly in summary,
at the beginning of the document, e.g., "Requirements Levels and
Dependencies".

>> (1) What 'careful evaluation' do you think should be done during
>>     Experimental?
> 
> In case of UTO, given
> * possibly limited budget of TCP implementation size (in embedded
> devices, for example)

MAY and SHOULD allow designers to omit things for space constraints.

> * limited TCP option space

MAY and SHOULD allow designers - and users - to disable things for
header space limitations.

> * possibility of resource exhaustion attacks as discussed in security
> considerations

That ought to be addressed before being released. Security questions are
not the kinds of things we want to gain experience with via widescale
deployment.

> Should I implement UTO and when should I enable it?

MAY handles that.

Joe

_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm