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

[[e-mail]]

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?

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