Subject: [Gen-art] draft-ietf-v6ops-nap-02

From: "Gray, Eric" <[email-masked]>
Date: Mon, 22 May 2006 18:22:24 -0400

I am the assigned Gen-ART reviewer for draft-ietf-v6ops-nap-02.txt.

For background on Gen-ART, please see the FAQ located at:

<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>. 

Please wait for direction from your document shepherd or AD before 
posting a new version of the draft.  The document shepherd for this
draft is David Kessens <[email-masked]>.

The version of this draft that I reviewed can be found at:

http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-02.txt

This document does not appear to me to be ready to publish
at this point.

My comments, questions and nits are below...

COMMENTS:
========

A few general comments (ranging from good to bad) and one, more
specific, comment:
--------------------------------------------------------------------

In general, I felt that this document will be very useful as a
compendium of "NAT replacement techniques" for use with IPv6.

The content is very good, generally, and it forms a very strong
basis for a later BCP that describes what actually gets done in
real IPv6 networks - especially including the real solutions it
identifies as needed in section 6 ("IPv6 Gap Analysis").

I want to thank the authors for taking on this work.
====================================================================

At some point, we will probably have to have one or more BCPs to
complete the task that this document sets.  I believe this is
already either stated, or implied, in section 6.
====================================================================

As a general observation, I find that the pronounced tendency to
"assign blame" for current NAT use to "marketing departments",
"marketing pronouncements", "marketing campaigns" and "messages", 
references to "marketed benefits", hype coming out of "product
marketing", etc. - leaves a distinctly metallic after-taste in my 
digestive aparatus.  In fact, it is unecessarily antagonistic and
offensive.

"Market acceptance" and "market perceived benefits" are fair and
reasonable observations about the industry, and do not attempt to
"assign blame" for the observed behaviors.

It is often difficult to determine whether market perceptions are
being driven by marketing campaigns, or driving them.  In the case
of NAT usage in the Internet, however, I think it is at least fair
to speculate that market perceptions may have initially driven the
"marketing pronouncements", given that NAT has been around since
well before the Internet became important enough to attract much 
in the way of "marketing campaigns".

In any case, however, I can imagine no useful purpose that might be
served by including these apparent accusations.  I suggest that a
sweep should be made of the document to remove all such statements, 
or - at least - reduce the degree to which they seem to have been 
made unecessarily, and offensively, vituperative. 

As an example, the "Security Considerations" section refers to "the
misleading nature" of claims the same section attributes to product
marketing departments as having been previously documented in RFCs
2663 and 2993.  In a cursory look at both of those RFCs, I find RFC
2993 to contain a couple of references to "market" but neither of
these RFCs makes any references to "marketing", or to "misleading"
statements.

I strongly suspect that what was good enough for those existing
RFCs is good enough for this proposed one.
====================================================================

Section 2.2 can be substantially reduced, if text that is unrelated
to describing the use of NAT and IPv4 for the purpose indicated in
the section title, is simply removed.  For example, generalizations
about the effectiveness of firewalls in providing security, comments
(or observations) about distributed security mechanisms and even the
effectiveness of address translation in the degenerate case may have
something to do with weakening the case for using NAT, but they have 
nothing much to do with perceived benefits of actually using NAT.

Statements that make generalization and judgements about the utility 
of NAT in achieving perceived benefits, are strangely out of place in 
a section labeled "Perceived Benefits of NAT and its Impact on IPv4".

Perhaps these should be included in a different section (for example,
similar text is already included in section 4.2 - "IPv6 and Simple
Security").

QUESTIONS:
=========

In the second paragraph of section 2.5 (only sentence), a little 
punctuation (and an article or two) may be needed to help with 
parsing.  For example, I believe what you tried to say was:

"Another benefit is<,> due to the usage of independent addresses 
 on <a> majority of the network infrastructure<,> there is an 
 increased ability to change provider<s> with less operational 
 difficulties."

(<text/characters> were added to your existing text)

Is this, in fact, what you were trying to say?
====================================================================

A similar problem exists with a sentence in section 2.6 (bottom 
of page 9 and top of page 10) - to wit:

Forced into this limiting situation<,> such customers can rightly 
claim that <-> despite the optimistic predictions of mathematical 
models <-> the global pool of IPv4 addresses is effectively 
already exhausted, especially for larger enterprises.

(again, <text/characters> were added to your existing text)

Is this - also - a correct interpretation of what you're saying?
====================================================================

Strictly as an observation, I am reasonably comfortable in saying
that using ULAs within a private network to communicate with hosts
that need to generate external traffic (e.g. - proxy devices), that
maintain both an ULA and one or more global addresses - is likely
to be indistinguishable, in practice, from NAT.  Yet this is what
the draft appears to recommend in the paragraph at the top of page
16.

Is this not true (i.e. - either that the distinction is small, or
that this is what is recommended in the indicated paragraph)?
====================================================================

Have the authors considered that the use of time-based 'Untraceable'
IPv6 addresses might have some impact on the ability of enterprises
to monitor the behavior of users within their own network?  This 
ought to be a consideration, for instance, in section 5.1 ("Medium
/ large private networks") in the case studies section (5).  If the
enterprises are unlikely to find this practicable, then it is not 
very likely to be used in this case.
====================================================================

In the SOHO network case, how do you envision that the use of either
(or both) DHCPv6-PD or a statically assigned IPv6 address range will
work with a business providing content (via a file server and one or
more proxy devices) where the content storage is to be kept private
and access to it is via high-speed proxies (perhaps providing secure
access to clients)?

Does the SOHO user need to define external name-service mappings to
the ISP, or do you anticipate that the ISP will allow the SOHO to
update the ISP's DNS entries directly?
====================================================================

As in section 5.1, how likely is it that an ISP will allow a single
user to "enable IPv6 privacy extensions"?  That is, given potential
for ISP liability for untraceable user behavior, isn't it likely an
ISP will explicitly disallow this usage (refering to section 5.3)?
====================================================================

NITS:
====

First paragraph of section 1 ("Introduction") contains the 
following partial statement "... driven a perception hat 
some connectivity ..." - "hat" should be "that"? 
====================================================================

In the last paragraph of section 4.1, the sentence beginning
"In the very simple case there is ..." should be either "In
a very simple case, there is ..." or "In the simplest case,
there is ..." - unless you are sure that there is only one 
"very simple case" and that it is not the "simplest case".
====================================================================

First sentence in the paragraph at the bottom of page 14, and
top of page 15, "... a given set configuration rules ..." -
should this be "... a given set <of> configuration rules ..."?
====================================================================

I believe the convention for including very large numbers in
text would result in the paragraph in section 4.6 starting as
follows:

  "IPv6 provides sufficient space to completely avoid the need
   for overlapping address space, i.e. - 
   
       340,282,366,920,938,463,463,374,607,431,768,211,456 

   - or about 3.4*10^38 total possible addresses."

For similar (readability) reasons, this number should be taken
out of the table on page 5.
====================================================================

I recommend the following changes to the first two sentences in
the second paragraph of section 4.7 (last paragraph on page 17):

  "The IPv6 address space allocated by the ISP will be dependent 
   upon the connecting Service <P>rovider.  This may result in a 
   renumbering effort if the network changes from <one> Service 
   Provider <to another>." 
====================================================================

First sentence, section 5 ("Case Studies") - change "... categories
of network ..." to "... categories of network<s> ..."

Second sentence, same paragraph, change "... each of these category
of networks ..." to "... each of these categories of networks ..."
====================================================================

Second paragraph in section 5.4 ("ISP/Carrier Customer Networks" -
beginning "When IPv6 NAP is ...") - for readability, this paragraph
should be broken into three different paragraphs, one for each of
the three domains.  (The RFC Editor would probably fix this)
====================================================================

First sentence, second paragraph - 

"As an alternative, some work <is being done / could be done?> in 
Mobile IP to define a policy message where a mobile node would learn 
from the Home Agent."  

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