Re: [Roll] Consensus Call -- resolution for #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local

On Fri, Nov 1, 2013 at 4:44 PM, Michael Richardson <mcr+ietf@sandelman.ca>wrote:

>
> I would like to ask the WG to speak now if you object to this
> solution, specifically with the the text going into mcast-05.
>
> Ralph wrote:
> >  This text could be added to draft-ietf-roll-trickle-mcast-05, or to
> >  draft-ietf-6man-multicast-scopes-00 or published separately in yet
> >  another "world's shortest RFC".
> >
> >  Second, draft-ietf-roll-trickle-mcast-05 should be changed to read:
> >
> >     When used with MPL, Realm-local scope is defined according to the
> >     underlying network technology; for example, [cite the
> >     IP-over-IEEE802.15.4 definition].
> >
> >  As a further refinement, I suggest text be added to
> >  draft-ietf-roll-trickle-mcast-05 to the effect of:
> >
> >     "scop 4" can also be used with MPL to cover deployments that use
> >     administratively defined scopes that cover, for example, subnets
> >     based on different underlying network technologies.
> >
> >  - Ralph
>
> Here's a summary the situation:
- draft-ietf-roll-trickle-mcast ("MPL draft") defines a multicast transport
  protocol.  It refers to scop 3 which has up to now been reserved.
- draft-ietf-6man-multicast-scopes ("Scopes draft") defines scop 3 and
  states it must be automatically determined by data link connectivitiy.
  It recommends the proper place to define how the scope zone boundary
  is determined is in the "IP-over-Foo" draft for each data link that
defines
  scop 3.
- The MPL draft *must* reference the Scopes draft in order to utilize
  scop 3.  It must also agree with the Scopes draft on the issue of whether
  the scop 3 boundary is automatically determined.  This is included in
  issue #132 and REMAINS OPEN.
- Another open question is where to locate the definition of scop 3 for
  802.15.4 networks?

Going by the recommendation in the Scopes draft, one solution for the
latter is to issue a short update to RFC 4944.  However, this is not the
most expedient solution from the standpoint of finishing the MPL draft.

The next best solution in my opinion is to place the 802.15.4 definition of
scop 3 into the Scopes draft.  Future data links that define scop 3 in their
IP-over-Foo RFCs will then only need to reference the Scopes document
for the precedent and not the MPL document as well.  Since the MPL draft
must already reference the Scopes draft anyway, this also solves one
open issue for MPL.

I personally think it's a bad idea to bury the definition of an
automatically
determined scope boundary for a particular data link within a transport
protocol specification.

Regards, -K-

--
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>