Re: [MBONED] Draft mtg minutes

Hitoshi Asaeda <asaeda@sfc.wide.ad.jp> Thu, 11 November 2010 02:23 UTC

Return-Path: <asaeda@sfc.wide.ad.jp>
X-Original-To: mboned@core3.amsl.com
Delivered-To: mboned@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A74F3A693A for <mboned@core3.amsl.com>; Wed, 10 Nov 2010 18:23:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.036
X-Spam-Level:
X-Spam-Status: No, score=-99.036 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4x7oEZClKj9 for <mboned@core3.amsl.com>; Wed, 10 Nov 2010 18:23:32 -0800 (PST)
Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id A682C3A6921 for <mboned@ietf.org>; Wed, 10 Nov 2010 18:23:17 -0800 (PST)
Received: from localhost (dhcp-451b.meeting.ietf.org [130.129.69.27]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id E17EE2780E9; Thu, 11 Nov 2010 11:23:42 +0900 (JST)
Date: Thu, 11 Nov 2010 10:23:37 +0800
Message-Id: <20101111.102337.244333477.asaeda@sfc.wide.ad.jp>
To: lenny@juniper.net
From: Hitoshi Asaeda <asaeda@sfc.wide.ad.jp>
In-Reply-To: <20101110114654.U68880@zircon.juniper.net>
References: <20101110114654.U68880@zircon.juniper.net>
X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: mboned@ietf.org
Subject: Re: [MBONED] Draft mtg minutes
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mboned>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Nov 2010 02:23:34 -0000

Thanks Lenny, but several comments seem to be lost.
I put them with [[]] symbol.
Regards,
--
Hitoshi Asaeda

...

Tuning IGMP and MLD
   Stig asked people to review both the multimob drafts
     on this topic and post comments to the multimob list.
   Stig said that spec allows unicast queries, but not
     sure if implemented. He asked if anyone has
     implemented this.
   Marshall asks if it is a problem reducing the robustness
     value. Marshall explains how it may be a problem
     with fast leave and low robustness variable.
   [[Hitoshi answered it could be possibly safe in the
     good-condition link with shorter general query interval.
     The draft mentions it.]]
   Toerless: unicast queries are dangerous, they may be
     sent remotely
   Stig: Yes, dangerous and I think [[IGMPv3/MLDv2]] spec say they
     must be accepted. Maybe spec should be updated.
   [[Hitoshi: Can be written in the appendix in my tuning draft.]]

...

Channel Reflector
   
Discussion about mboned-session-announcement-req

  Marshall says a new last call may be needed.
  Marshall trying to ask the room about support.
  Think one person in support
  Also Stig supported requirements but don't remember
    document.
  Lenny on Jabber says something about not enough support.

[**Note from chair- in April, SAP requirements draft went 
through WGLC.  Only 4 responses, 1 in favor and 3 opposed 
advancing the draft.  This was determined to be insufficient 
support for advanding the draft.]

  Other author (Vincent Roca) says some people are still using
    SAP and good to document [[SAP limitation because some
    applications, e.g. discussed in FECFRAME WG, assume to still
    use SAP. At least, the document clarifying the issues and its
    limitation must be published.]]
  Toerless, one thing he didn't see is that it is light
    weight, not requiring any infrastructure etc...
  Hitoshi says [[the goal and aim of this draft is not for new
    proposal or protocol. CR is one of the concrete implementation
    fulfilling the requirement.]]
  Toerless, asks whether requirements are needed
  Hitoshi, thinks should collect requirements because might
    want to develop new solutions, e.g. CR
  Marshall, there has to be more enthusiasm for it to be revived.
  Toerless, some may need service discovery in the network.
  [[Hitoshi says he hasn't expected to do draft on CR because the most
    important thing is to clarify the requirement. But if some needs,
    he would draft the solution such as CR.]]
  Stig, SAP can be useful in certain environments