Subject: [radext] Adoption call for draft-hartman-radext-bigger-packets

From: Jouni Korhonen <[email-masked]>
Date: Tue, 18 Mar 2014 11:48:01 +0800

Folks,

We had good support to adopt draft-hartman-radext-bigger-packets I-D as a WG
item during the London WG meeting. However, we need to confirm the adoption
in the mailing list. This mail starts a one week adoption call for the I-D.

If you are against the adoption, voice your opinion and why. Silence is
counted as an acceptance. The call ends 25th March.

- Jouni & Stefan

---

From: Peter Deacon <[email-masked]>
Date: Mon, 24 Mar 2014 09:43:23 -0700 (Pacific Daylight Time)

> counted as an acceptance. The call ends 25th March.

I do not support adoption at this time.  Seeing value in continuing to 
support UDP/DTLS no bridge is available for CoA and Accounting.  Noting 
also did not support rational in Alex's draft for ignoring this issue for 
reasons explained in detail earlier on this list.

Would like to see a solution whether it's bigger packets, extended request 
or something else offer full coverage yet enable implementors to support 
any subset they see value in supporting.

If systems are to start transmitting more than max size I prefer a less 
permissive environment where some indication of support is required up 
front prior to transmitting larger messages.  It can be a manual setting 
or an automatic "discovery" yet would prefer something "MUST" be 
indicated.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Mon, 24 Mar 2014 12:46:15 -0400

Peter Deacon wrote:
> also did not support rational in Alex's draft for ignoring this issue
> for reasons explained in detail earlier on this list.

  That is unnecessary, for reasons explained in detail earlier on this list.

> or an automatic "discovery" yet would prefer something "MUST" be indicated.

  The draft discusses negotiation of large packets, which seems to
address the above concerns.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 24 Mar 2014 12:49:00 -0400

For the record, I support Alan's response to Peter and after evaluating
Peter's concerns still support adopting my draft.

--Sam

---

From: Peter Deacon <[email-masked]>
Date: Mon, 24 Mar 2014 10:09:25 -0700 (Pacific Daylight Time)

>  That is unnecessary, for reasons explained in detail earlier on this list.

There is no defined mechanism for coalescing accounting sessions. 
Multi-Session-Id is inter-session rather than intra-session.

Binding CoA to authorization is not something we can support seeing value 
in maintaining autonomy to manage admitted sessions separately from 
authorization.

> address the above concerns.

A list of optional procedures are defined.  What I don't see is where it 
says one of them must be followed or an implementation must not assume 
support for larger packets.

regards,
Peter

---

From: Sam Hartman <[email-masked]>
Date: Mon, 24 Mar 2014 13:19:30 -0400

>>>>> "Peter" == Peter Deacon <[email-masked]> writes:

    Peter> On Mon, 24 Mar 2014, Alan DeKok wrote:
    Peter> A list of optional procedures are defined.  What I don't see
    Peter> is where it says one of them must be followed or an
    Peter> implementation must not assume support for larger packets.

I care about a deployment where we will assume sending large packets is
supported and where that's reasonable.
I've explained in the draft why I think there are cases where this is a
reasonable assumption.

I've also explained why  I think there is no significant harm to the
approach outlined in the draft.

we are not in agreement on this issue, and the chairs will need to judge
consensus on whether a change is required or on whether this should
block adoption.

thanks for sharing your concern.

--Sam

---

From: Alan DeKok <[email-masked]>
Date: Mon, 24 Mar 2014 13:20:04 -0400

> There is no defined mechanism for coalescing accounting sessions.

  Exactly.  Doing so is outside of the scope of RADIUS.

> Multi-Session-Id is inter-session rather than intra-session.

  Not the way it's used in 3GPP / WiMAX.  Check the list archives.

  This is the problem with RADIUS.  So much is either left unsaid, or is
ambiguous.  Your assumptions about how *you* use RADIUS don't always
translate to how others use it.

> Binding CoA to authorization is not something we can support seeing
> value in maintaining autonomy to manage admitted sessions separately
> from authorization.

  That's an opinion.

> support for larger packets.

  The draft explicitly discusses negotiation, prior to sending large
packets.  This directly addresses your concerns.

  Alan DeKok.

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 26 Mar 2014 14:36:28 +0200

Folks,

The adoption call has ended for this I-D. I recon there is some
voices against the adoption. However, the chairs still think the
positive feedback we got in London and also on the list favours
for the adoption.

- Jouni & Stefan