Subject: Re: [sacm] AD review of Requirements draft

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 6 Jan 2017 14:35:54 -0500

Hi Nancy,

Happy new year!  Thanks for your detailed response. inline

On Wed, Dec 28, 2016 at 1:36 AM, Nancy Cam-Winget (ncamwing) <
[email-masked]> wrote:

> Hi Kathleen,
>
> Many thanks for the thorough review, I’ve made updates (and uploaded
> version 15) based on comments below:
>
> From: sacm <[email-masked]> on behalf of Kathleen Moriarty <
> [email-masked]>
> Date: Thursday, December 8, 2016 at 12:50 PM
> To: "[email-masked]" <[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:
>
> 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].
> [NCW] Done in –15.
>
> Thank you.

>
> Bullet 2, recommend removing the second sentence:
>        This is what we want to
>        know about a target endpoint.
> [NCW] Done in –15.
>

Thank you.

>
> 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:"
> [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).
>

OK, thanks for the clarification.  This will help if any discussions come
up in IESG review.

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

Thank you.

>
> 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/
> [NCW] Done in –15.
>

Thank you.

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

OK, I'll review version 15 before we move it to IETF last call for this
specifically.

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

The index value, assuming one is in the data model, will have specific
privacy considerations per RFC6973.  It would be good to call that out in
the requirements - care taken with index value, etc.   Take a look at 6973
and maybe derive text from that?

> 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:
> [NCW] Thanks!  This reads much better.
>

Great, thanks!

>
>
> 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.
> [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?
>

Thank you and yes, it should be transfer.

>
>
> 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.
> [NCW] I think the WG wanted me to add examples, but I’ve removed them for
> now and see if the WG has objections.
>
> Thank you.

>
> 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:
>
> 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."
> [NCW] Done in -15
>

Thank you.

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

Yes, that's what I meant and sounds good.  Thank you!

Please let me know when you have version 15 posted for review and when you
think it's ready for IETF last call.

Thank you,
Kathleen

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