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

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:ietf@kuehlewind.net]
> Envoyé : lundi 24 septembre 2018 11:29
> À : 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,
> 
> 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
> >