Re: [tcpm] tcpsecure: how strong to recommend?

I normally just lurk here silently, and I certainly wasn't at Chicago or 
any of the other meetings discussing this.  But it strikes me that people 
are getting caught up in language problems and losing sight of what is 
desired.  In particular there is confusion between discussing whether 
implementing tcpsecure itself is mandatory / recommended / optional vs. 
whether some feature of tcpsecure is mandatory / recommended / optional, 
given that tcpsecure itself is implemented.

Clearly there will be implementations that do not implement 
tcpsecure.  Historical implementations.  Those that achieve similar ends 
through different means (e.g. IPSEC, MD5) and therefore have no need or use 
for tcpsecure.

Clearly there are implementations that need or want tcpsecure, BGP being 
the prominent example.

So there are two implementation variations that we consider necessary.  Is 
there any need or point in more?  Remember that compatibility problems, 
testing, etc. scale as (at least) NxN.  There is enormous practical 
incentive to minimize the number of variations that are implemented and 
deployed.

I contend that the specifications or RFCs should allow exactly two 
variations.  Those implementations that ignore and do not implement 
tcpsecure at all.  And those that implement all of it.

I think the way to accomplish that is to include an applicability statement 
saying that implementing tcpsecure is optional.  An implementation MAY or 
MAY NOT implement it.  And giving guidance on when one should or should 
not.  Probably something along the lines of saying one should implement it 
unless the same ends are accomplished by other means, and giving several 
examples of other means.

But if an implementation does choose to implement tcpsecure, then it MUST 
implement all of it -- the features, protocol behavior, etc. are described 
in the RFC using MUST.  Conversely, if an implementation chooses not to 
implement tcpsecure, then it MUST NOT implement any part of it.  Either 
implement all of tcpsecure or none of it.  Yes, this requires careful 
phrasing, but it can be done.

I am assuming that all the features included in tcpsecure are considered 
necessary or desirable for BGP.  If any are not, shouldn't they be excluded 
on the grounds that no one is ever likely to implement them?

One might contemplate the impact of the IETF requirement for independently 
developed, interoperable implementations.  The three tcpsecure (three 
choices of MAY vs. SHOULD that are being discussed) interact to some 
degree.  If each are described using MAY or SHOULD, we get eight 
implementation variations.  Each needing two independent implementations 
means at least sixteen implementation, which is absurd.  Does anyone really 
want to allow some arguably ill-informed implementors to pick and choose, 
as opposed to saying all or none?  Isn't it our responsibility as 
architects (who claim to know what we are doing :-) to minimize variations, 
not unnecessarily expand them?

Caveat: my primary experience is with the T10 and T11 standards (SCSI and 
friends), I apologize for my errors with IETF terminology and practice.

Dropping back into my hole to resume lurking.

Edward A. Gardner               eag at ophidian dot com
Ophidian Designs                719 593-8866
1262 Hofstead Terrace
Colorado Springs, CO  80907

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm