Re: [MBONED] WGLC for <draft-ietf-mboned-ipv4-uni-based-mcast-04.txt>

Tim Chown <tjc@ecs.soton.ac.uk> Mon, 25 February 2008 09:59 UTC

Return-Path: <mboned-bounces@ietf.org>
X-Original-To: ietfarch-mboned-archive@core3.amsl.com
Delivered-To: ietfarch-mboned-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 297223A6926; Mon, 25 Feb 2008 01:59:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level:
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
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 4-lmzOf9oYMr; Mon, 25 Feb 2008 01:59:25 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FF8C3A6968; Mon, 25 Feb 2008 01:59:25 -0800 (PST)
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 47B4E3A6926 for <mboned@core3.amsl.com>; Mon, 25 Feb 2008 01:59:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 FSwQyR6gEjOV for <mboned@core3.amsl.com>; Mon, 25 Feb 2008 01:59:23 -0800 (PST)
Received: from owl.ecs.soton.ac.uk (owl.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe77:96e]) by core3.amsl.com (Postfix) with ESMTP id 75A4D3A6968 for <mboned@ietf.org>; Mon, 25 Feb 2008 01:59:22 -0800 (PST)
X-ECS-MailScanner-Watermark: 1204538349.66344@4Oec3AcuaR0GNri14BlfQQ
Received: from goose.ecs.soton.ac.uk (goose.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe78:67b5]) by owl.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id m1P9x9h2016119 for <mboned@ietf.org>; Mon, 25 Feb 2008 09:59:09 GMT
X-ECS-MailScanner-Watermark: 1204537994.5254@4JnpKCCp8dFnvXcIZ1RhGg
Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe59:5f12]) by goose.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id m1P9rDxZ016210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <mboned@ietf.org>; Mon, 25 Feb 2008 09:53:13 GMT
Received: from login.ecs.soton.ac.uk (localhost.localdomain [127.0.0.1]) by login.ecs.soton.ac.uk (8.13.8/8.11.6) with ESMTP id m1P9x0ux024249 for <mboned@ietf.org>; Mon, 25 Feb 2008 09:59:00 GMT
Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.13.8/8.13.8/Submit) id m1P9x0Wu024248 for mboned@ietf.org; Mon, 25 Feb 2008 09:59:00 GMT
Date: Mon, 25 Feb 2008 09:59:00 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: "mboned@ietf.org" <mboned@ietf.org>
Message-ID: <20080225095859.GA23825@login.ecs.soton.ac.uk>
References: <475F8154.1010902@lab.ntt.co.jp> <920B8B05FB49A04699188E04302FE87D59307FE36D@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <920B8B05FB49A04699188E04302FE87D59307FE36D@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com>
User-Agent: Mutt/1.4.2.2i
X-ECS-MailScanner: Found to be clean, Found to be clean
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Subject: Re: [MBONED] WGLC for <draft-ietf-mboned-ipv4-uni-based-mcast-04.txt>
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: <http://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/mboned>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mboned-bounces@ietf.org
Errors-To: mboned-bounces@ietf.org

Hi,

I think Dave's proposed changes are good, and will enhance the draft
overall.

Tim

On Sat, Feb 23, 2008 at 12:15:07PM -0800, Dave Thaler wrote:
> There were 9 issues raised (besides a bunch of discussion on the question Hiroshi asked about whether folks supported it or not), either on the list or in email to the author, about the draft.  They are listed at
> http://www.armidalesoftware.com/v4ubm.htm
> along with the discussion on each.  I counted 9 folks arguing for the proposal in the draft (subject to the issues below), 1 person (Toerless) arguing against it, and 3 who responded on the thread but didn't seem to express an opinion.  By my reading, this indicates strong consensus for the current proposal, subject to agreement on the issue resolutions below.
> 
> I am working on the updates to this draft this weekend, but just wanted to give a list of what I currently plan to do on each issue.
> 
> #1 (Toerless Eckert) Consider hard coding of address issue
> I agree this needs to be addressed.  Propose adding text saying that addresses in the UBM space MUST NOT be hard-coded in applications.
> 
> Proposed resolution: Add such a statement.
> 
> #2 (Stig Venaas) Make space permanent
> My own opinion is that we must address the hard-coded address issue above in the document and then I think Toerless's reason to not consider permanent is mitigated.  Then I would argue that it should be permanent.  So tallying the arguments so far (some people I count twice based on their response):
> Permanent: Stig, Marshall, Pekka, DaveT
> 3-5 years: Pekka, Toerless, Tim
> Less: Toerless
> There appears to be rough consensus for permanent, since Pekka also argued for permanent, Toerless's main argument against is mitigated in issue 1, and Tim didn't explicitly argue against permanent he just argued for 3-5 rather than 1 year.
> 
> Proposed resolution: Make permanent after resolving issue 1.
> 
> #3 (Toerless Eckert) Make UBM addresses be non-global
> I strongly agree with Pekka that there is room for a separate draft/allocation on this topic, and disagree with Toerless that it is appropriate to change this proposal.  Since 90% of the people who responded indicated they were in favor of the draft (implying as it is currently targetted), I believe there is rough consensus on this.
> I would have no problem with a separate draft on non-global space, BTW.
> 
> Proposed resolution: No change
> 
> #4 (Prashant Jhingran) Add examples
> I agree, will add an example or two.
> 
> Proposed resolution: Add an example or two similar to RFC 3306 & RFC 3956.
> 
> #5 (Peter Koch) LIRs and "Owners" of address space
> Agree "owners" is a bad term.  The term should be changed to make it clear that no action by LIRs is needed.
> 
> Proposed resolution: Accept, and change "owners" to a better term that reflects end-organizations/networks.
> 
> #6 (Peter Koch) DNS reverse mapping
> I agree with Pekka that the decision is not up to the RIRs (and hence the document does not need to explicitly state that), it is up to the end-site that chooses the multicast address.  This should be clearer once issue 5 is fixed.  Note that the issue is not really different from RFC 3306 which also does not address this issue.
> 
> Proposed resolution: No change beyond the fix for issue 5.
> 
> #7 (Peter Koch) Use of IPv4 addresses other than global unicast addresses
> It is worth considering RFC 3306 as the precedent.  It states that the embedded prefix must be unicast, and "The scope of the unicast-prefix based multicast address MUST NOT exceed the scope of the unicast prefix embedded in the multicast address."  Since the IPv4 UBM space is defining global multicast addresses, this would imply that RFC 1918 addresses also must not be used.  (They could be used in a future admin-scoped UBM space as proposed in issue 3).  I believe this restriction should be added.
> 
> Proposed resolution: Add text with restrictions above, to match the restrictions in RFC 3306.
> 
> #8 (John Linn): Use a shorter prefix length
> The choice of /8 makes it much easier to diagnose (left shift by 8 bits can trivially be done visually), and only one person argued for this during WGLC, I believe there is not sufficient consensus for this change.  I believe this was discussed a while back as well, when the consensus was to stick with /8.
> 
> Proposed resolution: No change
> 
> #9 (John Linn): Could be noted that this layout is sympathetic to the Ethernet MAC multicast encoding
> The "could" was phrased as a mere suggestion.  I do not think this is important to point out, nor is it obvious what one might say.  "Sympathetic" is a bit vague, and the bits don't map exactly since there's 23 in the MAC encoding and a variable number (24 or less) for the group ID in UBM.  It is true that that's why the Group ID portion is at the bottom, but Ethernet isn't the only media this matters for.
> 
> Proposed resolution: No change
> 
> While I understand there are those who may disagree with one or more of the proposed resolution, my reading of the list is that the proposed resolutions most closely reflect rough consensus.
> 
> -Dave
> 
> > -----Original Message-----
> > From: Hiroshi Ohta [mailto:ohta.hiroshi@lab.ntt.co.jp]
> > Sent: Tuesday, December 11, 2007 10:36 PM
> > To: mboned@ietf.org
> > Subject: [MBONED] WGLC for <draft-ietf-mboned-ipv4-uni-based-mcast-04.txt>
> >
> > Working group,
> >
> > As we agreed in the mboned session during IETF-70 in Vancouver, we start
> > the WGLC for comments on <draft-ietf-mboned-ipv4-uni-based-mcast-04.txt>
> > with this note.  The draft can be found on
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-mboned-ipv4-uni-based-
> > mcast-04.txt
> >
> > Please review the document carefully, and send your feedback to the
> > list.  Please also indicate whether or not you believe that this
> > document is ready to go to the IESG.
> >
> > This Last Call will end on January 11, 2008 at 1400 EST (UTC/GMT-4).  We
> > set the WGLC period longer than usual considering we have holiday season
> > during this WGLC period.
> >
> > Thank you.
> > Hiroshi and Marshall
> >
> >
> >
> >
> > _______________________________________________
> > MBONED mailing list
> > MBONED@ietf.org
> > https://www1.ietf.org/mailman/listinfo/mboned
> 
> _______________________________________________
> MBONED mailing list
> MBONED@ietf.org
> http://www.ietf.org/mailman/listinfo/mboned

-- 
Tim


_______________________________________________
MBONED mailing list
MBONED@ietf.org
http://www.ietf.org/mailman/listinfo/mboned