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

[Michael Tuexen <[e-mail]>]

On 2014-12-11 12:10, [e-mail] wrote:
> So, it seems most of this is covered by clear statements that describe
> this as a sender-side only change to the transport protocol of the
> endpoint stack. ... and description and references to examples where
> deployment is expected, etc - I suggest to expand the introduction?
> 
> Michael can you run the changes by me as the document shepherd, so I 
> can
> check that I see the logic and it doesn't potentially  create new 
> issues?
Hi Gorry,

I'm sorry, I already submitted the version. Please have a look at
https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-prpolicies-06
and let me know if they changes are OK for you. If not I can
incorporate your suggested changes.

Best regards
Michael
> 
> Gorry
> 
>> Ø  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
>> 
>>