AD review of: draft-ietf-rap-rsvp-authsession-02.txt

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Before putting documents on the IESG agenda I review them first.
I have issued IETF Last Call for the document
    draft-ietf-rap-rsvp-authsession-02.txt
I would normally issue Last Call only after I have done the 
review and received responsess from authors. But it seems
that 3GPP wants this doc to become RFC soon (June 7th).
So therefor we do this in paralell

So you can consider my comments as IETF Last Call comments

Here are my comments and questions:

1. The RFC-Editor does not want references in the abstract section
   see draft-rfc-editor-rfc2223bis-02.txt for details
   You can replace [POL-EXT] with (RFC 2750) as a good alternative.

2. Sect. 2, talks about "DiffEdge". May want to explain that term.
   I see that you reference an RFC, yet a few words on that term
   may be good.

3. The way you specify the Policy element in sect 3.2 is
   different from what I have seen before. For example, RFC3181
   does it as follows:

      P-Type: 16 bits
         PREEMPTION_PRI  = 1

         This value is registered with IANA, see Section 7.

   I would strongly suggest to use the same/similar format.
   In fact, RFC3182 does that too
   For the actual value you can either put in a free number
   or you can do something like "TBD-by-IANA"

4. I would then also recommend a similar approach for each of the
   attribute types and their SubTypes. Actually RFC3182 is a very
   good example for that. The idea is that when we have the finalized
   RFC, people can find in the spec itself the numbers that have been
   assigned to each S-Type and SubType within an S-Type.
   And then in teh IANA Considerations section, they can find them
   all nicely listed together.

5. So I would also strongly recommend that in the IANA Considerations
   you make clear all the assigned (or TBD-by-IANA) values.
   I again think that RFC 3182 is a very good example.

6. Of course, you start a new registry, so the IANA COnsiderations
   section also needs to have a write-up as to how values within
   the new name space get assigned. In other words, I think your
   IANA COnsiderations section can be much much clearer than it
   currently is.

7. Section 3.3 (and others as well)
   Talks about "padding bytes". You may want to specify that they
   "MUST have a value of zero". Whatever you choose, it is important
   to be specific, otherwise running a digest (or creating a signature)
   for these objects is gonna be problematic.

8. Section 3.3.2 (and other places, but this one in particular)
   You talk about "plain ASCII" and "plain UNICODE". You may want
   to add a reference or be more specific as to what you mean.
   For example, is plain ASCII to mean 7-bit US ASCII?
   In other places (like in 3.3.1) you reference an RFC. Maybe
   in that RFC (which I have not yet checked) it becomes clear
   what exactly an "ASCII string" means.
   Sect 3.3.3 does need extra reference on this too.

9. The places where you talk about IPv4 and IPv6 addresses, you
   should specify how they are formatted. Are they 32 and 128
   bit values (respectively) in an OCTET STRING, or are they 
   formated as dotted decimal (IPv4) or separated by colons 
   (IPv6) ???

10. In section 5, I see you talk about "IndetityType", 
    "identity type" and "PE type". Probably this is all the
    same thing... but it is quite confusing. Why not use the
    terminology as defined in RFC 2750 whicj calls it P-Type
    But whichever you choose, I prefer a consistent term, and
    not 3 different onse in one section that supposedly mean
    the same thing. Or am I mistaken here.

11. Last sentence section 6. 
    Should "will include" be replaced by "MUST include" ??

12. I suspect that the Security Considerations section may
    cause trouble with the Security ADs. I would advise to
    be more explicit in pointing out possible risks and
    also strongly recommening (MUST language probably) that
    implementation MUST support the secure mechanisms.
    Maybe it is wise to check with one or both Security ADs.
    Let me know if you want me to help with that.

13. Pls split references section in normative and non-normative
    references as per draft-rfc-editor-rfc2223bis-02.txt

14. I am missing an IPR section as required per RFC2026.

Bert