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:[email protected]
<mailto:[email protected]>]
*Sent:* 4. januar 2016 11:48
*To:* Yoshifumi Nishida <[email protected]
<mailto:[email protected]>>
*Cc:* General area reviewing team <[email protected]
<mailto:[email protected]>>;
[email protected]
<mailto:[email protected]>; The IESG
<[email protected] <mailto:[email protected]>>
*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
<[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.
*/[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
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
