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

"roll issue tracker" <trac+roll@trac.tools.ietf.org> Tue, 05 November 2013 12:44 UTC

Return-Path: <trac+roll@trac.tools.ietf.org>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD3611E8277 for <roll@ietfa.amsl.com>; Tue, 5 Nov 2013 04:44:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.561
X-Spam-Level:
X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxMts+PfefU7 for <roll@ietfa.amsl.com>; Tue, 5 Nov 2013 04:44:13 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A294311E828C for <roll@ietf.org>; Tue, 5 Nov 2013 04:44:07 -0800 (PST)
Received: from localhost ([127.0.0.1]:45897 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac+roll@trac.tools.ietf.org>) id 1VdfzH-0008GP-6I; Tue, 05 Nov 2013 13:44:03 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: roll issue tracker <trac+roll@trac.tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca
X-Trac-Project: roll
Date: Tue, 05 Nov 2013 12:44:03 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/roll/trac/ticket/132#comment:14
Message-ID: <082.c49a7b1ff9fc985c22e71855f2f9890a@trac.tools.ietf.org>
References: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org>
X-Trac-Ticket-ID: 132
In-Reply-To: <067.7473226c34e99536104b136c326ce300@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: johui@cisco.com, mariainesrobles@gmail.com, rdroms@cisco.com, mcr@sandelman.ca, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Nov 2013 12:44:15 -0000

#132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local


Comment (by mariainesrobles@gmail.com):

 '''CONSENSUS CALL''' -- resolution for #132: draft-ietf-roll-trickle-
 mcast-04 - Clarify scope value of 3 - subnet-local

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08303.html

 From: Michael Richardson <mcr+ietf at sandelman.ca>
 Date: Fri, 01 Nov 2013 16:44:42 -0400

 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.

 Please EMAIL/POST/COMMUNICATE before 2013-11-08 (next Friday).

 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

 --
 Michael Richardson <mcr+IETF at sandelman.ca>, Sandelman Software Works








 <kerryLynn>    Source: http://www.ietf.org/mail-
 archive/web/roll/current/msg08304.html



     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- </kerryLynn>





 <yoshihiroOhba>     Source: http://www.ietf.org/mail-
 archive/web/roll/current/msg08306.html


     I prefer describing 802.15.4-specific realm-local scope boundary
 definition in another RFC so              that both trickle-mcast and
 multicast-scopes drafts are fully independent of any link-layer.

    Regards, Yoshihiro Ohba </yoshihioOhba>





 <michaelRichardson>    Source: http://www.ietf.org/mail-
 archive/web/roll/current/msg08308.html



    Are you willing to write this document? </michaelRichardson>





 <yoshihiroOhba>    Source: http://www.ietf.org/mail-
 archive/web/roll/current/msg08311.html


    If we choose to write another RFC, yes I can contribute to it.

    Regards, Yoshihiro Ohba </yoshihiroOhba>






 <kerryLynn>     Source: http://www.ietf.org/mail-
 archive/web/roll/current/msg08309.html



     Let's scope the effort this week.  Ralph predicts it will be the
 World's
     shortest RFC; maybe we can get it right the first time.

    -K- </kerryLynn>





 <ralphDroms>     Source: http://www.ietf.org/mail-
 archive/web/roll/current/msg08310.html



    In my opinion, the roll WG gets to answer the question "should realm-
 specific scope for 802.15.4    be defined in draft-ietf-roll-trickle-
 mcast?"

    If the consensus is no (which would be my answer), then, in my opinion,
 it's up to 6nan to decide    between putting the definition in the
 multicast scopes doc or a separate RFC.

     Ralph </ralphDroms>





 <robertCragie>     Source: http://www.ietf.org/mail-
 archive/web/roll/current/msg08323.html


         +1 - my answer would also be no. I guess that should be 6man as
 well. </robertCragie>





 <danielPopa>    Source: http://www.ietf.org/mail-
 archive/web/roll/current/msg08312.html


    Hello all,

    I support the idea of having the definition of multicast scope boundary
 in another RFC so that   trickle-mcast and multicast-scopes drafts specify
 such IP features independent of the link-layer.

    And I am willing to  contribute and help writing such RFC.

    I will unfortunately not be able to attend this IETF meeting, but I
 will be available via email.

    Regards,
    Daniel </danielPopa>

-- 
---------------------------------------+------------------------------
 Reporter:  mariainesrobles@gmail.com  |       Owner:  johui@cisco.com
     Type:  defect                     |      Status:  reopened
 Priority:  major                      |   Milestone:
Component:  trickle-mcast              |     Version:
 Severity:  In WG Last Call            |  Resolution:
 Keywords:                             |
---------------------------------------+------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/roll/trac/ticket/132#comment:14>
roll <http://tools.ietf.org/wg/roll/>