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

From: Ben Campbell <[email-masked]>
Date: Tue, 14 Aug 2018 20:18:17 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-radext-coa-proxy-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-radext-coa-proxy/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(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. I think it would be fine to progress it as Informational (or
even Experimental) if it included an applicability statement explaining why in
order to avoid the appearance of a standard masquerading as an Informational
RFC.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(My review is not yet complete; I wanted to get the DISUSS point out with as
much discussion time as possible. I expect to follow up with an update sometime
before the telechat.)

---

From: Alan DeKok <[email-masked]>
Date: Wed, 15 Aug 2018 07:45:13 -0400

On Aug 14, 2018, at 11:18 PM, Ben Campbell <[email-masked]> wrote:
> This draft is standards track, yet it primarily serves to extend RFC 5176.

  By adding new capabilities which are not implemented anywhere.

> That
> convincing.

  Those reasons apply to RFC 5176.  They don't apply to this document.

  Can we have a standards track document which defines *new* capabilities?  Capabilities which do not affect any existing implementation or deployment?

  Can we have a standards track document which depends on an informational document?

> Therefore I do not think it is appropriate to publish this draft as

---

From: Ben Campbell <[email-masked]>
Date: Wed, 15 Aug 2018 09:46:37 -0500

> On Aug 15, 2018, at 6:45 AM, Alan DeKok <[email-masked]> wrote:
> 

Granted.

>  Those reasons apply to RFC 5176.  They don't apply to this document.

Yes, but as you allude to below, this document depends on 5176. Given that it is an extension to 5176,  I’d say that it effectively incorporates 5176 by reference.

>  Can we have a standards track document which defines *new* capabilities?  Capabilities which do not affect any existing implementation or deployment?

Sure, that defines many, if not most, standards track documents.

>  Can we have a standards track document which depends on an informational document?

There’s the problem. According to RFC 2026, we cannot. The IESG can make exceptions under specific circumstances (see RFCs 3967 and 4897). The point of my DISCUSS is to force discussion of whether it is appropriate to make an exception for this draft.

My initial thoughts is that it is not appropriate to do so. This draft is a relatively small extension to 5176. It might be different if this draft incidentally depended on 5176, but in this case the informational RFC is the entire foundation of this draft.

If it’s important to make this draft standards track, then we should look into promoting 5176 to standards track.

Thanks,

Ben.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 15 Aug 2018 11:24:20 -0400

> Yes, but as you allude to below, this document depends on 5176. Given that it is an extension to 5176,  I’d say that it effectively incorporates 5176 by reference.

  Which means what?  That this document is really part of 5176, and that the caveats given in Section 1.1 should be applied, even though they don't apply to this document?

  I'm not sure I follow that logic.  "IF A then B" means that if A is false, then B is also false.

> There’s the problem. According to RFC 2026, we cannot. The IESG can make exceptions under specific circumstances (see RFCs 3967 and 4897). The point of my DISCUSS is to force discussion of whether…

  We already have RFC 5080 (proposed standard) which updates RFC 2866 (informational).

  Even more strongly, RFC 5080 points out errors in both the spec *and* in implementations.

  Which means that RFC 5080 took the opposite decision of 5176.  It marked existing implementations as non-compliant.  The reasons for that decision are historical.

> If it’s important to make this draft standards track, then we should look into promoting 5176 to standards track.

  Along with RFC 2866 (RADIUS accounting), RFC 2867, RFC 2868, RC 5997, RFC 6613 (TCP transport), RFC 6614 (TLS transport), and RFC 7360 (DTLS transport).  And probably more.  All of those documents are informational.  There have been discussions over the years about making them all standards track.

  However, the sad truth is that the RADIUS WG is essentially dead at this point.  There is little interest in revisiting 20 year-old specs, just to have them promoted to standards track.  And even if they were made standards track, the consensus has been that little of the content would change.

  As for this document, the WG was in favour of making it standards track, and it had support from the previous AD.  Exceptions have been made in the past in similar circumstances.

  I'm arguing this point simply because I'm not convinced by the counter-arguments.

  Alan DeKok.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 15 Aug 2018 15:01:21 -0500

>   I'm arguing this point simply because I'm not convinced by the counter-arguments.

Ultimately this is a decision for the IESG to make; it's seeming like we'll
need to have a conversation on tomorrow's telechat.

-Benjamin