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

Thank you, Lionel!

On Tue, Apr 21, 2015 at 3:23 PM, <lionel.morand@orange.com> wrote:

>  it was agreed to have two distinct errata and I was expecting a new one
> from Alan. I will issue a new one tomorrow.
>
> The step for this current errata report can be set to "verified".
>
> And it will be the same step for the next to come.
>
>
>
> Regards,
>
>
>
> Lionel
>
>
>
> *De :* Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]
> *Envoyé :* mardi 21 avril 2015 19:20
> *À :* MORAND Lionel IMT/OLN
> *Cc :* Stefan Winter; Alan DeKok; gdommety@cisco.com; radext@ietf.org;
> joelja@bogus.com; Bernard Aboba; david@mitton.com; bclaise@cisco.com;
> meklund@cisco.com; mchiba@cisco.com; RFC Errata System
>
> *Objet :* Re: [radext] [Technical Errata Reported] RFC5176 (4280)
>
>
>
> Hello,
>
>
>
> Where do we stand on this, is there a second errata or should I reject
> 4280 and wait for a new one that covers everything to be submitted?
>
>
>
> Thank you,
>
> Kathleen
>
>
>
> On Mon, Mar 23, 2015 at 11:21 AM, <lionel.morand@orange.com> wrote:
>
> Hi,
>
> I think also that two separate Errata should be created.
>
> Regards,
>
> Lionel
>
> -----Message d'origine-----
> De : Stefan Winter [mailto:stefan.winter@restena.lu]
> Envoyé : lundi 23 mars 2015 09:41
> À : Kathleen Moriarty; Alan DeKok
> Cc : gdommety@cisco.com; radext@ietf.org; MORAND Lionel IMT/OLN;
> joelja@bogus.com; Bernard Aboba; david@mitton.com; bclaise@cisco.com;
> meklund@cisco.com; mchiba@cisco.com; RFC Errata System
> Objet : Re: [radext] [Technical Errata Reported] RFC5176 (4280)
>
>
> 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 <aland@freeradius.org
> > <mailto:aland@freeradius.org>> 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
> >     <Bernard.Aboba@microsoft.com <mailto:Bernard.Aboba@microsoft.com>>
> >     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:rfc-editor@rfc-editor.org
> >     <mailto:rfc-editor@rfc-editor.org>]
> >     > Sent: Tuesday, February 24, 2015 12:42 PM
> >     > To: mchiba@cisco.com <mailto:mchiba@cisco.com>; gdommety@cisco.com
> >     <mailto:gdommety@cisco.com>; meklund@cisco.com
> >     <mailto:meklund@cisco.com>; david@mitton.com
> >     <mailto:david@mitton.com>; Bernard Aboba; bclaise@cisco.com
> >     <mailto:bclaise@cisco.com>; joelja@bogus.com
> >     <mailto:joelja@bogus.com>; stefan.winter@restena.lu
> >     <mailto:stefan.winter@restena.lu>; lionel.morand@orange.com
> >     <mailto:lionel.morand@orange.com>
> >     > Cc: aland@freeradius.org <mailto:aland@freeradius.org>;
> >     radext@ietf.org <mailto:radext@ietf.org>; rfc-editor@rfc-editor.org
> >     <mailto:rfc-editor@rfc-editor.org>
> >     > 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 <aland@freeradius.org
> >     <mailto:aland@freeradius.org>>
> >     >
> >     > 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
> >     radext@ietf.org <mailto:radext@ietf.org>
> >     https://www.ietf.org/mailman/listinfo/radext
> >
> >
> >
> >
> > --
> >
> > Best regards,
> > Kathleen
> >
> >
> > _______________________________________________
> > radext mailing list
> > radext@ietf.org
> > https://www.ietf.org/mailman/listinfo/radext
> >
>
>
> --
> 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
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>
>
>
>
> --
>
>
>
> Best regards,
>
> Kathleen
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>

-- 

Best regards,
Kathleen