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

From: "Susan Hares" <[email-masked]>
Date: Thu, 21 Apr 2016 14:57:10 -0400

Spencer: 

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

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

-----

Spencer: 

Does adding this text as a subsequent paragraph resolve your comment?  

The transports that the I2RS protocol can run over will be specified in the 

I2RS protocol, and in the I2RS protocol each transport protocol

as either mandatory to implement or optional to implement.

Sue

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 21 Apr 2016 15:05:17 -0500

Hi, Susan,

On Thu, Apr 21, 2016 at 1:57 PM, Susan Hares <[email-masked]> wrote:

> 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
>
> https://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/
>
>
>
>
>
>
>
> 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.
>
>
>
> -----
>
> Spencer:
>
>
>

That's fine. If I'm still an AD when the protocol shows up, I'll probably
look at how many transport protocols are specified, but letting the working
group spend more time figuring out what makes sense to them is very
reasonable.

Thanks!

Spencer