Subject: [sacm] Spencer Dawkins' No Objection on draft-ietf-sacm-requirements-16: (with COMMENT)

From: Spencer Dawkins <[email-masked]>
Date: Mon, 19 Jun 2017 11:46:32 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-sacm-requirements-16: 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-sacm-requirements/

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

I'm following along with Mirja's Abstain, although I'm balloting No Objection.

I'm looking at

T-005  Transport Reliability: SACM transfer protocols MUST provide
    reliable delivery of data.  This includes the ability to perform
    fragmentation and reassembly, and to detect replays.  The SACM
    transfer may take advantage of reliability features in the network
    transport; however, the network transport may be unreliable (e.g.
    UDP), in which case the SACM transport running over the unreliable
    network transport is responsible for ensuring reliability (i.e. by
    provisions such as confirmations and re-transmits).

and wondering why you'd want to run SACM transfer protocols over UDP in the
first place (and, assuming there's a fabulous reason to do that, why you
wouldn't run those protocols over UDP in all cases).

This is a No Objection position, but please recognize that these protocols
would be simpler if they were running over TCP.

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 21 Jun 2017 22:23:42 -0400

Hi Spencer,

Just one comment inline to help with your question on UDP.

> https://datatracker.ietf.org/doc/draft-ietf-sacm-requirements/

If the data model is a mib (accessing information about
system/device), then the transport is UDP, if it is YANG, then TCP,
etc.  The transport depends on the data model and established
transport (if there is one and they plan to re-use when possible).

Thanks for your review!

-- 

Best regards,
Kathleen

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 22 Jun 2017 07:44:25 -0500

Hi, Kathleen,

> transport (if there is one and they plan to re-use when possible).

This is very helpful.

After reading Alissa and Benoit's positions, I wonder if it's not better to
either

   - s/transport/transfer/g, so it's obvious that none of the references
   are to a classic transport protocol, or
   - drop this requirement as a NO-OP

but I know that you folks will Do The Right Thing :-) ...

Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 22 Jun 2017 07:49:43 -0500

And, of course ...

On Thu, Jun 22, 2017 at 7:44 AM, Spencer Dawkins at IETF <
[email-masked]> wrote:

> After reading Alissa and Benoit's positions, I wonder if it's not better
> to either
>

I'm blowing through last night's telechat e-mails and didn't see Alexey's
ballot before sending this. He's saying s/transport/transfer/g, which works
for me.

Thanks,

Spencer

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Sun, 25 Jun 2017 22:46:54 +0000

Thanks to everyone for the reviews and feedback.  I am working on the updates now….

As for this one (and in response to Alexey)….indeed we mean “transfer” so will be doing the
Substitution in the next revision as suggested.

     Nancy

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thursday, June 22, 2017 at 5:49 AM
To: Kathleen Moriarty <[email-masked]>
Cc: The IESG <[email-masked]>, "<[email-masked]>" <[email-masked]>, "[email-masked]" <[email-masked]>, Karen O'Donoghue <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Spencer Dawkins' No Objection on draft-ietf-sacm-requirements-16: (with COMMENT)
Resent-From: <[email-masked]>
Resent-To: "[email-masked]" <[email-masked]>, <[email-masked]>
Resent-Date: Thursday, June 22, 2017 at 5:49 AM

And, of course ...

On Thu, Jun 22, 2017 at 7:44 AM, Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Kathleen,

On Wed, Jun 21, 2017 at 9:23 PM, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:
Hi Spencer,

This is very helpful.

After reading Alissa and Benoit's positions, I wonder if it's not better to either

  *   s/transport/transfer/g, so it's obvious that none of the references are to a classic transport protocol, or
  *   drop this requirement as a NO-OP
but I know that you folks will Do The Right Thing :-) ...

I'm blowing through last night's telechat e-mails and didn't see Alexey's ballot before sending this. He's saying s/transport/transfer/g, which works for me.

Thanks,

Spencer