Analysis of Existing Quality-of-Service Signaling Protocols
draft-ietf-nsis-signalling-analysis-05

Revision of document to address small, but valid comments of the reviewers...Jukka's email to the
comments, and a small exchange about one point where I proposed text, are in the nsis list archive.

Previous history of the draft:
- AD early review for more analysis, less advocacy (it had considerable
  editorializing for a TCP-based RSVP replacement)
- Cross-area early review by RSVP-TE folks wrt how RSVP branched to serve MPLS

[Ballot comment]
- 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.

[Ballot comment]
>    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?

[Ballot comment]
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?