Subject: [NSIS] GIST updated from todays IESG call

From: Magnus Westerlund <[email-masked]>
Date: Thu, 09 Apr 2009 19:59:06 +0200

At today's IESG call we discussed the status of GIST and path forward.

It was clear that IESG is still dead locked on this document about its
intended status. We polled all the IESG members and it is clear that
publication as experimental status is acceptable for all, including the
ones that are currently abstaining. After discussion I was left with a
choice between invoking the alternative procedure (See bottom of
http://www.ietf.org/u/ietfchair/voting-procedures.txt) and publication
as the experimental. Please note that one of result of the alternative
procedure if that fails is a charter review. Based on these choices and
the information I have, I have chosen to go with downgrading GIST to
Experimental status. I think that is the least disruptive choice I can
make currently.

I request that the WG resolves the discusses and submits a new draft
version with an updated intended status. As usual discusses are for
discussion and I hope can be resolved reasonably quickly with the
discussing ADs.

I am personally sorry that it has taken until now to come to any
conclusion on the status question.

Best Regards

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Martin Stiemerling" <[email-masked]>
Date: Tue, 14 Apr 2009 14:37:20 +0200

[writing as co-chair]

Dear all,

GIST has now been under IESG review and discussion since mid/end of 2006. GIST was returned to the WG before the IETF#68 meeting in Prague (before March 2007). Three partially different IESGs have reviewed and discussed GIST. 

Since then GIST has been under discussion and several DISCUSSES have been resolved apart from the general doubt whether GIST as such is mature enough for standards track. This doubt seems to be still there, even with the new IESG members. 

GIST has gone a long road in the IESG and still is not considered suitable for standards track. Magnus described the two possible ways in this situation:
- downgrading GIST to experimental or 
- invoking the alternative procedure.

Downgrading is a hard step, especially after all the good work of the authors and the WG, the successful interops, the early expert review, and so on. BUT GIST as such will be still published as RFC. Calling for alternative procedure will eventually prolong the way of GIST to RFC status for an even longer time, with even more burden to the working group (considering a refusal of the IESG). As the WG will not only be in charge of finalizing GIST (and the other documents), but also be subject to a charter review.

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!

  Martin 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Magnus Westerlund
> Sent: Thursday, April 09, 2009 7:59 PM
> To: NSIS
> Cc: IESG
> Subject: [NSIS] GIST updated from todays IESG call
> 

[email-masked]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 14 Apr 2009 15:24:34 +0200

Dear Martin, Dear all

I am very sorry to hear that even with the new IESG members the doubt,
whether GIST as such is mature enough for standards track, 
seems to still be there.

>From what I understood from the email sent by Magnus, Magnus already chose
to go with 
downgrading GIST (and also all NSLPs) to Experimental status.

Taking into account all historical facts associated with the IESG review of
GIST, I think that the choice made 
by Magnus is an acceptable one for me.

Best regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Martin Stiemerling
> Sent: dinsdag 14 april 2009 14:37
> To: NSIS
> Subject: Re: [NSIS] GIST updated from todays IESG call
> 
> [writing as co-chair]
> 
> Dear all,
> 
> GIST has now been under IESG review and discussion since 
> mid/end of 2006. GIST was returned to the WG before the 
> IETF#68 meeting in Prague (before March 2007). Three 
> partially different IESGs have reviewed and discussed GIST. 
> 
> Since then GIST has been under discussion and several 
> DISCUSSES have been resolved apart from the general doubt 
> whether GIST as such is mature enough for standards track. 
> This doubt seems to be still there, even with the new IESG members. 
> 
> GIST has gone a long road in the IESG and still is not 
> considered suitable for standards track. Magnus described the 
> two possible ways in this situation:
> Downgrading is a hard step, especially after all the good 
> work of the authors and the WG, the successful interops, the 
> early expert review, and so on. BUT GIST as such will be 
> still published as RFC. Calling for alternative procedure 
> will eventually prolong the way of GIST to RFC status for an 
> even longer time, with even more burden to the working group 
> (considering a refusal of the IESG). As the WG will not only 
> be in charge of finalizing GIST (and the other documents), 
> but also be subject to a charter review.
> 
> 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).
> 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Magnus Westerlund
> > publication as experimental status is acceptable for all, including 
> > the ones that are currently abstaining. After discussion I was left 
> > with a choice between invoking the alternative procedure 
> (See bottom 
> > of
> > procedure if that fails is a charter review. Based on these choices 
> > and the information I have, I have chosen to go with 
> downgrading GIST 
> > to Experimental status. I think that is the least 
> disruptive choice I 
> > can make currently.
> > 
> NEC Laboratories Europe - Network Research Division NEC 
> Europe Limited | Registered Office: NEC House, 1 Victoria 
> Road, London W3 6BL | Registered in England 2832014 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nsis
>

---

From: Roland Bless <[email-masked]>
Date: Fri, 17 Apr 2009 00:05:46 +0200

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

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

---

From: Xiaoming Fu <[email-masked]>
Date: Mon, 20 Apr 2009 20:10:29 +0200

I second Roland's comments.
Xiaoming

---

From: Gerald Ash <[email-masked]>
Date: Mon, 20 Apr 2009 13:03:28 -0700 (PDT)

A couple of comments and requests:
 
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, 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.
 
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?
 
Request: Perhaps people with a long view could comment on the evolution of problems/needs over this 8 year period.
 
Thanks,
Jerry

--- On Tue, 4/14/09, Martin Stiemerling <[email-masked]> wrote:

From: Martin Stiemerling <[email-masked]>
Subject: Re: [NSIS] GIST updated from todays IESG call
To: "NSIS" <[email-masked]>
Date: Tuesday, April 14, 2009, 8:37 AM

[writing as co-chair]

Dear all,

GIST has now been under IESG review and discussion since mid/end of 2006. GIST
was returned to the WG before the IETF#68 meeting in Prague (before March 2007).
Three partially different IESGs have reviewed and discussed GIST. 

Since then GIST has been under discussion and several DISCUSSES have been
resolved apart from the general doubt whether GIST as such is mature enough for
standards track. This doubt seems to be still there, even with the new IESG
members. 

GIST has gone a long road in the IESG and still is not considered suitable for
standards track. Magnus described the two possible ways in this situation:
- downgrading GIST to experimental or 
- invoking the alternative procedure.

Downgrading is a hard step, especially after all the good work of the authors
and the WG, the successful interops, the early expert review, and so on. BUT
GIST as such will be still published as RFC. Calling for alternative procedure
will eventually prolong the way of GIST to RFC status for an even longer time,
with even more burden to the working group (considering a refusal of the IESG).
As the WG will not only be in charge of finalizing GIST (and the other
documents), but also be subject to a charter review.

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.

  Martin 

[email-masked]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3
6BL | Registered in England 2832014
_______________________________________________
nsis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nsis

---

From: Roland Bless <[email-masked]>
Date: Tue, 21 Apr 2009 11:35:30 +0200

Hi Jerry and all,

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
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?
> 
> Request: Perhaps people with a long view could comment on the evolution
> of problems/needs over this 8 year period.

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.

Regards,
 Roland

---

From: Roland Bless <[email-masked]>
Date: Tue, 21 Apr 2009 13:36:06 +0200

Hi again,

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

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

>> vanished thus nullifying the original motivation?

The above RFC is "only" 4 years old.

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

> of willingness to implement another signaling protocol into router

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 21 Apr 2009 14:22:54 +0200

> IESG) to detect GIST packets?  We are not privy to the discussion that

I wouldn't place to much focus on the discusses that are currently in
the tracker. They are not the reason for GIST being downgraded to
experimental. I am convinced that we can resolve them.

The reason GIST is being downgraded is that enough IESG members don't
like it being published as proposed standard. When one third or more of
the IESG members ballot abstain the process is to send the document back
to the WG. That happened and lots was done to the document and still
enough IESG members where uncertain. After further discussion and new
IESG members still not resulting an result that is clear to lead to
approval. This showing that the IESG was deadlocked on the document.
Which resulted in the choice I had to make. Downgrade status from
proposed to experimental, where most if not all are fine with publishing
GIST or have the alternative procedure being used. The alternative
procedure is an up or down vote on publication. If more than 2 persons
cast down it is a no. And the IESG has agreed that if that is the result
we should initiate a charter discussion process to see if the community
and IESG agrees with what should be produced by the WG. Thus the result
can be from anything between upholding the current charter, change it,
to kill the WG.

Based on the above choices I did chose Experimental as the least
disrupting and fast way forward.

> explain to the NSIS WG why this DISCUSS issue (and any others) could not

The IESG has had quite a lot of discussion around if one needs to
explain an abstain position or not. We are split on this question, but
currently there is no requirement on doing that. I am personally not
happy with this.

Regards

Magnus Westerlund

---

From: Ross Callon <[email-masked]>
Date: Tue, 21 Apr 2009 12:07:33 -0400

> > 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.
> 
> explain an abstain position or not. We are split on this question,
> but currently there is no requirement on doing that. I am personally
> not happy with this.

I would support a requirement that in the case where there are enough
abstain positions to prevent a document from going forward, then each AD
with an abstain position MUST write a comment explaining why they are
abstaining. 

Of course, in this case each of the abstain positions *does* already (at
least now) have a note explaining why. 

Ross