[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 <[email protected]> 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 <[email protected]> wrote:
On Jul 3, 2018, at 2:31 AM, Martin Vigoureux <[email protected]> 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.
