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

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

Robert,

Comments on your comments...we mainly seem to agree. "let" will
probably be the hardest issue to solve.

> 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.

> > - 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...

OK, I can not remember having seen that discussion on the list...

> > 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".

Why not, if there are two things. However, one may also
question the need for both. The way you use let in the appendix
B example makes very much sense to me. I agree you need to 
create the relation to/from control fields, and let seems to
be a proper name. 

But it is not clear to me why you would have to have the "if"
functionality in the FN, i.e. the process to choose which
format to use. Ok, it might be useful, but not necessary, and
if you have it, I am pretty sure it will be hard to convince
me that it should not be spelled out as an independent statement.

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. 

> The way the maths works, "let" automatically also performs
> the "if" functionality. 

This is not about mathematics, it is about capturing HC packet
formats. 

> > - 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. 

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.

> > - 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. 

After re-reading the draft again, including appendix B, I agree
it seems to be fully up-to-date, and it is indeed very useful. 

> > - 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? 

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.

> > - 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.

I think the examples are really needed to make this document fly,
but examples must be easily followed and explained. Here, I believe
you just have to use field naming that is proper, i.e. co must use
names either from uc or control_field.

> > - 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! 

OK, now I see, hmmm....confusing...

> I'll try to think of a way of clarifying this.

Yes, I think you should try to do that.

> > - 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?

Hmmm.....ok, true....maybe you should just pick a better field
example, something that is *clearly* a field. When you dig deep
into it, you can understand it, but it should be understandable 
also when you just read it through for the first time, IMHO.

> > - 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.

Ok, true, then it will be 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.

I read what you say and agree with you, but I do not see that it
makes any difference. Anyway, I leave it up to you!

> > - 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.

I guess there is nothing that is more correct than anything else,
do as you like!

/L-E

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

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 25 Feb 2005 11:57:28 +0100

On Feb 25 2005, at 10:01 Uhr, Lars-Erik Jonsson (LU/EAB) wrote:

> 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.

Gruesse, Carsten