Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctp-auth-05.txt

From: [email-masked]
Date: Wed, 08 Nov 2006 15:50:01 -0500

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.

	Title		: Authenticated Chunks for Stream Control Transmission Protocol (SCTP)
	Author(s)	: M. Tuexen, et al.
	Filename	: draft-ietf-tsvwg-sctp-auth-05.txt
	Pages		: 18
	Date		: 2006-11-8
	
This document describes a new chunk type, several parameters and
   procedures for SCTP.  This new chunk type can be used to authenticate
   SCTP chunks by using shared keys between the sender and receiver.
   The new parameters are used to establish the shared keys.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-auth-05.txt

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-tsvwg-sctp-auth-05.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-tsvwg-sctp-auth-05.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.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 21 Nov 2006 17:25:19 +0100

Hi,

I have reviewed this latest update and it seems to resolve my issues 
with one exception. The IANA section for the new HMAC registry is 
underspecified. Please provide a policy with which IANA can grant or 
deny requests for registration. Please look at RFC 2434 on policies on 
what is needed to register a new algorithm. I think that at least 
Specification Required is suitable in this case.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 21 Nov 2006 18:06:35 +0100

Hi Magnus,

so replacing

<t>For registering at IANA a new HMAC Identifier in this table a request
has to be made to assign such a number. This number must be unique and
a message digest algorithm usable with the HMAC defined in
<xref target="RFC2104">RFC2104</xref> MUST be specified.</t>

by

<t>For registering at IANA a new HMAC Identifier in this table a request
has to be made to assign such a number. This number MUST be unique and
a message digest algorithm usable with the HMAC defined in
<xref target="RFC2104">RFC2104</xref> MUST be specified in a RFC or  
other
permanent and readily available reference, in sufficient detail so that
interoperability between independent implementations is possible.</t>

would address your issue?

Randy, Peter, Eric: Is this this acceptable for you?

Best regards
Michael

On Nov 21, 2006, at 5:25 PM, Magnus Westerlund wrote:

> Hi,
>
> I have reviewed this latest update and it seems to resolve my  
> issues with one exception. The IANA section for the new HMAC  
> registry is underspecified. Please provide a policy with which IANA  
> can grant or deny requests for registration. Please look at RFC  
> 2434 on policies on what is needed to register a new algorithm. I  
> think that at least Specification Required is suitable in this case.
>
> Cheers
>
> Magnus Westerlund
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 23 Nov 2006 11:27:28 +0100

> would address your issue?

Yes, but I would be more comfortable by actually referencing the policy 
and RFC 2434.

Cheers

Magnus Westerlund

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 23 Nov 2006 20:20:29 +0100

OK, what about:

<t>For registering at IANA a new HMAC Identifier in this table a request
has to be made to assign such a number. This number MUST be unique and
a message digest algorithm usable with the HMAC defined in
<xref target="RFC2104">RFC2104</xref> MUST be used. The
"Specification Required" policy of <xref target="RFC2434">RFC2434</xref>
MUST be applied.</t>

If you like this, should I resubmit the ID?

Best regards
Michael

On Nov 23, 2006, at 11:27 AM, Magnus Westerlund wrote:

>> <xref target="RFC2104">RFC2104</xref> MUST be specified in a RFC  
>> or  other
> Yes, but I would be more comfortable by actually referencing the  
> policy and RFC 2434.
>
> Cheers
>
> Magnus Westerlund
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 24 Nov 2006 09:41:47 +0100

Hi Michael,

That works fine for me. Please resubmit the ID.

/Magnus

-- 

Magnus Westerlund

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 24 Nov 2006 11:31:28 +0100

Hi Magnus,

resubmitted as -06 with your change.

Best regards
Michael

On Nov 24, 2006, at 9:41 AM, Magnus Westerlund wrote:

>>>> <xref target="RFC2104">RFC2104</xref> MUST be specified in a  
>>>> RFC  or  other