RE: [DNA] DNA Goals response

["Bound, Jim" <jim.bound@hp.com>]

JinHyeock,

I know what a link and AP is and I await WG consensus I believe that is
close.  No other comments on that.

> Kindly find my presentation at 58th IETF meeting in which I 
> tried to clarify the notion of link there. 
>  
> http://www.ctie.monash.edu.au/dna/DNAv6JH58.ppt

Thanks I had this.

> 2. Analysis parts    
> Goals drafts contains the analysis related parts, Sec 2 DNA 
> in Existing IPv6 Systems and Sec 3 Problems in DNA. I 
> understand that you suggest to cut them down.  
> 
> It was our intention to present the current state of art of 
> DNA, without evaluating the pro and con of the possible 
> solutions. We aimed to describe the limitation of the 
> existing IPv6 to clarify the Goals.

The limitations in your opinion should be a separate draft is my main
objection.  This way we discuss and get consensus on that specifically
and I believe that would be useful to the WG and not interfere with
getting consensus on the goals.  I for one do not agree with all of your
assumptions about IPv6 and have said so all along.  Separate the two and
lets not put your views in the goals doc and cause it to hold up
consensus on the goals.
 
> 
> We thought that it would be useful for Goals draft to include 
> some analysis but you seemed to disagree. Right? Kindly 
> confirm yourself.

I NEVER said that please do not put words in my mail.  I never said no
analysis is not required I said stating what is wrong with IPv6 in an
IETF permanent document (in other words before) is inappropriate in a
goals document.  It is to important for documentation and this WG
process.
 
> 
> If so, I will start a thread about this and in case WG decide 
> to remove the analysis parts, we will remove them or generate 
> a separate draft. 

Yes but lets not call it analysis.

> 
> I wish we take a pragmatic approach, (rather than dogmatic). 
> We'd better make a decision based on whether it would help 
> Goals draft to include analysis part or not. 

What analysis is the key not analysis.  I think my mail above makes
clear what I consider inappropriate analysis.

>  
> Also kindly find my inline comments. 
> 
> > Except for some intro section and section 4 this entire 
> document does 
> > not represent goals but analysis.  I think they should be two 
> > different docs and two different thread debates. Comments 
> to the point 
> > in line.  I am less concerned in this response with the 
> correctness of 
> > statements but more about the layout of the goals document 
> and what I 
> > think we need a current analysis document both of which require 
> > different discussions and thoughts.
> 
> I see your point. 
>  
> > > Abstract
> > > 
> > >    At the time a host establishes a new link-layer 
> connection, it may or
> > >    may not have a valid IP configuration for Internet 
> connectivity.  The
> > >    host may check for link change, i.e.  determine 
> whether a link change
> > >    has occurred, and then, based on the result, it can 
> automatically
> > >    decide whether its IP configuration is still valid or 
> not.  While
> > >    checking for link change, the host may also collect necessary
> > >    information to initiate a new IP configuration for the 
> case that the
> > >    IP subnet has changed.  In this memo, this procedure is called
> > > 
> > >    Detecting Network Attachment (DNA).
> > > 
> > >    Rapid attachment detection is required when a host has 
> on-going data
> > >    traffic.  Current DNA schemes are inadequate to 
> support real-time
> > >    applications.  The existing procedures for advertising network
> > >    information incur reception delays and do not provide enough
> > >    information to properly determine the identity of links.  For
> > >    to-be-defined, efficient DNA schemes, a way to 
> correctly represent a
> > >    link change, a complete and consistent procedure for network
> > >    information advertisement and a rapid delivery of the 
> advertisements
> > >    will be necessary.
> > 
> > I would just keep the first paragraph for the abstract.
> 
> The second part is more about analysis. In case WG decide to 
> do away with the analysis, we will make a modification accordingly. 

I am trying to follow IETF status quo and rules of engagement.  I don't
know of a single document that has two paragraphs in the IETF for the
abstract?  If I am wrong I simply have not seen it and review many
documents in the IETF.

> 
> > > 1.  Introduction
> > > 
> > >    When a host has established a new link-layer 
> connection,  it can send
> > >    and receive some IP packets at the link, particularly 
> those used for
> > >    configuration.  On the other hand, the host has full Internet
> > >    connectivity only when it is able to exchange packets 
> with arbitrary
> > >    destinations.
> > > 
> > >    When a link-layer connection is established or 
> re-established, the
> > >    host doesn't know whether its existing IP 
> configuration is still
> > >    valid for Internet connectivity.  A subnet change 
> might have occurred
> > >    when the host changed its attachment point.
> > > 
> > >    In practice, the host doesn't know which of its 
> addresses are valid
> > >    on the newly attached link.  A host knows neither if 
> its existing
> > >    default router is on this link, nor whether its neighbor cache
> > >    entries are valid.  Correct configuration of each of 
> these components
> > >    are necessary in order to send packets on and off the link.
> > 
> > Add during "movement to new link" to the above is input.  
> 
> The host only changes it's link-layer connection. It's not 
> certain whether it moves to a new link or not yet. 

Hmm terminology issue.  If it changes its link connection it either has
moved or on two different links. Hearing both links is an interesting
property of seamless mobility and requires analysis as a goal for this
WG so I now suggest adding that as a goal.

>  
> > >    While other information for IP connectivity (such as DNS server
> > >    configuration) is also important, obtaining most of 
> such information
> > >    depends on the determination of correct global 
> addressing and valid
> > >    default router configuration.
> > 
> > I think the paragraph above needs work.  I could find all this on a 
> > link with no router at all. Or clarification.
> 
> The above is not clear to me. You could find all 'WHAT'? 

DNS server, DHCP server, SL servers, X.500, PKI server etc.

> 
> > >    Hence, to determine the need of a further configuration, a 
> > >    host needs to check at least that:
> > > 
> > >     1) Whether it knows a (partially) reachable default router.
> > 
> > I don't think this is true unless you add on a new link.
> 
> A host is under uncertainty. It doesn't know whether a link 
> change happened or not. 

This is where we do not agree and we can agree to disagree.  Point of
further discussion for sure.

>  
> > >     2) Whether it possesses a valid IP address.
> > 
> > If it is on a new link it does not and it is on a new link then it 
> > hears the Ras.
> 
> ditto. :-) 

Again we do not agree.

>  
> > The key is the host knowing its link.  Some can argue because link 
> > prefixes cannot be duplicated the chance of not knowing is 
> very slim 
> > because a host can hear all prefixes and it is the case of them 
> > changing very rapidly is the problem.  That is why an 
> option to send 
> > all prefixes is a good thing to pursue.
> 
> I see. 
> 
> > >    Partial reachability indicates that the host is able to receive
> > >    packets from the router, but not necessarily vice versa.
> > 
> > Not sure about this.  How is this possible.  If I can get a packet 
> > from an address then I can send to an address? Does this need to be 
> > worded differently or more explanation.
> 
> Assume I receive an RA from a new Router. It confirms that I 
> can receive a packet from the router. But it doesn't confirm 
> the router can receive a packet from me. 

My point is that the only technology that has this asymetric property
are radio transmissions not 802.xx protocols wired or wireless.  Is my
understanding.  So lets keep it focused and this is another goal for DNA
to define the L2 properties with respect to routing and link detection.
 
>  
> > >    To examine the status of the existing configuration, a 
> host may check
> > >    whether a 'link change' has occurred.
> > 
> > OK so this is layer 2?  Or layer 3?  Or some API?  Needs to be more 
> > specific or removed.
> > 
> > This is my point we should state the goals not provide a 
> history and 
> > education other than to say link detection needs further 
> investigation.
> 
> I see your point. But IMO, it's useful to provide some 
> history and education to clarity goals. Let WG decide it. Vox 
> Populi, Vox Dei. :-)

Your not providing history here your making bold and I think statements
about Ipv6 that require a separate work.

>  
> > >    Today a link change necessitates an IP configuration change.
> > >    Whenever the host detects that it has remained at the 
> same link, it
> > >    can usually assume its IP configuration is still valid. 
> > 
> > Not usually but always that is what the timers in stateless or 
> > stateful are all about.  Whats up with that statement?
> 
> I had in mind the case of changing APs while staying on the 
> same link with huge L2 handoff delay, the period between 
> deassociation with an old AP and reassociation with a new AP. 
> For example, Boeing people are using 4 satellites around the 
> world to get 5Mbps downlink to the airplanes, and it takes 
> 30sec for the airplane to handover from one satellite to the 
> other. In such cases, I thought DAD & NUD is necessary even 
> when a host is attached to the same link.  
> 

Ouch :--).  I thought you were speaking of addresses so that needs to be
crystal clear.  But I do nto support changing ND parameters unless they
are done with RA updates or DHCPv6 or Sys Admin hard configuration, not
based on hueristics that's insane idea technically.

> > > Otherwise,
> > >    the existing one is no longer valid and a new 
> configuration must be
> > >    acquired.  Hence a host only needs to check for link change to
> > >    examine the validity of its IP configuration.
> > 
> > Correct this is fine and almost enough for the introduction 
> in my view.
> 
> I see your point. 
> 
> > >    In the process of checking for link change, a host may 
> collect some
> > >    of the necessary information for a new IP 
> configuration, for example
> > >    on-link prefixes.  So, when an IP subnet change has 
> occurred, a host
> > >    can immediately initiate the process of getting a new IP
> > >    configuration.  This may reduce handoff delay and 
> minimize signaling.
> > 
> > OK I agree but shouldn't this be part of a solutions section and is 
> > this a goal?
> 
> I thought this as ALSO goal. 'Detecting link identity' is a 
> MUST goal. 
> This is 'Would be nice" Goal. 

I think it is mandatory goal.

> 
> > >    Rapid attachment detection is required for a device 
> that changes
> > >    subnet while having on-going sessions.  This may be 
> the case if a
> > >    host is connected intermittently, is a mobile node, or 
> has urgent
> > >    data to transmit upon attachment to a link.
> > 
> > This is a goal yes.
> 
> ok 
> 
> > >    The process by which a host collects the appropriate 
> information,
> > >    detects the identity of its currently attached link, 
> and ascertains
> > >    the validity of its IP configuration, is called 
> Detecting Network
> > >    Attachment (DNA).
> > 
> > This is a goal yes.
> 
> ok.
> 
> > >    It is important to note that DNA process does not 
> include the actual
> > >    IP configuration procedure.  For example, with respect 
> to DHCP, the
> > >    DNA process may determine that the host needs to get some
> > >    configuration information from a DHCP server.  
> However, the process
> > >    of actually retrieving the information from a DHCP server falls
> > >    beyond the scope of DNA.
> > 
> > OK this is a non-goal.
> 
> ok
> 
> > > 2.  Detecting Network Attachment in Existing IPv6 Systems
> > > 
> > >    When a host changes its attachment point, for 
> efficiency, a host
> > >    should examine whether its IP configuration is still 
> valid before
> > >    initiating the process of acquiring a new IP configuration.
> > 
> > OK now we are in the solution space not goals.
> 
> I see. You want this removed? 

That is my input I think WG should have healthy discussion on the
analysis the only part of analysis that is very bad and I will object to
all the way to last call are any statements stating what IPv6 does or
does not do. But analysis should be slim in a goals doc or why have
goals of you have the analysis done?  Analysis should make the goals
clear and that is not what is done in current draft.

> 
> > >    DNA process aims to examine whether a host's current IP 
> > >    configuration
> > >    is still valid.  To achieve this goal, DNA process checks 
> > >    whether the
> > >    host is still at the same link.  Also, DNA process 
> > >    collects necessary
> > >    information for a new IP configuration.
> > 
> > This is an algorithm suggestion not a goal.
> 
> The above is just a rephrasing of the below. 
> 
>        The process by which a host collects the appropriate 
> information,
>        detects the identity of its currently attached link, 
> and ascertains
>        the validity of its IP configuration, is called 
> Detecting Network
>        Attachment (DNA).

Yes but both need to be restated as what is the goal and then define
that clearer.

> 
> 
> > >    For this, the following mechanisms and data are 
> available to hosts:
> > > 
> > >     1) Router Solicitation/Router Advertisement (RS/RA) messages
> > >     2) Neighbor Solicitation/Neighbor Advertisement 
> (NS/NA) messages
> > >     3) Information provided by the link-layer
> > 
> > Ditto.
> 
> I see your point. 
>  
> > >    Currently there is no way to represent the identity of 
> links such
> > >    that link changes can be detected instantly.  The 
> information in the
> > >    above messages cannot be used to unambiguously identify links.
> > >    Section 3 gives the detail.
> > 
> > This is not a goal.  I don't agree with #3 if I know at #3 
> my link is 
> > changed then RS/RA/NS/NA are all on the new link.
>  
> Host can't decide whether it moves to a new link or not by 
> receiving just a single RA (or NA).

I believe hueristically it can and with other data from L2.  But that is
not relevant to the goals and again this should not be discussed in the
goals draft.
  
> 
> > >    Though the set of all the assigned prefixes may be 
> used to represent
> > >    a link identity, it is difficult for a host to attain 
> and retain all
> > >    the prefixes with certainty.  Moreover there may be  
> links without
> > >    any advertised prefix.
> > 
> > Turn the above into a goal and suggest things to look for 
> in the goals.
> 
> This is the current state of art. 

I don't agree that is invalid statement on state of art there is no real
deployment of MIPv6 yet to even say this or IPv6 with WiFi etc.  

> 
> > >    Hence, to check for link change, as of today, a host 
> must resort to
> > >    guessing, based on Router Discovery and Neighbor Unreachability
> > >    Detection (NUD).  A host can examines whether 1) its 
> existing default
> > >    router is still reachable and 2) its IP addresses are 
> still valid.
> > 
> > I can know I am on a new link from the link layer and 
> physical layer 
> > for WiFi, 3G, etc..Ethernet MACs are new.  The answer could 
> be a new 
> > field in those layers and maybe we should look at that and 
> talk with IEEE?
> 
> I think the difference of link definition results in the 
> above difference of opinions. 
> In WiFi, the link layer can notify the identity of the 
> current link-layer connection, maybe BSS, but can't indicate 
> the identity of a currently attached link. 

That I am checking now.  And as I said this may be a requirement to
IEEE.

> 
> > >    After a network attachment, a host receives new (solicited or
> > >    unsolicited) RAs and compares them with the previously 
> received ones.
> > >    It checks whether the information in the new RAs, the 
> prefixes and
> > >    the router addresses, matches with the stored ones, 
> the configured IP
> > >    addresses and the default router addresses.
> > 
> > This is solution not a goal.
> 
> This is the existing DNA scheme and not a proposed solution.

How can you have a DNA scheme and call it DNA when the WG has not even
agreed on DNA goals?  

>  
> > Ditto on the rest of the section it is not goals.
> 
> I agree that it's not goals. But I think they are useful for 
> goals description. 

Maybe and Maybe not.

>  
> > > 3.1  Wireless link properties
> > > 
> > >    1) Unclear boundary
> > > 
> > >    Unlike wired environments, what constitutes wireless 
> link  is variable
> > >    in both time and space.  It doesn't have clear boundaries. 
> > >    This may
> > >    be illustrated by the fact that a host may contact 
> > >    multiple (802.11)
> > >    access points at the same time.  Moreover reachability on 
> > >    a wireless
> > >    link is very volatile, which may make link detection hard.
> > 
> > Any device is aware of which wireless net is attached to 
> and that data 
> > is available so I am unclear the statements above are 
> valid? I also do 
> > not agree link detection is hard.
> 
> In Wireless environment, a host may ping-poing between two 
> links rapidly. 
> In that case, a host will have difficulty. 

I don't agree but define what exactly technically "difficulty" means
above?

> 
> > >    2) Asymmetric reachability
> > > 
> > >    In some wireless environments, it may be possible to receive
> > >    periodically multicast advertisement information 
> without being able
> > >    to send IP packets to the network.  In these cases, it is
> > >    insufficient to rely upon reception of unsolicited 
> advertisement
> > >    information as confirmation of router reachability.
> > 
> > This is old and not the norm.  It also applies to radio 
> more than say 
> > WiFi and current medias.
> 
> I see. 
> 
> > > 3.2  Inadequacies in RA information
> > > 
> > >    Usually a host receives the information necessary for IP
> > >    configuration from RA messages.  Based on the current 
> definition [4],
> > >    the information contained in RA messages is inadequate 
> to represent a
> > >    link change.  RA messages are not designed to represent link
> > >    identities and have inherent ambiguities.
> > 
> > This has nothing to do with Goals and a podium to present one view.
> > RA's are not to represent link change so lets make one.
> > But this is a goals document.
> 
> DNA Goal is to 'detect a link identity'. Isn't it useful to 
> write that an RA can't indicate a link identity? 

If stated a goal is to make RA's provide link IDs then yes that would be
a goal but state they can't without corresponding goal sounds like extra
baggage and no value and potential political wordsmithing that is not
relevant to the goals document.

> 
> > >    1) Link local scope of Router Address
> > > 
> > >    Usually a router address is contained in the source 
> address field of
> > >    RA messages.  That router address is link-local scope and its
> > >    uniqueness can't be guaranteed out side of a link.
> > > 
> > >    So if it happens that two different router interfaces 
> have the same
> > >    link-local address, a host can't detect that it has 
> moved from one
> > >    interface to another by checking the router address in 
> RA messages.
> > > 
> > >    On the other hand, a host can't be sure that its 
> default router is
> > >    reachable, even if it can communicate with the router 
> that has the
> > >    same address as its existing router address.  That 
> router may be a
> > >    different one, which happens to have the same 
> link-local address as
> > >    its default router address.
> > 
> > We can require that the router use non-link local addresses with a 
> > prefix and those cannot be duplicated across the links. I am not 
> > advocating that but the above statement is not entirely honest or 
> > tells the whole story and also again not a goal.
> 
> The above is about the existing problem of link-local scope of router 
> address.   

But is incomplete not referencing it can use non-link-local scope.

> 
> > >    2) Omission of Prefix Information Option
> > > 
> > >    To check the validity of its IP address, a host should examine
> > >    whether the prefix of its IP address is advertised on 
> the link to
> > >    which it is currently attached.
> > > 
> > >    The host checks whether the prefix of its IP addresses 
> are present in
> > >    the Prefix Information Option of incoming RA messages.  But an
> > >    unsolicited RA message can omit some prefixes for 
> convenience, for
> > >    example to save bandwidth [4].
> > 
> > So we fix that in RA's or add new RA fro mobile nodes.
> 
> Under current standard, hosts can't be 100% sure that it 
> knows all the prefixes, even if it does. That uncertainty 
> results in the uncertain address validity determination. 

I simply 100% do not agree at all techncially that this cannot be done
with a new set of RA's.
 
> 
> > >    Hence, the host can't be sure that the prefix of its current IP
> > >    address is not supported on the current link, even 
> though the prefix
> > >    is not contained in a received RA.
> > > 
> > > 3.3  Delays
> > > 
> > >    The following issues cause DNA delay that may result 
> in communication
> > >    disruption.
> > > 
> > >    1) Delay for receiving a hint
> > 
> > What type of hint and where is the delay at driver interrupt, IP 
> > queue, upto TCP or UDP in the stack?  This is a bold and not well 
> > defended statement as is at all.
> 
> Hint doesn't exclusively mean link-layer hint, the indication 
> from the link 
> layer. In below, I described the reason of delay for each hint.  

I did not say that but I will look for details below but I don't see
them above hence my comment.
 
>  
> > >    For rapid attachment detection, hints can be used to 
> tell a host that
> > >    a link change might have happened.  This hint itself 
> doesn't confirm
> > >    a link change, but can be used to initiate the appropriate
> > >    procedures.
> > 
> > Correct but lets go look at the IEEE properties of each link media 
> > first and be sure.
> 
> There are hints from L3. 

Ugggggggggg.  That should be a goal to verify.

> 
> > >    Hints come in various forms, and differ in how they 
> indicate a new
> > >    attachment.  They can be link-layer indications, the 
> lack of RA from
> > >    the default router or the receipt of a new RA.  The 
> time taken to
> > >    receive a hint also varies.
> > > 
> > >    As soon as a new link-layer connection has been made, 
> the link-layer
> > >    may send a link up notification to the IP layer.  A host may
> > >    interpret a new network attachment as a hint for a 
> possible link
> > >    change.  With link-layer support, a host can receive a 
> hint almost
> > >    instantly.
> > 
> > Correct and flush its caches.
> 
> I see. 
> 
> > >    [9] defines the use of RA Interval Timer expiry for a 
> hint.  A host
> > >    keeps monitoring periodic RAs and interprets the lack 
> of them as a
> > >    hint.  It may implement its own policy to determine 
> the number of
> > >    missing RAs for a hint.  Hence the delay depends on the Router
> > >    Advertisement interval.
> > > 
> > >    Without the schemes such as above, a host must receive 
> a new RA from
> > >    a new router to detect a possible link change.  The 
> detection time
> > >    then also depends on the Router advertisement frequency.
> > > 
> > >    Periodic RA beaconing transmits packets within an 
> interval varying
> > >    randomly between MinRtrAdvInterval to 
> MaxRtrAdvInterval seconds.
> > >    Because a network attachment is unrelated to the 
> advertisement time
> > >    on the new link, the host is expected to arrive on 
> average half way
> > >    through the interval.  This is approximately 1.75 
> seconds with [4]
> > >    advertisement rates.
> > > 
> > >    2) Delay for checking current default router Unreachability
> > > 
> > >    When a host examines the reachability of the current 
> > >    default router,
> > >    a certain delay occurs if the current default router is not
> > >    reachable.
> > > 
> > >    Usually it's easier to detect a node's presence than its 
> > >    absence.  A
> > >    host sends a solicitation message and, upon the 
> receipt of a reply,
> > >    it can assume that it's there.
> > > 
> > >    To be sure that a node is absent, time needs to be 
> taken to ensure
> > >    that the lack of a reply is not due to another reasons 
> > >    (for example, packet loss, MAC latency, or processing 
> delay).  So it 
> > >    takes time to
> > >    verify the unreachability of the current router.
> > > 
> > >    After a host moves to another link, if it uses NUD for 
> > >    detection, it
> > >    will take more than 3 seconds to recognize that the 
> > >    current router is
> > >    no longer reachable [4].
> > 
> > That is configurable.
> 
> You mean you can configure a host to perform NUD less than 3 secs? 
> 
> > >    3) Random delay execution for RS/ RA exchange
> > > 
> > >    Router Solicitation and Router Advertisement messages 
> are used for
> > >    Router Discovery.  According to [4], it is sometimes 
> > >    necessary for a
> > >    host to wait a random amount of time to send an RS and 
> for a router
> > >    to wait to reply an RA.
> > > 
> > >    Before a host sends an initial solicitation, it SHOULD 
> delay the
> > >    transmission for a random amount of time between 0 and
> > >    MAX_RTR_SOLICITATION_DELAY (1 second).  Also Router 
> Advertisements
> > >    sent in response to a Router Solicitation MUST be delayed 
> > >    by a random
> > >    time between 0 and MAX_RA_DELAY_TIME (0.5 seconds).
> > 
> > This is configurable.
> 
> Configurable under RFC 2461? 

Yes.

> 
> > > 4.  Goals for Detecting Network Attachment
> > > 
> > >    DNA solutions should be 1) Precise, 2) Sufficiently 
> fast and 3) Of
> > >    limited signaling.  The solutions should correctly 
> > >    determine whether
> > >    a link change has occurred.  They also should be 
> sufficiently fast
> > >    lest there should be service disruption.  They should 
> not flood the
> > >    link with related signaling.
> > > 
> > >    It will be necessary to investigate the usage of available 
> > >    tools, NS/
> > >    NA messages, RS/RA messages, link-layer hints and 
> other features.
> > >    This will allow precise description of procedures for 
> efficient DNA
> > >    Schemes.
> > > 
> > > 4.1  Goals list
> > > 
> > >    G1 DNA schemes should detect the identity of the 
> currently attached
> > >       link to ascertain the validity of the existing IP 
> configuration.
> > >       They should recognize and determine whether a link 
> change has
> > >       occurred and initiate the process of acquiring a new 
> > >       configuration
> > >       if necessary.
> > > 
> > >    G2 When upper-layer protocol sessions are being supported, DNA
> > >       schemes should detect the identity of an attached 
> link rapidly,
> > >       with minimal latency.
> > > 
> > >    G3 In the case where a host has not changed a link or 
> subnet, an IP
> > >       configuration change should not occur.
> > > 
> > >    G4 DNA schemes should not cause undue signaling on a link.
> > > 
> > >    G5 DNA schemes should make use of existing signaling 
> mechanisms 
> > > where
> > >       available.
> > > 
> > >    G6 DNA schemes should make use of signaling within the link
> > >       (particularly link-local scope messages), since 
> communication
> > >       off-link may not be achievable in the case of a link change.
> > > 
> > >    G7 DNA schemes should be compatible with security 
> schemes such as
> > >       Secure Neighbour Discovery [8] and IPSec [7].
> > > 
> > >    G8 A host configured for DNA should not expose itself 
> to additional
> > >       man in the middle or identity revealing attacks.
> > > 
> > >    G9 A host or router configured for DNA should not 
> expose itself or
> > >       other devices on the link to additional denial of 
> > >       service attacks.
> > >
> > >    G10 The Routers supporting DNA should work 
> appropriately with hosts
> > >       using unmodified configuration schemes, such as [4] and [6].
> > > 
> > >    G11 The Hosts supporting DNA should be able to work 
> with unmodified
> > >       routers and hosts which do not support DNA schemes.
> > 
> > The above is the list of goals we should be debating not all the 
> > upfront opinions and text.  That is second step after the goals.
> 
> That part is about the existing schemes, not the proposed solutions. 

I think all schemes need review existing and new ones.  As I said above
there is no MIPv6 mobility in the production world today but it is
beginning that is for sure and DNA is late.

> 
> Thanks for your taking trouble to provide feedback. It made 
> things clearer for me. 

I hope so.

Thanks for followup 
/jim

> 
> Best Regards
> 
> JinHyeock 
> 
>  
>