Subject: Re: [tsvwg] AD Evaluation of draft-ietf-tsvwg-sctp-dtls-encaps

From: Michael Tuexen <[email-masked]>
Date: Tue, 9 Dec 2014 17:48:02 +0100

On 08 Dec 2014, at 22:44, Spencer Dawkins <[email-masked]> wrote:

> Dear Authors,
> 
> I had a small number of comments, mostly but not entirely at nit level, on this draft. I suspect that you would see them again from other ADs and from review teams. 
Hi Spencer,

thanks for the comments. See my replies inline.
> 
> Would you like to respin before Last Call?
Sure. This makes things simple, I think and will make Gorry happy, who suggested already
a text change...

Best regards
Michael
> 
> Spencer
> 
> -- my notes
> 
> In this text:
> 
> 3.  Encapsulation and Decapsulation Procedure
> 
>    When an SCTP packet is provided to the DTLS layer, the complete SCTP
>    packet, consisting of the SCTP common header and a number of SCTP
>    chunks, MUST be handled as the payload of the application layer
>    protocol of DTLS.  When the DTLS layer has processed a DTLS record
>    containing a message of the application layer protocol, the payload
>    MUST be given up to the SCTP layer.  The SCTP layer expects an SCTP
>    common header followed by a number of SCTP chunks.
>    
> I don't read the MUSTs as 2119 MUSTs. You're just describing functionality. "is handled" and "is given up to" (which I might suggest saying as "is passed to") are probably more appropriate.
OK, changed. I think there was a comment requesting some normative language in the part
of the document describing the actual encap/decaps, that is why the MUST went in. But
if you think this is not necessary, I take them out.
>    
>    In this text:
> 
> 5.  DTLS Considerations
> 
>    If path MTU discovery is performed by the SCTP layer and IPv4 is used
>    as the network layer protocol, the DTLS implementation SHOULD allow
>    the DTLS user to enforce that the corresponding IPv4 packet is sent
>    with the Don't Fragment (DF) bit set.  If controlling the DF bit is
>    not possible, for example due to implementation restrictions, a safe
>    value for the path MTU has to be used by the SCTP stack.  It is
>    RECOMMENDED that the save value does not exceed 1200 bytes.  Please
>                         ^^^^ is this "safe"?
This is what the WG thinks is save. We discussed this also with members
of the RTCWeb WG. Do you think that we should use a different value? If yes,
which one? The motivation was based on the value for IPv6, and then taking
into account some more bytes for headers... and we ended up with 1200.
>    
>    note that [RFC1122] only requires end hosts to be able to reassemble
>    fragmented IP packets of reassembled size of 576 bytes.
>    
> In this text:
> 
> 5.  DTLS Considerations
> 
>    If path MTU discovery is performed by the SCTP layer and IPv4 is used
>    as the network layer protocol, the DTLS implementation SHOULD allow
>    the DTLS user to enforce that the corresponding IPv4 packet is sent
>    with the Don't Fragment (DF) bit set.  If controlling the DF bit is
>    not possible, for example due to implementation restrictions, a safe
>    value for the path MTU has to be used by the SCTP stack.  It is
>    RECOMMENDED that the save value does not exceed 1200 bytes.  Please
>    note that [RFC1122] only requires end hosts to be able to reassemble
>    fragmented IP packets of reassembled size of 576 bytes.
>                             ^^^^^^^^^^^^^^^^^^^
> I'm not sure you need to say "reassembled size of", but if you don't just delete this text, I'd suggest "able to reassemble fragmented IP packets up to 576 bytes in length".
Taken.
> 
> In this text:
> 
> 6.5.  Partial Reliability Extension
> 
>    Partial reliability as defined in [RFC3758] can be used in
>    combination with DTLS encapsulation.  It is also possible to use
>                                             ^^^^^^^^^^^^^^^^
>    additional PR-SCTP policies.
>    
> Is there a reference you could provide for implementers? Perhaps to draft-ietf-tsvwg-sctp-prpolicies, also submitted for publication, but please note my use of future tense in 6.7 comment ...
Changed to
It is also possible to use
additional PR-SCTP policies, for example the ones defined in
<xref target='I-D.ietf-tsvwg-sctp-prpolicies'/>.</t>
>    
> In this text:
> 
> 6.7.  Interleaving of Large User Messages
> 
>    SCTP as defined in [RFC4960] does not support the interleaving of
>    large user messages that need to be fragmented and reassembled by the
>    SCTP layer.  The protocol extension defined in
>    [I-D.ietf-tsvwg-sctp-ndata] overcomes this limitation and can be used
>    with DTLS encapsulation.
>    
> I think I understand why you have https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ listed as Informational, but it feels like it's on the edge of being Normative, or at least implementers are encouraged to support this extension now. Is this important enough to need to be said in this specification? If so, would it be correct to say this?
> 
>    The protocol extension being defined in
>    [I-D.ietf-tsvwg-sctp-ndata] would overcome this limitation and could be used
>    with DTLS encapsulation.
I just want to say that the extension defined in I-D.ietf-tsvwg-sctp-ndata (whatever RFC it will be)
can be used with DTLS encaps. For RTCWeb it will be used (it is mandatory to implement), but there
might be other use cases where this extension is not necessary.
Since I'm not sure I got the point you want to make, please let me know if my intention is now
clearer and which text you prefer to express this.

Best regards
Michael

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 9 Dec 2014 11:02:33 -0600

I'm on a telechat now, but on one point - I'm not asking about 1200, I'm
asking whether the word "save" is supposed to be "safe"!

Spencer

On Tue, Dec 9, 2014 at 10:48 AM, Michael Tuexen <[email-masked]>
wrote:

> > I had a small number of comments, mostly but not entirely at nit level,
> on this draft. I suspect that you would see them again from other ADs and
> from review teams.
> Hi Spencer,
>
> > I don't read the MUSTs as 2119 MUSTs. You're just describing
> functionality. "is handled" and "is given up to" (which I might suggest
> saying as "is passed to") are probably more appropriate.
> > I'm not sure you need to say "reassembled size of", but if you don't
> just delete this text, I'd suggest "able to reassemble fragmented IP
> packets up to 576 bytes in length".
> Taken.
> >
> > In this text:
> >
> > Is there a reference you could provide for implementers? Perhaps to
> draft-ietf-tsvwg-sctp-prpolicies, also submitted for publication, but
> please note my use of future tense in 6.7 comment ...
> Changed to
> > I think I understand why you have
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ listed as
> Informational, but it feels like it's on the edge of being Normative, or at
> least implementers are encouraged to support this extension now. Is this
> important enough to need to be said in this specification? If so, would it
> be correct to say this?
> >

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 9 Dec 2014 19:17:10 +0100

On 09 Dec 2014, at 18:02, Spencer Dawkins at IETF <[email-masked]> wrote:

> I'm on a telechat now, but on one point - I'm not asking about 1200, I'm asking whether the word "save" is supposed to be "safe"!
Got it. It is "safe". My typo.

Best regards
Michael
> 
> Spencer
> 
> On Tue, Dec 9, 2014 at 10:48 AM, Michael Tuexen <[email-masked]> wrote:

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 9 Dec 2014 21:51:31 -0600

Now that the telechat is settling down ...

> if you think this is not necessary, I take them out.

I think they are probably attractive nuisances that would get at least
Comments if not Discusses from a couple of other ADs (names on request).

> >    RECOMMENDED that the save value does not exceed 1200 bytes.  Please

We talked about this one :-)

> <xref target='I-D.ietf-tsvwg-sctp-prpolicies'/>.</t>

Sounds perfect. And that pushes me to get the write-up done for that draft
:-)

> clearer and which text you prefer to express this.

I'm mostly wondering if other ADs will think this reference is normative -
if it is, you'd be REF-HOLD on a draft that's still "draft exists".

If saying that is important enough to hold this draft, please do the right
thing.

I was attempting to provide text that didn't tie as closely to this
specific draft.

There's at least a 70-percent chance that no one will push on this - as I
said, if it's normative, it's barely normative. You can leave it this way,
just be thinking about what your response will be if someone asks.

But please, do the right thing ;-)

> Michael

Thanks for your quick responses on this. It's always a pleasure to work on
stuff that's still in short-term memory ...

Spencer

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 10 Dec 2014 10:32:52 +0100

On 10 Dec 2014, at 04:51, Spencer Dawkins at IETF <[email-masked]> wrote:

> I think they are probably attractive nuisances that would get at least Comments if not Discusses from a couple of other ADs (names on request). 
OK. Text changed as suggested.
> Sounds perfect. And that pushes me to get the write-up done for that draft :-)
>  
> >
> > In this text:
> >
> I'm mostly wondering if other ADs will think this reference is normative - if it is, you'd be REF-HOLD on a draft that's still "draft exists". 
It is OK for me to be REF-HOLD on that ID. The same applies to the other documents in the reference
section.
> 
> If saying that is important enough to hold this draft, please do the right thing.
OK. Let me try.
If we are ref-hold on I-D.ietf-tsvwg-sctp-ndata, everything will be fine after that ID turns into an RFC.
If we are not ref-hold on I-D.ietf-tsvwg-sctp-ndata, the reference will be to an particular version
of the ID, which is not what is intended. It is intended to refer to the corresponding RFC eventually.

This mean:
We either
use your language and are not REF-HOLD on I-D.ietf-tsvwg-sctp-ndata
or
keep the current wording but make sure that we are REF-HOLD on I-D.ietf-tsvwg-sctp-ndata.

I don't know how I can make sure that the document is REF-HOLD on I-D.ietf-tsvwg-sctp-ndata. I can live
with both options. Which one do you suggest?
> 
> I was attempting to provide text that didn't tie as closely to this specific draft.
I think we need to be consistent. All extensions discussed in section 6.1 to 6.7 are
referenced using non normative references. They should all handled the same way. So if
you want to make one normative, please do so for the others. However, based on the discussion
on the WG it was decided that using non-normative references is the best way.
> 
> There's at least a 70-percent chance that no one will push on this - as I said, if it's normative, it's barely normative. You can leave it this way, just be thinking about what your response will be if someone asks.
> 
> Thanks for your quick responses on this. It's always a pleasure to work on stuff that's still in short-term memory ...
> 
> Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 10 Dec 2014 06:43:55 -0600

Hi, Michael,

On Wed, Dec 10, 2014 at 3:32 AM, Michael Tuexen <[email-masked]>
wrote:

> > > I had a small number of comments, mostly but not entirely at nit
> level, on this draft. I suspect that you would see them again from other
> ADs and from review teams.
> > Hi Spencer,
> >
> > I just want to say that the extension defined in
> I-D.ietf-tsvwg-sctp-ndata (whatever RFC it will be)
> > I'm mostly wondering if other ADs will think this reference is normative
> - if it is, you'd be REF-HOLD on a draft that's still "draft exists".

If you are fine with REF-HOLD, there's no change required. My suggestion
would be to put in a section that's a Note to the RFC Editor, saying that
although the reference is Informative, the document should be held until
I-D.ietf-tsvwg-sctp-ndata has been approved.

I COULD include that as an RFC Editor Note in the datatracker, but putting
it in the document will make it harder to miss during approval and
publication.

I think that's all the questions we had for each other. When you submit the
next revision, I'll request Last Call for it.

And thanks for your continued good work on SCTP!

Spencer

> > There's at least a 70-percent chance that no one will push on this - as
> I said, if it's normative, it's barely normative. You can leave it this
> way, just be thinking about what your response will be if someone asks.
> >
> > Thanks for your quick responses on this. It's always a pleasure to work
> on stuff that's still in short-term memory ...
> >
> > Spencer
>
>

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 10 Dec 2014 17:24:39 +0100

On 10 Dec 2014, at 13:43, Spencer Dawkins at IETF <[email-masked]> wrote:

> Hi, Michael,
> 
> On Wed, Dec 10, 2014 at 3:32 AM, Michael Tuexen <[email-masked]> wrote:
> If you are fine with REF-HOLD, there's no change required. My suggestion would be to put in a section that's a Note to the RFC Editor, saying that although the reference is Informative, the document should be held until I-D.ietf-tsvwg-sctp-ndata has been approved.
OK. I added text for that.
> 
> I COULD include that as an RFC Editor Note in the datatracker, but putting it in the document will make it harder to miss during approval and publication.
> 
> I think that's all the questions we had for each other. When you submit the next revision, I'll request Last Call for it.
Done.
> And thanks for your continued good work on SCTP!
Thanks to you for your fast and constructive way of cooperation!

Best regards
Michael