Re: I-D ACTION:draft-ietf-v6ops-unman-scenarios-01.txt

[Fred Templin <ftemplin@IPRG.nokia.com>]

Margaret,

Not wanting to hold up process, but I'm afraid I do see one item
in the changes that somehow escaped my attention earlier. In the
abstract, the following new text appears:

 "The scenarios are specific to single link subnet"

In this context, the phrase "single link subnet" seems too restrictive
by its inclusion of the word "link". Everywhere else in the document,
we see the phrase expressed as "single subnet", and I do agree with
this usage. Suggest changing the phrase in the abstract to:

 "The scenarios are specific to a single subnet"

While I'm on the subject, there were a few minor editorial comments:

1) In section 5.2.2, first sentence of the second paragraph, the phrase
   "NAT will not be in use" appears twice.

2) Section 5.3, end of second sentence should be: "to hosts.", not
   "the hosts."

3) Section 5.4.2, first sentence of the second paragraph, change:
   "dual stack host" to "dual stack hosts".

Fred
ftemplin@iprg.nokia.com





Margaret Wasserman wrote:

> Hi All,
>
> Please review the changes to this document, and let us know if all
> of your last call issues were adequately resolved.  If there are no
> remaining issues, we hope to forward this document to the IESG by
> the middle of next week.
>
> Thanks,
> Margaret
>
>
> At 02:44 PM 6/5/2003 -0700, Christian Huitema wrote:
>
> > The draft "draft-ietf-v6ops-uman-scenarios-01.txt" into account the
> > comments received during the V6OPS WG last call for
> > draft-ietf-v6ops-uman-scenarios-00.txt. The authors believe that this
> > document addresses the last call comments. A list of these comments and
> > the way they were addressed is available at:
> >
> >         http://www.huitema.net/ipv6/Unman-Scenarios-Issues.htm
> >
> > The main changes fall in three categories:
> >
> > 1) Change the topology section to explain exactly why we did not
> > consider the multiple subnet case (i.e., with today's technology, such
> > networks are not unmanaged);
> >
> > 2) Change several of the case description scenarios to remove the
> > more-or-less implicit assumption that there is always a NAT in IPv4
> > deployments;
> >
> > 3) Fix a number of editorial issues, notably the abstract, the
> > introduction, the wording of references to DNS issues, and a split of
> > references between normative and informative.
> >
> > -- Christian Huitema