The Interior Routing Overlay Network (IRON)
draft-templin-ironbis-16
Discuss
Yes
(Ralph Droms)
No Objection
(Barry Leiba)
(Gonzalo Camarillo)
(Wesley Eddy)
Abstain
(Ron Bonica)
No Record
Deb Cooley
Erik Kline
Francesca Palombini
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke
Summary: Needs a YES.
Deb Cooley
No Record
Erik Kline
No Record
Francesca Palombini
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
John Scudder
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Roman Danyliw
No Record
Warren Kumari
No Record
Zaheduzzaman Sarker
No Record
Éric Vyncke
No Record
Adrian Farrel Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2013-02-20 for -12)
Unknown
I feel a little like I am "piling on" with this Discuss. I think the answers initially need to come from the responsible AD, but there may be subsequent text changes needed. I am worried that the lack of clarity on the two points of my Discuss have affected the level of IETF review and consensus for publication achieved during last call. Also, depending on the answers, I will need to do a different type of review. I should note that I have no fundamental objection to this work. --- This document presumably obsoletes RFC 6179. It should be marked as such; there should be a note to that effect in the Abstract and the Introduction; there should be a section explaining the differences from RFC 6179. --- RFC 6179 was Experimental on the IRTF Stream. If this document is intended as Informational, I should like to see a statement about why it is so positioned. Perhaps it was really intended as Experimental, but if so, I would like to see the parameters of the experiment.
Brian Haberman Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2013-02-20 for -12)
Unknown
Color me concerned about publishing this document as anything other than a mechanism being used by a single network. I agree with Pete's commentary on this needing some level of consensus within the IETF, especially given its relationship with LISP, before publishing it.
Stewart Bryant Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2013-02-18 for -12)
Unknown
This is a discuss is initially directed at the responsible Area Director. It would really help if it was made clear what, if any, changes have been made to this draft since it was last published as an RFC. I would like to understand why we are publishing this as an informational on the independent stream? This seems like a small increment when we might better conserve out publishing resources by waiting to see if it gets sufficient traction to justify advancement to a WG document of some sort. I am also concerned about moving this to informational given that we have work in the LISP WG that is publishing at experimental - i.e. this seems like an end run on chartered IETF work.
Ralph Droms Former IESG member
Yes
Yes
(for -12)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -12)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -12)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(2013-02-21 for -12)
Unknown
I am also concerned about publishing this document, but the other ballots cover my concerns already.
Stephen Farrell Former IESG member
No Objection
No Objection
(2013-02-19 for -12)
Unknown
- I agree with Stewart's discuss - the relationship between this and RFC 6179 is very unclear to me and it seems plain odd to re-use lots of the text and the acronym with s/Internet/Intraadomain/ and yet not obsolete 6179, so colour me confused. - p16 talks about SEAL signatures, but those are only 32 bit so-far undefined check values (since I've a DISCUSS on SEAL for that no need for another here). If SEAL ICVs stay at 32 bits, then this wouldn't really be a good plan I suspect. - p34, I can't see where the format etc. for signed SRS or SRA messages is defined. (Nor the unsigned definition either.) - p34, same comment about SAVI as I had for SEAL, since SAVI is only defined for LANs this just seems like a bad reference
Wesley Eddy Former IESG member
No Objection
No Objection
(for -12)
Unknown
Pete Resnick Former IESG member
Abstain
Abstain
(2013-02-20 for -12)
Unknown
(This is basically a repeat of my position on the SEAL document) I agree with the DISCUSS positions. I'm willing to have the DISUCSSion, but at the end of the day I think we need to say "No thanks" to having this in the IETF stream. The fact is that there is no indication of any consensus in the IETF to move forward with this experimentally; there is no indication that anyone will participate in the experiment. It sounds to me like this work needs to garner a constituency, and it sounds like we would have to figure out where it fits with other protocols (i.e., if it's competing with the or complementary to them). That requires a BOF, not an IETF Last Call and IESG Evaluation. I don't think we should be in the business of publishing things in the IETF stream *in order to* garner interest. It sounds from other comments like this is interesting work. It seems a shame not to have the IETF do work on this. But until there is demonstrated interest, I don't think this belongs in the IETF stream. Having the ISE publish as Experimental (or having the IRTF again take it on) seems reasonable.
Ron Bonica Former IESG member
Abstain
Abstain
(for -12)
Unknown