Opened 9 years ago
Closed 9 years ago
#177 closed task (fixed)
text in section 11.2 up-to-date?
Reported by: | stefan.winter@… | Owned by: | draft-ietf-radext-radius-fragmentation@… |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | radius-fragmentation | Version: | |
Severity: | Waiting for Shepherd Writeup | Keywords: | |
Cc: |
Description
Regarding "Operational Considerations" in -06:
I think it is a good idea to have such a section, specially is you think
it will be requested by ops-dir reviewers if not present. I would place
it as section 10, right before "Security considerations" section,
instead of in the Introduction section, to avoid basing the explanations
on something that has not been described yet.
I also think that the "formal violation..." discussion should be moved
here. We could also include the "proxying based on User-Name"
restriction too.
You did move the formal violation part to that new section, which is great, but the text itself is not the version I see circulated last on the mailing list. Was the change of text intentional, or is this an oversight that should be fixed?
The latest text I found in the ML archive is from 19 mar 2014, 11:17 my time:
(Alan DeKok:)
Perhaps this (word-smithing)
The authors acknowledge that this specification violates the "MUST"
requirement of [RFC2865] Section 4.1. We note that a proxy which
enforces that requirement would be unable to support future RADIUS
authentication extensions. Extensions to the protocol would therefore
be impossible to deploy.
All known implementations have chosen the philosophy of "be liberal in
what you accept". That is, they accept traffic which violates the
requirement of [RFC2865] Section 4.1. We therefore expect to see no
operational issues with this specification. After we gain more
operational experience with this specification, it can be re-issued
as a standards track document, and update [RFC2865].
(you:)
Thanks for the improved text. I will use it.
Please clarify which text should be in the final version.
Change History (2)
comment:1 Changed 9 years ago by alex@…
comment:2 Changed 9 years ago by stefan.winter@…
- Resolution set to fixed
- Status changed from new to closed
Revision -07 has the corrected text, closing this issue as Resolved.
You are right. For some reason I forgot adding this improved text Alan provided. So yes, that would be the most updated version, and I'll include it into the upcoming -07 release.