I'm happy to make changes regarding your comments; a couple of them were not directly actionable but I can make best guesses. Most of them were directly actionable and I agree the changes improve the text. I'd appreciate comments from the groups on whether we start codes at 2 or 1. My default will be 1 unless a couple of other people come forward and ask for 2.
I do disagree with a couple of comments however; see below. >>>>> "Alan" == Alan DeKok <[email protected]> writes: Alan> Continuing from the previous message... It says: Alan> A related question is should we allocate a code for Alan> Diameter? :) Exactly when someone plans to use it and works through the details. I would object to that allocation now. Alan> 5.3.3. Radius Namespace Alan> I suggest leaving out all re-definition of RADIUS AVPs. Alan> Instead, refer to RFC 2865 Section 5. Say that the Alan> NS-Specific data is RADIUS attributes, in the RADIUS attribute Alan> format. But the RADIUS packet header (code, length, Alan> authenticator) is not included. I'd prefer to keep the definition in. Alan> It also says: Alan> RADIUS AVPs are encoded with a one-octet attribute type Alan> followed by a one-octet length followed by the value of the Alan> RADIUS attribute being encoded. The length includes the type Alan> and length octets; the minimum legal length is 2 for an Alan> attribute with no value. Alan> This last bit is not true. RFC 2865 forbids attributes with Alan> "Length" of two. Instead, the entire attribute is suppressed, Alan> and never placed into a packet. Alan> The same should apply here. Unfortunately, as discussed in the text, we need to be able to send empty attributes in channel binding response. I understand RADIUS has no meaning for empty attributes, but I think we have a justified meaning for expressing that. I think the text is correct as is. Alan> It says: Alan> Some RADIUS container specifications forbid sending Alan> attributes with no value. Alan> No, the base RADIUS protocol forbids sending attributes with Alan> no value. It is not clear what they mean, or how it is better Alan> to send them than to send nothing at all. Alan> This prohibition not withstanding, these attributes SHOULD Alan> be sent with no value in channel binding responses. Alan> I am not clear why the document makes that suggestion. If Alan> it's a SHOULD, there should be explanation as to why it's a Alan> good idea. It's a SHOULD because we may specify cases where you include value or where you don't fully understand the container format. The definition of channel binding responses indicates that by default you SHOULD send the attribute without a value and explains why. (You don't want to echo back all that data.) _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
