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

From: James Polk <[email-masked]>
Date: Wed, 04 Sep 2013 14:41:48 -0500

All

I've been out on leave since just after Berlin (which I had to cancel 
at the last minute, so I wasn't able to attend in realtime, or 
present the INSIPID reqs and solutions drafts - which I normally do 
at each IETF). Somewhere along the way, it was decided that 
draft-kaplan-insipid-session-id should be informational and not 
historic. I backed this draft becoming historic, and wouldn't have 
backed this draft becoming an informational RFC, for some very 
specific reasons that Dan's Gen-Art review successfully tease out. 
I'm glad to see that Robert and Gonzalo Salgueiro (INSIPID WG chair) 
each generally agree to (Robert's agreement is below, Gonzalo's note 
of agreement is the next message on this thread on the INSIPID list).

Basically, as the author of more than 50% of the requirements doc 
text and approximately 70% of the solution doc text (from a 2 draft 
WG) I'm intimately familiar with the topic. We, as a WG, have 2 
existing legacy drafts that were never intended to reach RFC because 
they could never get any WG to reach consensus on either; I'm 
referring to draft-kaplan-insipid-session-id-00 and 
draft-kaplan-insipid-session-id-03 (neither is compatible the other). 
But, that didn't stop 3GPP from referencing one of the (the -03 
version of the kaplan draft) - and only a few months ago it was 
decided in INSIPID that we would rather have kaplan-03 as a separate 
historic RFC than an appendix within the existing solution doc 
currently progressing in INSIPID.

But alas, now with this "magical" change, the kaplan-03 _IS_ going to 
become an I-RFC, and it's going to be AD-sponsored, so the authors 
really don't have to abide by the INSIPID WG - and I have a problem 
with that on many levels.

#1 - this bait-and-switch will produce a non-historic RFC, where 
there was NOT any specific call for consensus to do that reassignment 
on the INSIPID list. I deem that a process violation.

#2 - with IETF LC about or actually over, one could interpret any 
failure of the INSIPID WG to produce a standards-track RFC with this 
kaplan-03 document as an informational RFC as INSIPID's meeting some 
measure of success within the WG, and that is not acceptable. 
Attempting to get WG consensus to point #1 would have addressed or at 
least fleshed this out.

#3 - I firmly want what Dan refers to with his Major issue #1 below, 
in that, as a condition of the INSIPID WG successfully documenting a 
standards-track solution, this kaplan-03 draft can then be published 
- perhaps even consecutive RFCs - as an I-RFC that way the INSIPID 
solution RFC(to-be) does all the IANA registration because it has the 
lower RFC number.

#4 - I am firmly opposed to the kaplan-03 draft IANA registering any 
part of the new Session-ID header. I would like to point out that if 
Dan's #1 major issue is worked out, his major issue #2 will also 
likely be worked out as a result of making the changes necessary for 
major issue #1.

The kaplan-03 draft should be written with INSIPID's express plan to 
produce their own solution, with the intention of the kaplan-03 
document being approved *after* the INSIPID solution is RFC'd.

James

>Date: Thu, 22 Aug 2013 12:08:26 -0500
>From: Robert Sparks <[email-masked]>
>To: "Romascanu, Dan (Dan)" <[email-masked]>
>CC: "[email-masked]" <[email-masked]>,
>         "[email-masked]"
>         <[email-masked]>, 
> "[email-masked]"
>         <[email-masked]>
>Subject: Re: [Insipid] [Gen-art] Gen-ART review of
>         draft-kaplan-insipid-session-id-03.txt
>
>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
>
>
>_______________________________________________
>insipid mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/insipid

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 12 Sep 2013 13:47:52 +0300

Hi,

there have been several threads related to this draft and not all of
them have taken place on the IETF general list. Let's try and use this
thread to resolve the few issues that have been brought up during the
IETF LC.

1) Informational vs. Historic

This draft documents a mechanism that has been widely deployed in the
field. The goal is to have a stable reference (i.e., an RFC) to the
mechanism. Examples of groups that need to reference this mechanism are
the INSIPID WG and 3GPP, which uses it in the IMS. In order to make the
goal of the draft clear, the Abstract says the following:

   This RFC, which contains the text of an individual Internet Draft
   that was submitted originally to the DISPATCH Working Group, is
   being published now as an Informational document to provide a
   reference for later RFCs.  The mechanism defined in this document
   has been widely deployed, and is being followed in a backward-
   compatible fashion for a new Standards Track RFC in the INSIPID
   Working Group.  The original Abstract follows.

Additionally, the IETF LC said the following:

> Note that this IETF last call is not intended to form IETF consensus on
> the content of this document. Consequently, the IESG is only looking for
> comments on the value of publishing this document as-is, not for
> comments on the content of the document.

In addition, we had to decide whether the eventual RFC would be Historic
or Informational. The IETF has not been consistent in how to publish
this type of stuff in the past. Sometimes we have used Historic RFCs and
sometimes we have used Informational ones. At some point, we can have a
discussion, issue an IESG statement or an RFC explaining what to do in
these cases, and be done with it. However, at this point we do not have
consistent guidelines. The IESG had a conversation about this particular
draft. We decided to make it Informational because while RFC 2026 seems
to allow the use of Historic RFCs for this purpose, Section 6.4 talks
about Historic RFCs only in the context of Standards Track RFCs.

http://tools.ietf.org/html/rfc2026#section-6.4

That was why Informational seemed a better choice.

In any case, whether this RFC becomes Informational or Historic, is a
very minor issue, IMHO. As Hadriel, editor of this draft, has mentioned
many times, most people out there do not even know the differences
between the different types of RFCs.  It is far more important to
clearly document why this mechanism is being published. So, if you have
comments on the Abstract (e.g., if you think it could be clearer),
please send text.

2) IANA Considerations and relation with the mechanism being developed
in the INSIPID WG

This draft is an individual submission that is being AD sponsored. So,
it is not a product of the INSIPID WG. Note that per the SIP Change
Process documented in RFC 5727, it is perfectly acceptable to register
SIP header fields in this way:

http://tools.ietf.org/html/rfc5727#section-4

Therefore, this draft registers the Session-ID header field with the
IANA. The designated expert is reviewing this registration, per the
rules in RFC 5727.

There have been comments regarding the fact that the mechanism being
developed by the INSIPID WG will be backwards compatible with the
mechanism described in this draft. That is a decision the INSIPID WG has
made, although it is not part of the requirements document the WG has
produced. Note that it is completely OK for a WG to decide to meet
additional requirements such as this one while developing a mechanism.

The issue is that, when the INSIPID mechanism is eventually published as
an RFC, it will probably use the same header field name (i.e.,
Session-ID). Therefore, the IANA Registry would need to be updated to
point to that RFC instead of this draft. Updating the IANA registry in
this way when INSIPID completes its charter does not seem to be a
problem. Even if INSIPID, for whatever reason, did not manage to produce
a mechanism in the future, the IANA registry would point to this draft
so that no other RFC could reuse the Session-ID token.

Therefore, there does not seem to be a good reason for delaying the
publication of this draft, considering that 3GPP needs to reference it
in one of its releases and they have tight deadlines.

Comments?

Cheers,

Gonzalo

On 04/09/2013 10:41 PM, James Polk wrote:> All
> 
> I've been out on leave since just after Berlin (which I had to cancel at
> the last minute, so I wasn't able to attend in realtime, or present the
> INSIPID reqs and solutions drafts - which I normally do at each IETF).
> Somewhere along the way, it was decided that
> backed this draft becoming an informational RFC, for some very specific
> reasons that Dan's Gen-Art review successfully tease out. I'm glad to
> see that Robert and Gonzalo Salgueiro (INSIPID WG chair) each generally
> agree to (Robert's agreement is below, Gonzalo's note of agreement is
> the next message on this thread on the INSIPID list).
> 
> Basically, as the author of more than 50% of the requirements doc text
> and approximately 70% of the solution doc text (from a 2 draft WG) I'm
> intimately familiar with the topic. We, as a WG, have 2 existing legacy
> drafts that were never intended to reach RFC because they could never
> get any WG to reach consensus on either; I'm referring to
> draft-kaplan-insipid-session-id-00 and
> But, that didn't stop 3GPP from referencing one of the (the -03 version
> of the kaplan draft) - and only a few months ago it was decided in
> INSIPID that we would rather have kaplan-03 as a separate historic RFC
> than an appendix within the existing solution doc currently progressing
> in INSIPID.
> 
> really don't have to abide by the INSIPID WG - and I have a problem with
> that on many levels.
> 
> #1 - this bait-and-switch will produce a non-historic RFC, where there
> was NOT any specific call for consensus to do that reassignment on the
> INSIPID list. I deem that a process violation.
> 
> measure of success within the WG, and that is not acceptable. Attempting
> to get WG consensus to point #1 would have addressed or at least fleshed
> this out.
> 
> #3 - I firmly want what Dan refers to with his Major issue #1 below, in
> that, as a condition of the INSIPID WG successfully documenting a
> standards-track solution, this kaplan-03 draft can then be published -
> perhaps even consecutive RFCs - as an I-RFC that way the INSIPID
> Dan's #1 major issue is worked out, his major issue #2 will also likely
> be worked out as a result of making the changes necessary for major
> issue #1.
> 
> produce their own solution, with the intention of the kaplan-03 document
> being approved *after* the INSIPID solution is RFC'd.
> 
> James
> 
> 
>> Session-ID header with IANA, even though there is a section that looks
>> like it does.
>>
>> 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.
>>
>>> I am the assigned Gen-ART reviewer for this draft. For background on
>>> Gen-ART, please see the FAQ at
>>>
>>> Please resolve these comments along with any other Last Call comments
>>> you may receive.
>>>
>>> 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
>>> 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
>>> 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
>>>
>>>

---

From: James Polk <[email-masked]>
Date: Thu, 12 Sep 2013 14:50:53 -0500

Gonzalo

comments in-line (for context) below

>in one of its releases and they have tight deadlines.

Yeah - playing devil's advocate here, say you have a small group of 
participants from another SDO that only want this kaplan draft to 
reach RFC status, say, by sabotaging any further work coming out of a 
WG (in this case INSIPID) to ensure that their AD-sponsored draft is 
the only solution that reaches RFC (and I'm not saying 3GPP is doing 
this, I'm merely playing devil's advocate)... then in publishing this 
non-WG consensus draft (that's been around for 5 years now) as an RFC 
before the INSIPID (or any) WG standards-track solution is published 
as an RFC is undercutting this and any other WG in the same situation?

To quote you from above "...most people out there do not even know 
the differences between the different types of RFCs..."

In other words, I'm postulating that if a small subset of a WG could 
get their favorite draft that has (and will) not reach WG consensus 
published as an RFC, then where exactly is this subset going to 
benefit from a competing proposal, even if backwards compatible (it's 
gotta be more complicated to implement, right?), published in "phase 
II" or any WG?

Said even another way - couldn't this small subset make enough of a 
stink about the WG draft, once they have gotten their ID published as 
an RFC, to ensure it will never be published?

Is that really where we want to go as a community?

I'm suggesting that this AD-sponsored draft *not* get published until 
after the WG solution is published (originally proposed by Dan 
Romascanu in his Gen-ART review of this draft). Do this, and I 
believe this problem of getting around any WG intent goes away.

James

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 13 Sep 2013 13:31:52 +0300

Hi James,

thanks for clarifying your concern. With respect to the INSIPID WG
managing to successfully complete its charter, as you know, there have
already been a few people that have expressed concerns about it. Some
people seem to believe that there is a non-zero probability for INSIPID
to fail. Nevertheless, that probability does not relate to some
potentially evil 3GPP guys trying to sabotage their work, as you
hypothesized in your email below. It relates to the difficulty of
resolving the correlation problem in a general manner. It also relates
to the overload in functionality the proposed header field may suffer.
As you know, the more "useful" things we can do with the header field,
the more likely it will be for B2BUAs and SBCs to mess with it (which
would defeat the whole purpose of the header field).

As the responsible AD for INSIPID, I agree there is some danger of
failure, as I have expressed a few times in the past. Nevertheless, I
think there are good chances for them to succeed in completing their
charter. That is of course why the WG is still active and has not been
shut down. Hopeless WGs are shut down, as what happened with SPLICES
(which was somewhat related to INSIPID) illustrates.

Having said all that, what happens with INSIPID is irrelevant in this
discussion. Per the SIP Change process, anybody can register a SIP
header field as long as the criteria described in RFC 5727 are met:

The idea with the SIP Change process was to make it easier and more
lightweight to register header fields that would have been previously
registered as P headers.

So, as stated in the IETF LC, we need comments about the usefulness of
publishing a widely-deployed mechanism and about the criteria for header
field registration above. Additionally, if something in the mechanism
makes it applicable only in certain environments (as was the case with
the old P headers), that would be relevant as well.

On a related note, the PROTO writeup mentions that there have been IPR
disclosures on the INSIPID requirements and solution drafts that may be
applicable to this draft as well. I have sent a reminder to the INSIPID
list in case someone feels the need to make any new IPR disclosure.

Thanks,

Gonzalo

On 12/09/2013 10:50 PM, James Polk wrote:
> participants from another SDO that only want this kaplan draft to reach
> RFC status, say, by sabotaging any further work coming out of a WG (in
> this case INSIPID) to ensure that their AD-sponsored draft is the only
> solution that reaches RFC (and I'm not saying 3GPP is doing this, I'm
> merely playing devil's advocate)... then in publishing this non-WG
> consensus draft (that's been around for 5 years now) as an RFC before
> the INSIPID (or any) WG standards-track solution is published as an RFC
> is undercutting this and any other WG in the same situation?
> 
> To quote you from above "...most people out there do not even know the
> differences between the different types of RFCs..."
> 
> In other words, I'm postulating that if a small subset of a WG could get
> their favorite draft that has (and will) not reach WG consensus
> published as an RFC, then where exactly is this subset going to benefit
> from a competing proposal, even if backwards compatible (it's gotta be
> more complicated to implement, right?), published in "phase II" or any WG?
> 
> stink about the WG draft, once they have gotten their ID published as an
> RFC, to ensure it will never be published?
> 
> after the WG solution is published (originally proposed by Dan Romascanu
> in his Gen-ART review of this draft). Do this, and I believe this
> problem of getting around any WG intent goes away.
> 
> James
> 
> 
>> Cheers,
>>
>> Gonzalo
>>
>>
>> with
>> Attempting
>> document

---

From: Adam Roach <[email-masked]>
Date: Fri, 13 Sep 2013 11:22:22 -0500

> IANA. The designated expert is reviewing this registration, per the

Yes, I am, and the only reason I didn't rubberstamp this for 
registration as soon as it hit my inbox is exactly the confusion that 
having two documents that register the same header field is likely to cause.

I've only been peripherally following the events in INSIPID, but I was 
aware of the existence of a draft intended to document historical usage 
as well as a separate standards-track document to publish a consensus 
mechanism (possibly including some degree of backwards compatibility 
with historical usage). Like Robert, I didn't expect the "historical 
usage" document to perform any registration, and was quite confused when 
the IANA approached me about doing so.

I don't have a really strong opinion about whether draft-kaplan creates 
a new entry in IANA that is replaced by a reference to 
draft-ietf-insipid when it is published (versus not registering 
anything, and then having the WG consensus document perform the 
registration). That's not to say that I don't have an opinion on the 
topic; I just don't feel strongly enough about it to wrestle about it.

Here's what I do feel strongly about: whatever the plan of record needs 
to be clearly recorded in a place that people will find it. If 
draft-kaplan registers Session-ID, we need two changes to the existing 
documents: First, draft-kaplan needs to be crystal clear about the plan 
of record its section 10 (e.g., "This registration is intended to be 
temporary, and should be removed when [draft-ietf-insipid-...] is 
published.")  Secondly, draft-ietf-insipid must clearly state that its 
IANA registration *removes* the old reference and *completely* replaces 
it with a pointer to the standards-track document.

The situation that I want to ensure cannot happen is an IANA-registered 
SIP header field that points to two documents simultaneously, especially 
if the ABNF is not absolutely identical between the two documents.

/a

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Fri, 13 Sep 2013 16:40:41 +0000

> Here's what I do feel strongly about: whatever the plan of record needs to be clearly recorded in a place that people will find it. If draft-kaplan registers Session-ID, we need two changes to the existing documents: First, draft-kaplan needs to be crystal clear about the plan of record its section 10 (e.g., "This registration is intended to be temporary, and should be removed when [draft-ietf-insipid-...] is published.")  Secondly, draft-ietf-insipid must clearly state that its IANA registration *removes* the old reference and *completely* replaces it with a pointer to the standards-track document.

Fully agree.
> 
> The situation that I want to ensure cannot happen is an IANA-registered SIP header field that points to two documents simultaneously, especially if the ABNF is not absolutely identical between the two documents.

The reality is that the backwards compatibility between the INSIPID Sess-ID mechanism and the kaplan draft is still undetermined and we cannot yet make a definitive statement on how it will look.  Assuming the Session-ID header field is (re-)used, the ABNF can't be identical because the session identifier used for INSIPID MUST address requirements that the kaplan id does not meet; so construction of the id will be different.  At this point the most that can be said is that one won't break the other (through non-intersection like using different header field names, etc.) or through direct backwards compatibility (same header field name but the INSIPID with expanded ABNF that plays nice with the kaplan id).

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 16 Sep 2013 10:49:35 +0200

Hi Adam,

exactly, we want to avoid having a confusing IANA registry. It needs to
be crystal clear for the implementors who will check it at any point.

In any case, note that a few IPR disclosures on the INSIPID drafts are
being updated to reflect that they also apply to this draft. So, we will
need to wait in order to make a decision... in the mean time, it would
be great to get further input from more participants.

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 20 Sep 2013 10:52:31 +0200

Hi Hadriel,

to summarize the status of this IETF LC, we are still expecting (at
least) an additional IPR disclosure on this draft (as announced on the
INSIPID list). When that happens, I will IETF LC it again.

In the mean time, we need to address the comments related to the IANA
registration the draft requests. I have discussed with the expert
reviewer (Adam) and adding something along these lines would help:

"This registration is intended to be temporary. The authors expect that
a standards-track definition of Session-ID will be published at a future
date. Assuming such a document is published, it will replace this
registration with a reference to itself, at which point this document
will no longer be referenced by IANA."

You have also received a review from the OPS directorate and I do not
think that has been addressed so far.

So, while we are waiting for the IPR disclosure, please go ahead and
revise the draft.

Thanks,

Gonzalo

---

From: SM <[email-masked]>
Date: Fri, 20 Sep 2013 22:29:56 -0700

Hello,
>INSIPID list). When that happens, I will IETF LC it again.

There was a discussion about IPR on this mailing list but nobody 
mentioned RFC 6701 or RFC 6702.  It is a mystery why the IETF cannot 
remember the (Informational) RFCs it published one year ago.

There was a Last Call for draft-kaplan-insipid-session-id-03 ( 
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg11753.html 
).  The announcement did not mention any IPR disclosure.  Does the 
above qualify as a late disclosure?

>will no longer be referenced by IANA."

draft-ietf-insipid-session-id-02 is a WG document intended as a 
Proposed Standard.  The INSIPID charter mentions a milestone for 
February 2013.  It would be good if the IESG takes into consideration 
the overhead of getting this temporary assignment published as an 
IETF RFC.  The reason given for publication was that 3GPP has tight 
deadlines.  It is understandable that there can be delays in reaching 
a milestone.  What is the INSIPID WG estimate for that future date?

Regards,
-sm