Policy Quality of Service (QoS) Information Model
draft-ietf-policy-qos-info-model-05

Document now basically approved with following RFC-Editor Note. Checking with chairs/authors and a few ADs.

RFC-Editor Note:

Please replace th abstract with this new text:

Abstract

  This document presents an object-oriented information model for
  representing QoS network management policies. This document is
  based on the IETF Policy Core Information Model and its
  extensions. It defines an information model for QoS enforcement
  for differentiated and integrated services using policy.
  It is important to note that this document defines an information
  model, which by definition is independent of any particular data
  storage mechanism and access protocol.

[Ballot discuss]
The first paragraph of the Introduction indicates that the QPIM includes
a standard framework for controlling access to network QoS resources. Yet,
I do not find any discussion of authentication, authorization, or access
control. The discussion of admission control actions is not sufficient to
meet fulfill the expectation of the Introduction. At a minimum, acc

Revision 5 addresses my comments. Two nits left
that can be handled later.

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: dinsdag 20 mei 2003 15:03
To: Joel M. Halpern; policy@ietf.org
Subject: RE: [Policy] Revised Draft


Mmm.. on page 46 and following I see afew FALSEFALSE values.
Is that correct? If not, then you can keep that to be
fixed at a later point.

Same for [DIFF-MIB] Refernce, it should refernece RFC3289

For those who want to see the I-Ds with colored changes,
See
  http://psg.com/~bwijnen/qpim.html

Is the doc ready for me to send it into IETF Last Call?

Thanks,
Bert

My comments can also be ahndled after IETF Last Call.
Checking with Authors and WG chairs if they want to go that path or if they rather do a new rev now.

AD review comments:
-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: vrijdag 4 april 2003 14:15
To: Policy (E-mail)
Subject: 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

State Changes to AD Evaluation                                    from New Version Needed (WG/Author)                    by Bert Wijnen

State Changes to New Version Needed (WG/Author)                    from AD Evaluation                                    by Bert Wijnen

State Changes to AD Evaluation                                    from Requested                                        by Bert Wijnen