RE: [tcpm] Re: draft-ietf-tcpm-tcp-uto-05

> -----Original Message-----
> From: Lars Eggert [mailto:lars.eggert@nokia.com] 
> Sent: Wednesday, May 30, 2007 12:32 AM
> To: ext Alfred HÎnes
> Cc: tcpm@ietf.org; ext Fernando Gont
> Subject: [tcpm] Re: draft-ietf-tcpm-tcp-uto-05
> 
> > (1)
> >
> > Yet, as an aid to implementors, I suggest to use more 
> specific names 
> > that can be easily carried over unchanged into 
> implementations and/or 
> > APIs without danger of name collisions; to be constructive, 
> I suggest:
> >
> >    ENABLED     -->  TCP_USE_UTO
> >
> >    CHANGEABLE  -->  TCP_ACCEPT_UTO
> >
> > and, to achieve more generic naming, also:
> >
> >    LOCAL_UTO   -->  TCP_LOCAL_UTO
> >
> > For the same reasons it might be useful to change the names of the 
> > configuration variables in Section 3.1 as well, e.g.:
> >
> >    U_LIMIT    -->   TCP_UTO_MAX
> >
> >    L_LIMIT    -->   TCP_UTO_MIN
> 
> This has been suggested before, but I think it was in an 
> off-list email.

Hmm.. The current email, (I don't see Alfred's original email on the list) is off-list as well :-)

Anyways, I suggested the same thing which Alfred is mentioning above, here is the snippet of the email exchange (actually the last one, which hopefully captures the crux) :-

============================== BEGIN EMAIL EXCH. ===================================
-----Original Message-----
From: Anantha Ramaiah (ananth) 
Sent: Wednesday, May 16, 2007 5:23 PM
To: 'Fernando Gont'; mallman@icir.org
Cc: Lars Eggert; Ted Faber
Subject: RE: UTO draft. 

Fernando,
   No sweat. Just leave it as it is. From what I recall, the variable names weren't that long.. Anyways, I see that when you are writing the equations, it might tend to get split up into 2 lines.
  Also Lar's point about TCP_USER_TIMEOUT is well taken as well.. 
-Anantha  

> -----Original Message-----
> From: Fernando Gont [mailto:fernando@gont.com.ar]
> Sent: Tuesday, May 15, 2007 11:56 PM
> To: mallman@icir.org; Anantha Ramaiah (ananth)
> Cc: Lars Eggert; Ted Faber
> Subject: Re: UTO draft. 
> 
> Hi All,
> 
> One of Anantha's comments suggested to precede all variables with the 
> prefix "UTO_". I was meaning to commit the change.
> But it turns out that it results in the names of the variables being 
> terribly long, the recommended formula spanning more than one row, 
> etc.
> 
> So, unless anybody feels strong about committing this change (please 
> speak up), I will not commit it.
> 
> As pointed out by Lars, implementations are free to do this type of 
> thing internally.  (And, after all, TCP's timeout is not named 
> "TCP_USER_TIMEOUT"... and the same is true for the name of virtually 
> all variables/constants).
> 
> Thanks,
> 
> --
> Fernando Gont

=========================== END EMAIL EXCH. ================================

> 
> Implementors are free to choose whatever variable names they 
> like for their implementation - there is no expectation that 
> these names will be used as-is. For example, RFC2581 and 
> RFC2988 define similar state variables, for which 
> implementations also choose different names.

True.. But the point is to try to use some intuitive names, you don't want to chose something slike X Y Z etc., I am not saying that you have done so, simply trying to be argumentative since, IMO the above argument does seem to make sense. :-) But your other points are well taken.

> 
> For this reason I'm unconvinced that renaming the state 
> variables is necessary. (At the very least, I wouldn't want 
> to add the "TCP_"  
> prefix. If the WG thinks some of the other name changes 
> clarify things, I could be convinced to go with it.)

Sure that is a good plan of action, leave it to the consensus of the WG. Anyways it is a minor thing, so no big deal, really.

-Anantha

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