Subject: [radext] Q on RFC6158

From: Leaf yeh <[email-masked]>
Date: Wed, 15 Feb 2012 11:23:11 +0000

The following might be Editorial Errata against RFC6158.

Section 2.1, Original Text: 

Note that the length limitations for VSAs of type String and Text are
less than 253 octets, due to the additional overhead of the Vendor-
Specific encoding.

Corrected Text -1 might be: 

'Note that the length limitations for VSAs of type String and Text are
less than 247 octets, due to the additional overhead of the Vendor-
Specific encoding.' 

If it complies with the text, 'For [RFC2865] RADIUS VSAs, the length limitation of the String and
Text types is 247 octets instead of 253 octets, due to the additional
overhead of the Vendor-Specific Attribute.', in section 3.2.1 of RFC6158.

Corrected Text -2 might be:

'Note that the length limitations for VSAs of type String and Text are
less than 249 octets, due to the additional overhead of the Vendor-
Specific encoding.'

If it complies with the definition of VAS in section 5.26 of RFC2865.

Corrected Text -3 might be:

'Note that the length limitations for VSAs of type String and Text are
less than 248 octets, due to the additional overhead of the Vendor-
Specific encoding.'

If it adopts the format meaningfully in the section of 4.1 of draft-ietf-radext-radius-extensions-04.txt.

Right? 

Best Regards,
Leaf

---

From: Alan DeKok <[email-masked]>
Date: Wed, 15 Feb 2012 12:57:59 +0100

> Corrected Text -1 might be: 

  First, what's wrong with the text?  It's factually accurate.

  The context of the text is important.  The line before it says about
Basic Data Types:

 * UTF-8 text [RFC3629], totaling 253 octets or less in length.

  So... the paragraph following notes that VSAs have a limit of less
than 253 octets of textual data.

  There is no need for that section to enumerate all of the possible
length limitations of attributes.  There is *absolutely* no need for RFC
6158 to note length limitations based on the extensions draft.

  Alan DeKok.
_______________________________________________
radext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/radext

---

From: Alan DeKok <[email-masked]>
Date: Wed, 15 Feb 2012 12:57:59 +0100

Alan DeKok.

---

From: Leaf yeh <[email-masked]>
Date: Thu, 16 Feb 2012 01:27:22 +0000

Alan -  So... the paragraph following notes that VSAs have a limit of less
than 253 octets of textual data.

If we follow the above logic, I suppose the below statement is not necessary to appear in the section 2.1 of RFC6158,

> less than 253 octets, due to the additional overhead of the Vendor-

especially for the part of '..., due to the additional overhead of the Vendor Specific encoding.'

I suggest to delete the above paragraph in section 2.1 or the keep it the same logic as that in section 3.2.1 shown as follows:

<quote> For [RFC2865] RADIUS VSAs, the length limitation of the String and
Text types is 247 octets instead of 253 octets, due to the additional
overhead of the Vendor-Specific Attribute. </quote>

Alan - It's factually accurate.

The text is factually 'right', because 247 is less than 253, but the logic above seems wrong.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan DeKok
Sent: Wednesday, February 15, 2012 7:58 PM
To: Leaf yeh
Cc: [email-masked]; [email-masked]
Subject: Re: [radext] Q on RFC6158

  Alan DeKok.

---

From: Leaf yeh <[email-masked]>
Date: Thu, 16 Feb 2012 01:27:22 +0000

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan DeKok
Sent: Wednesday, February 15, 2012 7:58 PM
To: Leaf yeh
Cc: [email-masked]; [email-masked]
Subject: Re: [radext] Q on RFC6158

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 16 Feb 2012 09:00:07 +0100

> If we follow the above logic, I suppose the below statement is not necessary to appear in the section 2.1 of RFC6158,

  If we follow that logic, much of RFC 5080 is unnecessary, because the
correct behavior is obvious.  Sadly, not everyone sees the obvious.

> I suggest to delete the above paragraph in section 2.1 or the keep it the same logic as that in section 3.2.1 shown as follows:

  How will this *improve* the document?

  i.e. how is the text an errata, and how is the change a solution to
the errata?

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 16 Feb 2012 09:00:07 +0100

Alan DeKok.

---

From: Leaf yeh <[email-masked]>
Date: Thu, 16 Feb 2012 08:19:13 +0000

Alan - How will this *improve* the document?

The Typo or the Editorial Errata could result in the 'Corrected Text' -1 written as: 

Best Regards,
Leaf

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Thursday, February 16, 2012 4:00 PM
To: Leaf yeh
Cc: [email-masked]; [email-masked]
Subject: Re: [radext] Q on RFC6158

  Alan DeKok.

---

From: Leaf yeh <[email-masked]>
Date: Thu, 16 Feb 2012 08:19:13 +0000

Best Regards,
Leaf

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Thursday, February 16, 2012 4:00 PM
To: Leaf yeh
Cc: [email-masked]; [email-masked]
Subject: Re: [radext] Q on RFC6158

  Alan DeKok.