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] <mailto:[email protected]>> wrote:
Hi Yoshi,
On 2 Jan 2016, at 09:20, Yoshifumi Nishida <[email protected]
<mailto:[email protected]>> wrote:
Hi Alexey,
Thanks for the comments.
On Wed, Dec 23, 2015 at 7:40 AM, Alexey Melnikov
<[email protected] <mailto:[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.
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).
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
