The Interior Routing Overlay Network (IRON)
draft-templin-ironbis-16

Summary: Needs a YES.

Alvaro Retana No Record

Benjamin Kaduk No Record

Erik Kline No Record

Francesca Palombini No Record

John Scudder No Record

Lars Eggert No Record

Martin Duke No Record

Martin Vigoureux No Record

Murray Kucherawy No Record

Robert Wilton No Record

Roman Danyliw No Record

Warren Kumari No Record

Zaheduzzaman Sarker No Record

Éric Vyncke No Record

(Adrian Farrel; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2013-02-20 for -12)
No email
send info
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 steering group member) Discuss

Discuss [Treat as non-blocking comment] (2013-02-20 for -12)
No email
send info
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 steering group member) Discuss

Discuss [Treat as non-blocking comment] (2013-02-18 for -12)
No email
send info
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 steering group member) Yes

Yes ( for -12)
No email
send info

(Barry Leiba; former steering group member) No Objection

No Objection ( for -12)
No email
send info

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -12)
No email
send info

(Martin Stiemerling; former steering group member) No Objection

No Objection (2013-02-21 for -12)
No email
send info
I am also concerned about publishing this document, but the other ballots cover my concerns already.

(Stephen Farrell; former steering group member) No Objection

No Objection (2013-02-19 for -12)
No email
send info
- 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 steering group member) No Objection

No Objection ( for -12)
No email
send info

(Pete Resnick; former steering group member) Abstain

Abstain (2013-02-20 for -12)
No email
send info
(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 steering group member) Abstain

Abstain ( for -12)
No email
send info