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.boucad...@orange.com>
> <mohamed.boucad...@orange.com>:
>
> Re-,
>
> Please see inline.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Mirja Kuehlewind (IETF) [mailto:i...@kuehlewind.net]
>> Envoyé : lundi 24 septembre 2018 10:14
>> À : BOUCADAIR Mohamed IMT/OLN
>> Cc : The IESG; opsawg@ietf.org; draft-ietf-opsawg-nat-y...@ietf.org; opsawg-
>> cha...@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.boucad...@orange.com>
>> <mohamed.boucad...@orange.com>:
>>>
>>> Hi Mirja,
>>>
>>> Thank you for the review.
>>>
>>> Please see inline.
>>>
>>> Cheers,
>>> Med
>>>
>>>> -----Message d'origine-----
>>>> De : OPSAWG [mailto:opsawg-boun...@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-y...@ietf.org; opsawg-
>>>> cha...@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
>
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
