Subject: [tram] SSODA in TURN-bis

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 8 Jan 2015 02:02:27 +0000

Hi all,

We are working on incorporating RFC6156 and SSODA into TURN-bis. During IETF-91 meeting there was discussion if the technique proposed in https://tools.ietf.org/html/draft-martinsen-tram-ssoda-01 would break existing TURN server implementations.  Pal had mentioned testing with four implementations and did not face any problem.

Please let us know if there are any concerns with the existing proposal of conveying two REQUESTED-ADDRESS-FAMILY attributes with different attribute values in Allocate request ?

Cheers,
-Tiru

---

From: Justin Uberti <[email-masked]>
Date: Wed, 7 Jan 2015 20:02:07 -0800

I promised I would write up a summary of the current mechanism, and what we
could do instead, so here goes:

The currently documented mechanism is to send two R-A-F attributes in the
request, and get back either a single address (from legacy servers), v4 +
v6 addresses (from new servers), a single address + a 0.0.0.0/:: (for new
servers that only support one address family), or an error-code (to
indicate complete failure).

At the time, there were 2 concerns listed, namely:
1) sending multiple R-A-Fs is undefined behavior; old (6156) servers may
fail the request completely, or do other weird things.
2) using 0.0.0.0/:: to indicate partial success is somewhat unclean;
specifically, detailed error information cannot be included.

I also thought of a 3rd problem:
3) an old(5766) server may fail the request completely, due to the fact
that R-A-F is comprehension-required. Thus an extra roundtrip may be needed
in this case, negating one of the benefits of SSODA.

I think the ideal solution to #1/#3 is to add a new OPTIONAL-ADDRESS-FAMILY
attribute, identical to R-A-F but comprehension-optional, where multiple
values are explicitly supported. Old servers can safely ignore this and
will return IPv4 (solving #3), while new servers can process this to return
multiple XOR-RELAYED-ADDRESSes in the response.
#2 is not a serious issue, but it could easily be solved by defining a new
ADDRESS-ERROR-CODE as follows:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Address Family                |  Rsvd  |Class|     Number    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Reason Phrase (variable)                                ..
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Then a server could return a normal IPv4 address, but a error code for
IPv6 with either 440 (unsupported address family) or 508 (insufficient
capacity) or some other TBD error.

I advocate we do the OPTIONAL-ADDRESS-FAMILY attribute as it is simple
and prevents potential interoperability problems with old servers. I
could go either way on ADDRESS-ERROR-CODE.

On Wed, Jan 7, 2015 at 6:02 PM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

>  Hi all,
>
>
>
> We are working on incorporating RFC6156 and SSODA into TURN-bis. During
> IETF-91 meeting there was discussion if the technique proposed in
> https://tools.ietf.org/html/draft-martinsen-tram-ssoda-01 would break
> existing TURN server implementations.  Pal had mentioned testing with four
> implementations and did not face any problem.
>
>
>
> Please let us know if there are any concerns with the existing proposal of
> conveying two REQUESTED-ADDRESS-FAMILY attributes with different attribute
> values in Allocate request ?
>
>
>
> Cheers,
>
> -Tiru
>
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>
>

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 7 Jan 2015 20:56:24 -0800

Hi Tiru

I can tell for sure that it will NOT break the rfc5766-turn-server.

And this is how SSODA is implemented in CoTURN server.

Thanks
Oleg

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 8 Jan 2015 15:14:19 +0800

Hi, Justin,

Is it more straightforward to define one new attribute that named “Additional-Address-Family ” instead of the R-A-F and  OPTIONAL-ADDRESS-FAMILY? The endpoint that does not include this attribute will be assigned the relay address that is the same type as seen from the source address of “Allocate Request” packet, not default in IPv4 relay address.

For reducing the port resource consumption on TURN server that described in https://tools.ietf.org/html/draft-martinsen-tram-ssoda-01, we have another proposal http://datatracker.ietf.org/doc/draft-wang-tram-turnlite/ that can mitigate the ip address/port allocation burden on TURN server------All endpoints that under one TURN server can use the same IPv4/IPv6 relay  address/port. 

Best Regards.

Aijun Wang.

From: tram [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: Thursday, January 08, 2015 12:02 PM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]
Subject: [SPAM] Re: [tram] SSODA in TURN-bis

I promised I would write up a summary of the current mechanism, and what we could do instead, so here goes:

The currently documented mechanism is to send two R-A-F attributes in the request, and get back either a single address (from legacy servers), v4 + v6 addresses (from new servers), a single address + a 0.0.0.0/:: (for new servers that only support one address family), or an error-code (to indicate complete failure).

1) sending multiple R-A-Fs is undefined behavior; old (6156) servers may fail the request completely, or do other weird things.

2) using 0.0.0.0/:: to indicate partial success is somewhat unclean; specifically, detailed error information cannot be included.

3) an old(5766) server may fail the request completely, due to the fact that R-A-F is comprehension-required. Thus an extra roundtrip may be needed in this case, negating one of the benefits of SSODA.

I think the ideal solution to #1/#3 is to add a new OPTIONAL-ADDRESS-FAMILY attribute, identical to R-A-F but comprehension-optional, where multiple values are explicitly supported. Old servers can safely ignore this and will return IPv4 (solving #3), while new servers can process this to return multiple XOR-RELAYED-ADDRESSes in the response.

#2 is not a serious issue, but it could easily be solved by defining a new ADDRESS-ERROR-CODE as follows:

Then a server could return a normal IPv4 address, but a error code for IPv6 with either 440 (unsupported address family) or 508 (insufficient capacity) or some other TBD error.
 
I advocate we do the OPTIONAL-ADDRESS-FAMILY attribute as it is simple and prevents potential interoperability problems with old servers. I could go either way on ADDRESS-ERROR-CODE.

On Wed, Jan 7, 2015 at 6:02 PM, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:

Hi all,

Cheers,

-Tiru

---

From: Justin Uberti <[email-masked]>
Date: Thu, 8 Jan 2015 12:23:17 -0800

On Wed, Jan 7, 2015 at 11:14 PM, Aijun Wang <[email-masked]>
wrote:

> Hi, Justin,
>
>
>
> Is it more straightforward to define one new attribute that named
> “Additional-Address-Family ” instead of the R-A-F and
> OPTIONAL-ADDRESS-FAMILY? The endpoint that does not include this attribute
> will be assigned the relay address that is the same type as seen from the
> source address of “Allocate Request” packet, not default in IPv4 relay
> address.
>

I suppose this could be a third option (c), in addition to (a) multiple
R-A-F and (b) multiple optional-a-f.  Here's how a/b/c look on the wire
when requesting v4+v6 simultaneously. If requesting v4 or v6 only for some
reason, a/b/c would all send a single RAF.

a: RAF (v4) + RAF (v6)
a1: server is 5766: error (RAF required-comprehension but unknown)
a2: server is 6156: v4 address, or error (undefined behavior)
a3: server is SSODA: v4 address + v6 address
b: OAF (v4) + OAF (v6)
b1: server is 5766/6156: v4 address (OAF ignored)
b2: server is SSODA: v4 address + v6 address
c: AAF (v6)
c1: server is 5766/6156: v4 address (AAF ignored)
c2: server is SSODA: v4 address + v6 address

Note that for c), one could send RAF(v4) + AAF(v6), but since that would
fail on a 5766 server, sending just AAF(v6) would be preferable.
Note that for b), if one sent OAF(v6) by itself for some reason, a 5766
server would return a v4 address, which is slightly inelegant.
For either b/c, we would need to say that including both RAF and OAF/AAF
for the same address family is prohibited.

b) is nice in that it avoids implicit behavior (i.e. that IPv4 is the
default AF), but feels a bit more complicated than c). I am supportive of
either b)/c), with maybe a slight preference for c).

>
> For reducing the port resource consumption on TURN server that described
> in https://tools.ietf.org/html/draft-martinsen-tram-ssoda-01, we have
> another proposal http://datatracker.ietf.org/doc/draft-wang-tram-turnlite/
> that can mitigate the ip address/port allocation burden on TURN
> server------All endpoints that under one TURN server can use the same
> IPv4/IPv6 relay  address/port.
>

The port consumption is a side benefit; the primary benefit of SSODA is the
reduction in the overall number of candidates.

>
>
> Best Regards.
>
> Aijun Wang.
>
>
>
> *From:* tram [mailto:[email-masked]] *On Behalf Of *Justin Uberti
> *Sent:* Thursday, January 08, 2015 12:02 PM
> *To:* Tirumaleswar Reddy (tireddy)
> *Cc:* [email-masked]
> *Subject:* [SPAM] Re: [tram] SSODA in TURN-bis
>
>
>
> I think the ideal solution to #1/#3 is to add a new
> OPTIONAL-ADDRESS-FAMILY attribute, identical to R-A-F but
> comprehension-optional, where multiple values are explicitly supported. Old
> servers can safely ignore this and will return IPv4 (solving #3), while new
> servers can process this to return multiple XOR-RELAYED-ADDRESSes in the
> response.
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 9 Jan 2015 02:34:32 +0000

Hi Justin,

option c) looks good, it was discussed in the WG sometime back that TURN-bis client MUST include R-A-F in the Allocate request.

-Tiru

From: Justin Uberti [mailto:[email-masked]]
Sent: Friday, January 09, 2015 1:53 AM
To: Aijun Wang
Cc: Tirumaleswar Reddy (tireddy); [email-masked]
Subject: Re: [tram] SSODA in TURN-bis

On Wed, Jan 7, 2015 at 11:14 PM, Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Justin,

I suppose this could be a third option (c), in addition to (a) multiple R-A-F and (b) multiple optional-a-f.  Here's how a/b/c look on the wire when requesting v4+v6 simultaneously. If requesting v4 or v6 only for some reason, a/b/c would all send a single RAF.

a: RAF (v4) + RAF (v6)

Note that for c), one could send RAF(v4) + AAF(v6), but since that would fail on a 5766 server, sending just AAF(v6) would be preferable.
Note that for b), if one sent OAF(v6) by itself for some reason, a 5766 server would return a v4 address, which is slightly inelegant.
For either b/c, we would need to say that including both RAF and OAF/AAF for the same address family is prohibited.

b) is nice in that it avoids implicit behavior (i.e. that IPv4 is the default AF), but feels a bit more complicated than c). I am supportive of either b)/c), with maybe a slight preference for c).

The port consumption is a side benefit; the primary benefit of SSODA is the reduction in the overall number of candidates.

Best Regards.
Aijun Wang.

From: tram [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Justin Uberti
Sent: Thursday, January 08, 2015 12:02 PM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]<mailto:[email-masked]>
Subject: [SPAM] Re: [tram] SSODA in TURN-bis

The currently documented mechanism is to send two R-A-F attributes in the request, and get back either a single address (from legacy servers), v4 + v6 addresses (from new servers), a single address + a 0.0.0.0/<http://0.0.0.0/>:: (for new servers that only support one address family), or an error-code (to indicate complete failure).

At the time, there were 2 concerns listed, namely:
1) sending multiple R-A-Fs is undefined behavior; old (6156) servers may fail the request completely, or do other weird things.
2) using 0.0.0.0/<http://0.0.0.0/>:: to indicate partial success is somewhat unclean; specifically, detailed error information cannot be included.

On Wed, Jan 7, 2015 at 6:02 PM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Cheers,
-Tiru

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

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 9 Jan 2015 11:11:29 +0800

Hi, Reddy and Justin:

Can we use only one attribute to accomplish the requirement of relay address that for additional address family? The TURN server can deduct the default relay address type by the XOR-MAP-Address that it seen from the  allocation request.  It can also satisfy the further situation such as only IPv6 TURN server deployed, but there is still the Dual stack ICE client exist.

Reuse or Redefine the RAF attribute then?

Best Regards.

From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]] 
Sent: Friday, January 09, 2015 10:35 AM
To: Justin Uberti; Aijun Wang
Cc: [email-masked]
Subject: RE: [tram] SSODA in TURN-bis

Hi Justin,

-Tiru

 

On Wed, Jan 7, 2015 at 11:14 PM, Aijun Wang <[email-masked]> wrote:

Hi, Justin,

a: RAF (v4) + RAF (v6)

b: OAF (v4) + OAF (v6)

c: AAF (v6)

 

Best Regards.

Aijun Wang.

 

 

Hi all,

Cheers,

-Tiru

---

From: Oleg Moskalenko <[email-masked]>
Date: Thu, 8 Jan 2015 19:33:24 -0800

That is my proposal, too.

The main objection is that some are saying that that will break the old servers. But nobody provided an example of an old server that would be broken. That possibility is remote; I believe that making a "symmetric" clean protocol with RAF for both ipv4 and ipv6 is more important.

Thanks
Oleg

Sent from my iPhone

> On Jan 8, 2015, at 7:11 PM, "Aijun Wang" <[email-masked]> wrote:
> 
> Hi, Reddy and Justin:
>

---

From: Justin Uberti <[email-masked]>
Date: Thu, 8 Jan 2015 22:25:39 -0800

On Thu, Jan 8, 2015 at 6:34 PM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

>  Hi Justin,
>
>
>
> option c) looks good, it was discussed in the WG sometime back that
> TURN-bis client MUST include R-A-F in the Allocate request.
>

I'm not sure this is a good idea since 5766 servers will choke on this.

>
>
> -Tiru
>
>
>
> *From:* Justin Uberti [mailto:[email-masked]]
> *Sent:* Friday, January 09, 2015 1:53 AM
> *To:* Aijun Wang
> *Cc:* Tirumaleswar Reddy (tireddy); [email-masked]
> *Subject:* Re: [tram] SSODA in TURN-bis
>
>
>
>
>
>
>
> The port consumption is a side benefit; the primary benefit of SSODA is
> the reduction in the overall number of candidates.
>
>
>
> Best Regards.
>
> Aijun Wang.
>
>
>

---

From: Justin Uberti <[email-masked]>
Date: Thu, 8 Jan 2015 22:26:51 -0800

On Thu, Jan 8, 2015 at 7:11 PM, Aijun Wang <[email-masked]>
wrote:

> Hi, Reddy and Justin:
>
>
>
> Can we use only one attribute to accomplish the requirement of relay
> address that for additional address family? The TURN server can deduct the
> default relay address type by the XOR-MAP-Address that it seen from the
>  allocation request.  It can also satisfy the further situation such as
> only IPv6 TURN server deployed, but there is still the Dual stack ICE
> client exist.
>
>
>
I am not sure what you are proposing; I thought c) reflected your earlier
suggestion.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 8 Jan 2015 22:30:59 -0800

On Thu, Jan 8, 2015 at 7:33 PM, Oleg Moskalenko <[email-masked]> wrote:

> The main objection is that some are saying that that will break the old
> servers. But nobody provided an example of an old server that would be
> broken. That possibility is remote; I believe that making a "symmetric"
> clean protocol with RAF for both ipv4 and ipv6 is more important.
>

I disagree. If there are even a few servers out there that fail, Chrome
will have to not use SSODA or have some complicated fallback heuristic.

The IETF has had a long tradition of making protocols that are backwards
compatible, sometimes at the cost of elegance. Well, except for IPv6.

---

From: Oleg Moskalenko <[email-masked]>
Date: Thu, 8 Jan 2015 22:44:08 -0800

> compatible, sometimes at the cost of elegance. Well, except for IPv6.

Well, we are talking exactly about IPv6 here, so...

Let's find a single server that will be broken. Then I may agree.

Can anybody provide an example ? There are just a few server
implementations out there, I believe.

If we choose an ugly option, then we will have to deal with the problems
for many years.

My opinion is that IPv6 and IPv4 are designed as 'equal' network protocols,
by their nature. So the right solution must not assume that one protocol is
the first-class protocol, and the other one is a 'special case'.

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 9 Jan 2015 17:17:00 +0800

After your detail analysis and the sentence “For either b/c, we would need to say that including both RAF and OAF/AAF for the same address family is prohibited.”, I think it may be better to keep only one attribute to fulfill the SSODA requirement?  

From: Justin Uberti [mailto:[email-masked]] 
Sent: Friday, January 09, 2015 2:27 PM
To: Aijun Wang
Cc: Tirumaleswar Reddy (tireddy); [email-masked]
Subject: Re: [tram] SSODA in TURN-bis

On Thu, Jan 8, 2015 at 7:11 PM, Aijun Wang <[email-masked]> wrote:

Hi, Reddy and Justin:

I am not sure what you are proposing; I thought c) reflected your earlier suggestion.

---

From: Simon Perreault <[email-masked]>
Date: Fri, 9 Jan 2015 09:11:30 -0500

On Fri, Jan 9, 2015 at 4:17 AM, Aijun Wang <[email-masked]>
wrote:

> After your detail analysis and the sentence “For either b/c, we would need
> to say that including both RAF and OAF/AAF for the same address family is
> prohibited.”, I think it may be better to keep only one attribute to
> fulfill the SSODA requirement?

There is no requirement that SSODA functionality be realized with only one
attribute, nor that the protocol be elegant, nor that it exhibits symmetry
that is pleasing to the eye.

There *is* a requirement that it be backwards-compatible though. Whether
that means compatible with the spec or compatible with actual
implementations is a matter of debate.

Justin, if we can't find a single implementation that would barf, why would
Chrome have to implement a complex fallback mechanism?

Simon

---

From: Justin Uberti <[email-masked]>
Date: Fri, 9 Jan 2015 09:34:14 -0800

I reviewed the code for restund, reTurn, and rfc5766-turn-server and they
all appear to handle RAF (and multiple RAF) OK.

The problem, as I see it, is that there may be other TURN servers, perhaps
non-open-source ones, that work fine today with Chrome, but will start
returning errors when we include RAF or multiple RAF, and so making this
change may break some small number of apps (who will then blame Chrome). We
just don't know what is out there.

On Fri, Jan 9, 2015 at 6:11 AM, Simon Perreault <[email-masked]> wrote:

>> After your detail analysis and the sentence “For either b/c, we would
>> need to say that including both RAF and OAF/AAF for the same address family
>> is prohibited.”, I think it may be better to keep only one attribute to
> Justin, if we can't find a single implementation that would barf, why
> would Chrome have to implement a complex fallback mechanism?
>
> Simon
>

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 9 Jan 2015 10:01:08 -0800

I checked the code of rfc5766-turn-server again, and I found that it will
NOT handle the multiple-RAF case. It will return 400 error with the message
"Only one address family attribute can be used in a request". At least,
it's been that way in the 2014 releases. I did not check the older releases.

Sorry that I provided a wrong information about the implementation, before.

I can fix that code but still there are people out there who will be using
the "wrong" versions.

So, if we do have to be absolutely backward compatible then we have to use
a different option...

Oleg

On Fri, Jan 9, 2015 at 9:34 AM, Justin Uberti <[email-masked]> wrote:

>> There is no requirement that SSODA functionality be realized with only
>> one attribute, nor that the protocol be elegant, nor that it exhibits
>> symmetry that is pleasing to the eye.
>>

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 9 Jan 2015 10:53:42 -0800

I double-checked that with a real test. I ran the coTurn test client (that
implements experimental SSODA draft with two RAF attributes) against
rfc5766-turn-server and the server yielded error 400 with the message "Only
one address family attribute can be used in a request"

:(

As I said, I can eliminate that problem in the subsequent
rfc5766-turn-server maintenance releases, but still...

I am sorry that I did not discover that previously and that I advocated an
incompatible implementation option.

So, if the WG insists on a backward-compatible protocol in all senses, then
we have to choose another option.

Thanks
Oleg

On Fri, Jan 9, 2015 at 10:01 AM, Oleg Moskalenko <[email-masked]>
wrote:

>> The problem, as I see it, is that there may be other TURN servers,
>> perhaps non-open-source ones, that work fine today with Chrome, but will
>> start returning errors when we include RAF or multiple RAF, and so making
>> this change may break some small number of apps (who will then blame
>> Chrome). We just don't know what is out there.
>>
>>
>>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 9 Jan 2015 12:48:31 -0800

OK, so we have clear evidence that some deployed servers will fail
(deterministically, fortunately) on the current SSODA proposal.

So we're back to which backwards-compatible option we want to pursue. I
suggest c), which is the optional-comprehension ADDITIONAL-ADDRESS-FAMILY.

Separately, we need to decide whether we want to pursue issue #2 that I
identified previously, i.e., allowing specific error codes to be returned
for each address family.

On Fri, Jan 9, 2015 at 10:53 AM, Oleg Moskalenko <[email-masked]>
wrote:

> So, if the WG insists on a backward-compatible protocol in all senses,
> then we have to choose another option.
>
> Thanks
> Oleg
>
>
>
>> I can fix that code but still there are people out there who will be
>> using the "wrong" versions.
>>
>> So, if we do have to be absolutely backward compatible then we have to
>> use a different option...
>>
>> Oleg
>>
>>
>>> I reviewed the code for restund, reTurn, and rfc5766-turn-server and
>>> they all appear to handle RAF (and multiple RAF) OK.
>>>
>>>> There *is* a requirement that it be backwards-compatible though.
>>>> Whether that means compatible with the spec or compatible with actual

---

From: Ca By <[email-masked]>
Date: Fri, 9 Jan 2015 17:00:00 -0800

> suggest c), which is the optional-comprehension ADDITIONAL-ADDRESS-FAMILY.
It was not clear to me earlier in the thread

Does option c allow for ipv6-only operation ?

CB

> On Fri, Jan 9, 2015 at 10:53 AM, Oleg Moskalenko <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>> I double-checked that with a real test. I ran the coTurn test client
>> (that implements experimental SSODA draft with two RAF attributes) against
>> I am sorry that I did not discover that previously and that I advocated
>> an incompatible implementation option.
>>
>> On Fri, Jan 9, 2015 at 10:01 AM, Oleg Moskalenko <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>>
>>> I checked the code of rfc5766-turn-server again, and I found that it
>>> will NOT handle the multiple-RAF case. It will return 400 error with the
>>> message "Only one address family attribute can be used in a request". At
>>> least, it's been that way in the 2014 releases. I did not check the older
>>> releases.
>>>
>>> On Fri, Jan 9, 2015 at 9:34 AM, Justin Uberti <[email-masked]
>>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>>>
>>>> On Fri, Jan 9, 2015 at 6:11 AM, Simon Perreault <[email-masked]
>>>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>>>>
>>>>>
>>>>> On Fri, Jan 9, 2015 at 4:17 AM, Aijun Wang <[email-masked]
>>>>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>>>>>
>>>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 9 Jan 2015 17:14:59 -0800

Yes. You just send RAF(v6) by itself, as before.
(Same goes for v4-only, or you could omit the attribute entirely.)

On Fri, Jan 9, 2015 at 5:00 PM, Ca By <[email-masked]> wrote:

>>>>>>> After your detail analysis and the sentence “For either b/c, we
>>>>>>> would need to say that including both RAF and OAF/AAF for the same address
>>>>>>> family is prohibited.”, I think it may be better to keep only one attribute
>>>>>>> to fulfill the SSODA requirement?
>>>>>>
>>>>>>
>>>>>> There is no requirement that SSODA functionality be realized with
>>>>>> only one attribute, nor that the protocol be elegant, nor that it exhibits