IETF conflict review for draft-cisco-sla-protocol
conflict-review-cisco-sla-protocol-00
Yes
No Objection
(Barry Leiba)
(Pete Resnick)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
Recuse
(Stewart Bryant)
Note: This ballot was opened for revision 00 and is now closed.
Ballot question: "Is this the correct conflict review response?"
Wesley Eddy Former IESG member
Yes
Yes
(2012-10-11)
Unknown
In reviewing this document, IANA raised a number of questions: 1. In the Version Number Registry, it says "Version for protocol in this document" for version 2. This should be replaced by what it should actually say in the registry. 2. There are a few ranges in the proposed registries that say "2048+" for example. Does this mean that there are an infinite amount of numbers? 3. There are no registration procedures defined in this document. Each registry needs defined registration procedures so that we know what process to follow. 4. What is the expected load for this registry? As this is not an IETF created registry, we would like to anticipate the load on IANA resources.
Adrian Farrel Former IESG member
(was Discuss)
No Objection
No Objection
(2012-08-30)
Unknown
Wes and I will work on a communication with the ISE proposing either action by the authors or an IESG note that notes the existence of IETF Standards Track solutions in this space.
Barry Leiba Former IESG member
No Objection
No Objection
()
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(2012-08-28)
Unknown
I agree with Wes' suggestion of including text about the existing IPPM work.
Pete Resnick Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
No Objection
No Objection
()
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2012-08-30)
Unknown
A few comments that you can take or leave as you see fit. - 2nd last para of section 1: is "simulates" right there? - p7, I didn't get what this means in the last diagram on the page: "This field MAY be used for secure environment" There seem to be a few statements like that, and I think they're not as clear as they could be, but it becomes clear when I read section 3 later. - p19, is the security for the sha-256 mode based on sha256(secret||message)? If so, then you are maybe vulnerable to a hash continuation attack and might want to think about that and/or note it in the security considerations. (I'm not sure why you even keep that mode given that you have HMAC.) - I'm not sure why IANA are needed to maintain registries for a Cisco proprietary protocol. Might be no great harm, but surely Cisco have sufficient self-control to prevent collisions? (If 10,000 companies all did this it might be a DoS on IANA but 10,000 companies don't do this so I'm not concerned about that.)
Stewart Bryant Former IESG member
(was Abstain)
Recuse
Recuse
()
Unknown