Re: [radext] WGLC for draft-ietf-radext-radius-extensions-01

[Leaf yeh <[e-mail]>]

One more editorial on the title of the draft, remember someone express the same in the ML, I just repeat it here.

'Remote Authentication Dial In User Service (RADIUS) Protocol Extensions '

But RFC2869 has the title of 'RADIUS Extensions'. They looks very similarly.

How about to re-title your draft? My suggesting might be 'RADIUS Extension Plus on the Type Space of Attributes with more Data Types', just for your reference.


----------------------------------------------------------
One more argument on the text in section 9.1

'New allocations are
normally taken from the Extended Type space, starting with lower
numbered attributes.'

But the attributes, including

241.26  Extended-Vendor-Specific-1
242.26  Extended-Vendor-Specific-2
243.26  Extended-Vendor-Specific-3
244.26  Extended-Vendor-Specific-4
245.26  Extended-Vendor-Specific-5
246.26  Extended-Vendor-Specific-6

seem not follow the above words.

Could it let to be decided by IANA?


Best Regards,
Leaf


-----Original Message-----
From: Alan DeKok [mailto:[e-mail]] 
Sent: Saturday, October 29, 2011 7:27 PM
To: Leaf yeh
Cc: Bernard Aboba; [e-mail]; [e-mail]; Qiujin; Wangshuxiang; Qianguofeng
Subject: Re: WGLC for draft-ietf-radext-radius-extensions-01

Leaf yeh wrote:
> Alan DeKok - Your question assumes that the input packet is edited to remove the attribute. This is not true. When the text says "discard the attribute", it means "ignore it".
> 
> Yes. 'Ignore' sounds better, but the question in technique seems still there. I guess the implementation might have some different treatment here:

  No.  The document describes the correct behavior.  There are no
implementation choices.

> 1. ignore the whole packet; then request the 2nd time; or
> 2. ignore the attributes followed this invalid attribute; or 
> 3. ignore only this invalid attribute, and delimit the next attribute per the 'length' field of this invalid attribute; 
> 
> Does the 3rd one means 'silently discard' in your text?

  Possibly.  I still don't understand why the text is unclear.  You're
focused on parsing the RADIUS packet.  The text about "invalid
attribute" is talking about the *attribute*, not the *packet*.

> Alan DeKok - The "invalid attribute" is correctly formed, so that the entire packet can be correctly decoded. The text says this explicitly.
> 
> Could you show me the explicit text in your draft mentioned above?

  The text which defines the "invalid attribute" term at the top of the
document.  It says that the Length field is valid, but the *Value* field
is wrong.  Since the Length field is valid, the packet can be parsed
correctly.  So the entire packet is correctly formed.

  Again, the term "invalid attribute" refers to the *Value* field of an
attribute.  It has nothing to do with parsing the packet.

  I really don't know how to make this any clearer.

  Alan DeKok.