Re: SEAL - draft-templin-intearea-seal-05.txt

Hi Eliot,

Thanks for taking the time to post this review, and see
my responses below:

> -----Original Message-----
> From: int-area-bounces <at> ietf.org [mailto:int-area-bounces <at> ietf.org] On Behalf Of Eliot Lear
> Sent: Tuesday, September 22, 2009 7:42 AM
> To: Ralph Droms
> Cc: int-area <at> ietf.org
> Subject: Re: [Int-area] SEAL - draft-templin-intearea-seal-05.txt
> 
> Ralph,
> 
> Here are a few comments.  This document deserves more time than I've
> given it.
> 
> Summary
> 
> This protocol specification provides a new and different tunneling
> mechanism (actually, really two - one over UDP and one within in a new
> protocol).

I would prefer to call it a new and different "encapsulation"
rather than a new and different tunneling mechanism. The
intent is that this new encapsulation would be used in
conjunction with new and existing tunneling protocols,
e.g., VET.

> It provides back-signaling in an attempt to cause tunnel
> ingresses to reduce their MTU.

That is part of it, yes, but I would prefer to say that the
goal is to cause the tunnel ingresses to "adjust their packet
sizing parameters", which does not always equate to reducing
their MTU.

> Comments
> 
> To start with, this document could do with a heavy dose of editing for
> brevity and clarity.  Substantial time is spent on the case for SEAL.  I
> think we can all accept that there are MTU problems on the network.  We
> needn't revisit each and every one of them.  Or if we must, let's do so
> in a different document.  So for starters, start the doc at §1.2.

The document actually started out as you say, but over
the course of several version updates the motivational
text was added at the suggestion of others who felt the
reader would appreciate a broader discussion of the issues. 
> 
> Second, while I realize that some might have grown attached to the name,
> and that this is picky, the term "subnetwork" is so overloaded that it
> is confusing to the casual reader such as myself.

The term subnetwork is defined inline in the abstract and
then again in the Introduction, but in concurrence with
Margaret's point the document should probably include a
Terminology section. Would it be satisfactory for me to 
nclude a formal definition for subnetwork under a new
terminology section?

> There are a number of imprecise terms, such as "reasonable reliability"
> that should be better qualified.

I will work on this, as well as any others you could
point out.

> There are also some sentences that
> just don't make sense.  For instance:
> 
>    While it is well known that the addressing
>    properties of IPv4 are limited (hence the larger address space
>    provided by IPv6), there is a lesser-known but growing consensus that
>    other limitations may be unable to sustain continued growth.
> 
> ???

I will re-work this sentence in the next document version
such that it will hopefully flow better into the following
paragraphs, which is what it was intended to do.

> This document normatively makes references to several other drafts,
> including [draft-templin-intarea-vet], [draft-templin-ranger] and
> [draft-russert-rangers] for a singular notion of the "enterprise
> abstraction".  From a matter of readibility, and general approach to
> standards, for a single definition can we reference a single document?

I was wanting these documents to be viewed as informative,
but I think by "normative", you are meaning that since
the term "enterprise" is not defined in this document
then the reader has to go off and read the other documents
to see what is meant? Would it be satisfactory for me to
simply include a definition for enterprise in a new
Terminology section?

> Section 4.3.6 dicusses the need for per-ETE state.  Security
> Considerations do not adequately address mitigating attacks based on,
> say, large pings or some other approach that can force a large packet to
> return.

I'm not sure I see that scenario. SEAL is concerned with
unidirectional MTU determination (i.e., from ITE->ETE),
and the ITE would not take any actions on behalf of large
packets coming back. Did I miss your meaning?

> In addition, any mechanism where we would expect wide deployment
> probably deserves substantial review.  Experimental in this case would
> seem to me to be more appropriate than Proposed Standard.

We already have an earlier version of SEAL in the
publication queue as experimental category, and there
has been substantial review of the SEAL approach over
the years both on and off list that has helped shape
the current document version. Proposed Standard seemed
like the next logical step.

> Again, I wish I had more time for more detailed review.

Thanks for taking the time to make these comments,

Fred
fred.l.templin <at> boeing.com

> 
> Eliot
> 
> _______________________________________________
> Int-area mailing list
> Int-area <at> ietf.org
> https://www.ietf.org/mailman/listinfo/int-area