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

["Ben Campbell" <[e-mail]>]

Okay, thanks!

Ben.

On 25 May 2016, at 15:10, Paul E. Jones wrote:

> We've been formulating a reply.  Coordination, time, etc.  But, a 
> reply is coming very soon.
>
> Paul
>
> ------ Original Message ------
> From: "Ben Campbell" <[e-mail]>
> To: [e-mail]; [e-mail]
> Sent: 5/25/2016 3:57:28 PM
> Subject: 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
>>>  [e-mail]
>>>  https://www.ietf.org/mailman/listinfo/insipid