Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-service-discovery-11

From: Jouni Mäenpää <[email-masked]>
Date: Sun, 8 Jun 2014 09:14:34 +0000

Hi,

Thanks for the comments! They have been addressed in the new -12 revision of the draft.

> Given that the base RELOAD spec already defines a discovery mechanism for 
> TURN, I was surprised to see TURN as the only service registered in the new 
> namespaces registry. What was the rationale for that decision?

The service discovery mechanism in the base RELOAD spec is specific to TURN. The reason why we started writing this draft was that there was interest from the working group in having also a more generic service discovery mechanism for RELOAD that could be used also for other use cases than TURN server discovery. Use cases that were discussed at that point included among others voice mail and gateway discovery. Should we add these services to the namespaces registry? ReDiR can also be used as alternative to the TURN server discovery mechanism specified in RELOAD base.

Regards,
Jouni

-----Original Message-----
From: Alissa Cooper [mailto:[email-masked]] 
Sent: 30. toukokuuta 2014 23:50
To: [email-masked]
Cc: [email-masked]
Subject: AD evaluation: draft-ietf-p2psip-service-discovery-11

I have reviewed this document in preparation for IETF last call. It’s in good shape. I have one question before I issue the last call, though.
Given that the base RELOAD spec already defines a discovery mechanism for TURN, I was surprised to see TURN as the only service registered in the new namespaces registry. What was the rationale for that decision?

Some nits to be resolved with any last call comments:

Section 2:
s/"turn-relay”/“turn-server”/

Section 4.2:
"It is RECOMMENDED that Lstart is set to 2.”

It would be helpful to add some text here to motivate the decision to use
2 as the recommendation.

Section 4.5
s/note: within the entire tree/note: within the entire tree node/

Section 5:
s/every kind which is storable/every Kind which is storable/

Section 6:
s/REDIR kind/REDIR Kind/

Section 8:
s/"REDIR” kind/"REDIR” Kind/

Section 9:
Seems like this section deserves a mention of the fact that a new access control policy had to be defined for Redir.

Section 10.4:
s/IANA SHALL create/IANA is requested to create/

Thanks,
Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 11 Jun 2014 16:26:35 -0700

Hi Jouni,

On 6/8/14, 2:14 AM, "Jouni Mäenpää" <[email-masked]> wrote:

>The service discovery mechanism in the base RELOAD spec is specific to
>TURN. The reason why we started writing this draft was that there was
>interest from the working group in having also a more generic service
>discovery mechanism for RELOAD that could be used also for other use
>cases than TURN server discovery. Use cases that were discussed at that
>point included among others voice mail and gateway discovery. Should we
>add these services to the namespaces registry? ReDiR can also be used as
>alternative to the TURN server discovery mechanism specified in RELOAD
>base.

I don’t have a strong opinion on whether the other services should be
added. If people are interested in using them, then they should be added.
Are people interested? If not, there should be an explanation in the
document that TURN is the only current use case of interest and that ReDir
is an alternative to the already-specified TURN discovery mechanism.

Thanks,
Alissa

>I have reviewed this document in preparation for IETF last call. It’s in
>good shape. I have one question before I issue the last call, though.
>TURN, I was surprised to see TURN as the only service registered in the
>new namespaces registry. What was the rationale for that decision?
>
>Seems like this section deserves a mention of the fact that a new access
>control policy had to be defined for Redir.
>
>Section 10.4:

---

From: Jouni Mäenpää <[email-masked]>
Date: Sat, 14 Jun 2014 08:34:25 +0000

Hi,

> Sent: 12. kesäkuuta 2014 2:27
> To: Jouni Mäenpää; [email-masked]
> Cc: [email-masked]
> Subject: Re: AD evaluation: draft-ietf-p2psip-service-discovery-11
> 
> Hi Jouni,
> 
> >> Given that the base RELOAD spec already defines a discovery mechanism
> >>for  TURN, I was surprised to see TURN as the only service registered
> >>in the new  namespaces registry. What was the rationale for that
> >>decision?
> >
> >add these services to the namespaces registry? ReDiR can also be used
> >as alternative to the TURN server discovery mechanism specified in
> >RELOAD base.
> 
> I don’t have a strong opinion on whether the other services should be added. If
> people are interested in using them, then they should be added.
> Are people interested? If not, there should be an explanation in the document
> that TURN is the only current use case of interest and that ReDir is an
> alternative to the already-specified TURN discovery mechanism.

Thanks for the reply! In the new -13 revision of the draft, we added one additional service (voice-mail). Also a note that ReDiR can be used as an alternative to the TURN server discovery mechanism in RELOAD base was added.

Regards,
Jouni

> >I have reviewed this document in preparation for IETF last call. It’s
> >in good shape. I have one question before I issue the last call, though.
> >Given that the base RELOAD spec already defines a discovery mechanism
> >for TURN, I was surprised to see TURN as the only service registered in
> >the new namespaces registry. What was the rationale for that decision?
> >
> >Seems like this section deserves a mention of the fact that a new
> >access control policy had to be defined for Redir.
> >
> >Section 10.4: