Subject: RE: [rohc] Comments on ROHC-FN -05 (draft-ietf-rohc-formal-notati on-05.txt)

From: "Finking, Robert" <[email-masked]>
Date: Thu, 24 Feb 2005 16:16:42 -0000

Hi All,

Thanks L-E. Wow what a great review! You obviously put a lot of time in -
much appreciated. Comments in-line.

For the non contentious changes I'll assume everybody is happy me doing them
unless I hear otherwise (this is just to avoid everybody having to post
saying "yes I agree we should insert a comma here"). The other ones we can
discuss.

Regards

Munch

From: Lars-Erik Jonsson (LU/EAB) 
Sent: Wednesday, February 23, 2005 3:54 PM
> 
> 
> I've reviewed the FN draft and I can notice that it has improved
> significantly during the last year. It is today both clearer what
> is the actual purpose of the notation, how it works, and how it is
> supposed to be used, and it is more compact than ever (actually

Thanks, and thanks for your part in helping get it where it is!

> only 32 pages). However, we are not finished with it yet, and my
> comments are the following:
> 
> 
> More significant issues:
> 
<snip>
>   I therefore propose to update the second part of 3.1 (from "Each
>   ROHC profile...") with something along these lines:
<snip>

I'm happy with this if everybody else is. 

> 
>   The Terminology->Profile should then also be updated so that it does
>   not overload the profile definition in 3095, based on the 
> above text:
>     
>     "A ROHC (RFC 3095 [4]) profile is a description of how to compress
>      a certain protocol stack over a certain type of link. Each
>      profile is built up of packet formats (defining the bits on the
>      wire) along with a set of rules that control compressor and
>      decompressor behavior."

Good point - overloading of terms is always bad news. Can we think of
another word that captures succinctly "the formal notation description part
of how to compress a certain protocol stack over a certain type of link".
I'll start the ball rolling with "Fonpacod" (FOrmal NOtation Packet
COmpression Description). Or how about "Kevin"? I've always thought that's
not a bad name =) Seriously though, we should think of a new term (assuming
there is no consensus on Kevin).

> 
> - Let statements:
>   I find the let statements rather confusing. First of all, 
> the name is
>   not very informative, and the use of let seems to be twofold. The 
>   general purpose (as described) seems to be to assert, so 
> why not call
>   it "assert" or "if" instead, that would make the name much more 
>   informative.

We did have a discussion about this a while back and did indeed consider
both of those alternatives...

> However, from how I read the third bullet on page 17,
>   let seems to be used also for a non-assert purpose, so 
> maybe we should
>   have a let statement also, for that purpose.

Right. That's why we decided to call it "let" I think - the other two names
don't really reflect this purpose, though depending on how you read "assert"
I guess that does have that sort of feel to it too. It doesn't really make
sense to me to have two separate statements, one for "let" and one for "if".
The way the maths works, "let" automatically also performs the "if"
functionality. Also, how would overriding work for "if" statements? IIRC we
did discuss the possibility of doing this, but decided not to. Still that
was probably off-list. I'm happy for us to revisit this if anybody can
suggest some good alternatives.

>   This third  bullet really
>   confused me, and I do think we will have to redefine/rewrite this
>   part!!! The assert purpose is not very clear on a general level, it
>   is useful to be able to capture the conditions for when a format can
>   be used, but then we should explain better that this is part of the
>   notation, and also make the mechanism more intuitive. It is never 
>   defined anywhere what it really means that a format "succeeds".

Good point! We should definitely make this clearer.

> 
> - Section 4.8 is to me mainly stating a number of obvious 
> things, and by
>   having a section like that it created more questions than 
> it answers.
>   The FN itself has no productive value before it is actually 
> used in a
>   profile specification, and then the scope of that usage is of course
>   local to that profile specification. I propose to basically keep the
>   content of the first paragraph of 4.8, but rewrite the rest and make
>   the whole section much shorter, e.g. to have the following 4.8 text:
<snip>

Fine by me as long as everybody else is happy (FBMALAEEIH)

> 
> - Appendix A: Can this appendix really be justified to keep in the
>               document, I can not see that it is needed. I would say
>               we should remove it.

I think it's essential as it gives a formal definition of the syntax of the
notation. Though it does need updating. Also I'd like to depart from the
horrible ABNF if possible, since it makes false assumptions about the syntax
of the language before you start, which means you end up jumping through
hoops. 

> 
> - Appendix B: Is this appendix up-to-date? And should we 
> still keep it?
>               The TCP profile is also an example, although it is much
>               more complicated. I do not have a clear opinion, what do
>               others think?
> 

Yes, it's up to date. At least it should be. 

> 
> Nits, editorials, and other minor issue:
> 
> - Abstract: Remove the reference, i.e. replace:
>      "...ROHC (RFC 3095 [4])..."
>   with:
>      "...ROHC (RFC 3095)..."
> 

OK

> - Terminology->Field: It is not the FN that divides the header
>                       into fields, that is something the profile
>                       designer do. But FN *operates on* fields.
>   I suggest replacing the Field definition with something like:
>      "ROHC-FN is to be used to define the mapping between uncompressed
>       and compressed headers in ROHC profile specifications. It is
>       applied to a set of contiguous bit patterns, commonly 
> referred to
>       as fields. It should be noted that how the header is 
> divided into
>       fields is decided by the profile designer, and must not
>       necessarily be identical to the one given by the 
> specification(s)
>       for the protocol header being compressed."

Sounds good =)

> 
> - Last sentence in 3.2.1 says "Otherwise, the binding will fail and an
>   alternative encoding method must be used". However, the 
> text is in the
>   decompressor text, but should instead be part of the 
> compressor text.
>   The consequence of an unsuccessful binding at the decompressor is
>   rather that the packet will have to be discarded, and the context
>   probably invalidated (but that is part of the profile logic to
>   specify).

This is not correct is it? If you have 5 different packet formats and the
first one you try to decompress your packet with has static encoding for a
particular field, and that fails, then you just try one of the other four
packet formats don't you? However, I agree that this is a bit confusing, so
I suggest we drop the end of the sentence (from and onwards): it is not
necessary to mention it.

> 
> - Section 3.2.2:
>   * It is unclear whether "structure is a reserved word", better to
>     use e.g. "example_structure === ..."
>   * The field names confused me, why 1,2, etc and then a,b, 
> etc? Should
>     not all field_* be a,b,c...etc?

Sure OK. Actually, I can't help wondering if this example isn't too
prototypical in general. It's not really a very realistic example, but it's
not a prototype either. But then, maybe it's a good mix of the two - or
maybe it fails at both! What does everyone else think? I feel it's got a bit
big and unwieldy.

> 
> - Second paragraph on page 9, add comma and replace "an" with 
> "a", i.e.:
>   "In the example, packet formats defined by "co_format" also 
> indicate a
>    list of..."

OK

> 
> - Third paragraph on page 9, add a "not" on the third line:
>   "...but which do not have an..."
>                    ^^^

No, the current meaning is correct, though I guess not clear enough! You
only have to specify a field in the control field list if it has an
uncompressed value. Fields like CRCs, or the various flags used in the TCP
profile, which don't have an uncompressed value do not need to appear in the
control field list. I guess it is easy to read that as "but do appear in the
uncompressed header", but that is not what the text says! I'll try to think
of a way of clarifying this.

> - What happened to the last paragraph of section 3.2.2???
> 

Err, um, aliens abducting the bits in transit? Trampled by marauding
wildebeest. Tipex spillage incident =) Government cover-up. Thanks for
pointing it out =)

> - Last paragraph of section 4.2, add comma x2:
>   "Because the FN is referentially transparent, constants are entirely
>    equivalent to the value they refer to, and are completely
>    interchangeable with that value."    ^     ^
>                                         ^     ^

OK

> - Second last paragraph of 4.3, remove "it":
>   "...appear in it the uncompressed header."
> 

How did that sneak in there?? =)

> - Section 4.3.1, just an observation: Could we have a better example 
>   than a control fields, and maybe make clearer where attribute ref's 
>   would be useful?

OK

> 
> - Third paragraph of 4.4, remove "it":
>   "...appear in it the uncompressed header."

Dang, that's one persistent "it" =)

> 
> - End of 4.4, please explain also WHY the tcp_list_length example is
>   illegal, one sentence after the example.

The explanation is in the preceding paragraph! I guess we could rearrange
the order?

> 
> - Section 4.4.4, second bullet "down to the next lowest" 
> sounds strange:
>   Suggestion: "...down to the nearest integer."
> 

OK, I guess the meaning is still obvious, though less precise.

> - Last paragraph of section 4.6, replace "then" with "them"
>   "...when inserting them into the..."
> 

OK

> - Section 4.7, suggest to rename to:
>   "Library of Encoding Methods" or "Encoding Methods Library"
> 

OK

> - End of section 4.7.1: Explain what nbits is in the example.
> 

OK

> - 1st sentence of section 4.9.2.1, should "that" be replaced 
> by "they"?
>   "...in the order they appear in..."

Sure, replaced by or followed by. Thanks

> 
> - End of third paragraph of section 4.9.2.1, missing "least"??
>   "...to represent the least significant part."

No that part is the significant part, the other part is the insignificant
part. I shall try to work the word "insignificant" into the first half of
the sentence.

> 
> - 1st paragraph of section 4.9.4.3, second sentence: Some words are
>   missing here, it says:
>   "...if no encoding method for that field elsewhere."
> 

LOL - thanks =)

> - Explain the example in 4.9.4.3, specifically, what is the effect of
>   the let statement there?

OK

> 
> - I do not know, but the last part of 4.9.4.3 is not very 
> clear to me, 
>   where default method overriding, and "uc_format" field 
> encoding lists.
> 

I'll have a think. Any suggestions for alternative words from anybody
are welcome.

> - Section 4.9.4.4, last sentence, should an "also" be added?

I agree it would make the meaning clearer, thanks.

> 
> - Section 4.9.5, first sentence, should it not be "any field", not
>   "any fields", i.e. remove "s"?

Good catch, actually it is "specifies" which should be "specify" (looking at
the rest of the sentence), but yes the word endings do not agree with each
other.

> 
> - Second paragraph of section 4.9.5 is actually discussing a potential
>   profile design choice. I suggest rewriting it as follows:
> 
>   "For example in IP, the behaviour of the IP-ID field in a 
> flow varies
>    depending on how the endpoints handle IP-IDs. Sometimes 
> the behaviour
>    is effectively random, sometimes the IP-ID follows a predictable
>    sequence, and at other times it stays fixed at zero. How the IP-ID
>    behaves is information that is never communicated explicitly in the
>    uncompressed header, but a ROHC profile can still be designed to 
>    identify the behavior and adjust the compression strategy 
> according 
>    to the identified behavior, thereby improving the compression
>    performance. To do so, the profile can introduce an explicit field
>    to communicate the IP-ID behaviour in compressed headers, and in
>    ROHC-FN terms this is done by introducing a control field:"

OK

> 
> - The second example in 4.9.5:
>   * "format" should be "co_format_***", right?

Dang nabbit, ' thought I'd got all o' those pesky formats fixed.

>   * can we have a more specific example name than "ctrl_field", e.g.
>     "scaled_field"

sure =)

>   * "length" should be "uncomp_length", right?

Sheesh, who's been eating my notation?

>   * This example, and also other examples, should have a few words
>     explaining it, so that the example becomes more useful to 
> a reader.

OK

> 
> - "Contributors" sections are usually used when only the editor is
>   listed on the front page, while a number of authors have contributed
>   with text to the RFC. I think this acknowledgement to Richard should
>   be put first in the "Acknowledgements" section, and remove 
> the initial
>   seven words before the comma. 

There was a discussion about this previously. I refer you to
http://www.rfc-editor.org/policy.html#policy.auth2 :

]   1. When the RFC Editor refers to 
]"authors", we mean exactly the set of names 
]listed on the first page of an RFC. These 
]people are considered to be equally 
]responsible for the contents of the 
]document, and all will be asked to read and 
]approve the RFC before publication.
]
]   2. When the RFC Editor refers to 
]"contributors", we mean people, other than 
]the authors, who also contributed 
]significantly to the RFC. They should be 
]listed in a Contributors section of the 
]body of the document.

Richard has certainly "contributed significantly", but is a person "other
than the authors". So it seems to make sense to list him as a contributor.

> 
> - References must be split in Normative and Informative. From 

Yes, I'm a bit puzzled by this. I did look at it last week, but I can't see
a way of doing the split using XML... D'oh! Just looked on the
xml.resource.org website and the very first of the "Helpful Hints" is:

]Normative References
]
]If you need to have multiple references sections....

> looking at
>   them, I conclude that:
>   [1] is never used, remove!
>   [2] is Normative
>   [3] is Informative, as it is only referred to in an 
> informative manner
>   [4] is Informative, as it is only referred to in an 
> informative manner

OK, thanks for the assessment.

> 
> - Add section number also to Authors' Addresses, i.e. section 8
>   (assuming current section 6 is merged into current 7).
>   Also correct Ghyslains address, write it "Lulea".

The section numbering is done automatically. Since other editors use XML
format, and since a special case is made for the author's section in not
numbering it, I assume this is the correct format? If not, I'll post a
question on the xml2rfc list.

> 
> - Check the document for nits at:
>    http://ietf.levkowetz.com/tools/idnits/idnits.pyht

OK, thanks - I'll check that out.

> 
> 
> BR
> /Lars-Erik
> 
> 
> -----------------------------------
> Lars-Erik Jonsson, M.Sc.
> Senior Research Engineer
> Wireless IP Optimizations
> AWARE - Advanced Wireless Algorithm Research
> Ericsson Research, Corporate Unit
> Ericsson AB
> Box 920, S-971 28 Luleå, Sweden
> E-mail: [email-masked]                      /"\
> Phone: +46 8 404 29 61                                      \ /
> Fax: +46 920 996 21               ASCII Ribbon Campaign      X
> Home: +46 920 999 57           against HTML email & vCards  / \
> 
> My opinions are my personal opinions and should not be considered
> as the opinions of my employer, if not explicitly stated.
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> 

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

---

From: "Finking, Robert" <[email-masked]>
Date: Fri, 25 Feb 2005 12:27:20 -0000

Hi L-E,

Thanks for the reply. Thanks for listening to my comments and taking them on
board - glad they were helpful. You're right, we seem to be converging! =)

Comments on points we still have issues with below.

Cheers

Raffles

> > Good point - overloading of terms is always bad news. Can we
> > think of another word that captures succinctly "the formal
> > notation description part of how to compress a certain
> > protocol stack over a certain type of link".
> 
> Actually, I do not know what word you are aiming at replacing. 
> The FN can be used for the packet format part of a profile, I
> do not think we need an additional name for when you use FN in
> that process.

OK, I may have misunderstood your original comment! What I'm seeing here is
that we are now overloading "FN" instead of "profile". Here "FN" can mean
either
  - The packet formats, described in the formal notation, or
  - The formal notation itself.

Within the FN draft, I think it is important to be able to distinguish
between these two, otherwise it could get a bit confusing. Does that make
sense, or have I missed your point?

> > > maybe we should have a let statement also, for that purpose.
> > 
> > Right. That's why we decided to call it "let" I think - the 
> > other two names don't really reflect this purpose, though
> > depending on how you read "assert" I guess that does have
> > that sort of feel to it too. It doesn't really make sense
> > to me to have two separate statements, one for "let" 
> > and one for "if".
> 
> Why not, if there are two things. 

There are not two things, just one - Carsten's comment captures it well I
feel - does that help? Maybe we should include some text like this in the
draft:

Carsten wrote:
]Since encoding methods are bi-directional, what may feel like an 
]assignment in one direction may feel like an if in the other direction; 
]therefore, we came up with just one type of assertion that covers both.

> 
> Personally, I would rather get rid of all the "format fails or
> succeeds" discussions, I see it as a matter of "when is this
> format used", i.e. when does a discriminator mean format A and
> when does it mean format B. That could be an intuitive "if"
> condition, in my opinion. 

OK, I can see that the "format fails" terminology might not be helpful.
Thanks for pointing that out =)

> 
> 
> > The way the maths works, "let" automatically also performs
> > the "if" functionality. 
> 
> This is not about mathematics, it is about capturing HC packet
> formats. 

That's true, all I'm saying is we can capture them without a separate "if"
statement.

> > I think it's essential as it gives a formal definition of the 
> > syntax of the notation. 
> 
> That did not really answer my question. I see Appendix A as
> completely useless, as you could easily make use of the notation
> without it. I am not saying what is in App A is *wrong*, it is
> just IMHO over formalizing things and adding material that does
> not help to solve what FN is solving.

Hmm OK, we seem to differ on this a little (essential vs. useless LOL). For
me it comes down to the fact that this is a *formal* notation, so it really
needs a formal definition! I guess this is a similar issue to the "maths
behind it" comment above. The thing is, you or I can look at some FN packet
formats (a "kevin") and intuitively get a very good idea about what they
mean. The point of having formality is that there is no ambiguity - there is
a formally defined meaning that can be calculated in the event of any
uncertainty. If we treat the FN in an informal way, then we just have
RoHC-N, the RoHC Notation. I'm sure that would satisfy a lot of people, but
my understanding is that it is not what we're aiming for here - we want
something that formally defines a kevin =)

Obviously there is an administrative burden here of making sure the formal
syntax is actually correct - which it isn't at the moment. I'm hoping Eilert
will furnish me with a syntax definition formally checked against the TCP
packet formats at some point! If we can't get a formally verified syntax
then I'd have to agree with you that it might be best to drop it anyway.

> 
> 
> > > - Last sentence in 3.2.1 says "Otherwise, the binding will 
> > >   fail and an alternative encoding method must be used".
> > >   However, the text is in the decompressor text, but should
> > >   instead be part of the compressor text. The consequence
> > >   of an unsuccessful binding at the decompressor is rather
> > >   that the packet will have to be discarded, and the context
> > This is not correct is it? If you have 5 different packet 
> > formats and the first one you try to decompress your packet
> > with has static encoding for a particular field, and that
> > fails, then you just try one of the other four packet formats
> > don't you? 
> 
> As a decompressor, you never have a choice, you get ONE single
> format and has to decompress it. If it fails, you are screwed.
> The compressor on the other hand, of course has to pick a proper
> format, as you describe above.

OK, lets take a step back. How do you know what that single format is? You
have to have a mechanism for selecting that single format. Normally you'd
use a discriminator. The way you then select the right format is that when
the decompressor tries each of the alternatives it finds that the
compressed_value encoding for the discriminator field fails for all but that
one correct format. However, in theory you don't have to use a
discriminator, you could use any mechanism at all that allows the correct
packet format to be selected i.e. any mechanism that causes incorrect
formats to be rejected - there is no theoretical reason why this shouldn't
be the presence or absence of context data needed by lsb and static encoding
methods. Of course to be of practical use, it would be necessary for the
compressor to know exactly what context information was available at the
decompressor.

As an aside, note that the current definition of the FN does not prohibit
the definition of packet formats which give the decompressor multiple
possible formats to use, though the draft does warn that it's not a very
clever thing to do! =) Again, in theory, it doesn't necessarily present a
problem, as long as both formats decompress the compressed header to the
same uncompressed header.

I guess this is a bit of a red herring since I've agreed to delete that text
anyway, but I thought it worth spelling this stuff out to aid understanding
of the FN - it may bring up other issues which need describing in the
document.

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Fri, 25 Feb 2005 13:26:28 +0100

> > format used"
> Note that this is a different question -- the compressor can use any 
> format that succeeds, and which one it selects is a quality of 
> implementation issue.
> 
> Since encoding methods are bi-directional, what may feel like an 
> assignment in one direction may feel like an if in the other 
> direction; 
> therefore, we came up with just one type of assertion that 
> covers both.

I do not see that there is any difference between how compressor
and decompressor see these things.

When we talk about creating a mapping between e.g. a control
field and an uncompressed field, like in the example on page
50, this has the same meaning for both compressor and 
decompresor, it is just that the decompressor has to invert
it when recreating the uncompressed value. This is for sure
what I would call a cler let statement.

However, if we are aiming at identifying when a format is "legal",
or I would rather see it as which format a particular discriminator
corresponds to at a specific time (for discriminators that are used
for different formats depending on context status), that is a
different thing, and also that condition would have the same
meaning for both compressor and decompressor, i.e. which
format the discriminator corresponds to. For the compressor,
it affects which formats are available to use, and for the
decompressor it affects how the received compressed packet is
interpreted. 

Rgds,
/L-E

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Fri, 25 Feb 2005 14:03:04 +0100

Some more comments (my last input this week)...

> OK, I may have misunderstood your original comment! What I'm 
> seeing here is that we are now overloading "FN" instead of
> "profile". Here "FN" can mean either

I can not see that my comments and new text affected this.

> between these two, otherwise it could get a bit confusing. 
> Does that make sense, or have I missed your point?

The FN, as defined by chapter 4, is the notation itself. Then 
we have packet formats expressed in FN, true. But in all packet
format examples in the FN draft, all are defined in FN-form.

Where are you in need of a term for "a packet format defined in FN",
within this document?

> There are not two things, just one - Carsten's comment 
> captures it well I feel - does that help? Maybe we should
> include some text like this in the draft:

As you can see from my answer to Carsten, it did not help at all.
 
> ]assignment in one direction may feel like an if in the other 
> ]direction; 
> ]therefore, we came up with just one type of assertion that 
> ]covers both.

Obviously, we have a total disconnect here, see my answer to Carsten.

> That's true, all I'm saying is we can capture them without a 
> separate "if" statement.

I do not doubt we can, but I disagree it is a good thing. In my
little world, having a mechanism that can do several different
things is about equally as bad as having multiple mechanisms that
can be used to do the same thing.

> Hmm OK, we seem to differ on this a little (essential vs. 
> useless LOL). For me it comes down to the fact that this
> is a *formal* notation, so it really needs a formal
> definition! 

I believe what is in chapter 4 is exactly what is needed to
define unambiguous packet formats using FN. You do not need
appendix A for that.

> Obviously there is an administrative burden here of making 
> sure the formal syntax is actually correct - which it isn't
> at the moment. I'm hoping Eilert will furnish me with a
> syntax definition formally checked against the TCP packet
> formats at some point! If we can't get a formally verified
> syntax then I'd have to agree with you that it might be best
> to drop it anyway.

Makes me even more convinced this is just extra theory we do
not actually need.

> OK, lets take a step back. How do you know what that single 
> format is? You have to have a mechanism for selecting that single
> format. 

Yes, the compressor selects format, the decompressor interprets it.
It is the same condition that tells the compressor "this is the
format you have available since the context disables the alternative",
as tells the decompressor, "the header you just got is this one - 
based on discriminator+context".

> Normally you'd use a discriminator. The way you then select the
> right format is that when the decompressor tries each of the
> alternatives it finds that the compressed_value encoding for
> the discriminator field fails for all but that one correct
> format. 

Yes, that is the same thing expressed in other words. 

> However, in theory you don't have to use a discriminator, you
> could use any mechanism at all that allows the correct packet
> format to be selected i.e. any mechanism that causes incorrect
> formats to be rejected - there is no theoretical reason why 
> this shouldn't be the presence or absence of context data
> needed by lsb and static encoding methods. Of course to be of
> practical use, it would be necessary for the compressor to
> know exactly what context information was available at the
> decompressor.

True, much theory here. Are we seriously aiming at implicitly
indicating different packet formats, i.e. have different
packet formats being indicated by anything but discriminator?
I do not think so, and if that is the case, I strongly object...=)

That's all from me for today, but it is excellent to finally
have these discussion going again!!!

Have a nice weekend!

/L-E