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

[Dave Thaler <[e-mail]>]

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:[e-mail]]
> Sent: Tuesday, December 11, 2007 10:36 PM
> To: [e-mail]
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mboned

_______________________________________________
MBONED mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/mboned