Subject: [dhcwg] RE: I-D ACTION:draft-daniel-dhc-dhcpv6-ctep-opt-00.txt

From: Soohong Daniel Park <[email-masked]>
Date: Fri, 19 Dec 2003 08:32:04 +0900

> First, I'm not sure whether this option even makes much 
> sense, but I'm 
> not commenting on that at the moment.

We have tried to address why this option is required in introduction
section.

1. Introduction

In the initial deployment of IPv6, the IPv6 nodes may need to 
communicate with the other IPv6 nodes via IPv4 networks.  Configured 
tunnels [3] provide a way to encapsulate the IPv6 packets in IPv4 
packets and tunnel them in the IPv4 network.   
      
This document defines a new option called Configured Tunnel End 
Point by which the DHCPv6 [1] server can notify the client with the 
list of end point of the configured tunnels to the various IPv6 
networks separated by the IPv4 networks. 

Not enough ? or need text improvement ?
Note that this draft is only proposing CTEP option not newly defined
mechanism.

> Important comments:
> ===================
> 
> 1) the spec does not elaborate at all how the tunnel 
> end-point is going to configure the IP address of the node 
> (because the configured tunnel must be configured somehow at 
> the tunnel-end someone as well).  
> This is of course easy if coupled to DHCPv6 address 
> assignment and is done as part of the DHCP process at the 
> server, but otherwise it could be a bit trickier.
> 
> The details are probably outside the scope of this specification, but 
> the complexity must be explicitly spelled out IMHO.

Well, most draft and rfc about dhcp options just address each option not
detail procedure.
However we will consider how we can express it more clear...

> 2) The document talks about "various IPv6 networks which are 
> separated 
> by IPv4 networks", but the tunnel end-point address is still an IPv6 
> address.
> 
> There is a mismatch there; either the endpoint must be v4 
> address, the 
> text must be changed, or this option should provide for the 
> possibility of either v6-in-v4 or v6-in-v4 (or even v4-in-v6) tunnels.

I see.

> 3) The IPR notice is totally wrong:
> 
>   Notice Regarding Intellectual Property Rights
> 
>      See 
> http://www.ietf.org/ietf/IPR/samsung-general-patent04102003.txt
> 
> .. is this meant to say that Samsung has claimed some IPR about this 
> option?  In this case, they must submit a separate IPR disclaimer at 
> www.ietf.org/ipr, the above is not correct.  Moreover, it's 
> incorrect to refer to the claims directly.  Replace this section with:
> 
> Intellectual Property Statement
> 
>    The IETF takes no position regarding the validity or scope of any
>    intellectual property or other rights that might be claimed to
>    pertain to the implementation or use of the technology described in
>    this document or the extent to which any license under such rights
>    might or might not be available; neither does it represent that it
>    has made any effort to identify any such rights. Information on the
>    IETF's procedures with respect to rights in standards-track and
>    standards-related documentation can be found in BCP-11. Copies of
>    claims of rights made available for publication and any 
> assurances of
>    licenses to be made available, or the result of an attempt made to
>    obtain a general license or permission for the use of such
>    proprietary rights by implementors or users of this 
> specification can
>    be obtained from the IETF Secretariat.
> 
>    The IETF invites any interested party to bring to its attention any
>    copyrights, patents or patent applications, or other proprietary
>    rights which may cover technology that may be required to practice
>    this standard. Please address the information to the IETF Executive
>    Director.
> 
> ... and if IPR has been claimed (but not filed yet), also add at the 
> end:
> 
>    The IETF has been notified of intellectual property rights
>    claimed in regard to some or all of the specification contained
>    in this document.  For more information consult the online list
>    of claimed rights.

replaced with 01 version. it is my habitual format.

> Nits:
> =====
> 
>      Destination Prefix: IPv6 Prefix;
> 
> ==> s/IPv6 Prefix;/An IPv6 prefix./

Ok.

>   Acknowledgement
> 
>      Funding for the RFC Editor function is currently provided by the
>      Internet Society. The idea of this specification is based on
>      RFC 2937, September 2000.  Thanks to the DHC Working 
> Group for their
>      time and input into the specification.  In particular, thanks to
>      Pekka Savola, Bernie Volz, Ralph Droms, for their 
> valuable comments
>      on this work.
> 
> ==> this section couples two separate sections, the "RFC-Editor/ISOC" 
> acknowledgement, and acknowledgement about this document.  
> They should 
> be separated, the latter parts put in a section of their own e.g. 
> before the References section.
> 

ditto. 

Regards

Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Pekka Savola <[email-masked]>
Date: Thu, 18 Dec 2003 20:49:34 +0200 (EET)

Hi,

A couple of comments.

On Wed, 17 Dec 2003 [email-masked] wrote:
> 	Title		: Configured Tunnel End Point Option for DHCPv6
> 	Author(s)	: S. Park
> 	Filename	: draft-daniel-dhc-dhcpv6-ctep-opt-00.txt
> 	Pages		: 6
> 	Date		: 2003-12-17
> 	
> For the newly deployed IPv6 networks to interoperate with vastly  
> deployed IPv4 networks, various transition mechanisms had been 
> proposed.  One such mechanism is configured tunnels.  This document 
> provides a mechanism by which the DHCPv6 servers can provide 
> information about the various configured tunnel end points to reach 
> the IPv6 nodes which are separated by IPv4 networks.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-daniel-dhc-dhcpv6-ctep-opt-00.txt

First, I'm not sure whether this option even makes much sense, but I'm 
not commenting on that at the moment.

Important comments:
===================

1) the spec does not elaborate at all how the tunnel end-point is
going to configure the IP address of the node (because the configured
tunnel must be configured somehow at the tunnel-end someone as well).  
This is of course easy if coupled to DHCPv6 address assignment and is
done as part of the DHCP process at the server, but otherwise it could
be a bit trickier.

2) The document talks about "various IPv6 networks which are separated 
by IPv4 networks", but the tunnel end-point address is still an IPv6 
address.

There is a mismatch there; either the endpoint must be v4 address, the 
text must be changed, or this option should provide for the 
possibility of either v6-in-v4 or v6-in-v4 (or even v4-in-v6) tunnels.

     See http://www.ietf.org/ietf/IPR/samsung-general-patent04102003.txt

   claims of rights made available for publication and any assurances of
   proprietary rights by implementors or users of this specification can

Nits:
=====

  Acknowledgement

     Funding for the RFC Editor function is currently provided by the
     Internet Society. The idea of this specification is based on
     RFC 2937, September 2000.  Thanks to the DHC Working Group for their
     time and input into the specification.  In particular, thanks to
     Pekka Savola, Bernie Volz, Ralph Droms, for their valuable comments
     on this work.

==> this section couples two separate sections, the "RFC-Editor/ISOC" 
acknowledgement, and acknowledgement about this document.  They should 
be separated, the latter parts put in a section of their own e.g. 
before the References section.

-- 
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: Soohong Daniel Park <[email-masked]>
Date: Mon, 22 Dec 2003 17:23:25 +0900

> Exactly.. that's why I don't have a hard stance to this at 
> the moment.  
> But if we don't know how it would be used, I have hard time believing 
> we could/should specify the DHCP mechanism in the first place :-)

Ok.

> > Well, most draft and rfc about dhcp options just address each option
> > not detail procedure. However we will consider how we can express it
> > more clear...
> 
> With the above issues, because there is no obvious "CTEP 
> protocol", it 
> might make sense to try to clarify this..

Ditto, we will consider both of them to clarify it.

> I notice that in -01, you removed the IPR section.  I think it would 
> make sense to add the boilerplate, such as I have above, in any case 
> -- that's actually a requirement for submitting a document to the 
> IESG!

It will be added in next version with separated acknowledgement section 
by your previous comment.

Anything else ?

Regards

---

From: Pekka Savola <[email-masked]>
Date: Mon, 22 Dec 2003 10:08:35 +0200 (EET)

Inline on a couple of issues..

> Note that this draft is only proposing CTEP option not newly defined

Exactly.. that's why I don't have a hard stance to this at the moment.  
But if we don't know how it would be used, I have hard time believing 
we could/should specify the DHCP mechanism in the first place :-)
 
> not detail procedure. However we will consider how we can express it

With the above issues, because there is no obvious "CTEP protocol", it 
might make sense to try to clarify this..