[radext] Last call comments on draft-ietf-radext-fragmentation-02

["Jim Schaad" <[e-mail]>]

In general, yes I believe this document is in good shape and ready to go
forward.  There are a couple of small things that need to 


1.  !!! Pet Peeve !!! - I would request that the authors please review the
use of 2119 language.  There are places where, IMHO, it is used incorrectly.
Examples are:
	(section 1) Nevertheless, if a proxy supports this specification, it
MAY re-assemble the data in order to either examine and/or modify it.  ---
This is not  protocol statement it is a statement of why one might wish to
do something.  If the proxy does not implement the spec, it does not have
this capability.
	(section 2) Instead, the CoA client MUST send a CoA-Request packet
containing session identification attributes, along with Service-Type =
Additional-Authorization, and a State attribute.	 ---- I don't think
this is part of the fragmentation protocol
	(section 3) An authorization exchange before authentication allows a
RADIUS client to provide the RADIUS server with information that MAY modify
how the authentication process will be performed (e.g. it MAY affect the
selection of the EAP method).  --- This decision process is independent of
the fragmentation protocol and thus is not appropriate 2119 language.

2.  !!! Pet Peeve !!! - I have run into people who believe that the
capitalization of may, should, must do not matter when defining 2119
language.  Personally I think they are idiots for this view, but they
strongly believe it.  For this reason I have started including the sentence
"When these words appear in lower case, they have their natural language
meaning." As part of the 2119 boiler plate.  You might want to consider
doing so.

3.  On page 9 (after figure 2) - It is not clear to me what you mean by
Non-compliant servers.  Are these servers that do not implement this
specification or are they servers that do not correctly implement the RADIUS
specification.  (Simple way to make it clear would be to add a parenthetical
after the first occurrence of the term   "non-compliant (i.e., servers not
implementing fragmentation)"

4. Same paragraph - suggest s/a particular Service-Type/a Service-Type other
than Additional-Authorization/  (I am not sure that is a correct statement
in terms of the actual value returned, but particular does not give me
something to code to)

5. Next paragraph - does it really need to be globally unique?  Is it
sufficient to be unique to either the server or the server/NAS pair?  The
problem with the phrase "globally and temporally unique" is that says to me
that it can never be re-used ever in the history of the world by anybody and
I don't think that is what is implied here.

6. Section 4.2 - Para #1 - The requirements on the Service-Type attribute,
while understandable, appear to violate a previous statement that the order
of the attributes not be changed (Section 3 para 3  The encoding process is
a simple linear walk over the attributes to be encoded.  This walk preserves
the order of the attributes, as required by [RFC2865].)  This should
probably be explicitly called out as being ok.  (This may be done by a proxy
rather than the server.)  - Maybe point to the discussion in section 7.2 as
well, although there it says that the attributes can be re-ordered.

After a second pass through the document (with jumps to other documents), I
still find this somewhat confusing language here.  Something that might make
things a bit clearer
	In section 3 para 3 - s/order of the attributes/order of attributes
of the same type/

7. Section 7.1 - I may have a slight misunderstanding here (and it may not
be worth changing the document for this in any case).  However, I believe
that a proxy can remove all previous proxy-state information and just insert
its own into a packet.  Thus it is possible that the server does not know
how many bytes to allow for proxy state as not all of the attributes will be
sent to the server.  (I just found that this is discussed in step #2 of this
section, which makes me less inclined to include in the general discussion
but still unsure.)

8.  Section 7.4 - Service-Type = Additional-Authorization should be included
in the server list.

9. section 10 - !! Pet Peeve !! - A MAC is not a signature and should not be
called one.

10.  References
	(Which of the documents do I need to understand to implement - as
oppose to understand background reasoning)
	RFC 2866 should be informational
	RFC 3579 should be informational
	RFC 5080 should be informational
	(Yes I could list others here such as how to write IANA
considerations which the author needs to know but not the reader).

11.  Did I miss where you defined the T bit - or did you?

12.  This may just be me, but I have a problem with the terms
"pre-authorization" and "post-authorization".   My issue with the terms is
that there are three cases where I see things happening:

	a) Before doing the authentication (NAS->server)
	b) Post doing the authentication (NAS->Server)
	c) "post" doing the authentication (Server->NAS as part of the
access-accept process).

	However the document currently says that c is post-authorization but
b is not covered in section 12.

13.  Should the Access-Request (ID=181) be Frag-Status = More-Data-Pending ?

14.  In the last paragraph on page 15, you are putting in a state attribute
where one did not exist in the original request.  It is not clear to me why
this is happening just because this is the fragmentation protocol.  It would
seem to me that this is something that should be done in general for all
access-accept messages, whether or not it is going to be fragmented.

15.  Section 5 - I don't know if there is a reason to discuss packing based
on the re-ordering of attributes which have disparate types in order to pack
the chunk tighter.

16. Section 8.1 - It might be worthwhile to repeat that implementations
SHOULD send this attribute in the an Access-Request with the value of
Fragmentation-Supported if fragmentation is not going to happen.


Spelling errors

s/wand/and/
s/eight (7)/seven (7)/
s/how many space/how much space/
s/MUST not/MUST NOT/
s/before start forwarding/before starting to forward/
s/could be a reasonable limits/could be a reasonable limit/  or  /could be
reasonable limits/