Re: [radext] Ben Campbell's Discuss on draft-ietf-radext-coa-proxy-06: (with DISCUSS and COMMENT)

[Ben Campbell <[e-mail]>]

> On Aug 15, 2018, at 8:14 PM, Alan DeKok <[e-mail]> wrote:
> 
> On Aug 15, 2018, at 3:55 PM, Ben Campbell <[e-mail]> wrote:
>> (This is a procedural DISCUSS. Hopefully it can be resolved easily, but I do
>> think it needs to be resolved prior to publication..)
>> 
>> This draft is standards track, yet it primarily serves to extend RFC 5176. That
>> RFC is informational. The shepherd writeup argues that this is okay because it
>> seems like 5176 should have been standards track. But the applicability
>> statement RFC 5176 explains why it was informational, and the reasons seem
>> convincing. Therefore I do not think it is appropriate to publish this draft as
>> Standards Track.
> 
>  We may choose Informational for this document, because it has a normative dependency on RFC 5176.
> 
>  But I don't see how those two last sentences are related.  The argument which is convincing for 5176 is not applicable to this document. So conflating the two applicability statements is simply not appropriate.
> 
>  i.e. the issues highlighted in Section 1.1 of RFC 5176 do not apply to this document.  Any applicability statement here would be *false* if it repeated (or even normatively referenced) the discussion in RFC 5176.

What I had in mind was just a statement to the effect that, while this extension includes normative language, it is informational because it is based on RFC 5176, which is also informational.

However, I do not understand your point that the applicability statement from 5176 does not apply to this draft. It basically says that 5176 is informational because CoA has (or had) issues (security, architectural, etc) that made it inappropriate for standards track. Since this draft is fundamentally based on 5176, it seems like it would inherit those issues. Or do you think all those issues have been mitigated, either by this draft or others? (The answer is probably academic, in that it addresses the question about whether 5176 _should_ still be informational, which doesn’t change the fact that it _is_.)


> 
>> I think it would be fine to progress it as Informational (or
>> even Experimental)
> 
>  If it's Experimental, then any possible subsequent Standards track document would run into the same problem: 5176 is Informational.
> 
>  And if we're being realistic... I think we're past the point where we can expect RADIUS Information or Experimental documents to progress to Standards track.  I can't for the life of me think of a single RADIUS document which has progressed from Informational or Experimental to Proposed Standard.  And, the RADIUS WG is on the verge of shutting down, with no new work envisioned.
> 
>  And if 20+ years isn't enough to make RFC 2866 (RADIUS accounting) a Proposed Standard, then I suspect no further progress will be made in the next 20 years.
> 
>> if it included an applicability statement explaining why in
>> order to avoid the appearance of a standard masquerading as an Informational
>> RFC.
> 
>  "This document is Informational because it updates RFC 5176, which is itself Informational.  None of the applicability statements in Section 1.1 of RFC 5176 apply to this document."
> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> Thanks for a readable and understandable drafts. I have some additional
>> comments that do not rise to the level of a DISCUSS
>> 
>> Substantive Comments:
>> 
>> - I support Adam's DISCUSS point concerning the security properties of
>> Operator-NAS-Identifier. But I will let that play out in Adam's thread.
>> 
>> §3.1 and §3,3: Do the normative changes to Access-Request and
>> Accounting-Request mean that this draft needs to update documents other than
>> just RFC 5176?
> 
>  The document does not provide for normative changes to Access-Request or Accounting-Request packets.  As with other RFCs that define new RADIUS attributes (e.g. 5580), it does not update RFC 2865 or 2866.
> 
>  i.e. simply carrying a new attribute is not a normative change to those packets.
> 
>> Editorial Comments:
>> 
>> - The abstract and introduction explain how this draft updates 5176, which is
>> good. However, they avoid using the explicit term-of-art "Updates RFC 5176".
>> Doing so would help make things more explicit. (The RFC style guide recommends
>> doing this at least in the abstract.)
> 
>  Fixed.
> 
>> - Please expand PPTP and L2TP on first mention.
> 
>  Fixed.
> 
>> §3.1: I suspect some of the normative keywords in this section refer to
>> previously existing requirements rather than new requirements. If  so, they
>> should not be capitalized except in literal quotes.
> 
>  The normative keywords do not refer to previously existing requirements.
> 
>> §6: I think it would be helpful to mention the discussion in §4.3 in the
>> security considerations.
> 
>  Sure.
> 
>> §7: It would be helpful for the IANA considerations to briefly summarize the
>> new attributes, so that a reader that started out reading the IANA
>> considerations doesn't have to flip back to §3.3 just to find out what they are.
> 
>  The latest draft has the updates.  IANA has the allocation ready, and it has been reviewed.
> 
>  Alan DeKok.