Re: [Ianaplan] Question from the ICG

JFC Morfin <jefsey@jefsey.com> Fri, 25 September 2015 14:54 UTC

Return-Path: <jefsey@jefsey.com>
X-Original-To: ianaplan@ietfa.amsl.com
Delivered-To: ianaplan@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC871A1BAF for <ianaplan@ietfa.amsl.com>; Fri, 25 Sep 2015 07:54:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.225
X-Spam-Level: *
X-Spam-Status: No, score=1.225 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DATE_IN_PAST_03_06=1.592, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHrCDWq_wLck for <ianaplan@ietfa.amsl.com>; Fri, 25 Sep 2015 07:54:12 -0700 (PDT)
Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39AB21A1BC2 for <ianaplan@ietf.org>; Fri, 25 Sep 2015 07:54:12 -0700 (PDT)
Received: from 251.47.14.81.rev.sfr.net ([81.14.47.251]:56666 helo=GHM-SAM.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.85) (envelope-from <jefsey@jefsey.com>) id 1ZfUO2-00013u-LM; Fri, 25 Sep 2015 07:54:11 -0700
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 25 Sep 2015 13:11:04 +0200
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Russ Housley <housley@vigilsec.com>, ianaplan@ietf.org
From: JFC Morfin <jefsey@jefsey.com>
In-Reply-To: <56048C23.5040802@gmail.com>
References: <56A1B728-98DF-409A-B2B6-2624F53FE175@cooperw.in> <3A58359B-420B-4FEC-B812-4659D980C5D3@vigilsec.com> <56048C23.5040802@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host.presenceweb.org
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: intl+dot.dj/only user confirmed/virtual account not confirmed
X-Source:
X-Source-Args:
X-Source-Dir:
Message-Id: <20150925145412.39AB21A1BC2@ietfa.amsl.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/pa00cND6UFsJiQ_cqo2T8XND_JQ>
Subject: Re: [Ianaplan] Question from the ICG
X-BeenThere: ianaplan@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IANA Plan <ianaplan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ianaplan/>
List-Post: <mailto:ianaplan@ietf.org>
List-Help: <mailto:ianaplan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Sep 2015 14:54:14 -0000

Fwiw:

We are entangled in France with the begining of a 
national debate initiated by the Government over 
a law proposition for a "numeric Republic". Due 
to the NTIA transition delay, I have proposed the 
XLIBRE bootstrap to focus on this 
regalan/private/civil issue and to exempllify it 
with an XMP2P/IP oriented architecture and r&d 
(the interest is not that much the result, but 
the cooperative proprietary/Libre research, 
development and experimentation experience we can use in this debate).

1. this means that I suspect the XLIBRE VGNS 
(virtual glocal network set) will not interfere in IETF/ICANN VGNS areas.
2. the "FL" class experimentation has started 
through different test hypothesis, but is not our 
priority anymore since the main project may 
request somme additional DDDS services we want to consider first.

Therefore the aggregation of the IETF to the 
ICANN community is no more a problem for us, as 
long as IP is not modified and the test "FL" CLASS remains an options for all.

Best regards
jfc



At 01:49 25/09/2015, Brian E Carpenter wrote:

>On 25/09/2015 10:26, Russ Housley wrote:
> > I think that we should respond with a very 
> simple confirmation that we plan to continue to 
> coordinate with the other operational 
> communities, but that we do not think that 
> formal processes are necessary to do so.
>
>fwiw, I certainly agree with that.
>
>   Brian
>
> > This is consistent with the comments that 
> were sent by the IAB to the ICG.  See
>https://www.iab.org/documents/correspondence-reports-documents/2015-2/iab-comments-on-icg-proposal/.
> >
> > Russ
> >
> >
> > On Sep 24, 2015, at 6:02 PM, Alissa Cooper wrote:
> >
> >> Dear IANAPLAN WG,
> >>
> >> Based on comments received during the 
> ICG’s public comment period, the ICG has a 
> question for the protocol parameters community. 
> We are requesting a response to this question 
> ideally by 7 October at 23:59 UTC (prior to the 
> ICG’s final call before ICANN 54 on October 
> 8), or by 14 October at 23:59 UTC if the 
> protocol parameters community requires more 
> time. We realize this is an aggressive 
> timetable, so please keep us informed if you feel you need further time.
> >>
> >> The ICG would like to state explicitly that 
> we do not expect a further ICG public comment 
> period to be necessary on the combined proposal 
> in response to the answers that the protocol 
> parameters community may provide. While the ICG 
> reserves the right to seek further public 
> comment if we receive extensive amendments from 
> any of the operational communities, we do not expect to do so at this time.
> >>
> >> The three operational communities have a 
> long history of cooperation as needed to help 
> ensure the smooth functioning of the DNS and 
> the Internet. A number of comments were 
> concerned that the three IANA functions could 
> end up being carried out by different operators 
> and suggested that there was a need for some 
> information exchange and coordination between 
> the operational communities to ensure a proper 
> understanding of the impact a change might have 
> on the operation of the other functions 
> (perhaps because of interdependencies between 
> the functions or because of shared resources or 
> key staff). This information exchange might 
> also help in coordinating action in the case of 
> remedying operational difficulties. For this to 
> work, the three operational communities need to 
> commit to coordinating and cooperating as 
> necessary when changing operator, whether by 
> leveraging existing coordination mechanisms or 
> new ones. Can the protocol parameters 
> operational community provide such a commitment?
>  If so, the ICG intends to reflect that and the 
> commitments of the other communities in Part 0 of the transition proposal.
> >>
> >> Please let us know if the question requires clarification.
> >>
> >> Thanks,
> >>
> >> Alissa Cooper on behalf of the ICG
> >>
> >
> >
> >
> >
> > _______________________________________________
> > Ianaplan mailing list
> > Ianaplan@ietf.org
> > https://www.ietf.org/mailman/listinfo/ianaplan
> >
>
>_______________________________________________
>Ianaplan mailing list
>Ianaplan@ietf.org
>https://www.ietf.org/mailman/listinfo/ianaplan