I have read and reviewed -05.
The document is a good start, but I have some issues with it currently.
Summary of substantial technical issues:
1) In the updated prefix policy table, the order of rows is ok, but the
precedence
values are a major problem that would make it difficult if not impossible for us
to implement/deploy the current draft. Please change to preserve the precedence
values to be the same as in RFC 3484 except where a change is actually required.
For example, ::1/128 should remain 50. Teredo should be 5, which is what has
been deployed for many years now. The operational issues center around ways
to configure nodes with additional rules. Ones already exist in some
implementations
and changing the values means that you can't push a rule out to a host unless
you
know it's a new vs old host. Avoiding gratuitous changes means you can have
one new-row pushed out to all hosts. I personally consider this a showstopper
for the draft.
2) The current Rule 5.1 text
"Rule 5.1: Use an address assigned by the selected next-hop."
is problematic for two reasons:
i) Next-hops don't assign addresses, they advertise prefixes. Addresses are
assigned by the hosts themselves (in SLAAC) or by DHCP servers.
It should say something like "Prefer addresses in a prefix advertised by
the next-hop"
ii) nowhere does the doc have text about whether a host must remember
who it got an on-link prefix from. RFC 4861 section 5 doesn't say it does.
RFC 4191 section 3 doesn't either. And this document has no section
that's similar to either one. Note that 4191 section 3 defines some as
being optional. Is this one optional or required? I don't have a concern
either way, my concern is that the document doesn't say anything like
what it ought to cover in order to enable this rule.
Summary of editorial issues:
1) As Brian pointed out one instance of, many places in the doc say what
_could_
be done. A standards track document needs to instead specify what _is_ done.
2) Several informative references (that are drafts not RFCs) are used in text
in
normative ways. Rather than making them be normative references, the text
should be updated so that the use is clearly informative.
3) A number of grammar issues. Parts of Appendix B are rather hard to read
for instance. Perhaps it can just be deleted.
Also I prefer the Updates (not Obsoletes) option, where the document
specifies the deltas. This is the current approach in the doc.
-Dave
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Brian E Carpenter
> Sent: Monday, November 14, 2011 6:48 AM
> To: Arifumi Matsumoto
> Cc: 6man
> Subject: Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt
>
> > So, which of update or replace do you prefer ?
>
> Hmm. If we want to go quickly, an update that makes it easy for the
> implementer to find the changes is better.
>
> Regards
> Brian
>
> On 2011-11-13 21:19, Arifumi Matsumoto wrote:
> > Brian,
> >
> > thank you for your comments.
> >
> > On 2011/11/09, at 10:11, Brian E Carpenter wrote:
> >
> >> Hi,
> >>
> >> I think I'm going to make myself unpopular.
> >>
> >> Reading this document as a proposed standard, I think it will confuse the
> reader.
> >> I think that what we actually need is a 100% replacement of RFC 3484,
> >> that can be read on its own.
> >>
> >> (We've been here before - the same argument is why we ended up doing
> >> 3697bis.)
> >>
> >> If that is not done, I would suggest reorganising the text so that
> >> (after a short Introduction) the reader finds:
> >>
> >> - firstly, a complete but concise statement of the normative changes
> >> made to 3484 (such as section 2.1.5, and the new rules 5.1 and 9)
> >>
> >> - secondly, the explanations (such as sections 2.1.1-2.1.4).
> >>
> >> An implementer would only need to read the first part.
> >
> > This document had started as an update, because there was not so many
> > things to update at first.
> >
> > As the document gets older, it got a bit bigger than I had expected.
> >
> > So, which of update or replace do you prefer ?
> >
> >> Trivia:
> >>
> >> Needs a header: Updates: 3484 (if approved)
> >>
> >>> 4. IANA Considerations
> >>>
> >>> Address type number for the policy table may have to be assigned by
> >>> IANA.
> >> You can't say "may", you have to tell IANA exactly what to do in which
> registry.
> >
> > Thanks !
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
