Re: [radext] *[AD] Re: AUTH48 [LB]: RFC 8044 <draft-ietf-radext-datatypes-08.txt> NOW AVAILABLE

"Moriarty, Kathleen" <> Fri, 20 January 2017 22:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36B0912952D; Fri, 20 Jan 2017 14:55:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.22
X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)"; dkim=pass (1024-bit key) header.b=iuxINhdB; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.b=i5NbCTeK
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BFfqBkSdpPYn; Fri, 20 Jan 2017 14:55:06 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C901512952F; Fri, 20 Jan 2017 14:55:06 -0800 (PST)
DomainKey-Signature: s=smtpout;; c=simple; q=dns; h=Received:From:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: MIME-Version:X-Sentrion-Hostname:X-RSA-Classifications; b=s+WgbGy3FclDWV9960HXzxncaROtN4qzviJMSGHttX4t+GVkU0UblOFq fnziKnlWt3pkKsTJj28OTMTs/ruSl9RGGTXWaFZ3LC62LktecDpL85oQ9 0ykAAr2XWY7DPJ738mHWEdqvmO3uMkA1UlHfhaUOj8Ds+ftZDoVhlqpeB I=;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=smtpout; t=1484952906; x=1516488906; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7Imd30UNF1eK358CxkT2dSYxbuJcjcEG0qBR9L7vYZk=; b=iuxINhdB8jS7AKjfIGpEiJFhnJfHKyX1dKbvEOpursDwhRSWAYKvKPN7 gVAQ1At989vbOAFD5NYGva3+U2xL++ZlqC1j4rF77NIxUEjTtPp/3ra2z Jrr0X8oQ3jSYId+jZwm465FoUn3Bv8HTmozDVTSH3ZZjgfjjaQcveMeEq 8=;
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jan 2017 16:55:06 -0600
From: "Moriarty, Kathleen" <>
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jan 2017 04:46:59 +0600
Received: from ( []) by (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v0KMt2AG018831 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 20 Jan 2017 17:55:03 -0500
X-DKIM: OpenDKIM Filter v2.4.3 v0KMt2AG018831
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; s=jan2013; t=1484952904; bh=j65Nq+diZ3PrMe6i3KmGGPdKnJo=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=i5NbCTeKWjpVzF6yf+qA27G2alZO+6NQJzG8mMsnBTfePow2RPnuLnkbEab7ssJL+ /I4QnEMkWhkR7EQFa88u97B/4WNVFH1QoPonxq3WQd6cMBfVvdyuYQ4FE1xAABrMe4 E39WYlX1l1veo1XHF2kPWvFgj4CeU4Wie9+M/km8=
X-DKIM: OpenDKIM Filter v2.4.3 v0KMt2AG018831
Received: from ( []) by (RSA Interceptor); Fri, 20 Jan 2017 17:53:46 -0500
Received: from ( []) by (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v0KMsjNr013433 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Fri, 20 Jan 2017 17:54:45 -0500
Received: from ([fe80::64dd:bdd6:70f5:692a]) by ([]) with mapi id 14.03.0266.001; Fri, 20 Jan 2017 17:54:44 -0500
To: Lynne Bartholomew <>
Thread-Topic: *[AD] Re: [radext] AUTH48 [LB]: RFC 8044 <draft-ietf-radext-datatypes-08.txt> NOW AVAILABLE
Thread-Index: AQHSc28ztyCF+GkL0E2O9pYbN8xvgKFB+YP+
Date: Fri, 20 Jan 2017 22:54:44 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_8DD90954736641D9A2F072BF5901B453emccom_"
MIME-Version: 1.0
X-RSA-Classifications: public
Archived-At: <>
X-Mailman-Approved-At: Tue, 24 Jan 2017 01:27:48 -0800
Cc: "" <>, "" <>, Winter Stefan <>, Kathleen Moriarty <>, "" <>, Alan DeKok <>, RFC Editor <>, "" <>, Bernard Aboba <>
Subject: Re: [radext] *[AD] Re: AUTH48 [LB]: RFC 8044 <draft-ietf-radext-datatypes-08.txt> NOW AVAILABLE
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Jan 2017 22:55:09 -0000

Hi Lynne,

Thank you, I'll look at this tonight.  The gmail address is correct, but these messages are consistently getting lost or filed wrong, so I need to figure that out.


Please excuse typos, sent from handheld device

On Jan 20, 2017, at 5:47 PM, Lynne Bartholomew <<>> wrote:

Dear Kathleen,

Sending this email to your Dell address, in case the Gmail address is no longer correct.

RFC Editor/lb

On Jan 20, 2017, at 12:46 PM, Lynne Bartholomew <<>> wrote:

Dear *Kathleen,

We do not believe that we have heard from you regarding our question below.  Please review, and let us know how this document should be updated.

Thank you.

RFC Editor/lb

On Jan 13, 2017, at 10:11 AM, Lynne Bartholomew <<>> wrote:

Dear Kathleen,

Thank you for the email.

It is not clear to us how best to update this document.  Would the following be correct?

Updates: 2865, 3162, 6158, 6572

Updates: 2865, 3162, 4072, 6158, 6572, 7268

This document updates RFCs 2865, 3162, 6158, and 6572.

This document updates RFCs 2865, 3162, 4072, 6158, 6572, and 7268.

Thank you.

RFC Editor/lb

On Jan 13, 2017, at 7:36 AM, Kathleen Moriarty <<>> wrote:


I think we have agreement to continue moving forward, just noting the 'updates' since it is not a significant update.

Thank you,

On Wed, Jan 11, 2017 at 3:28 PM, Bernard Aboba <<>> wrote:
Data types do not affect what is actually sent on the wire, they just make it easier for a RADIUS server to add support for an attribute without custom code. So the datatypes draft does not create a deployment blocker or backward compatibility issue, it actually may make implementation easier.

On Jan 11, 2017, at 8:43 AM, Kathleen Moriarty <<>> wrote:

Adding the IESG and the working group to see if there are any concerns with the following approach... inline

On Wed, Jan 11, 2017 at 10:40 AM, Alan DeKok <<>> wrote:

> > > a) RFCs 4072 and 7268 are not cited anywhere in this document.
> > > Please let us know where they should be cited; otherwise, the
> > > listings will be removed.
> >
> > The RFCs are referenced simply because this document is updating
> > attributes that they define.
> Can you please list the specific updates from the 2 mentioned RFCs here and then I'll figure out if this needs to go back through the WG and last calls or not.

  RFC 4072 defines EAP-Key-Name.  It's in the RADIUS space, but t's defined to have a Diameter data type "OctetString".   We can't use "OctetString" for a RADIUS data types, so the "data types" document defines it as the RADIUS data type "string". Which ends up being the same for all intents and purposes.

  RFC 7268 defines a bunch of attributes.  Most are of 32-bit integers, which maps well to the data types doc.  The only real "new" thing is EAPoL-Announcement.  It's defined manually in RFC 7268 as "concatenate the fragments together before looking at it".  The data types doc calls this out as a special data type "concat", along with EAP-Message, and a few others.

  I think everyone is in agreement as to what the data types should be.  The "updates RFC 4072 / 7268" note is really saying "RFC 4072 / 7268 talks about this attribute, but doesn't really give an adequate definition for it.  So the data types document picks something, which is compatible with the original definition, but uses a now-standard data type"

  i.e. the original spec isn't so much wrong, as unclear and incomplete.

This seems like a small enough 'updates' that I think it should be fine to progress just adding the note that RFC4072 and RFC7268 are updated.

Any objections?  The alternative would be to put this back through the last call process, but I think this looks small enough to avoid that.  It would really just be for process sake IMO.

  Alan DeKok.


Best regards,
radext mailing list<>


Best regards,