Re: [pim] Last Call: <draft-ietf-pim-rfc4601bis-03.txt> (Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)) to Internet Standard

Alia Atlas <akatlas@gmail.com> Wed, 11 March 2015 14:24 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6A81ACDEE for <pim@ietfa.amsl.com>; Wed, 11 Mar 2015 07:24:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.399
X-Spam-Level:
X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oA-DXNvVHhf for <pim@ietfa.amsl.com>; Wed, 11 Mar 2015 07:24:21 -0700 (PDT)
Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 845451ACDC2 for <pim@ietf.org>; Wed, 11 Mar 2015 07:24:21 -0700 (PDT)
Received: by oigh136 with SMTP id h136so8091122oig.1 for <pim@ietf.org>; Wed, 11 Mar 2015 07:24:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3cXb5nCy3DyB7gLUDYz+Yp2WV5Wt6EAcV5EJyJvzjAA=; b=Emp3YjhNBK9BBzAcZWz9drO8wXVcM0Gst1eaHXeLLMV8jhs8eV2M/1vMWC69MvNrHC 3NXWE3YQo40jYnbfCsweatQ0PZ4vpdG/Yae/PCU18qa+Lsg4zGYEdps2yOcNdRmDjAKs JqCTJNpZIl3h6/K/RnfyJeHh9XovoHtNHq0lTgH3372yJd/a1xYy7Fc1cj6jccnTeICz ufV5u2XlsEVahACNwXyWtPzfuC2MHK/N0LGfdZShpRlPp2ub4pAZMXKYzOVz0h+xACom UE1VNMjrDLn92UDW/ddv3JoaG0wdH//Q7TPox9BJ2TaFGVRZmvhaAp4N7/aHpoeETeEO j7kw==
MIME-Version: 1.0
X-Received: by 10.202.65.8 with SMTP id o8mr28751183oia.113.1426083861020; Wed, 11 Mar 2015 07:24:21 -0700 (PDT)
Received: by 10.60.139.164 with HTTP; Wed, 11 Mar 2015 07:24:20 -0700 (PDT)
In-Reply-To: <20150311134617.GB874@cisco.com>
References: <20150213174210.6909.43630.idtracker@ietfa.amsl.com> <54F0BFB1.4090707@concordia.ca> <CAG4d1reOc4Wzkyqmg3YF_VXhUfWumVuSr3gTU8zAog9NC12sNg@mail.gmail.com> <20150311134617.GB874@cisco.com>
Date: Wed, 11 Mar 2015 10:24:20 -0400
Message-ID: <CAG4d1rfKE6xSHsJyw9xNf38f0Q+sz5J=pE-Fse-Toj7p9rgq2g@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: Toerless Eckert <eckert@cisco.com>
Content-Type: multipart/alternative; boundary="001a113ddb5ef51e110511040508"
Archived-At: <http://mailarchive.ietf.org/arch/msg/pim/DIRzWZ36L58hkoDVtuNFG3vOeSs>
Cc: "pim@ietf.org" <pim@ietf.org>
Subject: Re: [pim] Last Call: <draft-ietf-pim-rfc4601bis-03.txt> (Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)) to Internet Standard
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Mar 2015 14:24:24 -0000

Toerless,

On Wed, Mar 11, 2015 at 9:46 AM, Toerless Eckert <eckert@cisco.com> wrote:

> Alia:
>
> How would an implementer of PIM based on 4601 figure out from 4601bis,
> what if any changes she would need to do on her implementation ?
>

It is not very hard to compare 4601 and 4601bis with the rfcdiff tool to
see the
differences.


> I may be missing something, but by not having an errata/changes section/
> summary, existing implementers will ahve a lot more trouble adopting
> this update than they should IMHO. Is that normal IETF process in bis
> documents ?
>

So - I have three responses.  First, this type of feedback would be quite
useful during WGLC.  It isn't, I think, a reason to impact the draft at this
stage,even if the draft comes back to the WG to handle issues around the
updates and section 6.3.  Second, looking with rfcdiff shows some changes
from "should to SHOULD or must to MUST"; I don't really see a way of
summarizing it cleanly.  Third, the major changes to a bis version are
summarized;
I haven't seen a lot of bis drafts progressed yet but the short summary
that
is there about the removed functionality seems useful.

Regards,
Alia

The "removed functionality" is the least interesting bit of changes,
> so that does not count.
>
> Toerless
>
> On Fri, Feb 27, 2015 at 02:10:25PM -0500, Alia Atlas wrote:
> > Bill,
> >
> > Thanks for the good review and catches!
> > I'd like to see the draft updated before March 5 so that it can still
> > make the telechat on March 12.
> >
> > Regards,
> > Alia
> >
> > On Fri, Feb 27, 2015 at 2:04 PM, William Atwood <
> william.atwood@concordia.ca
> > > wrote:
> >
> > > In the following, I will refer to draft-ietf-pim-4601bis as simply
> > > "4601bis".
> > >
> > > RFC 4601 has been updated by several RFCs:
> > >
> > > RFC 5059 Bootstrap Router (BSR) Mechanism for Protocol
> > >          Independent Multicast (PIM)
> > > RFC 5796 Authentication and Confidentiality in Protocol
> > >          Independent Multicast Sparse Mode (PIM-SM)
> > >          Link-Local Messages
> > > RFC 6226 PIM Group-to-Rendezvous-Point Mapping
> > >
> > > 4601bis refers to RFC 5059 in Section 3.7.  The new text is identical
> to
> > > the text in RFC 4601, although the reference in RFC 4601 is to the
> > > Internet Draft that became RFC 5059.
> > >
> > > 4601bis makes no reference to RFC 5796.  Given that RFC 5796 alters the
> > > preferred IPsec solution (AH is "recommended" in RFC 4601, while RFC
> > > 5796 says that implementations "MUST support ESP and MAY support AH"),
> > > and given that RFC 5796 provides considerable detail on the use of
> IPsec
> > > to protect link-local messages for PIM-SM, RFC 5796 should be
> > > specifically referenced in Section 6.3 of 4601bis.
> > >
> > > 4601bis makes no reference to RFC 6226.  Given that RFC 6226 alters the
> > > algorithm for determining the Rendezvous Point, RFC 6226 should be
> > > specifically mentioned in Section 3.7 of 4601bis.  The authors should
> > > also consider whether to eliminate Section 4.7.1 and replace it with a
> > > pointer to RFC 6226, to reduce it and add a pointer to RFC 6226, or to
> > > leave it unchanged.
> > >
> > > Suggested text for some of these changes has been supplied to the
> > > authors of 4601bis.
> > >
> > >   Bill Atwood
> > >
> > >
> > > On 13/02/2015 12:42 PM, The IESG wrote:
> > > >
> > > > The IESG has received a request from the Protocol Independent
> Multicast
> > > > WG (pim) to consider the following document:
> > > > - 'Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
> > > >    Specification (Revised)'
> > > >   <draft-ietf-pim-rfc4601bis-03.txt> as Internet Standard
> > > >
> > > > The IESG plans to make a decision in the next few weeks, and solicits
> > > > final comments on this action. Please send substantive comments to
> the
> > > > ietf@ietf.org mailing lists by 2015-02-27. Exceptionally, comments
> may
> > > be
> > > > sent to iesg@ietf.org instead. In either case, please retain the
> > > > beginning of the Subject line to allow automated sorting.
> > > >
> > > > Abstract
> > > >
> > > >
> > > >    This document specifies Protocol Independent Multicast - Sparse
> Mode
> > > >    (PIM-SM).  PIM-SM is a multicast routing protocol that can use the
> > > >    underlying unicast routing information base or a separate
> multicast-
> > > >    capable routing information base.  It builds unidirectional shared
> > > >    trees rooted at a Rendezvous Point (RP) per group, and optionally
> > > >    creates shortest-path trees per source.
> > > >
> > > >    This document addresses errata filed against RFC 4601, and removes
> > > >    the optional (*,*,RP) feature that lacks sufficient deployment
> > > >    experience.
> > > >
> > > >
> > > >
> > > >
> > > > The file can be obtained via
> > > > http://datatracker.ietf.org/doc/draft-ietf-pim-rfc4601bis/
> > > >
> > > > IESG discussion can be tracked via
> > > > http://datatracker.ietf.org/doc/draft-ietf-pim-rfc4601bis/ballot/
> > > >
> > > >
> > > > No IPR declarations have been submitted directly on this I-D.
> > > >
> > > >
> > >
> > > --
> > > Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
> > > Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
> > > Department of Computer Science
> > >    and Software Engineering
> > > Concordia University EV 3.185     email:william.atwood@concordia.ca
> > > 1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
> > > Montreal, Quebec Canada H3G 1M8
> > >
> > > _______________________________________________
> > > pim mailing list
> > > pim@ietf.org
> > > https://www.ietf.org/mailman/listinfo/pim
> > >
>
> > _______________________________________________
> > pim mailing list
> > pim@ietf.org
> > https://www.ietf.org/mailman/listinfo/pim
>
>
> --
> ---
> Toerless Eckert, eckert@cisco.com
>