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

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

I saw that, however, just because RFC6147 only specifies this for UDP, TCP and ICMP, this does mean that there cannot be a future spec that also includes other protocols and I don’t think there is need to restrict the configuration option only to these protocols.


> Am 24.09.2018 um 11:36 schrieb <[e-mail]> <[e-mail]>:
> 
> Re-,
> 
> I'm afraid I cannot do this modification because that text is referring to RFC6147 which says explicitly: 
> 
> ==
>   This document describes stateful NAT64 translation, which allows
>   IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or
>   ICMP.  
> ==
> 
> Thank you. 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Mirja Kuehlewind (IETF) [mailto:[e-mail]]
>> Envoyé : lundi 24 septembre 2018 11:29
>> À : 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,
>> 
>> 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 <[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.
>>> 
>>> 
>>>> 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 <[e-mail]>
>>>> <[e-mail]>:
>>>>> 
>>>>> Hi Mirja,
>>>>> 
>>>>> Thank you for the review.
>>>>> 
>>>>> Please see inline.
>>>>> 
>>>>> Cheers,
>>>>> Med
>>>>> 
>>>>>> -----Message d'origine-----
>>>>>> De : OPSAWG [mailto:[e-mail]] De la part de Mirja
>> Kühlewind
>>>>>> Envoyé : vendredi 21 septembre 2018 18:20
>>>>>> À : The IESG
>>>>>> Cc : [e-mail]; [e-mail]; opsawg-
>>>>>> [e-mail]
>>>>>> 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
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/opsawg
>>> 
>