Subject: [dispatch] AD review of draft-holmberg-dispatch-iotl

From: Richard Barnes <[email-masked]>
Date: Thu, 11 Dec 2014 10:33:17 -0500

I have reviewed this document in preparation for IETF LC.  Overall, it's in
pretty good shape, and I have requested last call, but there are a few
comments below that I would like addressed before it goes to the IESG.

Thanks,
--Richard

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?

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

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

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

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

"""
   The 'iotl' parameter is defined in order to fulfil requirements from
   the 3GPP.
"""
This doesn't really seem necessary, and seems like something other ADs are
likely to get hung up on.  Unless you mean to explicitly disclaim its
applicability to other networks.  In that case, it would be helpful to be
more explicit, "... and may not be applicable to other types of network."

"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

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

"""
 uri-parameter = transport-param / user-param / method-param / ttl-param
                 / maddr-param / lr-param / iotl-param / other-param
"""
You should check with someone more knowledgeable about ABNF than me, but I
understand the better thing to do than redefining the uri-parameter
production is to update it, e.g. "uri-parameter =/ iotl-param"

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Dec 2014 10:46:57 -0500

On 12/11/14 10:33 AM, Richard Barnes wrote:

> This doesn't really seem necessary, and seems like something other ADs
> are likely to get hung up on.  Unless you mean to explicitly disclaim
> its applicability to other networks.  In that case, it would be helpful
> to be more explicit, "... and may not be applicable to other types of
> network."

Christer and I had some long discussions on how to generalize this 
beyond the 3GPP scope.

To make it general it would have been necessary to formalize the notion 
of "traffic leg" in the sip environment, and how such legs could be 
classified. And it would have required a registry for traffic leg types, 
and possibly state models for how legs are grouped.

It wasn't evident how to do this, or that anybody other than 3GPP would 
want the result. So I suggested narrowing the scope to just 3GPP.

> You should check with someone more knowledgeable about ABNF than me, but
> I understand the better thing to do than redefining the uri-parameter

Yes!

	Thanks,
	Paul

---

From: Richard Barnes <[email-masked]>
Date: Thu, 11 Dec 2014 11:26:10 -0500

On Thu, Dec 11, 2014 at 10:46 AM, Paul Kyzivat <[email-masked]>
wrote:

> Christer and I had some long discussions on how to generalize this beyond
> the 3GPP scope.
>
> To make it general it would have been necessary to formalize the notion of
> "traffic leg" in the sip environment, and how such legs could be

I certainly didn't mean that the document should be generalized beyond
3GPP.  I'm totally fine with that restriction, and the text in the body
captures it well.  I just don't think it needs mentioning in the abstract,
or if it does, it should use the phrasing from the body: "The SIP URI
'iotl' parameter defined in this document is only applicable to 3GPP
networks.  The usage of the parameter within other types of networks is
undefined."

--Richard

> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Dec 2014 19:10:53 +0000

Hi,

I am fine replacing the “requirement” statement in the Abstract as suggested by Richard (by copying the text from the Applicability section):

"The SIP URI 'iotl' parameter defined in this document is only applicable to 3GPP networks.  The usage of the parameter within other types of networks is undefined."

Note that similar text exists also in the Introduction section:

   “The 'iotl' parameter is defined in order to fulfil requirements from
   the 3rd-Generation Partnership Project (3GPP), but it can also be
   used in other network environments.”

I guess I could remove that completely, as we have the other sentence both in the Abstract and in the Applicability section.

Regards,

Christer

On Thu, Dec 11, 2014 at 10:46 AM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

Christer and I had some long discussions on how to generalize this beyond the 3GPP scope.

To make it general it would have been necessary to formalize the notion of "traffic leg" in the sip environment, and how such legs could be classified. And it would have required a registry for traffic leg types, and possibly state models for how legs are grouped.

It wasn't evident how to do this, or that anybody other than 3GPP would want the result. So I suggested narrowing the scope to just 3GPP.

I certainly didn't mean that the document should be generalized beyond 3GPP.  I'm totally fine with that restriction, and the text in the body captures it well.  I just don't think it needs mentioning in the abstract, or if it does, it should use the phrasing from the body: "The SIP URI 'iotl' parameter defined in this document is only applicable to 3GPP networks.  The usage of the parameter within other types of networks is undefined."

--Richard

"""

Yes!

        Thanks,
        Paul

_______________________________________________
dispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dispatch

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 11 Dec 2014 17:24:29 -0500

> production is to update it, e.g. "uri-parameter =/ iotl-param"

Yes, that would be much clearer.

>    The 'iotl' parameter is defined in order to fulfil requirements from

There are three occurrences of statements like this:

   Abstract

   1.  Introduction

   The 'iotl' parameter is defined in order to fulfil requirements from
   the 3rd-Generation Partnership Project (3GPP), but it can also be
   used in other network environments.

   2.  Applicability

   The SIP URI 'iotl' parameter defined in this document is only
   applicable to 3GPP networks.  The usage of the parameter within other
   types of networks is undefined.

All of these are appropriate, given the purposes of these sections.  I
think it would help if the wording of all three was aligned.  The
typical phrasing in RFCs is "... is outside the scope of this
specification."  How about the following wording, which does not exclude
iotl from being used in non-3GPP networks, but makes it clear that this
draft does not define its usage there:

   The 'iotl' parameter is defined in order to fulfil requirements from
   the 3rd-Generation Partnership Project (3GPP).  The parameter may be
   used within other types of networks, but that usage is outside the
   scope of this specification.

(In the Abstract, "3rd-Generation Partnership Project (3GPP)" can be
abbreviated as "3GPP" because that acronym has been defined in the
abstract previously.)

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Dec 2014 22:59:47 +0000

Hi,

>> You should check with someone more knowledgeable about ABNF than me, 
>> but I understand the better thing to do than redefining the 
>> uri-parameter production is to update it, e.g. "uri-parameter =/ iotl-param"
>

AFAIK, that way of extending parameters have been deprecated, and one is (again) supposed to re-define the whole parameter.

But, Paul can correct me if I'm wrong :)

-----------

> All of these are appropriate, given the purposes of these sections.  I think it would help if the wording of all 
> three was aligned.  The typical phrasing in RFCs is "... is outside the scope of this specification."  How about 
> the following wording, which does not exclude iotl from being used in non-3GPP networks, but makes it clear 
> that this draft does not define its usage there:
>
> (In the Abstract, "3rd-Generation Partnership Project (3GPP)" can be abbreviated as "3GPP" because that acronym has been defined in the abstract previously.)

Richard indicated that he wants to remove the requirements sentence, and suggested the following:

	"The SIP URI 'iotl' parameter defined in this document is only applicable to 3GPP networks. The usage of the 
	parameter within other types of networks is undefined."

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Dec 2014 18:14:55 -0500

> But, Paul can correct me if I'm wrong :)

What made you think that? I know of no such change, *in general*.

There has been some discussion about whether such a change (using =/) 
constitutes a revision to the base draft. (IMO it does, some people 
don't think so.) If you actually do the change as you did then I think 
there is no question - it clearly is a revision!

IMO, if you want to avoid such changes causing an update to the base 
document then you should do things such that the ABNF in the base 
document isn't modified.

If there is a registry, then that really should serve as an alternative 
to listing values in ABNF. So then this issue doesn't come up.

In this particular case, there now *is* a registry of URI parameters, 
and your draft *is* asking for it to be updated. So I was wrong in 
suggesting that /= was better - I should have said that there should not 
be any change to the uri-parameter ABNF.

	Thanks,
	Paul

---

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

Hi,

>>>>                   / maddr-param / lr-param / iotl-param / 
>>>> other-param """

Maybe I have misunderstood something, then - or I remember wrong.

> There has been some discussion about whether such a change (using =/) constitutes a revision to the base draft. (IMO it does, some 
> people don't think so.) If you actually do the change as you did then I think there is no question - it clearly is a revision!
>
> IMO, if you want to avoid such changes causing an update to the base document then you should do things such that the ABNF in the base document isn't modified.
>
> If there is a registry, then that really should serve as an alternative to listing values in ABNF. So then this issue doesn't come up.
>
> In this particular case, there now *is* a registry of URI parameters, and your draft *is* asking for it to be updated. So I was wrong in 
> suggesting that /= was better - I should have said that there should not be any change to the uri-parameter ABNF.

Ok. So, what shall I do in this particular case? :)

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 12 Dec 2014 09:23:54 -0500

> there is no question - it clearly is a revision!

It could be argued both ways, I think.  Strictly speaking, the change
doesn't extend the set of strings that are generated by <uri-parameter>,
so I could argue that the draft only extends the base RFC by providing
additional interpretation to strings that are already valid.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 12 Dec 2014 16:57:41 +0000

Hi,

> It could be argued both ways, I think.  Strictly speaking, the change doesn't extend 
> the set of strings that are generated by <uri-parameter>, so I could argue that the 
> draft only extends the base RFC by providing additional interpretation to strings that > are already valid.

My fingers are ready, waiting on the keyboard. Just tell me what to type :)

Regards,

Christer

---

From: Richard Barnes <[email-masked]>
Date: Fri, 12 Dec 2014 12:06:35 -0500

On Fri, Dec 12, 2014 at 11:57 AM, Christer Holmberg <
[email-masked]> wrote:

> doesn't extend

My vote is for "=/", FWIW.

Note that there's about a 45% chance that someone will express a preference
during LC / IESG eval as well.  So maybe hold off for now?

--Richard

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Dec 2014 16:07:27 -0500

> My fingers are ready, waiting on the keyboard. Just tell me what to type :)

My preference is that you not provide any ABNF extending the values for 
uri-parameter. The IANA considerations section are sufficient.

Obviously we have a difference of opinion here.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 12 Dec 2014 16:32:47 -0500

Christer Holmberg <[email-masked]> writes:
>> doesn't extend the set of strings that are generated by
>> <uri-parameter>, so I could argue that the draft only extends the
>> base RFC by providing additional interpretation to strings that > are
>> already valid.
>

Personally, I'd ask the AD what the right way to treat it is.

Dale

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 14 Dec 2014 17:31:59 +0000

The IANA considerations section extends nothing - it is merely a set of instructions to IANA on how to update the registration tables.

Therefore what you propose is not a practical solution to the documentation.

Regards

Keith 

> -----Original Message-----
> From: dispatch [mailto:[email-masked]] On Behalf 
> Of Paul Kyzivat
> Sent: 12 December 2014 21:07
> To: [email-masked]
> Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl
> 
> >>> There has been some discussion about whether such a change (using 
> >>> =/) constitutes a revision to the base draft. (IMO it does, some 
> >>> people don't think so.) If you actually do the change as you did 
> >>> then I think there is no question - it clearly is a revision!
> >>
> >> <uri-parameter>, so I could argue that the draft only 
> extends the base RFC by providing additional interpretation 
> to strings that > are already valid.
> >
> My preference is that you not provide any ABNF extending the 
> values for uri-parameter. The IANA considerations section are 
> sufficient.
>

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 14 Dec 2014 20:29:01 +0000

Hi,

I suggest to keep the text as it is. I am sure the wise men and women of the IESG will guide me in the right direction, to get it right.

Regards,

Christer

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
Sent: 14 December 2014 19:32
To: Paul Kyzivat; [email-masked]
Subject: Re: [dispatch] AD review of draft-holmberg-dispatch-iotl

Regards

Keith 

> From: dispatch [mailto:[email-masked]] On Behalf Of Paul 
> Kyzivat
> extends the base RFC by providing additional interpretation to strings 
> that > are already valid.
> >
> My preference is that you not provide any ABNF extending the values 
> for uri-parameter. The IANA considerations section are sufficient.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Dec 2014 10:03:10 -0500

> I suggest to keep the text as it is. I am sure the wise men and women of the IESG will guide me in the right direction, to get it right.

Note that the text, as-is, *revises* the abnf definition of 
uri-parameter, specifying that it can take on one of a set of values, 
including your new one and some old ones. But if you examine the 
existing registry you will find that there are several additional values 
currently defined that are *not* included in your new abnf. The result 
is that your text adds confusion.

At least using =/ doesn't suffer *that* problem.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Dec 2014 10:04:29 -0500

> The IANA considerations section extends nothing - it is merely a set of instructions to IANA on how to update the registration tables.

Exactly. That is the point.

> Therefore what you propose is not a practical solution to the documentation.

Why?

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 15 Dec 2014 12:04:49 -0500

> At least using =/ doesn't suffer *that* problem.

There has been a custom in SIP to write productions like:

    thing = thing-subtype-A / thing-subtype-B / thing-subtype-C /
            generic-thing

where all of the strings generated by <thing-subtype-X> are also strings
generated by <generic-thing>.  This is pointless from the point of a
formal grammar, but is informative for a human reader that wants to know
the import of strings generated by <thing>.

In regard to <uri-parameter>, there are 12 RFCs mentioned in its
registry
(https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-11),
but only two (3261 and 5627) give productions for <uri-parameter>:

   uri-parameter     =  transport-param / user-param / method-param
                        / ttl-param / maddr-param / lr-param / other-param

   uri-parameter   =/ gr-param

Dale

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 16 Dec 2014 11:17:16 +0000

I read your proposal as to not have any ABNF at all, and a proposal to rely on the IANA registration.

If that is what is proposed it contains no normative proposal for the coding, and therefore that is why it is not acceptable.

I prefer the =/ which at least adds to the 3261 definition. 

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 15 December 2014 15:04
> To: DRAGE, Keith (Keith); [email-masked]
> > The IANA considerations section extends nothing - it is 
> merely a set of instructions to IANA on how to update the 
> registration tables.
> 
> >> extends the base RFC by providing additional interpretation to 
> >> strings that > are already valid.
> >>>
> >>> My fingers are ready, waiting on the keyboard. Just tell 
> me what to 
> >>> type :)
> >>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Dec 2014 08:41:25 -0500

> If that is what is proposed it contains no normative proposal for the coding, and therefore that is why it is not acceptable.

It needs to say in a normative way that it is defining a new 
uri-parameter, consistent with the definition in 3261, and give the name 
of that parameter. That is all it needs to do.

AFAICT, this *could* be accomplished with normative language within the 
IANA Considerations section, or it could be in some other section 
referenced by the IANA Considerations section.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 16 Dec 2014 13:53:32 +0000

Hi,

> It needs to say in a normative way that it is defining a new uri-parameter, consistent with the definition in 3261, and give the name of that parameter. That is all it needs to do.

Just for my understanding, where would the syntax of the parameter value(s) etc be defined?

Regards,

Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 16 Dec 2014 14:03:26 +0000

Well in my view in the main body of the document.

The main body of the document is for the implementors to read. The IANA considerations section is for IANA to read, and then update to say what they have done.

Regards

Keith

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: 16 December 2014 13:54
> To: Paul Kyzivat; DRAGE, Keith (Keith); [email-masked]
> Subject: RE: [dispatch] AD review of draft-holmberg-dispatch-iotl
> 
> Hi,
> 
> >> I read your proposal as to not have any ABNF at all, and a 
> proposal to rely on the IANA registration.
> >>
> >> If that is what is proposed it contains no normative 
> proposal for the coding, and therefore that is why it is not 
> acceptable.
> >
> > It needs to say in a normative way that it is defining a 
> new uri-parameter, consistent with the definition in 3261, 
> and give the name of that parameter. That is all it needs to do.
>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 16 Dec 2014 09:48:48 -0600

I've found this conversation a little hard to follow.
Hopefully I'm not going to make it worse for anyone, but I think this is 
where the discussion is.

1) There _should_ be some ABNF somewhere, the core of the remaining 
discussion is where to put it.
2) The ABNF should probably use =/ (even though Christer didn't do that 
for -03).

Do I have that right?

fwiw, I drew the genart straw on this draft, and will be doing a careful 
review, but hadn't planned to do
that until later this week or sometime next.

RjS

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 16 Dec 2014 18:49:28 +0000

Hi Robert,

>Hopefully I'm not going to make it worse for anyone, but I think this is where the >discussion is.
>
>1) There _should_ be some ABNF somewhere, the core of the remaining discussion is >where to put it.
>2) The ABNF should probably use =/ (even though Christer didn't do that for -03).

-03 (submitted today) does use =/, as it seems everyone can live with that.

http://www.ietf.org/id/draft-holmberg-dispatch-iotl-03.txt

>fwiw, I drew the genart straw on this draft, and will be doing a careful review, but >hadn't planned to do that until later this week or sometime next.

Were you assigned version -03? If not, is it possible to change the version?

Regards,

Christer

On 12/16/14 8:03 AM, DRAGE, Keith (Keith) wrote:
>> new uri-parameter, consistent with the definition in 3261, and give 
>> the name of that parameter. That is all it needs to do.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Dec 2014 00:22:00 -0500

> 2) The ABNF should probably use =/ (even though Christer didn't do that

I'm arguing otherwise.

My opinion is that in cases where there is an IANA registry of values, 
and the base syntax has provision for values defined in the future, then 
there need not, and should not, be ABNF extending the base syntax.

Yes, I know this goes against a lot of precedent. But I also find that 
the result of that precedent is confusing. It is *less* confusing when 
=/ is used than when the base syntax rule is restated and revised, but 
still confusing nevertheless. When there is a registry it is the only 
authoritative place to get an exhaustive list of possible values.

In the future, I would not do enumerations in ABNF for things that are 
to have registries - right from the beginning.

	Thanks,
	Paul

>> The main body of the document is for the implementors to read. The
>> IANA considerations section is for IANA to read, and then update to
>> say what they have done.
>>
>> Regards
>>
>> Keith
>>