Analysis of Existing Quality-of-Service Signaling Protocols
RFC 4094

Note: This ballot was opened for revision 05 and is now closed.

(Jon Peterson) Yes

(Harald Alvestrand) No Objection

Comment (2004-08-19 for -)
Reviewed by Scott Brim, Gen-ART

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

Comment (2004-08-17 for -)
In the Background section, the draft says:

   Istvan Cselenyi suggested
   to request for QoSSIG BOF in IETF#47 

This should probably be re-worded.

The sections in 2.1 (Subject:mumble) are hard to parse.  I'd suggest making them
subsections, or rewording them.

2.2.9 mentions ERP applications without expanding what ERP means; so does
RFC 2997, which it references, though, so it may be that some consider it a
well known term of art.

In 2.2.15, the draft says:

    If bidirectional
   reservation is needed, the RSVP signaling should be proceeded twice
   between the signaling source and the destination.

This probably needs rewording.

In 2.4 (and again in 3.5), the draft says:

   A good signaling protocol should be transparent or oblivious to the

This should probably be re-worded. 

In Section 3.5, the draft says:

 In the last several years, a number of new applications has been
   developed and they require the use of IP signaling. One example is
   midcom, which has been designed for firewall control.

What's the relevance of midcom to NSIS?

(Scott Hollenbeck) No Objection

(Russ Housley) No Objection

Comment (2004-08-17 for -)
  Please delete the revision history that follows the Abstract before
  publishing as an RFC.

  In section 2.2.2: s/IPSEC/IPsec/

(David Kessens) No Objection

(Allison Mankin) (was Discuss, Yes) No Objection

Comment (2004-12-01)
The other ADs' comments were well addressed by the editor -

I had a comment, which the author supported:

(Thomas Narten) No Objection

Comment (2004-08-19 for -)
>    Previously, there has been a lot of work targeted at creating a new
>    signaling protocol for resource control.  Istvan Cselenyi suggested
>    to request for QoSSIG BOF in IETF#47 (
>    serv-arch/msg05055.html), for identifying problems in QoS signaling,

how permanent is the URL reference? Same issue applies for other URLs.

s/IPSEC/IPsec/ throughout

>    the VC for forwarding RSVP control messages terminated. While a


>    - Point-to-mulitpoint path establishment


>    RSVP proxies [BEGD02] extends RSVP by being able to originates or


>    In the last several years, a number of new applications has been


p. Pan is listed as author (?) on first page, but not in authors
section. Is this right?

(Bert Wijnen) No Objection

Comment (2004-08-21 for -)
- Missing an IANA considerations section

- References to RFC 2751 and 2752 should probably be replaced with 
  refs to RFC 3181 3182. Those obsolete the earlier ones. They fix
  serious bugs in assignments.


- Have (G)MPLS folk checked sections 2.2.10 and 2.2.11?
- Has someone checked Sct 2.2.12?
  Is RFC3474 and/or RFC3476 not defining extensions for UNI ??
  And that includes new objects GENERALIZED_UNI and UNI_IPv4_SESSION
  for UNI. Not sure if the ibjects for ASON are relevant here.