Subject: [P2PSIP] UNSAF considerations and draft-ietf-p2psip-drr

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 17 Jun 2013 15:02:12 +0300

Folks,

Appendix A of the following draft describes how a node can obtain IP
addresses on which it may be reached:

http://tools.ietf.org/html/draft-ietf-p2psip-drr-07#appendix-A

Have you taken into account the UNSAF considerations?

http://tools.ietf.org/html/rfc3424

Cheers,

Gonzalo

---

From: "Roni Even" <[email-masked]>
Date: Sun, 23 Jun 2013 18:28:35 +0300

Hi Gonzalo,
Thanks for point out to RFC3424.
How about adding to the following sentence an informative reference to
RFC3424. Note that appendix A is not creating an UNSAF proposal but just
mentions some methods for informational purpose.

Suggest adding to "Note that there is no foolproof way to determine if a
peer is publically reachable, other than via out-of-band  mechanisms."  to

"Note that there is no foolproof way to determine if a peer is publically
reachable, other than via out-of-band mechanisms. For discussion about
issues with address evaluation also see UNSAF [RFC3424]"

I am not sure if it adds much information but it may be good to have this
reference

Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Gonzalo Camarillo
> Sent: 17 June, 2013 3:02 PM
> To: P2PSIP Mailing List
> Subject: [P2PSIP] UNSAF considerations and draft-ietf-p2psip-drr
> 
> Folks,
> 
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 24 Jun 2013 11:11:21 +0300

Hi Roni,

I think the draft should discuss in more detail how a node makes the
decision of attempting to use DRR and what are the trade-offs. The case
of closed or managed networks is clear. The draft can mention that an
administrator simply configures nodes to use DRR because the
administrator knows, somehow, that it will work fine.

In open networks, the draft should discuss the trial and error system
being proposed. For example, a node without a public IP address may be
able to communicate directly with a node in the same non-public address
space. That case is not covered by the discussions about UNSAF
mechanisms. The whole point about developing ICE was that UNSAF
mechanisms do not work in many situations.

In short, this is an important interoperability issue because it relates
to when a node should use one mechanism or another. Therefore, the draft
should discuss all the implications of the proposed mechanism carefully.

Thanks,

Gonzalo

---

From: "Roni Even" <[email-masked]>
Date: Mon, 24 Jun 2013 11:58:23 +0300

Hi Gonzalo,
During the WG discussion we were asked to have in the main body just the
case of manage networks and leave in the informational appendix A some
informational text about finding routable addresses since it was clear that
there is no guarantee that it will work. I do not think that it is the
purpose of this document to discuss the whole topic of finding routable
addresses, we are just pointing at available options. The idea is that there
is always a fall back to SRR
Roni

> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: 24 June, 2013 11:11 AM
> To: Roni Even
> Cc: 'P2PSIP Mailing List'
> Subject: Re: [P2PSIP] UNSAF considerations and draft-ietf-p2psip-drr
> 
> Hi Roni,
> 
decision
> of attempting to use DRR and what are the trade-offs. The case of closed
or
> managed networks is clear. The draft can mention that an administrator
> simply configures nodes to use DRR because the administrator knows,
> somehow, that it will work fine.
> 
being
> proposed. For example, a node without a public IP address may be able to
> communicate directly with a node in the same non-public address space.
> That case is not covered by the discussions about UNSAF mechanisms. The
> whole point about developing ICE was that UNSAF mechanisms do not work
> in many situations.
> 
to when
> a node should use one mechanism or another. Therefore, the draft should
> discuss all the implications of the proposed mechanism carefully.
> 
> Thanks,
> 
> Gonzalo
> 
> 
> 
> > RFC3424. Note that appendix A is not creating an UNSAF proposal but
> > just mentions some methods for informational purpose.
> >
> > Suggest adding to "Note that there is no foolproof way to determine if
> > a peer is publically reachable, other than via out-of-band
> > mechanisms."  to
> >
> > "Note that there is no foolproof way to determine if a peer is
> > publically reachable, other than via out-of-band mechanisms. For
> > discussion about issues with address evaluation also see UNSAF
[RFC3424]"
> >
> > I am not sure if it adds much information but it may be good to have
> > this reference
> >
> > Roni Even
> >
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Gonzalo Camarillo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 24 Jun 2013 13:07:56 +0300

Hi Roni,

sure, the purpose of this document is not to create a new ICE type of
mechanism, I agree. Nevertheless, the document needs to be clear about
the options implementers and administrators have. That is, what is
likely to work, what is not likely to work, special cases (e.g., when
two nodes are in the same private address space), etc. That is the type
of (brief) discussion I would like to see in the draft. When it comes to
the definition of the mechanisms themselves, I am OK with them as they are.

Thanks,

Gonzalo