Subject: [rohc] This is an IETF working group... Or???

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Tue, 28 Sep 2004 14:53:49 +0200

Carsten, Lars-Erik,

Once again, recent discussions on CR the draft have left me thinking. After long hesitations, I have decided to bring my concerns to the chairs of the working group, FYI.

[Lars-Erik]
> > What is it that you think is unclear, that is so important and
> > makes sense to specify explicitly in this document?
[Zhigang]
> I thought I already pointed out in my email below. For your 
> convenience, copy-and-paste again:
> 
> > > a new context to be established by reusing a base context with
> > >a different but similar source and/or destination IP addresses.
[Lars-Erik]
> And why it is so important?

I stopped thinking about this question for a second, and it turns out that I also wonder...

[GHPE]
> > I don't think that it is more fair to suggest that IP 
> > addresses can be sent in compressed form. 
[Zhigang]
> No, that's not what I suggested. What I suggested is to
> make it clear that IP addresses can be *either* omitted
> *or* sent in compressed form

When looking at the three following comments - from the same contributor to this list - on the ROHC-CR draft:

1) R-mode. The original text was not precluding whatsoever the use of
an R-mode base context, but there seemed anyway to be a need to protect
the R-mode against this possible misinterpretation.
http://www1.ietf.org/mail-archive/web/rohc/current/msg02587.html

2) Making ACKing of initialization packets (IR-CR) mandatory?
Is this not the equivalent of trying to mandate that the initialization
part of ROHC-CR is done according to the logic of R-mode???
http://www1.ietf.org/mail-archive/web/rohc/current/msg02603.html

3) Is this an attempt to gain some acceptance for IP-address compression??? 
http://www1.ietf.org/mail-archive/web/rohc/current/msg02604.html

I can go with the first comment (1), I did remove mentioning modes - it was rather clumsy of me to write the original text like it was in -04. The text I then suggested made sure that it was fair to any possible profile logic for "mode behavior". However, technically speaking the new text has exactly the same implications.

However, while I hope that I am completely wrong, I get worried when looking at 1) and 2) in light of known IPRs on R-mode and ACKs, and 3) in light of http://www.ietf.org/ietf/IPR/nokia-updated-ipr-draft-saifullah-rohc-ip-addr-comp-context-replicat.txt. Mostly since the concept behind 3) also have been extensively discussed by the wg and not retained as a useful technical solution some time ago.

I sincerely hope that these comments are not (excuse the adjective) lame attempts to open the door to some late and last-minute IPR coverage of the CR solution, now or for the future.

As the editor of a wg document, it is difficult to appreciate having discussions where one side is trying to make objective comments on a technical solution and the specification itself, while the other part seems to bite on some "clarifications" for which the level of importance does not match the potential impact on the document, and comments for which the foundation may lie in other aspects of the final specs, such as covering IPRs?

While I am not saying that this is the case, I'd like the chairs to pay attention and to make sure that this kind of behavior does not happen on the mailing list.

Best regards,

///Ghyslain

--
 Ghyslain Pelletier, Dipl. Ing.
 Wireless IP Optimizations
 Ericsson Research, Corporate Unit

 Ericsson AB, Laboratoriegränd 11
 Box 920, S-97128 Luleå, SWEDEN
 Phone : +46 (0)  8 404 29 43
 Mobile: +46 (0) 70 264 83 14
 [email-masked]
 http://www.ericsson.com

-----------------------------------
 The opinions expressed in this
 message are my personal opinions.
 These opinions are not
 necessarily those of my employer,
 unless stated otherwise.
-----------------------------------

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: [email-masked]
Date: Wed, 29 Sep 2004 03:40:06 -0400

Ghyslain,

If I understand you correctly, you seem to say any technical contributions/comments should be rejected because of IPRs. If that is your belief (which I disagree), then the current CR draft already violates it since Ericsson has IPR on CRC and CRC is in the CR draft. Should you "sincerely" apply the same standard to others and to yourself?

> 2) Making ACKing of initialization packets (IR-CR) mandatory?

I made this proposal based on technical merit. RE IPR, I can tell you that there is no IPR on this. Otherwise, I would have already made disclosure right up-front according to the IETF rules. I don't believe IPRs related to R-mode covers this.

> 3) Is this an attempt to gain some acceptance for IP-address 

All my comments are to make sure it is not precluded by CR draft, which you agreed. RE IPR, yes, Nokia may have IPRs related to this. We followed the rules. We made the disclosure up-front. What is wrong with this?

Br, Zhigang

> -----Original Message-----
> From: ext Ghyslain Pelletier (LU/EAB)
> [mailto:[email-masked]]
> Sent: 28 September, 2004 03:54 PM
> To: Liu Zhigang.C (Nokia-NRC/Dallas); [email-masked]'; 
> Lars-Erik Jonsson
> (LU/EAB)
> Cc: [email-masked]
> Subject: This is an IETF working group... Or???
> 
> 
> Carsten, Lars-Erik,
> 
> Once again, recent discussions on CR the draft have left me 
> thinking. After long hesitations, I have decided to bring my 
> concerns to the chairs of the working group, FYI.
> 
> [Lars-Erik]
> When looking at the three following comments - from the same 
> contributor to this list - on the ROHC-CR draft:
> 
> I can go with the first comment (1), I did remove mentioning 
> modes - it was rather clumsy of me to write the original text 
> like it was in -04. The text I then suggested made sure that 
> it was fair to any possible profile logic for "mode 
> behavior". However, technically speaking the new text has 
> exactly the same implications.
> 
> However, while I hope that I am completely wrong, I get 
> worried when looking at 1) and 2) in light of known IPRs on 
> R-mode and ACKs, and 3) in light of 
http://www.ietf.org/ietf/IPR/nokia-updated-ipr-draft-saifullah-rohc-ip-addr-comp-context-replicat.txt. Mostly since the concept behind 3) also have been extensively discussed by the wg and not retained as a useful technical solution some time ago.

Best regards,

///Ghyslain

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Wed, 29 Sep 2004 10:31:08 +0200

Zhigang,

Thank you for clarifying the situation from your side.

> If I understand you correctly, you seem to say any technical 
> contributions/comments should be rejected because of IPRs.

Yet again you create your own interpretation. That's no surprise.

Imho all technical contributions/comments should be evaluated, and accepted or rejected based on their technical merit (including potential gains VS added complexity/constraints) after discussion between wg members - this is what I have been trying to do all along.

You made technical suggestions, which I and others have answered on a technical basis, and yet we could never come to some closure on the discussion. Others wg members also answered along my line.

After a while, it seemed rather clear that your commnents are mainly related to IP address compression and "R-mode-type of logic". IPHC was discussed by the wg a while ago based on a technical discussion the proposal was not retained. R-mode-type of logic does not make sense to be mandated for IR-CR - I think we've explained enough why. On top of this, IPHC and specific mode logic are *outside* the scope of the CR document draft anyway and yet you insist on requiring that text be inserted/modified in the draft.

I took your comments seriously and evaluated them, and agreed to modify text so that the scope of the document is correct in light of your concerns. I have the mail history to back this up. I think I have provided satisfactory answers - the draft does not preclude additional logic per-profile and certainly leave it up to profiles themselves to define packet formats, including specifics of encoding methods - yet, you keep insisting for more so that:

- NACKs to IR-CR are mandated (which would clearly lower the gains of CR,
  and would not increase robustness for e.g. TCP flows already running
  over a low BER link).
- support for a specific encoding method (i.e. IPHC) be spelled out.

which I have answered that it is clearly not in the scope of the draft, and the wg has not agreed either that this is something useful or necessary for CR.

At this point I think that it was no surprise that one would seek to understand why a discussion cannot be closed, and since it is easy to suspect that IPRs exist on the above then I thought useful to ensure that this is not the reason why the discussion on the CR draft is yet another neverending one, and having the wg chairs aware of my concerns regarding potentially why. I still think that it was appropriate, and am happy to hear that I was mistaken.

> > > I sincerely hope that these comments are not (excuse the adjective)
> > > lame attempts to open the door to some late and last-minute IPR
> > > coverage of the CR solution, now or for the future.

Great, then I know that it is not the case, as I have been hoping for.

> > > As the editor of a wg document, it is difficult to appreciate having
> > > discussions where one side is trying to make objective comments on a
> > > technical solution and the specification itself, while the other part
> > > seems to bite on some "clarifications" for which the level of importance
> > > does not match the potential impact on the document

On top of this, your comments were received after the wglc, when I am trying to create a final version to send for IESG review. Please get involved earlier in the process in the future if you believe that you can bring technical contributions that can impact the specs, or at least on time to facilitate the editor's work.

All in all, thank you for clarifying the situation.

Best regards,

///Ghyslain

> From: [email-masked] [mailto:[email-masked]]
> Sent: den 29 september 2004 09:40
> To: Ghyslain Pelletier (LU/EAB); [email-masked]; Lars-Erik Jonsson
> (LU/EAB)
> Cc: [email-masked]
> Subject: RE: This is an IETF working group... Or???
> 
> 
> Ghyslain,
> 
> If I understand you correctly, you seem to say any technical 
> contributions/comments should be rejected because of IPRs. If 
> that is your belief (which I disagree), then the current CR 
> draft already violates it since Ericsson has IPR on CRC and 
> CRC is in the CR draft. Should you "sincerely" apply the same 
> standard to others and to yourself?
> 
> I made this proposal based on technical merit. RE IPR, I can 
> tell you that there is no IPR on this. Otherwise, I would 
> have already made disclosure right up-front according to the 
> IETF rules. I don't believe IPRs related to R-mode covers this.
> 
> All my comments are to make sure it is not precluded by CR 
> draft, which you agreed. RE IPR, yes, Nokia may have IPRs 
> related to this. We followed the rules. We made the 
> disclosure up-front. What is wrong with this?
> 
> Br, Zhigang
> 
> http://www.ietf.org/ietf/IPR/nokia-updated-ipr-draft-saifullah
-rohc-ip-addr-comp-context-replicat.txt. Mostly since the concept behind 3) also have been extensively discussed by the wg and not retained as a useful technical solution some time ago.

Best regards,

///Ghyslain

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Wed, 29 Sep 2004 11:10:12 +0200

Some corrections...

> - NACKs to IR-CR are mandated (which would clearly lower the 
>   gains of CR, and would not increase robustness for e.g. TCP
>   flows already running over a low BER link).

should have read ACKs, not NACKs, of course.

> - support for a specific encoding method (i.e. IPHC) be spelled out.

should have read IPAC, not IPHC!

Sorry about that,

///Ghyslain

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Ghyslain Pelletier (LU/EAB)
> Sent: den 29 september 2004 10:31
> To: [email-masked]'; [email-masked]; Lars-Erik 
> Jonsson (LU/EAB)
> Cc: [email-masked]
> Subject: [rohc] RE: This is an IETF working group... Or???
> 
> 
> Zhigang,
> 
> Imho all technical contributions/comments should be 
> evaluated, and accepted or rejected based on their technical 
> merit (including potential gains VS added 
> complexity/constraints) after discussion between wg members - 
> this is what I have been trying to do all along.
> 
> You made technical suggestions, which I and others have 
> answered on a technical basis, and yet we could never come to 
> some closure on the discussion. Others wg members also 
> answered along my line.
> 
> After a while, it seemed rather clear that your commnents are 
> mainly related to IP address compression and "R-mode-type of 
> logic". IPHC was discussed by the wg a while ago based on a 
> technical discussion the proposal was not retained. 
> R-mode-type of logic does not make sense to be mandated for 
> IR-CR - I think we've explained enough why. On top of this, 
> IPHC and specific mode logic are *outside* the scope of the 
> CR document draft anyway and yet you insist on requiring that 
> text be inserted/modified in the draft.
> 
> I took your comments seriously and evaluated them, and agreed 
> to modify text so that the scope of the document is correct 
> in light of your concerns. I have the mail history to back 
> this up. I think I have provided satisfactory answers - the 
> draft does not preclude additional logic per-profile and 
> certainly leave it up to profiles themselves to define packet 
> formats, including specifics of encoding methods - yet, you 
> keep insisting for more so that:
> 
> which I have answered that it is clearly not in the scope of 
> the draft, and the wg has not agreed either that this is 
> something useful or necessary for CR.
> 
> At this point I think that it was no surprise that one would 
> seek to understand why a discussion cannot be closed, and 
> since it is easy to suspect that IPRs exist on the above then 
> I thought useful to ensure that this is not the reason why 
> the discussion on the CR draft is yet another neverending 
> one, and having the wg chairs aware of my concerns regarding 
> potentially why. I still think that it was appropriate, and 
> am happy to hear that I was mistaken.
> 
> On top of this, your comments were received after the wglc, 
> when I am trying to create a final version to send for IESG 
> review. Please get involved earlier in the process in the 
> future if you believe that you can bring technical 
> contributions that can impact the specs, or at least on time 
> to facilitate the editor's work.
> 
> -rohc-ip-addr-comp-context-replicat.txt. Mostly since the 
> concept behind 3) also have been extensively discussed by the 
> wg and not retained as a useful technical solution some time ago.
> 
> I sincerely hope that these comments are not (excuse the 
> adjective) lame attempts to open the door to some late and 
> last-minute IPR coverage of the CR solution, now or for the future.
> 
> As the editor of a wg document, it is difficult to appreciate 
> having discussions where one side is trying to make objective 
> comments on a technical solution and the specification 
> itself, while the other part seems to bite on some 
> "clarifications" for which the level of importance does not 
> match the potential impact on the document, and comments for 
> which the foundation may lie in other aspects of the final 
> specs, such as covering IPRs?
> 
> While I am not saying that this is the case, I'd like the 
> chairs to pay attention and to make sure that this kind of 
> behavior does not happen on the mailing list.
> 
> Best regards,
> 
> ///Ghyslain
> 
> --

---

From: [email-masked]
Date: Wed, 29 Sep 2004 07:23:15 -0400

Ghyslian,

> Yet again you create your own interpretation. That's no surprise.

Below is your own words. I guess I'd better not to say anything more. 

Now, what is your answer to my earlier question on Ericsson's IPR 
on CRC in the CR draft, in light of your own words below?

---------------------
"I sincerely hope that these comments are not (excuse the adjective) 
lame attempts to open the door to some late and last-minute IPR 
coverage of the CR solution, now or for the future."
---------------------

BTW, I'm open to critics. But frankly, it's not easy and fair to 
see your repeatedly accusations of my "putting words in your mouth"
and "misinterpreting" your emails. This is exactly the reason why I have
been insisting to clarify that CR draft does not preclude IP address 
compression, to prevent what is going on from happening in the future.

Br, Zhigang

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Wed, 29 Sep 2004 13:49:25 +0200

Zhigang,

My answer is exactly in line with my own words in my own previous mail:

> mho all technical contributions/comments should be evaluated,
> and accepted or rejected based on their technical merit
> (including potential gains VS added complexity/constraints)
> after discussion between wg members.

Your question was:

> Ericsson has IPR on CRC and CRC is in the CR draft. Should you
> "sincerely" apply the same standard to others and to yourself?

I have applied exactly the same "standard" (referring to the "standard I wrote and copy-pasted in this mail) in my TCP work with respect to everyone.

That is, the CRC issue has been discussed and agreed by WG consensus:

[Mark's mail]
http://www.ietf.org/mail-archive/web/rohc/current/msg01689.html
[Ghyslain's mail]
http://www.ietf.org/mail-archive/web/rohc/current/msg01693.html
[Gorry F.]
http://www1.ietf.org/mail-archive/web/rohc/current/msg01714.html

The CRC has been in the draft since May 2003... and CR a wg document since June 2003.

> and "misinterpreting" your emails. This is exactly the reason 

My point is that in the future, I would appreciate that my comments and answers be kept in their context and if reformulated, then make sure that it is clear that it is _your_ interpretation of what I said that is discussed. Similar things seem to happen from time to time, and the original comment is often modified/truncated - obviously by accident, but still it makes exchanges more difficult. See for example
http://www.ietf.org/mail-archive/web/rohc/current/msg02645.html

> why I have

And I have proposed many different ways to achieve this, which you haven't agreed yet.

Obviously, this does not work. I really don't like myself either the tone that this exchange have gotten into, and frankly would really prefer avoiding these kind of situation, but I also want to do my work and get this document out in a way that I think is right. You have clarified that your comments were driven purely by technical issues, and I believe that now after your explanations.

Please let's now move forward, also so that I can send the document for IESG review and focus on something else - because this is far from my favorite day at work.

Best regards,

///Ghyslain

> Sent: den 29 september 2004 13:23