Subject: Re: [radext] [Technical Errata Reported] RFC5176 (4280)

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 17 Mar 2015 11:59:02 -0400

Hello,

Is there agreement on the changes and do additional errata need to be filed
for the added text in this thread?

Thank you,
Kathleen

On Wed, Feb 25, 2015 at 9:46 AM, Alan DeKok <[email-masked]> wrote:

>   I agree.  There should be an additional paragraph after the paragraph
> below, saying:
>
> ...
>    Error-Cause MAY be included in a CoA-ACK and Disconnect-ACK packet to
>    indicate successful actions.  If it is included in those packets, the
> Value MUST
>    be within the range 200-299.
> ...
>
>   There is further discussion of CoA-ACK in the text describing the
> allowed VALUEs.  But there should be a short sentence in the Description,
> too.
>
> On Feb 24, 2015, at 6:07 PM, Bernard Aboba <[email-masked]>
> wrote:
>
> > The Description text should also be addressed in this Errata:
> >
> >   Description
> >
> >      It is possible that a Dynamic Authorization Server cannot honor
> >      Disconnect-Request or CoA-Request packets for some reason.  The
> >      Error-Cause Attribute provides more detail on the cause of the
> >      problem.  It MAY be included within CoA-NAK and Disconnect-NAK
> >      packets.
> >
> >
> > -----Original Message-----
> > From: RFC Errata System [mailto:[email-masked]]
> > Sent: Tuesday, February 24, 2015 12:42 PM
> > To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; Bernard Aboba; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked]
> > Subject: [Technical Errata Reported] RFC5176 (4280)
> >
> > The following errata report has been submitted for RFC5176, "Dynamic
> Authorization Extensions to Remote Authentication Dial In User Service
> (RADIUS)".
> >
> > --------------------------------------
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata_search.php?rfc=5176&eid=4280
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: Alan DeKok <[email-masked]>
> >
> > Section: 3.6
> >
> > Original Text
> > -------------
> >   0         0        0+  101   Error-Cause
> >
> >
> > In both tables, for CoA and Disconnect messages.
> >
> > Corrected Text
> > --------------
> >   0         0+        0+  101   Error-Cause
> >
> >
> > In both tables, for CoA and Disconnect messages.
> >
> > Notes
> > -----
> > Section 3.5 says that Error-Cause may be sent in a CoA-ACK or
> Disconnect-ACK packet:
> >
> >      ...
> >      Values 200-299 represent successful completion, so that these
> >      values may only be sent within CoA-ACK or Disconnect-ACK packets
> >
> > Instructions:
> > -------------
> > This erratum is currently posted as "Reported". If necessary, please use
> "Reply All" to discuss whether it should be verified or rejected. When a
> decision is reached, the verifying party (IESG) can log in to change the
> status and edit the report, if necessary.
> >
> > --------------------------------------
> > RFC5176 (draft-ietf-radext-rfc3576bis-13)
> > --------------------------------------
> > Title               : Dynamic Authorization Extensions to Remote
> Authentication Dial In User Service (RADIUS)
> > Publication Date    : January 2008
> > Author(s)           : M. Chiba, G. Dommety, M. Eklund, D. Mitton, B.
> Aboba
> > Category            : INFORMATIONAL
> > Source              : RADIUS EXTensions
> > Area                : Operations and Management
> > Stream              : IETF
> > Verifying Party     : IESG
> >
>
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext
>

-- 

Best regards,
Kathleen

---

From: Stefan Winter <[email-masked]>
Date: Mon, 23 Mar 2015 09:40:41 +0100

Hello,

> Is there agreement on the changes and do additional errata need to be
> filed for the added text in this thread?

There was no disagreement on the Errata - it seems to be correct.

I'm not enough into process questions to answer the second part, so: the
text sketches make sense, but do we need to file a second errata, or can
we "mangle" the original errata text to include this? Seems a bit
strange to me to have two Errata for one underlying issue; I'd prefer to
have all changes in one ...

Since most of you are in Denver, maybe shortly touching this question in
the meeting makes sense?

Greetings,

Stefan Winter

> 
> Thank you,
> Kathleen
> 
> On Wed, Feb 25, 2015 at 9:46 AM, Alan DeKok <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>       I agree.  There should be an additional paragraph after the
>     paragraph below, saying:
> 
>     ...
>        indicate successful actions.  If it is included in those packets,
>     the Value MUST
>     allowed VALUEs.  But there should be a short sentence in the
>     Description, too.
> 
>     On Feb 24, 2015, at 6:07 PM, Bernard Aboba
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
> 
>     > From: RFC Errata System [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     > To: [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; Bernard Aboba; [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     > Cc: [email-masked] <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     > The following errata report has been submitted for RFC5176,
>     "Dynamic Authorization Extensions to Remote Authentication Dial In
>     User Service (RADIUS)".
>     >
>     > Reported by: Alan DeKok <[email-masked]
>     <mailto:[email-masked]>>
>     >
>     > Section: 3.6
>     >
>     > Original Text
>     > -------------
>     >   0         0        0+  101   Error-Cause
>     >
>     >
>     > This erratum is currently posted as "Reported". If necessary,
>     please use "Reply All" to discuss whether it should be verified or
>     rejected. When a decision is reached, the verifying party (IESG) can
>     log in to change the status and edit the report, if necessary.
>     >
>     > Author(s)           : M. Chiba, G. Dommety, M. Eklund, D. Mitton,
>     B. Aboba
>     > Category            : INFORMATIONAL
>     [email-masked] <mailto:[email-masked]>

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: <[email-masked]>
Date: Mon, 23 Mar 2015 15:21:19 +0000

Hi,

I think also that two separate Errata should be created.

Regards,

Lionel

-----Message d'origine-----
De : Stefan Winter [mailto:[email-masked]] 
Envoyé : lundi 23 mars 2015 09:41
À : Kathleen Moriarty; Alan DeKok
Cc : [email-masked]; [email-masked]; MORAND Lionel IMT/OLN; [email-masked]; Bernard Aboba; [email-masked]; [email-masked]; [email-masked]; [email-masked]; RFC Errata System
Objet : Re: [radext] [Technical Errata Reported] RFC5176 (4280)

Hello,

I'm not enough into process questions to answer the second part, so: the text sketches make sense, but do we need to file a second errata, or can we "mangle" the original errata text to include this? Seems a bit strange to me to have two Errata for one underlying issue; I'd prefer to have all changes in one ...

Since most of you are in Denver, maybe shortly touching this question in the meeting makes sense?

Greetings,

Stefan Winter

--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.