Subject: Re: Last Call: draft-cheshire-dnsext-dns-sd-07.txt

From: RJ Atkinson <[email-masked]>
Date: Thu, 18 Nov 2010 07:51:57 -0500

IESG Folks,

  The IETF already has taken MUCH MUCH too long handling this document.  
Each time this I-D gets revised, new and different issues are raised.  
While I am generally OK with the way IETF processes work, 
this document is an exception.  

  Excessive nit-picking is going on with this document, especially 
since it is already globally deployed and clearly works well.
Further, there are multiple interoperable implementations already
deployed, which is an existence proof that the current I-D is
sufficient.  This I-D is quite different from most documents heading
to Proposed Standard, because for most I-Ds interoperability hasn't been 
shown and operational utility in the deployed world hasn't been shown.

  Perfection is NOT what IETF processes require for a Proposed Standard 
RFC.  Please stop seeking or asking for perfection from this I-D.

  Please just publish the document as an RFC **RIGHT NOW**
and AS-IS.  

  Even if IESG folks really think more document editing is needed, 
then still publish it RIGHT NOW and AS-IS.  If folks really want
to see document clarifications, that can be done LATER when the
document advances along the IETF standards-track.

  Now, before the IESG go off and try to point fingers at the author
for taking time between revisions of this I-D, please consider
that the root problem is that the Goal Posts keep being moved back
so that no matter how complete one set of author edits might be,
the document can never get to a state where it is acceptable.

  Sigh.

Yours with Great Frustration,

Ran

---

From: Douglas Otis <[email-masked]>
Date: Fri, 19 Nov 2010 11:30:38 -0800

> the document can never get to a state where it is acceptable.
+1,

-Doug

---

From: Michael StJohns <[email-masked]>
Date: Sun, 21 Nov 2010 22:00:45 -0500

>document advances along the IETF standards-track.

---- 

What Ran said.  In spades.   

This document seems to be of reasonable quality, in a niche that probably won't get working group attention written by authors that seem to have a reasonable amount of knowledge in this space who want to place a set of ideas into the IETF space.  Proposed standards are supposed to be used to do preliminary evaluations of how to do things - they shouldn't be held up simply because they don't address the universe. 

Mike

---

From: [email-masked]
Date: Sun, 21 Nov 2010 19:36:18 -0800 (PST)

> This document seems to be of reasonable quality, in a niche that probably
> won't get working group attention written by authors that seem to have a
> reasonable amount of knowledge in this space who want to place a set of ideas
> into the IETF space.  Proposed standards are supposed to be used to do
> preliminary evaluations of how to do things - they shouldn't be held up simply
> because they don't address the universe.

+1

				Ned

---

From: Doug Barton <[email-masked]>
Date: Sun, 21 Nov 2010 20:44:12 -0800

> shown and operational utility in the deployed world hasn't been shown.

I'm confused. If the standard is already deployed, then what is the rush 
to publish the RFC?

That said, I'm reasonably supportive of the draft moving forward, here 
are a few nits:

1. In Section 4.1, 4th full paragraph, the bit, " (because of the 
limitations of the typing-based user interfaces of that era)" should be 
stricken. It does not add value to the clarity of the text, nor would 
arguing about whether it's correct or not.

2. In that same paragraph, shortly after the above, "from a list of 
choices presented on the screen ..." should be something similar to 
"from a list of choices presented by the user interface ..." One could 
also argue that the "not intended to ever by typed in" should be 
replaced with the appropriate 2119 language.

3. In Section 7, 3rd full paragraph, it says, "conforming to normal DNS 
host name rules: Only lower-case letters ..." The "normal DNS host name 
rules" [citation required] do not permit only lower case letters. I do 
think however that it would be ok to spell out that this protocol 
requires that, like what was done with disallowing names without an 
alphabetic. Note, this is not nitpicking. Often (especially in DNS) we 
see examples of things that people believe to be true printed as fact in 
new RFCs, which lead more people to believe that they are true. Getting 
it right the first time has value.

4. I'm not sure Section 15.2 needs to be in the document at all, 
although I am not formally opposed to its inclusion.

hth,

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Tony Finch <[email-masked]>
Date: Mon, 22 Nov 2010 14:53:44 +0000

On Sun, 21 Nov 2010, Doug Barton wrote:
>
> I'm confused. If the standard is already deployed, then what is the rush to
> publish the RFC?

Why bother with RFCs at all? Why not move to a zero-step standards process
and do all implementation and deployment from Internet Drafts?

It's an embarrassment to the IETF that it wasn't published years ago.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

---

From: Doug Barton <[email-masked]>
Date: Tue, 23 Nov 2010 12:55:34 -0800

> and do all implementation and deployment from Internet Drafts?

Do you really want to have a contest about who can argumentum ad more 
absurdum?

Allow me to amplify my argument more completely. There are already 2 
open source implementations of dns-sd that I'm familiar with, 
mDNSResponder and avahi; in addition to apple's Rendezvous. The OS 
versions are mostly interoperable on the protocol level, but not on the 
binary level. One example that I've been working with lately can be 
found at http://www.avahi.org/ticket/303.

In the theoretical perfect world the reason for producing a spec is so 
that vendors can _create_ interoperable versions of the service. That 
motivation doesn't apply here, so one wonders what the time pressure is.

Regarding the document itself, I have reservations about the quality of 
the document, and whether or not it describes the protocol in sufficient 
detail that someone starting from scratch could develop another 
interoperable version. However I tend to agree with the point of view 
that the world is a better place if we have _a_ spec than if we have 
none, so I'm specifically not asking to re-address all of the concerns 
that have been discussed previously with the document. However the bit 
about lower case labels should definitely be fixed (either by removal, a 
citation, or a clarification that the requirement applies only to this 
protocol). The other nits I pointed out were a good-faith attempt to 
improve the quality of the document without trying to open whole new 
cans of worms.

hth,

Doug

--

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 Nov 2010 13:17:31 -0800

At 12:55 PM -0800 11/23/10, Doug Barton wrote:
>In the theoretical perfect world the reason for producing a spec is so that vendors can _create_ interoperable versions of the service. That motivation doesn't apply here, so one wonders what the time pressure is.

That is "a" reason, not "the" reason. Another is so that vendors can assure interoperability of their systems after they are deployed. Saying "you have to figure out how to interoperate with all other implementations" does not lead to that interoperability. A stable RFC can help greatly, as has been shown repeatedly in the IETF.

--Paul Hoffman, Director
--VPN Consortium

---

From: Doug Barton <[email-masked]>
Date: Tue, 23 Nov 2010 13:32:15 -0800

> That is "a" reason, not "the" reason. Another is so that vendors can assure interoperability of their systems after they are deployed. Saying "you have to figure out how to interoperate with all ot…

That's a motivation for creating the draft, yes. It's not a motivation 
for publishing the RFC before it's ready.

Please understand, I'm not saying "don't publish," I'm not even saying 
"fix _all_ the problems." I'm saying, "Fix the obvious, glaring protocol 
error that has potential to do more damage down the road, and while 
you're at it here are some other minor suggestions to improve the 
quality of the document if you choose to accept them. THEN publish the RFC."

And now I've repeated myself sufficiently so I will spare the list 
members any more responses to ad absurdum replies.

Doug

--