Subject: [i2rs] Spencer Dawkins' No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 16 Mar 2016 22:07:31 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-i2rs-architecture-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In this text:

7.1.  One Control and Data Exchange Protocol

   The I2RS
   protocol may need to use several underlying transports (TCP, SCTP
   (stream control transport protocol), DCCP (Datagram Congestion
   Control Protocol)), with suitable authentication and integrity
   protection mechanisms.  These different transports can support
   different types of communication (e.g. control, reading,
   notifications, and information collection) and different sets of
   data.  Whatever transport is used for the data exchange, it must also
   support suitable congestion control mechanisms.  The transports
   chosen should be operator and implementor friendly to ease adoption.
   
I echo Benoit's question about defining multiple underlying transports. I
suspect you'll need to pick one mandatory-to-implement transport
protocol, and when everyone has to support that one, I'd be surprised to
see implementations that support more than one transport protocol unless
the mandatory-to-implement transport protocol is seriously broken in some
scenarios.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 17 Mar 2016 08:14:41 -0400

Spencer: 

Thank you for your comments.  Perhaps a bit of context will help --- 

I2RS WG goal is not to create new protocols, but to re-use and extend existing protocols.  This creates a bit if a different flow in the document path.   The architecture design allows for multiple protocols (NETCONF, RESTCONF, and others) with multiple encodings (XML, JSON) so that the WG could work through these protocols.  However, in any particular version of the protocol will have:
a) a set of requirements for features, 
b) set of valid application protocols (e.g. NETCONF, RESTCONF) with specific features (E.g. ephemeral state, publication/subscription service, traceability, insecure data)
c)  a set of valid transport protocols (TLS, SSH, HTTP) that transport the application,
d) a set of valid protocol security mechanisms, 
e) recommendations for security environment, and 
f) data models supported by the protocol. 

We are currently finalizing the requirements for version 1 with the protocol strawman released this week for extensions to NETCONF/RESTCONF.  

Sue 

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]] 
Sent: Thursday, March 17, 2016 1:08 AM
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Spencer Dawkins' No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

In this text:

   The I2RS
   
I echo Benoit's question about defining multiple underlying transports. I suspect you'll need to pick one mandatory-to-implement transport protocol, and when everyone has to support that one, I'd be surprised to see implementations that support more than one transport protocol unless the mandatory-to-implement transport protocol is seriously broken in some scenarios.