Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10]

David/Wes,

I don't intend to prolong this discussion, but the current stance comes across very incurrate.

Based on the example which you gave narrated below :

RFC 3168 used up 2 reserved bits in the TCP header, and hence updated the RFC 793. Now RFC 3168 is optional. This doesn't prevent the fact that "updates" can be used as a qualifier. 

With TCP secure, it changes the processing rules of certain segments (algorithm), so strictly speaking it does update RFC 793. It is optional since none of the conditions is MUST and also there is an AS in place. Here you can't use "updates" since that becomes too strong a word! This beats me.

It appears that we are reading too much into the word "updates" rather than acknowledging its simplicity, i.e, it is just a quick reference point.

So, I guess I am confused as to how and where the lines are drawn. Hence, I think that it would be expedient to seek the advice of IESG as well in this matter. Isn't a good thing ? 

$0.02,
-Anantha
> -----Original Message-----
> From: David Borman [mailto:david.borman@windriver.com] 
> Sent: Tuesday, September 30, 2008 8:55 AM
> To: Lars Eggert; tcpm@ietf.org
> Cc: ext Joe Touch; Alfred HÎnes; Anantha Ramaiah (ananth); 
> rrs@cisco.com; Mitesh Dalal (mdalal)
> Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10]
> 
> (WG co-chair hats on)
> 
> Wes and I discussed this, and we agree with Lars.  "Updates" 
> is generally for things that are now required if you 
> implement the cited spec.  Tcpsecure doesn't fit that 
> criteria, so the "Updates 793"  
> doesn't belong on this document.  As Lars said, this is less 
> than perfect, but it is what we currently have.
> 
> FWIW, I could only find one RFC that has "Updates 793", and 
> that is RFC 3168, "The Addition of Explicit Congestion 
> Notification (ECN) to IP", which allocates two of the 
> reserved flags in the TCP header.
> 
> 			-David & Wes, TCPM WG co-chairs
> 
> On Sep 30, 2008, at 4:43 AM, Lars Eggert wrote:
> 
> > Hi,
> >
> > (individual hat on)
> >
> > On 2008-9-29, at 20:31, ext Joe Touch wrote:
> >> Is it possible that a SHOULD isn't considered a "updates"?
> >
> > RFC2119 language has nothing to do with the "updates" 
> relationship.  
> > It's the applicability that matters.
> >
> > "Updates 793" on document X means "if you implement 793 you 
> also need 
> > to implement X". That is, because "updates" is typically 
> used when a 
> > new document fixes critical bugs in an existing 
> specification or adds 
> > mandatory new functionality.
> >
> > For this document the applicability statement is basically "SHOULD 
> > implement when vulnerable, MAY otherwise". That's a conditional 
> > "updates". Unfortunately, the "updates" header isn't 
> expressive enough 
> > to convey this.
> >
> > We're left with two less-than-optimal choices: Add "updates 793", 
> > which doesn't capture the conditional expressed by the 
> applicability 
> > statement, or omit "updates 793", which is also inaccurate.
> >
> > My reason for suggesting to omit the "updates" - and this is a 
> > personal preference, I'll respect the WG decision and would like to 
> > head other opinions - is that a plain "updates 793" looks 
> like a "you 
> > must implement this when implementing 793", and we had a long 
> > discussion around the applicability statement that seemed 
> to indicate 
> > that the WG didn't want to make this blanket recommendation.
> >
> > Lars
> >
> > PS: As an example, look at the recent RFC5348, which is TFRC. It 
> > obsoletes RFC3448 (which was the old version of TFRC) but it also 
> > updates RFC4342 (DCCP's CCID3), which implements TFRC inside DCCP.
> > The "updates" relationship here means that CCID3 
> implementations must 
> > now (also) implement RFC5348, i.e., the new version of 
> > TFRC._______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm
> 
> 
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm