Re: [bess] Alissa Cooper's No Objection on draft-ietf-bess-evpn-df-election-framework-07: (with COMMENT)

2019-01-15 Thread Rabadan, Jorge (Nokia - US/Mountain View)
Alissa,

Thank you very much for reviewing. 
You raise very good points about the "update" topic. As discussed, in the rev 
08 we will change the document to update 7432, explaining why in the abstract 
and introduction.

About changing the introduction structure, we thought about it but still prefer 
to keep those sub-sections as part of the introduction. Let us know if it is ok 
or you want us to change the title "introduction" to something else. Maybe 
"introduction and problem statement"?

Thank you.
Jorge

-Original Message-
From: Alissa Cooper 
Date: Wednesday, January 9, 2019 at 5:21 PM
To: The IESG 
Cc: "draft-ietf-bess-evpn-df-election-framew...@ietf.org" 
, Stephane Litkowski 
, "bess-cha...@ietf.org" , 
"stephane.litkow...@orange.com" , 
"bess@ietf.org" 
Subject: Alissa Cooper's No Objection on 
draft-ietf-bess-evpn-df-election-framework-07: (with COMMENT)
Resent-From: 
Resent-To: , , 
, , , 

Resent-Date: Wednesday, January 9, 2019 at 5:21 PM

Alissa Cooper has entered the following ballot position for
draft-ietf-bess-evpn-df-election-framework-07: No Objection

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-bess-evpn-df-election-framework/



--
COMMENT:
--

I know there has already been a bunch of discussion about whether this 
document
should formally update RFC 7432. I wanted to ask specifically about Section
3.1. I may be completely misunderstanding this since I did not give RFC 
7432 a
thorough read, but it appears as though Section 3.1 specifically articulates
details applicable to RFC 7432 (independent of what this draft specifies in 
3.2
and later sections) that were not included in that RFC. That seems like it
warrants the "Updates" relationship, because then people reading RFC 7432 in
the future will know to look at this document for updates, and can at least
find the FSM and its description there. There is not consensus about what
"Updates" means (as evidenced by recent discussion instigated by the IESG 
[1])
and I don't think this is worth dying on a hill over, just wanted to raise 
that
specifically in case people hadn't considered it.

The introduction of this document is unusually long (more than a third of 
the
substantive content of the document). You might consider having 1.1 start a 
new
section rather than having 1.1, 1.2, and 1.3 be subsections of the 
introduction.

[1] https://mailarchive.ietf.org/arch/msg/ietf/-1u_1-peHKAmUDuLyGAJYu0fPCE





___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess


[bess] Alissa Cooper's No Objection on draft-ietf-bess-evpn-df-election-framework-07: (with COMMENT)

2019-01-09 Thread Alissa Cooper
Alissa Cooper has entered the following ballot position for
draft-ietf-bess-evpn-df-election-framework-07: No Objection

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-bess-evpn-df-election-framework/



--
COMMENT:
--

I know there has already been a bunch of discussion about whether this document
should formally update RFC 7432. I wanted to ask specifically about Section
3.1. I may be completely misunderstanding this since I did not give RFC 7432 a
thorough read, but it appears as though Section 3.1 specifically articulates
details applicable to RFC 7432 (independent of what this draft specifies in 3.2
and later sections) that were not included in that RFC. That seems like it
warrants the "Updates" relationship, because then people reading RFC 7432 in
the future will know to look at this document for updates, and can at least
find the FSM and its description there. There is not consensus about what
"Updates" means (as evidenced by recent discussion instigated by the IESG [1])
and I don't think this is worth dying on a hill over, just wanted to raise that
specifically in case people hadn't considered it.

The introduction of this document is unusually long (more than a third of the
substantive content of the document). You might consider having 1.1 start a new
section rather than having 1.1, 1.2, and 1.3 be subsections of the introduction.

[1] https://mailarchive.ietf.org/arch/msg/ietf/-1u_1-peHKAmUDuLyGAJYu0fPCE


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess