Subject: [karp] Framework document

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 01 Apr 2011 03:42:59 -0400

During the WG session, Sam and Gregory in the jabber room suggested 
moving the document to parked state.  Later on, we can revisit and see 
if there is value in RFC publication.

This seems a good idea.
Does anyone object?

Thank you,
Joel

---

From: Gregory Lebovitz <[email-masked]>
Date: Fri, 1 Apr 2011 01:18:48 -0700

No objection. That works for me.

In conjunction, could we please document here, on list, why it is that the
AD's and WG Chairs have decided to park the framework at present?

As I was reviewing Design-guide and -mrkmp I found it problematic more than
just a few times that we didn't have a framework overview that we've agreed
upon from which to reflect comments.

I know we wanted to actually try some different things out, like mrkmp for
example, to see if indeed we could actually separate the KMP from the
routing protocols before we hard-coded such a thing into the framework. But
I think we still need an active doc that captures "last thinking of record"
and where we can update from lessons learned in our trials and errors. For
this reason I think it should be active.

Can others please explain why it shouldn't be? Then can we come to WG
consensus on it?

Specifically, our charter currently calls for a Framework document. The
decision to not do one == decision to change our charter. This is fine, as
long as we have WG consensus on it after a healthy discussion. No?

Gregory

On Fri, Apr 1, 2011 at 12:42 AM, Joel M. Halpern <[email-masked]>wrote:

> During the WG session, Sam and Gregory in the jabber room suggested moving
> the document to parked state.  Later on, we can revisit and see if there is
> value in RFC publication.
>
> This seems a good idea.
> Does anyone object?
>
> Thank you,
> Joel
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>

-- 
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks