[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: WGLC for draft-ietf-radext-radius-extensions-01
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?
192-223 Experimental Use [RFC3575]
224-240 Implementation Specific [RFC3575]
247-255 Reserved [RFC3575]
Note: 241-246 Extended type [Defined in draft-ietf-radext-radius-extensions]
I meant the space of 144-191 doesn't really deserve to be ' Deprecated'.
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.
Leaf - > 2. Section 2.1 - Length
> '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. If it is not discarded, it MUST NOT be handled in the
> same manner as a well-formed attribute.
>
> Note that an "invalid attribute" does not cause the entire packet
> to be discarded, or to be treated as a negative acknowledgement.
> Instead, only the "invalid attribute" is discarded.'
> 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?
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?
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'?
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.
-------------------------------------
One more Editorial
7. Section 2.4
' 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | String ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
String
The String field is one or more octets. ...'
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.
Best Regards,
Leaf
-----Original Message-----
From: Alan DeKok [mailto:aland@deployingradius.com]
Sent: Friday, October 28, 2011 8:40 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:
> I am Not sure that the following words are necessary in section 9,
>
> ' However, allocation from the "Deprecated" space
> can still be performed by publication of an IETF specification, where
> that specification requests allocation from the "Deprecated" space,
> and gives reasons why use of the Extended Type space is impossible.'
>
> I can't see any reason why use of the Extended Type space is impossible, when the new allocation intends to use the code from 144 to 191 in the above "Deprecated" space.
Neither can I. But it gives people the ability to use the range
144..191 if they *really* need it.
> I regard the space of 144-191 sounds the equal-right space as the extended space defined in the draft. Am I right?
No. The above text says its "Deprecated". It SHOULD NOT be used.
It's deprecated because the extended format does more, and has more
attributes available. We wish to reserve the 144..191 space for future
extensions, or for specifications which can't use the extended space.
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.
> 2. Section 2.1 - Length
>
> ' 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. If it is not discarded, it MUST NOT be handled in the
> same manner as a well-formed attribute.
>
> Note that an "invalid attribute" does not cause the entire packet
> to be discarded, or to be treated as a negative acknowledgement.
> Instead, only the "invalid attribute" is discarded.'
>
> How about the compliant implementation will do? Will the Octets per the Length of the attribute, eg. 2 or 3, will be discarded?
I have no idea what that means.
> Then how to delimit the next attribute?
I don't know what that means, either.
> 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. '
>
> TLV date type sounds a sub-attribute here.
Yes... it's defined that way in the document.
> Why do we need discard the whole attribute if we adopt the same logic described above, in section 2.1?
We discard the TLV that is invalid. We don't discard the attribute
which encapsulates it.
> B. Editorials:
>
> 1. Section 2.2
>
> ' When the More
> flag is set (1), ...
> 255; it MUST NOT have a length Field of of value 4; ...'
>
> Supposed one 'of' should be here.
Fixed, thanks.
> 2. Section 2.3 (The same case happened in section 2.4.)
>
> ' We define a new data type in RADIUS, called "tlv". The "tlv" data
> type is an encapsulation layer which which permits the "Value" field
> of an Attribute to contain new sub-Attributes. '
>
> Supposed one 'which' should be here.
Fixed, thanks.
> 3. Section 2.3 - TLV-Type
>
> 'As with Extended-Type above, the TLV-Type is meaningful only
> within a context defined by "Type" fields of the encapsulating
> Attributes.'
>
> Supposed the above should be '...within a context defined by "Extended-Type" field of the encapsulating Attribute.'.
It says "Type field*s*".
> 4. Section 2.5
>
> 'The expected use
> og this data type is within Accounting-Request packets, but this data
> type SHOULD be used in any packet where 32-bit integers are expected
> to be insufficient.'
>
> Supposed the above 'og' should be 'of'.
Fixed, thanks.
> 5. Section 3.1 -String (The same case happened in Section 3.2, 3.3, 3.4, 3.5, 3.6)
>
> 'String
>
> The String field is one or more octets...'
>
> Supposed the above should be 'Value
> The Value field is one or more octets...'
Fixed, thanks.
> 6. Section 3.5 (The same case happened in Section 3.6)
>
> 'Length
>
> >= 4'
>
> Supposed the above should be ' Length >= 5'.
Fixed, thanks.
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/>