Subject: Re: [tram] Suresh Krishnan's Discuss on draft-ietf-tram-turn-server-discovery-09: (with DISCUSS)

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Fri, 2 Sep 2016 21:54:04 +0000

Hi Suresh,
Apologies for the delay, just back from holiday. Please see inline..

On 8/31/16, 9:18 PM, "Suresh Krishnan" <[email-masked]>
wrote:

>Suresh Krishnan has entered the following ballot position for
>draft-ietf-tram-turn-server-discovery-09: Discuss
>
>When responding, please keep the subject line intact and reply to all
>email addresses included in the To and CC lines. (Feel free to cut this
>introductory paragraph, however.)
>
>
>Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>for more information about IESG DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/
>
>
>
>----------------------------------------------------------------------
>DISCUSS:
>----------------------------------------------------------------------
>
>* Section 4.1.1.
>
>The DHCP procedure is underspecified. I think this can be easily fixed
>but it requires some work.
>
>Please describe what sort of messages you would be using. i.e. are you
>going for a stateful exchange to piggy pack with other address and config
>information or are you going for a stateless Information-request based
>exchange(Most likely). Is there an ORO? If so, what options are requested
>in the ORO? Are there multiple request-response round trips as implied by
>the text?

Does following text address your concerns?

..
   DHCP can be used to determine the domain name related to an
   interface's point of network attachment.  Network operators may
   provide the domain name to be used for service discovery within an
   access network using DHCP.  Sections 3.2 and 3.3 of [RFC5986] define
   DHCP IPv4 and IPv6 access network domain name options,
   OPTION_V4_ACCESS_DOMAIN and OPTION_V6_ACCESS_DOMAIN respectively, to
   identify a domain name that is suitable for service discovery within
   the access network.

   For IPv4, the discovery procedure MUST request for an access network
   domain name option in a Parameter Request List option, as described
   in [RFC2131].  [RFC2132] defines the DHCP IPv4 domain name option;
   while this option is less suitable, a client MAY request for it if
   the access network domain name defined in [RFC5986] is not available.

   For IPv6, the discovery procedure MUST request for an access network
   domain name option in an Options Request Option (ORO), as described
   in [RFC3315].

   If neither option can be retrieved the procedure fails for this
   interface.  If a result can be retrieved it will be used as input
   for S-NAPTR resolution.

..

-Prashanth

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 7 Sep 2016 04:22:16 +0000

Hi Prashanth,

>    interface.  If a result can be retrieved it will be used as input

Thank you. That certainly addresses one part of my DISCUSS but it still needs 
additional text on the DHCPv6 side to specify which message exchange will be 
used. Did you intend to use the stateful exchange or the stateless exchange?

Regards
Suresh

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Thu, 8 Sep 2016 03:27:05 +0000

Hi Suresh,

On 9/6/16, 9:22 PM, "Suresh Krishnan" <[email-masked]> wrote:

>>> Please refer to
>>>https://www.ietf.org/iesg/statement/discuss-criteria.html
>used. 

Sorry, missed that one.

>Did you intend to use the stateful exchange or the stateless exchange?

We intend to use stateless. Will update the draft accordingly.

Thanks,
Prashanth

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 9 Sep 2016 10:20:04 +0000

Hi Prashanth,

> We intend to use stateless. Will update the draft accordingly.

Sounds good. I will clear when the new revision posts.

Thanks
Suresh