Subject: chairs and charter

From: Randy Bush <[email-masked]>
Date: Fri, 7 Mar 2003 10:29:14 -0800

after creating this wg, providing substance and focus, and chairing
it for a few years, liman and ray wish to rest on the laurels of
the wg's successes.  also, they're each swamped with daytime work.

dave meyer and rob austein have agreed to co-chair dnsop, lead
drafting of a charter revision, etc.  dave brings deep ops view and
ietf process experience, and rob dns and ietf depth.  i think they
should make an excellent team and hope you will support them,

i also hope that dave and rob can push the dnsop-ng vision in time
for the sf meeting, with focus on things such as dnssec deployment,
v4/v6 co-existence, dns discovery, ...  so expect a flurry of
change between now and sf.

and remember to buy liman and ray a beer in sf for their long
stretch of getting this wg going and significant progress.

randy

#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Lars-Johan Liman <[email-masked]>
Date: 10 Mar 2003 16:55:00 +0100

> randy

Mmm. That's what I call a kick in the groin, giving me less than a
week to go from a private announcement "you are going to be replaced",
to a public one, not even letting me announce it to the list myself to
the working gorup i chair.

And all this just as I had pursuaded my manager to realize what kind
of resources this will take, and allow me spend 1 working day/week
with IETF related work (which I was actually promised when I started
here, but which hasn't happend due to general downfall of the Internet
business, and other reality-related issues), and to the fact that we
ended up tied up in a development contract with the national Swedish
TLD domain name holder, and various operational contracts. No we're
out of the .SE TLD development contracts, and we've hired more
operational staff, and things have taken a turn in the right
direction.

So consider this my last-minute announcement to the effect that I will
continue to candidate as chair this working group if you want to have
me. I will of course step down, if there are voices for my
resignation.

I'll open up an agenda point for the floor at the IETF meeting, so you
can make your voices heard.

				Best regards,
				  /Lars-Johan Liman

---

From: Randy Bush <[email-masked]>
Date: Mon, 10 Mar 2003 08:04:16 -0800

shit!  i got your reply a week ago, nothing since, and did not realize
that you were changing course or i misunderstood.  deep apologies.  i
have to head for the <bleep>ing airport.  but let's plan to talk voice
tuesday (i will be in tz=-5).  let's try to get rob and dave to join.

sigh

randy

---

From: Paul Vixie <[email-masked]>
Date: 10 Mar 2003 17:36:05 +0000

[email-masked] (Lars-Johan Liman) writes:

> ...
> me. I will of course step down, if there are voices for my resignation.

here's a voice for your continuance.

> can make your voices heard.

too late.
-- 
Paul Vixie

---

From: John Schnizlein <[email-masked]>
Date: Mon, 10 Mar 2003 13:02:59 -0500

>here's a voice for your continuance.

And another.

John

---

From: "John M. Brown" <[email-masked]>
Date: Mon, 10 Mar 2003 18:24:42 -0700

and another voice for Liman's continuance....

john brown

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Paul Vixie
> Sent: Monday, March 10, 2003 10:36 AM
> To: [email-masked]
> Subject: Re: chairs and charter
> 
>

---

From: Lars-Johan Liman <[email-masked]>
Date: 11 Mar 2003 09:48:29 +0100

> tuesday (i will be in tz=-5).  let's try to get rob and dave to join.

Having spent a sleepless night mulling over this, I've realized a few
more things, and a voice discussion would be good.

My numbers in a separate message.

And, apologies for my rough language in the previous message. That was
not called for.

				Cheers,
				  /Liman

---

From: Brad Knowles <[email-masked]>
Date: Wed, 12 Mar 2003 00:38:11 +0100

And another.

-- 
Brad Knowles, <[email-masked]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Mar 2003 12:11:30 +0200 (EET)

> change between now and sf.

I'd like to see DNS discovery issues on the agenda for the meeting (I
couldn't find whether agenda had already been posted, so I'm not sure if
there's time etc.etc.).

In particular, one could discuss:
 - the generic model of reserved addresses for DNS discovery
 - models and applicability of IPv6-specific DNS discovery in conjunction 
with stateless address autoconfiguration

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Sun, 16 Mar 2003 19:53:18 +0200 (EET)

On 15 Mar 2003, Johan Ihren wrote:
> I'm all in favour of talking about DNS discovery, that's a worthwhile
> subject. However, to my mind the real issue is discovery mechanisms in
> general, not only DNS. As long as we stay micro focused on "dns
> discovery", "foo discovery" and "bar discovery" I fear that we'll keep
> on finding individual mechanisms rather than a generic method.
> 
> Unfortunately the more generic discussion doesn't seem well suited for
> DNSOP.

Indeed, this is a worry.

However, DNS could be argued to be sufficiently special.

For instance, I have run DHCPv4 here in the IETF network basically just to
find the DNS servers.  If I wanted to run in IPv6-only operation, I'd have
to configure the server manually, run DHCPv6 or whatever.  I'm not at all
interested in configuring search paths, NTP, Foo, or Bar in "visiting"  
networks.

---

From: Johan Ihren <[email-masked]>
Date: 15 Mar 2003 08:21:03 +0100

Johan Ihrén
Autonomica

---

From: Johan Ihren <[email-masked]>
Date: 16 Mar 2003 22:10:39 +0100

> interested in configuring search paths, NTP, Foo, or Bar in "visiting"  

That you're not interested in configuring ntp, foo and bar is fine.
But that is in no way an argument for a multitude of discovery
mechanisms. I still think that *one* generic discovery mechanism is
very much better than several.

Much better that you just configure your client not to import the
stuff you don't care about than inventing more mechanisms to support
every form of granularity that people can invent.

Let's keep it simple. 

Johan

---

From: Tim Chown <[email-masked]>
Date: Mon, 17 Mar 2003 06:06:20 +0000

> every form of granularity that people can invent.

Hi Johan,

I agree with the keep it simple princple in general, but in this case I'm 
not convincved.  DNS is a special case, as Pekka explained.  I think that, 
for example, advertising DNS by RA's in IPv6 offers a veru useful "missing 
piece" in the stateless autoconfiguration puzzle.  To require the presence 
of DHCPv6 for DNS discovery in IPv6 seems wrong.  I have no objection to it 
as *a* method, but in the scenario of my home network I'd be quite happy
to run without statelessly configuring clients needing to use DHCP to get
the DNS info.

I think many people accept that the well-known site-local method will die 
because of the issues with site-locals, thus leaving only DHCPv6 unless 
something like RA piggybacks is defined for the stateless scenario.

It would be interesting to review discovery methods in different protocols
(including transition protocols), as a variety of methods are already used
including well-known (site-local) addresses, link-local multicast, well-known
names, DHCPv6, SLP, anycast, etc.  The more we have, the more that needs
to be supported (which in itself becomes an argument to keep the stateless
picture simpler by not requiring DHCPv6 presence).

Tim

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 17 Mar 2003 18:41:09 +0859 ()

Tim;

> I think that, 
> piece" in the stateless autoconfiguration puzzle.

No, not at all.

> I have no objection to it 

The issue is merely that "stateless" approach is hopeless only to cause
a lot of problems when its application is seriously considered.

It is a problem of IPng group to remove "stateless" approach from IPv6
specification.

							Masataka Ohta

---

From: Tim Chown <[email-masked]>
Date: Tue, 18 Mar 2003 02:46:24 +0000

> It is a problem of IPng group to remove "stateless" approach from IPv6

Oh, nothing radical then...

---

From: Johan Ihren <[email-masked]>
Date: 18 Mar 2003 05:40:02 +0100

Tim Chown <[email-masked]> writes:

Tim,

> I agree with the keep it simple princple in general, but in this
> case I'm not convincved.  DNS is a special case, as Pekka explained.
> I think that, for example, advertising DNS by RA's in IPv6 offers a
> veru useful "missing piece" in the stateless autoconfiguration
> puzzle.  To require the presence of DHCPv6 for DNS discovery in IPv6
> seems wrong.  I have no objection to it as *a* method, but in the

I think your statement of "as *a* method" perfectly summarizes the
reason for my objection to having multiple discovery mechanisms.

Keeping the door open to multiple mechanisms to discover the same
thing is just plain wrong. Sorry.

Someone has to implement these things, burn code into proms and ship
products. That process is not simplified by having several alternate
mechanisms available. From an implementation point of view it would be
much preferable to have just one and be done with it. And if you only
have one, it had better be somewhat more generic than RA.

> scenario of my home network I'd be quite happy to run without
> statelessly configuring clients needing to use DHCP to get the DNS
> info.

With all due respect, I think this is short sighted. Today you almost
cannot buy a DSL router for home use that doesn't have an integrated
DHCP server, among all kinds of other strange stuff. To make a future
equivalents of such devices also talk DHCPv6 is clearly possible.

"Wait", you say, "that router is the device that sends out the
RA". Sure it is. And it can also do DHCPv6.

The more interesting issue that I think we should focus on is *how do
you configure* the device to make correct announcements of where the
recursive nameservice is located. And if we stay with the DSL-
whatever-in-a-home example it seems rather clear that that
configuration issue is exactly the same regardless of whether the
stuff is sent out piggybacked as an RA option or via DHCPv6.

> I think many people accept that the well-known site-local method
> will die because of the issues with site-locals, thus leaving only
> DHCPv6 unless something like RA piggybacks is defined for the
> stateless scenario.

I agree.

> It would be interesting to review discovery methods in different
> protocols (including transition protocols), as a variety of methods
> are already used including well-known (site-local) addresses,
> link-local multicast, well-known names, DHCPv6, SLP, anycast, etc.
> The more we have, the more that needs to be supported (which in
> itself becomes an argument to keep the stateless picture simpler by
> not requiring DHCPv6 presence).

It is always more difficult to throw things away than to add new
stuff. This is a universal problem and usually it leads to overly
complex collections of not fully orthogonal pieces. Such is life, and
that's another reason for software upgrades.

But in the particular case of *discovery* mechanisms I still think
that this is a mistake that needs to be rectified. 

And the reason is that discovery is part of "bootstrapping" a device
to become a first class member of the network. "Software upgrades"
take place after bootstrapping so mucking with discovery will always
be extremely expensive for installed devices. Not to mention that when
the device and the infrastructure don't share the same view on
discovery things will break in ugly ways.

Regards,

Johan Ihrén
Autonomica

---

From: Tim Chown <[email-masked]>
Date: Tue, 18 Mar 2003 21:38:15 +0000

Hi Johan,

I think we're talking about two mechanisms, not "several", one geared
to stateful environments (which is fine, and of course necessary), the 
other to stateless environments.   

The RA method for stateless (for which a draft was proposed last year,
though I think it expired) is the only stateless method on (or near :)
to the table now, but the question is more general: do we want to mandate
a DHCPv6 server to be present to have DNS functionality in statelessly
configuring IPv6 nodes?

> equivalents of such devices also talk DHCPv6 is clearly possible.

Sure.  But that's then still a lot of DHCP code for just DNS discovery
(if DNS discovery is all that is required of the DHCPv6 server, and the
node doesn't need other DHCPv6 options).

Also, often the home DSL router can perform the resolver function.  This
throws up a possibility for such home devices for the RA message having an
option to say "use me for DNS", which would be simpler, but only apply
to a subset of cases.

> stuff is sent out piggybacked as an RA option or via DHCPv6.

Agreed.   The "use me" option above would circumvent that need (for that
specific case), but I accept it's still extra code.
 
> that this is a mistake that needs to be rectified. 

I appreciate people may be concerend of creeping featurism, but I think
it's a fairly clear minimum requirement for a node to have basic stateless 
autoconf and DNS config (ref. Jim's comment to the list on DNS "MUST").
Maybe others don't see such a scenario being common.
 
Maybe a node will also want other DHCPv6 options, like preferred prefix,
time, NIS, whatever, but these are beyond the basic need for connectivity
and name resolution.

> discovery things will break in ugly ways.

Appreciated.

If dnsop doesn't want to consider this item, so be it, but it has, as I
understand it, been punted from the IPv6 Charter to dnsop (rightly :) so
I feel it's worth pressing the question at this point.  

Tim

---

From: Johan Ihren <[email-masked]>
Date: 20 Mar 2003 01:15:20 +0100

Hi Tim,

> I think we're talking about two mechanisms, not "several", one
> geared to stateful environments (which is fine, and of course
> necessary), the other to stateless environments.

True.

> The RA method for stateless (for which a draft was proposed last
> year, though I think it expired) is the only stateless method on (or
> near :) to the table now, but the question is more general: do we
> want to mandate a DHCPv6 server to be present to have DNS
> functionality in statelessly configuring IPv6 nodes?
> 
> Sure.  But that's then still a lot of DHCP code for just DNS
> discovery (if DNS discovery is all that is required of the DHCPv6
> server, and the node doesn't need other DHCPv6 options).

I'm sure I'll get flamed for this.

To my mind that is actually almost a detail. That cost in the server
end (of course it is a cost to build a DHCPv6 server instead of not
doing that) is compensated by a simpler structure in the client end
(not having to decide what protocols to implement and, even worse,
decide how to to do failover between alternatives). 

There is a cost associated with having alternatives. And that cost is
in many cases at least as high as having just one, albeit more
complex, alternative.

> Also, often the home DSL router can perform the resolver function.
> This throws up a possibility for such home devices for the RA
> message having an option to say "use me for DNS", which would be
> simpler, but only apply to a subset of cases.

>> The more interesting issue that I think we should focus on is *how
>> do you configure* the device to make correct announcements of where
>> the recursive nameservice is located. And if we stay with the DSL-

> Agreed.  The "use me" option above would circumvent that need (for
> that specific case), but I accept it's still extra code.
>  
> I appreciate people may be concerend of creeping featurism, but I
> think it's a fairly clear minimum requirement for a node to have
> basic stateless autoconf and DNS config (ref. Jim's comment to the
> list on DNS "MUST").  Maybe others don't see such a scenario being
> common.

When this was on the table a number of years ago the outcome as far as
I understand was that what was needed was an IP address and a default
route. No nameservice.

Maybe some years from now the answer will again have changed and with
the wrong design choice here that will be unnecessarily difficult to
cater to.

> Maybe a node will also want other DHCPv6 options, like preferred
> prefix, time, NIS, whatever, but these are beyond the basic need for
> connectivity and name resolution.

I think you should add "what is my name" to the set of stuff that is
part of the basic set. Not knowing your own name has a tendency of
being a source of trouble.

>> And the reason is that discovery is part of "bootstrapping" a
>> device to become a first class member of the network. "Software
>> upgrades" take place after bootstrapping so mucking with discovery
>> will always be extremely expensive for installed devices. Not to
>> mention that when the device and the infrastructure don't share the
>> same view on discovery things will break in ugly ways.
> 
> Appreciated.
> 
> If dnsop doesn't want to consider this item, so be it, but it has,
> as I understand it, been punted from the IPv6 Charter to dnsop
> (rightly :) so I feel it's worth pressing the question at this
> point.

Absolutely. I'm not arguing against fixing this. I'm just arguing
against fixing it the wrong way. And I fully admit that I don't *know*
which way is wrong here and now.

Some years ago a decision not to depend on DHCPv6 was made (as far as
I understand, I wasn't present at that time). And it didn't work out
too well, which is why we're having this discussion. My worry is that
if we again decide that DHCPv6 isn't needed because we *only* have to
fix the *special* case of name resolution then we may end up here
again and lose even more time.

Johan