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
