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

From: Ralph Droms <[email-masked]>
Date: Wed, 07 Jul 2004 10:41:13 -0400

I agree with Thomas and Rob that "IPv6 Host Configuration of DNS Server
Information Approaches" should be published as an RFC so that the content of
the document is retained permanently.  I like Thomas' suggestion to
eliminate the dependency on publication of the specific drafts as RFCs by
including a summary description of the basic approach in those drafts and
recommend we make that change to "IPv6 Host Configuration of DNS Server
Information Approaches".

- Ralph

At 12:42 PM 6/30/2004 -0400, Thomas Narten wrote:
>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
>
>Rob Austein <[email-masked]> writes:
>
> > At Thu, 24 Jun 2004 07:50:44 -0700, David Meyer wrote:
> > >
> > > On Thu, Jun 24, 2004 at 03:10:29PM +0900, Masataka Ohta wrote:
> > > >> ...
> > > >> However, are there any possibility that the ID become an RFC?
> > > >>
> > > >> I think it does not have to be.
> > >
> > >     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.
>
> > 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
>.
>dnsop resources:_____________________________________________________
>web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
>mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

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

---

From: David Meyer <[email-masked]>
Date: Wed, 7 Jul 2004 09:09:08 -0700

>> recommend we make that change to "IPv6 Host Configuration of DNS Server

	For the most part, we can declare WG consensus on the
	publication issue (i.e., clearly we want to capture this
	work this time out). 

	Regarding logistics:

	The extended WCLC for this document ends today. What I
	would like the authors to do is as follows:

	(i).	Eliminate normative references as proposed by
		Thomas (http://www.uoregon.edu/~llynch/dnsop/msg02959.html)

	(ii).	Address the comments from Ohta-san
		(http://www.uoregon.edu/~llynch/dnsop/msg02966.html)

	(iii).	Address the comments from Pekka
		(http://www.uoregon.edu/~llynch/dnsop/msg02967.html)

	Once this is done, post a the -02 draft to the I-D
	repository and we'll send it on to our ADs.

	Thanks,

	Dave
.

---

From: David Meyer <[email-masked]>
Date: Wed, 7 Jul 2004 09:40:18 -0700

On Wed, Jul 07, 2004 at 12:19:28PM -0400, Ralph Droms wrote:
>> Jinmei-san contributed some comments 
>> (http://www.uoregon.edu/~llynch/dnsop/msg02915.html) that I think the 
>> authors should address as well.

	Yes, thanks Ralph; sorry for overlooking that one; it
	should definitely be addressed. Authors, just to review
	the current list:

	(i).    Eliminate normative references as proposed by Thomas
		(http://www.uoregon.edu/~llynch/dnsop/msg02959.html)

	(iv).	Address the comments from Jinmei-san
		(http://www.uoregon.edu/~llynch/dnsop/msg02915.html)

	Thanks,

	Dave

>> 
>> - Ralph
>> 
>> At 09:09 AM 7/7/2004 -0700, David Meyer wrote:
.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 07 Jul 2004 12:19:28 -0400

- Ralph

.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 08 Jul 2004 02:12:38 +0900

David Meyer;

>>>authors should address as well.

Can I interpret your statement that it includes follow-ups on
Jinmei-san's contribution should also be addressed?

							Masataka Ohta

.

---

From: David Meyer <[email-masked]>
Date: Wed, 7 Jul 2004 10:22:33 -0700

>> Jinmei-san's contribution should also be addressed?

Ohta-san,

Not exactly sure what you're referring to, but there are issues
in Jimnei-san's email that need to be addressed. Dave
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Jaehoon Jeong <[email-masked]>
Date: Wed, 7 Jul 2004 14:13:14 -0700 (PDT)

Hi Dave,

As I sent an email last week, 
http://www.uoregon.edu/~llynch/dnsop/msg02960.html

I think that I solved (i) and (iv) comments in the new
version:

http://www.adhoc.6ants.net/~paul/publications/ietf-internet-draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt

Therefore, I'll reflect (ii) and (iii) comments on our
02 version and submit it to IETF.
Could David and others check this?

Thanks.

Jaehoon Paul Jeong

--- David Meyer <[email-masked]> wrote:
> that I think the 
> >> >>> Information Approaches" should be published
> as an RFC so that the 
> >> >content of
> >> >>> eliminate the dependency on publication of
> the specific drafts as RFCs 
> >> >by
> >> >>> including a summary description of the basic
> approach in those drafts 
> >> >and
> dnsop
resources:_____________________________________________________
> web user interface:
> http://darkwing.uoregon.edu/~llynch/dnsop.html
> mhonarc archive:
> http://darkwing.uoregon.edu/~llynch/dnsop/index.html
> 

__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 08 Jul 2004 15:49:39 +0900

>>>>> On Wed, 7 Jul 2004 14:13:14 -0700 (PDT), 
>>>>> Jaehoon Jeong <[email-masked]> said:

> Could David and others check this?

(Just to avoid a possible dead-lock)
I'm afraid I won't have enough time to review the pre-submit version
of the draft.  I'll check the submitted version to see if my comments
are properly addressed.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: "Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 8 Jul 2004 17:11:43 +0900

Hi all,

I have reflected (ii) and (iii) on 02 version in addition to (i) and (iv).
You can find the new version in the following link:
http://www.adhoc.6ants.net/~paul/publications/ietf-internet-draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt

If you have another comment or think there is still something resolved, let me know it. 
I'll submit it to the IETF secretariat next Monday.

Thanks.

Paul

----- Original Message ----- 
From: "Jaehoon Jeong" <[email-masked]>
To: "David Meyer" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 08, 2004 6:13 AM
Subject: Re: [dnsop] WGLC for "IPv6 Host Configuration of DNS Server Information Approaches"

.

---

From: David Meyer <[email-masked]>
Date: Thu, 8 Jul 2004 08:36:57 -0700

Thanks Paul,

	Dave

.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 08 Jul 2004 14:39:47 -0400

I have a couple of comments on the revised doc at
http://www.adhoc.6ants.net/~paul/publications/ietf-internet-draft/draft-ietf
-dnsop-ipv6-dns-configuration-02.txt

1. Section 5.1 describes (implicitly) an ISP scenario in which the CPE is a
router and there is a customer network behind the CPE.  However, section
5.1.1 describes a scenario in which the CPE is a host that is directly
connected to the ISP network.  I found the jump between scenarios a little
confusing wihtout more warning that two scenarios were being described.  I
also was confused by the last paragraph in 5.1.1, which (I think) applies to
the CPE/host scenario and not the CPE/router scenario.  If others also find
the existing text less than clear, perhaps the following text would improve
the clarity:

   5.1 ISP Network

      A characteristic of ISP network is that multiple Customer
      Premises Equipment (CPE) devices are connected to IPv6 PE
      (Provider Edge) routers and each PE connects multiple CPE devices
      to the backbone network infrastructure [11].  The CPEs may be
      hosts or routers.

      In the case where the CPE is a router, there is a customer
      network that is connected to the ISP backbone through the CPE.
      Typically, each customer network gets a different IPv6 prefix
      from an IPv6 PE router, but the same RDNSS configuration will be
      distributed.

      This section discusses how the different approaches to
      distributing DNS information are compared in an ISP network.

   5.1.1 RA Option Approach

      When the CPE is a host, the RA option for RDNSS can be used to
      allow the CPE to get RDNSS information as well as /64 prefix
      information for SLAC at the same time when the host is attached
      to a new subnet [8]. Because an IPv6 host must receive at least
      one RA message for stateless address autoconfiguration and router
      configuration, the host could receive RDNSS configuration
      information in that RA without the overhead of an additional
      message exchange.

      When the CPE is a router, the CPE may accept the RDNSS
      information from the RA on the interface connected to the ISP,
      and copy that information into the RAs advertised in the customer
      network.

      This approach is more valuable in the mobile host scenario, in
      which the host must receive at least an RA message for detecting
      a new network, than in other scenarios generally although
      administrator should configure RDNSS information on the routers.
      Secure ND [12] can provide extended security when using RA
      message.

2. I doubt the configuration mechanism described in section 5.2.1 would be
used in practice and I think we should omit section 5.2.1.

3. Regarding section 5.3.1:

At 11:35 AM 7/7/2004 +0300, Pekka Savola wrote:
>RA approach is
>    light-weight especially in wireless environment where RA message is
>    used for IPv6 address autoconfiguration, such as cellular networks.
>
>==> I recall Hesham Soliman saying on IPv6 WG list that the /64 is assigned
>on a cellular node with the v6 PDP context activation?  That is, he argued
>that there's no need for proxy-ND on the cellular node, as the /64 is
>assigned independently.  The only way to interpret AFAICS is that ND is not
>used for SLAAC on those hosts, or we were talking of different things.

What is the current state of the use of ND/RA and SLAC in 3GPP in 3GPP, and
are there any planned extensions to use ND/RA and SLAC in the future?  If
ND/RA and SLAC are not currently used, some of the stated advantages of the
RA option approach should be reconsidered.  That is, if the use of the RA
option requires implementation and deployment of ND/RA where it is not
specified now in 3GPP, deployment of the RA option would seem to require
roughly the same amount of specification, implementation, deployment and
traffic overhead as the DHCPv6 option.

4. I don't think Jinmei-san's issues 6 and 13 from
http://www.uoregon.edu/~llynch/dnsop/msg02915.html were addressed.

- Ralph

.

---

From: "Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 9 Jul 2004 17:37:23 +0900

Hi Ralph,

Your suggestion looks very good.
I need the help of several people:
Juha, Jinmei-san and Ohta-san.

----- Original Message ----- 
From: "Ralph Droms" <[email-masked]>
>       Secure ND [12] can provide extended security when using RA

o Okay, I agree at the above text.
I have reflected this on our new version just now.

> used in practice and I think we should omit section 5.2.1.

o Okay, I'll omit subsection 5.2.1, which was written by myself, from our draft.

> traffic overhead as the DHCPv6 option.

o About this, Juha seems to be able to suggest his opinion.

> http://www.uoregon.edu/~llynch/dnsop/msg02915.html were addressed.

o About issue 6 related to RA approach, I  took Jinmei's second suggestion.
I omitted a word "simple" from the RA text.
The modified text is as follows;
--------------------------------------------------------------------------------------
3.1.1  Advantages

The RA option for RDNSS has a number of advantages.  These include:

 1) The RA option is an extension of existing ND/Autoconfig  mechanisms [3][4].
    No new protocol mechanisms are needed for extending an ND implementation to
    support this option.

--------------------------------------------------------------------------------------

o About issue 13 related to WKA approach,
the reorganization of the text can be done by Ohta-san in order to harmonize with other approaches.

After I listen to others' text contribution or opinion, I'll reflect them on 02 version and submit it.

Thanks for your work in advance.

Paul

.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 09 Jul 2004 22:39:09 +0900

>>>>> On Fri, 9 Jul 2004 17:37:23 +0900, 
>>>>> "Jaehoon Paul Jeong" <[email-masked]> said:

> Juha, Jinmei-san and Ohta-san.

I'll try to find time to review it within 24 hours, but if I miss the
deadline, please just go ahead (though I reserve the right to make
comments later:-).

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sat, 10 Jul 2004 18:03:00 +0900

> Juha, Jinmei-san and Ohta-san.

I guess you need my help for the last one, so I'll concentrate on that
part.

This does not address the first part of my concern: the meaning of
"(no) new protocol mechanisms" is vague (and can be unfair).
According to the response from Bob (Hinden), it should mean:

> The intent of "no new protocol mechanisms" text was it was only necessary 
> to define a new option, not change the ND protocol.  Just the same as if 
> one was to define a new DHCP option, the protocol mechanisms of the DHCP do 
> not need to change.  Does that help?

(see also
http://darkwing.uoregon.edu/~llynch/dnsop/msg02952.html
as a reference)

With this clarification, the text should rather be:

  1) The RA option is an extension of existing ND/Autoconfig
     mechanisms [3][4], and does not require a change in the base ND
     protocol.

But we then need to face the fairness issue I pointed out.  This
"advantage" also applies to the other mechanisms.  Actually, we don't
even need any new options for the DHCPv6 and WKA approaches.  So, to
be fair, I'd recommend either

A: just remove this advantage because this property is common for all
   the approaches.  (I prefer this option)

or

B: make similar points for the other approaches as well.  For example,
   revise item 6 of Section 3.2.1

   from

   6) The specification for configuration of DNS recursive name 
   servers through DHCPv6 is available as an RFC. 

   to

   6) The specification for configuration of DNS recursive name 
   servers through DHCPv6 is available as an RFC.  No new protocol
   extensions such as new options are necessary.

> the reorganization of the text can be done by Ohta-san in order to harmonize with other approaches.

I guess you requested Ohta-san's help here, but if I need to say
something as the one who made the original comment, I don't think this
is a show-stopper while the change would make the document more
reader-friendly.  In fact, I noted in my original comment that:

> 13. Section 3.3 (Well-known Anycast Addresses)

> Readers would expect the same organization for this section as that
> for Sections 3.1 and 3.2: general description, advantages,
> disadvantages, and observation.  It might be helpful for readers if
> Section 3.3 can use the same organization.

> (This is just a comment, and not a requirement for advancing the
> document)

					JINMEI, Tatuya

---

From: "Jaehoon Paul Jeong" <[email-masked]>
Date: Mon, 12 Jul 2004 16:17:21 +0900

Hi Jinmei-san,
Look at the inlines.

----- Original Message ----- 
From: <JINMEI Tatuya>
Sent: Saturday, July 10, 2004 6:03 PM
>    extensions such as new options are necessary.

The second alternative looks good because this feature is an advantage for each approach.
For the fairness, I'll include the feature in each approach's advantage.

> reader-friendly.  In fact, I noted in my original comment that:

I expect Ohta-san to send his new text to me soon.
As soon as I receive it, I'll recompile our draft and submit it to the IETF secretariat.

Thanks again for your contribution.

Paul

.