> 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 --------------------------------------------------------------------
