Subject: [rohc] Proposed changes to rohc-tcp-09

From: Kristofer Sandlund <[email-masked]>
Date: Thu, 21 Apr 2005 10:36:22 +0200

Hi all!

I've gone through on rohc-tcp-09 and found once more a lot of room for 
improvements. Probably lots more than those I've listed here!
First of all, I have already done two changes to the tcp-pf document in the CVS, 
which have both been decided on long ago, these are:

- Fixed IPID-behavior (symbolic constant use and IPv6 using RANDOM) (v.1.39) in 
the CVS as discussed earlier.

- Removed "list_tcp_options". This syntax is no longer in FN spec, and we need 
to define this in English in the tcp-draft instead. Changed so that the 
list_tcp_options is a reference at the start of the definitions. (v.1.40)

Apart from that, the packet formats still have a couple of open issues regarding 
notating the scaled encoding and the moving of let-statements out of 
default_methods.

TEXT ADDITIONS/CHANGES FOR LIST COMPRESSION
----
- 7.2.4 should not have any references to ROHC-FN.
- New section between 7.2.3 and 7.2.4 describing the format of type 0 lists 
header in box notation. Must also describe how to put together the xi list and 
the item list.

I can volunteer to write this stuff, but could it be possible that we can put 
the source for this in the CVS (even if it is still in word) so that we can get 
some speed up on the editing? I'm not fond of the "centralized" editing we've 
been doing on this document.

OTHER CHANGES TO TCP-09
---
(mostly structural changes, since we kind of rushed out -09 for the draft 
deadline and me and Ghyslain had different opinions on how to divide the chapters)

- 4.6.1 should be 4.7.
- "5.1.4.2. Optional Acknowledgements (ACKs), Upward Transition", why have the 
word "optional" in the section title, the fact that they are optional is 
probably enough to have in the section text itself.
- "5.1.4.4. Negative ACKs (NACKs), Downward Transition" - is the text and title 
correct? A NACK does not necessarily take the compressor to IR-state, a 
STATIC-NACK does. A regular NACK will just require an IR-DYN to be sent. Need to 
polish this text to cover both types of nacks.
- Should we really mention k_1/n_1 and k_2/n_2 for the downward transitions. We 
know that putting names to these things caused quite awkward discussions in 
certain other standards bodies (no names), so why not just talk about 
"confidence that context is invalid" or something like that. The k_1 stuff is 
too much of an implementation choice to be mentioned.
- I know this was discussed on the list a couple of years ago, but why do we 
need "5.1.5.  State Machine Supporting Context Replication"? This state machine 
is already described in the CR draft itself.... Maybe I should extend this 
question to "why do we even need any state machines, they just describe a 
specific way of implementing things and not actually much normative logic", but 
maybe some people want states to be able to relate to 3095 (where they are 
equally pointless)?
- Move section 7.1 (chains) to before 6.1
- Move section 7.2 to either inside 6.1 or to a new section directly before 6.1.
- Move section 6.2 (feedback considerations) somewhere inside section 5, perhaps 
combine it with feedback logic in 5.2.7?
- Rename section 6.3 from "Control Fields..." to something like "Context 
Persistent Fields" due to the (silly) change of the meaning of control_fields in 
the FN. Otherwise, we're overloading the term.
- Section "6.5 Initialization" should be section in 5. Seems like it really 
covers the same territory as to 5.1.1 and 5.2.4 and should be merged in there 
somehow.
- Rename section 6, but to what? "Fields encodings and Context"? It will only 
contain the profile-specific encodings, the control fields and the crc section 
with the changes above.
- Rename section 7 to "Structure of ROHC-TCP Packets" or something else (if the 
above is done, then we only have 7.3-7.5 here, which seems like a good chapter 
division.
- Is it really a point in dividing the FN-definitions in section 8.2-8.9 into 
sections? Isn't that like dividing MIB code into sections (and at least the 
ROHC-MIB is not divided that way)? After all, this is code, even if it is our 
own make-belive FN language!
- Next time the tcp-pf.txt is copied into the draft, DO NOT remove the box 
notation (for all the people I have made read the document, I've had to give 
them the tcp-pf document so that they could get easy reference to how things 
work), and DO NOT remove the initial part of the file with the references to 
profile-specific encodings.
- Swap places of 8.9.2.6 and 8.9.2.7

It the source ends up in the CVS, I can take a stab at editing most of these 
changes the next few days so we can get some progress after standing still with 
this document for quite some time now.

Comments, please!

BR,
	Kristofer Sandlund, Effnet AB

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

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Thu, 21 Apr 2005 11:04:15 +0200

> I can volunteer to write this stuff, but could it be possible 
> that we can put the source for this in the CVS (even if it is
> still in word) so that we can get some speed up on the editing?
> I'm not fond of the "centralized" editing we've been doing on
> this document.

Kristofer,

Feel free to discuss with the editor about helping out with the
editing of this document, but it is up to the editor how to do
this. I will hold the editor responsible for all changes, and
for making sure that all changes are based on what has been
agreed, even if he gets help from others with writing text.

Rgds,
/L-E (Big chair hat on)

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Mon, 25 Apr 2005 15:18:16 +0200

Kristofer,

Sorry for not responding quicker, but here are now some comments!

> - 7.2.4 should not have any references to ROHC-FN.

Agree!

> - New section between 7.2.3 and 7.2.4 describing the format 
> of type 0 lists header in box notation. Must also describe
> how to put together the xi list and the item list.
> 
> I can volunteer to write this stuff...

Yes, this is needed, I guess we would all appreciate text input.

> - "5.1.4.2. Optional Acknowledgements (ACKs), Upward 
> Transition", why have the word "optional" in the section 
> title, the fact that they are optional is probably enough to
> have in the section text itself.

Agree!

> - "5.1.4.4. Negative ACKs (NACKs), Downward Transition" - is 
> the text and title correct? A NACK does not necessarily take
> the compressor to IR-state, a STATIC-NACK does. A regular
> NACK will just require an IR-DYN to be sent. Need to 

Agree, maybe the description based on "states" is not really
what we want to have. We have discussed this before, and the
whole concept of states and state machines has imho caused
more confusion than it has helped.

> - Should we really mention k_1/n_1 and k_2/n_2 for the 
> downward transitions. We know that putting names to these
> things caused quite awkward discussions in certain other
> standards bodies (no names), so why not just talk about 
> "confidence that context is invalid" or something like that. 
> The k_1 stuff is too much of an implementation choice to be
> mentioned.

Yes, I fully agree with you.

> - I know this was discussed on the list a couple of years 
> ago, but why do we need "5.1.5.  State Machine Supporting
> Context Replication"? This state machine is already
> described in the CR draft itself.... Maybe I should extend
> this question to "why do we even need any state machines,
> they just describe a specific way of implementing things
> and not actually much normative logic", but maybe some
> people want states to be able to relate to 3095 (where
> they are equally pointless)?

Oooops, as I just said above, I have the same feeling about
the descriptive concept with states. We should learn from 
our mistakes with 3095 and get rid of this.

> - Next time the tcp-pf.txt is copied into the draft, DO NOT 
> remove the box notation (for all the people I have made
> read the document, I've had to give them the tcp-pf document
> so that they could get easy reference to how things work),
> and DO NOT remove the initial part of the file with 
> the references to profile-specific encodings.

Agree, we should have the formats also in box notation, so
that also ordinary humans can read this specification and get
something out of it.

BR
/L-E

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Thu, 28 Apr 2005 09:52:00 +0200

Just some quick notes... inline.

/Ghyslain

> our mistakes with 3095 and get rid of this.

I _totally_ agree! I did fiercely defend this point of view a while ago, also pointing out that state are only a pedagogical mean of explaining some concepts, until the wg actually decided that this had to be in. It was mostly after R. Price and M. West having insisted a lot that these should be in. But I'm happy if we can make this go away again.

> that also ordinary humans can read this specification and get

I disagree, for the simple reason that this means that we've failed with the aspect of having a formal notation that is readable and understandable. Having both augments the risks of discrepency between both notations and the risk of errors. When one would review, I am afraid that only one notation would be looked at, and not the other. If there are discrepencies, we might miss errors somewhere in the process. So, I "vote" for not having both notations in there at the same time. If you want to push the case for the "other" notation, then that is a different topic.

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Thu, 28 Apr 2005 15:09:42 +0200

> I disagree, for the simple reason that this means that we've 
> failed with the aspect of having a formal notation that is 
> readable and understandable. Having both augments the risks 
> of discrepency between both notations and the risk of errors. 
> When one would review, I am afraid that only one notation 
> would be looked at, and not the other. If there are 
> discrepencies, we might miss errors somewhere in the process. 
> So, I "vote" for not having both notations in there at the 
> same time. If you want to push the case for the "other" 
> notation, then that is a different topic.

I just cite Kristofer:
"for all the people I have made read the document, I've had
to give them the tcp-pf document so that they could get easy
reference to how things work"

Many of us can much easier build an understanding from
pictures, FN descriptions are not easy to "see how it
works" from. Yes, we have failed with many of our intensions
with the FN, but I do not think we will remove it, so the
question is not about one or the other. 

But of course, we should draw the box notation from the FN,
then it will help with reviewing the formats rather than the
opposite.

/L-E

---

From: "Finking, Robert" <[email-masked]>
Date: Thu, 28 Apr 2005 14:14:51 +0100

> -----Original Message-----
> From: Lars-Erik Jonsson (LU/EAB)  
> 

Agreed!

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Fri, 29 Apr 2005 08:52:40 +0200

I am not saying that it might not be helpful for the reader, of that it cannot be made clear what part is normative or not, I am simply saying that it does not belong to this document and that it should "live" somewhere else.

Also my concerns as the editor of the TCP draft.

> dealbreaker for me if we 
> don't have them there either.

Then let's remind everyone where the box notation pf are (a link to the CVS?)

/Ghyslain

> From: Kristofer Sandlund [mailto:[email-masked]]
> Sent: den 28 april 2005 16:58
> To: Ghyslain Pelletier (LU/EAB)
> Cc: Lars-Erik Jonsson (LU/EAB); [email-masked]
> Subject: Re: [rohc] Proposed changes to rohc-tcp-09
> 
> 
> While I understand your concern about having to have two 
> things to verify, I 
> think that is mitigated by the fact that the box notation in 
> this case are FN 
> comments, and therefore not in any way normative.
> 
> I think we will be helping the reader out a lot by keeping 
> the box in the 
> document, and it should be clear for anyone who has read the 
> FN draft which part 
> is normative and which is just comments, but it's not a 
> dealbreaker for me if we 
> don't have them there either.
> 
> BR,
> 	Kristofer
> 
> Ghyslain Pelletier (LU/EAB) wrote:
> > The point is not about now chosing to switch to box 
> notation, the point is that we decided to use FN for TCP.
> > 
> > So, since what is in a draft is ultimately what should 
> consist into the specification in the end, I cannot 
> understand why we would have BOTH box notation AND FN to 
> describe the TCP packet formats. For sure, both CANNOT be 
> normative (or?).
> > 
> > The TCP profile is a specification, not an explanatory 
> document whose purpose is to explain FN in yet another manner 
> than the FN draft does. Furthermore, we then need to MAINTAIN 
> two packet format descriptions, which I think is insane and 
> can lead to discrepencies.
> > 
> > If YOU want to have the TCP profile represented using the 
> box notation, than submit this as an informational draft and 
> synch it with releases of the TCP profile, with the mention 
> "informational". Then if the group wants to have this 
> document live further and be informational RFC than that will 
> be fine with me.
> > 
> > Anywho, this is my opinion.
> > 
> > /Ghyslain  
> > 
> > 
> >>Sent: den 28 april 2005 15:10
> >>To: Ghyslain Pelletier (LU/EAB); Kristofer Sandlund; [email-masked]
> >>Subject: RE: [rohc] Proposed changes to rohc-tcp-09
> >>
> >>
> >>

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Fri, 29 Apr 2005 09:04:06 +0200

> I am not saying that it might not be helpful for the reader, 
> of that it cannot be made clear what part is normative or 
> not, I am simply saying that it does not belong to this 
> document and that it should "live" somewhere else.

This is where we seem to disagree. If it is useful to the
reader of the TCP profile, I believe the profile RFC is
where it should be.

> Then let's remind everyone where the box notation pf are (a 

The CVS is an unofficial non-archive, useless in the long run.

I agree with Kristofers note that the box notation would be
"comments", it is like a picture visualizing the normative
text (which is the FN description).

/L-E

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Fri, 29 Apr 2005 09:52:32 +0200

Please comment on what is wrong with my constructive proposal of maintaining this kind of pictoresque "dual" representation in a separate draft that would live as informational. The reasons for this is 1) maintainability of the TCP spec 2) scope of the TCP spec 3) the TCP spec is (and is meant to) a complete specification without redundant explanations using box notation.

Furthermore, box notation cannot say as much as the formal notation does, which means that in any case you'll need to look at the FN (also since this is the mandatory part of the pf). As such, once a reader as read and understood the FN (which is one of our objectives), I think that the pf should be understandable and readable.

So, once again, I'd like to stand firm by my opinion that any pictorials of the packet formats as comments should live outside the TCP specs, as they don't make up the specification itself.

/Ghyslain

> Sent: den 29 april 2005 09:04
> To: Ghyslain Pelletier (LU/EAB); 'Kristofer Sandlund'
> Cc: [email-masked]'

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Fri, 29 Apr 2005 11:26:30 +0200

Box pictures would be only a visualization of the formal and
complete description given by the FN description. As such, I
think it serves the reader better when presented along with
the FN descriptions within the TCP profile specification.

It does not change the scope of the TCP profile in any way,
and it does not provide any formal redundancy. I am not
asking for complementary textual description of the content
of the formats, like we had in e.g. 3095. The complete formal
definitions are fully covered by the FN descriptions. I am
NOT asking for adding formal redundancy.

/L-E

> From: Ghyslain Pelletier (LU/EAB) 
> Sent: den 29 april 2005 09:53
> To: Lars-Erik Jonsson (LU/EAB); 'Kristofer Sandlund'
> Cc: [email-masked]'
> Please comment on what is wrong with my constructive proposal 
> of maintaining this kind of pictoresque "dual" representation 
> in a separate draft that would live as informational. The 
> reasons for this is 1) maintainability of the TCP spec 2) 
> scope of the TCP spec 3) the TCP spec is (and is meant to) a 
> complete specification without redundant explanations using 
> box notation.
> 
> Furthermore, box notation cannot say as much as the formal 
> notation does, which means that in any case you'll need to 
> look at the FN (also since this is the mandatory part of the 
> pf). As such, once a reader as read and understood the FN 
> (which is one of our objectives), I think that the pf should 
> be understandable and readable.
> 
> So, once again, I'd like to stand firm by my opinion that any 
> pictorials of the packet formats as comments should live 
> outside the TCP specs, as they don't make up the specification itself.
> 
> /Ghyslain
>

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Fri, 29 Apr 2005 13:31:54 +0200

> > in a separate draft that would live as informational. The 

I'd like to restate my above point, which you are not addressing. The scope of what you're after is IMHO for another document...

> complete description given by the FN description. As such, I

I understand that. That does not make it any better.

What you ask still only provides (redundant) information on the bit arrangement, which is quite easily deduced already from the list of fields in the format. On top of this, we already have commented annotations in the ROHC-TCP draft to help with bit arrangements...

The question is if this is necessary to be in the ROHC-TCP draft, also once one as read and understood the FN. I don't think so.

> the FN descriptions within the TCP profile specification.

This is a matter of opinion. But then you're free to provide this as a separate draft and drive it as an informational document.

> and it does not provide any formal redundancy. I am not

In practice, it _does_ mean redundancy in the specification anyway.

> of the formats, like we had in e.g. 3095. The complete formal

This means that this (redundant) information is incomplete, and the reader still needs to read and understand the FN. To what point then?

> NOT asking for adding formal redundancy.

I understand that. Should be clear from previous mail.

Anyways... Over and out for me on this one - get consensus first.

/Ghyslain

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Fri, 29 Apr 2005 14:22:26 +0200

> Anyways... Over and out for me on this one - get consensus first.

This is a little bit hard to judge, I think. You are the only one
opposing having the box notation in the profile along with the FN
formats, while Robert has said "agreed", and me and Kristofer are
the ones who want this to be there.

If I was to see some kind of rough consensus in this, it would be
that only one person is opposing while more than one is asking for
it. However, I do not think I would like to conclude based on these
few and diverse opinions.

/L-E

---

From: "Finking, Robert" <[email-masked]>
Date: Wed, 4 May 2005 10:24:40 +0100

Hi All,

Just to clarify my opinion on this one: as far as I'm concerned, the box notation is an FN comment, and so is part of the FN description, just like any other useful comment - no problem there.

I think the box notation is useful if it makes the FN easier to digest. My only concern is the maintenance/correctness issue with making sure the box notation accurately reflects what the FN says. I strongly agree with L-E that the box notation should be derived from the FN, definitely not the other way around!

Regards

Raffles

> [mailto:[email-masked]] 
> Sent: Friday, April 29, 2005 1:22 PM
> To: Ghyslain Pelletier (LU/EAB); Kristofer Sandlund
> Cc: [email-masked]