Subject: [Geopriv] Comments to draft-thomson-geopriv-lis-discovery-02

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 21 Jul 2007 21:35:12 +0200

I have a few comments. The document is important for the entire HELD 
solution and hence it is extremely important to discuss it during this 
meeting.
I also suggest a wide review within the IETF very early in the process 
since these discovery aspects can cause serious delays during the IETF 
Last Call.

I think that the DHCP discovery and the DNS-based discovery shouldn't be 
in the same draft.

Terminology
------------

Use the terms we always use: IAP, ISP instead of "access networks" and 
"access network provider"

Let us use the term LCS instead of LIS.

Discovery of "PUBLIC IP ADDRESS"
----------------------------------------

There are many protocols out there that allow the end host to 
communicate with a NAT to learn the public IP address.
Now there two approaches:
* You list some of them in the document and make one mandatory to implement
* You describe the one that is mandatory to implement and indicate that 
other mechanisms may be used as welll

I prefer the latter approach. Maybe STUN would be a good approach to use.

Discovery Order
-----------------

I think that this text needs to be in HELD rather than in this document.

Extensions
-----------

I believe that the concept in general might have a broader applicability 
and hence I would suggest to generalize the work on the DNS-based 
discovery procedure to support other applications as well. I think it 
would be interesting to use this stuff for LoST as well (not in the 
current LoST document but as a future extension).

Operational Considerations
----------------------------

I also believe that the document should have a section that talks about 
the operational considerations for the DNS-based discovery approach. It 
essentially requires the ISP to have the IP addresses of the end hosts 
or the DSL routers in the DNS in order for this resolution step to work.

It is good to have an example in the text.

Ciao
Hannes

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 21 Jul 2007 15:18:18 -0500

Hi Hannes,

A few points.

> solution and hence it is extremely important to discuss it during this

[AJW] Agreed

> since these discovery aspects can cause serious delays during the IETF
[AJW] Agreed

> I think that the DHCP discovery and the DNS-based discovery shouldn't
be

[AJW] We had two separate drafts for this and at the behest of a
previous chair we combined them. What may be a more reasonable approach
is to convert this document into a general "This is how you find local
services" document, and put the specific UNAPTR and HELD bits into the
HELD draft.

> Terminology

[AJW]   <soapbox> I still hate the term LCS because of its widespread
alternate usage in 3GPP (there are literally 10s of specs that use LCS
for location services). LIS is being used in a number of other
specifications, and is appearing in lots of RFIs/RFPs and RFQs. I think
that we in the IETF are picking something different, just for the sake
of being different here, and it is going to cause confusion in the wider
industry.</soapbox>

> Discovery of "PUBLIC IP ADDRESS"
[AJW] You don't think that the document does this?

> Discovery Order

[AJW] If this document is to be the basis for local service discovery
then I think the order is better here. If we decide to split it up into
DHCP and DNS again, then your suggestion is good, though it will make
the HELD draft longer again.. ;)

> Extensions

[AJW] See above.

> Operational Considerations

[AJW] This is kind of covered. Would it be reasonable to add this in an
appendix?

> It is good to have an example in the text.

[AJW] Do you like the current example, or do you want another one?

> Hannes

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 21 Jul 2007 22:45:21 +0200

Hi James,

Winterbottom, James wrote:
>> I think that the DHCP discovery and the DNS-based discovery shouldn't
>>     
> be
>   
>> in the same draft.
>>
>>     
>
> previous chair we combined them. 
I understand.

I am, however, interesting in extending this to other "application 
domains". Hence, having both mechanisms in one document wouldn't allow 
me todo that.

> What may be a more reasonable approach
That could potentially work.
> of being different here, and it is going to cause confusion in the wider

I don't care about the specific term being used. I just want to use the 
same term through the different documents since otherwise it is far too 
confusing for every reader.

>> * You describe the one that is mandatory to implement and indicate
>>     
> that
>   
>> I prefer the latter approach. Maybe STUN would be a good approach to
>>     
> use.
>   
The document also talks about UPnP. The question is whether it is only 
an example or more than it.
There are  many other protocols that provide similar capabilities.

>  
>   
>> Discovery Order
>> -----------------
>>
>> I think that this text needs to be in HELD rather than in this
>>     
> document.
>   
>
Many document handling decisions...

>> Extensions
>> -----------
>>
>> I believe that the concept in general might have a broader
>>     
> applicability
>   
>> I also believe that the document should have a section that talks
>>     
> about
>   
>> the operational considerations for the DNS-based discovery approach.
>>     
> It
>   
>> or the DSL routers in the DNS in order for this resolution step to
>>     
> work.
>   
>
I am mentioning this since  Dan  has  posted the document about  
operational considerations to the group. I went through it and noticed 
that it is not relevant for the requirements but certainly helpful for 
this document.

The appendix would be good

> [AJW] Do you like the current example, or do you want another one?
I like the current example.

Ciao
Hannes