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

[Yoshifumi Nishida <[e-mail]>]

Hi Alexey,

On Mon, Jan 4, 2016 at 2:48 AM, Alexey Melnikov <[e-mail]>
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 <
> <[e-mail]>[e-mail]> wrote:
>
>> Hi Yoshi,
>>
>> On 2 Jan 2016, at 09:20, Yoshifumi Nishida < <[e-mail]>
>> [e-mail]> wrote:
>>
>> Hi Alexey,
>>
>> Thanks for the comments.
>>
>> On Wed, Dec 23, 2015 at 7:40 AM, Alexey Melnikov <
>> <[e-mail]>[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.
>

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