Subject: [dhcwg] REMINDER: dhc WG last call on dhc WG last call on draft-ietf-dhc-dna-ipv4-07.txt

From: Ralph Droms <[email-masked]>
Date: Mon, 21 Jun 2004 17:56:52 -0400

This message announces a WG last call on "Detection of Network
Attachment (DNA) in IPv4" <draft-ietf-dhc-dna-ipv4-07.txt>.  The last
call will conclude at 5PM EDT on 2004-06-25.

Please respond to this WG last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.

draft-ietf-dhc-dna-ipv4-07.txt addresses the problem of detecting
attachment to an IPv4 network.  The time required to detect movement
(or lack of movement) between subnets, and to obtain (or continue to
use) a valid IPv4 address may be significant as a fraction of the
total delay in moving between points of attachment.  This
specification synthesizes experience garnered over the years in the
deployment of hosts supporting ARP, DHCP and IPv4 Link-Local
addresses, in order to optimize detection of network attachment by
mobile hosts.This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-07.txt

- Ralph Droms 

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

---

From: Soohong Daniel Park <[email-masked]>
Date: Wed, 23 Jun 2004 10:15:46 +0900

This draft looks good and I second it.

My comments are as below;

[1] Category is correct as PS ? I think BCP would be better.

[2] 1. Introduction, 
>This document concerns the interaction of mechanisms used by IPv4
>protocol stacks.  Network attachment detection and its interaction
>with interface configuration is considered elsewhere, for example in
>Neighbor Discovery for IPv6 [RFC2461], IPv6 Stateless Address
>Autoconfiguration [RFC2462] and Mobility Support in IPv6 [MIPv6].

I am not sure why this draft refers rfc2461,2462 and even MIPv6.
This draft is strictly bound to IPv4 especially DHCPv4 and IPv4LL 
and something like that, so I think we don't need to refer IPv6 protocol.

[3] 2.3 IPv4 Address Acquisition
To obtain its IPv4 address quickly, Rapid Commit option of DHCPv4
can be used for optimizing detection of network attachment on mobile
hosts. With my experience, it's stable and fast than current
mechanism, thus if feasible, you can indicate this utility at this
section. 
http://www.ietf.org/internet-drafts/draft-ietf-dhc-rapid-commit-opt-03.txt
(I updated and published it as 04 version yesterday)

For reference, I cite a result of comparison between them.
(It was tested on both wired and wireless though testbed was so simple)

===========================================
Item				Mean value		Standard deviation
===========================================
Time delay
(sec.)	       Existing	0.051269	0.002349
                   New		0.001541	0.001213
===========================================
Packet loss
(packet)       Existing	417.04		53.10322
                   New		366.02		32.55092
===========================================

Hope this helps

Regards

- Daniel (Soohong Daniel Park)
- Mobile Platform Lab. Samsung Electronics.

---

From: Soohong Daniel Park <[email-masked]>
Date: Wed, 23 Jun 2004 12:51:08 +0900

[2] 1. Introduction, 

Hope this helps

---

From: Greg Daley <[email-masked]>
Date: Thu, 24 Jun 2004 12:48:59 +1000

Hi Daniel,

Here are some opinions.

> [1] Category is correct as PS ? I think BCP would be better.

I'm actually interested in this as well, but for a
different reason.

> (I updated and published it as 04 version yesterday)

If the document is a BCP, then it cannot really reference
alternative procedures which aren't RFC's.

Also, even if the document is PS, there would be some
conflict as to whether the rapid commit would need to
be normatively referenced.

A normative reference to another draft which is still to
go through IESG review is probably worth avoiding at this stage.

The rapid commit will be able to indicate the benefits
itself. People will use it in addition to the DNAv4 procedures
as it is a compatible optimization.

Greg

---

From: Soohong Daniel Park <[email-masked]>
Date: Thu, 24 Jun 2004 13:03:51 +0900

Hi Greg.

> I'm actually interested in this as well, but for a

um..I am wondering what a different reason is.

>alternative procedures which aren't RFC's.

I know of course, thus I said *for reference* in
the previous mail. Also if required, it can be solved
in RFC queue prior to publishing RFC. Anyway
I don't have a hard stance at this time.

>as it is a compatible optimization.

That's what I am saying...^.^

Regards.

---

From: Greg Daley <[email-masked]>
Date: Thu, 24 Jun 2004 15:57:37 +1000

> um..I am wondering what a different reason is.
Well, we've got a charter item in DNA WG for DNA
for IPv6.

This is basically providing similar sets of functions
to DNAv4: no new messages, adjustments of how a host
interprets the information received.

This is currently being listed as BCP for DNAv6.

An indication that the DNAv4 work is standards work
may impact on the choices made for DNA WG.

Greg

---

From: Erik Guttman <[email-masked]>
Date: Wed, 23 Jun 2004 17:09:57 +0200 (CEST)

I have reviewed the document.  I paid particular attention to the
resolution of the issues I suggested (13-17).  Satisfactory resolutions
for each of these have been added to draft 07.  I recommend this document
be advanced.

Regards,

Erik