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

[Michael Tuexen <[e-mail]>]

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...
> 
>>> 
>>> One terminology issue is worth being considered: The document speaks
>> about two additional policies for PR-SCTP. However, the RFC defining PR-
>> SCTP (RFC 3758) does not use the term policy at all. Timed Reliability which in
>> this document is called a 'policy' is described in RFC 3758 as a 'service to
>> upper layer'. It would be good to either align terminology, or to explain that
>> the term policy used here corresponds to the 'service' described in RFC 3758.
>> That is a good catch. Terminology has evolved over time.
>> 
>> I changed in the introduction
>> 
>> The decision to abandon a user message
>> is sender side only and the exact condition is called a PR-SCTP policy.
>> 
>> to
>> 
>> The decision to abandon a user message
>> is sender side only and the exact condition is called a PR-SCTP policy (<xref
>> target='RFC3758'/> refers to them as 'PR-SCTP Services').
> 
> OK 
> 
>>> 
>>> Regards,
>>> 
>>> Dan
> 
>