Hi Alexey, On Mon, Jan 4, 2016 at 2:48 AM, Alexey Melnikov <[email protected]> wrote:
> Hi Yoshi, > > > On 02/01/2016 23:03, Yoshifumi Nishida wrote: > > Hi Alexey, > > On Sat, Jan 2, 2016 at 6:49 AM, Alexey Melnikov < > <[email protected]>[email protected]> wrote: > >> Hi Yoshi, >> >> On 2 Jan 2016, at 09:20, Yoshifumi Nishida < <[email protected]> >> [email protected]> wrote: >> >> Hi Alexey, >> >> Thanks for the comments. >> >> On Wed, Dec 23, 2015 at 7:40 AM, Alexey Melnikov < >> <[email protected]>[email protected]> 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. > Thanks! > 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). > I am not the best person to answer it. But, as far as I checked, RFC6525, RFC7053 and RFC7496 don't define numeric values except chunk values which will be on the wire. Thanks, -- Yoshi
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
