Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl - Richard's comments

From: Christer Holmberg <[email-masked]>
Date: Fri, 12 Dec 2014 17:12:18 +0000

Hi Richard,

Thanks for your comments! See inline.

(I have removed the comments that are covered in separate threads)

> The document says clearly how to indicate a traffic leg, but never really states *why* a network element would 
> care what type of traffic leg a message is part of.  Is there an example that could be given?

The Introduction section contains the following:

	"The traffic leg information can be used by intermediary entities to
   	make policy decisions, related to e.g. media anchoring, signalling
   	policy, insertion of media functions (e.g. transcoder) and charging."

----------------

> It seems like Section 5.2.1 could just be included directly under Section 5.2.

I am sure Keith can tell you why that is a bad idea :)

I have been using this structure in other drafts too, so I'd like to keep it.

----------------

> Section 5.2.1 needs to include a normative reference to a 3GPP spec defining "home" and "visited".

I'll take a look at that.

----------------

> The Security Considerations is basically saying, "Be careful making decisions based on this 
> parameter, because anyone could change it".  The RFC 2119 language is helpful, because it 
> refers to undefined concepts.  It would be better to refer to documents that have a defined 
> concept of trust boundaries, e.g., RFC 3325 for the notion of Spec(T).

I am not sure I understand what you mean.

----------------

>"""
>   This document defines a new SIP URI parameter, 'iotl', which can be
>   used in a SIP URI to indicate that the entity associated with the
>   address, or an entity responsible for the host part of the address,
>   represents the end of a specific traffic leg (or multiple traffic
>   legs).
>"""
> This sentence is really long, and I don't think it's grammatical.  At least my internal brain couldn't parse it.  
> Likewise the corresponding sentence in Section 1.

I could split it into two sentences:

	"This document defines a new SIP URI parameter, 'iotl'. The parameter 
	can be used in a SIP URI to indicate that the entity associated with the
   	address, or an entity responsible for the host part of the address,
   	represents the end of a specific traffic leg (or multiple traffic legs)."

----------------

> "an end user can be attached"
> Don't you mean "an end user *device*"?  The idea of end users being attached to the network calls to mind scenes from the Matrix 
> :)  http://matrixcommunity.org/wordpress/wp-content/uploads/2014/04/Neo-and-the-pods.jpg

While being able to associate the draft with Matrix would be soooooo cool, I'll add the device part :)

----------------

> "If, within an initial request for a dialog...identifies the type of traffic leg"
> * This section on choosing which 'iotl' parameter to use is useful.  Editorially, it would be a 
> little clearer to pull it out into bullet points, and preface with "A SIP entity determines the 
> type of traffic leg in the following way".  I would also suggest considering whether putting 
> a MUST here would be appropriate, e.g., "SIP entities that understand the 'iotl' parameter 
> MUST use the following rules to determine the type of traffic leg..."

I initially tried to put everything into bullet points, but didn't figure out how to do it in a good way.

But, I can give it another try.

Regards,

Christer