Subject: [sacm] AD review of Requirements draft

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 8 Dec 2016 15:50:37 -0500

Hello,

Thank you all for your work on the requirements draft.  It is clear a lot
of work went into this and I know in my review I am bringing back up at
least one item that the WG discussed, but think it's necessary prior to
IESG review.  The document looks very good, despite the length of my
review.  The comments are intended to help improve the document prior to
IETF last call and IESG review.  Thank you for researching and adding the
privacy considerations, most of the topics that needed to be covered are
and that was very helpful.  I just found a few more from experience of
reviewing lots of drafts and reading other reviews.  It does look good
overall though.  I tried to provide proposed text where I could to make
things easier, but feel free to discuss or propose alternate text.  Let's
discuss if there are any questions on my comments.

Thank you!

SACM Requirements Draft:

Edit suggestion for the first sentence of section 2.  Requirements:

OLD:
   This document defines requirements based on the SACM use cases
   defined in [RFC7632].
NEW:
   This document defines requirements based on the SACM use cases
   described in [RFC7632].

Bullet 2, recommend removing the second sentence:
       This is what we want to
       know about a target endpoint.

I see this requirement and question if you are looking for this capability
for all defined models (that's how I read it) or just for the documentation
to detail how this is provided or reasons why it is not necessary.  I would
think the latter might be better for IoT.
    "G-003  Scalability: SACM needs to support a broad set of deployment
    scenarios.  The data models, protocols, and transports MUST be
    scalable unless they are specifically defined to apply to a special-
    purpose scenario, such as constrained devices.  A SACM transport
    protocol standard SHOULD include a section on scalability
    considerations that addresses the number of endpoints and amount of
    information to which it can reasonably be expected to scale.
    Scalability must be addressed to support:"

Requirement G-004 - Do you mean that multiple transports are acceptable and
they may vary depending on deployment scenarios?  I think that's what was
meant, but am not reading that with the current wording.

Current text:
OLD:
    G-004  Versatility: The data model, protocols, and transports MUST be
    suitably specified to enable implementations to fit into different
    deployment models and scenarios, including considerations for
    implementations of data models and transports operating in
    constrained environments.

Proposed NEW (but it's fine if you re-word and find a way to fit into the
first sentence):
    G-004  Versatility: The data model, protocols, and transports MUST be
    suitably specified to enable implementations to fit into different
    deployment models and scenarios, including considerations for
    implementations of data models and transports operating in
    constrained environments.  Separate solutions may be necessary to meet
    the needs of specific deployment models and scenarios.

Requirement G-006:  suggest s/proxies/middle boxes/

Arch-008: This needs to have a privacy consideration listed here or in the
privacy considerations or both.  Being able to correlate based on an
identifier is a common privacy issue, but when you couple it with time
stamps, there is a lot more that can be lean red about patterns of users of
those systems (IoT or computing).

Section 2.3, IM-001 leaves me wondering what the common elements might be
and has me assuming an index value that serves as an identifier is likely
present and will require privacy considerations.  Can you elaborate to see
if we need to put considerations here or just in a privacy related section?

Section 2.6:
The wording in the introduction is confusing and some of it isn't really
correct.  As such, I pulled out the big guns and asked the transport ADs
what they thought.  TCP/IP and TLS shouldn't be lumped as equivalent and
the terms transport, application transport, transfer, or even substrate
have been used to distinguish some of the layers that are important.  I
have some suggestions for the introduction as well as the requirements.
The transport ADs may have more tweaks when it it in IESG review.

Current text:
2.6.  Requirements for SACM Transport Protocols

   The term transport protocol is frequently overloaded.  The term SACM
   transport protocol is intended to be distinguished from underlying
   layer 3 and 4 protocols such as TCP/IP and TLS.  However, it is
   possible that a layer 3 or 4 protocol may be used as a SACM transport
   protocol, either alone or as part of a SACM transport protocol (i.e.
   using HTTP over TLS with XML as the content).  The SACM transport
   protocol is focused on moving data and performing necessary access
   control operations; it is agnostic to the data model operations.

   The requirements for SACM transport protocols include:

Proposed text:
2.6.  Requirements for SACM Transfer Protocols

   The term SACM
   transfer protocol is intended to be distinguished from underlying
   layer 3 and 4 protocols such as TCP/IP, operating at an equivalent level
as the hyperText transfer protocol (HTTP).    The SACM transfer
   protocol is focused on moving data and performing necessary access
   control operations; it is agnostic to the data model operations.

   The requirements for SACM transfer protocols include:

The following requirement is really tough to read, so I'm proposing some
text:

OLD:
    T-001  Multiple Transport Protocol Support: SACM transport protocols
    MUST support different network transport protocols in a deployment
    to support different transport layer requirements, different device
    capabilities, and system configurations dealing with connectivity.

NEW:
    T-001  Multiple Transfer Protocol Support: SACM transfer protocols
    will vary depending on the deployment model that relies on
    different transport layer requirements, different device
    capabilities, and system configurations dealing with connectivity.

Note: I'm really hesitant to leave the MUST in as there will be use cases
that just deal with one deployment model.  In that case, multiple protocols
really don't need to be supported as far as I can see.

T-002 - s/transport/transfer/
T-003 - s/transport/transfer/g
T-004 - s/transport/transfer/  and shouldn't origin authentication be
covered too?

T-005
OLD:
T-005  Transport Reliability: SACM transport protocols MUST provide
    reliable delivery of data.  This includes the ability to perform
    fragmentation and reassembly, and to detect replays.  The SACM
    transport 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).
NEW:
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
    transport 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 transfer protocol running over the
unreliable
    network transport is responsible for ensuring reliability (i.e. by
    provisions such as confirmations and re-transmits).

T-006, I would suggest dropping the example as it may lead to unnecessary
discussions.  If the WG chooses to do some of the things described in the
examples, then there may be debates at that time in regard to end-to-end
protections.

OLD:
   T-006  Transport Layer Requirements: Each SACM transport protocol
    MUST clearly specify the transport layer requirements it needs to
    operate correctly.  Examples of items that may need to be specified
    include connectivity requirements, replay requirements, data link
    encryption requirements, and/or channel binding requirements.  These
    requirements are needed in order for deployments to be done
    correctly.  For example, a proxy server between UDP and TCP can
    provide a connection that correctly fulfills the connectivity and
    replay requirements as well as data link requirements (through the
    use of TLS and DTLS) but would be unable to provide a channel
    binding requirement, as that implies there is no MITM to look at the
    data.

NEW:
   T-006  Transfer Layer Requirements: Each SACM transfer protocol
    MUST clearly specify the requirements it needs to
    operate correctly.  Examples of items that may need to be specified
    include connectivity requirements, replay requirements, data link
    encryption requirements, and/or channel binding requirements.  These
    requirements are needed in order for deployments to be done
    correctly.

I see transport shows up in a few other places in the document, please
review and edit as needed (security considerations, etc.).

Security considerations:

First sentence, consider changing from:
OLD:
   This document defines the requirements for SACM.  As such, it is
   expected that several data models, protocols, and transports may be
   defined or reused from already existing standards.
NEW:
   This document defines the requirements for SACM.  As such, it is
   expected that several data models, protocols, and transfer protocols may
be
   defined or reused from existing standards.

I would leave out the following two sentences as architecture
considerations would be in an architecture document.  As I read through the
section, I'll keep in mind dropping these sentences in case it results in
suggestions to change text.

drop:
   "This section will
   highlight security considerations that may apply to SACM based on the
   architecture and standards applied in SACM.  In particular,
   highlights to security considerations that may apply to the SACM
   reference architecture and standard data models and transports will
   be discussed."

Section 5.2

I had made notes above and after reading the privacy consideration section
think the specific items should be called out in the requirements since
privacy will be a major consideration for SACM developers and implementors.

In this section, there should be a sentence added to talk about identifiers
being protected as they can be used to link data to other data, people, and
devices.  By other data - I just mean that multiple pieces of data can be
linked to people or devices.  There should be a mention of providing
privacy by leaving out privacy sensitive information that might include
personally identifiable information or identifiers.  Roles can be used in
place of identifying information for an individual in that role for
instance.

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 21 Dec 2016 13:47:01 -0500

Hi,

I haven't seen a response yet to the AD review.  Please let me know if you
have any questions.

Thank you,
Kathleen

On Thu, Dec 8, 2016 at 3:50 PM, Kathleen Moriarty <
[email-masked]> wrote:

> Requirement G-004 - Do you mean that multiple transports are acceptable
> and they may vary depending on deployment scenarios?  I think that's what
> was meant, but am not reading that with the current wording.
>
> Current text:
> OLD:
>    layer 3 and 4 protocols such as TCP/IP, operating at an equivalent
> level as the hyperText transfer protocol (HTTP).    The SACM transfer
>    expected that several data models, protocols, and transfer protocols
> may be
> In this section, there should be a sentence added to talk about
> identifiers being protected as they can be used to link data to other data,
> people, and devices.  By other data - I just mean that multiple pieces of
> data can be linked to people or devices.  There should be a mention of
> providing privacy by leaving out privacy sensitive information that might
> include personally identifiable information or identifiers.  Roles can be
> used in place of identifying information for an individual in that role for
> instance.
>
> --
>
> Best regards,
> Kathleen
>

-- 

Best regards,
Kathleen

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Wed, 28 Dec 2016 06:36:11 +0000

Hi Kathleen,

Many thanks for the thorough review, I’ve made updates (and uploaded version 15) based on comments below:

From: sacm <[email-masked]<mailto:[email-masked]>> on behalf of Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>
Date: Thursday, December 8, 2016 at 12:50 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [sacm] AD review of Requirements draft

Hello,

Thank you all for your work on the requirements draft.  It is clear a lot of work went into this and I know in my review I am bringing back up at least one item that the WG discussed, but think it's necessary prior to IESG review.  The document looks very good, despite the length of my review.  The comments are intended to help improve the document prior to IETF last call and IESG review.  Thank you for researching and adding the privacy considerations, most of the topics that needed to be covered are and that was very helpful.  I just found a few more from experience of reviewing lots of drafts and reading other reviews.  It does look good overall though.  I tried to provide proposed text where I could to make things easier, but feel free to discuss or propose alternate text.  Let's discuss if there are any questions on my comments.

Thank you!

SACM Requirements Draft:

OLD:
[NCW] Done in –15.

[NCW] Done in –15.

I see this requirement and question if you are looking for this capability for all defined models (that's how I read it) or just for the documentation to detail how this is provided or reasons why it is not necessary.  I would think the latter might be better for IoT.
[NCW] We didn’t want to exclude IoT especially as target endpoints in an enterprise could begin to start including constrained devices.  Although, at the time we placed the requirement we strictly said it would be for the “classical” IT enterprise. The intent was to ensure that the information and data models model MUST be scalable, but recognized that transports can vary in performance/scalability.  So having the section on scalability considerations was called out for documenting the boundaries of scalability (or lack thereof).

Requirement G-004 - Do you mean that multiple transports are acceptable and they may vary depending on deployment scenarios?  I think that's what was meant, but am not reading that with the current wording.
[NCW] Yes, that is the intent and I like your suggested addition which will be in –15.

Current text:
OLD:

Proposed NEW (but it's fine if you re-word and find a way to fit into the first sentence):

[NCW] Done in –15.

Arch-008: This needs to have a privacy consideration listed here or in the privacy considerations or both.  Being able to correlate based on an identifier is a common privacy issue, but when you couple it with time stamps, there is a lot more that can be lean red about patterns of users of those systems (IoT or computing).
[NCW] I’ve added the consideration of time stamps in behavioral trends to the Privacy section; wasn’t sure how to fold it into the requirement but did list it in the privacy considerations.

Section 2.3, IM-001 leaves me wondering what the common elements might be and has me assuming an index value that serves as an identifier is likely present and will require privacy considerations.  Can you elaborate to see if we need to put considerations here or just in a privacy related section?
[NCW] Not sure what you mean wrt to privacy considerations?  Do you mean for each attribute defined in IM (or the minimum set)?
We still haven’t defined that minimum set….and I think we still have those that believe there can be more than 1 SACM data model?

Section 2.6:
The wording in the introduction is confusing and some of it isn't really correct.  As such, I pulled out the big guns and asked the transport ADs what they thought.  TCP/IP and TLS shouldn't be lumped as equivalent and the terms transport, application transport, transfer, or even substrate have been used to distinguish some of the layers that are important.  I have some suggestions for the introduction as well as the requirements.  The transport ADs may have more tweaks when it it in IESG review.

Current text:

Proposed text:

   The term SACM
   transfer protocol is intended to be distinguished from underlying
   layer 3 and 4 protocols such as TCP/IP, operating at an equivalent level as the hyperText transfer protocol (HTTP).    The SACM transfer
   protocol is focused on moving data and performing necessary access
   control operations; it is agnostic to the data model operations.

   The requirements for SACM transfer protocols include:
[NCW] Thanks!  This reads much better.

The following requirement is really tough to read, so I'm proposing some text:

OLD:

NEW:

Note: I'm really hesitant to leave the MUST in as there will be use cases that just deal with one deployment model.  In that case, multiple protocols really don't need to be supported as far as I can see.
[NCW] I think that is fine. Though you have changed “transport” to “transfer”, that means the whole section is about “transfer” and should change all references as such?

T-002 - s/transport/transfer/
T-003 - s/transport/transfer/g
T-004 - s/transport/transfer/  and shouldn't origin authentication be covered too?

T-005
OLD:
    UDP), in which case the SACM transfer protocol running over the unreliable

T-006, I would suggest dropping the example as it may lead to unnecessary discussions.  If the WG chooses to do some of the things described in the examples, then there may be debates at that time in regard to end-to-end protections.

OLD:

NEW:
[NCW] I think the WG wanted me to add examples, but I’ve removed them for now and see if the WG has objections.

I see transport shows up in a few other places in the document, please review and edit as needed (security considerations, etc.).
[NCW] I haven’t done them all and wasn’t sure whether you wanted SACM transfer all over vs. SACM transport?

Security considerations:

   expected that several data models, protocols, and transfer protocols may be

I would leave out the following two sentences as architecture considerations would be in an architecture document.  As I read through the section, I'll keep in mind dropping these sentences in case it results in suggestions to change text.

drop:
   "This section will
[NCW] Done in -15

Section 5.2

I had made notes above and after reading the privacy consideration section think the specific items should be called out in the requirements since privacy will be a major consideration for SACM developers and implementors.
[NCW] Not sure what you mean….I may be adding the same text in the requirements, would that be acceptable?

In this section, there should be a sentence added to talk about identifiers being protected as they can be used to link data to other data, people, and devices.  By other data - I just mean that multiple pieces of data can be linked to people or devices.  There should be a mention of providing privacy by leaving out privacy sensitive information that might include personally identifiable information or identifiers.  Roles can be used in place of identifying information for an individual in that role for instance.

--

Best regards,
Kathleen