Re: [Insipid] AD Evaluation of draft-ietf-insipid-session-id-22

Authors, any thoughts on these?

Thanks!

Ben.

On 14 May 2016, at 19:46, Ben Campbell wrote:

> Hi,
>
> This is my AD Evaluation of draft-ietf-insipid-session-id-22. I have a
> number of comments, and think that at least the "substantive" comments
> should be addressed prior to IETF last call.
>
> Thanks!
>
> Ben.
>
> ------------- Substantive Comments:
>
> - Abstract: The abstract makes it sound like the draft is
> multi-protocol. It's not, it's SIP specific. I recognize the idea is
> that the syntax could be used across signaling protocols, but this
> particular draft only defines how to do so for SIP. Please clarify.
>
> - General
>
> - 4.1, 2nd paragraph: Why is the requirement for version 4 or 5 UUIDs
> only a SHOULD? It seems like we should really avoid any sort of
> persistent identifies in the UUID. If we really need the SHOULD, please
> describe when it might be reasonable to choose otherwise.
>
> - 4.2, 2nd paragraph: "such as when a UA first initiates a SIP request,"
>
> Should that be a SIP INVITE request, or SIP dialog-initiating request?
>
> -- 2nd to last paragraph: Is there a normative statement elsewhere than
> devices other than conference-focuses MUST NOT reuse UUIDs? (Also, the
> MUST in this paragraph belongs with the section on MDUs. If this text
> means to simply point out that the MDU section has this requirement,
> then please state it descriptively here.)
>
> -- last paragraph: I'm a bit uncomfortable with making storage
> completely out of scope, due to the potential "information-at-rest"
> security or privacy implications. (I note that RFC7206 cites 6872 for
> this purpose).
>
> - 6, paragraph 8: Has the working group discussed the privacy
> implications of requiring an endpoint to keep the same UUID after a
> redirect, refer, or INVITE-with-replaces? It may be that the peer and
> intermediaries already know the source of the 2nd dialog is the same
> that of the first, but I think it's a topic that needs some mention in
> the text.
>
> -- paragraph 10: Both the MAY and MUST seem incorrect here. The MAY is a
> statement of fact, and the MUST is a description of rules elsewhere in
> the draft. I suggest using descriptive language for both.
>
> -7, first paragraph: Does the assumption of no "special treatment" means
> the intermediary  passing the session-id unchanged? Removes it? Either?
>
> -- 4th paragraph: What happens when a B2BUA that does not implement
> session-id aggregates responses? If it passes through the peer UUIDs
> unchanged, does anything break? Can the UAC be misled about the UUID of
> the resulting peer?
>
> -- 3rd paragraph from end: I'm confused by "A non- redirected or
> rejected response", since responses neither get redirected or rejected.
> Do you mean a redirection response or a rejection response? (Perhaps
> using response code classes would be more clear.)
>
> "MUST replace its own UUID" - In what message(s)?
>
> -- 2nd to last paragraph: Why are the SHOULDs not MUSTs? Can you
> describe situations in which one might reasonably not follow the
> SHOULDs?
>
> -- last paragraph: The first "MAY" seems like a statement of fact. Is
> the 2nd MAY appropriate? That is, intermediary allowed to _not_ do this,
> and let endpoints get out of sync?
>
> -8, last paragraph: Why is the SHOULD not a MUST? When might one
> reasonably not follow it?
>
> -9, 2nd paragraph: Does this assume that the conference is new to each
> subsequent MCU? That is, one would never use this approach to bridge two
> existing conferences that already have their own UUIDs?
>
> - 10.3: Why doesn't the b2bua send a re-invite to update the uuid as in
> the next example?
>
> - 10.5: Please don't use the name of a trademarked, commercial service
> in an RFC. Can you recast this as a "web-based conference service"?
>
> Also, this should be clarified to be one of many ways to implement this
> use case, not necessarily a preferred way. (For example,  endpoints
> might initiate the INVITE requests toward the focus.)
>
> - 10.7, first bullet: It seems highly unlikely that a 3pcc server would
> not be dialog stateful.
>
> - 11: This section creates MUST level requirements for an implementation
> to be backwards compatible with a pre-standard, proprietary version.
> That seems to be a stretch. Did the working group really intend that an
> implementation could not choose not to implement this section?
>
> -- 4th bullet: Wny isn't the presence or absence of remote-uuid
> sufficient for responses?
>
> -- 5th bullet: This seems out of place; it's about non-compliant
> implementations of this document, not about backwards compatibility.
>
> - 6th bullet: Why would an "old" implementation include "remote-uuid" at
> all?
>
> - 12, first paragraph: The MUST here seems to conflict with the previous
> SHOULD about using UUID versions other than 4 or 5. (see previous
> comment).
>
> -- 3rd paragraph: Is there an impact if something tampers with or lies
> about session-Id values?
>
> - 15: Thank you for including this.
>
> Editorial Comments and Nits:
>
> -1, first paragraph: Please expand SIP on first mention.
>
> - 4.2, 4th paragraph: Please expand PBX on first mention.
>
> -- 2nd to last paragraph: This referes to conference focus, but most of
> the relevant section discusses MDUs. Please use consistent terms.
> (either may be okay, but "focus" probably better captures the signaling
> vs media role.)
>
> -6, paragraph 9: What is meant by "negatively affect"? Is this allowed
> to affect the session in neutral or positive ways?
>
> -- paragraph 11: Consider s/"MUST take care to ensure"/"MUST ensure".
> The "take care" part softens the message.
>
> -- 2nd to last paragraph: Redundant normative statements. Consider
> making the first one descriptive, since the second is the more precise
> of the two. (This pattern repeats in section 7 paragraph 7)
>
> - 7, 2nd paragraph: "which is why intermediaries" I think that's one
> reason why. There are likely others.
>
> -- 7th paragraph: "If an intermediary receives a SIP message without a
> Session-ID header field or valid header field value..."
>
> Does this mean either without session-id, or with session-Id but without
> a valid value? (As worded, the second part reads like it means without
> any valid header fields, but that doesn't make sense.)
>
> -8, first paragraph: This seems redundant to previous sections.
>
> 10.1, paragraph before SIP detail: It's not really complete if you omit
> stuff :-)
>
> 10.3: There's no description of the initial re-invite.
>
> 11, paragraph 5: It's not clear what "that" refers to.
>
>
>
>
>
>
>
>
>
> _______________________________________________
> insipid mailing list
> insipid@ietf.org
> https://www.ietf.org/mailman/listinfo/insipid