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

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 11 Jan 2017 11:43:07 -0500

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 <[email-masked]> 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.
>
> http://www.iana.org/assignments/radius-types/radius-types.xhtml#radius-
> types-2
>
>   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,
Kathleen

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 11 Jan 2017 12:28:26 -0800

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 <[email-masked]> wrote:
> 
> Adding the IESG and the working group to see if there are any concerns with the following approach... inline
> 
>> > 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.
>> 
>> http://www.iana.org/assignments/radius-types/radius-types.xhtml#radius-types-2
>> 
>>   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"
>> 
> 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,
> Kathleen
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 13 Jan 2017 10:36:01 -0500

Hello,

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

Thank you,
Kathleen

On Wed, Jan 11, 2017 at 3:28 PM, Bernard Aboba <[email-masked]>
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.
>
> 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,
> Kathleen
>

-- 

Best regards,
Kathleen

---

From: Lynne Bartholomew <[email-masked]>
Date: Fri, 13 Jan 2017 10:11:38 -0800

Dear Kathleen,

Thank you for the email.

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

OLD:
Updates: 2865, 3162, 6158, 6572

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

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

NEW:
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 <[email-masked]> wrote:

> Hello,
> 
> I think we have agreement to continue moving forward, just noting the 'updates' since it is not a significant update.
> 
> Thank you,
> Kathleen
> 
> On Wed, Jan 11, 2017 at 3:28 PM, Bernard Aboba <[email-masked]> wrote:

---

From: Lynne Bartholomew <[email-masked]>
Date: Fri, 20 Jan 2017 12:46:42 -0800

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

---

From: Lynne Bartholomew <[email-masked]>
Date: Fri, 20 Jan 2017 14:47:04 -0800

Dear Kathleen,

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

RFC Editor/lb

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Fri, 20 Jan 2017 22:54:44 +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.

Kathleen

Please excuse typos, sent from handheld device

On Jan 20, 2017, at 5:47 PM, Lynne Bartholomew <[email-masked]<mailto:[email-masked]>> wrote:

Dear Kathleen,

RFC Editor/lb

On Jan 20, 2017, at 12:46 PM, Lynne Bartholomew <[email-masked]<mailto:[email-masked]>> wrote:

Dear *Kathleen,

Thank you.

RFC Editor/lb

On Jan 13, 2017, at 10:11 AM, Lynne Bartholomew <[email-masked]<mailto:[email-masked]>> wrote:

Dear Kathleen,

Thank you for the email.

OLD:

NEW:

OLD:

NEW:

Thank you.

RFC Editor/lb

On Jan 13, 2017, at 7:36 AM, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

Thank you,
Kathleen

On Wed, Jan 11, 2017 at 3:28 PM, Bernard Aboba <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:

  Alan DeKok.

--

Best regards,
Kathleen
_______________________________________________
radext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/radext

--

Best regards,
Kathleen

---

From: Lynne Bartholomew <[email-masked]>
Date: Fri, 20 Jan 2017 15:12:27 -0800

Dear Kathleen,

Thank you very much for the prompt reply.  No rush -- we just wanted to make sure we were using the correct email address for you.

Thanks again!

RFC Editor/lb

On Jan 20, 2017, at 2:54 PM, Moriarty, Kathleen <[email-masked]> wrote:

> On Jan 20, 2017, at 5:47 PM, Lynne Bartholomew <[email-masked]> wrote:
> 
>> Dear Kathleen,
>>

---

From: [email-masked]
Date: Sat, 21 Jan 2017 10:22:02 -0500

Dear Lynne,

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

Yes, thank you.
Kathleen

---

From: Lynne Bartholomew <[email-masked]>
Date: Mon, 23 Jan 2017 09:51:31 -0800

Dear Kathleen,

We updated the first-page header and the Abstract per your note below.

The updated files are here:

   http://www.rfc-editor.org/authors/rfc8044.txt
   http://www.rfc-editor.org/authors/rfc8044-diff.html

This diff file shows these latest changes:

   http://www.rfc-editor.org/authors/rfc8044-lastdiff.html

We have noted your approval on the AUTH48 status page:

   https://www.rfc-editor.org/auth48/rfc8044

We will prepare this document for publication shortly, along with its companion document RFC 8045.

Thank you!

RFC Editor/lb

---

From: Lynne Bartholomew <[email-masked]>
Date: Mon, 23 Jan 2017 10:44:22 -0800

Dear Alan and *Kathleen,

We are preparing this document for publication, and we found that our question regarding the listing for RFC 4072 was not addressed.

RFC 4072 is listed under Normative References, but it is not cited anywhere in the text.  Please let us know whether it should be cited somewhere or removed from the references list.  Note for *Kathleen:  If the choice is to remove the reference, we will need your approval, because it is listed as Normative.

Thank you.

RFC Editor/lb

---

From: Alan DeKok <[email-masked]>
Date: Mon, 23 Jan 2017 13:51:29 -0500

> 
> On Jan 23, 2017, at 1:44 PM, Lynne Bartholomew <[email-masked]> wrote:
> 
> Dear Alan and *Kathleen,
> 

  It's listed as Normative because of the "Updates" line which says that this document updates RFC 4072.

  The only other reference to RFC 4072 was to via an attribute in the table which was removed.

  I think that leaving RFC 4072 as normative is the correct decision.

---

From: Lynne Bartholomew <[email-masked]>
Date: Mon, 23 Jan 2017 10:58:40 -0800

Apologies; RFC 4072 is now in the "updates" list and is listed in the Abstract.

RFC Editor/lb

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 23 Jan 2017 13:59:04 -0500

Thank you, all!

On Mon, Jan 23, 2017 at 1:58 PM, Lynne Bartholomew <[email-masked]>
wrote:

> >> We are preparing this document for publication, and we found that our
> question regarding the listing for RFC 4072 was not addressed.
> >>
> >> RFC 4072 is listed under Normative References, but it is not cited
> anywhere in the text.  Please let us know whether it should be cited
> somewhere or removed from the references list.  Note for *Kathleen:  If the
> choice is to remove the reference, we will need your approval, because it
> is listed as Normative.
> >

-- 

Best regards,
Kathleen