Skip to main content

The Uniform Resource Identifier (URI) DNS Resource Record
draft-faltstrom-uri-14

Yes

(Pete Resnick)

No Objection

(Alia Atlas)
(Benoît Claise)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Richard Barnes)
(Spencer Dawkins)
(Ted Lemon)

Note: This ballot was opened for revision 13 and is now closed.

Barry Leiba Former IESG member
(was Discuss) Yes
Yes (2015-03-25) Unknown
Version -14 addresses all my comments; thanks very much.
Pete Resnick Former IESG member
Yes
Yes (for -13) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2015-03-09 for -13) Unknown
You don't need to expand DNS and URI as they are well known.

On the other hand, you do need to expand:
DDDS
NAPTR                           

---

I am uneasy with your use of 2119 language in this document...


The use of "MUST" in section 2 is inappropriate. It would be better to
say "must" and even better to say "need to". And the use of "MUST NOT"
would read better as "is not".



Since this is an Informational document, the 2119 language in 4.2 is 
out of place.  Are you defining new procedures, quoting procedures
documented elsewhere, or making commentary? I think you could write...

   The priority of the target URI in this RR.  Its range is 0-65535.  A
   client attempts to contact the URI with the lowest-numbered priority
   it can reach; URIs with the same priority are tried in the order 
   defined by the weight field.



Section 4.4's use of "MUST" is more debatable. 

   The Target MUST NOT be empty ("").

Where does this rule come from and why? Is it a specific case of an
existing rule, or are you defining something new? 


And so on...
Alia Atlas Former IESG member
No Objection
No Objection (for -13) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (for -13) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (for -13) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -13) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -13) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2015-03-10 for -13) Unknown
This looks fine, I just found a typo in the security considerations section:

    will effectlyely lead to a downgrade attack.
s/effectlyely/effectively/
Martin Stiemerling Former IESG member
No Objection
No Objection (for -13) Unknown

                            
Richard Barnes Former IESG member
No Objection
No Objection (for -13) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -13) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2015-03-11 for -13) Unknown
- General: Would it be ok or not of if _ftp._tcp had a value
with an sftp URI?  Could you state any rules for a) how
secure vs. insecure should be handled in the QNAME and b) if
there are security match/mismatch expectations between the
QNAME and the value of the RR?  

- s2: This reminds me of .well-known URIs that re-direct. I
know we're not focusing on the web though (but you did bring
it up) but the same effect for http can now be achieved that
way and it might be good to note

- 4.1: "DNS labels that occur in nature" - I love it:-)

- 5.1: I wondered what sftp would be here? would it be
_sftp._tcp or _ftp._ssh or _ftp._ssh._tcp or what?
Ted Lemon Former IESG member
No Objection
No Objection (for -13) Unknown