Subject: [radext] Alissa Cooper's No Objection on draft-ietf-radext-coa-proxy-06: (with COMMENT)

From: Alissa Cooper <[email-masked]>
Date: Wed, 15 Aug 2018 11:33:39 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-radext-coa-proxy-06: No Objection

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/

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

S 3.3.

>      The new Operator-NAS-Identifier attribute is defined as follows.

I suggest adding the depiction of the fields and their lengths in
bytes, as is done in RFC 5580. I was a little confused about whether
the fields in the attribute are just the TLV.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 15 Aug 2018 15:25:50 -0400

> the fields in the attribute are just the TLV.

  There are no fields in the Operator-NAS-Identifier attribute.  it's just an opaque blob.

  Maybe you were thinking of the Operator-Name attribute?  That's defined already in RFC 5580.  I don't think there's a need to re-use that text here.

  Alan DeKok.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 15 Aug 2018 12:44:09 -0700

>   There are no fields in the Operator-NAS-Identifier attribute.  it's just

I believe what Alissa means is that it's variable length and therefore must
be somehow delimited.

-Ekr

>   Maybe you were thinking of the Operator-Name attribute?  That's defined
> already in RFC 5580.  I don't think there's a need to re-use that text here.
>
>   Alan DeKok.
>
>

---

From: Alan DeKok <[email-masked]>
Date: Wed, 15 Aug 2018 15:50:06 -0400

On Aug 15, 2018, at 3:44 PM, Eric Rescorla <[email-masked]> wrote:
> 
> On Wed, Aug 15, 2018 at 12:25 PM, Alan DeKok <[email-masked]> wrote:
> I believe what Alissa means is that it's variable length and therefore must be somehow delimited.

  The encapsulating RADIUS attribute header has a "Length" field.  That delimits the Operator-NAS-Identifier value.

  The value itself is (again) just an opaque blob.  The value can have any length, 1 to 32 octets.  There is no intrinsic meaning in any one octet of the value.

  There is no need for the *contents* of the attribute to have any delimitation whatsoever.

  Alan DeKok.

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 15 Aug 2018 16:02:36 -0400

> On Aug 15, 2018, at 3:50 PM, Alan DeKok <[email-masked]> wrote:
> 

Acknowledging my limited recall of how RADIUS attributes are defined, I think what is tripping me up is the definition of the Length field, which says “4 to 23.” If I assume that length is measured in octets, that the type field requires 1 octet, that the length field requires 1 octet, and that the value can be between 1 and 32 octets long, I would conclude that valid length values would be between 3 and 34, not between 4 and 23. Can you clarify why not?

This is I guess the root of why I thought the octet diagram would help.

Alissa

---

From: Alan DeKok <[email-masked]>
Date: Wed, 15 Aug 2018 16:05:06 -0400

> Acknowledging my limited recall of how RADIUS attributes are defined, I think what is tripping me up is the definition of the Length field, which says “4 to 23.” If I assume that length is measured…

  The Length of the attribute typically refers to allowed values of the Length field in the RADIUS attribute header.  That Length includes the octets of the header.

  In this case, 3.

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 15 Aug 2018 16:11:30 -0400

> On Aug 15, 2018, at 4:05 PM, Alan DeKok <[email-masked]> wrote:
> 

Ok, I see you’ve agreed to fix this in another thread.

Thanks,
Alissa