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

[Hannes Tschofenig <[e-mail]>]

Hi James,

Winterbottom, James wrote:
> Hi Hannes,
>
> A few points.
>
>
>   
>> 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.
>>     
>
> [AJW] Agreed
>
>   
>> 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.
>>
>>     
> [AJW] Agreed
>
>   
>> I think that the DHCP discovery and the DNS-based discovery shouldn't
>>     
> be
>   
>> in the same draft.
>>
>>     
>
> [AJW] We had two separate drafts for this and at the behest of a
> 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
> 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.
>   
That could potentially work.
>
>   
>> 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.
>>
>>     
>
> [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>
>
>   

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.

>   
>> 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.
>   
> [AJW] You don't think that the document does this?
>
>   
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.
>   
>
> [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.. ;)
>
>   
Many document handling decisions...

>> 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).
>>
>>     
>
> [AJW] See above.
>
>  
>   
>> 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.
>   
>
> [AJW] This is kind of covered. Would it be reasonable to add this in an
> appendix?
>
>   
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


>  
>   
>> It is good to have an example in the text.
>>
>>     
>
> [AJW] Do you like the current example, or do you want another one?
>
>  
>   
I like the current example.

Ciao
Hannes

>> Ciao
>> Hannes
>>
>>
>>
>> _______________________________________________
>> Geopriv mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/geopriv
>>     
>
> ------------------------------------------------------------------------------------------------
> 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]
>
>   



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