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

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

Work for me. (I wouldn’t use the word tempting but anyway.)

I will clear my discuss with this update!

Mirja



> Am 24.09.2018 um 13:57 schrieb <[e-mail]> <[e-mail]>:
> 
> Re-,
> 
> I can add this text to cover your comment:
> 
>   It is tempting to define TCP-specific timers as generic timers
>   applying to any connection-oriented protocol.  Nevertheless, such
>   approach is not followed in this document because there is no
>   standard document specifying such generic behavior.  Future documents
>   may be edited to clarify how to reuse TCP-specific timers when
>   needed.
> 
> Please let me know if this is OK. 
> 
> Thank you.
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Mirja Kuehlewind (IETF) [mailto:[e-mail]]
>> Envoyé : lundi 24 septembre 2018 13:45
>> À : BOUCADAIR Mohamed IMT/OLN
>> Cc : [e-mail]; [e-mail]; opsawg-
>> [e-mail]; The IESG
>> Objet : Re: [OPSAWG] Mirja Kühlewind's Discuss on draft-ietf-opsawg-nat-yang-
>> 15: (with DISCUSS)
>> 
>> Hi Med,
>> 
>> top-posting as we coming closer to a conclusion here. It’s okay to leave it
>> tcp specific as you say below. Maybe you can add some text in the doc saying
>> basically exactly what you say below, a future spec could describe how to
>> reuse these timers. (I guess that could fit in to 2.3)…?
>> 
>> Mirja
>> 
>> 
>> 
>>> Am 24.09.2018 um 13:36 schrieb <[e-mail]>
>> <[e-mail]>:
>>> 
>>> Re-,
>>> 
>>> Please see inline.
>>> 
>>> Cheers,
>>> Med
>>> 
>>>> -----Message d'origine-----
>>>> De : Mirja Kuehlewind (IETF) [mailto:[e-mail]]
>>>> Envoyé : lundi 24 septembre 2018 11:39
>>>> À : BOUCADAIR Mohamed IMT/OLN
>>>> Cc : [e-mail]; [e-mail]; opsawg-
>>>> [e-mail]; The IESG
>>>> Objet : Re: [OPSAWG] Mirja Kühlewind's Discuss on draft-ietf-opsawg-nat-
>> yang-
>>>> 15: (with DISCUSS)
>>>> 
>>>> Hi med,
>>>> 
>>>> inline...
>>>> 
>>>>> Am 24.09.2018 um 11:31 schrieb <[e-mail]>
>>>> <[e-mail]>:
>>>>> 
>>>>> Re-,
>>>>> 
>>>>> Please see inline.
>>>>> 
>>>>> Cheers,
>>>>> Med
>>>>> 
>>>>>> -----Message d'origine-----
>>>>>> De : Mirja Kuehlewind (IETF) [mailto:[e-mail]]
>>>>>> Envoyé : lundi 24 septembre 2018 11:23
>>>>>> À : BOUCADAIR Mohamed IMT/OLN
>>>>>> Cc : The IESG; [e-mail]; [e-mail];
>>>> opsawg-
>>>>>> [e-mail]
>>>>>> Objet : Re: [OPSAWG] Mirja Kühlewind's Discuss on draft-ietf-opsawg-nat-
>>>> yang-
>>>>>> 15: (with DISCUSS)
>>>>>> 
>>>>>> Hi Med,
>>>>>> 
>>>>>> please see inline.
>>>>>> 
>>>>>>> Am 24.09.2018 um 10:55 schrieb <[e-mail]>
>>>>>> <[e-mail]>:
>>>>>>> 
>>>>>>> Re-,
>>>>>>> 
>>>>>>> Please see inline.
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> Med
>>>>>>> 
>>>>>>>> -----Message d'origine-----
>>>>>>>> De : Mirja Kuehlewind (IETF) [mailto:[e-mail]]
>>>>>>>> Envoyé : lundi 24 septembre 2018 10:14
>>>>>>>> À : BOUCADAIR Mohamed IMT/OLN
>>>>>>>> Cc : The IESG; [e-mail]; [e-mail];
>>>>>> opsawg-
>>>>>>>> [e-mail]
>>>>>>>> Objet : Re: [OPSAWG] Mirja Kühlewind's Discuss on draft-ietf-opsawg-
>> nat-
>>>>>> yang-
>>>>>>>> 15: (with DISCUSS)
>>>>>>>> 
>>>>>>>> Hi Med,
>>>>>>>> 
>>>>>>>> thanks for you reply. It makes sense that you may want different
>> values
>>>>>> for
>>>>>>>> different protocol in the case of UDP and TCP.
>>>>>>> However, I think the question
>>>>>>>> is not that much which protocol but which properties does the protocol
>>>>>> have,
>>>>>>>> e.g. all connection-oriented protocol probably have some kind of
>>>> handshake
>>>>>>>> that can be used to trigger these timers.
>>>>>>>> 
>>>>>>> 
>>>>>>> [Med] I hear you... but the issue is the other way around: availability
>>>> of
>>>>>> a stateful implementation which adheres to that design approach.
>>>>>> 
>>>>>> Understood. And I also understand that your motivation is to aline with
>>>>>> existing implementations, which makes sense. I just wonder if there is a
>>>> way
>>>>>> to make it even easier to enable new implementations for other protocols
>>>> in
>>>>>> future (without defining a new protocol-specific extension).
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> Is it maybe possible to model these times generally for certain
>> protocol
>>>>>>>> feature and the have the ability to overwrite these „default“ values
>>>> with
>>>>>>>> protocol-specific values?
>>>>>>> 
>>>>>>> [Med] There are ways to overwrite default values, e.g., define a type
>> and
>>>>>> derive new one from it. Nevertheless, it is simpler to define explicit
>>>> timers
>>>>>> as we have done in the document given that protocol differentiation is a
>>>>>> requirement. One for UDP, one for ICMP, and state-specific timers for
>> TCP.
>>>>>> Future documents can re-use state-specific timers for generic
>>>> configuration
>>>>>> matters, if needed.
>>>>>> 
>>>>>> 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...
>>>>>> 
>>>>> 
>>>>> [Med] No problem to change the name if this helps, but I'm afraid this
>>>> effort may be useless if there is no reference document that explains how
>>>> these timers can be used for other protocols.
>>>> 
>>>> Understood. I don’t think people go ahead an implement this without a
>>>> reference doc (however, some might actually have implementation for other
>>>> protocols that are just not documented in an RFC, anyway) but at least you
>>>> would not necessary need to extend the yang model as soon as we have the
>>>> reference docs.
>>>> 
>>> 
>>> [Med] Another approach is that the reference document can indicate that
>> tcp-* timers are used to instruct the behavior, and hence no medication will
>> be required to the module. Given that we may be speculating about what would
>> be defined in the future, I do still have a preference for the current
>> approach in the draft. If a generic approach is defined in a future standard,
>> then it is easy to define an extension by reusing what is already defined for
>> TCP.
>>> 
>>>>> 
>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> Given that these protocol specific differences especially in NAT are a
>>>>>> huge
>>>>>>>> problem for the deployment of new protocol it would be really nice if
>>>> this
>>>>>>>> could be model in a generic as possible way. E.g. would be nice to be
>>>> able
>>>>>> to
>>>>>>>> use the same config for the config for quic (one a NAT is implemented
>> to
>>>>>>>> detect the quic handshake over udp).
>>>>>>> 
>>>>>>> [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.
>>>>> 
>>>>> [Med] We can already do that with this model: per-port-timeout. An entry
>>>> for 443, for example may be provided in such case. No?
>>>> 
>>>> That already help. However, you might not always want to configure a long
>>>> time-out without e.g. also having the trans-open-timeout as well which
>> would
>>>> be possible to implement with quic as the handshake is visible in clear.
>>>> 
>>>> Btw. is the per port time-out protocol-independent? Because HTTPS is also
>>>> using 443 (over TCP) and I guess you would want the usually tcp timers
>> there.
>>>> So not sure if that config using the per-port-timeout would work at all?
>>>> 
>>> 
>>> [Med] Good catch. A leaf is missing to indicate the protocol. If no
>> protocol is indicated, this means "any protocol". Updated my local copy.
>> Thanks.
>>> 
>