RE: Resolution of my discuss comments for draft-ietf-v6ops-nap-02.txt

["Tony Hain" <alh-ietf@tndh.net>]

Jari Arkko wrote:
> > tone/language
> 
> Much better indeed, but still a few terms that
> you probably should remove (search for "marketing").

Despite the distaste for the term, people don't evaluate the technical
trade-offs, they buy what they have been told will solve their problem. That
is 'marketing'. Earlier versions were a little heavy on the point, but there
are only 2 references in the intro and one in the security issues at this
point, so I believe the document actually carries the appropriate tone about
why its existence is even necessary.  


> ...
>      The downside with a Mobile IPv6 based solution is that it requires
>      a home agent in the network, the configuration of a security
>      association for each mobile node, and consumes some amount of
>      bandwidth for tunnel overhead. 

Replaced existing with this.


> A random, dynamic assignment
>      of home addresses without manual intervention also requires
>      support for IKEv2-based extension to Mobile IPv6
>      [I-D.ietf-mip6-ikev2-ipsec].

Is this a level of detail beyond the scope of the document? 


> 
> >4.2 -2 does not oversell IPsec, it simply states the real situation.
> >
> >
> I'm not going to hold your document based on the -03 text, but
> I would still suggest the following edit:
> 
>        While IPsec might be available in IPv4
>        implementations and works the same way, deployment in NAT
>        environments either breaks the protocol or requires complex
>        helper services with limited functionality or efficiency.
> =>
>        While IPsec is commonly available in IPv4 implementations
>        and can support NATs, NAT support has limitations and
>        does not work in all situations. In addition, the use of IPsec
>        with NATs consumes extra bandwidth for UDP encapsulation
>        and keepalive overhead.

You appear to be assuming desktop/server OS's. Many/most cell-phone/pda OS's
and virtually-none of the embedded appliance implementations include IPsec
for IPv4. Even when they do they don't include the nat traversal pieces. I
did add the comment about the helper services not working in all situations.


> ...
> The one remaining thing that I would suggest you add here is
> a warning about the issues in multihoming and ingress filtering.
> If I read Section 4.7, I get the feeling that multiple prefixes and
> multiple ISPs works fine today, which may not be exactly correct,
> see e.g. draft-huitema-shim6-ingress-filtering. Do not add a lot
> of text, just mention that there are issues in some cases in the
> multiple-ISP model.

Does this work for you:
Additional considerations are being documented as multihoming work evolves
xref  ---  draft-bagnulo-shim6-ingress-filtering-00.txt

Tony