Subject: [tram] Adoption of draft-reddy-tram-stun-path-data-01

From: Simon Perreault <[email-masked]>
Date: Fri, 27 Mar 2015 08:35:35 -0500

TRAMsters,

This is to confirm the adoption of draft-reddy-tram-stun-path-data-01 as
a working group draft. If anyone is opposed, now is a good time to
explain why.

Simon & Gonzalo

---

From: Justin Uberti <[email-masked]>
Date: Sat, 28 Mar 2015 17:51:39 -0700

I support the adoption of this draft.

On Fri, Mar 27, 2015 at 6:35 AM, Simon Perreault <[email-masked]>
wrote:

> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 30 Mar 2015 04:35:40 +0000

I support adoption of this draft.

Ram

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Mar 2015 14:55:47 -0500

> a working group draft. If anyone is opposed, now is a good time to

This looks fine in general, with one issue:

Issue:
ReTransCnt, ReqTransCnt and RespTransCnt are so similar that this is
very confusing.  When I finally parsed this, I realize that the server
isn't going to have three piece of information; it only needs to a)
echo the client's counter, and b) (if stateful) indicate how many
times it has responded over time.  As specified, I can't see any way
that having the number of received messages being different to the
number of responses is of any value.

Finally, I think that you should specify a more regular form for the
parameter.  One byte of Client Retransmission Counter, and one byte of
Server Retransmission Counter should be easy to understand.  Zero
being an indication that the sender didn't want to say for any reason,
as currently specified.

Nit:
   These metrics can then be used
   by the controlling agent to influence the ICE candidate pair
   priorities.
Changing priorities is not possible, changing what might be selected is.

---

From: Oleg Moskalenko <[email-masked]>
Date: Mon, 30 Mar 2015 23:55:22 -0700

I agree with Martin that the PATH-CHARACTERISTIC attribute is confusing:

1) In the request it has 4 bytes (1+3), in the response in has 8 bytes
(2+2+2+2) - that is bizarre. It would be a good style to keep the
attribute of the same size and structure, regardless of the attribute
placement.
2) The server is never doing any retransmissions for the responses;
all retransmissions in STUN are responsibility of the client. So, the
ReqTransCnt and RespTransCnt are always equal. The number of received
requests is always equal to the number of responses. So, why do we
need two separate fields for the same value ?
3) Why ReTransCnt in the request occupies 1 bytes, but in the response
the same value takes 2 bytes ? That is very strange.

I agree with the usefulness of the approach and I think that the draft
has to be adopted - but those things to be clarified before the
adoption.

Thanks
Oleg

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 31 Mar 2015 06:58:45 +0000

> From: tram [mailto:[email-masked]] On Behalf Of Martin Thomson
> Sent: Tuesday, March 31, 2015 1:26 AM
> To: Simon Perreault
> Cc: [email-masked]
> Subject: Re: [tram] Adoption of draft-reddy-tram-stun-path-data-01
> 
> > This is to confirm the adoption of draft-reddy-tram-stun-path-data-01
> > as a working group draft. If anyone is opposed, now is a good time to
> > explain why.
> 
> ReTransCnt, ReqTransCnt and RespTransCnt are so similar that this is very
> confusing.  When I finally parsed this, I realize that the server isn't going to
> have three piece of information; it only needs to a) echo the client's counter,
> and b) (if stateful) indicate how many times it has responded over time.  As
> specified, I can't see any way that having the number of received messages
> being different to the number of responses is of any value.

Agreed, ReqTransCnt can be removed.

> Server Retransmission Counter should be easy to understand.  

Yes, will update draft.

> Zero being an
> indication that the sender didn't want to say for any reason, as currently
> specified.
> 
> Nit:

Yup, will correct in the next version.

-Tiru

---

From: Simon Perreault <[email-masked]>
Date: Tue, 31 Mar 2015 08:24:59 -0400

> has to be adopted - but those things to be clarified before the

I don't see why these relatively minor things couldn't be worked on
after adoption.

Simon

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 31 Mar 2015 08:11:28 -0700

OK, I agree.

Oleg

Sent from my iPhone

> On Mar 31, 2015, at 5:24 AM, Simon Perreault <[email-masked]> wrote:
>