A marked-up version with my full comments in context can be found at http://research.microsoft.com/~dthaler/draft-ietf-6man-rfc3484-revise-05.pdf
-Dave > -----Original Message----- > From: Dave Thaler > Sent: Wednesday, November 16, 2011 7:49 PM > To: 6man > Cc: 'Brian E Carpenter'; Arifumi Matsumoto > Subject: RE: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt > > 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: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] 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 > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
