Subject: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt

From: "Marc Linsner" <[email-masked]>
Date: Mon, 18 Sep 2006 19:41:48 -0400

Please read this and express a hum for or against accepting as a wg item.
I'll count hums at the end of this week.

      Title		: A Dynamic Host Configuration Protocol (DHCP)
                           based Location-to-Service Translation
                           Protocol (LoST) Discovery Procedure
	Author(s)	: H. Schulzrinne, et al.
	Filename	: draft-polk-ecrit-dhc-lost-discovery-00.txt
	Pages		: 17
	Date		: 2006-9-5

Thanks,

-Marc-  

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 19 Sep 2006 11:55:42 -0400

Please respond since we want to finish the LoST as soon as possible.
Comments on the LoST draft are also very much appreciated.

---

From: Andrew Newton <[email-masked]>
Date: Tue, 19 Sep 2006 13:37:12 -0400

I don't understand why the draft describes three different ways of  
doing this: ip addresses, a records, and naptr records... the latter  
seemingly missing the point of naptr records.

This draft should simply provide one thing: a domain name.  That  
would be the input into the U-NAPTR algorithm along with the service  
URN.  From there, multiple naptrs can be found, pointing to URIs.   
And pointing to a URIs is essential, as the HTTP request path cannot  
be gleened via just an IP address or A record.

I'd like to see this fixed before the working group adopts this item.

-andy

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 19 Sep 2006 13:40:28 -0400

Hi Andy,

we used the SIP-based discovery work. Hence, it was fine with SIP proxy 
server discovery why isn't it fine todo the same here as well?

Ciao
Hannes

Andrew Newton schrieb:
> I don't understand why the draft describes three different ways of doing 
> this: ip addresses, a records, and naptr records... the latter seemingly 
> missing the point of naptr records.
> 
> This draft should simply provide one thing: a domain name.  That would 
> be the input into the U-NAPTR algorithm along with the service URN.  
>  From there, multiple naptrs can be found, pointing to URIs.  And 
> pointing to a URIs is essential, as the HTTP request path cannot be 
> gleened via just an IP address or A record.
>

---

From: Andrew Newton <[email-masked]>
Date: Tue, 19 Sep 2006 13:47:07 -0400

On Sep 19, 2006, at 1:40 PM, Hannes Tschofenig wrote:

>
> we used the SIP-based discovery work.

I don't understand this.

> Hence, it was fine with SIP proxy server discovery why isn't it  
> fine todo the same here as well?

Perhaps because this is a configuration mechanism, which might be  
used in one of the steps for discovery.

-andy

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 19 Sep 2006 13:48:03 -0400

Let me be a bit more precise:

We used the procedure used in RFC 3361 and from RFC 3319.

RFC 3361
           Dynamic Host Configuration Protocol (DHCP-for-IPv4)
           Option for Session Initiation Protocol (SIP) Servers

RFC 3319

           Dynamic Host Configuration Protocol (DHCPv6) Options
           for Session Initiation Protocol (SIP) Servers

Ciao
Hannes

---

From: Andrew Newton <[email-masked]>
Date: Wed, 20 Sep 2006 10:12:01 -0400

>           for Session Initiation Protocol (SIP) Servers

Yes, it looks very similar.  But the usages for SIP and LoST are very 
different. The problem is that your LoST location configuration with DHCP is 
actually non-interoperable with the current LoST specification.

dhc-lost-discovery describes three methods of configuration:

1) IP address(es).
2) A record lookup.
3) Multiple NAPTR record lookups.

The problem with the 1 and 2 is that they don't do enough.  The U-NAPTR 
resolution specified in LoST could, and likely should, result in HTTP URIs 
that use ports other than 80 with specific query paths.  As an example: 
https://example.com:4433/lost/.  Neither an IP address nor an A record is 
enough information to construct that URI.

The problem with option 3 is that it fails to understand how DNS and U-NAPTR 
work.  Your specification says that when multiple DNS qnames are present, 
they are used to query multiple NAPTR records.  Why?  The query against one 
qname can result in multiple NAPTR records.  What's the purpose of adding a 
layer above the U-NAPTR algorithm?

I can only conclude that this draft is incompatible with the work already 
accepted by ECRIT, and therefore should not be accepted as a working group 
item until it is fixed.

To be quite clear, I like the idea of using DHCP to configure a pointer to 
the LoST server, and I'd be in favor of working group acceptance of a 
document that did it in a way compatible with LoST.

-andy

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 20 Sep 2006 10:35:28 -0400

I agree.
Barbara

________________________________

From: Marc Linsner [mailto:[email-masked]]
Sent: Mon 9/18/2006 7:41 PM
To: [email-masked]
Subject: [Ecrit] Hum for draft-polk-ecrit-dhc-lost-discovery-00.txt

Thanks,

-Marc- 

*****

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

---

From: Leslie Daigle <[email-masked]>
Date: Wed, 20 Sep 2006 18:27:09 -0400

Further -- as noted in all the DDDS documentation, NAPTR
records don't exist "in the wild"; they are always part of a
DDDS application (in this case, U-NAPTR).

So -- it seems that the 3rd option should really be about
specifying the application unique string that feeds into
the U-NAPTR-based LoST discovery specification.  The
application unique string would, in fact, be an FQDN.

If you really need another layer of indirection (and I suspect
Andy is right, you don't), you could still have multiple
AUS's.

Leslie.

Andrew Newton wrote:
> different. The problem is that your LoST location configuration with 
> DHCP is actually non-interoperable with the current LoST specification.
> 
> resolution specified in LoST could, and likely should, result in HTTP 
> URIs that use ports other than 80 with specific query paths.  As an 
> example: https://example.com:4433/lost/.  Neither an IP address nor an A 
> record is enough information to construct that URI.
> 
> The problem with option 3 is that it fails to understand how DNS and 
> U-NAPTR work.  Your specification says that when multiple DNS qnames are 
> present, they are used to query multiple NAPTR records.  Why?  The query 
> against one qname can result in multiple NAPTR records.  What's the 
> purpose of adding a layer above the U-NAPTR algorithm?
> 
> I can only conclude that this draft is incompatible with the work 
> already accepted by ECRIT, and therefore should not be accepted as a 
> working group item until it is fixed.
> 
> To be quite clear, I like the idea of using DHCP to configure a pointer 
> to the LoST server, and I'd be in favor of working group acceptance of a

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 22 Sep 2006 03:51:25 -0400

Hi Andy,

Andrew Newton schrieb:
> different.

SIP and LoST are very different. The discovery mechanism is, however, 
similar.

  The problem is that your LoST location configuration with
> URIs that use ports other than 80 with specific query paths.

Why do you think that it is useful to use anything other than the 
default port with U-NAPTR for LoST discovery? I would argue that this 
would make it very hard to get the LoST messages through a firewall. 
Imaging, I a LoST server at my VSP running at a port number that is 
provided by U-NAPTR. Do you think I would get through most firewalls in 
access networks?

   As an
> record is enough information to construct that URI.

While I agree that these discovery mechanisms provide different 
properties it is up to the local network to determine what they would 
like to use. If there is only a single LoST server in the access network 
  running at port 80 why do we need to use anything else than (1).

> purpose of adding a layer above the U-NAPTR algorithm?

The DHCP-based mechanism is not there to replace or compete in any way 
with the mechanism proposed in the LoST draft. They just fulfill an 
entirely different purpose.

It would be fine for me to just specify a single FQDN in the DHCP option 
  if that would satisfy some of your concerns.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 22 Sep 2006 03:56:58 -0400

Hi Leslie,

I just to make sure that I understand you right. With the third option 
you would use the DHCP option to return an FQDN (instead of a domain 
name) and use it as input to the U-NAPTR-based discovery found in the 
LoST specification.

I am just curious why the mechanisms used for SIP are not good enough 
for our purpose.

Ciao
Hannes

Leslie Daigle schrieb:
>> The problem with the 1 and 2 is that they don't do enough.  The 
>> U-NAPTR resolution specified in LoST could, and likely should, result 
>> in HTTP URIs that use ports other than 80 with specific query paths.  
>> As an example: https://example.com:4433/lost/.  Neither an IP address 
>> nor an A record is enough information to construct that URI.
>>
>> U-NAPTR work.  Your specification says that when multiple DNS qnames 
>> are present, they are used to query multiple NAPTR records.  Why?  The 
>> query against one qname can result in multiple NAPTR records.  What's 
>> the purpose of adding a layer above the U-NAPTR algorithm?
>>
>> To be quite clear, I like the idea of using DHCP to configure a 
>> pointer to the LoST server, and I'd be in favor of working group 
>> acceptance of a document that did it in a way compatible with LoST.
>>
>> -andy
>>
> 
>

---

From: Andrew Newton <[email-masked]>
Date: Fri, 22 Sep 2006 10:32:02 -0400

Hannes Tschofenig wrote:

[...skipping dangerous assumptions about port 80...]

>  if that would satisfy some of your concerns.

Yes, it would.  And that would be simpler to code against, too.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Fri, 22 Sep 2006 10:34:21 -0400

> name) and use it as input to the U-NAPTR-based discovery found in the 

Oh boy!  What's the difference between a FQDN and a domain name?

> I am just curious why the mechanisms used for SIP are not good enough 

I think the better question is, why do we need to copy the mechanisms from 
SIP when there is a simpler solution?

-andy

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Fri, 22 Sep 2006 16:56:06 +0200

Hi Andy, 

> Oh boy!  What's the difference between a FQDN and a domain name?

Sorry. It should read 'return an FQDN (instead of an IP address)'.

> SIP when there is a simpler solution?
It might look nicer but it less efficient with regard to the number of
messages that are needed before we get the IP address of the LoST
server.  

How many LoST servers do we think we typically have in an access
network? 

Ciao
Hannes

---

From: Andrew Newton <[email-masked]>
Date: Fri, 22 Sep 2006 11:08:30 -0400

> messages that are needed before we get the IP address of the LoST

I'm afraid the number of messages argument has been lost on LoST... I should 
know, I was the one making it.  If we are truly concerned about the number 
of messages, then we should seriously think about dropping HTTP and HTTPS in 
favor of a UDP transfer service.  But we are not doing that because in 
general there does not seem to be a large concern about this.  Do you really 
want to open that can of worms?

Additionally, this is a configuration-time or network-attachment-time 
process, and the engineering in this working group regarding processes that 
take place at network attachment have always assumed plenty of breathing 
room.  We can also re-examine that if you would like, but I don't recommend it.

Finally, I can't help but point out that the 3rd mechanism in the current 
draft is a layer on top of U-NAPTR, and therefore even more messages than 
the concern you have stated.

-andy

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 22 Sep 2006 11:09:33 -0400

Hi Andy,

> [...skipping dangerous assumptions about port 80...]

You seem to assume that we have to return a port number as part of the 
discovery procedure, I guess.

> 
>> It would be fine for me to just specify a single FQDN in the DHCP 
>> option  if that would satisfy some of your concerns.
> 
Is it OK for you to still have the ability to carry an IP address to the 
end host using DHCP in there?

Ciao
Hannes

---

From: Andrew Newton <[email-masked]>
Date: Fri, 22 Sep 2006 11:13:45 -0400

> discovery procedure, I guess.

Not just a port number, but an HTTP query path too.  Please go back and read 
my email about how you get from an IP address to a URI.

> end host using DHCP in there?

Absolutely not.  Again, an IP address does not contain enough information to 
construct an HTTP URI.  See above.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 23 Sep 2006 12:08:42 +0200

Andrew Newton wrote:
> Not just a port number, but an HTTP query path too.  Please go back and 
> read my email about how you get from an IP address to a URI.

Not really. The LoST-URL U-NAPTR process does this already. There's no 
need to do this twice.

> 
>> Is it OK for you to still have the ability to carry an IP address to 
>> the end host using DHCP in there?
> 
> Absolutely not.  Again, an IP address does not contain enough 
> information to construct an HTTP URI.  See above.
> 
> -andy
>

---

From: Andrew Newton <[email-masked]>
Date: Sat, 23 Sep 2006 10:27:25 -0400

On Sep 23, 2006, at 6:08 AM, Henning Schulzrinne wrote:

>
>
> Andrew Newton wrote:
>> Hannes Tschofenig wrote:
>>> You seem to assume that we have to return a port number as part  
>>> of the discovery procedure, I guess.
>> Not just a port number, but an HTTP query path too.  Please go  
>> back and read my email about how you get from an IP address to a URI.
>
> Not really. The LoST-URL U-NAPTR process does this already. There's  
> no need to do this twice.

That would be great, except we are talking about an IP address and  
not a LoST URL.  Besides, the LoST URL produces an HTTP URL from the  
U-NAPTR process, and that is where you get a query path.

-andy

---

From: Leslie Daigle <[email-masked]>
Date: Tue, 26 Sep 2006 19:13:19 -0400

Hi Hannes,

 > I am just curious why the mechanisms used for SIP are not good enough

If you're referring to RFC3263 -- observe that 3263<3401 (the
final publication number of the DDDS spec) :-)

I.e., the SIP location service was defined when NAPTR-based
application specification was caught in IESG-limbo-hell (yes, I remember
when "final" documents disappeared into the IESG for 6 months
at a stretch, and your AD didn't reply to your e-mail, EVER, and
there WAS NO I-D TRACKER!  *ahem* sorry... just had to get that
twitch over with ;-) ).

So -- if the SIP location service was defined today, it would have
different text.

> name) and use it as input to the U-NAPTR-based discovery found in the 

Yes -- with the adjustment to the above that you & Andy later agreed
on ("instead of an IP address").

That would align with the material in draft-ietf-ecrit-lost-01.txt --
i.e., that domain names are used in a U-NAPTR application to produce
the actual URI(s) of the LoST server(s).

I'd suggest this text:

    The option MAY contain multiple domain names, but these SHOULD refer
    to different NAPTR records, rather than different A records.  The
    client MUST try the records in the order listed.  The client only
    resolves the subsequent domain names if attempts to contact the first
    one failed or yielded no common transport protocols between client
    and server or denote a domain administratively prohibited by client
    policy.

    Use of multiple domain names is not meant to replace NAPTR (?TBD?)
    and SRV records, but rather to allow a single DHCP server to indicate
    LoST servers operated by multiple providers.

wants to become something like this:

    The option MAY contain multiple domain names, each of which can
    separately be used to locate an appropriate LoST service as
    outlined in (<tbd -- draft-ietf-ecrit-lost-01.txt>).  The client only
    resolves the subsequent domain names if attempts to contact the first
    one failed or yielded no common transport protocols between client
    and server or denote a domain administratively prohibited by client
    policy.

And then this:

    Use of multiple domain names is not meant to replace NAPTR (?TBD?)
    and SRV records, but rather to allow a single DHCP server to indicate
    LoST servers operated by multiple providers.

should actually be handled in the draft-ietf-ecrit-lost-01.txt document
(IMO) -- an illustration of how you can use one FQDN and point
to several different services operated by various providers.

To borrow a text illustration from the S-NAPTR document, you already
get at least 2 opportunities to "share the load" in ?-NAPTR:

<quote from RFC3958>

    Thus, to find the EM services for thinkingcat.example, the NAPTR
    records for thinkingcat.example are retrieved:

thinkingcat.example.
;;   order pref flags
IN NAPTR 100  10   "s"   "EM:ProtA"                  (   ; service
                          ""                              ; regexp
                         _ProtA._tcp.thinkingcat.example. ; replacement
                                                      )
IN NAPTR 100  20   "s"   "EM:ProtB"                  (   ; service
                          ""                              ; regexp
                          _ProtB._tcp.example.com.        ; replacement
                                                      )
IN NAPTR 100  30   "s"   "EM:ProtC"                  (   ; service
                          ""                              ; regexp
                          _ProtC._tcp.example.com.        ; replacement
                                                      )

    Then the administrators at example.com can manage the preference
    rankings of the servers they use to support the ProtB service:

    _ProtB._tcp.example.com.
     ;;    Pref Weight Port  Target
    IN SRV 10    0     10001 bigiron.example.com.
    IN SRV 20    0     10001 backup.em.example.com.
    IN SRV 30    0     10001 nuclearfallout.australia-isp.example.

</quote from RFC3958>

Leslie.

>>> are present, they are used to query multiple NAPTR records.  Why?  
>>> The query against one qname can result in multiple NAPTR records.  
>>> What's the purpose of adding a layer above the U-NAPTR algorithm?
>>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 27 Sep 2006 09:37:11 +0200

Hi Leslie,

how naive from my side to think that RFC 3361 and RFC 3319 went through 
the IETF process without complications.

Anyway, I have addressed the comments and submitted a draft update:
http://www.tschofenig.priv.at/svn/draft-tschofenig-dhc-lost-discovery/draft-polk-ecrit-dhc-lost-discovery-01.txt

Ciao
Hannes

PS: Currently, the draft does not allow more than one domain name. If 
useful then I am going to change it.

Leslie Daigle schrieb:
>>>> Yes, it looks very similar.  But the usages for SIP and LoST are 
>>>> very different. The problem is that your LoST location configuration 
>>>> with DHCP is actually non-interoperable with the current LoST 
>>>> specification.
>>>>
>>>> U-NAPTR resolution specified in LoST could, and likely should, 
>>>> result in HTTP URIs that use ports other than 80 with specific query 
>>>> paths.  As an example: https://example.com:4433/lost/.  Neither an 
>>>> IP address nor an A record is enough information to construct that URI.
>>>>