Re: Ben Campbell's Discuss on draft-ietf-bfd-multipoint-active-tail-09: (with DISCUSS and COMMENT)

[Martin Vigoureux <[e-mail]>]

[adding back authors/WG/chairs/shepherd, which I unintentionally pruned 
by replying only to the list... sorry]

Thank you Ben. Perfectly clear to me now.

The Introduction of bfd-multipoint currently states:
    As an option, if a return path from a tail to the head exists, the
    tail may notify the head of the lack of multipoint connectivity.
    Details of tail notification to the head are outside the scope of
    this document and are discussed in
    [I-D.ietf-bfd-multipoint-active-tail].

Would you consider this as sufficient?

Thank you
-m

Le 2018-07-04 à 6:14, Ben Campbell a écrit :
> 
> 
>> On Jul 3, 2018, at 2:43 PM, Martin Vigoureux <[e-mail]> wrote:
>>
>> Ben
>>
>> so, I'm not sure to have fully understood your initial statement and I might have introduced additional confusion with mine.
>>
>> bfd-multipoint-active-tail extends the capabilities of bfd-multipoint and in doing so modifies that base specification, this is why bfd-multipoint-active-tail Updates bfd-multipoint (though I would agree that the header very badly indicates that).
>>
>> Are you suggesting that bfd-multipoint-active-tail should not Update bfd-multipoint and that the authors simply add a reference to bfd-multipoint-active-tail in bfd-multipoint?
> 
> Yes, although I would suggest at least some explanation in mfd-multipoint about the reason for the reference.
> 
>> And are you suggesting that because we are progressing the two drafts at the same time?
> 
> Yes.
> 
> Ben.
> 
>>
>> Thanks
>> -m
>>
>> Le 2018-07-03 à 20:05, Ben Campbell a écrit :
>>>> On Jul 3, 2018, at 10:21 AM, Ben Campbell <[e-mail]> wrote:
>>>>
>>>>
>>>>
>>>>> On Jul 3, 2018, at 2:31 AM, Martin Vigoureux <[e-mail]> wrote:
>>>>>
>>>>> Hello Ben,
>>>>>
>>>>> thanks for your review.
>>>>> About your DISCUSS, bfd-multipoint-active-tail indeed updates bfd-multipoint.
>>>>> Correcting this would in fact require to merge the two documents.
>>>>> Back in November 2014 the WG has decided to split the multipoint BFD spec in two. This was mainly driven by the existence of implementations of bfd-multipoint but not yet of bfd-multipoint-active-tail, which still holds today.
>>>>
>>>> I don’t see why it’s to merge the documents to fix this. Why not have  bfd-multipoint mention the differences in bfd-multipoint-active-tail and directly reference it. The point of “updates” is to make sure readers are aware of the updating draft; a direct reference in the “updated” seems an even better way.
>>> Uhm, make that “I don’t know why it’s _necessary_ to merge…”  and “a direct reference in the updated _draft_”
>>> Ben.
>>>>
>>>> Ben.
>>>>
>>>>
>>>>>
>>>>> -m
>>>>>
>>>>> Le 2018-07-03 à 3:21, Ben Campbell a écrit :
>>>>>> Ben Campbell has entered the following ballot position for
>>>>>> draft-ietf-bfd-multipoint-active-tail-09: Discuss
>>>>>> When responding, please keep the subject line intact and reply to all
>>>>>> email addresses included in the To and CC lines. (Feel free to cut this
>>>>>> introductory paragraph, however.)
>>>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>>> The document, along with other ballot positions, can be found here:
>>>>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint-active-tail/
>>>>>> ----------------------------------------------------------------------
>>>>>> DISCUSS:
>>>>>> ----------------------------------------------------------------------
>>>>>> This is a process discuss:
>>>>>> If I read things correctly, this draft purports to update an _unpublished_ RFC
>>>>>> (i.e., another draft.). If so, can't we just correct that draft before
>>>>>> publishing it?
>>>>>> ----------------------------------------------------------------------
>>>>>> COMMENT:
>>>>>> ----------------------------------------------------------------------
>>>>>> Assuming this progresses mostly as-is, please mention the update in the
>>>>>> abstract, and put a sentence or two in the introduction to give a high level
>>>>>> summary of what the update actually is.
>>>>>
>>>>
>