Subject: 2461bis AUTH48 changes

From: Jari Arkko <[email-masked]>
Date: Tue, 28 Aug 2007 10:53:56 +0300

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