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

well said Edward! I concur with your take on this and was alluding to
the same ideas that you mentioned below. To highlight your comment
again:

> 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.

I think it does captures the debate we are having here. My
opinion is that if we view these changes as Updates to RFC793, then
they may be perceived as mandatory changes and again open discussions
around IPR, MAY/SHOULD/MUST language and so on. However if we have
a  banner statement stating that implementing these changes are
recommended/optional and enumerate situations in which they are 
helpful this should alleviate a lot of opposing view.  And
once we have this statement and if a tcp implementation does decide
to have this feature then it MUST be this way for the feature to work
correctly.

So to reiterate to the group, we need an applicability statement that
highlights the implementations/deployments/applications that are
RECOMMENDED to have this fix, with others being OPTIONAL. However,
the features/changes themselves being MUST (or SHOULD, if that's what
it would take for a consensus). Is the group in agreement here?

my 0.02
Mitesh

> -----Original Message-----
> From: Edward A. Gardner [mailto:eag@ophidian.com] 
> Sent: Monday, October 01, 2007 11:16 AM
> To: tcpm@ietf.org
> Subject: 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
> 

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