Re: [ssm] URGENT: draft-ietf-ssm-arch-06.txt

Brian Haberman <brian@innovationslab.net> Tue, 04 October 2005 13:24 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMmm9-0002k1-Ud; Tue, 04 Oct 2005 09:24:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMmm6-0002jX-4q for ssm@megatron.ietf.org; Tue, 04 Oct 2005 09:24:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17998 for <ssm@ietf.org>; Tue, 4 Oct 2005 09:24:04 -0400 (EDT)
Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMmuk-0000ZH-Uc for ssm@ietf.org; Tue, 04 Oct 2005 09:33:04 -0400
Received: from ([128.244.206.105]) by piper.jhuapl.edu with ESMTP id KP-BXZ33.17275517; Tue, 04 Oct 2005 09:23:21 -0400
In-Reply-To: <20051004091338.GF9249@cisco.com>
References: <20051004091338.GF9249@cisco.com>
Mime-Version: 1.0 (Apple Message framework v623)
Message-Id: <c0d73bcd68c567f92d6b7dba8fc4a658@innovationslab.net>
From: Brian Haberman <brian@innovationslab.net>
Subject: Re: [ssm] URGENT: draft-ietf-ssm-arch-06.txt
Date: Tue, 4 Oct 2005 09:23:20 -0400
To: Toerless Eckert <eckert@cisco.com>
X-Mailer: Apple Mail (2.623)
X-esp: ESP<4>=RBL:<0> RDNS:<0> SHA:<4> UHA:<0> SLS:<0> BAYES:<0> SenderID:<0> CAN-SPAM Compliance Dictionary (TRU7a):<0> NigeriaScam Dictionary (TRU7a):<0> Obscenities Dictionary (TRU7a):<0> Spam Dictionary (TRU7a):<0> APL-TRU-Words:<0> Porn Dictionary (TRU7a):<0> Embed HTML Dictionary (TRU7a):<0> APL-TRU-Substrings:<0> URL Dictionary (TRU7a):<0> HTML Dictionary (TRU7a):<0>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196
Cc: zinin@psg.com, jedi@cisco.com, David Meyer <dmm@cisco.com>, bcain@storigen.com, fenner@research.att.com, holbrook@cs.stanford.edu, ssm@ietf.org
X-BeenThere: ssm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Source-Specific Multicast <ssm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ssm@ietf.org>
List-Help: <mailto:ssm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1066156016=="
Sender: ssm-bounces@ietf.org
Errors-To: ssm-bounces@ietf.org

Hi Toerless,
      Well, the draft is in Revised ID Needed state after IESG review.
https://datatracker.ietf.org/public/pidtracker.cgi? 
command=print_ballot&ballot_id=1300&filename=draft-ietf-ssm-arch

To my knowledge, the editors/authors have either: run out of cycles
or motivation.  I would love to see this draft finished as well.  If  
needed,
I could try and help resolve the DISCUSS comments.

Regards,
Brian

On Oct 4, 2005, at 5:13, Toerless Eckert wrote:

> Can somebody please tell me what needs to be done to get an SSM
> architecture RFC out of that draft... like: This year ?
>
> We've got a whole bloody broadband industry like in DSL and Cabl
> where it's extremely difficult to propose and require SSM support  
> without
> having an actual IETF RFC for this still pretty badly understood model.
>
> In addition, there is at least one further IETF draft hanging on the
> normative reference.
>
> Is there any relationship between the amount of changes / improvement
> that went into this draft and it's lifetime ? Or is it rather that this
> draft is hanging around waiting for someone who is not spending the  
> time
> to move it forward ? If so, can we please identify that roadblock and
> get rid of it so that this draft can move forward with a little bit
> accelerated speed ?
>
> Short of this: Can we simply define timeouts of let's say 5 years after
> which drafts that have an interested user community become an RFC even
> if not all bureaucracy nitpicking has been resolved ? After all, the
> PIM-SM RFC2362 also had 120 known bugs when we started out redoing it
> something like 5 years ago, but it's pure existance has helped to
> ensure that THE INDUSTRY HAS CONTINUED TO DO ANY FORM OF PIM DURING THE
> LAST 5 YEARS... *sigh* sorry for getting so loud. Just wanted to  
> highlight
> that the situation in SSM is worse than in PIM - with similar waiting
> times - because in SSM there is no prior RFC whatsoever that could be
> used instad of the real thing, and i really don't see the value of
> indefinite postponement anymore.
>
> Thanks
>     Toerless Eckert
>
> _______________________________________________
> ssm mailing list
> ssm@ietf.org
> https://www1.ietf.org/mailman/listinfo/ssm
_______________________________________________
ssm mailing list
ssm@ietf.org
https://www1.ietf.org/mailman/listinfo/ssm