Re: WGLC for BFD Multipoint documents (last round)

[Greg Mirsky <[e-mail]>]

Hi Reshad,
nits fixed and the new text below:
OLD TEXT
A number of values of the state variable are added to the base BFD…
NEW TEXT
A number of new values of the state variable bfd.SessionType are added to
the base BFD…
Would you accept this update?

Regards,
Greg

On Mon, Jan 29, 2018 at 5:52 AM, Reshad Rahman (rrahman) <[e-mail]>
wrote:

> Hi Greg,
>
>
>
>    - Section 4.2. s/The head has a session of type MultipointHead Section
>    4.4.1/ The head has a session of type MultipointHead, as defined in Section
>    4.4.1, /
>    - Section 4.4.1. “A number of values of the state variable are added
>    to the base BFD…”. That sentence needs rewording IMO but maybe I’m just
>    missing what it’s trying to convey.
>    - Section 4.6. s/Active role , / Active role, /
>    - Section 4.10. “MUST send packets with P bit set.”. Did we agree on
>    “MUST send packets with *the* P bit set.”?
>
>
>
> Regards,
>
> Reshad.
>
>
>
> *From: *Greg Mirsky <[e-mail]>
> *Date: *Saturday, January 27, 2018 at 11:38 PM
>
> *To: *"Reshad Rahman (rrahman)" <[e-mail]>
> *Cc: *"Carlos Pignataro (cpignata)" <[e-mail]>, Jeffrey Haas <
> [e-mail]>, "[e-mail]" <[e-mail]>
> *Subject: *Re: WGLC for BFD Multipoint documents (last round)
>
>
>
> Hi Reshad,
>
> many thanks for your guidance and support. Should I upload the new version
> of the draft?
>
>
>
> Kind regards,
>
> Greg
>
>
>
> PS. Diff and the current working version are attached.
>
>
>
> On Sat, Jan 27, 2018 at 6:36 PM, Reshad Rahman (rrahman) <
> [e-mail]> wrote:
>
> Thanks Greg. PSI <RR2>.
>
>
>
> I think we’ve closed on these comments.
>
>
>
> Regards,
>
> Reshad.
>
>
>
> *From: *Greg Mirsky <[e-mail]>
> *Date: *Friday, January 26, 2018 at 7:42 PM
> *To: *"Reshad Rahman (rrahman)" <[e-mail]>
> *Cc: *"Carlos Pignataro (cpignata)" <[e-mail]>, Jeffrey Haas <
> [e-mail]>, "[e-mail]" <[e-mail]>
> *Subject: *Re: WGLC for BFD Multipoint documents (last round)
>
>
>
> Hi Reshad, et. al,
>
> thank you for your kind consideration of the update. I'm applied all the
> changes you've agreed to. Remaining are few nits I wanted to confirm with
> you and one update that is not editorial:
>
> In 4.13.1
> <https://tools.ietf.org/html/draft-ietf-bfd-multipoint-12#section-4.13.1>.
> Reception of BFD Control Packets
>
> OLD TEXT:
>
> Else (bfd.SessionType is not PointToPoint)
>
> NEW TEXT
>
> Else (bfd.SessionType is MultipointTail)
>
> Please find my notes in-line tagged GIM2>>.
>
>
>
> Kind regards,
>
> Greg
>
>
>
> On Fri, Jan 26, 2018 at 7:14 AM, Reshad Rahman (rrahman) <
> [e-mail]> wrote:
>
> Hi Greg,
>
>
>
> Thank you for the prompt response. The changes look good. Some nits I may
> missed during my review and nits on new rev:
>
>    - 3 Overview. s/Details of how head keeps track/Details of how heads
>    keep track/ (or if singular “of how a head keeps track”)
>
> GIM2>> I think that singular is consistent with the preceding sentence 'A
> head may wish to be alerted to the tails' connectivity (or lack thereof).'
> And because there's 'a head' should the next reference be 'the head', thus
> making 'Details of how the head keeps track ...'?
>
> <RR2> Good.
>
>
>    -
>    - 4.2 Session Model. References to Section 4.4.1 were added but
>    consider making a change e.g adding () around the reference or “, as
>    defined in Section 4.4.1, “ .
>
> GIM2>> Done
>
>
>    -
>    - 4.4.1 New State Variable Values. First paragraph starts “A number
>    values of the state variable are added to the base BFD…”. Should be “A
>    number of values…”? Or reword that paragraph to something along the lines
>    of “A number of values are added to some existing state variables defined
>    in the base BFD…”
>
> GIM2>> Used the former 'A number of values ...'
>
> <RR2> Ack.
>
>
>    -
>    - 4.10 Timer Manipulation. s/However to indicate a change in the
>    packets MultipointHead session MUST send packets with P bit set.
>    MultipointTail session/However to indicate a change in the packets,
>    MultipointHead sessions MUST send packets with the P bit set.
>    MultipointTail sessions/
>
> GIM2>> Or should it be 'However, to indicate a change in the packets,
> MultipointHead MUST send packets with the P bit set.'?
>
> <RR2> Good.
>
>
>    -
>
>
>
> Please see inline <RR>.
>
>
>
> Regards,
>
> Reshad.
>
>
>
> *From: *Greg Mirsky <[e-mail]>
> *Date: *Thursday, January 25, 2018 at 4:46 PM
> *To: *"Reshad Rahman (rrahman)" <[e-mail]>
> *Cc: *"Carlos Pignataro (cpignata)" <[e-mail]>, Jeffrey Haas <
> [e-mail]>, "[e-mail]" <[e-mail]>
> *Subject: *Re: WGLC for BFD Multipoint documents (last round)
>
>
>
> Hi Reshad,
>
> sincere thank you for your help and support. In this note I'll address
> Shepherd Write-up on BFD for Multipoint Networks draft (active tails will
> be addressed in the separate response shortly). Please find my responses to
> your comments in-line tagged GIM>>. Attached are diffs to the updated
> version and the current working text.
>
>
>
> : (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>> Fixed.
>
>
>
> - General. There are a few instances where singular is used instead of
> plural (e.g. for session, packet) 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 4.9 “(… than it did previously.)”. I
> have not called out all of them, search for “.)”
>
> GIM>> Got 10+ of those
>
>
>
> - General. s/this protocol/Multipoint BFD/?
>
> GIM>>
>
> - General. Use of term tree e.g. multipoint tree. Should we use path
> instead?
>
> - Abstract. Remove “Comments on this draft…”
>
> GIM>> Done
>
> - 1 Introduction. “Details of tail notification…”. Add reference to
> draft-ietf-bfd-multipoint-active-tail?
>
> GIM>> Current text puts them outside the scope. I agree that alternative
> may be to point to draft-ietf-bfd-multipoint-active-tail directly, though
> then we have new informational reference. Perhaps
>
> OLD TEXT
>
> Details of tail notification to head are outside the scope of this
> document.
>
> NEW TEXT
>
> Details of tail notification to head are outside the scope of this
> document and are discussed in [I_D.ietf-bfd-multipoint-active-tail].
>
>
>
> Acceptable?
>
> <RR> Yes.
>
>
>
> - 1 Introduction. s/is not being used in context/is not being used in the
> context/
>
> GIM>> Done
>
> - 1 Introduction. Add reference to [RFC5880] after “… and adds to the base
> BFD specification.”
>
> GIM>> Done
>
> - 1 Introduction. Remove “It is the intention of the authors to fold…”
>
> GIM>> Done
>
> - 2 Goals. Not sure about “multicast or multipoint medium”, maybe
> “multipoint or multicast path”?
>
> GIM>> Would "Another goal is for the mechanism to work on any multipoint
> network segments or multicast technologies" work?
>
> <RR> I am fine with something along the lines of "Another goal is for the
> mechanism to work on any multicast technology."
>
>
>
> - 2 Goals. “… multipoint paths with multiple heads” should that be
> “multipoint-to-multipoint”?
>
> GIM>> Yes, indeed. Would referring to multipoint explicitly as
> point-to-multipoint make it more clear?
>
> OLD TEXT
>
> A further goal is to support multiple, overlapping multipoint paths, as
> well as multipoint paths with multiple heads...
>
> NEW TEXT
>
> A further goal is to support multiple, overlapping point-to-multipoint
> paths, as well as multipoint-to-multipoint paths  ...
>
> <RR> Yes.
>
>
>
> - 2 Goals. Remove “A final goal is to integrate multipoint operation…”. If
> this is still relevant we need clarification on how this is being done. May
> need to also explain what is meant by “relatively easy”
>
> GIM>> Agree and done.
>
> - 2 Goals. s/any tails/any tail/
>
> - 2 Goals. s/It is a non-goal/It is not a goal/?
>
> GIM>> Done and done
>
> - 3 Overview. s/Details of how head keeps track/Details of how heads keep
> track/. Add reference to draft-ietf-bfd-multipoint-active-tail after that
> sentence?
>
> GIM>> Not sure that changing to plural in this sentence is warranted. I
> interpret it as reference to a single p2mp BFD session. Would you agree?
>
> <RR> You’re right, no need for plural. So “Details of how a head keeps
> track”?
>
>
>
> GIM>> RE: reference to the active tails draft. As noted above, it will
> introduce new informational reference. Any concern with that?
>
> <RR> No need for reference to active-tail.
>
>
>
> - 3 Overview. s/Head may wish/A head may wish/
>
> GIM>> Done
>
> - 3 Overview. s/it’s connectivity/its connectivity/
>
> GIM>> I think that more extensive change is required here:
>
> OLD TEXT
>
> ... how tails alert it's connectivity to head ...
>
> NEW TEXT
>
> ... how tails alert their connectivity to the head ...
>
> or
>
> ... how tail alerts its connectivity to the head ...
>
> Acceptable? Which one?
>
> <RR> I’d go for “…how tails alert their connectivity to the head…”.
>
>
>
> - 4.1 Multipoint BFD Control Packets. Add reference to [RFC5880] after
> “…via the setting of the M bit.”
>
> GIM>> Done
>
> - 4.2 Session Model. s/from the head over multicast path/from the head
> over the multicast path/.
>
> - 4.2 Session Model. MultipointHead and MultipointTail: add reference for
> each to section 4.4.1 where they are defined.
>
> GIM>> Done and done
>
>
>
> - 4.4.1 New State Variables. Already discussed splitting this into new
> variables and new values.
>
> - 4.4.1 New State Variables. Already discussed taking bfd.SilentTail out
> of draft-ietf-bfd-multipoint
>
> - 4.4.2 State Variable Initialization and Maintenance. s/defined in
> section 6.8.1 of the [RFC5880] needs/defined in section 6.8.1 of [RFC5880]
> need/
>
> GIM>> Done
>
> - 4.5 State Machine. s/Session of type/Sessions of type/
>
> - 4.5 State Machine. s/and must be ignored/and MUST be ignored/
>
> GIM>> Done and done
>
> - 4.5 State Machine. Should there be a state machine for the head or is it
> too simple since no packets are received from tail? e.g. if the multipoint
> path goes down does the MultipointHead session go down?
>
> GIM>> I think that the very last sentence addresses your question:
>
>    Sessions of type MultipointHead never receive packets and have no
>
>    Detection Timer, and as such all state transitions are
>
>    administratively driven.
>
> <RR> Ack.
>
>
>
> - 4.6 Session Establishment. s/Unlike Point-to-point/Unlike point-to-point/
>
> GIM>> Done
>
> - 4.6 Session Establishment. “Except when terminating BFD service…”, does
> terminating mean shutting down (as in admin down)?
>
> GIM>> Yes, I think that is exactly as you've described. Should that be
> clarified, e.g. "Except when administratively terminating BFD service ..."?
>
> <RR> “Except when administratively terminating the BFD service”?
>
>
>
> - 4.6 Session establishment. Active and passive roles: add reference to
> the appropriate section of [RFC5880].
>
> GIM>> Like to Section 6.1 Overview in RFC 5880? How I would refer to the
> particular section in XML?
>
> <RR> Just reference to [5880] is fine.
>
>
>
> - 4.7 Discriminators and Packet Demultiplexing. s/over the MultipointHead
> session with/over the Multipoint path va the MultipointHead session with/
>
> GIM>> Done as s/over the MultipointHead session with/over the multipoint
> path via the MultipointHead session with/
>
>
>
> - 4.7. s/PointToPoint/point-to-point/. PointToPoint is to be used only
> when referring to bfd.SessionType.
>
> - 4.7. s/Bootstrapping BFD session to a multipoint LSP/Bootstrapping a BFD
> session to multipoint MPLS LSP/
>
> - 4.8 Packet consumption on tails. s/for a multicast group/for an IP
> multicast group/
>
> - 4.8. s/For multipoint LSP/For multipoint LSPs/
>
> - 4.8. s/encapsulation of BFD control packet/encapsulation of BFD control
> packets/
>
> GIM>> Done to all the above
>
> - For IPv4/IPv6 address range, add reference to [RFC5884]?
>
> GIM>> I think that first use of martian addresses as IP DA was for LSP
> Ping RFC4379 now RFC8029. Should refer to RFC8029?
>
> <RR> Yes.
>
>
>
> - 4.8. s/Packet identified as BFD packet/Packets identified as BFD packets/
>
> - 4.8. s/used,/is used,/
>
> GIM>> Done and done
>
> - 4.10 Timer Manipulation. s/However to indicate change in packet/However
> to indicate a change in the packets, /
>
> - 4.10. s/MUST send packet with P bit/MUST send packets with P bit/
>
> - 4.10/ s/MultipointHead MAY also/A MultipointHead session MAY also/
>
> GIM>> Done * 3
>
> - 4.11 Detection times. s/Since the MultipointHead session never receives
> packets, it does not/Since MultipointHead sessions never receive packets,
> they do not/
>
> - 4.11 Detection times. s/the Detection Time/the detection time/
>
> GIM>> Done and done
>
> - 4.13 Base Specification Text Replacement. Clarify here or in the
> introduction that processing for point-to-point BFD does NOT change.
>
> GIM>> Please check if the following update is acceptable
>
> OLD TEXT
>
> The following sections are meant to replace the corresponding sections in
> the base specification
>
> NEW TEXT
>
> The following sections are meant to replace the corresponding sections in
> the base specification [RFC5880]
>
> in support of BFD for multipoint networks while not changing processing
> for point-to-point BFD.
>
> <RR> Ack.
>
>
>
> - 4.13.1. Add reference to [RFC5880] before mentioning section 6.7, e.g
> “under of rules of section 6.7 of [RFC5880]”
>
> GIM>> Done on two occurences
>
> - 4.13.2 P14. If the State field is Init and bfd.SessionType is not
> PointToPoint. Instead of checking “is not PointToPoint” should we check “is
> MultipointTail”? Otherwise this has an impact on S-BFD?
>
> GIM>> I agree. Should we get WG confirmation as for technical update or it
> is editorial?
>
> <RR> WG confirmation would be good.
>
> - 7 Security Considerations. s/ex:/e.g./
>
> GIM>> Done
>
> - 7 Security Considerations. Should we add at the beginning “The same
> security considerations as those described in [RFC5880] apply to this
> document. Additionally …”?
>
> GIM>> Agreed and done
>
>
>
> On Wed, Jan 24, 2018 at 2:42 PM, Reshad Rahman (rrahman) <
> [e-mail]> 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 <[e-mail]>
> *Date: *Tuesday, January 16, 2018 at 11:01 PM
>
>
> *To: *"Reshad Rahman (rrahman)" <[e-mail]>
> *Cc: *"Carlos Pignataro (cpignata)" <[e-mail]>, Jeffrey Haas <
> [e-mail]>, "[e-mail]" <[e-mail]>
> *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)" <[e-mail]>
> 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 <[e-mail]>
> *Date: *Tuesday, January 16, 2018 at 9:25 PM
> *To: *"Reshad Rahman (rrahman)" <[e-mail]>
> *Cc: *"Carlos Pignataro (cpignata)" <[e-mail]>, Jeffrey Haas <
> [e-mail]>, "[e-mail]" <[e-mail]>
> *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 <[e-mail]>
> 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) <
> [e-mail]> wrote:
>
> Hi Greg,
>
>
>
> I am fine with the change below.
>
>
>
> Regards,
>
> Reshad.
>
>
>
> *From: *Greg Mirsky <[e-mail]>
> *Date: *Tuesday, January 16, 2018 at 2:20 PM
> *To: *"Reshad Rahman (rrahman)" <[e-mail]>
> *Cc: *"Carlos Pignataro (cpignata)" <[e-mail]>, Jeffrey Haas <
> [e-mail]>, "[e-mail]" <[e-mail]>
>
>
> *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) <
> [e-mail]> 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)" <[e-mail]>
> *Date: *Tuesday, January 16, 2018 at 9:32 AM
> *To: *"Carlos Pignataro (cpignata)" <[e-mail]>, Greg Mirsky <
> [e-mail]>
> *Cc: *Jeffrey Haas <[e-mail]>, "[e-mail]" <[e-mail]>
>
>
> *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)" <[e-mail]>
> *Date: *Tuesday, January 16, 2018 at 1:47 AM
> *To: *Greg Mirsky <[e-mail]>
> *Cc: *"Reshad Rahman (rrahman)" <[e-mail]>, Jeffrey Haas <
> [e-mail]>, "[e-mail]" <[e-mail]>
> *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 <[e-mail]> 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) <
> [e-mail]> 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, [e-mail]
>
> *“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) <[e-mail]>
> 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 <[e-mail]>
> *Date: *Monday, January 15, 2018 at 6:17 PM
> *To: *"Reshad Rahman (rrahman)" <[e-mail]>
> *Cc: *Jeffrey Haas <[e-mail]>, "Carlos Pignataro (cpignata)" <
> [e-mail]>, "[e-mail]" <[e-mail]>
> *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)" <[e-mail]>
> 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" <
> [e-mail] on behalf of [e-mail]> 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 <[e-mail]>
> 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>
>
>
>
>
>
>
>
>
>
>
>
>
>