IETF conflict review for draft-cisco-sla-protocol
conflict-review-cisco-sla-protocol-00

The following approval message was sent
From: The IESG
To: "Nevil Brownlee" , draft-cisco-sla-protocol@tools.ietf.org, rfc-ise@rfc-editor.org
Cc: The IESG , , 
Subject: Results of IETF-conflict review for draft-cisco-sla-protocol-03

The IESG has completed a review of draft-cisco-sla-protocol-03 consistent
with RFC5742.

The IESG has no problem with the publication of 'Cisco Service Level
Assurance Protocol'  as an Informational
RFC.

The IESG has concluded that this work is related to IETF work done in WG IP
Performance Metrics (IPPM), but this relationship does not prevent
publishing

The IESG would also like the RFC-Editor to review the comments in the
datatracker related to this document and determine whether or not they
merit incorporation into the document. Comments may exist in both the
ballot and the history log.

The IESG review is documented at:
http://datatracker.ietf.org/doc/conflict-review-cisco-sla-protocol/

A URL of the reviewed Internet Draft is:
http://datatracker.ietf.org/doc/draft-cisco-sla-protocol/

The process for such documents is described at
http://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot comment]
  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.

[Ballot comment]
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.

[Ballot comment]

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.)

[Ballot discuss]
This is for Discussion with the IESG on the telechat - no action is requested of the authors or the ISE at this stage.

- - - - - -

I agree with the issue that Wes has highlighted and I would be hopeful that the authors would work with the ISE to include such text. However, as is always the case with Independent Stream publications, we can only ask.

Wouldn't it be better to supplement the request with a request to include an IESG note on this document pointing to explicit standards track RFCs for TWAMP etc and saying that the IESG recommends the use of IETF standards track protocols?

[Ballot comment]
This document describes a test and measurement protocol similar in functionality to the OWAMP and TWAMP protocols developed in the IETF IPPM working group, which are Standards Track IETF specifications with existing implementations and deployment in the Internet.

As the protocol described in this document also has been implemented and used, it seems to me that it would be beneficial to the community and to readers to at least have some text that acknowledges those IPPM protocols and gives a brief comparison/contrast to summarize how this differs and why it's been developed and deployed by Cisco.