Subject: Re: [Geopriv] Open issues in draft-ietf-geopriv-lis-discovery?

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 1 May 2008 08:58:10 -0400

Comments in-line.
Barbara 

> [[MCD]] The intent isn't the same as the DHCP LbyR draft. As opposed
to
> your suggested definition, I think the more explicit statement would
be
> "The URI identifies a LIS and is not specific to any particular target
> device which can is locatable by this LIS". Since the intent of this
> draft, I believe, is actually the latter, I'm not sure that it's
> appropriate to be using this option in any case.

[BHS] Martin, I'm sorry -- I got a little lost at the end of this
statement. What option do you believe it's not appropriate to use?

>> 3. With the DNS options, it seems like this document could avoid some
of
>> the shaky issues with reverse DNS and NATs by explicitly stating 
>> requirements for networks in which this is deployed.  For example,
you 
>> might say that in order to support automatic LIS discovery, a network

>> MUST use include in DHCP messages either the LIS option (to support 
>> direct DHCP discovery), or one of the domain and FQDN options (to 
>> support NAPTR discovery).  In the latter cases, the network MUST
insert 
>> NAPTR records pointing to the LIS for all domain names contained in
such
>> options.

> [[MCD]] I agree. In the very common residential scenario - where there
> can be no assurance that the DHCP service in the residence is going to
> support the option then it is best if the alternative methods are
> supported by the broadband provider.

[BHS] Ugh! I feel like a broken record sometimes.
Please, either write a protocol specification or write a BCP (best
current  practices), but don't try to mix the two together. Or provide
implementation recommendations in the specification, but leave out the
normative language for those recommendations. This LIS Discovery draft
is not an ecrit document. It's not specific to emergency services. It's
not specific to the discovery of a LIS only in a consumer broadband
access environment. 

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622

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

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 1 May 2008 09:48:22 -0500

See below.

Cheers,
Martin

-----Original Message-----
From: Stark, Barbara [mailto:[email-masked]] 
Sent: Thursday, 1 May 2008 10:58 PM
To: Dawson, Martin; Richard Barnes; GEOPRIV
Subject: RE: [Geopriv] Open issues in draft-ietf-geopriv-lis-discovery?

Comments in-line.
Barbara 

to
be

[[MCD]] I meant the DHCP option described in the draft that is proposed
for the delivery of a location reference. That is, I don't think this
option is the same as one which simply provides a LIS URI and, as such,
shouldn't be considered appropriate for the general LIS discovery
purpose.

of
you 

insert 
such

[[MCD]] Fair call. I think, at some stage, a BCP is warranted. Hopefully
the protocol spec can precede the BCP... so probably we just need to
ensure these sorts of notes are captured while the spec progresses.
*****

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other
use of, or taking of any action in reliance upon this information by
persons or entities other than the intended recipient is prohibited. If
you received this in error, please contact the sender and delete the
material from all computers. GA622

------------------------------------------------------------------------------------------------
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: Richard Barnes <[email-masked]>
Date: Thu, 01 May 2008 11:06:34 -0400

Comments in-line
--Richard

> not specific to the discovery of a LIS only in a consumer broadband

[RLB] The proposed recommendation is not specific to emergency services 
or consumer broadband, it's specific to LIS discovery.  This document is 
describing ways that a physical access network can point an endpoint to 
a LIS, via one of two methods:
1. Directly telling the endpoint through a DHCP option
2. Telling the endpoint a DNS name, then letting the endpoint do NAPTR
The tricky thing is how the network "tells" the endpoint the proper DNS 
name.  The current draft allows the network to to tell the endpoint it's 
domain name implicitly, through the assigned IP address and reverse DNS. 
  This doesn't work reliably for a host of well-documented reasons, so 
my proposal was to remove this possibility and say that if a network is 
pointing endpoints to its LIS via option (2), then it has to make sure 
that option (2) works, i.e., it has tell hosts their domain names 
*explicitly*, and has to ensure that these domain names work for discovery.

As an aside, I think this draft may be written from a point of view 
that's too "client-centric", i.e., it assumes that network operators 
will figure out what they need to do (DHCP options, DNS records) based 
on what the client is going to do.  It seems like it would be really 
helpful if the draft clearly explained what the network has to do as 
well as the client (the above proposal being a part of that).