Subject: [dtn-interest] Review for TCP CL

From: "Scott, Keith L." <[email-masked]>
Date: Tue, 28 Aug 2012 14:35:36 +0000

Looks good.  A few quick comments:

Section 1

Second Paragraph

"...(CLA) to send and receive bundles using an underlying internet protocol." -- This isn't quite true; the CLA can in fact use an underlying link (or even, I suppose, raw physical) service.  This IS brought out better in section 2.1 where the CLA '...sends and receives bundles utilizing the service of some 'native' link, network, or internet protocol.' Maybe Section1 paragraph2 could pretty much reflect this:

"...(CLA) to send and receive bundles using the service of some 'native' link, network, or internet protocol."

Third Paragraph

"...the TCPCL reside above the transport layer, i.e., at the application layer."

            Would you consider:

"...the TCPCL reside above the transport layer of the Internet model, i.e., at the application layer."

I think the figure does a good job of showing the relationship; but assigning BP to a 'layer' in the Internet model is always tricky and a little extra verbosity might help.

Section 4.2

"...the magic string is to provide a some protection..." -- '...a some...' needs fixing.

The 'should' in 'This negotiation should proceed in the following manner:' should be SHOULD?

"Bundle refusal to interrupt transmission of a bundle may only be used iff both peers indicate support for it in their contact header."

            Maybe reword as:

"The bundle refusal capability may only be used iff both peers..."

            Or

"The capability that allows a receiver to refuse reception of a bundle may only be used iff both peers..."

Authors' Addresses:

Does somebody have a more recent address for Mike Demmer?

                        --keith

-----Original Message-----

From: Joerg Ott [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>

Sent: Friday, August 24, 2012 2:23 PM

To: Vint Cerf; Scott, Keith L.

Cc: Fall, Kevin; Stephen Farrell; Simon Perreault

Subject: Review for TCP CL

Hi Vint and Keith,

during our interim meeting, I earned the responsibility of

pursuing people for our WG-style operation subgroup to get

documents out.

This is a friendly reminder that the two of you committed

to reviewing the TCP convergence layer.  A new draft was

posted recently.  See the link below for your convenience.

https://datatracker.ietf.org/doc/draft-irtf-dtnrg-tcp-clayer/

We did not set a specific deadline for the review, but

getting feedback in a couple of weeks (<= 4) would be good.

Cheers,

Jörg

---

From: Simon Perreault <[email-masked]>
Date: Tue, 28 Aug 2012 13:25:13 -0400

Le 2012-08-28 10:35, Scott, Keith L. a écrit :
> "...(CLA) to send and receive bundles using an underlying internet
> protocol." -- This isn't quite true; the CLA can in fact use an
> underlying link (or even, I suppose, raw physical) service.  This IS
> brought out better in section 2.1 where the CLA '...sends and receives
> bundles utilizing the service of some 'native' link, network, or
> internet protocol.' Maybe Section1 paragraph2 could pretty much reflect
> this:
>

ok, fixed.

> I think the figure does a good job of showing the relationship; but
> assigning BP to a 'layer' in the Internet model is always tricky and a
> little extra verbosity might help.

Per Vin't follow-up comment, I fixed that with: "In particular, when BP 
is using TCP as its bearer with TCPCL as its convergence layer, both BP 
and TCPCL reside at the application layer of the Internet model."

> "...the magic string is to provide a some protection..." -- '...a

ok, fixed.

> manner:' should be SHOULD?

Actually it should be MUST because things will completely break if you 
don't follow this. I can't think of any exception case.

> "Bundle refusal to interrupt transmission of a bundle may only be used
> iff both peers indicate support for it in their contact header."
>
>              Maybe reword as:
>

ok, fixed using your first suggestion.

> Does somebody have a more recent address for Mike Demmer?

I don't...

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca