On Tue, Nov 6, 2012 at 8:18 AM, Ted Lemon <ted.le...@nominum.com> wrote:
> On Nov 5, 2012, at 5:36 PM, Lorenzo Colitti <lore...@google.com> wrote:
> > Since their document doesn't say why they want it, we can't know if the
> reason they want it is a reason that we would consider an acceptable reason
> to standardize it.
>
> Roberta Maglione was present at the meeting I spoke of, and has been
> present in each working group meeting since then where this has been
> discussed, and has explicitly stated what the BBF's needs are and why.
> There's probably even a liason statement lying around somewhere.
>
> If you genuinely feel that this has not been sufficiently documented, I
> guess we can track it down, but this is the first time I've heard you
> dispute the point that the BBF has a need for this functionality.
> Previously when we've talked about it you've said that it doesn't matter
> that they have this need, not that they don't in fact have this need.
>
Can we stop talking about me and take it back to the use case and the issue
specified in the tracker? I think it's fair to say that the use case:
1. Is poorly documented ("in order to avoid routing on the CPE, we're
specifying a protocol to configure routing on it" - seriously?)
2. Is poorly justified (why do we need a protocol to configure routing
beyond the one we already have? is this case common enough that a vendor
option is not enough? if the problem is provisioning the edge router, why
can't we solve that problem instead?)
3. Has an incorrect statement about the BBF (TR-124 does not call for
this draft or say why it's needed).
4. Violates the strong IAB recommendations made in RFC 3002 that the
IETF not design for walled gardens.
The "it doesn't matter that they have this need" is mostly captured in #4.
_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif
