draft-ietf-radext-radius-fragmentation-06: mop-up of small comments

[stefan.winter@…]

While reading the document, I found the followings nits/comments:

• 1. Introduction, the first "bullet" paragraph. The last sentence "... entirely ..." sounds strange. Did you want to express that the approach is not useful in this context because it "... only ..." solves server-to-NAS?

• second bullet: What is a SAML "Sentence"?

• 2. Scope: "slightly more than 4096" - the draft speaks of 100K (a 25-fold increase), which doesn't go well together with the word "slightly"

• a few paras down, nit: "its preferable to not introduce" -> "it's" or "it is"

• the section deals with CoA and co-location with a RADIUS server. It was impossible for me to follow the prose text - an ASCII-art flow picture is badly needed here!

• 3. Overview. "Service-Type indicating that the service being provided is /frgmentation/." The actual value for Service-Type is "Additional-Authorization". Even though the document makes a case for the equation "Fragmentation" = "Additional-Authorization" in its narrow scope, this is not necessarily evident to a reader. I suggest to re-word this with the actual name of the Service-Type that is defined later in the document.

• Nit: In the paragraph after that one, the last sentence starts with "A a ".

• 4.1 Pre-Authorization, just below Figure 6: nit: "It then process the" -> processes

• below figure 7: "Each chunk is a valid RADIUS packet" -> suggest to add "(see section 11.2)" to make a link with the slight violation of RFC2865.

• Section 6 has a technical error in that it misses the attribute "User-Name" in the overhead calculation. So, where the calculation ends with 3979 usable octets, another 255 need to be substracted: the User-Name attribute from packet 1 will be in every subsequent packet as well, and will occupy a total of 255 octets in the worst case.

• Section 7.1, second sentence: nit: "Should they cannot add" reads like bogus English; suggets "Should they be unable to"

[alex@…]

Thanks. We'll address them in the upcoming -07 version.

[aland@…]

the section deals with CoA and co-location with a RADIUS server. It was impossible for me to follow the prose text - an ASCII-art flow picture is badly needed here!

I've written some clarifying text and added some diagrams.

We should also note that using proxies with CoA is currently *impossible* in RADIUS. There is no specification for how to proxy CoA packets across multiple hops.

It would seem that this document depends on the document which fixes CoA proxying.

[stefan.winter@…]

Thanks for the clarifying text and ASCII-art on CoA. I think it really helps the document.

Most of the comments were fixed with -07; what remains is:

• 1. Introduction, the first "bullet" paragraph. The last sentence "... entirely ..." sounds strange. Did you want to express that the approach is not useful in this context because it "... only ..." solves server-to-NAS?

• second bullet: What is a SAML "Sentence"? I know SAML *messages* and *assertions* and *attributes*, but no sentences ...

• The sentence in 7.1 now reads: "Should they are unable to add this information to the packet, they may silently discard forwarding it to its destination, leading to DoS situations." This still sounds a bit strange. A simple s/are/be/ would fix this.

[alex@…]

1. No. What we wanted to express is what the RFC6158 says about the NAS-Filter-Rule attribute: that it is not allowed to be in an Access-Challenge packet. The text now says:

[...]this approach does entirely solve the problem of sending large amounts of data from a server to a NAS, as many current RADIUS attributes are not permitted in an Access-Challenge packets. [...]

2. English-Spanish "false friend". It has been modified to "SAML statement".

3. If reworded the sentence to:

[...] If they are unable to add this information to the packet [...]

[stefan.winter@…]

That sentence in #1 still reads strange to me, but I'm not a native speaker myself. I'm sure the RFC editor will fix any grammar if needed, so I'm closing this ticket.