Re: [Int-area] SEAL - draft-templin-intearea-seal-05.txt

["Templin, Fred L" <Fred.L.Templin at boeing.com>]

Eliot,

Thanks for taking a look; I believe I can address most of
your concerns in the next document version. I will work
through the comments and let you know when I am ready to
discuss further.

About publication category, there is already an earlier
version of SEAL awaiting publication as an experimental
RFC via the independent submissions stream. Like many
others in the independent stream, that publication has
been held up for some time now so it was necessary to
move forward with the new version of SEAL we are
discussing here.

Again, thanks for your time.

Fred
fred.l.templin at boeing.com

> -----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).  It provides back-signaling in an attempt to cause tunnel
> ingresses to reduce 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.
> 
> 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.
> 
> There are a number of imprecise terms, such as "reasonable reliability"
> that should be better qualified.  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.
> 
> ???
> 
> 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?
> 
> 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.
> 
> 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.
> 
> Again, I wish I had more time for more detailed review.
> 
> Eliot
> 
> _______________________________________________
> Int-area mailing list
> Int-area at ietf.org
> https://www.ietf.org/mailman/listinfo/int-area