Re: WGLC for BFD Multipoint documents (last round)

"Reshad Rahman (rrahman)" <rrahman@cisco.com> Thu, 01 February 2018 00:51 UTC

Return-Path: <rrahman@cisco.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B818F12FA7D for <rtg-bfd@ietfa.amsl.com>; Wed, 31 Jan 2018 16:51:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level:
X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 RIAwnm5O_czM for <rtg-bfd@ietfa.amsl.com>; Wed, 31 Jan 2018 16:51:04 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B12FE12EC98 for <rtg-bfd@ietf.org>; Wed, 31 Jan 2018 16:51:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26016; q=dns/txt; s=iport; t=1517446263; x=1518655863; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=lZOOHa7je2jaWbQe0swUdIowW90xcvVPelk0GKK0NQ0=; b=L8Vej1R1qm2t/L6DkPfpdyWA6uy3F8Og8QXtXIFW9Yt986fOOlK6UmNN n8pgt4lbUaMNx6eROOHp3M7qCIf4HzU2JqLTZ3YJqFJxk43bhuaxZHjun Qa3zdXR14fq6F8RVyR/7o1xxPRfe8JlvJhIUCqO4xrONqC5L0Kx4l1Bv8 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DpAABFZHJa/5ldJa1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDEQQtZnUoCoMUQookji2BWyeJEo40FYICCiWFFgIagjVUGAE?= =?us-ascii?q?BAQEBAQEBAmsohSMBAQEDAQwXEToEBxACAQYCEQMBAgECAiYCAgIfERUICAIED?= =?us-ascii?q?gWKHQMNCBCKbp1xgieHPA2DJgEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQ+DTII?= =?us-ascii?q?VgVeBaCkMgWuBDoJrRAEBAgEBgUMSLyECgl0xghQgBaNgPgKIFoQAhE6FBoIdh?= =?us-ascii?q?iKEF4YBgVaLBoJhR4kOAhEZAYE7AR85gVBwFRkkKgGBbwEPglUcgQoBAnl4AQG?= =?us-ascii?q?LD4EXAQEB?=
X-IronPort-AV: E=Sophos;i="5.46,442,1511827200"; d="scan'208";a="64027448"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Feb 2018 00:51:02 +0000
Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w110p1HG002223 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Feb 2018 00:51:01 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 31 Jan 2018 18:51:01 -0600
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1320.000; Wed, 31 Jan 2018 18:51:01 -0600
From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
To: Greg Mirsky <gregimirsky@gmail.com>
CC: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, Jeffrey Haas <jhaas@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: WGLC for BFD Multipoint documents (last round)
Thread-Topic: WGLC for BFD Multipoint documents (last round)
Thread-Index: AQHTdDbMQKkp4UZhy0e3Kn8Lrj3T1qNFVBAAgABtnICAASUEgIADdUKAgADmoICAAGfFAIABPX0AgCk9u4CAAASiAIAAK1EAgAAqqgCAACNngIAABGqAgACB1oCAAEjuAIAAB2UAgAAsZQCAAA7FAIAAO8sAgAALOICAAA9fAIAMOY6AgAnDWICAAWECgA==
Date: Thu, 1 Feb 2018 00:51:01 +0000
Message-ID: <C2EC8F30-6444-4A6A-8510-4309F95FCA14@cisco.com>
References: <20171213172443.GC8708@pfrc.org> <CA+RyBmX6PHczvwEzc4UNqBioK8qv=wTfyeHg9j04EJNe1Uv0wA@mail.gmail.com> <746F74E2-7DFC-41A7-879F-4054CF95475C@cisco.com> <CA+RyBmWqGPTkBek+a0N+BaFr9QZ+xEKvWT5oRxPBuhFsQcizcw@mail.gmail.com> <38B53F72-66B9-4E8F-8BCE-C28A2C283D38@cisco.com> <20171219160537.GH8708@pfrc.org> <CA+RyBmWQTH9N9cCOHJ_9BgvfDGLGFgrsKrMj8mmqGm-V=5KLSw@mail.gmail.com> <20171220171322.GE8708@pfrc.org> <7C073038-8E7D-4735-82A4-97592AA9B34B@cisco.com> <CA+RyBmXanVpKKmyXP9+yuh4z2H4qAeN4jH2xEMx7ddiSHViV3g@mail.gmail.com> <DB3B0F10-4BD8-4096-8875-2E476064E77A@cisco.com> <491F0297-F2AB-4377-A013-1050FDBBB709@cisco.com> <CA+RyBmVXO0o09k-DYY69E2sKdKiU5YBf-h=PnBgerx+HF=ryfg@mail.gmail.com> <44B4B608-7A2B-4E95-A5F7-116896C57028@cisco.com> <0714A770-BF3F-4EF8-A302-A478439A5B13@cisco.com> <5F69E3D1-19E1-45F7-926D-61449E1F09B2@cisco.com> <CA+RyBmWMwom+2=jWHfvSr9AG=WPCnhYJ6uC9HVonVFh9McaysQ@mail.gmail.com> <E14FF8C0-082B-4D52-89F6-0CBAF9CD4181@cisco.com> <CA+RyBmUOpBgVho0SPsp9FB=ymFV29q_2EY2k8uOf-O4gfpTmyw@mail.gmail.com> <CA+RyBmXs_gRjeUk9gx0653WkvjDfztD-cgNw=mNX+66Whj_AFw@mail.gmail.com> <639B40D7-F79B-4546-93B3-55812C880217@cisco.com> <CA+RyBmUEG2L4ExWRCvLYVMs=BL5OsGRpfD0a9RLEvu+4Avhy9A@mail.gmail.com> <E816D829-7F6D-478A-9DE6-F5C5A177B981@cisco.com> <CA+RyBmXMPvwXZsD5KX6GAb3hVf2QFFFQGk3ahh79WwOL+jyPNQ@mail.gmail.com>
In-Reply-To: <CA+RyBmXMPvwXZsD5KX6GAb3hVf2QFFFQGk3ahh79WwOL+jyPNQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.27.0.171010
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.247.191]
Content-Type: text/plain; charset="utf-8"
Content-ID: <4D774A5564A3954C8F9B98EDE89F25FF@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/AusJlbWMSZXqMsjDoXQntxAulP0>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Feb 2018 00:51:08 -0000

Hi Greg,

Please see inline <RR>.

Regards,
Reshad.


On 2018-01-30, 10:47 PM, "Greg Mirsky" <gregimirsky@gmail.com>; wrote:

    Hi Reshad,
    thank you for your detailed review of
    draft-ietf-bfd-multipoint-active-tail and comments. I have copied
    parts of the review an i-lined my answers and notes tagged GIM>>.
    I've attached the diff to highlight the update and the new working
    version of the draft. Greatly appreciate your help.
    
    Regards,
    Greg
    
    :(16) Will publication of this document change the status of any
    : existing RFCs? Are those RFCs listed on the title page header, listed
    : in the abstract, and discussed in the introduction? If the RFCs are not
    : listed in the Abstract and Introduction, explain why, and point to the
    : part of the document where the relationship of this document to the
    : other RFCs is discussed. If this information is not in the document,
    : explain why the WG considers it unnecessary.
    This document will update RFCs 5880 and 7880. They are not in the
    title page header.
    GIM>>  This draft is Informational while RFCs 5880 and 7880 are
    Standard track. Would an Informational track document be updating
    Standard? Please confirm.
<RR> This draft was experimental at a certain point but got changed to Standards Track because AFAIR of a normative reference from the TRILL P2MP BFD.
    
    - General. There are a few instances where singular is used instead of
    plural (e.g. for session, tail) and also where “a” or “the” is
    missing. I have tried to indicate all such occurrences below.
    - General. A few sentences have the period ‘.’ before the closing
    parenthesis instead of after, e.g. in Introduction “path as is
    feasible.)”. I have not called out all of them, search for “.)”
    GIM>> I think I've hunted down them all down.
    
    - 1 Introduction. s/which allows tail/which allows tails/
    - 1 Introduction. Clarifications/explanations are desirable on “it is
    preferable if unicast paths share as little fate with the multipoint
    path as is feasible.)”
    GIM>> Please consider the following text update:
    OLD TEXT
    and in fact it is preferable if unicast paths share as little fate
    with the multipoint path as is feasible
    NEW TEXT
    and in fact it is preferable if unicast paths share as little fate
    with the multipoint path as is feasible, so to increase probability of
    delivering the notification from the tail to the head)
<RR> Ack.
    
    - 1 Introduction. s/Goal of this application/The goal of this application/
    GIM>> Done
    - 1 Introduction mentions “…state implosion towards the head”. Not
    sure implosion is the right term there, if it is the right term then
    clarification is needed.
    GIM>> Agree. I think that 'state explosion' is what we're concerned
    with.Would s/implosion/explosion/ be acceptable?
<RR> Ack.
    
    - 2 Overview. Change “Head may wish” to “A head may wish” or “Heads may wish”
    GIM>> Used the former.
    - 2 Overview. “…the head can direct the tails to transmit…”: add
    reference or explanation on how the head does that. Also
    s/direct/request/?
    GIM>> Controlling Multipoint BFD Options section provides the details.
    Will add reference ', as described in Section 3.4' Would that address
    this comment?
<RR> Yes.
    
    - 2 Overview. 1st paragraph, I know it’s obvious when you read the
    draft but might be good to have 1 sentence to explain why this is
    unreliable.
    GIM>> Section 5.2 gives good explanation of what is being considered
    unreliable. I' agree that using different shades of reliable
    notification to the head is not the best terminology but I don't have
    better to offer. Would reference to section 5.2 be acceptable? Do we
    want to characterize the level of guaranteed notification to the head
    otherwise than 'notification reliability'?
<RR> Reference to 5.2 is good enough.

    - 2 Overview. 3rd paragraph: s/as a unicast to the tail/as a unicast
    to that tail/?
    GIM>> Done
    - 2 Overview. 3rd paragraph: “or the single reply thereto is lost”,
    rephrase that sentence e.g. to “or the single reply os also lost”?
    GIM>> "..  or the single reply also lost ..."
<RR> Ack.

    - 2 Overview. “If some tails are more equal than others…”. I know what
    you mean but plus change the wording.
    GIM>> Proposed update:
    OLD TEXT
    If some tails are more equal than others, ...
    NEW TEXT
    If the awareness of the state of some nodes is more important for the head, ...
<RR> Ack.
    
    - 3 Protocol Details. s/This section is update/This section is an update/
    - 3.2 Multipoint Client Session Failure. s/know the tail state/know
    the tail’s state/
    GIM>> Done and done.
    
    - 3.3 State Variables. As discussed, bfd.SessionType should be in “new
    variable values” section and the others in “new variables” section.
    - 3.3.1 New State Variables. The paragraph on bfd.ReportTailDown says
    “If 0, the tail..”. Mention that the packets sent from the tail are in
    response to the head’s periodic BFD control packets? Also when set to
    1, how do the tails know from the head that they need to notify the
    head? This paragraph needs some clarification.
    3.3.2 State Variable Initialization and Maintenance. s/section 6.8.1
    of the [RFC5880] needs/section 6.8.1 of [RFC5880] need/
    - 3.4 Controlling Multipoint BFD Options. 2nd paragraph: add reference
    to section 5.1?
    GIM>> Agree
    - 3.4. 3rd paragraph : add reference to section 5.3? Also do we need a
    state variable which controls this behaviour (discovering tails)?
    GIM>> In the reverse order.
    Then the variable be per tail? What if number of tails is unknown to
    the head? I'd rather not define that in the base specification.
<RR> No, the variable would be on the head for all tails. 

    Reference added.
    - 3.4. Paragraph 5 should be after paragraph 3?
    GIM>> I agree, makes the narrative more logical.
    - 3.4. Paragraph 6, regarding “initial delay”, add a reference to
    3.13.3 which describes the delay.
    - 3.5 State Machine. s/State machine for/The state machine for/
    GIM>> Done and done
    - 3.8 Soliciting the Tails. “random delay”, add a reference to 3.13.3
    which describes the delay.
    - 3.13. “in the base specification” refers to base BFD or base BFD
    multipoint? Add a reference.
    GIM>> In fact it is both. Added references accordingly.
    - 3.13.1. Should reception at head also be covered here? If not, add
    “at tail” to the title
    GIM>> You're right, the changes update processing at MultipointTail
    but the base specification does not differentiate processing of the
    received BFD control packet based on the bfd.SessionType. I propose to
    have the text without update.
    - 3.13.1. s/by head below procedure MUST be/by the head, the procedure
    below MUST be/
    GIM>> Agree. I think more changes can benefit the text:
    OLD TEXT
    In addition to that if tail tracking is desired by head below
    procedure MUST be applied.
    NEW TEXT
    In addition to that, if tail tracking is desired by head, below
    procedure MUST be applied.
    Would you agree?
<RR> Ack.
    
    - 3.13.1 and 3.13.2. Both are adding to the procedures in
    draft-ietf-bfd-multipoint, specify where the addition is taking place
    (e.g. at the end).
    GIM>>
    - 7 Security Considerations. Should we add at the beginning “The same
    security considerations as those described in [RFC5880] and
    [I-D.ietf-bfd-multipoint] apply to this document.”?
    GIM>> Agree.
    
    On Wed, Jan 24, 2018 at 2:42 PM, Reshad Rahman (rrahman)
    <rrahman@cisco.com>; wrote:
    > Hi,
    >
    >
    >
    > I forgot to mention that last week I did the shepherd write-up for both
    > drafts.
    >
    >
    >
    > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/shepherdwriteup/
    >
    > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint-active-tail/shepherdwriteup/
    >
    >
    >
    > Regards,
    >
    > Reshad.
    >
    >
    >
    > From: Greg Mirsky <gregimirsky@gmail.com>;
    > Date: Tuesday, January 16, 2018 at 11:01 PM
    >
    >
    > To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>;
    > Cc: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>;, Jeffrey Haas
    > <jhaas@pfrc.org>;, "rtg-bfd@ietf.org"; <rtg-bfd@ietf.org>;
    > Subject: Re: WGLC for BFD Multipoint documents (last round)
    >
    >
    >
    > Hi Reshad,
    >
    > sorry for my sloppiness. Fixed.
    >
    >
    >
    > Regards, Greg
    >
    >
    >
    > On Jan 16, 2018 7:05 PM, "Reshad Rahman (rrahman)" <rrahman@cisco.com>;
    > wrote:
    >
    > Hi Greg,
    >
    >
    >
    > In 4.4.1 of MP, “A number values of the state variable are added to the…”,
    > looks like there is a missing “of”?
    >
    >
    >
    > For the active-tail draft I haven’t completed my review of -06 yet: there
    > are parts which aren’t clear to me and I don’t know yet if this is because
    > there’s something missing in the document or whether it’s just lack of
    > understanding on my part.
    >
    >
    >
    > Regards,
    >
    > Reshad.
    >
    >
    >
    > From: Greg Mirsky <gregimirsky@gmail.com>;
    > Date: Tuesday, January 16, 2018 at 9:25 PM
    > To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>;
    > Cc: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>;, Jeffrey Haas
    > <jhaas@pfrc.org>;, "rtg-bfd@ietf.org"; <rtg-bfd@ietf.org>;
    > Subject: Re: WGLC for BFD Multipoint documents (last round)
    >
    >
    >
    > Hi Reshad, et. al,
    >
    > the attached are diff to highlight updates to BFD in Multipoint Network and
    > the working copy of Active Tails. After checking through the Active Tails
    > draft, I've found no additional changes to make resulting from removing all
    > references to bfd.SilentTail from BFD in Multipoint Networks draft. Your
    > review and comments are most welcome.
    >
    >
    >
    > Regards,
    >
    > Greg
    >
    >
    >
    > On Tue, Jan 16, 2018 at 2:51 PM, Greg Mirsky <gregimirsky@gmail.com>; wrote:
    >
    > Hi Reshad,
    >
    > thank you. I'll add it into the working version to others updates. I believe
    > changes to active tails be more extensive as now it must introduce the
    > bfd.SilentTail variable, not just its new state. Will work on that now.
    >
    >
    >
    > Regards,
    >
    > Greg
    >
    >
    >
    > On Tue, Jan 16, 2018 at 1:58 PM, Reshad Rahman (rrahman) <rrahman@cisco.com>;
    > wrote:
    >
    > Hi Greg,
    >
    >
    >
    > I am fine with the change below.
    >
    >
    >
    > Regards,
    >
    > Reshad.
    >
    >
    >
    > From: Greg Mirsky <gregimirsky@gmail.com>;
    > Date: Tuesday, January 16, 2018 at 2:20 PM
    > To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>;
    > Cc: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>;, Jeffrey Haas
    > <jhaas@pfrc.org>;, "rtg-bfd@ietf.org"; <rtg-bfd@ietf.org>;
    >
    >
    > Subject: Re: WGLC for BFD Multipoint documents (last round)
    >
    >
    >
    > Hi Reshad,
    >
    > I think this is very good idea. Then in section 4.13.3 Transmitting BFD
    > Packets of BFD for Multipoint Networks should be edited. Perhaps the
    > following be acceptable:
    >
    > OLD TEXT
    >
    >    A system MUST NOT transmit any BFD Control packets if bfd.SilentTail
    >
    >    is 1.
    >
    > NEW TEXT
    >
    >    A system MUST NOT transmit any BFD Control packets if bfd.SessionType is
    >
    >    MultipointTail.
    >
    > Will look into related changes in active tails if others agree with the
    > proposal in general.
    >
    >
    >
    > Regards,
    >
    > Greg
    >
    >
    >
    >
    >
    > On Tue, Jan 16, 2018 at 10:53 AM, Reshad Rahman (rrahman)
    > <rrahman@cisco.com>; wrote:
    >
    > Regarding bfd.SilentTail, I am wondering if instead it should be removed
    > from MP draft  (always 1 in there) and kept as new state variable in
    > active-tail?
    >
    >
    >
    > Regards,
    >
    > Reshad.
    >
    >
    >
    > From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>;
    > Date: Tuesday, January 16, 2018 at 9:32 AM
    > To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>;, Greg Mirsky
    > <gregimirsky@gmail.com>;
    > Cc: Jeffrey Haas <jhaas@pfrc.org>;, "rtg-bfd@ietf.org"; <rtg-bfd@ietf.org>;
    >
    >
    > Subject: Re: WGLC for BFD Multipoint documents (last round)
    >
    >
    >
    > Hi Greg,
    >
    >
    >
    > The changes for bfd.SessionType (in both drafts) look good.
    >
    >
    >
    > bfd.SilentTail is fine in multipoint but in active-tail it is in the New
    > State Variables section.  It should be in 3.3.2 instead and there should be
    > a reference to the multipoint draft.
    >
    >
    >
    > Also, I am in the process of doing the shepherd write-up. So you don’t have
    > to push these changes immediately, you can wait for the review, up to you.
    >
    >
    >
    > Regards,
    >
    > Reshad.
    >
    >
    >
    > From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>;
    > Date: Tuesday, January 16, 2018 at 1:47 AM
    > To: Greg Mirsky <gregimirsky@gmail.com>;
    > Cc: "Reshad Rahman (rrahman)" <rrahman@cisco.com>;, Jeffrey Haas
    > <jhaas@pfrc.org>;, "rtg-bfd@ietf.org"; <rtg-bfd@ietf.org>;
    > Subject: Re: WGLC for BFD Multipoint documents (last round)
    >
    >
    >
    > Looks good to me, Greg. Thanks.
    >
    > Thumb typed by Carlos Pignataro.
    >
    > Excuze typofraphicak errows
    >
    >
    > On Jan 16, 2018, at 15:32, Greg Mirsky <gregimirsky@gmail.com>; wrote:
    >
    > Hi Reshad and Carlos,
    >
    > thank you for your suggestions. Please check the diffs with proposed changes
    > to BFD Multipoint and BFD Multipoint with active tails drafts (attached).
    >
    >
    >
    > Regards,
    >
    > Greg
    >
    >
    >
    > On Mon, Jan 15, 2018 at 8:25 PM, Carlos Pignataro (cpignata)
    > <cpignata@cisco.com>; wrote:
    >
    > Reshad, Greg,
    >
    >
    >
    > Indeed, it seems the content of the section is updated, but the title is
    > misleading. The same applies to the active-tail doc:
    >
    >
    >
    > https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-06#section-3.3.1
    >
    > https://tools.ietf.org/html/draft-ietf-bfd-multipoint-12#section-4.4.1
    >
    >
    >
    > Thanks,
    >
    >
    >
    > —
    > Carlos Pignataro, carlos@cisco.com
    >
    > “Sometimes I use big words that I do not fully understand, to make myself
    > sound more photosynthesis."
    >
    >
    >
    > On Jan 16, 2018, at 10:52 AM, Reshad Rahman (rrahman) <rrahman@cisco.com>;
    > wrote:
    >
    >
    >
    > Hi Greg,
    >
    >
    >
    > Section 4.4.1 still says “New state variables” for bfd.SessionType and the
    > text still starts with “A number of state variables and their values are
    > added…”, so I misinterpreted that as bfd.SessionType is being added as new
    > state variable.
    >
    >
    >
    > Please consider splitting this section in 2 parts for clarification e.g.
    > 4.4.1 for New State Variables (bfd.SilentTail) and 4.4.2 for New State
    > Variable Values (bfd.SessionType).
    >
    >
    >
    > https://tools.ietf.org/html/draft-ietf-bfd-multipoint-12#section-4.4.1
    >
    >
    >
    > Regards,
    >
    > Reshad.
    >
    >
    >
    > From: Greg Mirsky <gregimirsky@gmail.com>;
    > Date: Monday, January 15, 2018 at 6:17 PM
    > To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>;
    > Cc: Jeffrey Haas <jhaas@pfrc.org>;, "Carlos Pignataro (cpignata)"
    > <cpignata@cisco.com>;, "rtg-bfd@ietf.org"; <rtg-bfd@ietf.org>;
    > Subject: Re: WGLC for BFD Multipoint documents (last round)
    >
    >
    >
    > Hi Reshad,
    >
    > I thought I've addressed them as per Carlos suggestion. Have I missed
    > anything?
    >
    >
    >
    > Regards, Greg
    >
    >
    >
    > On Jan 15, 2018 3:00 PM, "Reshad Rahman (rrahman)" <rrahman@cisco.com>;
    > wrote:
    >
    > The changes for bfd.SessionType (it’s not a new state variable but uses
    > what’s defined in RFC7880) weren’t made in the latest revision.
    >
    > Greg, do you plan on addressing this soon? Or there’s no consensus on this
    > topic yet?
    >
    > Regards,
    > Reshad.
    >
    > On 2017-12-20, 12:09 PM, "Rtg-bfd on behalf of Jeffrey Haas"
    > <rtg-bfd-bounces@ietf.org on behalf of jhaas@pfrc.org>; wrote:
    >
    >     Greg,
    >
    >     On Tue, Dec 19, 2017 at 02:17:02PM -0800, Greg Mirsky wrote:
    >     > Hi Carlos and Jeff,
    >     > thank you for responding so expediently. I think we've reached the
    > rough
    >     > consensus. Attached are the diffs for both BFD documents and the
    > updated
    >     > copies. Please let me know if the changes being made have addressed
    > all the
    >     > comments received during the WGLC. I'll then upload new versions.
    >
    >     I believe this covers all points I've seen on the mailing list to date.
    >
    >     Please push the updates.
    >
    >     We'll have further discussion about the need for a registry in
    > conjunction
    >     with the Yang module implications discussion.
    >
    >     -- Jeff
    >
    >     > On Tue, Dec 19, 2017 at 8:05 AM, Jeffrey Haas <jhaas@pfrc.org>; wrote:
    >     [...]
    >     > > At this point it is also worth noting that the session type has no
    >     > > centralized location covering their enumerations.  This leads to two
    >     > > interesting observations:
    >     > > - We could have an IANA registry for such things.  However, I'm not
    > sure
    >     > >   this is really need.  But this also means:
    >     > > - Here's another case why some pieces of the BFD yang module likely
    > shoudl
    >     > >   be IANA maintained.  In this case, the bfd-path-type identity as
    > the
    >     > >   relevant example.
    >
    >
    >
    >
    >
    > <Diff_ draft-ietf-bfd-multipoint-active-tail-06.txt -
    > draft-ietf-bfd-multipoint-active-tail-07.txt.html>
    >
    > <Diff_ draft-ietf-bfd-multipoint-12.txt -
    > draft-ietf-bfd-multipoint-13.txt.html>
    >
    >
    >
    >
    >
    >