Re: [tsvwg] OPS-DIR review of draft-ietf-tsvwg-sctp-prpolicies-05.txt

[Michael Tuexen <[e-mail]>]

On 2014-12-11 11:57, Romascanu, Dan (Dan) wrote:
> Ø I'm good with Michael submitting an update addressing the comments
> as discussed in this thread.
> 
> Ø
> 
> Ø Thanks,
> 
> Ø
> 
> Ø Spencer
> 
> Me too. Can you please send me a note when this happens, so that I do
> not miss the update?
Sure. The updated version is available at
https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-prpolicies-06
> 
> Thanks for considering my comments.
Thanks for providing them!

Best regards
Michael
> 
> Regards,
> 
> Dan
> 
> FROM: Spencer Dawkins at IETF [mailto:[e-mail]]
>  SENT: Thursday, December 11, 2014 12:10 AM
>  TO: Michael Tuexen
>  CC: Romascanu, Dan (Dan); [e-mail]; [e-mail];
> [e-mail]
>  SUBJECT: Re: OPS-DIR review of
> draft-ietf-tsvwg-sctp-prpolicies-05.txt
> 
> From at least one AD :-)
> 
> On Wed, Dec 10, 2014 at 2:52 PM, Michael Tuexen
> <[e-mail]> wrote:
> 
> On 10 Dec 2014, at 13:23, Romascanu, Dan (Dan) <[e-mail]>
> wrote:
> 
>  > Hi Michael,
>  >
>  > Thank you for addressing the issues raised in the OPS-DIR review.
>  >
>  > First, please see the disclaimer that I put in my review:
>  >
>  >>> Although this document defines an extension of an existing
> protocol, there
>  >> are no explicit considerations about operations and management.
> The OPS
>  >> and Transport ADs should decide whether this is an issue to be
> addressed
>  >> before the document is approved.
>  >
>  > The OPS-DIR reviews are written to help the OPS ADs with a reading
> of the I-Ds in review from the perspective of the operators using the
> and deploying the new protocols or extensions defined by the document.
> We - the reviewers - believe that the operational and manageability
> issues are important, but it's up to the ADs to decide whether they
> are important enough to require changes in the document, and what
> these changes should be.
>  Hi Dan,
> 
>  understood. But I want to understand your points and possibly address
> them...
> 
>> 
>  > More in-line.
>  >
>  > Regards,
>  >
>  > Dan
>  >
>  >
>  >> -----Original Message-----
>  >> From: Michael Tuexen [mailto:[e-mail]]
>  >> Sent: Wednesday, December 10, 2014 1:02 AM
>  >> To: Romascanu, Dan (Dan)
>  >> Cc: [e-mail]; [e-mail]; draft-ietf-tsvwg-sctp-
>  >> [e-mail]
>  >> Subject: Re: OPS-DIR review of
> draft-ietf-tsvwg-sctp-prpolicies-05.txt
>  >>
>  >> On 26 Nov 2014, at 13:33, Romascanu, Dan (Dan)
> <[e-mail]>
>  >> wrote:
>  >>
>  >>> I have reviewed this document as part of the Operational
> directorate's
>  >> ongoing effort to review all IETF documents being processed by the
> IESG.
>  >> These comments were written primarily for the benefit of the
> operational
>  >> area directors. Document editors and WG chairs should treat these
>  >> comments just like any other last call comments.
>  >> Hi Dan,
>  >>
>  >> thank you very much for your review. Please see my questions and
>  >> comments in-line.
>  >>
>  >> Best regards
>  >> Michael
>  >>>
>  >>>
>  >>> Summary: Ready with issues
>  >>>
>  >>> Document Ready, but Operational and Management considerations
>  >> missing.
>  >>>
>  >>> As the Abstract says:
>  >>>
>  >>> This document defines two additional policies for the Partial
>  >>> Reliability Extension of the Stream Control Transmission Protocol
>  >>> (PR-SCTP) allowing to limit the number of retransmissions or to
>  >>> prioritize user messages for more efficient send buffer usage.
>  >>> Although this document defines an extension of an existing
> protocol, there
>  >> are no explicit considerations about operations and management.
> The OPS
>  >> and Transport ADs should decide whether this is an issue to be
> addressed
>  >> before the document is approved.
>  >>>
>  >>> Specifically, following the checklists in RFC 5707, Appendix A:
>  >>>
>  >>> - Deployment is not discussed, although there is text that says
> that the
>  >> Limited Retransmissions Policy can be used with data channels in
> the
>  >> WebRTC protocol stack, and that the Priority Policy can be used in
> the IPFIX
>  >> protocol stack
>  >> The introduction says, that "The decision to abandon a user
> message is
>  >> sender side only". So for deploying the additional policies you
> need to
>  >> implement it at the sender side.
>  >
>  > This is not exactly what I meant by deployment. My understanding is
> that the policies defined in this document come to answer some
> specific needs of protocols like IPFIX and WebRTC. Am I correct? If I
> am, I would expect the policies to be deployed where these protocols
> run.
> 
> For IPFIX some of this is discussed in
>  https://tools.ietf.org/html/rfc7011#section-10.2 [1]
>  For RTCWeb is is discussed in
>  
> https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-12#section-6.1
> [2]
>  Please note that the policies defined here are of general use. So the
> description
>  how to use it will be in the documents describing the use cases.
>  >
>  >>> - Installation and initial setup is not discussed
>  >> We normally don't discuss the installation of the OS (assuming
> that the SCTP
>  >> stack is part of the kernel, which is the case for Linux, FreeBSD
> and Solaris) or
>  >> how to install applications (assuming that the transport stack is
> part of the
>  >> application, which is the case for browsers like Firefox, Chrome
> and Opera).
>  >
>  > Thank you for the clarification. Maybe it would help writing just
> this - the installation of the new capabilities will be part of OS
> upgrades.
>  ... if you use a stack provided by the kernel. If the stack is
> provided by
>  an application, you need to install the application.
>  So it comes down to: You need to install the software which contains
> the SCTP stack you are using.
>  For me, this is obvious. So I'm hesitating to add this. It would be a
> sentence which
>  you can copy to almost every SCTP (or TCP) specification.
> 
>> 
>  >>> - Migration Path does not seem to apply
>  >> Migrating from what? You can just use an implementation at the
> sender side
>  >> and you can operate with every receiver implemening RFC 3758.
>  >
>  > This is OK - that's what I had in mind when I said 'does not apply'
> - so no need to do anything.
>  >
>  >>> - There is information about RFC 3758 being mandatory to
> implement in
>  >> order to implement these extensions
>  >>> - The impact on the network operation is not discussed explicitly
>  >> In the security considerations section we say that the SCTP
> association using
>  >> this extension is not more aggressive than one not using the
> extension.
>  >
>  > OK.
>  >
>  >>> - There are no explicit suggestions about verifying correct
> operations,
>  >> although one can understand that the socket options described in
> sections
>  >> 4.3, 4.4, 4.5 are useful to determine stream specific status,
> association
>  >> specific status, and to get and set the PR-SCTP support
>  >> Are you suggesting to specify test cases? At least this is not
> common right
>  >> now in transport area although it would make sense in my
> opinion...
>  >
>  > OK
>  >
>  >>> - Interoperability does not seem to apply excepting the
> requirement to
>  >> implement RFC 3758
>  >> And that is all what is needed...
>  >
>  > OK
>  >
>  >>> - There is no information about faults or threshold conditions to
> be
>  >> reported
>  >> Not sure what you are expecting here.
>  >
>  > Nothing - this is a point in the 5707 list which does not seem to
> apply.
>  >
>  >>> - Configuration is not discussed, it may not apply, but it would
> be good
>  >> to state this
>  >> Well, configuration is described in detail in the socket API
> section. This is how
>  >> you configure the transport stack.
>  >
>  > OK
>  >
>  >>> - There are no manageability considerations of any kind
>  >> Isn't the socket API what you use to manage the transport stack?
> Or are you
>  >> referring to MIB stuff?
>  >
>  > Whatever is used by operators to perform and verify installation,
> check behavior, and troubleshoot problems.
> 
> Ahh, OK. I don't think an operator would use the socket API for that.
>  If you want to test you transport stack you need to have tests and a
> test tool
>  for running these tests. Up to now, the IETF (at least the transport
> area)
>  hasn't specified tests. Personally, I would really love to do it and
> think
>  that it is very important. But I think this is a decision not limited
> to this particular
>  document, but to (transport) protocols in general. So I leave it up
> to the ADs...
> 
> I'd say the question of test cases has been raised to the attention of
> TSVWG (cc on this thread), and I'd be happy to consider that if they
> think working on that would be a good plan, but I don't think this
> document needs to wait for them to figure that out.
> 
> I'm good with Michael submitting an update addressing the comments as
> discussed in this thread.
> 
> Thanks,
> 
> Spencer
> 
> 
> 
> Links:
> ------
> [1]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7011-23section-2D10.2&amp;d=AAMFaQ&amp;c=BFpWQw8bsuKpl1SgiZH64Q&amp;r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&amp;m=6cUQU7WzGxVzLIHAs0xxQPmF6uxX5BY1uBQciZGTCcc&amp;s=LqjSQkjNGebAvCFgTSNxXQ_e427vOGThVYUIAPMJDgw&amp;e=
> [2]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Drtcweb-2Ddata-2Dchannel-2D12-23section-2D6.1&amp;d=AAMFaQ&amp;c=BFpWQw8bsuKpl1SgiZH64Q&amp;r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&amp;m=6cUQU7WzGxVzLIHAs0xxQPmF6uxX5BY1uBQciZGTCcc&amp;s=nVL3E_6PggjIKyLIIspGt7ZzjVOoGU0fIot986j6yTs&amp;e=