Subject: [paws] draft-wei-paws-database-discovery-01

From: Weixinpeng <[email-masked]>
Date: Wed, 22 May 2013 01:10:38 +0000

Hi all,
         I have uploaded a new version draft on database discovery. Comments are welcomed.
http://tools.ietf.org/html/draft-wei-paws-database-discovery-01.

Xinpeng Wei

---

From: "Mark Jones" <[email-masked]>
Date: Wed, 22 May 2013 11:29:00 -0400

Hi Xinpeng,

In section 3, you state:

   The URL or IP address of WSDB DS can be found by any method such as

   DNS, DHCP, manually configuring etc, and it is out of scope of this

   document.

I'm unclear on how the Master device obtains the URL of a trusted discovery
server unless there is some pre-configuration involved. I understand that
DNS could be used if the Master device is already pre-configured with a
preferred/home TVWS DS URL (or a preferred/home domain that is then resolved
with U-NAPTR) but I don't see how DHCP could be used to bootstrap this
information in the TVWS scenarios. Please could you elaborate.

Thanks

Mark

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Weixinpeng
Sent: May-21-13 9:11 PM
To: [email-masked]
Cc: Peter McCann
Subject: [paws] draft-wei-paws-database-discovery-01

Hi all, 

         I have uploaded a new version draft on database discovery. Comments
are welcomed.

 

Xinpeng Wei

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 22 May 2013 19:17:29 +0300

Hi Mark, 

if this follows LoST closely then the mechanisms are pretty much standard procedures used in a number of other protocols as well:

First, you can pre-configure your server (since LoST would allow you to get a response regardless where it enters the system). This makes a sense since you may get your server configured statically as part of the software default configuration. 

Second, you can dynamically obtain information about a server that is closer to your device via DHCP or (if that does not work) via a DNS lookup that first uses a reverse DNS lookup of the public IP address. 

Does this help? 

Ciao
Hannes

On May 22, 2013, at 6:29 PM, Mark Jones wrote:

> I’m unclear on how the Master device obtains the URL of a trusted discovery server unless there is some pre-configuration involved. I understand that DNS could be used if the Master device is already pre-configured with a preferred/home TVWS DS URL (or a preferred/home domain that is then resolved with U-NAPTR) but I don’t see how DHCP could be used to bootstrap this information in the TVWS scenarios. Please could you elaborate.
>

---

From: "Mark Jones" <[email-masked]>
Date: Wed, 22 May 2013 15:36:35 -0400

Hi Hannes,

Thanks for the explanation. Some comments/questions are inline below.

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: May-22-13 12:17 PM
> To: Mark Jones
> Cc: Hannes Tschofenig; 'Weixinpeng'; [email-masked]; 'Peter McCann'
> Subject: Re: [paws] draft-wei-paws-database-discovery-01
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> Hi Mark,
> 
> if this follows LoST closely then the mechanisms are pretty much standard
> procedures used in a number of other protocols as well:
> 
> First, you can pre-configure your server (since LoST would allow you to get a
> response regardless where it enters the system). This makes a sense since
> you may get your server configured statically as part of the software default
> configuration.
> 

Understood but I thought the goal of this draft was to get away from device pre-configuration. If one still has to configure the device with a URL then why not eliminate LoST and configure it with the URL of its "home WSDB" instead. If the device is roaming then it could get a redirect off the initial PAWS INIT_REQ/INIT_RESP to give it the URL of the WSDB appropriate for its roaming location. 

I realize that I'm coming late to these discussions so perhaps I missed a regulatory requirement that the WSDB DS provider be distinct from the WSDB provider. I don’t have an anti-LoST agenda here. I'm just trying to understand the motivation for a separate service.

> Second, you can dynamically obtain information about a server that is closer
> to your device via DHCP or (if that does not work) via a DNS lookup that first
> uses a reverse DNS lookup of the public IP address.
> 

These DHCP or reverse DNS methods assume that the non-WS IP connectivity provider (backhaul provider) has some business relationship with a WSDB DS provider for a given location. Is that correct?

> Does this help?

It does but I think this needs to be elaborated further in this draft. This is the mandatory first step in the discovery procedure so I think it needs more than an "out of scope", e.g. a few examples referring to the scenarios in the requirements draft.

Regards
Mark

> > I’m unclear on how the Master device obtains the URL of a trusted
> discovery server unless there is some pre-configuration involved. I
> understand that DNS could be used if the Master device is already pre-
> configured with a preferred/home TVWS DS URL (or a preferred/home
> domain that is then resolved with U-NAPTR) but I don’t see how DHCP could
> be used to bootstrap this information in the TVWS scenarios. Please could
> you elaborate.
> >
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> 
> iQEcBAEBCgAGBQJRnO+aAAoJEGhJURNOOiAtt8IH/AoLd2re9qEoSKNTJnf2pE
> UC
> /wz7QnJ8q77JKGwWY9imoeHMBp35M+1wnIS6dbKmRQQQYaFfbW/9ffkEhB
> VYPBga
> HWpjl6acEulUBq4HaKJYQE4JZ7FMVlH1LZrblkNRTGYaflNFGFFlKf9jhxGOXZzi
> grV/FOb6wATFp8lhGscwZ2iIK7j6p0rpx231YJtb5IqGc7wXho6wuGFlaaB8k+v+
> ayFVi7k/KUzXuk2madYwSXGDZjHwlwQfO1kvwZ1FC8oHHNDfZOI65rzawM+5
> 9n6T
> 6hpkRE1AnFdn26+zD14QTFkyWeHzjntkJK0BFamyi6TReHozmyQ4BCBeFTO8+
> u0=
> =LCBT
> -----END PGP SIGNATURE-----

---

From: Weixinpeng <[email-masked]>
Date: Thu, 23 May 2013 03:13:10 +0000

Hi Mark,
         Thanks for your feedback, and I think there are some issues that I need to clarify.

         we have to be clear that the discovery mechanism is provided as an optional method that can help master device to find the correct WSDB, which means the master device can get WSDB by, such as, pre-configuring of WSDB, provision etc.

         The dynamic discovery mechanism provides more convenient for master device to find WSDB, for example, when a new WSDB is setup for providing service or when some deployed WSDB goes down and never work.

         About the DHCP you mentioned below, technically speaking, there have been some extension of DHCP for supporting the provision of LoST server, refer to RFC5223. Besides, using DHCP method doesn't means IP network provider must have some business relationship with WSDB DS provider, if the network provider wants to provide master device with FQDN of WSDB DS it can use DHCP.

Best Regards,
Xinpeng.

From: Mark Jones [mailto:[email-masked]]
Sent: Wednesday, May 22, 2013 11:29 PM
To: Weixinpeng; [email-masked]
Cc: Peter McCann
Subject: RE: [paws] draft-wei-paws-database-discovery-01

Hi Xinpeng,

In section 3, you state:

I'm unclear on how the Master device obtains the URL of a trusted discovery server unless there is some pre-configuration involved. I understand that DNS could be used if the Master device is already pre-configured with a preferred/home TVWS DS URL (or a preferred/home domain that is then resolved with U-NAPTR) but I don't see how DHCP could be used to bootstrap this information in the TVWS scenarios. Please could you elaborate.

Thanks
Mark

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Weixinpeng
Sent: May-21-13 9:11 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Peter McCann
Subject: [paws] draft-wei-paws-database-discovery-01

Hi all,

Xinpeng Wei

---

From: "Mark Jones" <[email-masked]>
Date: Thu, 23 May 2013 10:30:33 -0400

Hi Xinpeng,

Thank you for your responses. I have some further comments/questions inline
below (prefixed by mj>).

From: Weixinpeng [mailto:[email-masked]] 
Sent: May-22-13 11:13 PM
To: Mark Jones; [email-masked]
Cc: Peter McCann; Zhulei (A)
Subject: RE: [paws] draft-wei-paws-database-discovery-01

Hi Mark,

         Thanks for your feedback, and I think there are some issues that I
need to clarify.

         we have to be clear that the discovery mechanism is provided as an
optional method that can help master device to find the correct WSDB, which
means the master device can get WSDB by, such as, pre-configuring of WSDB,
provision etc. 

mj> Understood.

         The dynamic discovery mechanism provides more convenient for master
device to find WSDB, for example, when a new WSDB is setup for providing
service or when some deployed WSDB goes down and never work.

mj> In this regard, DNS resolution would appear to be equally convenient
mechanism to manage WSDB instances being commissioned or decommissioned. I
view LoST as a kind of "location-aware DNS" so I understand its
applicability to discovery of the appropriate WSDB. I still think the draft
needs more information on how the Master device finds its WSDB DS so that
implementers understand if/when this optional discovery method is applicable
to their deployment.

         About the DHCP you mentioned below, technically speaking, there
have been some extension of DHCP for supporting the provision of LoST
server, refer to RFC5223. 

mj> I understand that the DHCP option specifying the LoST server would be
provided to the Master device when it initiated its backhaul connection
(non-WS connection) to the internet. Correct?

Besides, using DHCP method doesn't means IP network provider must have some
business relationship with WSDB DS provider, if the network provider wants
to provide master device with FQDN of WSDB DS it can use DHCP.

mj> If the backhaul network operator is configuring his DHCP server to send
options to provision the WSDB DS then I assume he has some business interest
in doing so. What am I missing?

Thanks

Mark

Best Regards,

Xinpeng.

Hi Xinpeng,

In section 3, you state:

   document.

Thanks

Mark

Hi all, 

 

Xinpeng Wei

---

From: Weixinpeng <[email-masked]>
Date: Fri, 24 May 2013 01:57:35 +0000

Hi Mark,
         Please see comments inline. Thanks!

Best Regards,
Xinpeng.

Sent: Thursday, May 23, 2013 10:31 PM

Hi Xinpeng,

Thank you for your responses. I have some further comments/questions inline below (prefixed by mj>).

From: Weixinpeng [mailto:[email-masked]]
Sent: May-22-13 11:13 PM
To: Mark Jones; [email-masked]<mailto:[email-masked]>
Cc: Peter McCann; Zhulei (A)
Subject: RE: [paws] draft-wei-paws-database-discovery-01

Hi Mark,

mj> Understood.

mj> In this regard, DNS resolution would appear to be equally convenient mechanism to manage WSDB instances being commissioned or decommissioned. I view LoST as a kind of "location-aware DNS" so I understand its applicability to discovery of the appropriate WSDB. I still think the draft needs more information on how the Master device finds its WSDB DS so that implementers understand if/when this optional discovery method is applicable to their deployment.
[Wei] Yeah, because we cannot covey location information in DNS query message, so DNS is inappropriate to find the WSDB. I think I will do more clarification about how master device finds WSDB DS later.

         About the DHCP you mentioned below, technically speaking, there have been some extension of DHCP for supporting the provision of LoST server, refer to RFC5223.

mj> I understand that the DHCP option specifying the LoST server would be provided to the Master device when it initiated its backhaul connection (non-WS connection) to the internet. Correct?
[Wei] Yeah.

Besides, using DHCP method doesn't means IP network provider must have some business relationship with WSDB DS provider, if the network provider wants to provide master device with FQDN of WSDB DS it can use DHCP.

mj> If the backhaul network operator is configuring his DHCP server to send options to provision the WSDB DS then I assume he has some business interest in doing so. What am I missing?
[Wei] I think there may be some relationship between network operator and WSDB DS. But the reason why DHCP is mentioned here is because in the LoST protocol DHCP is extended to provide LoST server's domain name to the LoST client.

Thanks
Mark

Best Regards,
Xinpeng.

From: Mark Jones [mailto:[email-masked]]
Sent: Wednesday, May 22, 2013 11:29 PM
To: Weixinpeng; [email-masked]<mailto:[email-masked]>
Cc: Peter McCann
Subject: RE: [paws] draft-wei-paws-database-discovery-01

Hi Xinpeng,

In section 3, you state:

Thanks
Mark

Hi all,

Xinpeng Wei