Re: [NSIS] GIST updated from todays IESG call

[Roland Bless <bless at tm.uka.de>]

Hi again,

I was too fast when hitting the "send" button...
Some more small comments inline.

Roland Bless wrote:
> Gerald Ash wrote:
>> 1. IMO after 8 years of hard work on NSIS, the WG deserves more of an
>> explanation for downgrading GIST to experimental than “the IESG was
>> deadlocked”.  What is the *technical* explanation for why the IESG
>> DISCUSS’s could not be resolved?  After several years of IESG review,
> 
> IMHO it's not the DISCUSSes that cannot be resolved. It's just
> that the majority of IESG members have changed several times over the
> long period, the WG chair has changed and major proponents of the NSIS
> approach have left the IESG. Therefore, IESG people seem to have pulled

Please don't take this wrong: this is no criticism of any former/current
WG chairs.

> in different directions, esp. if you consider the RAO discussion.
> We couldn't get it right from the beginning since some people said:
> "Oh, please use RAO for interception" and others said "don't use it,
> it's broken". For some people, RAO is an already deployed (but poorly
> defined and badly implemented) means and more efficient than any other
> alternative, for others it's not usable in a general scope and will
> cause deployment problems. Any alternative, like the one specified
> now, seems to be disliked also, because it's not very efficient to
> process in the fast path. Gee, a *constructive* criticism or even
> *help* from the IESG would be really appreciated.
> 
>> the main DISCUSS issue still appears to be how to detect GIST packets:
>> RAO is unacceptable (although it did pass an earlier IESG review);
>> port/magick is a “non starter”.  There is no proposed resolution offered
>> in any of the DISCUSS comments.  Is there no acceptable way (to the
>> IESG) to detect GIST packets?  We are not privy to the discussion that
>> must have taken place.
> 
>> Request: Perhaps an IESG member could write a “majority opinion” to
>> explain to the NSIS WG why this DISCUSS issue (and any others) could not
>> be resolved.
> 
> I would go further: I think the IESG should really come up with a
> *constructive* proposal how to resolve the issue. As I said: the WG
> has done everything to get it right, but obviously the IESG has changed
> too quickly before we could get it right. :-)
> Furthermore, I want to mention that the path-coupled signaling MRM is
> only *one* method. GIST is flexible enough to use others.
> 
>> 2. A couple of IESG comments cast doubt on the need/motivation for
>> NSIS.  The NSIS BOF was held at IETF-50 (March 2001).  Several comments
>> made at the BOF (documented at
>> http://www.ietf.org/proceedings/01mar/index.html, search “nsis”)
>> identify the perceived need for improvement in signaling protocols.  Bob
>> Braden published an I-D proposing the 2-layer NSIS architecture at
>> http://www.watersprings.org/pub/id/draft-braden-2level-signal-arch-01.txt
>> (his CSTP became GIST).  An analysis of existing signaling protocols was
>> published in RFC 4094 http://www.ietf.org/rfc/rfc4094.txt.   Surely much
>> has changed over 8 years and problems may have been fixed and needs
>> vanished thus nullifying the original motivation?

The above RFC is "only" 4 years old.

>> Request: Perhaps people with a long view could comment on the evolution
>> of problems/needs over this 8 year period.

Unfortunately, I wasn't at the BOF. Allison Mankin ran the BOF but she
left the IETF and is now at the NSF.
Scott Bradner was Transport AD at the time, too. Probably he can comment?

> I still think that we need a flexible and new signaling solution and
> that RSVP is not really well suited for many signaling applications
> other than RSVP-TE.
> GIST supports mobility, provides Session-ID and Peer-IDs, various
> signaling routing methods, denial of service protection, flexible use of
> different transports, and security features. I guess it's more the lack
> of willingness to implement another signaling protocol into router
> software.

Moreover, RSVP allows for receiver-initiated reservations only, whereas
QoS NSLP allows sender-initiated and receiver-initiated reservations...
But I don't want to repeat the requirements/analysis docs here.
Finally, we have *running code* since several years now and we
were aiming for *proposed* standard, neither draft nor full
standard at this time. So I don't fully understand the fear of some
IESG members that going for PS would be dangerous to the Internet....

Regards,
 Roland