Subject: Fwd: 6MAN WG Adoption Call: draft-nordmark-6man-rs-refresh-01

From: Bob Hinden <[email-masked]>
Date: Wed, 8 Apr 2015 12:19:30 -0700

Reminder.  Please send comments on this adoption call.

Thanks
Bob & Ole

> Begin forwarded message:
> 
> From: Bob Hinden <[email-masked]>
> Subject: 6MAN WG Adoption Call: draft-nordmark-6man-rs-refresh-01
> Date: March 27, 2015 at 8:34:09 AM PDT
> Cc: 6man Chairs <[email-masked]>
> To: IPv6 List <[email-masked]>
> 
> This message starts a two week 6MAN Working Group Last Call on adopting:
> 
>        Title           : IPv6 Neighbor Discovery Optional Unicast RS/RA Refresh
>        Authors         : Erik Nordmark
>                          Andrew Yourtchenko
>                          Suresh Krishnan
>        Filename        : draft-nordmark-6man-rs-refresh-01.txt
>        Pages           : 12
>        Date            : 2014-10-27
> 
>        https://tools.ietf.org/html/draft-nordmark-6man-rs-refresh-01
> 
> as a working group document. Substantive comments and statements of support for adopting this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This adoption call will end on April 10, 2015.
> 
> Regards,
> 
> Bob Hinden & Ole Trøan
>

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 9 Apr 2015 00:30:27 +0000 (UTC)

Hi,
I support adoption.
Regards,Mark.
      From: Bob Hinden <[email-masked]>
 To: IPv6 List <[email-masked]> 
Cc: Bob Hinden <[email-masked]> 
 Sent: Thursday, 9 April 2015, 5:19
 Subject: Fwd: 6MAN WG Adoption Call: draft-nordmark-6man-rs-refresh-01

Thanks
Bob & Ole

> as a working group document. Substantive comments and statements of support for adopting this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  Th…

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 09 Apr 2015 09:15:11 -0700

Thanks for the reminder.

I support this draft (kind of obvious since I asked for the adoption call).

The reason for why I think this is important is that we should avoid any 
(further) fragmentation of ND for different types of networks and hosts, 
and instead provide different options at deployment.

Regards,
    Erik

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 9 Apr 2015 13:32:59 -0500

I also support adoption.

Regards,

Behcet

---

From: Fernando Gont <[email-masked]>
Date: Thu, 09 Apr 2015 15:29:33 -0300

> Reminder.  Please send comments on this adoption call.

I support adoption of this document as a 6man wg item.

I will send a detailed review asap -- hopefully this weekend.

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Fri, 10 Apr 2015 02:34:57 +0000

I support the adoption of this draft, and also second the reason Erik posted.

Regards,
Will (Shucheng LIU)

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Erik Nordmark
> Sent: Friday, April 10, 2015 12:15 AM
> To: Bob Hinden; IPv6 List
> Subject: Re: Fwd: 6MAN WG Adoption Call:
> draft-nordmark-6man-rs-refresh-01
> 
> 
> Thanks for the reminder.
> 
> (further) fragmentation of ND for different types of networks and hosts, and
> instead provide different options at deployment.
> 
> Regards,
>     Erik
> 
> >> as a working group document. Substantive comments and statements of
> support for adopting this document should be directed to the mailing list.
> Editorial suggestions can be sent to the authors.  This adoption call will end on
> April 10, 2015.
> >>
> >> Regards,
> >>
> >> Bob Hinden & Ole Trøan
> >>
> >
> >

---

From: 神明達哉 <[email-masked]>
Date: Fri, 10 Apr 2015 09:57:24 -0700

At Wed, 8 Apr 2015 12:19:30 -0700,
Bob Hinden <[email-masked]> wrote:

> > as a working group document. Substantive comments and statements
> > of support for adopting this document should be directed to the
> > mailing list.  Editorial suggestions can be sent to the authors.
> > This adoption call will end on April 10, 2015.

I think it's worth discussing so I support the adoption.  But I have
one higher level question: did we agree that we need some enhancements
to ND to address the concern of multicast overhead?  It's quite
possible that I missed something in previous discussions, but I
thought there was not a clear consensus for the need for protocol
level changes while we generally saw potential issues in this area.

On the draft itself, I have a few minor comments:

- Section 5:
   Refresh Time:  16-bit unsigned integer.  Units is seconds.  The all-
                  ones value (65535) means infinite.

What should the host do if this is 0?  Should it just keep sending
RSes? (I'm joking).

- Section 7: remove 'section'.
   [...]  Note that section
   Section 9 says that routers SHOULD report such inconsistencies to
   system management.

- Section 8.2: s/be be/may be/ (?)

   [...]  That be be performed at deployment time (e.g., only
   hosts which are known to support RTO are configured with the layer 2
   security keys), or the routers detect any RSs which do not include

- Section 8.3: remove '.' before 'Note':

   .  Note that such new information is not likely to reach sleeping
   hosts until those hosts refresh by sending a RS.

--
JINMEI, Tatuya

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 11 Apr 2015 17:15:11 +0000

I  support this document's adoption by 6man.  Minor edits are included below.

Section 5

s/a option/an option/

Section 7.2 and other places

s/etc/etc./

s/can not/cannot/

Hemant

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Friday, March 27, 2015 11:34 AM
To: IPv6 List
Cc: 6man Chairs
Subject: 6MAN WG Adoption Call: draft-nordmark-6man-rs-refresh-01

Regards,

Bob Hinden & Ole Trøan

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 14 Apr 2015 16:02:22 +0000

Dear all:

This documents contributes to the reduction of multicast noise, which is critical in many environments as discussed in the intro.
The document is already sound with a clearly defined behavior. I support the adoption.

Cheers,

Pascal

> Sent: vendredi 27 mars 2015 16:34
> To: IPv6 List
> Cc: 6man Chairs
> as a working group document. Substantive comments and statements of support
> for adopting this document should be directed to the mailing list.  Editorial
> suggestions can be sent to the authors.  This adoption call will end on April 10,
> 2015.
> 
> Regards,
> 
> Bob Hinden & Ole Trøan

---

From: Hosnieh Rafiee <[email-masked]>
Date: Tue, 14 Apr 2015 16:17:37 +0000

+1

I support the adoption of this document.

Hosnieh

> From: ipv6 [mailto:[email-masked]] On Behalf Of Pascal Thubert
> (pthubert)
> Sent: Tuesday, April 14, 2015 6:02 PM
> Subject: RE: 6MAN WG Adoption Call: draft-nordmark-6man-rs-refresh-01
> 
> Dear all:
> 
> This documents contributes to the reduction of multicast noise, which
> is critical in many environments as discussed in the intro.
> > support for adopting this document should be directed to the mailing
> > list.  Editorial suggestions can be sent to the authors.  This
> > adoption call will end on April 10, 2015.
> >
> > Regards,
> >
> > Bob Hinden & Ole Trøan
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 17 Apr 2015 15:09:18 +0900

>         Title           : IPv6 Neighbor Discovery Optional Unicast RS/RA

I oppose adoption of the document as it stands.

I believe that document cannot meet its stated goal of "allow the operator
to choose whether unicast RS refresh is more efficient than periodic
multicast RAs, while preserving the timely and scalable reconfiguration
capabilities that a periodic RA model provides" in the presence of legacy
hosts that do not support this specification.

The reason is as follows: as noted in section 8.2, in the presence of hosts
that do not support this specification, routers must send periodic Router
Advertisements, otherwise the "timely and scalable reconfiguration
capabilities" cannot be maintained. This mode provides no power savings
over the status quo.

The document says that the network can operate in a mode where multicast
RAs are suppressed if it is known that all hosts on the link support the
specification. However:

   1. It is impossible to know with certainty when a legacy node has joined
   the network. If a legacy host's three initial Router Solicitations are
   missed, then that host will never again send an RA, and will never get IPv6
   connectivity unless it disconnects and reconnects. In contrast, today the
   node will get IPv6 connectivity as soon as it receives a periodic RA.
   2. In general, it is impossible to know when a legacy node has
   disconnected from the network. On some link layers this might be possible
   by relying on layer 2 information (e.g., wifi association state), but that
   requires that the router also be the layer 2 access point.
   3. This mode provides no benefit unless *all* the nodes on the network
   support the specification. Given that currently 0% of nodes support it, it
   can be expected that the vast majority of networks, where the operator does
   not tightly control the details of the IPv6 implementations in the clients,
   will see no benefit.

I would support adoption on condition that if the goal cannot be met, we
either abandon the work, or we qualify it with an applicability statement
that says that unicast RS refresh should only be used in special-purpose
networks where the operator controls both the devices and the network.

Also note: the above makes the document of limited use, but not harmful.
However, I think it's harmful, because it will cause operators and device
vendors who are familiar with IPv4 and its client-initiated, pull
configuration model (i.e., DHCP) to assume that periodic RAs are not
necessary, and therefore not implement them, because things "will work"
without them. I've been asked many times, "Why do we have to listen to RAs
anyway? Can't we just wake up and refresh the information we need? That
would be easier."

Over time, relying on this mechanism will cause IPv6 to lose the "timely
and scalable reconfiguration capabilities" provided by periodic RAs that
we're trying to preserve, because the lack of those capabilities will not
cause visible problems. That model works today in IPv4, but we should bear
in mind that in IPv4 there are lots of things that we're forced to do to do
because we can't announce network configuration updates to hosts in a
timely manner. For example, we have to use VRRP because it's impossible to
change the default gateway. Sometimes we use NAT because it's impossible to
renumber. And so on.

Cheers,
Lorenzo

---

From: <[email-masked]>
Date: Fri, 17 Apr 2015 09:02:57 +0000

Dear chairs, 

I support the adoption of this draft. 

Cheers,
Med

> -----Message d'origine-----
> De : ipv6 [mailto:[email-masked]] De la part de Bob Hinden
> Envoyé : vendredi 27 mars 2015 16:34
> À : IPv6 List
> Cc : 6man Chairs
> Objet : 6MAN WG Adoption Call: draft-nordmark-6man-rs-refresh-01
> 
> Editorial suggestions can be sent to the authors.  This adoption call will
> end on April 10, 2015.
> 
> Regards,
> 
> Bob Hinden & Ole Trøan

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 17 Apr 2015 12:00:15 +0000

Hi Lorenzo,

  1.  It is impossible to know with certainty when a legacy node has joined the network. If a legacy host's three initial

The absence of RS-flag in RS should enable the router to identify the presence of one or more legacy nodes on the network segment.

  1.  Router Solicitations are missed, then that host will never again send an RA

Ummm..you mean, router, not the host above !! :)

3. I agree, and such a scenario is well expected during the initial roll out. But that shouldn't dilute the long term benefit of this proposal, IMO.

Cheers,
Rajiv

On Apr 17, 2015, at 2:09 AM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:

On Sat, Mar 28, 2015 at 12:34 AM, Bob Hinden <[email-masked]<mailto:[email-masked]>> wrote:
        Title           : IPv6 Neighbor Discovery Optional Unicast RS/RA Refresh
        Authors         : Erik Nordmark
                          Andrew Yourtchenko
                          Suresh Krishnan

I believe that document cannot meet its stated goal of "allow the operator to choose whether unicast RS refresh is more efficient than periodic multicast RAs, while preserving the timely and scalable reconfiguration capabilities that a periodic RA model provides" in the presence of legacy hosts that do not support this specification.

The reason is as follows: as noted in section 8.2, in the presence of hosts that do not support this specification, routers must send periodic Router Advertisements, otherwise the "timely and scalable reconfiguration capabilities" cannot be maintained. This mode provides no power savings over the status quo.

The document says that the network can operate in a mode where multicast RAs are suppressed if it is known that all hosts on the link support the specification. However:

  1.  It is impossible to know with certainty when a legacy node has joined the network. If a legacy host's three initial Router Solicitations are missed, then that host will never again send an RA, and will never get IPv6 connectivity unless it disconnects and reconnects. In contrast, today the node will get IPv6 connectivity as soon as it receives a periodic RA.
  2.  In general, it is impossible to know when a legacy node has disconnected from the network. On some link layers this might be possible by relying on layer 2 information (e.g., wifi association state), but that requires that the router also be the layer 2 access point.
  3.  This mode provides no benefit unless *all* the nodes on the network support the specification. Given that currently 0% of nodes support it, it can be expected that the vast majority of networks, where the operator does not tightly control the details of the IPv6 implementations in the clients, will see no benefit.

I would support adoption on condition that if the goal cannot be met, we either abandon the work, or we qualify it with an applicability statement that says that unicast RS refresh should only be used in special-purpose networks where the operator controls both the devices and the network.

Also note: the above makes the document of limited use, but not harmful. However, I think it's harmful, because it will cause operators and device vendors who are familiar with IPv4 and its client-initiated, pull configuration model (i.e., DHCP) to assume that periodic RAs are not necessary, and therefore not implement them, because things "will work" without them. I've been asked many times, "Why do we have to listen to RAs anyway? Can't we just wake up and refresh the information we need? That would be easier."

Over time, relying on this mechanism will cause IPv6 to lose the "timely and scalable reconfiguration capabilities" provided by periodic RAs that we're trying to preserve, because the lack of those capabilities will not cause visible problems. That model works today in IPv4, but we should bear in mind that in IPv4 there are lots of things that we're forced to do to do because we can't announce network configuration updates to hosts in a timely manner. For example, we have to use VRRP because it's impossible to change the default gateway. Sometimes we use NAT because it's impossible to renumber. And so on.

Cheers,
Lorenzo
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 17 Apr 2015 10:36:37 -0700

[Sorry for the duplicate - corrected the from address]

On 4/16/15 11:09 PM, Lorenzo Colitti wrote:
> I believe that document cannot meet its stated goal of "allow the 
> operator to choose whether unicast RS refresh is more efficient than 
> periodic multicast RAs, while preserving the timely and scalable 
> reconfiguration capabilities that a periodic RA model provides" in the 
> presence of legacy hosts that do not support this specification.
>
> The reason is as follows: as noted in section 8.2, in the presence of 
> hosts that do not support this specification, routers must send 
> periodic Router Advertisements, otherwise the "timely and scalable 
> reconfiguration capabilities" cannot be maintained. This mode provides 
> no power savings over the status quo.
Lorenzo,

I think you must be making some unstated assumptions in coming to that 
conclusion, because it does not match my conclusion.

This specification allows a host to go to sleep and turn of its radio, 
which includes not being awoken by any multicast RA, and when it wakes 
up it can send a RS to refresh the information that might have changed 
while it was asleep. That provides power savings for that host.

>
> The document says that the network can operate in a mode where 
> multicast RAs are suppressed if it is known that all hosts on the link 
> support the specification. However:
>
>  1. It is impossible to know with certainty when a legacy node has
>     joined the network. If a legacy host's three initial Router
>     Solicitations are missed, then that host will never again send an
>     RA, and will never get IPv6 connectivity unless it disconnects and
>     reconnects. In contrast, today the node will get IPv6 connectivity
>     as soon as it receives a periodic RA.
>

As I pointed out in some earlier email, a host which is subject to 
packet loss so that the initial RAs are lost does not see any useful 
service. Your "as soon as" is currently as bad as 30 minutes (and 
separate discussions about MaxRtrAdvInterval might increase this to 6 
hours). I don't know which host will wait for that long. Thus I don't 
think you can claim that legacy hosts work under such packet loss 
conditions.

Regards,
     Erik

>  1. In general, it is impossible to know when a legacy node has
>     disconnected from the network. On some link layers this might be
>     possible by relying on layer 2 information (e.g., wifi association
>     state), but that requires that the router also be the layer 2
>     access point.
>  2. This mode provides no benefit unless *all* the nodes on the
>     network support the specification. Given that currently 0% of
>     nodes support it, it can be expected that the vast majority of
>     networks, where the operator does not tightly control the details
>     of the IPv6 implementations in the clients, will see no benefit.
>
>
> I would support adoption on condition that if the goal cannot be met, 
> we either abandon the work, or we qualify it with an applicability 
> statement that says that unicast RS refresh should only be used in 
> special-purpose networks where the operator controls both the devices 
> and the network.
>
> Also note: the above makes the document of limited use, but not 
> harmful. However, I think it's harmful, because it will cause 
> operators and device vendors who are familiar with IPv4 and its 
> client-initiated, pull configuration model (i.e., DHCP) to assume that 
> periodic RAs are not necessary, and therefore not implement them, 
> because things "will work" without them. I've been asked many times, 
> "Why do we have to listen to RAs anyway? Can't we just wake up and 
> refresh the information we need? That would be easier."
>
> Over time, relying on this mechanism will cause IPv6 to lose the 
> "timely and scalable reconfiguration capabilities" provided by 
> periodic RAs that we're trying to preserve, because the lack of those 
> capabilities will not cause visible problems. That model works today 
> in IPv4, but we should bear in mind that in IPv4 there are lots of 
> things that we're forced to do to do because we can't announce network 
> configuration updates to hosts in a timely manner. For example, we 
> have to use VRRP because it's impossible to change the default 
> gateway. Sometimes we use NAT because it's impossible to renumber. And 
> so on.
>
> Cheers,
> Lorenzo
>
>

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 17 Apr 2015 10:34:06 -0700

Lorenzo,

Regards,
     Erik

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 20 Apr 2015 22:54:28 +0900

On Sat, Apr 18, 2015 at 2:34 AM, Erik Nordmark <[email-masked]> wrote:

>> hosts that do not support this specification, routers must send periodic
>> Router Advertisements, otherwise the "timely and scalable reconfiguration
> which includes not being awoken by any multicast RA, and when it wakes up
> it can send a RS to refresh the information that might have changed while
> it was asleep. That provides power savings for that host.
>

But then the "timely and scalable reconfiguration capabilities" cannot be
maintained. The network can't tell that host about any new information,
because that host won't receive it. The host will only receive it when it
wakes up next.

> As I pointed out in some earlier email, a host which is subject to packet
> loss so that the initial RAs are lost does not see any useful service. Your
> "as soon as" is currently as bad as 30 minutes (and separate discussions
> about MaxRtrAdvInterval might increase this to 6 hours). I don't know which
> host will wait for that long. Thus I don't think you can claim that legacy
> hosts work under such packet loss conditions.
>

It depends how frequent the RAs are. In general purpose networks, they
might be more frequent. Also, any node joining may cause a solicited
multicast RA. Depending on the application, "after 10 minutes" may be a lot
better than "never".

What about points #2 and #3?

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 20 Apr 2015 10:41:52 -0700

On 4/20/15 6:54 AM, Lorenzo Colitti wrote:
> But then the "timely and scalable reconfiguration capabilities" cannot 
> be maintained. The network can't tell that host about any new 
> information, because that host won't receive it. The host will only 
> receive it when it wakes up next.
The host will take no action on any state until it wakes up. "timely" 
implies that hosts do not take any actions on stale state, and with RS 
refresh they would not. Hence it is very "timely".

Note that without RS refresh hosts can take action on stale state if the 
packet loss experienced by the RAs is such that they miss e.g., the RAs 
that set the preferred lifetime for a prefix to zero, or set the default 
router lifetime to zero. Thus RFC 4861 operates in a probabilistic mode 
- which made sense when all networks were wires and one could assume the 
packet loss were independent events. Walking out of range of a radio 
does not result in independent events.

Thus using RS refresh makes the "timely" work better than in RFC 4861.

> multicast RA. Depending on the application, "after 10 minutes" may be 
> a lot better than "never".
For the network deployments where frequency of RAs is a concern, the 
desire seems to be to increase the time.
If you read e.g. section 5.1 in 
draft-yourtchenko-colitti-nd-reduce-multicast you'll see that.
Those are also the networks where resilient-RS makes sense.

> What about points #2 and #3?
I think this email thread should about WG adoption and not WG last call 
or even about WG discussion.
Are you arguing that all your points in the draft need to be addressed 
to your satisfaction before it can even become a WG draft?
That isn't how an IETF working group is supposed to operate.

FWIW your #2 was a statement of fact, but not clear how it is relevant 
to the discussion. Seems to be related to your assumption that any 
multicast RA makes this null and void, which is incorrect.
#3 was AFAICT a restatement of your conclusion based on some unstated 
assumptions. I already tried to guess at that unstated assumption in my 
first respond and I responded based on that. Was my guess wrong? Did I 
you make some other unstated assumptions?

Regards,
    Erik

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 21 Apr 2015 10:21:28 +0900

On Tue, Apr 21, 2015 at 2:41 AM, Erik Nordmark <[email-masked]> wrote:

> router lifetime to zero. Thus RFC 4861 operates in a probabilistic mode -
> which made sense when all networks were wires and one could assume the
> packet loss were independent events. Walking out of range of a radio does
> not result in independent events.
>

Wait - are you arguing that soliciting information when the refresh timer
expires, or when the node wakes up, is more "timely" than the network just
sending an RA and having the node receive it? That doesn't make sense.

If what you're saying is that the sleeping node is going to ignore RAs
anyway, then you don't need an RS refresh option for the node to send an RS
and receive an RA when it wakes up. That's already possible.

If what you're saying is that the node won't receive the RA due to general
packet loss, then that can happen even for a solicited RA.

> draft-yourtchenko-colitti-nd-reduce-multicast you'll see that.

The document says that if you want to reduce multicast, you can increase
the RA interval. Personally, I don't think that makes sense, because one RA
every half hour is a tiny amount of traffic, which is trivial on any
general-purpose network.

> I think this email thread should about WG adoption and not WG last call or
> even about WG discussion.
> Are you arguing that all your points in the draft need to be addressed to
> your satisfaction before it can even become a WG draft?

No. I am worried that this document cannot meet its goals, and even if it
does not, after adoption we will be unable to abandon it and instead ship
something that does not meet its goals.

Perhaps the issue here is that we don't agree on a problem statement, or
more accurately, what we're trying to accomplish with this drafts.

FWIW your #2 was a statement of fact, but not clear how it is relevant to
> the discussion. Seems to be related to your assumption that any multicast
> RA makes this null and void, which is incorrect.
>

It is relevant to the discussion because the draft proposes a mode where
periodic multicast RAs are suppressed. My point #2 observes that it's not
possible to exit that mode because there is no way to know whether legacy
hosts have left the network.

> first respond and I responded based on that. Was my guess wrong? Did I you
> make some other unstated assumptions?
>

My assumption is that in order to allow nodes to be updated dynamically,
hosts will still need to listen to periodic RAs. If you're saying that
that's now optional, then that's quite a change to the existing specs, and
that statement should be made very very clear in the draft.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 21 Apr 2015 10:35:15 +0900

>         Title           : IPv6 Neighbor Discovery Optional Unicast RS/RA

All,

I think the root of my objections to this draft is that it proposes what is
in effect a substantial change to the current configuration model in IPv6
networks without saying so explicitly.

Currently, we have an easy-to understand, easy-to-reason-about model:
periodic RAs periodically notify everyone on link of the current
configuration information, and nodes that don't want to wait for such
periodic configuration information can solicit said information by sending
a request.

With this document, it's not clear what model is proposed.

It seems to me that this document is proposing a model where there are no
periodic RAs being sent. That's something that can be proposed, but if so,
we need to carefully evaluate the implications to the architecture, and how
switching to such a model affects the properties of the model we currently
have. We also need to make sure we understand how that model works for
hosts that a) don't support either resilient RS or this draft, b) support
resilient RS but not this draft.

If I am incorrect and the document is not proposing such a model, then it
should not mention this as a possibility. But then we need to understand
where the power savings are.

Cheers,
Lorenzo

---

From: 神明達哉 <[email-masked]>
Date: Tue, 21 Apr 2015 09:44:52 -0700

At Tue, 21 Apr 2015 10:35:15 +0900,

> networks without saying so explicitly.
[...]
> where the power savings are.

I'm not sure if these points are too critical to adopt the document,
but I guess it may be related to the higher-level question that I
asked in response to this call:
http://www.ietf.org/mail-archive/web/ipv6/current/msg22411.html
(and that hasn't been answered).

I was not sure if we had agreed on sufficient need for making
non-trivial (if not substantial) changes to a core part of the
protocol.  If what Lorenzo was trying to say is a different form of
what I tried to ask, I tend to agree with part of his argument.
Although I'm not necessarily opposed to adopting the document just
because of that, I think it's reasonable to request clarifying the
problem statement and expected goal.

--
JINMEI, Tatuya

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 21 Apr 2015 10:02:15 -0700

On 4/20/15 6:21 PM, Lorenzo Colitti wrote:
> On Tue, Apr 21, 2015 at 2:41 AM, Erik Nordmark <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>         But then the "timely and scalable reconfiguration
>         capabilities" cannot be maintained. The network can't tell
>         that host about any new information, because that host won't
>         receive it. The host will only receive it when it wakes up next.
>
>     The host will take no action on any state until it wakes up.
>     "timely" implies that hosts do not take any actions on stale
>     state, and with RS refresh they would not. Hence it is very "timely".
>
>     Note that without RS refresh hosts can take action on stale state
>     if the packet loss experienced by the RAs is such that they miss
>     e.g., the RAs that set the preferred lifetime for a prefix to
>     zero, or set the default router lifetime to zero. Thus RFC 4861
>     operates in a probabilistic mode - which made sense when all
>     networks were wires and one could assume the packet loss were
>     independent events. Walking out of range of a radio does not
>     result in independent events.
>
> Wait - are you arguing that soliciting information when the refresh 
> timer expires, or when the node wakes up, is more "timely" than the 
> network just sending an RA and having the node receive it? That 
> doesn't make sense.
No, that wasn't what I said. I'll repeat. (But perhaps it is better for 
me to explain this over the phone instead of bothering the whole list?)
1. If there is no packet loss then the RS refresh is as timely as the 
host waking up to receive the unsolicited RAs. This is because the host 
will not use any of the state from the RA until it is time for it to 
wake up.
2. In the presence of packet loss things are more complex, but it is 
clear that unsolicited RAs do not provide any time guarantees. One can 
only make a probabilistic argument (assuming independent event packet 
loss) of how likely it is for a host to have received the information 
after N RAs have been sent. RS refresh provides has a lower expected 
delay; the host will retransmit the RS (following resilient-RS 
retransmissions) until it gets an RA. With unsolicited RAs the host 
would be waiting up to 15 minutes (or 6 hours with a larger maxra) for a 
the next unsolicited RA. With RS refresh it would send a new RS after a 
second. If the host implementations don't act on the state until RS 
refresh has succeeded (or the host has detected it has moved to a 
different link and received the RAs for that link), then the amount of 
time during which the host operates on stale state becomes zero. But in 
practice a host might act on the, potentially stale, state after the 
first RS refresh.

Hence for hosts sleeping on a schedule
   if we don't care about packet loss, then unsolicited and refresh are 
the same.
   if we care about packet loss, then refresh has a lower average delay.

> anyway, then you don't need an RS refresh option for the node to send 
> an RS and receive an RA when it wakes up. That's already possible.
There is no RFC which suggests or recommends sending a RS after wakeup. 
RFC 4861 is very prescriptive on when RS can and can not be sent.

>
> If what you're saying is that the node won't receive the RA due to 
> general packet loss, then that can happen even for a solicited RA.
See above.

>
>         It depends how frequent the RAs are. In general purpose
>         networks, they might be more frequent. Also, any node joining
>         may cause a solicited multicast RA. Depending on the
>         application, "after 10 minutes" may be a lot better than "never".
>
>     For the network deployments where frequency of RAs is a concern,
>     the desire seems to be to increase the time.
> The document says that if you want to reduce multicast, you can 
> increase the RA interval. Personally, I don't think that makes sense, 
> because one RA every half hour is a tiny amount of traffic, which is 
> trivial on any general-purpose network.

IPv6 needs to apply to a large range of network technologies, just like 
IPv4 does.
I think that is the fundamental disconnect here.

>     I think this email thread should about WG adoption and not WG last
>     call or even about WG discussion.
>     Are you arguing that all your points in the draft need to be
>     addressed to your satisfaction before it can even become a WG draft?
> No. I am worried that this document cannot meet its goals, and even if 
> it does not, after adoption we will be unable to abandon it and 
> instead ship something that does not meet its goals.
>
> Perhaps the issue here is that we don't agree on a problem statement, 
> or more accurately, what we're trying to accomplish with this drafts.

You've said that for > 2 years now, but never provided any useful 
suggestions.

AFAICT you are in the rough here. But up to the WG chairs to decide.

Regards,
    Erik

>
>     FWIW your #2 was a statement of fact, but not clear how it is
>     relevant to the discussion. Seems to be related to your assumption
>     that any multicast RA makes this null and void, which is incorrect.
>
>
> It is relevant to the discussion because the draft proposes a mode 
> where periodic multicast RAs are suppressed. My point #2 observes that 
> it's not possible to exit that mode because there is no way to know 
> whether legacy hosts have left the network.
>
>     #3 was AFAICT a restatement of your conclusion based on some
>     unstated assumptions. I already tried to guess at that unstated
>     assumption in my first respond and I responded based on that. Was
>     my guess wrong? Did I you make some other unstated assumptions?
>
>
> My assumption is that in order to allow nodes to be updated 
> dynamically, hosts will still need to listen to periodic RAs. If 
> you're saying that that's now optional, then that's quite a change to 
> the existing specs, and that statement should be made very very clear 
> in the draft.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 21 Apr 2015 10:10:43 -0700

On 4/20/15 6:35 PM, Lorenzo Colitti wrote:
> I think the root of my objections to this draft is that it proposes 
> what is in effect a substantial change to the current configuration 
> model in IPv6 networks without saying so explicitly.
>
> periodic configuration information can solicit said information by 
> sending a request.

Lorenzo,
which RFC states "nodes that don't want to wait for such periodic 
configuration information can solicit said information by sending a 
request"?
AFAIK that isn't allowed. If you do that you would be violating this 
MUST in RFC 4861:
    Once the host sends a Router Solicitation, and receives a valid
    Router Advertisement with a non-zero Router Lifetime, the host MUST
    desist from sending additional solicitations on that interface, until
    the next time one of the above events occurs.

> With this document, it's not clear what model is proposed.
AFAICT the document is clear on what it is proposing. If others find it 
unclear we can definitely add some wording.

You seem to disagree with the change in the model? Or perhaps you don't 
since the paragraph above seems to say that that the model already 
allows for "pull" by sending RSes? Even though that is not allowed in 
RFC 4861!!

So I'm confused by your statements.

Regards,
     Erik

>
> It seems to me that this document is proposing a model where there are 
> no periodic RAs being sent. That's something that can be proposed, but 
> if so, we need to carefully evaluate the implications to the 
> architecture, and how switching to such a model affects the properties 
> of the model we currently have. We also need to make sure we 
> understand how that model works for hosts that a) don't support either 
> resilient RS or this draft, b) support resilient RS but not this draft.
>
> If I am incorrect and the document is not proposing such a model, then 
> it should not mention this as a possibility. But then we need to 
> understand where the power savings are.
>
> Cheers,
> Lorenzo
>
>

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 21 Apr 2015 10:23:18 -0700

> (and that hasn't been answered).
Jinmei,

Your email had some editorial corrections, which will be applied.

The question seemed to be addressed to the WG and not the authors, which 
is a sad excuse for not responding.
Your question was:

It is up to the WG chairs to gauge consensus, and I don't think there 
has been any explicit call on whether we need work to reduce ND 
multicast in general. (There are various techniques which can already be 
used such as setting O=0 to avoid multicast NS from hosts, and adjust 
timers, etc).

My personal take is that we don't need any open-ended protocol work 
here, but it would useful to have some (v6ops?) documents with 
operational recommendations e.g. for WiFi networks. Others have 
expressed concerns that for WiFI vendors are busy implementing various 
forms of filtering of multicast, and it isn't clear to what extent those 
solutions/hacks (depending on your point of view) will cause problems in 
the future. Hence some recommendations would be helpful.

One separate output of the efficient-nd design team is that we need to 
ask the WG whether there is interest in improving DAD, but that is more 
about DAD robustness than efficiency. I had that question on the slides 
in Dallas, but the question wasn't asked of the room. Bob and Ole 
suggested we do that question on the mailing list.

> problem statement and expected goal.

Please send text on what you would want to see as (part of) PS and goals.

Thanks,
    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 21 Apr 2015 11:21:17 -0700

Jinmei,

Thanks for your comments.
Responses below.

> What should the host do if this is 0?  Should it just keep sending
Good catch. I'm inclined to just make zero be reserved, and state that 
hosts should ignore an RTO if the Refresh Time is zero - i.e. treat the 
RA as if the RTO was not present.
Is that sufficient?

We could pick some arbitrary number (10 seconds?) and say that it is a 
lower bound, but I don't know how to pick such a number.

>     Section 9 says that routers SHOULD report such inconsistencies to
Fixed.

>     security keys), or the routers detect any RSs which do not include
I think "could be" is better since it avoids potential confusion with 
uppercase MAY.
>     hosts until those hosts refresh by sending a RS.
Fixed.

Thanks,
    Erik

---

From: 神明達哉 <[email-masked]>
Date: Tue, 21 Apr 2015 11:51:16 -0700

At Tue, 21 Apr 2015 11:21:17 -0700,

> RA as if the RTO was not present.

I think so.

> lower bound, but I don't know how to pick such a number.

Some more conservative lower bound may also help, but I don't know how
to pick one either.  It's probably enough if you add a note that care
should be taken if this field is set to some small value so it won't
cause unexpected RS storm.

> I think "could be" is better since it avoids potential confusion with

I'm fine with 'could be'.

--
JINMEI, Tatuya

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Apr 2015 23:19:36 +0900

On Wed, Apr 22, 2015 at 2:02 AM, Erik Nordmark <[email-masked]> wrote:

> With unsolicited RAs the host would be waiting up to 15 minutes (or 6
> hours with a larger maxra) for a the next unsolicited RA. With RS refresh
> it would send a new RS after a second.

Oh, I see what you mean now. But I think you are assuming that unmodified
hosts will simply ignore periodic multicast RAs, and then not send an RS
when they wake up. That sort of behaviour is a violation of the standard
(because the host is not processing the multicast RAs) and is guaranteed to
cause breakage.

Also: I'd argue that nothing stops a node from sending RSes using the
resilient RS retransmit algorithm when it wakes up (see below). You don't
need any of this document for a host to be able to do that.

> RFC 4861 is very prescriptive on when RS can and can not be sent.

RFC 4861 says a host can send an RA when it "re-attaches to a link after
being detached for some time". I'd argue that's the case here. The host is
in effect disconnected, because it's asleep and not processing multicast RA
(and maybe not even unicast packets). If you think hosts might not do that
because it's not clearly allowed by the standard, then fine, let's clarify
the standard. But we don't need to change the semantics.

> I think that is the fundamental disconnect here.

IPv4 applies to a large range of network technologies not because of the
standards, but because implementations are, let's say, "creative". For
example: ARP is a broadcast packet, right? In how many networks is ARP
*actually* a broadcast that goes to everybody? I'd argue that there is no
large wireless network where ARP is actually broadcast - because if there
were, that network would fall over. :-)

> You've said that for > 2 years now, but never provided any useful

But it's impossible for me, or anyone else, to provide a useful suggestion
without a problem statement.

This document proposes a solution. I don't like this solution because I
think it is not useful except if limited cases, and in some cases it is
harmful, and I think that on balance, the harm outweighs the good. So I
ask: "Why do we need this? What justifies a change to the IPv6
configuration model, such that we're changing it from a pure push model to
a hybrid push/pull model and possibly to a pull-only model? Why are we not
carefully considering the reasons for making the change, and instead only
documenting the change without asking ourselves why?"

Suppose for the sake of argument that your draft isn't actually solving any
real problem. There would be no suggestion anyone could possibly make other
than "please describe the problems that need to be solved, and let's design
a solution together". And I don't think "I waited two years and there were
no useful suggestions, so we should adopt this solution" is an argument
that makes sense.

Assuming it has actually been two years, then in those two years I can
recall the following use cases:

1. Mobile network paging channel excessive usage. I think the numbers in
that argument were dubious, because in any mobile network today the vast
majority of devices is sending packets *way* more often than one every half
an hour. But even supposing they weren't, that problem can be fixed by
increasing the maximum RA interval and/or piggybacking RAs onto unicast
traffic, and/or sending an RA to the node opportunistically right after the
node sends a packet and thus has the channel grant.

2. Excessive multicast use on wifi. Most of this problem problem can be
solved by sending solicited RAs unicast. RA isn't really a high-order
contributor to this problem anyway - bonjour is much worse, and so is ARP.

3. Low-battery nodes. Here you can construct an argument that justifies
anything: all you need to do is posit the existence of a node whose
constraints make it a poor fit for the periodic RA model, and then decide
to optimize for that node. For example, you can posit a node that is
super-constrained, whose battery has to last years of sending one packet
per day, but cannot disconnect because it needs to receive unicast packets
on someone else's schedule instead of the natural option for a constrained
device of *disconnecting* and only polling periodically. Even here, though
- why are these devices not using special link layers? For example, 802.11
in particular is terrible at power consumption for this sort of device.
It's a high-speed technology intended to provide XXX megabit speeds, not
optimizing low power. Why are we trying to use it?

I have repeatedly suggested: let's look at the *real* harm in these cases,
and let's see how far we can go without changing the protocol. But I think
you've just kept coming back with suggestions on how to fix the protocol
without first discussing how and how much it's broken.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Apr 2015 23:27:16 +0900

On Wed, Apr 22, 2015 at 2:10 AM, Erik Nordmark <[email-masked]> wrote:

> I think the root of my objections to this draft is that it proposes what
>> is in effect a substantial change to the current configuration model in
>> IPv6 networks without saying so explicitly.
>>
> AFAIK that isn't allowed. If you do that you would be violating this MUST
> in RFC 4861:

As I said in my other reply, I think the event that occurs here is "The
host re-attaches to a link after being detached for some time." To me, if
you can't receive packets, you're arguably not attached.

I agree that this is interpretation is not particularly clear, but it's
also something that can be clarified without substantially changing the
semantics.

> since the paragraph above seems to say that that the model already allows
> for "pull" by sending RSes? Even though that is not allowed in RFC 4861!!
>

I disagree with changing the model in such a way that push configuration
becomes optional (either through explicit design, or de facto, over time,
due to sloppy / buggy implementations or developers / network operators
used to IPv4-style pull configuration).

Today, a node cannot rely only on periodic refresh without losing
information, unless it's prepared to engage in a relatively heavyweight
process of sending multicast RS and waiting for RA (or doing DNA). This
document will change that.

---

From: 神明達哉 <[email-masked]>
Date: Thu, 23 Apr 2015 11:32:53 -0700

At Tue, 21 Apr 2015 10:23:18 -0700,

> Please send text on what you would want to see as (part of) PS and goals.

It was very vague and abstract level of thought when I wrote this, so
I wouldn't have been able to propose any specific text.  But I guess
Lorenzo seemed to answer the request pretty well in his later message:
http://www.ietf.org/mail-archive/web/ipv6/current/msg22477.html

--
JINMEI, Tatuya

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 23 Apr 2015 14:55:15 -0700

On 4/22/15 7:27 AM, Lorenzo Colitti wrote:
> On Wed, Apr 22, 2015 at 2:10 AM, Erik Nordmark <[email-masked] 
>         I think the root of my objections to this draft is that it
>         proposes what is in effect a substantial change to the current
>         configuration model in IPv6 networks without saying so explicitly.
>
>         Currently, we have an easy-to understand, easy-to-reason-about
>         model: periodic RAs periodically notify everyone on link of
>         the current configuration information, and nodes that don't
>         want to wait for such periodic configuration information can
>         solicit said information by sending a request.
>
>
>     Lorenzo,
>     configuration information can solicit said information by sending
>     a request"?
>     AFAIK that isn't allowed. If you do that you would be violating
>     this MUST in RFC 4861:
> As I said in my other reply, I think the event that occurs here is 
> "The host re-attaches to a link after being detached for some time." 
> To me, if you can't receive packets, you're arguably not attached.

Lorenzo,

If you re-read your own text above you'll find that is says "nodes that 
don't want to wait for such periodic ..." and I was responding to that 
statement
because it seems incorrect. So I think you need some more work on your 
description of existing model that you you claim is easy to understand 
and easy to reason about, since you don't seem to be able to describe it 
correctly.

If you want to fold in DNA aspects (re-attaching to a link - possibly 
the same or different) as you are trying to, then I suspect your model 
description will need more work. Might be better to write an internet 
draft instead of doing this back and forth over email. That would also 
ensure that we can get a permanent record of the model.

But might not be as easy to understand and reason about as you claim.

Regards,
    Erik

>
> I agree that this is interpretation is not particularly clear, but 
> it's also something that can be clarified without substantially 
> changing the semantics.
>
>     AFAICT the document is clear on what it is proposing. If others
>     find it unclear we can definitely add some wording.
>
>     You seem to disagree with the change in the model? Or perhaps you
>     don't since the paragraph above seems to say that that the model
>     already allows for "pull" by sending RSes? Even though that is not
>     allowed in RFC 4861!!
>
>
> I disagree with changing the model in such a way that push 
> configuration becomes optional (either through explicit design, or de 
> facto, over time, due to sloppy / buggy implementations or developers 
> / network operators used to IPv4-style pull configuration).
>
> information, unless it's prepared to engage in a relatively 
> heavyweight process of sending multicast RS and waiting for RA (or 
> doing DNA). This document will change that.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 23 Apr 2015 14:56:38 -0700

Jinmei,

That email doesn't have any useful text which can be included in the 
document as a problem statement. To quote:
"1. Mobile network paging channel excessive usage. I think the numbers 
in that argument were dubious, because in any mobile network today the 
vast majority of devices is sending packets *way* more often than one 
every half an hour. But even supposing they weren't, that problem can be 
fixed by increasing the maximum RA interval and/or piggybacking RAs onto 
unicast traffic, and/or sending an RA to the node opportunistically 
right after the node sends a packet and thus has the channel grant.

3. Low-battery nodes. Here you can construct an argument that justifies 
anything: all you need to do is posit the existence of a node whose 
constraints make it a poor fit for the periodic RA model, and then 
decide to optimize for that node. For example, you can posit a node that 
is super-constrained, whose battery has to last years of sending one 
packet per day, but cannot disconnect because it needs to receive 
unicast packets on someone else's schedule instead of the natural option 
for a constrained device of *disconnecting* and only polling 
periodically. Even here, though - why are these devices not using 
special link layers? For example, 802.11 in particular is terrible at 
power consumption for this sort of device. It's a high-speed technology 
intended to provide XXX megabit speeds, not optimizing low power. Why 
are we trying to use it?"

That is mostly Lorenzo's personal views about different potential 
problems, and isn't something I can cut and paste into the document as a 
PS, which is really what "send text" means.

Note that the document already has a goals section. If you disagree with 
it, then please suggest edits, additions, removals.

Thanks,
    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 23 Apr 2015 14:55:04 -0700

Jinmei,

Thanks,
    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 23 Apr 2015 15:47:19 -0700

On 4/22/15 7:19 AM, Lorenzo Colitti wrote:
>
>         Perhaps the issue here is that we don't agree on a problem
>         statement, or more accurately, what we're trying to accomplish
>         with this drafts.
>
>
> But it's impossible for me, or anyone else, to provide a useful 
> suggestion without a problem statement.
Lorenzo,

I hope you are seeing that you are going in circles. You ask for a 
problem statement, and when I point you at one (such as the Goals 
section in this draft), you say it is insufficient for what you think it 
should say. When I ask what you want it to include you say it is 
impossible for you to help since an acceptable (to you) problem 
statement isn't written yet.

I think the fundamental difference in opinion between you and me on this 
subject is that you don't care of communities that work on hosts that 
sleep on schedule end up doing whatever they want to IPv6 Neighbor 
Discovery (at least you have said at the mike that you don't care about 
those types of devices - and that they can go to some other WG). Thus 
time and again you dismiss any arguments relating to such hosts. Such an 
attitude is likely to cause fragmentation of the protocols and 
implementations for IPv6.

I really really really want to avoid fragmenting IPv6 and ND into 
different protocols for different types of devices. I think such 
fragmentation is harmful to IPv6 and its application across a large set 
of networks and devices - many of which do not yet use IP technology.

I hope there are others in the IPv6 working group that care about 
avoiding fragmentation while applying IPv6 to different IoT devices and 
other constrained devices, and the call for WG adoption of this draft 
seem to already have half a dozen supporters. That is promising to those 
of us that want to avoid fragmentation.

Regards,
    Erik

---

From: Erik Kline <[email-masked]>
Date: Tue, 28 Apr 2015 00:27:51 +0900

A question comes to mind: what might the operational guidance be for
setting the refresh timer value in the RA?

Observation: it almost certainly shouldn't be /longer/ than the router
lifetime, even if the prefix lifetimes are infinite.

Reasonable stab in the dark: refresh timer value in the RA should be
in the neighborhood of some fraction (1/2, 2/3) * min(router lifetime,
prefix lifetimes...).

If that turns out to be the case, then the host can compute this timer
value for itself, sleep on its own schedule, and wake up whenever it
wants and send a unicast RS.  At that point this isn't a protocol
change but rather an operational document.  [1]

At the very least, this is a simple enough experiment to perform for
people writing the code on the affected devices (doesn't require
router vendor code changes).  Has anybody done this and measured the
outcome?

-Erik the Lesser

[1]  Note that the node MUST to be ready to basically re-attach from
scratch in the event that the router has gone (I swapped my IoT device
access point for a new model, and it got a new prefix too, while
everyone listening was asleep, for example).  So guessing a wrong
timer value must be non-fatal for the node.  At worst it won't be
"optimal" but i'm curious to know what the impact of deviation from
"optimal" would really be in these networks, given that nodes are all
going to go for the longest possible timer value.

---

From: Ole Troan <[email-masked]>
Date: Mon, 27 Apr 2015 20:26:19 +0200

Erik,

> lifetime, even if the prefix lifetimes are infinite.

indeed.

> router vendor code changes).  Has anybody done this and measured the

I think this was briefly discussed on the mailing list. the short-coming with this scheme would be the lack of explicit information from the network to the host and from the host to the network that this is supported.

it would at least be a lot harder for the network to identify and deal with legacy hosts without explicit notification of support.

cheers,
Ole

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 28 Apr 2015 08:23:23 -0700

> router vendor code changes).  Has anybody done this and measured the
Erik,
the above wouldn't work because a RFC 4861 compliant router can delay 
sending the solicited RA (and multicast it) hence the host would have to 
wait for seconds with (at least) the radio powered on when it otherwise 
would have gone back to sleep after a few milliseconds.

That RA delay is why rs-refresh says that routers which implement the 
specification should unicast the solicited RAs immediately. Furthermore, 
the RTO option indicates to the hosts that the routers are in fact 
implementing rs-refresh which includes the immediate RA response.

That should all be covered in the document; I don't know if you've read 
it and understood it. I'd welcome suggestions for how to make this more 
clear if it turns out that it is not.

As an aside, you seem to think that a protocol specification is merely 
about packet formats. However, protocol specifications include 
behaviors, protocol constants, default values, statements about what is 
mandatory to implement etc.
The behaviors might be things that are conditionally mandatory or 
recommended i.e., of the form "if you implement option foo, then you 
SHOULD use binary exponential backoff for the retransmit timer."

Do you have any technical issues for the WG not pursuing this work?
Any non-technical reasons why not?
Please provide sufficient detail so that the WG can properly evaluate 
your concerns.

Thanks,
    Erik