AD review for: draft-ietf-policy-qos-info-model-04.txt

Finally... and (too) long overdue.
I feel ashamed :-(

Oh well... here we go.

I believe they are just nits, and I am willing to consider
them as input to the IETF Last Call, so that all editorial
changes can be made after the Last Call.
Authors and WG chairs, let me know if you want to do it
that way or if your rather do another rev rigth away.

- The abstract should not contain any citations, see
  See: http://www.rfc-editor.org/policy.html
- References must be split in normative and informative
  See: http://www.rfc-editor.org/policy.html
- In general, you may want to check and make sure that 
  you expand an acronym the first time it is used in the
  document.
  See: http://www.rfc-editor.org/policy.html
- Last sentence of 1st para of sect 1.2.4
  s/amethodology/methodology/
- 2nd para in sect 1.2.5
  s/the QPIM standard/the QPIM specification/
  I don't think the text should assume it is a standard.
  Standard attribute/level gets assigned separately.
- Page 42 I see:
     PROPERTIES   Antecedent[ref QoSPolicyAdmissionAction [0..n]]
                  Dependent[ref QoSPolicyTrfcProf [1..1]]
  And then a bit later I see a few times QoSPolicyTrfcProfile
  Should that be QoSPolicyTrfcProf ??
- I see:
    ABSTRACT          FALSE
  But I also see:
    ABSTRACT          False
  And same for the case of TRUE/True (I believe).
  Would it not be better to be consistent.
  In the original RFC3060 we were consistent using Upper Case
  In the PCIMe (RFC3460) we unfortunatly also are not consistent.
  What a pitty
- I see also inconsistent use of Upper/Mixed case in sect 8.5.1:
   NAME      qpRSVPWarnOnly
   SYNTAX    Boolean
   Default   False
   VALUE     The value TRUE means that the request should be admitted AND
             an RSVP warning message should be sent to the originator. The
             value of FALSE means that the request should be not admitted
             and an appropriate error message should be sent back to the
             originator of the request.
- I see reference to [RSVP-PREEMPT], but it is not listed in the
  references section
- I see a reference to [COPS] but I do not see it in the references section
- I see page 39:
     12.  QoSPolicyRSVPMessageTypeVariable - The RSVP message type, either
          Path, Resv, PathErr or ResvErr [RSVP].
  And on page 63
                ALLOWED VALUE TYPES: Integer (An enumerated value of
                                    {PATH=1 , PATHTEAR=2, RESV=3,
                                     RESVTEAR=4, ResvErr=5, CONF=6,
                                     PATHERR}
  And similar stuff on other pages.
  Would it not be good to be consistent in using Upper/Mixed case?
- I am missing an IPR statement as per rfc2026 sect 10.
  You do have it in RFC3460 and RFC3060.
- While you are at it, you may want to update some more references
  in the reference section. Several docs have become RFC by now
  (my fault, I know).
- You may also want to check for references that have been obsoleted
  by newer RFCs. For example RFC2751/2 have been obsoleted by RFC3181/2.

Thanks,
Bert 
p.s. I will try to do the draft-ietf-policy-qos-device-info-model-08.txt
early next week.