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
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
