Subject: Re: [Int-dir] Could I get a few DNS experts to review draft-faltstrom-uri?

From: 神明達哉 <[email-masked]>
Date: Mon, 4 Aug 2014 15:17:45 -0700

At Thu, 31 Jul 2014 13:27:31 -0700,
"Christopher LILJENSTOLPE" <[email-masked]> wrote:

> Thank's Tatuya!  You are correct in your assumption.  There is no
> drop-dead date, but Ted would prefer it sooner, rather than later.

This is my review comment.  I've found a few possible issues that may
have to be resolved before publication.  But I'm not sure if these are
sufficiently critical to be a blocking issue.

- Section 3: I don't understand the rationale of this sentence (or I
  don't understand what it means):

   Using prefix labels, such as underscored service tags, prevents the
   use of wildcards, as constructs as _s2._s1.*.example.net.  are not
   possible in the DNS, see RFC 4592 [RFC4592].

  I don't understand which part of RFC 4592 is referenced here, but as
  far as I can see the RFC rather states such use of wildcards is
  acceptable (see Section 2.1.3).  Perhaps what it tries to say is
  that, for example, "_s2._s1.*.example.net. cannot be used to
  synthesize an answer for _s2._s1._s0.example.net."  If so, that is
  correct, but the above sentence couldn't be interpreted that way to
  me.

- Section 3: the previous point aside, the rest of this section seems
  too vague to me to understand.  For example, phrases like "subtle
  management problems" are literally subtle.  Some concrete examples
  (even if they are hypothetical) may help.

- Section 4.4: I don't see why this field needs to be enclosed with
  double-quotes.  It's placed in the end of the RDATA, and there
  should be no ambiguity or other issues that would require quotation.
  It's also not clear to me how IRIs are represented in the
  presentation (textual) format.  For example, could there be a utf-8
  encoded string here?  If so, that's quite different from the usual
  practice for the presentation format of existing RR types, where
  only printable ascii characters are used.

- Section 5, about the "D" flag: (asking simply because I don't know)
  is it enough to publish an RFC for introducing a new flag value of
  NAPTR?  Isn't there any registration procedure required, such as
  IANA considerations?

- References: I wonder whether RFC 3404 should be listed in the
  normative references section, given that this draft makes a protocol
  update (a new flag value of NAPTR RDATA) to the RFC

Editorial nits:
- Section 1: s/need/needs/
   need to know both the hostname and the protocol that the URI is to be

- Section 1: s/because/is because/
   interested in.  This because data in the service field of the NAPTR

- Section 4.1: I see why there is a "duplicate" dot, but it still
   looks awkward.  Maybe we could remove one dot, or enclose
   "example.com." with quotes.
   Service Parameter "A:B:C" for host example.com.. Then we would query

- Section 4.5: s/are/be/
   The Target field can also contain an IRI, but with the additional
   requirements that it are in UTF-8 [RFC3629], and the requirement that

- Section 7: s/seond/second/
   It is instead an extension and the seond step of the S-NAPTR

- Section 8: s/know/knows/
   a replacement for U-NAPTR [RFC4848].  The URI Resource Record Type is
   though only interesting when one know a base domain name, a protocol

- Section 8: s/exists/exist/
   records of any kind are used to look up what services exists for a

- Section 9: s/because/is because/
   SRV record.  This because it like the SRV record can only be looked

- Section 9: s/return/returns/
   number, the URI record return a full URI. As such, it can be viewed

--
JINMEI, Tatuya

---

From: "Christopher LILJENSTOLPE" <[email-masked]>
Date: Mon, 04 Aug 2014 15:57:52 -0700

> sufficiently critical to be a blocking issue.

Thank you Tatuya!

	Christopher

--
李柯睿
Avt tace, avt loqvere meliora silentio
Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc
Current vCard here: http://www.asgaard.org/cdl/cdl.vcf

---

From: "Christopher LILJENSTOLPE" <[email-masked]>
Date: Mon, 04 Aug 2014 16:00:27 -0700

Greetings Ralf,

	Wondering if you had seen the request for review and if so, would you 
be able to also submit?  If not, we need to find someone else soonish.

	Christopher

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 05 Aug 2014 09:45:35 +0300

Hi

Just one comment below.

>    correct, but the above sentence couldn't be interpreted that way to

The above originates from SRV RRs.. see Section 4.5. of RFC4592. In case 
of SRVs the "*.example.net" is a wildcard domain name but not the owner 
domain name (which would still be "_s2._s1.*.example.net" and that is 
not a wildcard domain name).

What I think should be said in the draft is an exact reference i.e. 
pointing to the exact section in RFC4592 that actually explains the SRV 
RR case.

- Jouni

> _______________________________________________
> Int-dir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-dir
>

---

From: Ralf Weber <[email-masked]>
Date: Tue, 5 Aug 2014 06:51:27 +0000

Moin!

On 05 Aug 2014, at 00:00, Christopher LILJENSTOLPE <[email-masked]> =
wrote:
> 	Wondering if you had seen the request for review and if so, =
would you be able to also submit?  If not, we need to find someone else =
soonish.
Not until now as I'm on a family vacation and list mail is sorted in =
folders. Would a review early next week (Monday or Tuesday) be ok?

So long
-Ralf
---
Ralf Weber
Senior Infrastructure Architect
office: +49 6446 4392053
mobile: +49 151 22659325
us: +1 650 817 5895
Nominum=20
www.nominum.com
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Tue, 5 Aug 2014 09:02:07 -0400

> folders. Would a review early next week (Monday or Tuesday) be ok?

Yes, of course.   Thanks!

---

From: "Christopher LILJENSTOLPE" <[email-masked]>
Date: Tue, 05 Aug 2014 06:04:38 -0700

> folders. Would a review early next week (Monday or Tuesday) be ok?

That would be great Ralf - thx.

	Christopher

---

From: 神明達哉 <[email-masked]>
Date: Tue, 5 Aug 2014 10:31:55 -0700

At Tue, 05 Aug 2014 09:45:35 +0300,

> pointing to the exact section in RFC4592 that actually explains the SRV

Ah, okay, and then I believe it's essentially the same as "(perhaps)
what it tries to say" in my original comment.  With this understanding
I propose the following revised text:

     Using prefix labels, such as underscored service tags, for a
     specific owner name may cause a counter-intuitive effect when the
     owner name is a wildcard name.  For example, _s2._s1.*.example.net.
     is not a wildcard name and cannot be used to return a synthesized
     answer for a query name of _s2._s1.a.example.net.  See Section
     4.5 of RFC4592 for more details.

--
JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 05 Aug 2014 23:23:31 -0700

At Mon, 04 Aug 2014 15:57:52 -0700,

> > sufficiently critical to be a blocking issue.

One other point on something I've noticed while playing with the
ISC BIND 9's implementation of the URI RR: the draft is not clear
about whether an empty string is acceptable for the "target" field of the
RDATA (in Section 4.4. and 4.5).  This corner case actually causes an
odd behavior of BIND 9: it successfully loads the following record:

_http._web.example.com. 3600 IN URI 10 1 ""

but rejects it if it comes from the wire.  The inconsistent
implementation behavior should be fixed anyway (I've reported it to
ISC), but I suspect this is partly because the specification is not
clear enough.  I don't know if an empty string should be accepted (I
don't see a valid reason for allowing it, but there may be some usage
or we may simply want to be lenient), but, either way, the incident of
BIND 9 suggests it should be explicitly described.

--
JINMEI, Tatuya

---

From: Ralf Weber <[email-masked]>
Date: Mon, 11 Aug 2014 05:36:17 +0000

Moin!

> That would be great Ralf - thx.
Ok it is Monday somewhere, although not were I am now, but long flights are ideal for document reviews and I had one today.

It looks like Patrik updated the document already to include some of the comments made earlier, so I am not going to repeat that here. 

In general I like the document and would like to see it move forward and most importantly picked up by browser/application developers.

There was one problem that I encountered while reading and digging into it and it might be because I am old fashioned, but when I looked at the examples I couldn't digest:
	_http._web.example.com.
as an owner name didn't compute for my brain as the draft was talking about SRV, so I was expecting:
	_http._tcp.example.com.
of course section 4.1 mentions that there are two ways to define the ownername (why two - wouldn't one be easier for application developers ?) and describes them by text. Shouldn't there be a reference to the respective IANA registries:
- http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
- http://www.iana.org/assignments/enum-services/enum-services.xhtml
or the RFCs defining them?
- RFC6335
- RFC6117
That would make it easier for application developers to use that and not have to google for the specs.

Another minor thing is that you can easily shoot yourself in the foot with:
	_http._web.example.net.    IN URI 10 1 "http://www.example.com/"
	_http._web.example.com.    IN URI 10 1 "http://www.example.net/"
so maybe there should be a section for domain administrators giving them guidelines
like section 3.2 of the S-NAPTR RFC3958

So long
-Ralf
---
Ralf Weber
Nominum 
www.nominum.com
[email-masked]

---

From: "Christopher LILJENSTOLPE" <[email-masked]>
Date: Mon, 11 Aug 2014 09:08:21 -0700

Thank's Ralf.

	Christopher

On 10 Aug 2014, at 22:36, Ralf Weber wrote:

> Ok it is Monday somewhere, although not were I am now, but long 
> flights are ideal for document reviews and I had one today.
>
> It looks like Patrik updated the document already to include some of 
> the comments made earlier, so I am not going to repeat that here.
>
> In general I like the document and would like to see it move forward 
> and most importantly picked up by browser/application developers.
>
> There was one problem that I encountered while reading and digging 
> into it and it might be because I am old fashioned, but when I looked 
> at the examples I couldn't digest:
> 	_http._web.example.com.
> of course section 4.1 mentions that there are two ways to define the 
> ownername (why two - wouldn't one be easier for application developers 
> ?) and describes them by text. Shouldn't there be a reference to the 
> respective IANA registries:
> - 
> http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml