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

[Kathleen Moriarty <[e-mail]>]

Thanks, Lionel.  One more question in-line.

On Tue, Apr 21, 2015 at 3:44 PM, <[e-mail]> wrote:

>  I'm OK with this erratum but I would provide further clarifications.
>
> First, I would recommend to clarify what "mandatory" in the context of
> RADIUS.
>

I can replace the text with what you provided below, but if clarifying what
"mandatory" means is needed.  Can someone propose text within the paragraph
below so I have the full replacement text?  If I am just doing "Hold For
Document Update", I can add this in a not as well.  I'd just like to get
the agreed upon text.

>  I would also highlight the specific case of the Proxy-State.
>
>
>
> I would propose the following text:
>
>
>
> In CoA-Request and Disconnect-Request packets, all attributes MUST
> be treated as mandatory to understand by the NAS, except Proxy-State
>
> attributes that MUST be treated as opaque data. See Section 3.1 for
>
> further details on the handling of Proxy-State attributes by NAS.
>
>
>
> let me know if it is OK for you.
>

Thank you,
Kathleen

>
>
> regards,
>
>
>
> Lionel
>
>
>
> *De :* Kathleen Moriarty [mailto:[e-mail]]
> *Envoyé :* mardi 21 avril 2015 19:16
> *À :* RFC Errata System
> *Cc :* [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; Benoit Claise; joel jaeggli;
> Stefan Winter; MORAND Lionel IMT/OLN; [e-mail]; Alan DeKok
> *Objet :* Re: [radext] [Technical Errata Reported] RFC5176 (4311)
>
>
>
> Hello,
>
>
>
> I haven't seen any discussion on this from the Radext WG.  The report
> looks reasonable and make sense to me, but would like to hear from the
> chairs to confirm.  Since this is getting addressed in a new draft, I would
> be included to mark this as "Hold for Document Update".  This puts the
> errata with this draft (it's not rejected) and can be added to a new
> revision of this particular draft if it gets updated in the future.
>
>
>
> Please let me know if you agree/disagree and I'll mark it appropriately.
>
>
>
> Thanks!
>
>
>
> On Mon, Mar 23, 2015 at 12:50 PM, RFC Errata System <
> [e-mail]> wrote:
>
> 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=4311
>
> --------------------------------------
> Type: Technical
> Reported by: Alan DeKok <[e-mail]>
>
> Section: 2.3
>
> Original Text
> -------------
> Section 2.3 says:
>
>       In CoA-Request and Disconnect-Request packets, all attributes MUST
>       be treated as mandatory.
>
>
> Corrected Text
> --------------
> In CoA-Request and Disconnect-Request packets, all attributes MUST
> be treated as mandatory, except Proxy-State.  See Section 3.1 for a
> discussion of how the NAS must handle Proxy-State.
>
> Notes
> -----
> This was seen with vendor equipment.  CoA proxying was done to the NAS,
> and the proxy was adding and forwarding Proxy-State as required by Section
> 3.1.  However, the NAS was returning a CoA-NAK with Error-Cause =
> Unsupported-Attribute.
>
> The issue comes because Proxy-State is called out in Section 3.1 for
> special handling.  However, that special handling isn't called out in
> Section 2.3.  As a result, implementors can get confused.
>
> The RADEXT WG is rechartering with a document to address CoA proxying.  We
> will also be addressing this issue in that document.  There are additional
> attributes which a NAS should ignore, OR which should be filtered out by
> the proxy closest to the NAS.
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext
>
>
>
>
>
> --
>
>
>
> 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