Subject: RE: [dnsop] WGLC for "IPv6 Host Configuration of DNS Server Information Approaches"

From: Ralph Droms <[email-masked]>
Date: Wed, 23 Jun 2004 09:06:39 -0400

Yes, RFC 3315 has grandfather exception (we started work on RFC 3315 *well*
before the current guideline on 5 authors was adopted) and lists 6 authors.

I agree that listing Paul as editor and all 8 in an "Authors" section would
be appropriate, with others mentioned as contributors in a separate section
or in the "Acknowledgments".

- Ralph

At 03:49 PM 6/23/2004 +0300, [email-masked] wrote:
>Hi all,
>
>One minor comment:
>
>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]]On Behalf Of ext Ralph Droms
>Sent: 23 June, 2004 15:34
>
> >1. Author list
> >Currently eight people are listed, which are much more than the norm
> >(up to 5) mentioned in Section 2.12 of
> >draft-rfc-editor-rfc2223bis-07.txt
>
>All eight people contributed text and reviewed the entire document.
>Perhaps the author list should be reorganized as one editor,
>with all eight people listed in a "Contributors" section.
>
>JW: There are, e.g., 6 authors listed on the front page of RFC3315, but 
>probably 8 is all too many. So it might be rational to list Paul as editor 
>(ed.) on the front page and the other authors in the "Authors" section. 
>This is what we have done in
>http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-10.txt
>
>In addition to that, we can also mention some Contributors (outside the 
>design team), *if* some people have contributed a lot for the document.
>
>BR,
>         -Juha W.-

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: <[email-masked]>
Date: Wed, 23 Jun 2004 15:49:05 +0300

Hi all,

One minor comment:

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Ralph Droms
Sent: 23 June, 2004 15:34

JW: There are, e.g., 6 authors listed on the front page of RFC3315, but probably 8 is all too many. So it might be rational to list Paul as editor (ed.) on the front page and the other authors in the "Authors" section. This is what we have done in 
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-10.txt

In addition to that, we can also mention some Contributors (outside the design team), *if* some people have contributed a lot for the document.

BR,
	-Juha W.-
.

---

From: David Meyer <[email-masked]>
Date: Wed, 23 Jun 2004 09:40:57 -0700

>> or in the "Acknowledgments".

	My preference would be to list Paul as the editor, have a
	"Contributors" or "Authors" (or even "Contributing
	Authors) section that lists the other authors, and the
	standard two "Acknowledgment(s)" sections (i.e., one for
	folks who made comments on the document, and the other
	recognizing that the funding for the RFC Editor). 

	This would be consistent with current guidelines and
	practice. 

	Dave

.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 24 Jun 2004 15:10:29 +0900

> 	My preference would be to list Paul as the editor, have a

That's fine.

However, are there any possibility that the ID become an RFC?

I think it does not have to be.

If it won't, there is no point care about formalities such as
references, authors, applicability...

Even if it will, it can be determined just before it becoms
an RFC.

						Masataka Ohta

.

---

From: David Meyer <[email-masked]>
Date: Thu, 24 Jun 2004 07:50:44 -0700

>> Even if it will, it can be determined just before it becoms

	Seems to me that we should publish it as informational to
	capture the work that has been done. In any event, we
	should adhere to the publication standards.

	Dave
.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 25 Jun 2004 00:23:35 +0900

David Meyer wrote:

> In any event, we

Sure. Even IDs have their own rules, which is a lot less
strict than those for RFCs, though.

The question is on the publication standard as WHAT?

> 	capture the work that has been done.

That's too bad. :-)

Seriously speaking, then, we should publish all the proposals
as separate RFCs or put more explanations in the draft so that
no additional explanations are neccesary.

Have you really confirmed it with ADs? I'm afraid you have.

						Masataka Ohta

.

---

From: David Meyer <[email-masked]>
Date: Thu, 24 Jun 2004 08:33:03 -0700

>> Have you really confirmed it with ADs? I'm afraid you have.

	Nope, I have not.

	Dave
.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 24 Jun 2004 12:11:06 -0400

I suggest publication of the I-Ds that describe the RA option
and the WKA approach in their current forms as Informational,
followed by the publication of the final version of the
summary doc as Informational.

This plan would archive our results and meet the requirements
for publication.

- Ralph

.

---

From: David Meyer <[email-masked]>
Date: Thu, 24 Jun 2004 09:27:23 -0700

>> >>> Have you really confirmed it with ADs? I'm afraid you have.

	Ralph,

	While I agree with your suggestions (they are consistent
	with mine), I dropped a note to our ADs to ask them what
	they thought (as per Ohta-san's suggestion). I'll report
	back or just copy dnsop@lists into the thread when I see
	a respoonse.

	Dave
.

---

From: Rob Austein <[email-masked]>
Date: Thu, 24 Jun 2004 15:41:32 -0400

At Thu, 24 Jun 2004 07:50:44 -0700, David Meyer wrote:
> >> ...

Disclaimer: our area directors asked the WG to take this approach as a
way of wrapping up our work on this topic, and they can of course
speak for themselves.  The following is just my opinion based on my
understanding of their thinking.

I'm pretty sure that a large part of the point of the exercise is to
publish the document in permanent form.  We were not able to reach
consensus on a way forward, so we're trying to write down what we've
learned about each of the several options during the course of years
of nonterminating discussion, as fairly as possible given that we
don't have consensus on the right approach.

A well-written document of this type serves at least two purposes:

a) It's a briefing document for anybody (eg, the IESG) who might need
   to make informed decisions in this space at some time in the
   future.

b) It offers a relatively constructive way of breaking out of the
   endless discussion loop, by providing a relatively objective
   criterion by which we (or somebody) can determine whether a new
   discussion on this topic is genuinely new or is just the same old
   nonterminating discussion yet again.  In the latter case, a good
   document will at least allow us (or somebody) to cut to the chase
   and ask whether anything has changed since the last time around,
   rather than having to reevolve the whole line of argument, bring a
   new group of participants up to speed, and so forth.

One way of looking at this is that, when an argument can't be resolved
and the participants need to resign themselves to agreeing to
disagree, it is sometimes useful to spell out in some detail precisely
what it is on which they have agreed to disagree. :)
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Thomas Narten <[email-masked]>
Date: Wed, 30 Jun 2004 12:42:51 -0400

FWIW, I largely agree with the points Rob made below.

Also, on the topic of normative references, another aspect of the
discussion is whether a reference is being provided, say "as an
example" of one way one might do something, or whether it is being
provided as _THE_ way of doing something. The former does not need to
be a normatie reference, while the latter more likely is.

I assume that some of the specific IDs being mentioned are really an
example of one general way to do it, but not necessary the _only_
way. Or the idea is so obvious, that a one-paragraph (or sentence?)
description is enough for the reader to understand the basic approach
(i.e, the type of understanding needed for this docuenmt). E.g., for
something like "put the address of a DNS server into an RA", I doubt
one needs to go and read a spec with the details to understand the
general idea enough to talk about its pros and cons.

So, to me, it's not at all clear that some of the related IDs need to
be cited normatively.  Indeed, one woudl hope that this document is
reasonably self-contained.

Thomas

.