Re: [OPSAWG] Mirja Kühlewind's Discuss on draft-ietf-opsawg-nat-yang-15: (with DISCUSS)

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Jürgen,

I don’t want to push this back to the wg (expect people would be excited on their own to further work on this, which I assume is not the case) and I do understand that this document relies on the information can be found in other specifications which is the right approach.

I’m just trying to figure out if there is anything easy to do to make it easier for future implementations which cover other protocol to also use this model (without extension). I also understand that renaming alone may not be sufficient but it also may be sufficient. We just don’t really know and therefore making the naming more generic (and mention in the doc that these timers could be used for other protocol if suitable) provides at least the chance that it would work.

Please get me right, I’m holding the discuss to exactly have this discussion. However, I don’t necessarily want to enforce a chance if that is not adequate.

Mirja


> Am 24.09.2018 um 12:12 schrieb Juergen Schoenwaelder <[e-mail]>:
> 
> On Mon, Sep 24, 2018 at 11:23:07AM +0200, Mirja Kuehlewind (IETF) wrote:
>> 
>> What about maybe renaming the timers and don’t have tcp in the name but explain in the text that these timer are used for tcp but could/should also be used for other connection-oriented protocols…? Would that be an option that could eventually help? E.g. call the "tcp-trans-open-timeout“ just "trans-open-timeout“ and explain that RFC 7857 specifies this for TCP but other implementation for connection-oriented protocols could use the same timer? Just thinking...
>> 
> 
> I assume renaming is not sufficient. If you insist on generic timers,
> then I assume you have to send this document back to the WG to define
> semantics of generic timers and how such generic timers map to
> different protocols.
> 
>>> [Med] For the quic example, one would argue that the UDP-related config parameters are sufficient; there is even no need to inspect whether this is quic or plain UDP packet.
>> 
>> No, that’s exactly the problem. QUIC is a connection-oriented protocol, so it would potentially be possible and desirable to have longer time-outs than you usually have for other UDP traffic. 
>> 
> 
> So here we already hit the first obstacle. QUIC running over UDP,
> which means QUIC timers and UDP timers interacting. So the new generic
> timers would have a way of expressing that. Perhaps having protocol
> specific timers is good enough?
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
>