The Subnetwork Encapsulation and Adaptation Layer (SEAL)
draft-templin-intarea-seal-68
Discuss
Yes
(Ralph Droms)
No Objection
(Barry Leiba)
(Gonzalo Camarillo)
(Russ Housley)
(Wesley Eddy)
Abstain
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
Benoît Claise Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2013-02-20 for -51)
Unknown
While I believe there is some value in publishing this specification, I agree with Brian:
If the author insists on maintaining the Informational status,
I would suggest a title change to indicate that this is description
of Boeing-developed protocol. Otherwise, I suggest moving it
Experimental like the RFC it is obsoleting.
Existing examples: RFC 3176, RFC 3954, RFC 6812
Brian Haberman Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2013-02-19 for -51)
Unknown
I have no objections to the *concepts* developed in this draft, but I have a major concern with the way it is specified. So color me as wanting to discuss the following issues: 1) At this point, I believe it is not in the best interest of the Internet at-large to allocate an IP protocol number to what appears to be an experimental mechanism used only within the confines of a single enterprise. The author has made many attempts to drum up support for this concept over the years, but it is apparent that vendors are not interested in building this technology into their products. The current implementation leverages one of the experimental IP protocol numbers available for such use. 2) If the author insists on maintaining the Informational status, I would suggest a title change to indicate that this is description of Boeing-developed protocol. Otherwise, I suggest moving it Experimental like the RFC it is obsoleting.
Stephen Farrell Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2013-02-18 for -51)
Unknown
I read this fairly quickly so I may have gotten some of this wrong, in which case, apologies;-) (1) I don't see anywhere that the ICV algorithm is defined, nor where any automated key management is discussed, and I think the AKM is needed given the 32 bit ICV. What am I missing? I think that needs to be fixed and is simple to fix properly by selecting an HMAC-SHA-x at some reasonable length (96 bits) and maybe picking either TLS or IPsec as being needed for setting up ITE/ETE security associations, but with a 96 bit ICV you're probably ok for an informational/experimental draft without AKM. To be honest, that lack sends me a big signal that this isn't ready even after 51 revisions if it doesn't include those are by now pretty basic things. (2) Should we really burn an IP protocol number on this? I've no strong opinion but they are >50% gone and this seems tenuous and I'm not even sure the IP protocol number is really needed if TCP and UDP can be used as outer encapsulations. I'll readily clear this though if someone explains to me that this draft is par for the course in terms of getting an IP protocol number.
Stewart Bryant Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2013-02-20 for -51)
Unknown
This is a discuss for discussion with the IESG. I anticipate clearing on the call. I agree with the other IESG review comments and support Brian's discuss. I addition, this work seems to have a lot of overlap with LISP which is an IETG WG project. I think that the least it should do is to discuss LISP, but I am wondering whether the IESG should consider this as an end-run of IETF work.
Ralph Droms Former IESG member
Yes
Yes
(for -42)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2013-02-20 for -51)
Unknown
I agree with Brian's Discuss. If this is Informational then it needs to be shaped as a description of a particular company's protocol. It would then be published to allow others to implement and interoperate if they want. If this moves to Experimental (which seems better to me) it should describe the parameters of the experiment.
Barry Leiba Former IESG member
No Objection
No Objection
(for -51)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -51)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(2013-02-21 for -51)
Unknown
Balloting no objection, but I support Brian's discuss and share the other IESG reviews.
Russ Housley Former IESG member
No Objection
No Objection
(for -51)
Unknown
Wesley Eddy Former IESG member
No Objection
No Objection
(for -51)
Unknown
Pete Resnick Former IESG member
Abstain
Abstain
(2013-02-20 for -51)
Unknown
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 again seems reasonable, and I don't think that the fact the this potentially competes with LISP should preclude that.
Ron Bonica Former IESG member
Abstain
Abstain
(2013-02-19 for -51)
Unknown
I agree with Brian's discuss, but am abstaining because I don't want to leave the DISCUSS with my successor.