Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

From: Martin Vigoureux <[email-masked]>
Date: Tue, 14 Apr 2020 14:16:52 +0200

WG,

it's been more than a month since the e-mail below.
In the meantime there were few updates. These updates cover the 
resolution of Brian's (v11 and finally v12) and Joel's (v13 and finally 
v15) concerns, plus some other minor changes.

Also, there were other comments:
- on the relation with 4291. This comment had already been made at the 
time of WG adoption and responded to at that time.
- on how much address space is needed to operate SRv6. The conclusion 
here was about not adding recommendations in this document. However, I 
encourage people with the interest and knowledge to continue the 
discussion and identify whether something needs to be documented somewhere.
- on the conditions in which the upper-layer header is processed. This 
lead to no change in the document.

These changes bring valuable clarifications but do not affect the 
functional specification. I think we can now move forward.

I very much understand that dissatisfaction persists in relation to the 
"8200 discussion". This will be reflected in the shepherd report, such 
that, ultimately, the IESG is made aware.

Bruno is the shepherd.

-m

Le 2020-03-04 à 22:02, Martin Vigoureux a écrit :
> WG,
> 
> I wanted to bring more context to my decision.
> 
> This document has received a lot of valuable reviews and comments which 
> improved it. That served me as a base to determine consensus on the 
> overall document.
> 
> The point I'd like to insist on is the one I was mentioning in my 
> previous e-mail. In my view, the remaining prominent discussion (and 
> tension) point was about the text of 8200, its implications on the 
> optional PSP capability, and the ramifications of it.
> I have determined there is rough consensus, in SPRING, on the way to 
> read the specific text of 8200, but also that certain aspects go beyond 
> SPRING and would benefit from being discussed with a wider community.
> 
> 
> I'd like to remind that this was a WG Chair level decision. Indeed, 
> Bruno still needs to produce the shepherd write-up and submit the 
> document for publication.
> 
> Martin
> 
> Le 2020-03-02 à 19:53, Martin Vigoureux a écrit :
>> WG,
>>
>> as I had indicated in a previous message I am the one evaluating 
>> consensus for this WG LC.
>>
>> I have carefully read the discussions on the list. I acknowledge that 
>> disagreements were expressed regarding what a particular piece of text 
>> of RFC 8200 says, and on which this document builds to propose an 
>> optional capability. Since RFC 8200 is not a product of the SPRING WG, 
>> I have paid specific attention to the messages ([1], [2], and [3]) 
>> sent by the responsible AD of 6MAN and of RFC8200.
>>
>> My overall conclusion is that there is support and rough consensus to 
>> move this document to the next stage.
>>
>> Bruno will handle the immediate next steps.
>>
>>
>> Martin
>>
>>
>> [1] 
>> https://mailarchive.ietf.org/arch/msg/spring/67ZG76XRezPXilsP3x339rGpcso/
>> [2] 
>> https://mailarchive.ietf.org/arch/msg/spring/plidxjZFBnd4_mEzGsLC76FZmQ0/
>> [3] 
>> https://mailarchive.ietf.org/arch/msg/spring/uBYpxPyyBY6bb86Y2iCh3jSIKBc/
>>
>> Le 2019-12-05 à 18:15, [email-masked] a écrit :
>>> Hello SPRING,
>>>
>>> This email starts a two weeks Working Group Last Call on 
>>> draft-ietf-spring-srv6-network-programming [1].
>>>
>>> Please read this document if you haven't read the most recent 
>>> version, and send your comments to the SPRING WG list, no later than 
>>> December 20.
>>>
>>> You may copy the 6MAN WG for IPv6 related comment, but consider not 
>>> duplicating emails on the 6MAN mailing list for the comments which 
>>> are only spring specifics.
>>>
>>> If you are raising a point which you expect will be specifically 
>>> debated on the mailing list, consider using a specific email/thread 
>>> for this point.
>>>
>>> This may help avoiding that the thread become specific to this point 
>>> and that other points get forgotten (or that the thread get converted 
>>> into parallel independent discussions)
>>>
>>> Thank you,
>>>
>>> Bruno
>>>
>>> [1] 
>>> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05 
>>>
>>>
>>> _________________________________________________________________________________________________________________________ 
>>>
>>>
>>> Ce message et ses pieces jointes peuvent contenir des informations 
>>> confidentielles ou privilegiees et ne doivent donc
>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous 
>>> avez recu ce message par erreur, veuillez le signaler
>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les 
>>> messages electroniques etant susceptibles d'alteration,
>>> Orange decline toute responsabilite si ce message a ete altere, 
>>> deforme ou falsifie. Merci.
>>>
>>> This message and its attachments may contain confidential or 
>>> privileged information that may be protected by law;
>>> they should not be distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender 
>>> and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that have 
>>> been modified, changed or falsified.
>>> Thank you.
>>>
>>>
>>>
>>> _______________________________________________
>>> spring mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/spring
>>>
>>
>> _______________________________________________
>> spring mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/spring
>>
> 
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Andrew Alston <[email-masked]>
Date: Tue, 14 Apr 2020 12:30:31 +0000

Martin,

Since myself - and others still believe the consensus call was fundamentally flawed and a violation of process - we actually welcome this continuing so that we can finally officially lodge the prepared appeals.  Thank you for this

Thanks

Andrew

From: spring <[email-masked]> On Behalf Of Martin Vigoureux
Sent: Tuesday, 14 April 2020 15:17
To: [email-masked]
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

WG,

Bruno is the shepherd.

-m

Le 2020-03-04 à 22:02, Martin Vigoureux a écrit :
>> https://mailarchive.ietf.org/arch/msg/spring/67ZG76XRezPXilsP3x339rGpcso/<https://mailarchive.ietf.org/arch/msg/spring/67ZG76XRezPXilsP3x339rGpcso>
>> [2]
>> https://mailarchive.ietf.org/arch/msg/spring/plidxjZFBnd4_mEzGsLC76FZmQ0/<https://mailarchive.ietf.org/arch/msg/spring/plidxjZFBnd4_mEzGsLC76FZmQ0>
>> [3]
>> https://mailarchive.ietf.org/arch/msg/spring/uBYpxPyyBY6bb86Y2iCh3jSIKBc/<https://mailarchive.ietf.org/arch/msg/spring/uBYpxPyyBY6bb86Y2iCh3jSIKBc>
>>
>> Le 2019-12-05 à 18:15, [email-masked]<mailto:[email-masked]> a écrit :
>>> Hello SPRING,
>>>
>>> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05>
>>>
>>>
>>> [email-masked]<mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>
>>>
>>
>> [email-masked]<mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>
>>
>
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>
>

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 14 Apr 2020 16:36:41 -0300

> v15) concerns, plus some other minor changes.

So, procedurally speaking, how come that:

1) *Firstly* you declare consensus

2) Then multiple folks claim that their concerns have been ignored,

3) Once month later, and after successive revisions from the one you
    declared consensus on, you ship the document to the IESG for
    publication?

During the last month, I asked multiple times what was the status of 
this documents. My questions were ignored.

Was the plan to try to address concerns *after* you had already declared 
wg consensus?

And, in that light, didn't you get the process backwards? (i.e., first 
you listen to the community, then concerns are addressed, and *then* you 
declare wg consensus?)

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Voyer, Daniel" <[email-masked]>
Date: Sat, 18 Apr 2020 19:13:04 +0000

Thank you Martin, very happy that we are moving forward with this 

Dan

Sent from my mobile

> On Apr 14, 2020, at 08:17, Martin Vigoureux <[email-masked]> wrote:
> 
> WG,
> 
> In the meantime there were few updates. These updates cover the resolution of Brian's (v11 and finally v12) and Joel's (v13 and finally v15) concerns, plus some other minor changes.
> 
> - on the relation with 4291. This comment had already been made at the time of WG adoption and responded to at that time.
> - on how much address space is needed to operate SRv6. The conclusion here was about not adding recommendations in this document. However, I encourage people with the interest and knowledge to continue the discussion and identify whether something needs to be documented somewhere.
> - on the conditions in which the upper-layer header is processed. This lead to no change in the document.
> 
> These changes bring valuable clarifications but do not affect the functional specification. I think we can now move forward.
> 
> I very much understand that dissatisfaction persists in relation to the "8200 discussion". This will be reflected in the shepherd report, such that, ultimately, the IESG is made aware.
> 
> Bruno is the shepherd.
> 
> -m
> 
>> This document has received a lot of valuable reviews and comments which improved it. That served me as a base to determine consensus on the overall document.
>> The point I'd like to insist on is the one I was mentioning in my previous e-mail. In my view, the remaining prominent discussion (and tension) point was about the text of 8200, its implications on the optional PSP capability, and the ramifications of it.
>> I have determined there is rough consensus, in SPRING, on the way to read the specific text of 8200, but also that certain aspects go beyond SPRING and would benefit from being discussed with a wider community.
>> I'd like to remind that this was a WG Chair level decision. Indeed, Bruno still needs to produce the shepherd write-up and submit the document for publication.
>> Martin
>>> as I had indicated in a previous message I am the one evaluating consensus for this WG LC.
>>> 
>>> I have carefully read the discussions on the list. I acknowledge that disagreements were expressed regarding what a particular piece of text of RFC 8200 says, and on which this document builds to propose an optional capability. Since RFC 8200 is not a product of the SPRING WG, I have paid specific attention to the messages ([1], [2], and [3]) sent by the responsible AD of 6MAN and of RFC8200.
>>> 
>>> My overall conclusion is that there is support and rough consensus to move this document to the next stage.
>>> 
>>> [1] https://mailarchive.ietf.org/arch/msg/spring/67ZG76XRezPXilsP3x339rGpcso/
>>> [2] https://mailarchive.ietf.org/arch/msg/spring/plidxjZFBnd4_mEzGsLC76FZmQ0/
>>> [3] https://mailarchive.ietf.org/arch/msg/spring/uBYpxPyyBY6bb86Y2iCh3jSIKBc/
>>> 
>>>> This email starts a two weeks Working Group Last Call on draft-ietf-spring-srv6-network-programming [1].
>>>> 
>>>> Please read this document if you haven't read the most recent version, and send your comments to the SPRING WG list, no later than December 20.
>>>> 
>>>> You may copy the 6MAN WG for IPv6 related comment, but consider not duplicating emails on the 6MAN mailing list for the comments which are only spring specifics.
>>>> 
>>>> If you are raising a point which you expect will be specifically debated on the mailing list, consider using a specific email/thread for this point.
>>>> 
>>>> This may help avoiding that the thread become specific to this point and that other points get forgotten (or that the thread get converted into parallel independent discussions)
>>>> 
>>>> Thank you,
>>>> 
>>>> Bruno
>>>> 
>>>> [1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05 
>>>> 
>>>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>>>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>> 
>>>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>>>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>>>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>>>> Thank you.
>>>> 
>>>> 
>>>> 
> ------------------------------------------------------------------------------
> External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints
>