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

["Romascanu, Dan (Dan)" <[e-mail]>]

Ø  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?

Thanks for considering my comments.

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]<mailto:[e-mail]>> wrote:
On 10 Dec 2014, at 13:23, Romascanu, Dan (Dan) <[e-mail]<mailto:[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]<mailto:[e-mail]>]
>> Sent: Wednesday, December 10, 2014 1:02 AM
>> To: Romascanu, Dan (Dan)
>> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; draft-ietf-tsvwg-sctp-
>> [e-mail]<mailto:[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]<mailto:[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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7011-23section-2D10.2&d=AAMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=6cUQU7WzGxVzLIHAs0xxQPmF6uxX5BY1uBQciZGTCcc&s=LqjSQkjNGebAvCFgTSNxXQ_e427vOGThVYUIAPMJDgw&e=>
For RTCWeb is is discussed in
https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-12#section-6.1<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Drtcweb-2Ddata-2Dchannel-2D12-23section-2D6.1&d=AAMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=6cUQU7WzGxVzLIHAs0xxQPmF6uxX5BY1uBQciZGTCcc&s=nVL3E_6PggjIKyLIIspGt7ZzjVOoGU0fIot986j6yTs&e=>
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