So I have not heard objections, and I have heard a few confirmations from the editor, chairs, etc, so we are moving ahead with this.
Jari Jari Arkko kirjoitti: > Folks, > > The 2461bis document has been for a (long) while in AUTH48. This > is also affecting other documents that are pending for the RFC to > come out. > > One of the reasons why this has taken so long is that a number of > issues were raised on the list, privately to me, and in IESG review > of some other documents, all possibly requiring clarifications or > modifications to 2461bis. We also met with the people in the Cc > list in IETF-69 to talk about this. > > I have now reviewed all the raised issues and would like to > report to the WG where we are. There is also one suggested > modification which I believe we should perform. If there are > any objections to this modification I'd like to hear them by > the end of the week. The other issues should be deferred > for further work or pursued in other ways. > > 1. Issues raised in draft-wbeebee. A number of clarifications > in the off/on-link rules were given. I sent another mail about > this (see link below) and suggested that at this time we > do not have sufficient agreement that the matter indeed > needs clarification, and the amount of changes would > exceed something we can do in AUTH48. As a result, > this should be pursued in separate documents and > discussed further in the WG. > > http://www1.ietf.org/mail-archive/web/ipv6/current/msg08505.html > > 2. Issues raised in the IESG review of draft-ietf-16ng-ipv6-over-ipv6cs. > This is an "IPv6 over Foo" document that wants to override > the AdvDefaultLifetime value for this specific link layer. > > The IESG reviewers wanted to allow overriding for consenting > link layer designers, but only if the 2461bis allowed the override > for a specific variable. Note that the beginning of Section 6.2.1 > says the default values can be overridden by link layer specifications, > but it is silent on limits, and the limits are given using MUST > language. > > I do not want to go into a discussion of what makes sense for > a specific link layer, but I do believe that this is appropriate > under certain circumstances. For AdvDefaultLifetime, right > now the document simply says "MUST be either zero or > between MaxRtrAdvInterval and 9000 seconds." When we > talked about this in a small group in Chicago, it was > suggested that for point-to-point links the IPv6 over Foo > documents should have more freedom to specify this > timer, as the nature of the link tells you how many > devices can be at the other end, and you may also have > more information about link up/down events than in > other link types. > > In any case, we could either allow a particular extension under > specific conditions, or make it more generally clear that > the IPv6 over Foo documents can override even the MUSTs > relating to timer limits. I would suggest the former. > > The change would be as follows: > > OLD: > MUST be either zero or between > MaxRtrAdvInterval and 9000 seconds. A value of > zero indicates that the router is not to be used as > a default router. > NEW: > MUST be either zero or between > MaxRtrAdvInterval and 9000 seconds. A value of > zero indicates that the router is not to be used as > a default router. These limits may be overridden > by specific documents that describe how IPv6 operates > over different link-layers. For instance, in a point-to-point > link the peers may have enough information about the > number and status of devices at the other end so that > advertisements are needed less frequently. > > I would like the WG to OK this change. Any objections? > > 3. Issues raised by Thomas Narten about conflicts and > synchronization to other RFCs. > > There was an earlier discussion of this in the WG, > under the thread "narten's review". Thomas has > looked at this again during AUTH48 and raised the > issues to me. The issues included > > - Updating the document with information about > what new bits have been allocated in the reserved > fields, along with informative pointers to the documents > in question. > > - The same for options. > > - Synchronizing RFC 3775 Section 7.5 new limits for > router advertisement frequencies and 2461bis. > > I think Thomas is basically right and the document > would be better with these folded in. I also think > if properly written, these changes would not have > caused normative references or DS advancement > problems. However, at the end of the day, the > changes are fairly big for AUTH48, were already > discussed in the WG, and are more of editorial in > nature than fixing a critical bug. Finally, the > RFC 3775 synchronization would involve more > than mere timer values; there are more items > in Section 7.5 that would have to be folded in. > > So, I would rather move on with the RFC publication > than re-run the discussion, even if I think I would > personally have written the bis document in > slightly different manner to avoid Thomas' issues. > > In summary, I only see one issue (item 2) that requires > a change in AUTH48. If the WG agrees we should get > the document out next week. > > Jari > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
