Note: This ballot was opened for revision 04 and is now closed.
Summary: Needs a YES.
Comment (2004-12-01) 
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
Comment (2004-08-21)
- 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.
Comment (2004-08-19)
Reviewed by Scott Brim, Gen-ART
Comment (2004-08-17)
Please delete the revision history that follows the Abstract before
publishing as an RFC.
In section 2.2.2: s/IPSEC/IPsec/
Comment (2004-08-17)
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?
Comment (2004-08-19)
> 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?
datatracker.ietf.org