datatracker.ietf.org
Sign in
Version 5.6.2.p6, 2014-09-03
Report a bug

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

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

Summary: Needs a YES.

[Allison Mankin]

Comment (2004-12-01 for -05)

The other ADs' comments were well addressed by the editor -
http://www.ietf.org/mail-archive/web/nsis/current/msg04544.html

I had a comment, which the author supported:
http://www.ietf.org/mail-archive/web/nsis/current/msg04548.html

[Bert Wijnen]

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.

Questions:

- 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.

[Harald Alvestrand]

Comment (2004-08-19 for -)

Reviewed by Scott Brim, Gen-ART

[Russ Housley]

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/

[Ted Hardie]

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
   applications.

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?

[Thomas Narten]

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 (http://www-nrg.ee.lbl.gov/diff-
>    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

s/terminated/terminates/

>    - Point-to-mulitpoint path establishment

spelling

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

s/originates/originate/

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

s/has/have/

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