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

[Alan DeKok <aland@deployingradius.com>]

Leaf yeh wrote:
> Alan DeKok - We wish to reserve the 144..191 space for future extensions, or for specifications which can't use the extended space. 
> 
> Can we suppose the following codes are reserved for the future extension?

  Yes, they are.

> I meant the space of 144-191 doesn't really deserve to be ' Deprecated'.

  I explained my reasons.  Saying they don't "deserver" to be deprecated
isn't a useful response.

> Alan DeKok - The alternative is to allow allocation from 144..191.
> What will happen is that no one will use the extended space, and the 144..11 space will quickly be completely allocated.
> 
> Understand, but it looks harmless even we expect that happen.

  By the same argument, there's no harm in requiring people to use the
extended space.

>> How about the compliant implementation will do? Will the Octets per the Length of the attribute, eg. 2 or 3, will be discarded?
> Alan DeKok - I have no idea what that means.
> 
> I meant ' If a client or server receives an Extended Attribute with a Length of 2 or 3, then that Attribute MUST be deemed to be an "invalid attribute", it SHOULD be silently discarded.', then how to do discard this attribute? Does it mean the octets, per the Length of the attribute, eg. 2 or 3, from the 1st octet of 'Type', will be discarded? 

  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".

> Can we trust all the attributes followed this 'invalid' attribute' in the Radius packet, if the delimitation of these attributes turns to be some kind of suspicious or difficult?

  I have no idea what that means.

> Leaf - > Then how to delimit the next attribute?
> Alan DeKok - I don't know what that means, either.
> 
> I meant how to figure out the beginning octet of the next attribute followed this 'invalid' attribute'?

  You haven't read the draft, then.  The "invalid attribute" is
correctly formed, so that the entire packet can be correctly decoded.
The text says this explicitly.

  So your question above is based on an incorrect assumption: the
"invalid attribute" means "malformed RADIUS packet".

> Alan DeKok - We discard the TLV that is invalid. We don't discard the attribute which encapsulates it.
> 
> There exists the same issue described above.

  The same misunderstanding applies here, too.

> One more Editorial 
..
> Would you mind to change the above 'String's to be 'Value's? 
> 
> That might mean more replacements in section 4.1, 4.2, 4.3, 4.4, 4.5 & 4.6.

  Already done.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>