Subject: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt

From: <[email-masked]>
Date: Wed, 8 Mar 2006 08:49:11 +0200

Hi all,

I'd like to start a WG last call on the Diameter API.  The API is in use
in the OpenDiameter project, 
and changes they have made for their implementation have been reflected
in the API.  

WGLC ends on Friday March 24th. 

Please review the document, send issues in the form of>

 Description of issue
 Submitter name: Your_Name_Here
 Submitter email address: Your_Email_Address_Here
 Date first submitted: Insert_Date_Here
 Reference: URL to e-mail describing problem, if available
 Document: Document Requiring change [Diameter API]
 Comment type: ['T'echnical | 'E'ditorial]
 Priority: ['S' Must fix | '1' Should fix | '2' May fix ]
 Section: Insert_Section_Number_Here
 Rationale/Explanation of issue:
 Length description of problem

 Requested change:
 Proposed changes to the document. Please be specific about what text
you want 
 to change, add or delete. Issues cannot be considered until specific
text is provided.

If you have read the document & think it is good to go, please send a
mail to that
respect.

thanks,
John

>>From: ext [email-masked] [mailto:[email-masked]]
>>Sent: 07 March, 2006 09:50
>>To: [email-masked]
>>Cc: [email-masked]
>>Subject: [Dime] I-D ACTION:draft-ietf-dime-diameter-api-00.txt
>>
>>A New Internet-Draft is available from the on-line Internet-Drafts 
>>directories.
>>This draft is a work item of the Diameter Maintanence and Extensions 
>>Working Group of the IETF.
>>
>>	Title		: The Diameter API
>>	Author(s)	: P. Calhoun, et al.
>>	Filename	: draft-ietf-dime-diameter-api-00.txt
>>	Pages		: 45
>>	Date		: 2006-3-6
>>	
>>  The Diameter authentication, authorization, and accounting (AAA)  
>> protocol provides support for peering AAA transactions across the  
>> Internet.  This document describes a standardized API for the  
>> Diameter protocol.  The API is defined for the C language.  The  
>> intent of the API is to foster source code portability across  
>> multiple programming platforms.
>>
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-api-00.tx
>>t
>>
>>To remove yourself from the I-D Announcement list, send a message to 
>>[email-masked] with the word unsubscribe in the body of

>>the message.
>>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>>to change your subscription settings.
>>
>>
>>Internet-Drafts are also available by anonymous FTP. Login with the 
>>username "anonymous" and a password of your e-mail address. After 
>>logging in, type "cd internet-drafts" and then
>>	"get draft-ietf-dime-diameter-api-00.txt".
>>
>>A list of Internet-Drafts directories can be found in 
>>http://www.ietf.org/shadow.html or 
>>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>>Internet-Drafts can also be obtained by e-mail.
>>
>>Send a message to:
>>	[email-masked].
>>In the body type:
>>	"FILE /internet-drafts/draft-ietf-dime-diameter-api-00.txt".
>>	
>>NOTE:	The mail server at ietf.org can return the document in
>>	MIME-encoded form by using the "mpack" utility.  To use this
>>	feature, insert the command "ENCODING mime" before the "FILE"
>>	command.  To decode the response(s), you will need "munpack" or
>>	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
>>	exhibit different behavior, especially when dealing with
>>	"multipart" MIME messages (i.e. documents which have been split
>>	up into multiple messages), so check your local documentation on
>>	how to manipulate these messages.
>>		
>>		
>>Below is the data which will enable a MIME compliant mail reader 
>>implementation to automatically retrieve the ASCII version of the 
>>Internet-Draft.
>>

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 08 Mar 2006 08:25:52 -0500

Hi John,

>and changes they have made for their implementation have been reflected
We've significantly branched away from this API since our model evolved 
differently but I'll review the document
regards,
victor

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 08 Mar 2006 20:59:50 -0500

So we're standardizing an API that hasn't been implemented? That seems a 
bit dubious.

Anders

Victor Fajardo wrote:

>> in the OpenDiameter project, and changes they have made for their 
>> implementation have been reflected
>> in the API.   
>>
>> you want to change, add or delete. Issues cannot be considered until 
>> specific
>> text is provided.
>>

---

From: <[email-masked]>
Date: Thu, 9 Mar 2006 06:28:35 +0200

Well, review the document and let us know if the API defined is good
or bad, or any recommendations and we'll take it from there.

john 

>-----Original Message-----
>From: ext Anders Kristensen [mailto:[email-masked]] 
>Sent: 09 March, 2006 04:00
>To: Victor Fajardo
>Cc: Loughney John (Nokia-NRC/Helsinki); [email-masked]
>Subject: Re: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt
>
>So we're standardizing an API that hasn't been implemented? 
>That seems a bit dubious.
>
>Anders
>
>Victor Fajardo wrote:
>
>> Hi John,
>> 
>>> I'd like to start a WG last call on the Diameter API.  The 
>API is in 
>>> use in the OpenDiameter project, and changes they have made 
>for their 
>> We've significantly branched away from this API since our model 
>> evolved differently but I'll review the document regards, victor
>> 
>>> Submitter email address: Your_Email_Address_Here Date first 
>>> submitted: Insert_Date_Here
>>> Document: Document Requiring change [Diameter API] Comment type: 
>>> ['T'echnical | 'E'ditorial]
>>> specific text is provided.
>>>
>>> mail to that respect.
>>>>> This draft is a work item of the Diameter Maintanence and 
>>>>> Extensions Working Group of the IETF.
>>>>>
>>>>>     Title        : The Diameter API
>>>>> You can also visit 
>https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: David Frascone <[email-masked]>
Date: Thu, 09 Mar 2006 01:26:38 -0600

The API was used in sun's reference implementation.  Opendiameter moved 
away from it, since they're in c++.

I think there is one other implementation.  The author has promised to 
review and post ocmments to this list.

[email-masked] wrote:
>>>>Proposed changes to the document. Please be specific about 
>>
>>what text 
>>
>>>>you want to change, add or delete. Issues cannot be 
>>
>>considered until 
>>
>>>>If you have read the document & think it is good to go, 
>>
>>please send a 
>>
>>>>mail to that respect.
>>>>
>>>>thanks,
>>>>John
>>>>
>>>> 
>>>>
>>>>
>>>>>>A New Internet-Draft is available from the on-line 
>>
>>Internet-Drafts 
>>
>>>>>>directories.
>>>>>>To remove yourself from the I-D Announcement list, send a 
>>
>>message to 
>>
>>>>>>[email-masked] with the word unsubscribe 
>>
>>in the body of
>>
>>>>>>    
>>>>
>>>>
>>>> 
>>>>
>>>>
>>>>>>the message.
>>>>>>You can also visit 
>>
>>>>>>Internet-Drafts are also available by anonymous FTP. 
>>
>>Login with the 
>>
>>>>>>    command.  To decode the response(s), you will need 
>>
>>"munpack" or
>>
>>>>>>    "multipart" MIME messages (i.e. documents which have 
>>
>>been split
>>
>>>>>>    up into multiple messages), so check your local 
>>
>>documentation on
>>

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 9 Mar 2006 08:11:16 -0500

What makes it better/more usefull than the practically endless other API
possibilities so that IETF endorses it?

Actually why does IETF endorses an API at all?

   Thanks,
   Tolga

> From: David Frascone [mailto:[email-masked]]
> Sent: Thursday, March 09, 2006 2:27 AM
> To: [email-masked]

---

From: David Lehmann <[email-masked]>
Date: Thu, 09 Mar 2006 09:27:18 -0500

David Frascone wrote:
>
> The API was used in sun's reference implementation.  Opendiameter 
> moved away from it, since they're in c++.
I question whether this is Sun's API.  If someone from Sun can confirm 
or deny, please do.

> review and post ocmments to this list.
Please name it. 

As it stands right now, there is no known implementation which uses this 
API. 
As Anders stated, this is a bit dubious.

Back in October 2005, I tried to raise a discussion on the AAA group 
about the API, but
the authors were unresponsive.  That being the case, we could not follow 
it because of its
shortcomings and a general lack of maturity. In addition, there seemed  
to be no effort to
make it mature. So now, a new draft suddenly appears and we immediately 
go to last call?  
IMHO, there should be much more discussion and there should be a couple 
of independent
implementations.  Without real implementations, there will be no 
meaningful discussions
and the API will have serious shortcomings.  A simple review of the 
draft will not cut it.
IMHO, we are a least a year away from a last call.

-- 

David Lehmann
Ulticom, Inc.
http://www.ulticom.com

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 9 Mar 2006 16:44:03 +0100

Hi David,

> >review and post ocmments to this list.

 I guess that's me but I'm not the author of the implementatiion.
 I'm using a Diameter Base
 Protocol which is based on this API on top of which I implement an
 application. I already posted some comments on
 it (Diameter API) both on AAA and DIME ML. 
 I "promised" to compile all these comments.

> IMHO, we are a least a year away from a last call.

 I agree that maybe this WG LC is a little bit premature.

 Julien Bournelle

-- 
julien.bournelle at int-evry.fr

---

From: <[email-masked]>
Date: Thu, 9 Mar 2006 17:49:41 +0200

Just as a note - if the document isn't ready, then make comments,
the document will be revised and we can then see if the document
needs another WGLC, etc.

The focus should be getting the document finalized, if it takes more
than one round, or additional revisions, then that's fine.

John 

>From: ext Julien Bournelle [mailto:[email-masked]] 
>Sent: 09 March, 2006 17:44
>To: David Lehmann
>Cc: [email-masked]
>> >I think there is one other implementation.  The author has promised 
>> >to review and post ocmments to this list.
>> Please name it. 
>
> Protocol which is based on this API on top of which I 
>implement an  application. I already posted some comments on  
>> As it stands right now, there is no known implementation which uses 
>> this API.
>> about the API, but the authors were unresponsive.  That being the 
>> case, we could not follow it because of its shortcomings and 
>a general 
>> lack of maturity. In addition, there seemed to be no effort 
>to make it 
>> mature. So now, a new draft suddenly appears and we 
>immediately go to 
>> last call?
>> IMHO, there should be much more discussion and there should be a 
>> couple of independent implementations.  Without real 
>implementations, 
>> there will be no meaningful discussions and the API will 
>have serious 
>> shortcomings.  A simple review of the draft will not cut it.

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 9 Mar 2006 10:52:44 -0500

Hi John,

What is the goal of this document?

The draft says:
"The intent of the API is to foster source code portability across multiple
programming platforms."

Is this really something done often by IETF?

Protocols being procedures between two peers need to be standardized, but
APIs are a local contract between a protocol layer and an application of
that protocol. For that reason they won't cause interoperability problems
and people won't be forced to comply with them. Although initially this
seems like good news because there is no need to comply with them, this also
is the reason, why they are not very useful -there are of course exceptions
like the socket API-. BTW, any API also implies certain implementation
decisions, aren't we intervening too much to implementation dependent
details by defining an API as a WG-document?

I think, any API document for Diameter is better to be a non-WG document. In
this way, people which are interested can submit the "best" API according to
them and we won't have one "officially endorsed by IETF" version of API.

   Thnaks,
   Tolga

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, March 09, 2006 10:50 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Dime] WGLC on ACTION:draft-ietf-dime-diameter-api-00.txt
>
>

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 9 Mar 2006 17:15:17 +0100

Hi Tolga,

 I don't know if it is something that should be done by IETF.
 
 What I know is that if I developp a Diameter Application using this
 Diameter API, I can then used any Diameter Base Protocol implementation
 complying with it.

 My 2 cents,

 Julien Bournelle

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 9 Mar 2006 11:17:20 -0500

Hi Julien,

Yes of course, if the same API is used by two implementations, it is easy
two switch between them. My point is, why this should be an official
document of IETF?

Just as an example, the current API draft relies on callbacks. This
obviously is a design choice. I don't think it is a good idea to force
everybody to use the same design choices.

    Thanks,
    Tolga

> From: Julien Bournelle [mailto:[email-masked]]
> Sent: Thursday, March 09, 2006 11:15 AM
> To: Tolga Asveren
> Cc: [email-masked]
> > > >Subject: Re: [Dime] WGLC on
> ACTION:draft-ietf-dime-diameter-api-00.txt
> > > >
> > > >Hi David,
> > > >

---

From: <[email-masked]>
Date: Thu, 9 Mar 2006 19:19:50 +0200

API document is informational, only. Like all API documents in the
IETF. Noone is required to implement it.

John 

>From: ext Tolga Asveren [mailto:[email-masked]] 
>Sent: 09 March, 2006 18:17
>To: [email-masked]
>Yes of course, if the same API is used by two implementations, 
>it is easy two switch between them. My point is, why this 
>should be an official document of IETF?
>
>Just as an example, the current API draft relies on callbacks. 
>This obviously is a design choice. I don't think it is a good 
>idea to force everybody to use the same design choices.
>
>    Thanks,
>    Tolga
>
>> Diameter API, I can then used any Diameter Base Protocol 
>> implementation  complying with it.
>>
>>  My 2 cents,
>>
>>  Julien Bournelle
>>
>>
>> > APIs are a local contract between a protocol layer and an 
>> > application of that protocol. For that reason they won't cause
>> interoperability problems
>> > and people won't be forced to comply with them. Although initially 
>> > this seems like good news because there is no need to comply with
>> them, this also
>> > like the socket API-. BTW, any API also implies certain 
>> > implementation decisions, aren't we intervening too much to 
>> > implementation dependent details by defining an API as a 
>WG-document?
>> >
>> > > Subject: RE: [Dime] WGLC on 
>> > > The focus should be getting the document finalized, if it takes 
>> > > more than one round, or additional revisions, then that's fine.
>> > >
>> > > John
>> > >
>> > > >> >The API was used in sun's reference implementation.  
>> > > >> >Opendiameter moved away from it, since they're in c++.
>implement 
>> > > >an  application. I already posted some comments on it (Diameter 
>> > > >API) both on AAA and DIME ML.
>> > > >> As it stands right now, there is no known 
>implementation which 
>> > > >> uses this API.
>> > > >> about the API, but the authors were unresponsive.  That being 
>> > > >> the case, we could not follow it because of its shortcomings 
>> > > >> and
>> > > >a general
>> > > >> IMHO, there should be much more discussion and there 
>should be 
>> > > >> a couple of independent implementations.  Without real
>> > > >implementations,

---

From: <[email-masked]>
Date: Fri, 10 Mar 2006 09:42:46 +0200

I don't think that meta-discussions are useful.  Review the document,
raise conserns - if there are things that are in the document are
not good, then state that. If there isn't enough WG consensus to 
approve the document, then the document doesn't get approved.

The IETF has worked on APIs before, see:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-12.txt
IPv6 Advanced IPv6 API http://www.ietf.org/rfc/rfc3542.txt 

and a good search will find:
https://datatracker.ietf.org/public/idindex.cgi?command=do_search_id&fil
ename=api&id_tracker_state_id=-1&wg_id=0&other_group=&status_id=0&last_n
ame=&first_name=

John

>Sent: 09 March, 2006 17:53
>To: [email-masked]
>"The intent of the API is to foster source code portability 
>across multiple programming platforms."
>
>Protocols being procedures between two peers need to be 
>standardized, but APIs are a local contract between a protocol 
>layer and an application of that protocol. For that reason 
>they won't cause interoperability problems and people won't be 
>forced to comply with them. Although initially this seems like 
>good news because there is no need to comply with them, this 
>also is the reason, why they are not very useful -there are of 
>course exceptions like the socket API-. BTW, any API also 
>implies certain implementation decisions, aren't we 
>intervening too much to implementation dependent details by 
>defining an API as a WG-document?
>
>I think, any API document for Diameter is better to be a 
>non-WG document. In this way, people which are interested can 
>submit the "best" API according to them and we won't have one 
>"officially endorsed by IETF" version of API.
>
>   Thnaks,
>   Tolga
>
>
>
>> Just as a note - if the document isn't ready, then make 
>comments, the 
>> document will be revised and we can then see if the document needs 
>> another WGLC, etc.
>>
>Opendiameter 
>> >> >I think there is one other implementation.  The author has 
>> >> >promised to review and post ocmments to this list.
>> >> Please name it.
>> >
>implement an  
>> >application. I already posted some comments on it (Diameter 
>API) both 
>> >on AAA and DIME ML.
>> >> Back in October 2005, I tried to raise a discussion on the AAA 
>> >> group about the API, but the authors were unresponsive.  
>That being 
>> >> the case, we could not follow it because of its shortcomings and
>> >a general

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 10 Mar 2006 11:18:13 -0500

> Sent: Friday, March 10, 2006 2:43 AM
> To: [email-masked]; [email-masked]
[TOLGA]I just tried to present my personal opinion, but in any case it is a
good idea to get things done with some result -where result could be a RFC
or no document or etc...-
> ename=api&id_tracker_state_id=-1&wg_id=0&other_group=&status_id=0&last_n
[TOLGA]The biggest reasons for the above APIs is that their predecessors
were existing and well-accepted by the industry -SCTP socket API tries to
mimic TCP socket API and similarly IPv6 API tries to mimic IPv4 API-. As
counter example, there are many IETF defined protocols with no IETF defined
APIs.

---

From: David Lehmann <[email-masked]>
Date: Fri, 10 Mar 2006 12:47:36 -0500

> approve the document, then the document doesn't get approved.
I have concerns about putting this very immature I-D in last call as if 
it went through extensive review/discussion and has real life, working 
implementations to back up its usefulness.
> IPv6 Advanced IPv6 API http://www.ietf.org/rfc/rfc3542.txt 
Notice that the SCTP socket API I-D still has not been made an RFC even 
though this I-D has been discussed for years and has real life working 
implementations.  Both Solaris and Linux follow the SCTP API I-D and 
real applications are being developed on these platforms using this 
API.  The API is getting extensive exercise to draw out its weaknesses.  
So by the time the I-D goes to RFC, it will be solid a API, cumulating 
years of discussion and real world experience.

I believe the same can be said for the IPv6 API RFC.

IMHO, the Diameter API I-D is nowhere near the maturity of SCTP's API 
and the Diameter API has virtually no following. So why is the Diameter 
API I-D being held to such low standards?

The I-D is at least a year (realistically 2-3 years) away from 
qualifying for WGLC.
IMHO, of course.

-- 

David Lehmann
Ulticom, Inc.
http://www.ulticom.com

---

From: <[email-masked]>
Date: Sat, 11 Mar 2006 08:19:46 +0200

The fact is, it is a charter item, and we should look at completing our
charter.  I'm really happy if people send technical comments of the
draft, so we can judge if there needs to be changes, a rethink or
if it is OK.  

thanks,
John 

>Sent: 10 March, 2006 18:18
>To: [email-masked]
>> raise conserns - if there are things that are in the 
>document are not 
>> good, then state that. If there isn't enough WG consensus to approve 
>> the document, then the document doesn't get approved.
>[TOLGA]I just tried to present my personal opinion, but in any 
>case it is a good idea to get things done with some result 
>-where result could be a RFC or no document or etc...-
>>
>[TOLGA]The biggest reasons for the above APIs is that their 
>predecessors were existing and well-accepted by the industry 
>-SCTP socket API tries to mimic TCP socket API and similarly 
>IPv6 API tries to mimic IPv4 API-. As counter example, there 
>are many IETF defined protocols with no IETF defined APIs.
>>
>> John
>>
>> >"The intent of the API is to foster source code portability across 
>> >multiple programming platforms."
>> >
>standardized, 
>> >but APIs are a local contract between a protocol layer and an 
>> >interoperability problems and people won't be forced to comply with 
>> >them. Although initially this seems like good news because there is 
>> >no need to comply with them, this also is the reason, why they are 
>> >not very useful -there are of course exceptions like the 
>socket API-. 
>> >BTW, any API also implies certain implementation decisions, 
>aren't we 
>> >I think, any API document for Diameter is better to be a non-WG 
>> >document. In this way, people which are interested can submit the 
>> >"best" API according to them and we won't have one "officially 
>> >endorsed by IETF" version of API.
>> >
>> >   Thnaks,
>> >   Tolga
>> >
>> >
>> >
>should be a

---

From: <[email-masked]>
Date: Mon, 13 Mar 2006 08:49:03 +0200

David,

>IMHO, the Diameter API I-D is nowhere near the maturity of 
>SCTP's API and the Diameter API has virtually no following. So 
>why is the Diameter API I-D being held to such low standards?
>

WGLC implies nothing. It seems that in many working groups, noone
reviews documents until WGLC.  So, people need to review the
current draft and raise issues.  That's where we are at right now.

If we need more working group last calls in order to complete the
draft, then we will have them. 

John