Re: [CGA-EXT] proposed csi charter text

marcelo bagnulo braun <marcelo@it.uc3m.es> Fri, 28 December 2007 15:43 UTC

Return-path: <cga-ext-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8HNK-00065p-7b; Fri, 28 Dec 2007 10:43:54 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8HNI-00065W-8n for cga-ext@ietf.org; Fri, 28 Dec 2007 10:43:52 -0500
Received: from smtp03.uc3m.es ([163.117.176.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J8HNH-0002os-Da for cga-ext@ietf.org; Fri, 28 Dec 2007 10:43:51 -0500
Received: from [200.40.4.227] (unknown [200.40.4.227])(using TLSv1 with cipher AES128-SHA (128/128 bits))(No client certificate requested)by smtp03.uc3m.es (Postfix) with ESMTP id 28D3529A82C;Fri, 28 Dec 2007 16:43:39 +0100 (CET)
In-Reply-To: <729b68be0712280735r47c723d7xc13c2e5e45a9915e@mail.gmail.com>
References: <72D662E6-AF61-468C-82DD-65564307EF34@it.uc3m.es> <729b68be0712280735r47c723d7xc13c2e5e45a9915e@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="ISO-8859-1"; delsp="yes"; format="flowed"
Message-Id: <089887A5-450B-436A-9629-3E7CCBA40428@it.uc3m.es>
Content-Transfer-Encoding: quoted-printable
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
Subject: Re: [CGA-EXT] proposed csi charter text
Date: Fri, 28 Dec 2007 16:43:54 +0100
To: Jean-Michel Combes <jeanmichel.combes@gmail.com>
X-Mailer: Apple Mail (2.752.3)
X-imss-version: 2.049
X-imss-result: Passed
X-imss-scanInfo: M:B L:E SM:2
X-imss-tmaseResult: TT:1 TS:-17.9526 TC:1F TRN:45 TV:5.0.1023(15634.000)
X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0
X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000)
X-Spam-Score: 2.1 (++)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Cc: cga-ext@ietf.org
X-BeenThere: cga-ext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: CGA and SeND Extensions <cga-ext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/cga-ext>
List-Post: <mailto:cga-ext@ietf.org>
List-Help: <mailto:cga-ext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=subscribe>
Errors-To: cga-ext-bounces@ietf.org

Hi,

El 28/12/2007, a las 16:35, Jean-Michel Combes escribió:

> Hi,
>
> sorry for the delayed reply.
>
> 2007/12/18, marcelo bagnulo braun <marcelo@it.uc3m.es>:
>> Hi all,
>>
>> the bof in vancouver was very successful and we got very good
>> feedback from the AD and the IAB. so the next step is to agree on the
>> changes on the charter that were suggested on the BOF.
>>
>> After discussing with the Ad and the chairs, we propose to include in
>> the charter a new item on certificate management to provide cert
>> profile, cert validation and cert porisioning.
>>
>> We think that the anycast case that was suggested is not strictly
>> clear that is within the scope of our work, so we prefer not to
>> mention it explicitly in the charter, while it is possible to
>> evaluate if the proposed solutions do work with anycast and
>> eventually recharter later to include this work.
>>
>
> If we don't mention this case in the charter, there will be nothing
> about it in the PS document and this one will have to be updated later
> to integrate this case. As the problem with anycast addresses is, more
> or less, the same with ProxyND, IHMO, it would be preferable to have
> this case in the PS to avoid an update of it in the future.
>

but it is far from clear to me that the anycast case is similar to  
the one of proxynd and imho more analysis is needed
so i would really prefer to charter this work as it is curently  
defined and if people are interested on the anycast case and we do  
the anlysis and it seems that it is a possible to deal with the  
anycast case with the sam tools, we can easily recharter to cover  
this case

Moreover, there is a clear stage to do this, since we need to produce  
a problem statement for proxy send, so this would be a great moment  
to bring and discuss this issue and if during the proxy send pb  
statement disucssion we conclude that it would be ok to work on this  
we can try to recharter before starting the work on the acutal proxy  
send solution work

would that be ok?

Regards, marcelo


> [snip]
>
>>
>> - Produce a problem statement document for Neighbor Discovery Proxies
>>    and then specify standards-track SEND Extensions to support  
>> Neighbor
>>    Discovery Proxies:  SEND protocol as currently defined in RFC 3971
>>    lacks of support for ND Proxies defined in RFC 3775 and RFC 4389.
>>    Extensions to the SEND protocol will be defined in order to  
>> provide
>>    equivalent SEND security capabilities to ND Proxies.
>
> [snip]
>
> Best regards and happy new year.
>
> JMC.


_______________________________________________
CGA-EXT mailing list
CGA-EXT@ietf.org
https://www1.ietf.org/mailman/listinfo/cga-ext