Subject: Some thoughts about draft-saldana-tsvwg-tcmtf-02

From: "Jose Saldana" <[email-masked]>
Date: Mon, 2 Apr 2012 10:14:58 +0200

In this message I try to answer some of the questions that have been sent to
the list. I think the main questions are:

1) Does the draft intend to obsolete RFC4170?
2) The name of the draft
3) Agreement between the ends

Let's go with question 1)

Wes says:
>Hi Jose; by my understanding, your proposal is significantly different from
4170, and not just a set of changes to it, 
>so I don't think it would strictly be a "bis" document to 4170.
>This is just my opinion :)

James says:
>"bis" named documents are intended to replace existing RFC(s) (i.e., make
an existing RFC obsolete (if, and) when
> this new draft is published as an RFC. This -rfcXXXbis- designation is
intended to give context to what
>this new draft is about, but does not indicate any changes in
solution/direction/whatever this new draft is attempting to achieve.

>A good example from TSVWG is when the original SCTP base spec RFC
>(2960) was rewritten to update and correct any known errors (mistakes or
omissions) that draft was draft-*-tsvwg-
>2960bis-... when in WG draft form. This draft reached consensus within this
WG and the community to become RFC 
>4960, which is a proposed standard currently. 
>If, and when, SCTP needs to progress towards Internet Standard (IS) along
the standards track, it (likely) will start 
>with  a filename with "...-tsvwg-4960bis-..." in it.

>Does this make sense?

>If you follow that (and no one disagrees with it), do you believe your
draft qualifies as an intended rewrite of RFC
>4170? It is important what you as an author believes about this, as well as
what the WG believes about this. If 
>consensus is reached whether (or not) this draft should be considered a
rewrite of RFC 4170, the filename can 
>change then (usually at the direction of the WG chairs). The draft title
does not need to change, and in fact often
>does not.

My opinion:
The idea of the draft is to widen the scope of RFC4170 (TCRTP), which only
includes RTP traffic, and a single option for each layer
- RTP traffic
- ECRTP compression
- PPPMux multiplexing
- L2TPv3 tunneling

The new draft would include
- RTP, UDP and TCP traffic
- ECRTP, ROHC, IPHC, no compression
- PPPMux or other multiplexing options. In this layer I don't know if there
exists any other suitable multiplexing protocol
- L2TPv3 of GRE tunneling

So the draft includes all the options of RFC4170, as one of its possible
uses. Would it be necessary to obsolete RFC4170?

--------------------------

Question 2): The name of the draft

In my opinion, we can leave the name of the draft as it is now. The name is
not the most important thing.

-------------------------

Question 3) Signaling 

Wes says:
>I have a related question on the document.  Since it allows for multiple
options at each "layer" of the tunneling and 
>compression, how do you get agreement at each end about what it's okay to
use, and what actually is used?  Is it 
>just assumed to be a matter of management out of band?

My opinion:
The main idea is to do something similar to RFC4170. If you look at section
4 (http://tools.ietf.org/html/rfc4170#section-4), there is a "Example
implementation of TCRTP". the ways to deploy the PPP and L2TP negotiations
are suggested there: LCP negotiation, IPCP negotiation, tunnel
establishment, session establishment and tunnel tear down. The negotiations
are the ones described on each of the RFCs of the protocols corresponding of
each layer. The idea of the new draft could be similar.

So there are two options:
a) First, the ends would have to negotiate which protocols are they going to
use at each layer. And then, each of the protocols would have its own
negotiation. In this case, the new draft would have to consider a first
negotiation of each layer.

b) Other option is that in each scenario only one option is considered: if
the best option for my scenario is e.g. UDP-ROHC-PPPMux-GRE, then I will
always use it, and I do not need to negotiate anything. In this case, the
draft would not have to include a specific negotiation of the protocols to
use for each layer.

--------------------

I would appreciate if you could send me some feedback.

Best regards, and thank you for your questions,

Jose