Subject: [dhcwg] Failed WGLC summary for draft-ietf-dhc-dhcpv6-prefix-pool-opt

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 23 Apr 2013 20:33:44 +0200

This mail summarizes Work Group Last Call on
draft-ietf-dhc-dhcpv6-prefix-pool-opt announced on March 24th and
concluded on April 8th, 2013. Sorry for the late announcement.

The chairs feel that this document has failed WGLC as there was
insufficient consensus to move forward. This does not mean end of life
for this draft - it remains a valid WG item and people are encouraged to
work on it.

There was also a late IPR disclosure that the working group was not
aware of it when the last call started. Existence of IPR claims may have
affected the response from WG. Remember that IPR must be disclosed as
early as possible (preferably in the individual draft phase).

Having said that, there were some good technical comments received.
Authors are advised to address them and continue work on this draft. It
seems reasonable to focus on a better explanation of why this is a real
problem and why the use case is practical rather than theoretical one.
But the most important issue here is a lack of support. Please address
the comments made in this WGLC, find people who are interested in this
work and are ready to voice their support when the time comes and only
then ask for another WGLC.
Bernie & Tomek

---

From: "Leaf Yeh" <[email-masked]>
Date: Wed, 24 Apr 2013 21:53:17 +0800

> There was also a late IPR disclosure that the working group was not aware
of it when the last call started. Existence of IPR claims may have affected
the response from WG. Remember that IPR must be disclosed as early as
possible (preferably in the individual draft phase).

That's my fault though I am not Huawei employee now, but the IPR disclosure
from Huawei sounds an defensive (& harmless) IPR, right?

> It seems reasonable to focus on a better explanation of why this is a real

We called for interests many times in the ML of the DHC-WG
(http://www.ietf.org/mail-archive/web/dhcwg/current/maillist.html ) and have
some discussion in the ML of routing-discussion
(http://www.ietf.org/mail-archive/web/routing-discussion/current/maillist.ht
ml ) before. The reason why we need OPTION_PREFIX_POOL is explicit for the
automatic route aggregation at provider edge (PE) router, because the
DHCPv6-PD mechanism will introduce too many route entries at PE router for
every customer network behind the customer edge (CE) routers (DHCPv6-PD
clients).

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tomek Mrugalski
Sent: Wednesday, April 24, 2013 2:34 AM
To: dhcwg
Subject: [dhcwg] Failed WGLC summary for
draft-ietf-dhc-dhcpv6-prefix-pool-opt

This mail summarizes Work Group Last Call on
draft-ietf-dhc-dhcpv6-prefix-pool-opt announced on March 24th and concluded
on April 8th, 2013. Sorry for the late announcement.

The chairs feel that this document has failed WGLC as there was insufficient
consensus to move forward. This does not mean end of life for this draft -
it remains a valid WG item and people are encouraged to work on it.

There was also a late IPR disclosure that the working group was not aware of
it when the last call started. Existence of IPR claims may have affected the
response from WG. Remember that IPR must be disclosed as early as possible
(preferably in the individual draft phase).

Having said that, there were some good technical comments received.
Authors are advised to address them and continue work on this draft. It
seems reasonable to focus on a better explanation of why this is a real
problem and why the use case is practical rather than theoretical one.
But the most important issue here is a lack of support. Please address the
comments made in this WGLC, find people who are interested in this work and
are ready to voice their support when the time comes and only then ask for
another WGLC.
Bernie & Tomek

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 24 Apr 2013 16:46:14 +0200

> from Huawei sounds an defensive (& harmless) IPR, right?
The nature of the IPR claim seems indeed benign. Its content is not an
issue, its late disclosure is.

> some discussion in the ML of routing-discussion
Work Group Last Call serves 3 purposes. First is to gather any last
moment comments. The second is to confirm whether there is still
consensus that that working group still supports the work in question.
This was expressed before when the WG decided to adopt a draft. The
consensus (or lack of thereof) may change over time for various reasons:
problem is better understood, no longer relevant, other solutions may
appear, IPR claims may be disclosed in the mean time etc.
The third reason for WGLC is to confirm that the group thinks it is
ready for publication.

Consensus and readiness for publication cannot be implied. It must be
explicitly expressed at the time of last call. Otherwise we would have
to publish everything that was ever adopted, which would be a bad thing.

With may chair hat off, I think people are somewhat interested in
solving the problem, but don't like the specific solution too much. Look
at the comments you got - "it's a problem that we ought to solve", "I am
on the fence with the need for this" or "I will count myself as
'abstain'" is a very different statement than expected "I think this is
the right solution, the draft is ready and I support it moving forward".

We had a discussion about what to do next, but I don't have any specific
advice for you, just some ideas you may possibly consider:
Perhaps it would be a useful exercise to approach the problem from a
fresh perspective. Try to explore new possibilities. For example: don't
put prefix-pool in relay-repl at all and do everything with requestor
messages. Cleaner and simpler, but would have the problem of
reconfiguring data on the relay and would lack faith sharing. What if
your relay could accept reconfigure? Perhaps new message types for
prefix-pool exchange would be the right way to go?

That's just a loose collection of ideas that doesn't form any coherent
solution. I'm not saying that any of these is a good idea, just that it
may be helpful to look at the alternatives. I'm not saying that these
may be better solutions that the one from prefix-pool-opt. Try to spin
up an honest, open minded discussion on the mailing list and see what
people think the solution should look like. It is possible that people
will realize when discussing alternatives that the they are worse and
your original solution was the best one.

Another issue raised was that prefix-pool is just one of many other
parameters needed. This does not solve relay configuration, but just a
small part of it. On the other hand, you probably don't want this to
evolve into another router configuration protocol. Perhaps this aspect
was what people didn't like?

Some of us afraid that there is not enough bandwidth in the work group
to go through such a let's-start-from-scratch exercise and they may be
right. I don't know. Perhaps an honest talk with people who did some
work in the PD area before, but did not support prefix-pool-opt will
shed some light here. Were they too busy? Is the issue at hand
irrelevant in their opinion? Perhaps the have better solution in mind?

Tomek

---

From: "Leaf Yeh" <[email-masked]>
Date: Fri, 26 Apr 2013 13:36:33 +0800

Tomek - Authors are advised to address them and continue work on this draft.

FYI, I've updated the draft (OPTION_PREFIX_POOL) to be ver.-03
(http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-prefix-pool-opt-03
). 
Hope it could have solved all the technical comments in the last WGLC.
Definitely we need more discussion on it, especially for the topic below:

Tomek - It seems reasonable to focus on a better explanation of why this is
a real problem and why the use case is practical rather than theoretical
one.

Best Regards,
Leaf