Subject: [anonsec] WG adoption of draft-komu-btns-api-01

From: julien.IETF at laposte.net (Julien Laganier)
Date: Fri, 1 Jun 2007 16:35:38 +0200

[re-issuing question w/ different subject line since it 
seems the previous one got us caught in a spam filter 
rule]

Folks,

Miika has worked on C-bindings for the abstract API 
(draft-komu-btns-api-01). Hereby I'd like to call for 
WG adoption of this document. If you agree, or 
disagree with adoption, please send an email saying so 
to the mailing list without changing the subject line 
before 2007-06-15. (OTOH please do change the subject 
line if you want to discuss contents of the documents 
themselves.)

(If you have no time to read the documents, you might 
take a look at their respective presentations given 
during last meeting.)

-- julien / BTNS co-chair

---

From: julien.IETF at laposte.net (Julien Laganier)
Date: Fri, 1 Jun 2007 16:35:40 +0200

Folks,

Michael has worked on a revised abstract API, available 
at:

<http://www.sandelman.ca/SSW/ietf/ipsec/btns/richardson-btns-abstract-api-00.txt>

Hereby I'd like to call for WG adoption of this 
document. If you agree, or disagree with adoption, 
please send an email saying so to the mailing list 
without changing the subject line before 2007-06-15. 
(OTOH please do change the subject line if you want to 
discuss contents of the documents themselves.)

---

From: julien.IETF at laposte.net (Julien Laganier)
Date: Fri, 1 Jun 2007 17:12:34 +0200

Folks, 

since we had issues with the first question issued that 
were caught into a spam filter, as well as answer to 
them, I'd like to ask those of you who replied to the 
question already to double check if their answer made 
it to the list. 

In case it didn't, please reply again, but to the 
second questions (with no "call" in subject line)

Sorry for the annoyance.

---

From: miika at iki.fi (Miika Komu)
Date: Fri, 1 Jun 2007 22:33:35 +0300 (EEST)

On Thu, 31 May 2007, Simon Josefsson wrote:

Hi,

no worries, I got already feedback that the OpenSSL part should be removed 
or abstracted. It was there mostly to clarify things to myself.

Thanks for the notice on the copyright.

> I object to standardize any API that uses data types from a particular
> external implementation (in this case OpenSSL).
>
> The approach used in this document appear to require that every
> implementation of the document needs to #include OpenSSL headers, and
> possibly call OpenSSL functions (the implementation of the
> ipsec_openssl_to_channel_info is unclear to me).  I believe that is
> clearly unacceptable for any Standards Track document.
>
> If this problem can be solved, by having a generic interface to input
> the necessary information needed from the TLS library, the document
> seems like a useful contribution to me.
>
> A suggestion for an improvement to the document would be to add a
> copyright license to the example code to make it possible to use the
> example in implementations.  This often helps spread usage and leads to
> faster adoption of the API.  See section 3 of
> draft-josefsson-free-standards-howto-00.txt.
>
> /Simon
>
> Julien Laganier <julien.IETF at laposte.net> writes:
>
>> Folks,
>>
>> before 2007-06-14. (OTOH please do change the subject
>> _______________________________________________
> _______________________________________________
>

-- 
Miika Komu                                       http://www.iki.fi/miika/

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 1 Jun 2007 11:14:19 -0500

> external implementation (in this case OpenSSL).

I agree that we must not have APIs that rely on non-standard APIs.
I.e., a C bindings of Michael's API that relies on BSDish sockets (or
Unix-like integer file descriptors for "sockets") is OK, but a C
bindings of Michael's API that relies on OpenSSL is not.

> seems like a useful contribution to me.

I'm sure that this problem can be solved.  In fact, I can't understand
why any dependence on any SSL/TLS library would be needed here.  Miika's
API should use octet strings to deal with certificates (DER or PEM) and
raw public keys.

> draft-josefsson-free-standards-howto-00.txt.

I should read that I-D.  Yes, it's important in an API document to make
sure that implementors have the right to: a) derive work from the API in
the document and distribute the result freely, b) derive documentation
from the RFC and distribute that freely.

---

From: julien.IETF at laposte.net (Julien Laganier)
Date: Wed, 13 Jun 2007 12:24:15 +0200

Folks,

We have a consensus to adopt draft-komu-btns-api-00 as 
WG item. 

Miika, could you please submit it as a WG draft: 
draft-ietf-btns-c-api-00.

Best,

-- julien, BTNS co-chair

On Friday 01 June 2007 16:35, Julien Laganier wrote:
> [re-issuing question w/ different subject line since
> it seems the previous one got us caught in a spam
> filter rule]
>
> Folks,
>
> (draft-komu-btns-api-01). Hereby I'd like to call
> for WG adoption of this document. If you agree, or
> disagree with adoption, please send an email saying
> so to the mailing list without changing the subject
> line before 2007-06-15. (OTOH please do change the
> subject line if you want to discuss contents of the
> documents themselves.)
>
> (If you have no time to read the documents, you
> might take a look at their respective presentations
> given during last meeting.)
>

---

From: julien.IETF at laposte.net (Julien Laganier)
Date: Wed, 13 Jun 2007 12:24:11 +0200

Folks,

We have a consensus to adopt 
draft-richardson-btns-abstract-api-00 as WG item. 

Michael, could you please submit it as a WG draft: 
draft-ietf-btns-abstract-api-00.

Best,

-- julien, BTNS co-chair

On Friday 01 June 2007 16:35, Julien Laganier wrote:
> Michael has worked on a revised abstract API,
> available at:
>
> (OTOH please do change the subject line if you want
> to discuss contents of the documents themselves.)
>