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

Hi Med,

one more small nit that I saw just now. Maybe you can change 

"NAT64 translation allows IPv6-only clients to contact IPv4
       servers using unicast UDP, TCP, or   ICMP.“

to something like

"NAT64 translation allows IPv6-only clients to contact IPv4
       servers using e.g. UDP, TCP, or ICMP.“

Thanks!
Mirja

> Am 24.09.2018 um 10:55 schrieb <mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com>:
> 
> Re-,
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net]
>> Envoyé : lundi 24 septembre 2018 10:14
>> À : BOUCADAIR Mohamed IMT/OLN
>> Cc : The IESG; opsawg@ietf.org; draft-ietf-opsawg-nat-yang@ietf.org; opsawg-
>> chairs@ietf.org
>> 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.
> 
> 
>> 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. 
> 
>> 
>> 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.
> 
>> 
>> Mirja
>> 
>> 
>> 
>>> Am 24.09.2018 um 07:39 schrieb <mohamed.boucadair@orange.com>
>> <mohamed.boucadair@orange.com>:
>>> 
>>> Hi Mirja,
>>> 
>>> Thank you for the review.
>>> 
>>> Please see inline.
>>> 
>>> Cheers,
>>> Med
>>> 
>>>> -----Message d'origine-----
>>>> De : OPSAWG [mailto:opsawg-bounces@ietf.org] De la part de Mirja Kühlewind
>>>> Envoyé : vendredi 21 septembre 2018 18:20
>>>> À : The IESG
>>>> Cc : opsawg@ietf.org; draft-ietf-opsawg-nat-yang@ietf.org; opsawg-
>>>> chairs@ietf.org
>>>> Objet : [OPSAWG] Mirja Kühlewind's Discuss on draft-ietf-opsawg-nat-yang-
>> 15:
>>>> (with DISCUSS)
>>>> 
>>>> Mirja Kühlewind has entered the following ballot position for
>>>> draft-ietf-opsawg-nat-yang-15: Discuss
>>>> 
>>>> When responding, please keep the subject line intact and reply to all
>>>> email addresses included in the To and CC lines. (Feel free to cut this
>>>> introductory paragraph, however.)
>>>> 
>>>> 
>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>> 
>>>> 
>>>> The document, along with other ballot positions, can be found here:
>>>> https://datatracker.ietf.org/doc/draft-ietf-opsawg-nat-yang/
>>>> 
>>>> 
>>>> 
>>>> ----------------------------------------------------------------------
>>>> DISCUSS:
>>>> ----------------------------------------------------------------------
>>>> 
>>>> Thanks for a well-written document and also for considering other
>> protocols
>>>> like SCTP. I've put in a discuss because I would really like have a quick
>>>> discussion here to double-check that we do the right thing, however, it
>> might
>>>> well be that we can resolve this discuss without any changes. My question
>> is:
>>>> given the model is designed to be generic enough to incorporate other
>>>> transport
>>>> protocols, I'm wondering if it would be possible to also define the timers
>>>> you
>>>> have there in a more generic way such that they can be re-used for other
>>>> protocols (maybe just changing the name and adding some explanation text).
>>> 
>>> [Med] The document includes timers that are valid for any transport
>> protocol (e.g., per-port-timeout, hold-down, etc.). Things are more
>> complicated for the other timers. For example, one could imagine that the
>> same timer can be used to timeout any session (e.g., UDP and ICMP),
>> nevertheless we do have different default/recommended values per transport
>> protocol (e.g., 300s for UDP and 60s for ICMP). Also, existing
>> implementations/deployments are used to allow for differentiating the
>> behavior per transport protocol. For TCP, there are more state compared to
>> UDP, hence the need for more specific timers. Other protocols may reuse some
>> of these specific timers if needed. This should be described in an extension
>> document, not in this one.
>>> 
>>>> 
>>>> As a side node: I myself have been working on a model for a
>>>> protocol-independent state machine a bit (see draft-trammell-plus-
>>>> statefulness;
>>>> now expired); maybe that's a helpful reference to have a quick look at…
>>>> 
>>> 
>>> [Med] Thank you for the reference.
>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OPSAWG mailing list
>>>> OPSAWG@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/opsawg
> 