Re: GIST updated from todays IESG call

I second Roland's comments.
Xiaoming
Roland Bless wrote:
> Hi Martin and all,
> 
> see below...
> 
> Martin Stiemerling wrote:
> 
>> However, in the full spirit of progressing NSIS to RFC status and not
>> to abolish all the excellent work of the past, the decision to go for
>> experimental looks natural in the light of the dead lock.
>>
>> Remember, that GIST is only the first document out of the whole
>> series that is still to come (e.g., QoS NSLP, NATFW NSLP, QSPEC,
>> etc).
>>
>> Please note, that downgrading to experimental, also likely applies to
>> the NSLPs.
>>
>> Please let the WG know your opinion about that!
> 
> I'm really disappointed. IMHO the WG has done all necessary
> steps to make it a really good protocol. If we didn't care about
> protocol quality, we could have finished GIST long time ago.
> It's not the WGs fault that using Router-Alert turned into a
> potential/real show stopper later on, though it is still used for RSVP.
> We asked all the experts at the time, and, it was the recommended
> practice to efficiently intercept signaling packets.
> Therefore, it really is totally weird if one reads Adrian Farrel's
> DISCUSS POINT 3 on whether the currently RAO-less option is
> efficient and fast enough (esp. if you recall that he actually
> already reviewed the document some years ago).
> The IESG seems now to pull into the RAO direction again(?), if
> reading Cullen Jenning's comment.
> I also cannot understand Ross Callon's comment why we need
> GIST at all in addition to RSVP and RSVP-TE, though our WG
> published various RFCs on this topic already at the very beginning.
> 
> Ron Bonica's comments are also depressing. I don't agree with
> his comment on complexity at all, because we have several
> interoperable implementations, which were not too hard to
> code. Furthermore, if you take page count as a measure for
> complexity, OSPFv3 would never have been standardized...
> As an L3 control protocol for IP resources, it naturally has
> to deal with a lot of things, so I don't think that there
> are easier solutions for the same feature set.
> 
> However, if going for experimental gets us out of this
> whole mess quickly, let's do it. Please no more delays.
> It would be good having an official RFC number anyway for vendors
> in order to implement it. Probably, then they see the benefits
> more clearly...
> 
> Regards,
>  Roland
>