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

[Leaf yeh <leaf.y.yeh@huawei.com>]

Alan DeKok - Saying they don't "deserver" to be deprecated isn't a useful response.

It was just my argument, sorry for that. Let's wait for the decision made by the WG or IESG.

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:

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?

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?

Leaf - >3. Section 2.3 - TLV-Length
> ' If a client or server
>       receives a TLV with an invalid TLV-Length, then the attribute
>       which encapsulates that TLV MUST be deemed to be an "invalid
>       attribute", it SHOULD be silently discarded. '
Alan DeKok - We discard the TLV that is invalid. We don't discard the attribute which encapsulates it.

But the above text sounds to discard the whole encapsulating attribute.


Best Regards,
Leaf


-----Original Message-----
From: Alan DeKok [mailto:aland@deployingradius.com] 
Sent: Saturday, October 29, 2011 2:50 PM
To: Leaf yeh
Cc: Bernard Aboba; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang; Qianguofeng
Subject: Re: WGLC for draft-ietf-radext-radius-extensions-01

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/>