Subject: [Teas] Fwd: IETF WG state changed for draft-ietf-teas-yang-te-topo

From: Lou Berger <[email-masked]>
Date: Wed, 6 Mar 2019 16:21:06 -0500

All,

     The recent versions of the te-topology doc had sufficiently 
significant technical changes that our AD and I, with input from the 
authors, agreed that the document should come back to the WG and to 
rerun a full last call process.  The key changes in rev -19 were:

- Referencing the te-types document and updates to point to its module

- introduction of information-source-instance

The second change is a technical change resulting from implementation 
experience, so is a good change, but as it is a substantive technical 
change the document has to come out of the RFC editor queue to accept it.

Authors,
     Can you send out a message summarizing all changes.

We will then restart the WG LC process.

Thank you,
Lou (as Shepherd/co-chair)

-------- Forwarded Message --------
Subject: 	IETF WG state changed for draft-ietf-teas-yang-te-topo
Date: 	Wed, 06 Mar 2019 10:49:31 -0800
From: 	IETF Secretariat <[email-masked]>
To: 	[email-masked], [email-masked], 
[email-masked]

The IETF WG state of draft-ietf-teas-yang-te-topo has been changed to "WG
Document" from "Submitted to IESG for Publication" by Deborah Brungard:

https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/

---

From: Xufeng Liu <[email-masked]>
Date: Fri, 8 Mar 2019 14:25:13 -0500

Hi Lou,

The change summary has been posted to the WG mailing list (
https://mailarchive.ietf.org/arch/msg/teas/sQ2wMTXYXwniUujt29fysqHwwpI).
Please advise if the authors need to do anything further.
Thanks,
- Xufeng

On Wed, Mar 6, 2019 at 4:21 PM Lou Berger <[email-masked]> wrote:

> authors, agreed that the document should come back to the WG and to rerun a
> full last call process.  The key changes in rev -19 were:
>
> <[email-masked]>
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: Lou Berger <[email-masked]>
Date: Fri, 8 Mar 2019 14:52:38 -0500

Xufeng,

     Can you (or other authors) discuss the motivations/issue addressed 
by the information-source-instance?-- Perhaps I missed it, but I 
believe  this was a change made without WG discussion.

Thank you,

Lou

On 3/8/2019 2:25 PM, Xufeng Liu wrote:
> Hi Lou,
>
> The change summary has been posted to the WG mailing list 
> (https://mailarchive.ietf.org/arch/msg/teas/sQ2wMTXYXwniUujt29fysqHwwpI). 
> On Wed, Mar 6, 2019 at 4:21 PM Lou Berger <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     All,
>
>     significant technical changes that our AD and I, with input from
>     the authors, agreed that the document should come back to the WG
>     and to rerun a full last call process.  The key changes in rev -19
>     were:
>
>     The second change is a technical change resulting from
>     implementation experience, so is a good change, but as it is a
>     substantive technical change the document has to come out of the
>     RFC editor queue to accept it.
>
>     Authors,
>     <mailto:[email-masked]>
>     To: 	[email-masked] <mailto:[email-masked]>,
>     [email-masked] <mailto:[email-masked]>,
>     <mailto:[email-masked]>
>
>
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 8 Mar 2019 20:56:57 +0000

Hi Lou,

We have had quite a bit of  private discussions between the co-anthers, and I believe, we provided a summary to the WG.
In our opinion it is a very simple, straightforward, yet quite useful addition. It was brought  to our attention by the model implementers that for a given topological element (e.g. TE link) there could be more than one instance of the same source of where the information has come from. For example, there could be more  than one instance of OSPF-TE protocol running in the network, and it is useful for the client application to understand which instance discovered/provided information for which TE links.  Before the change the model could only indicate the type of the information source (OSPF-TE protocol), but not its specific instance, hence the addition of the instance leaf.

Regards,
Igor (and co-authors)

From: Lou Berger [mailto:[email-masked]]
Sent: Friday, March 08, 2019 2:53 PM
To: Xufeng Liu
Cc: TEAS WG; [email-masked]
Subject: Re: [Teas] Fwd: IETF WG state changed for draft-ietf-teas-yang-te-topo

Xufeng,

    Can you (or other authors) discuss the motivations/issue addressed by the information-source-instance?-- Perhaps I missed it, but I believe  this was a change made without WG discussion.

Thank you,

Lou

The change summary has been posted to the WG mailing list (https://mailarchive.ietf.org/arch/msg/teas/sQ2wMTXYXwniUujt29fysqHwwpI). Please advise if the authors need to do anything further.
Thanks,
- Xufeng

On Wed, Mar 6, 2019 at 4:21 PM Lou Berger <[email-masked]<mailto:[email-masked]>> wrote:

All,

    The recent versions of the te-topology doc had sufficiently significant technical changes that our AD and I, with input from the authors, agreed that the document should come back to the WG and to rerun a full last call process.  The key changes in rev -19 were:

The second change is a technical change resulting from implementation experience, so is a good change, but as it is a substantive technical change the document has to come out of the RFC editor queue to accept it.
Authors,
    Can you send out a message summarizing all changes.

Thank you,

-------- Forwarded Message --------
Subject:

IETF WG state changed for draft-ietf-teas-yang-te-topo

Date:

Wed, 06 Mar 2019 10:49:31 -0800

From:

IETF Secretariat <[email-masked]><mailto:[email-masked]>

To:

[email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

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

---

From: Lou Berger <[email-masked]>
Date: Sat, 9 Mar 2019 15:55:49 -0500

Hi Igor, (and authors)

     Can you point to where in the archive this discussion took place - 
https://mailarchive.ietf.org/arch/browse/teas/?q=source%20instance isn't 
yielding helpful information.  It's also fine for the authors to make 
the case for the change now if a suitable reference can't be found.

Lou

PS For future reference, technical changes are generally now allowed 
once a document has been approved by the IESG, and even more rarely once 
in the RFC editor queue.  (This is nothing new - I remember having quite 
a discussion back when Jon P. was RFC editor and having to convince him 
that moving the '|' in a packet format half a bit over in a drawing 
didn't require moving the doc out of the RFC editor queue even though 
half bits clearly didn't match the text.)

On 3/8/2019 3:56 PM, Igor Bryskin wrote:
>
> Hi Lou,
>
> We have had quite a bit of  private discussions between the 
> co-anthers, and I believe, we provided a summary to the WG.
>
> In our opinion it is a very simple, straightforward, yet quite useful 
> addition. It was brought  to our attention by the model implementers 
> that for a given topological element (e.g. TE link) there could be 
> more than one instance of the same source of where the information has 
> come from. For example, there could be more  than one instance of 
> OSPF-TE protocol running in the network, and it is useful for the 
> client application to understand which instance discovered/provided 
> information for which TE links.  Before the change the model could 
> only indicate the type of the information source (OSPF-TE protocol), 
> but not its specific instance, hence the addition of the instance leaf.
>
> Regards,
>
> Igor (and co-authors)
>
> *From:*Lou Berger [mailto:[email-masked]]
> *Sent:* Friday, March 08, 2019 2:53 PM
> *To:* Xufeng Liu
> *Cc:* TEAS WG; [email-masked]
> *Subject:* Re: [Teas] Fwd: IETF WG state changed for 
> draft-ietf-teas-yang-te-topo
>
> Xufeng,
>
>             The recent versions of the te-topology doc had
>         sufficiently significant technical changes that our AD and I,
>         with input from the authors, agreed that the document should
>         come back to the WG and to rerun a full last call process. 
>         The key changes in rev -19 were:
>
>         substantive technical change the document has to come out of
>         the RFC editor queue to accept it.
>
>         Authors,
>
>         *Subject: *
>         *Date: *
>         *From: *
>         *To: *
>         [email-masked] <mailto:[email-masked]>,

---

From: Igor Bryskin <[email-masked]>
Date: Sun, 10 Mar 2019 20:22:21 +0000

Hi Xufeng,

I believe every time we published an update for the document we provided a summary of the changes since the previous revision.
Could you find the one for the latest update?

Lou,
Since the document was put into the RFC  Editor queue we have made far more serious change - we replaced the dependency on te-tunnel model  with the dependency on te-types model. You knew about our intention long time ago, as well as that the document would need in this case another close look by WG. You have not warned us about the problem, nor pulled the document out of the queue then.
Now you are focused on the most trivial change (almost as harmful as changing Tarek's association from CSCO to Jniper), which could be easily reviewed by the WG along with consequences of the depency change. Why is that?

Igor

Thanks,
Igor
From:Lou Berger
To:Igor Bryskin,Xufeng Liu,
Cc:TEAS WG,[email-masked],
Date:2019-03-09 15:56:11
Subject:Re: [Teas] Fwd: IETF WG state changed for draft-ietf-teas-yang-te-topo

Hi Igor, (and authors)

    Can you point to where in the archive this discussion took place - https://mailarchive.ietf.org/arch/browse/teas/?q=source%20instance isn't yielding helpful information.  It's also fine for the authors to make the case for the change now if a suitable reference can't be found.

Lou

PS For future reference, technical changes are generally now allowed once a document has been approved by the IESG, and even more rarely once in the RFC editor queue.  (This is nothing new - I remember having quite a discussion back when Jon P. was RFC editor and having to convince him that moving the '|' in a packet format half a bit over in a drawing didn't require moving the doc out of the RFC editor queue even though half bits clearly didn't match the text.)

Regards,
Igor (and co-authors)

From: Lou Berger [mailto:[email-masked]]
Sent: Friday, March 08, 2019 2:53 PM
To: Xufeng Liu
Cc: TEAS WG; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] Fwd: IETF WG state changed for draft-ietf-teas-yang-te-topo

Xufeng,

Thank you,

Lou

All,

Thank you,

-------- Forwarded Message --------
Subject:

Date:

From:

To:

---

From: Lou Berger <[email-masked]>
Date: Sun, 10 Mar 2019 18:07:40 -0400

Igor,

On 3/10/2019 4:22 PM, Igor Bryskin wrote:
> Hi Xufeng,
>
> I believe every time we published an update for the document we 
> provided a summary of the changes since the previous revision.
> Since the document was put into the RFC  Editor queue we have made far 
> more serious change - we replaced the dependency on te-tunnel model  
> with the dependency on te-types model. You knew about our intention 
> long time ago, as well as that the document would need in this case 
> another close look by WG. You have not warned us about the problem, 
> nor pulled the document out of the queue then.

Correct. This has been widely discussed, at the last IETF and on list.

> Now you are focused on the most trivial change (almost as harmful as 
> changing Tarek's association from CSCO to Jniper), which could be 
> easily reviewed by the WG along with consequences of the depency 
> change. Why is that?

The change in dependency was basically and editorial change, it was to 
reflect where the module was being defined.  An affiliation change is 
also not considered to be a substantive technical change by the IETF, 
remember we contribute to the IETF as individuals, so such affiliation 
changes are non problematic.  Most importantly,  the RFC editor was 
consulted *prior* to agreeing to this change, to ensure that it was an 
acceptable change while in the editor queue and that the reference 
change didn't require that it be pulled -- this was all coordinated with 
the Shepherd/AD/RFC-Editor and authors before it was discussed with the 
WG at the last IETF.

The reason that the technical change forced this reset is simply that it 
happened without any discussion with the IESG.

Once a document is submitted for publication, they own it - not the WG.  
Once our AD was notified that this change was made, the only question 
she had for me (as Shepherd/co-chair, Pavan was consulted but recused 
himself as he is a co-author) was if to send it back to the WG or remove 
the change and immediately start on a bis.  The former seemed the more 
reasonable.  At this point, we can always go the BIS route if that's 
what the WG decides.

Please also keep in mind that the WG owns the technical content of a WG 
document, not the authors or editors.  Authors and editors have a lot of 
leeway in how to gauge or build consensus, including making a change in 
an active WG document and then discussing it with the WG.  Ultimately it 
is WG last call that ensures that a document represents WG consensus 
prior to publication submission. It is true that technical changes also 
happen during IESG processing, and it is IETF last call that ensures the 
final technical comment matches IETF consensus - and it the AD that 
ensures the content matches IETF consensus.

A technical change, no matter how small, post all LCs and in the RFC 
editor queue initiated by the authors, without any coordination, is a 
serious process fowl.  Deborah was fully within her rights to reject 
this change and present the Chairs with the option of doing what we're 
doing or proceeding with RFC publication without the change.  BTW the 
formal version of this is documented in RFCs2418 and 4858.

Do you think we should proceed with publication without this change?  If 
so, please respond to the 2nd LC stating this.

Lou

(as Shepherd and Co-chair)

>
> Igor
>
>
>
> Thanks,
> Igor
> *From:*Lou Berger
> *To:*Igor Bryskin,Xufeng Liu,
> *Cc:*TEAS WG,[email-masked],
> *Date:*2019-03-09 15:56:11
> *Subject:*Re: [Teas] Fwd: IETF WG state changed for 
> https://mailarchive.ietf.org/arch/browse/teas/?q=source%20instance 
> isn't yielding helpful information.  It's also fine for the authors to 
> make the case for the change now if a suitable reference can't be found.
>
> Lou
>
> once a document has been approved by the IESG, and even more rarely 
> once in the RFC editor queue.  (This is nothing new - I remember 
> having quite a discussion back when Jon P. was RFC editor and having 
> to convince him that moving the '|' in a packet format half a bit over 
> in a drawing didn't require moving the doc out of the RFC editor queue 
> even though half bits clearly didn't match the text.)
>
>> more than one instance of the same source of where the information 
>> has come from. For example, there could be more  than one instance of 
>>     Can you (or other authors) discuss the motivations/issue 
>> addressed by the information-source-instance?-- Perhaps I missed it, 
>> but I believe  this was a change made without WG discussion.
>>
>> Thank you,
>>
>> Lou
>>
>>         implementation experience, so is a good change, but as it is
>>         a substantive technical change the document has to come out
>>         of the RFC editor queue to accept it.
>>
>>         Authors,
>>

---

From: Tarek Saad <[email-masked]>
Date: Mon, 11 Mar 2019 01:49:03 +0000

Hi Lou/WG,

I also confirm this topic of protocol source-instance was discussed in an internal meeting within the authors. I cant locate the minutes of that meeting, but the decision to add the information-source-instance is inline with other RFCs that carry IGP/BGP link state. For example, I quote from RFC7752, https://tools.ietf.org/html/rfc7752#section-3.2

“
   Both OSPF and IS-IS MAY run multiple routing protocol instances over
   the same link.  See [RFC6822<https://tools.ietf.org/html/rfc6822>] and [RFC6549<https://tools.ietf.org/html/rfc6549>].  These instances define
   independent "routing universes".  The 64-bit Identifier field is used
   to identify the routing universe where the NLRI belongs.
“

In above, the instance is encoded in the 64-bit identifier. In the TE topology model, the information-source-instance plays the same role.

Regards,
Tarek

From: Teas <[email-masked]> on behalf of Lou Berger <[email-masked]>
Date: Friday, March 8, 2019 at 3:21 PM
To: Xufeng Liu <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, TEAS WG <[email-masked]>
Subject: Re: [Teas] Fwd: IETF WG state changed for draft-ietf-teas-yang-te-topo

Xufeng,

Thank you,

Lou

All,

Thank you,

-------- Forwarded Message --------
Subject:

Date:

From:

To:

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Sun, 10 Mar 2019 21:18:36 -0500

Igor,

The only foul that the authors made was to not discuss the diffs on the
list before submitting rev-19. There was an incorrect assumption made (by
the authors) that Xufeng's post submission email with details on the diffs
was sufficient to trigger the necessary discussion. This was an oversight
and had no intended malice. This practice (of submitting the changes first
and then triggering a discussion about the diffs) is sort of deemed
acceptable while the document is being reviewed by the WG or IESG, but not
while it is sitting in the RFC Editor's queue. In hindsight, given that the
document was sitting in the RFC Editor's queue, the authors should have
reached out to the AD/Shepherd for guidance before submission (and I take
the blame on behalf of the authors for not doing it).

Lou, Hi!

>> Do you think we should proceed with publication without this change?

I think the WG would need more details (to weigh in with an informed
opinion) on how proceeding with publication without this change would
impact the progress of the document. If a new rev is published now without
the information-source-instance change (and with all the other changes made
in rev 19 left intact), would the document skip back to the RFC-Editor's
queue without any IESG involvement?

Regards,

-Pavan (no hat on)

On Sun, Mar 10, 2019 at 5:08 PM Lou Berger <[email-masked]> wrote:

> I believe every time we published an update for the document we provided a
> summary of the changes since the previous revision.
> more serious change - we replaced the dependency on te-tunnel model  with
> the dependency on te-types model. You knew about our intention long time
> ago, as well as that the document would need in this case another close
> look by WG. You have not warned us about the problem, nor pulled the
> document out of the queue then.
>
> changing Tarek's association from CSCO to Jniper), which could be easily
> reviewed by the WG along with consequences of the depency change. Why is
> that?
>
> reflect where the module was being defined.  An affiliation change is also
> not considered to be a substantive technical change by the IETF, remember
> we contribute to the IETF as individuals,  so such affiliation changes are
> non problematic.  Most importantly,  the RFC editor was consulted *prior*
> to agreeing to this change, to ensure that it was an acceptable change
> while in the editor queue and that the reference change didn't require that
> it be pulled -- this was all coordinated with the Shepherd/AD/RFC-Editor
> and authors before it was discussed with the WG at the last IETF.
>
> Once our AD was notified that this change was made, the only question she
> had for me (as Shepherd/co-chair, Pavan was consulted but recused himself
> as he is a co-author) was if to send it back to the WG or remove the change
> and immediately start on a bis.  The former seemed the more reasonable.  At
> this point, we can always go the BIS route if that's what the WG decides.
>
> leeway in how to gauge or build consensus, including making a change in an
> active WG document and then discussing it with the WG.  Ultimately it is WG
> last call that ensures that a document represents WG consensus prior to
> publication submission.  It is true that technical changes also happen
> during IESG processing, and it is IETF last call that ensures the final
> technical comment matches IETF consensus - and it the AD that ensures the
> content matches IETF consensus.
>
> serious process fowl.  Deborah was fully within her rights to reject this
> change and present the Chairs with the option of doing what we're doing or
> proceeding with RFC publication without the change.  BTW the formal version
> of this is documented in RFCs2418 and 4858.
>
> yielding helpful information.  It's also fine for the authors to make the
> case for the change now if a suitable reference can't be found.
>
> Lou
>
> PS For future reference, technical changes are generally now allowed once
> a document has been approved by the IESG, and even more rarely once in the
> RFC editor queue.  (This is nothing new - I remember having quite a
> discussion back when Jon P. was RFC editor and having to convince him that
> moving the '|' in a packet format half a bit over in a drawing didn't
> require moving the doc out of the RFC editor queue even though half bits
> clearly didn't match the text.)
> We have had quite a bit of  private discussions between the co-anthers,
> and I believe, we provided a summary to the WG.
>
> addition. It was brought  to our attention by the model implementers that
> for a given topological element (e.g. TE link) there could be more than one
> instance of the same source of where the information has come from. For
> example, there could be more  than one instance of OSPF-TE protocol running
> in the network, and it is useful for the client application to understand
> which instance discovered/provided information for which TE links.  Before
> the change the model could only indicate the type of the information source
> (OSPF-TE protocol), but not its specific instance, hence the addition of
> the instance leaf.
>
>
>
> Regards,
>
> Igor (and co-authors)
>
>
>
>
>
> *From:* Lou Berger [mailto:[email-masked] <[email-masked]>]
>     Can you (or other authors) discuss the motivations/issue addressed by
> the information-source-instance?-- Perhaps I missed it, but I believe  this
> was a change made without WG discussion.
>
> Thank you,
>
> Lou
>
> IETF Secretariat <[email-masked]>
> [email-masked], [email-masked],

---

From: Lou Berger <[email-masked]>
Date: Sun, 10 Mar 2019 23:02:08 -0400

> If a new rev is published now without

I don't believe so, I think we still have to go through redoing the pub 
request and iesg, but as there would be no substantive change it might go 
through faster.

Given where we are today, imo let's get it right and move forward.  if 
dropping the change means that we've have to immediately start on a BIS I 
think dropping it would be the wrong move. If on the other hand the change 
really isn't needed, that it would be good to hear that.

Lou

----------
On March 10, 2019 10:19:27 PM Vishnu Pavan Beeram <[email-masked]> 
wrote:

> ----------