Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)
Note: This ballot was opened for revision 01 and is now closed.
(Ted Hardie) Yes
(Allison Mankin) Yes
(Steven Bellovin) (was Discuss) No Objection
(Margaret Cullen) No Objection
(Bill Fenner) No Objection
Comment (2004-05-27 for -** No value found for 'p.get_dochistory.rev' **)
Possible typo in the ABNF - ; ALPHANUM = <UNDEFINED> iana-registered-protocol = ALPHA *31ALPHANUM ; line 7 should this be ALPHANUMSYM like the others?
(Scott Hollenbeck) No Objection
(Russ Housley) (was Discuss) No Objection
This document has some very long lines. The author should come up with a presentation for this information that fits the line length limits.
(David Kessens) No Objection
(Thomas Narten) (was Discuss) No Objection
Nits/Editorial of a named application service. The application client MUST select one protocol to choose The PREF field of the NAPTR RRs may be used by the domain administrator to The first DNS query is for the NAPTR RRs Missing "."? > identify the server as being authoritative for the original taret s/taret/target/ > 6.5.2 Application Protocols > > The protocol identifiers that are valid for the "app-protocol" > production are any standard, registered protocols [IANA registry > again -- is this the list of well known/registered ports?]. It would be good to be more clar about what "registered protocols" are. Can you name the "name space" within IANA that is meant here? Oh, I guess you mean to refer to the IANA registry that _this_ document creates. Right? This could be made more clear (think about how you want this worded in the final RFC).