Re: [Gen-art] Gen-art LC review of draft-ietf-tsvwg-sctp-failover-14

[Alexey Melnikov <[e-mail]>]

Hi Karen,

On 05/01/2016 10:42, Karen Elisabeth Egede Nielsen wrote:
>
> HI,
>
> Please find some feedback below.
>
> BR, Karen
>
> *From:*Alexey Melnikov [mailto:[e-mail] 
> <mailto:[e-mail]>]
> *Sent:* 4. januar 2016 11:48
> *To:* Yoshifumi Nishida <[e-mail] 
> <mailto:[e-mail]>>
> *Cc:* General area reviewing team <[e-mail] 
> <mailto:[e-mail]>>; 
> [e-mail] 
> <mailto:[e-mail]>; The IESG 
> <[e-mail] <mailto:[e-mail]>>
> *Subject:* Re: Gen-art LC review of draft-ietf-tsvwg-sctp-failover-14
>
> Hi Yoshi,
>
> On 02/01/2016 23:03, Yoshifumi Nishida wrote:
>
>     Hi Alexey,
>
>     On Sat, Jan 2, 2016 at 6:49 AM, Alexey Melnikov
>     <[e-mail] <mailto:[e-mail]>> wrote:
>
>         Hi Yoshi,
>
>
>         On 2 Jan 2016, at 09:20, Yoshifumi Nishida
>         <[e-mail] <mailto:[e-mail]>> wrote:
>
>             Hi Alexey,
>
>             Thanks for the comments.
>
>             On Wed, Dec 23, 2015 at 7:40 AM, Alexey Melnikov
>             <[e-mail]
>             <mailto:[e-mail]>> wrote:
>
>                 I am the assigned Gen-ART reviewer for this draft. The
>                 General Area
>                 Review Team (Gen-ART) reviews all IETF documents being
>                 processed
>                 by the IESG for the IETF Chair. Please wait for
>                 direction from your
>                 document shepherd or AD before posting a new version
>                 of the draft.
>
>                 For more information, please see the FAQ at
>
>                 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
>                 Document: draft-ietf-tsvwg-sctp-failover-14
>                 Reviewer: Alexey Melnikov
>                 Review Date: 2015-12-23
>                 IETF LC End Date: 2015-12-23
>                 IESG Telechat date: (if known) N/A
>
>                 Summary: Ready with a couple of minor points that need
>                 to be clarified.
>
>                 Major issues:
>                 None
>
>                 Minor issues:
>
>                 In Section 5
>
>                    However as [RFC4960] switchback behavior is
>                    suboptimal in certain situations, especially in
>                 scenarios where a
>                    number of equally good paths are available, an SCTP
>                 implementation
>                    MAY support also, as alternative behavior, the
>                 Primary Path
>                    Switchover mode of operation and MAY enable it
>                 based on users’
>                    requests.
>
>                 Did you really mean "users" (human beings) and not
>                 "applications" (programs) here? I.e., is this
>                 something that needs to be exposed in APIs or User
>                 Interfaces.
>
>             Yes, It basically meant if people prefer (which means they
>             understand its advantage and disadvantage), this feature
>             can be activated.
>
>             APIs or UIs can be implemented for this, but I'm not very
>             sure if we need.. Could you elaborate your concern here?
>
>         Your text sounds like a requirement on UIs (and not on APIs),
>         I think you meant a requirement on APIs (with no requirement
>         on UIs, which might expose this option anyway. I personally
>         think that exposing this option to anybody by application
>         developers or system administrators is going to be a mistake).
>         So I think you should change "users'" to "applications'". I am
>         sorry if this sounds like nitpicking, but I think this is an
>         important difference.
>
>     Ok. I see your point. What we have presumed here is something like
>     sysctl command which only administrators can run.
>
>     This is because it might be difficult for endusers to know whether
>     equally good paths a available or not.
>
>     So, an example of the usage is administrators activate this
>     feature after some discussions with their users or customers.
>
>     If we say "enable it based on users' (e.g. system administrators)
>     decisions", do you think it will be clearer?
>
> Yes.
>
> */[Karen Elisabeth Egede Nielsen] Hmm…. /**/We have defined a run-time 
> API for this by purpose. Further in some signaling node 
> implementations in deployment this API has been exposed all the way up 
> to the UI/O&M  interface towards Users (human system 
> administrators/operators) as configurable on a per association level. 
> I do however agree with changing the text either simple replacing 
> “users” with “applications” or by the clarification on system 
> administrators as there is no requirement for such to be controlled by 
> the users on all applications/all systems./*
>
/*Agreed.*/
>
>
> *//*
>
>                 In Section 7.1: should new constants be defined with
>                 specific numeric values, in order to improve
>                 interoperability?
>
>             In my understanding, RFC6458 doesn't define specific
>             numeric values. I prefer to follow the convention of
>             RFC6458 unless there are strong reasons.
>
>         How is ABI interoperability (binary interface interoperability
>         between different implementations, for example if they are
>         implemented as shared libraries) achieved with SCTP options?
>
>     The peer state value is exchanged only between an SCTP stack and
>     its applications. It won't be exchanged between SCTP stacks.
>
>     (SCTP stacks estimate their peers' state from packet loss and
>     other info.)
>
>     I think that's why RFC6458 didn't have to define numeric values.
>
>
> Is this common for SCTP extensions? For other APIs I am familiar with 
> applications are frequently linked against shared libraries, so 
> standardizing numeric values is beneficial (even if they are never 
> sent across the wire).
>
> */[Karen Elisabeth Egede Nielsen] Yes this is common for all constants 
> in the SCTP API, RFC6458. Extensions as well as “base constants”./*
>
Ok. I don't think this is right, but I will let go of this.

Best Regards,
Alexey