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

[Spencer Dawkins at IETF <[e-mail]>]

>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
> For RTCWeb is is discussed in
> https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-12#section-6.1
> 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