Re: [RADIR] finishing the problem statement

Jason Schiller <schiller@uu.net> Mon, 09 March 2009 21:06 UTC

Return-Path: <schiller@uu.net>
X-Original-To: radir@core3.amsl.com
Delivered-To: radir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F03953A6C86 for <radir@core3.amsl.com>; Mon, 9 Mar 2009 14:06:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZDW3SU+6OlT for <radir@core3.amsl.com>; Mon, 9 Mar 2009 14:06:36 -0700 (PDT)
Received: from ashesmtp01.verizonbusiness.com (ashesmtp01.verizonbusiness.com [198.4.8.163]) by core3.amsl.com (Postfix) with ESMTP id 73DC13A68A9 for <radir@ietf.org>; Mon, 9 Mar 2009 14:06:31 -0700 (PDT)
Received: from omzismtp01.vzbi.com ([165.122.46.164]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KG9001BMBS20W00@firewall.verizonbusiness.com> for radir@ietf.org; Mon, 09 Mar 2009 21:02:27 +0000 (GMT)
Received: from omzismtp01.vzbi.com ([127.0.0.1]) by omzismtp01.vzbi.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KG900FGHBS26D00@omzismtp01.vzbi.com> for radir@ietf.org; Mon, 09 Mar 2009 21:02:26 +0000 (GMT)
Received: from meno.corp.us.uu.net ([153.39.146.71]) by omzismtp01.vzbi.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KG900F8MBS29D00@omzismtp01.vzbi.com> for radir@ietf.org; Mon, 09 Mar 2009 21:02:26 +0000 (GMT)
Date: Mon, 09 Mar 2009 16:02:25 -0500 (EST)
From: Jason Schiller <schiller@uu.net>
X-Sender: schiller@meno.corp.us.uu.net
To: Thomas Narten <narten@us.ibm.com>
In-reply-to: <200903091507.n29F7Ipg014272@cichlid.raleigh.ibm.com>
Message-id: <Pine.GSO.4.20.0903091601340.3818-100000@meno.corp.us.uu.net>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Cc: radir@ietf.org
Subject: Re: [RADIR] finishing the problem statement
X-BeenThere: radir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing and Addressing Directorate <radir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/radir>, <mailto:radir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radir>
List-Post: <mailto:radir@ietf.org>
List-Help: <mailto:radir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radir>, <mailto:radir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Mar 2009 21:06:37 -0000

I'm ok with the new boiler plate...  looking over the new text now.

__Jason


==========================================================================
Jason Schiller                                               (703)886.6648
Senior Internet Network Engineer                         fax:(703)886.0512
Public IP Global Network Engineering                       schiller@uu.net
UUNET / Verizon                         jason.schiller@verizonbusiness.com

The good news about having an email address that is twice as long is that
it increases traffic on the Internet.

On Mon, 9 Mar 2009, Thomas Narten wrote:

> Date: Mon, 09 Mar 2009 11:07:18 -0400
> From: Thomas Narten <narten@us.ibm.com>
> To: radir@ietf.org
> Subject: [RADIR] finishing the problem statement
> 
> We are a bit overdue on revising the problem statement and getting it
> out...
> 
> I spoke with Olaf a while back and he seemed to think that much of the
> initial excitement about the topic had died down again, and anyway RRG
> is where the work is actually happening. So he is inclined to see the
> document shipped and close the directorate. However, the current
> problem statement (as we have discussed amongst  ourselves) does not
> have any sort of broad concensus, so it couldn't get any sort of
> official blessing. If we were to ask for publication now, we'd
> likely be told to publish it as individual submission.
> 
> As we've discussed before, Olaf has said the pressures on routing
> section had good stuff, but that the business section in particular
> was problematic. We've had past discussions about that together with
> some suggestions for improvements.
> 
> I would like to get this document published as an informational RFC,
> but one with IETF blessing/support. That means we have to get folk
> familiar with this space to support publication of our document.
> 
> I spent some time going over the document in January, reviewed our
> previous discussions and made a number of changes. I then didn't
> followup and close the loop and get back to this list.
> 
> One thing that of course happens when one re-reads a document after 6
> months is that one sees all sorts of things that should be tweaked.
> 
> Rather than try to do an issue by issue review, I've just gone ahead
> and revised the document; I'll send it (and diffs) in separate messages.
> 
> The ID cutoff is today (7PM West Coast Time). I'd like to go ahead and
> post the revised document, but if anyone thinks I should not (whether
> on principle -- because you want to review more carefully first, or
> because you have specific issues with the revision), please speak
> up. I plan to post unless I get a "no". (I don't have plans to have
> the document discussed in SF, so it is not critical that it get posted
> today).
> 
> Finally, I've used the following boilerplate:
> 
>    This Internet-Draft is submitted to IETF in full conformance with the
>    provisions of BCP 78 and BCP 79.  This document may contain material
>    from IETF Documents or IETF Contributions published or made publicly
>    available before November 10, 2008.  The person(s) controlling the
>    copyright in some of this material may not have granted the IETF
>    Trust the right to allow modifications of such material outside the
>    IETF Standards Process.  Without obtaining an adequate license from
>    the person(s) controlling the copyright in such materials, this
>    document may not be modified outside the IETF Standards Process, and
>    derivative works of it may not be created outside the IETF Standards
>    Process, except to format it for publication as an RFC or to
>    translate it into languages other than English.
> 
> I assume that we are all OK with submitting under the updated
> boilerplate that grants full rights to the IETF trust, but the
> document can't say that until I get explicite confirmation from each
> of us on that point.
> 
> Thomas
> _______________________________________________
> RADIR mailing list
> RADIR@ietf.org
> https://www.ietf.org/mailman/listinfo/radir
>