Subject: Re: [Insipid] [Gen-art] Gen-ART review of draft-kaplan-insipid-session-id-03.txt

From: Robert Sparks <[email-masked]>
Date: Thu, 22 Aug 2013 12:08:26 -0500

Adding the working group.

Dan - thanks for this review. I've been working towards trying to 
express a concern, and this really helped clarify what was bothering me.

This document, AFAIK, _is not_ actually trying to register the 
Session-ID header with IANA, even though there is a section that looks 
like it does.

Rather, that registration is in 
http://datatracker.ietf.org/doc/draft-ietf-insipid-session-id/

That is a very good example of how just adding the explanatory paragraph 
at the beginning of the document isn't enough to turn this into 
something that documents an earlier path considered and implementation 
that exists current deployments - the text needs to be touched in 
several places to make it clear that's what the document is doing.  In 
the IANA considerations case, one possible adjustment is to change the 
text to "here's what known implementations have used for syntax. See 
[draft-ietf-insipid-session-id] for the intended registered syntax", and 
not issue instructions to IANA.

It's more work for Hadriel, but I think it's necessary.

RjS

On 8/21/13 12:26 PM, Romascanu, Dan (Dan) wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at
>
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Please resolve these comments along with any other Last Call comments you may receive.
>
> Document: draft-kaplan-insipid-session-id-03.txt
> Reviewer: Dan Romascanu
> Review Date: 8/21
> IETF LC End Date: 8/30
> IESG Telechat date:
>
> Summary:
> Ready with Issues
>
> Major issues:
>
> 1. In similar situations when IETF WGs decided to document proprietary solutions that were used as a basis for standards-track RFCs Historic RFCs were issued rather than Informational RFCs. See for example RFC 5412, 5413, 5414 which documented the prior art that was used to create RFC 5415. Publication of these documents was also withhold until the standards-track RFC was published. None of these precedents is followed here. One of the reasons for the WG to prefer Informational rather than Historic is the fact that the registration of a new SIP header field is required from IANA, and in conformance with RFC 5727 this can be done in an Informational RFC, but not in a Historic one. What is missing however is clear text that the solution described in this document is a legacy solution and that the solution going forward is the one that is being defined by the INSIPID WG. The IESG should also consider whether this document should be approved for publication before the standards-t
>   rack solution defined by the INSIPID WG is also published.
>
> 2. The Abstract makes the claim that the Standards-Track RFC that will be eventually produced by the INSIPID WG will be developped in a backwards-compatible manner with this document. This does not seem appropriate here - if at all such a requirement should be included in draft-ietf-insipid-session-id-reqts-08.txt. However it does not appear there, and that document was recently submitted for publication to the IESG, so the WG did not include it in its consensus.
>
> Minor issues:
>
> 1. The IANA considerations sections need to be more explicit in demonstrating that the conditions for registration of extension SIP header fields in Informational RFCs have been met as per RFC 5727. That RFC defines that Designated Expert review needs to happen for such new registrations - I could not find a proof that such a review took place in the shepherd write-up. Actually the question about the expert reviews is not answered directly, instead of an answer wide deployment is mentioned, but that deployment could not use this SIP header field which was not yet approved. According to RFC 5727 there are two basic conditions that need to be verified by the Designated Expert - that the proposed header field must be of a purely informational nature and must not significantly change the behavior of SIP entities that support it, and that the proposed header field must not undermine SIP security in any sense, and that the Informational RFC defining the header field must address se
>   curity issues in detail, as if it were a standards-track document. I believe that both conditions are met by the I-D, but there is no adequate text in the IANA considerations section to explain this.
>
> Nits/editorial comments:
>
>
> Regards,
>
> Dan
>
>
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Thu, 22 Aug 2013 13:30:43 -0400

On Aug 22, 2013, at 1:08 PM, Robert Sparks <[email-masked]>
 wrote:

> Dan - thanks for this review. I've been working towards trying to express a concern, and this really helped clarify what was bothering me.
> 
> This document, AFAIK, _is not_ actually trying to register the Session-ID header with IANA, even though there is a section that looks like it does.
> 
> Rather, that registration is in http://datatracker.ietf.org/doc/draft-ietf-insipid-session-id/
> 
> That is a very good example of how just adding the explanatory paragraph at the beginning of the document isn't enough to turn this into something that documents an earlier path considered and implementation that exists current deployments - the text needs to be touched in several places to make it clear that's what the document is doing.  In the IANA considerations case, one possible adjustment is to change the text to "here's what known implementations have used for syntax. See [draft-ietf-insipid-session-id] for the intended registered syntax", and not issue instructions to IANA.

During the shepherd write-up I made a similar same comment.  I think the right thing to do is to write explanatory text detailing that this document is in fact not registering anything because all relevant IANA registrations are deferred to the active WG document defining the new session id (draft-ietf-insipid-session-id).  It should also explain that documeny has the responsibility to assure backwards compatibility with this document.

--G

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 22 Aug 2013 15:16:34 -0400

Actually I consciously left the IANA section as registering the header, and it was not an oversight.

For background: I did not submit the draft as Informational originally in version-00 - I submitted it as Historic, and was asked by the shepherding AD to change it to Informational later, based on IESG feedback (I think; I could be wrong about it being from IESG feedback).

Once it became Informational, we (myself, the AD, and the WG chairs) did actually discuss whether it would register the header in IANA or not.  My understanding was that this Informational draft *would* in fact register the new header in IANA.  Technically there's nothing wrong with that, afaik, other than I do need to get Designated Expert review as Dan correctly pointed out.

We discussed that once the WG draft-ietf-insipid-session-id is published, it would then update IANA's entry for the header to point to the new WG RFC.  Whether the WG draft-ietf-insipid-session-id text needs to change to make that clear or not, or change to extend the already-registered header or not, etc., is of course also still change-able.

If the WG draft-ietf-insipid-session-id fundamentally changes the 'Session-ID' header from what it is in draft-kaplan-insipid-session-id, in a non-backwards-compatible fashion, then it won't have met the agreement reached in IETF 85 for adopting draft-jones-insipid-session-id-0 as the new WG document solution.  If we decide that's ok, then I think it actually needs to register a new header name regardless.  We know 'Session-ID' is already in-use in the wild, and there are plenty of more strings available for header names.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Aug 2013 15:49:43 -0400

On 8/22/13 1:30 PM, Gonzalo Salgueiro wrote:

> It should also explain that documeny has the responsibility to assure backwards compatibility with this document.

AFAIK the WG has no *responsibility* to assure backwards compatibility.
Its not mentioned in the charter, or in the requirements.

IMO its a "nice to have", nothing more.

	Thanks,
	Paul

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Thu, 22 Aug 2013 15:57:12 -0400

Well it is documented in the minutes as something the WG agreed to.  See similar post:

http://www.ietf.org/mail-archive/web/insipid/current/msg00614.html

Cheers,

--G

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Aug 2013 16:04:08 -0400

> http://www.ietf.org/mail-archive/web/insipid/current/msg00614.html

Then it ought to be recorded in someplace binding.
A new requirement would be a good way.

	Thanks,
	Paul

---

From: Robert Sparks <[email-masked]>
Date: Thu, 22 Aug 2013 15:11:18 -0500

> If the WG draft-ietf-insipid-session-id fundamentally changes the 'Session-ID' header from what it is in draft-kaplan-insipid-session-id, in a non-backwards-compatible fashion, then it won't have m…
As you note, and as RFC5727 allows, we _can_ register a header with an 
Informational RFC, as long as it meets the two restrictions in that 
document.
(And I believe this one does). I also think the IESG could be convinced 
that a Historic RFC would meet those requirements, and I don't think it 
was the intent to exclude them when RFC5727 was put together.

I, obviously, expected that since there _was_ a standards effort around 
this concept, and an expectation that it would use the same name in a 
backwards compatible way, that the standards track document would do the 
registration, and there would be some relationship like the one Dan 
points to in order to tie in this document.

I don't really care if we thread the registration differently, as long 
as we leave a _very_ clear record of what's happening since there is 
standards activity here. I don't think we have that in the current document.

But my _main_ concern is that this still reads like a PS, and I would 
rather we take the time to change the language to be clear it's 
documenting a current situation rather than providing instructions to 
new implementers.

RjS

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Aug 2013 16:27:02 -0400

At this point I am half tempted to suggest that we just agree to publish 
the Kaplan draft as historic, and then close this WG.

I say this because I don't think:
- we can reach agreement to make the Kaplan draft an RFC.
- the current work is going to yield something
   that will achieve its goals and be backward compatible
- pursuing the current work with a new header name would
   achieve wide deployment, given that a fairly large
   community is committed to Session-ID.

	Thanks,
	Paul

On 8/22/13 4:11 PM, Robert Sparks wrote:
>> For background: I did not submit the draft as Informational originally
>> in version-00 - I submitted it as Historic, and was asked by the
>> shepherding AD to change it to Informational later, based on IESG
>> feedback (I think; I could be wrong about it being from IESG feedback).
>>
>> Once it became Informational, we (myself, the AD, and the WG chairs)
>> did actually discuss whether it would register the header in IANA or
>> not.  My understanding was that this Informational draft *would* in
>> fact register the new header in IANA.  Technically there's nothing
>> wrong with that, afaik, other than I do need to get Designated Expert
>> review as Dan correctly pointed out.
>>
>> We discussed that once the WG draft-ietf-insipid-session-id is
>> published, it would then update IANA's entry for the header to point
>> to the new WG RFC.  Whether the WG draft-ietf-insipid-session-id text
>> needs to change to make that clear or not, or change to extend the
>> already-registered header or not, etc., is of course also still
>> change-able.
>>
>> If the WG draft-ietf-insipid-session-id fundamentally changes the
>> 'Session-ID' header from what it is in
>> draft-kaplan-insipid-session-id, in a non-backwards-compatible
>> fashion, then it won't have met the agreement reached in IETF 85 for
>> adopting draft-jones-insipid-session-id-0 as the new WG document
>> solution.  If we decide that's ok, then I think it actually needs to
>> register a new header name regardless.  We know 'Session-ID' is
>> already in-use in the wild, and there are plenty of more strings
>> available for header names.
>>> Session-ID header with IANA, even though there is a section that
>>> looks like it does.
>>>
>>> That is a very good example of how just adding the explanatory
>>> paragraph at the beginning of the document isn't enough to turn this
>>> into something that documents an earlier path considered and
>>> implementation that exists current deployments - the text needs to be
>>> touched in several places to make it clear that's what the document
>>> is doing.  In the IANA considerations case, one possible adjustment
>>> is to change the text to "here's what known implementations have used
>>> for syntax. See [draft-ietf-insipid-session-id] for the intended
>>> registered syntax", and not issue instructions to IANA.
>>>
>>>> 1. In similar situations when IETF WGs decided to document
>>>> proprietary solutions that were used as a basis for standards-track
>>>> RFCs Historic RFCs were issued rather than Informational RFCs. See
>>>> for example RFC 5412, 5413, 5414 which documented the prior art that
>>>> was used to create RFC 5415. Publication of these documents was also
>>>> withhold until the standards-track RFC was published. None of these
>>>> precedents is followed here. One of the reasons for the WG to prefer
>>>> Informational rather than Historic is the fact that the registration
>>>> of a new SIP header field is required from IANA, and in conformance
>>>> with RFC 5727 this can be done in an Informational RFC, but not in a
>>>> Historic one. What is missing however is clear text that the
>>>> solution described in this document is a legacy solution and that
>>>> the solution going forward is the one that is being defined by the
>>>> INSIPID WG. The IESG should also consider whether this document
>>>> should be approved for publication before the standar
> ds-t
>>>> 2. The Abstract makes the claim that the Standards-Track RFC that
>>>> will be eventually produced by the INSIPID WG will be developped in
>>>> a backwards-compatible manner with this document. This does not seem
>>>> appropriate here - if at all such a requirement should be included
>>>> in draft-ietf-insipid-session-id-reqts-08.txt. However it does not
>>>> appear there, and that document was recently submitted for
>>>> publication to the IESG, so the WG did not include it in its consensus.
>>>>
>>>> Minor issues:
>>>>
>>>> 1. The IANA considerations sections need to be more explicit in
>>>> demonstrating that the conditions for registration of extension SIP
>>>> header fields in Informational RFCs have been met as per RFC 5727.
>>>> That RFC defines that Designated Expert review needs to happen for
>>>> such new registrations - I could not find a proof that such a review
>>>> took place in the shepherd write-up. Actually the question about the
>>>> expert reviews is not answered directly, instead of an answer wide
>>>> deployment is mentioned, but that deployment could not use this SIP
>>>> header field which was not yet approved. According to RFC 5727 there
>>>> are two basic conditions that need to be verified by the Designated
>>>> Expert - that the proposed header field must be of a purely
>>>> informational nature and must not significantly change the behavior
>>>> of SIP entities that support it, and that the proposed header field
>>>> must not undermine SIP security in any sense, and that the
>>>> Informational RFC defining the header field must addres
> s se
>>>>   curity issues in detail, as if it were a standards-track document.
>>>> I believe that both conditions are met by the I-D, but there is no
>>>> adequate text in the IANA considerations section to explain this.
>>>>
>>>> Nits/editorial comments:
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Dan
>>>>
>>>>

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Thu, 22 Aug 2013 16:27:47 -0400

> A new requirement would be a good way.

If I recall correctly, that was proposed but the WG felt it wasn't proper to add it to the requirements doc because of certain potential feasibility unknowns relative to interworking scenarios between old and new Sess-IDs.  It was instead used as a conditional to WG adoption of the solution doc and it was added as a new section to that solution doc.

Based on what I've seen, there is enough strong support for backwards compatibility that I am certain they will not let us forget its priority. ;-)

--G

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Thu, 22 Aug 2013 16:38:42 -0400

My thoughts are we don't need to continue beating this lifeless horse, but alas I'll comment...

On Aug 22, 2013, at 4:27 PM, Paul Kyzivat <[email-masked]> wrote:

> At this point I am half tempted to suggest that we just agree to publish the Kaplan draft as historic, and then close this WG.
> 

Agreed.

>  that will achieve its goals and be backward compatible

Speculative at best.

>  community is committed to Session-ID.

Discussions in Berlin with Laura and other strong supporters of the 3GPP solution (i.e., the Kaplan draft) have assured me that they plan to adopt the new Session-ID mechanism, so long during the transition it can be backwards compatible with the old Sess-ID that is widely deployed on their networks.

Cheers,

Gonzalo

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 22 Aug 2013 18:29:30 -0400

> - we can reach agreement to make the Kaplan draft an RFC.

We don't need to "reach agreement" to publish an Informational RFC.  It's not standards-track, and not even a WG doc.  All it was ever going to be published as was Informational, as far back as 2010.

>  that will achieve its goals and be backward compatible

I think it's premature to give up on it.  I mean we haven't failed yet, afaik.  We only really started getting down to the nitty-gritty stuff this past month.

>  community is committed to Session-ID.

I think there might be conflicting goals/requirements within the WG.  Fulfilling one might conflict with fulfilling the other.  It's not just about backwards-compatibility, but also about the need for re-INVITEs/UPDATEs.  A new header name might avoid those conflicts.  For vendors that want/need to handle conference servers and updating all participants with the new correlation value, a new header would be usable.  For ones that just need to correlate the basic call scenarios without extra messages, the legacy one would be usable.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Aug 2013 10:30:08 -0400

>> At this point I am half tempted to suggest that we just agree to publish the Kaplan draft as historic, and then close this WG.

Note that I said I was "half tempted", not that I am proposing it.
Its an expression of frustration.

> We don't need to "reach agreement" to publish an Informational RFC.  It's not standards-track, and not even a WG doc.  All it was ever going to be published as was Informational, as far back as 201…

I should have been clearer. I was talking about an alternative that 
hasn't been discussed recently - just take up the Kaplan draft again and 
*make it a standard*. Different from publishing it in a non-normative way.

> I think it's premature to give up on it.  I mean we haven't failed yet, afaik.  We only really started getting down to the nitty-gritty stuff this past month.

Yes, we are still at it. But I see a lot of going in circles.
The impression I get is that the most recent proposed changes lose what 
Paul J was trying to accomplish. ISTM that the result of that will be 
more complex than the Kaplan draft but have no advantages over it.

And your repeated comments that B2BUAs often won't propagate reINVITEs 
that update the value on transfer call into question the workability of 
any two-halved approach.

> I think there might be conflicting goals/requirements within the WG.  Fulfilling one might conflict with fulfilling the other.  It's not just about backwards-compatibility, but also about the need…

Certainly publishing with a new name is a technical possibility.
But then backward compatibility will require new implementers to include 
both. Will people do that? Or will we just end up with two competing 
standards?

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 30 Aug 2013 12:17:42 +0000

(As WG cochair)

Formally, none of these comments made it into the IETF last call, because as far as I can tell they were not made in the appropriate place, which is the IETF discussion list.

Moreover, I made a post to this list at the time the IETF last call was announced stating that the INSIPID WG list should not be used, but rather the IETF discussion list.

I am not seeing anything in either Robert's or Paul's comment that can be taken as a specific comment beyond what is already in the gen-art review. If they want to reformulate any comments that are not already reflected in the gen-art review so that they are more specific, then I am sure they are welcome to post them on the IETF discussion list.

These above are issues that are not part of the WG.

To respond to concerns about how the IANA registration impacts the working group output (as this was discussed by the WG chairs with the AD before the publication request for the kaplan draft was made)...

It was our understanding that the kaplan draft does make an IANA registration in the header field tables. The fact that an entry appears in the IANA tables conveys no seal of approval or correctness, and I can find nothing in RFC 5226 that states otherwise. The seal of approval and correctness is conveyed by the RFC itself and its contents. All that happens is that the process is followed and the value appears. Whether that process (RFC 5727) is complete in this instance (as queried in the gen-art review) is a separate issue that the AD will presumably address.

When we get to the insipid solution document, there is nothing that prevents that document (within its IANA considerations) entirely rewriting that entry, either to remove references to the kaplan draft (or its RFC successor) or to show both references. How those statements appear in the insipid solution document is up to the WG.

Therefore I do not believe there is an issue here.

What is clear is that there are implementations out in the field that do use the existing kaplan draft, and therefore if an RFC does exist, an entry in the IANA tables would assist recipients of the header field in determining the functionality. For completeness, I would also say that those people who identified those implementations have also stated that they intend to migrate to the insipid solutions draft when it is available.

We do have decisions already made in the WG (and documented in the the proceedings) that the solutions document should remain compatible with the existing solution. That implies that the header field name is the same, the value conforms to the same ABNF, but that the solution can add as many parameters as it likes. I do not see that as unduly constraining on the working group, and apparently also the working group has not in its previous discussions.

Obviously we do also have an agreed set of requirements to meet (which are not met by the kaplan draft). As those are also a WG decision and will presumably shortly also be an IETF decision, they can be taken as overriding the backwards compatibility decision if the two decisions prove to be incompatible.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> Sent: 22 August 2013 21:27
> To: [email-masked]
> Subject: Re: [Insipid] [Gen-art] Gen-ART review of draft-kaplan-insipid-
> session-id-03.txt
>