Re: 2461bis AUTH48 changes

[Jari Arkko <jari.arkko at piuha.net>]

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