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

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