Subject: [rohc] AD evaluation of draft-ietf-rohc-formal-notation-12

From: Magnus Westerlund <[email-masked]>
Date: Fri, 08 Dec 2006 14:11:18 +0100

Hi,

I have reviewed formal notation and have few comments. In general the 
document is quite readable and easy to understand for being a definition 
of a formal notation.

1. Section 4.9: Enforce statements.

It is not clear here that all ENFORCE statements within a particular 
scope have an OR relation to them. I think that needs clarification in 
this section.

2. Section 4.11.6:

"  Usage of the "THIS" keyword (see Section 4.6) as shown in the example
    above, is typical when using "crc" encoding.  It causes the CRC to be
    calculated over all fields in the header."

First of all I think the usage of "header" in the last sentence in the 
above paragraph is wrong. Because this depends on which scope "THIS" 
has. From the example above you can't determine a particular scope as 
you don't see the full definition of the encoding.

3. B.5, In the example for encoding obvious you haven't changed the 
sequence_no =:= lsb(0,-3) to sequence_no =:= lsb(2,-3). To me it seems 
that it should have been changed after the discussion in the last 
paragraph of Section B.4. The alternative I see which may be more clear 
would actually to include in B.4 at the end the corrected example.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

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

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 8 Dec 2006 14:40:37 +0100

On Dec 08 2006, at 14:11, Magnus Westerlund wrote:

> Hi,
>
> I have reviewed formal notation and have few comments. In general  
> the document is quite readable and easy to understand for being a  
> definition of a formal notation.
>
> It is not clear here that all ENFORCE statements within a  
> particular scope have an OR relation to them. I think that needs  
> clarification in this section.

The ENFORCE statements have an AND relationship to them, i.e., each  
and all of them must be fulfilled for a format to succeed.

To me, this is reasonably clear from the statement:

    There are three possible conditions that the expression may be in:

    1.  The boolean expression evaluates to false, in which case the
        local scope of the format that contains the "ENFORCE" statement
        cannot be used,

I.e., one of them evaluating to false makes the format fail.
This is exactly the definition of a conjunction, i.e., an AND  
relationship.

See also 4.12.1.1 (but this only talks about uncompressed formats;  
the same is true of compressed formats).

But it would not hurt to add this clarification in a note or in  
introductory text.
E.g., 4.9 could start with

NEW:
   "ENFORCE" statements provide a way to add predicates to a format,  
all of which must be fulfilled for a format to succeed.

As another editorial improvement, this would also say what they are  
good for before delving into what they are like.

> First of all I think the usage of "header" in the last sentence in  
> the above paragraph is wrong. Because this depends on which scope  
> "THIS" has. From the example above you can't determine a particular  
> scope as you don't see the full definition of the encoding.

Good catch.
I didn't flag this because I thought that at this point it should be  
clear how THIS needs to be used for this to be true but, again, this  
is a useful clarification.

Proposal:
OLD:
It causes the CRC to be
    calculated over all fields in the header.
NEW:
E.g., when used in the encoding method for an entire header, it  
causes the CRC to be
    calculated over all fields in the header.

> sequence_no =:= lsb(0,-3) to sequence_no =:= lsb(2,-3). To me it  
> seems that it should have been changed after the discussion in the  
> last paragraph of Section B.4. The alternative I see which may be  
> more clear would actually to include in B.4 at the end the  
> corrected example.

It might be sufficient to just introduce the line:
          sequence_no   =:= lsb(2, -3);
at the end of B.4 (and fix the line in B.5, of course).

Gruesse, Carsten

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Fri, 8 Dec 2006 15:04:06 +0100

Magnus, Carsten,

Thanks for your comments; the resolution proposed by Carsten is ok with
me.

Magnus - do you want us to produce an updated draft already for this, or
can we wait?

///Ghyslain

Carsten Bormann wrote:
>> document is quite readable and easy to understand for being a
>> scope have an OR relation to them. I think that needs clarification
>> in this section.
> 
> The ENFORCE statements have an AND relationship to them,
> i.e., each and all of them must be fulfilled for a format to succeed.
> 
>         local scope of the format that contains the "ENFORCE"
>         statement cannot be used,
> 
> See also 4.12.1.1 (but this only talks about uncompressed
> formats; the same is true of compressed formats).
> 
> But it would not hurt to add this clarification in a note or
> in introductory text.
>    "ENFORCE" statements provide a way to add predicates to a
> format, all of which must be fulfilled for a format to succeed.
> 
> As another editorial improvement, this would also say what
> they are good for before delving into what they are like.
> 
>> 2. Section 4.11.6:
>> 
>> "  Usage of the "THIS" keyword (see Section 4.6) as shown in the
>>    example above, is typical when using "crc" encoding.  It causes
>>    the CRC to be calculated over all fields in the header."
>> 
> I didn't flag this because I thought that at this point it
> should be clear how THIS needs to be used for this to be true
> but, again, this is a useful clarification.
> 
> Proposal:
> OLD:
> It causes the CRC to be
> E.g., when used in the encoding method for an entire header,
> it causes the CRC to be

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 08 Dec 2006 15:13:45 +0100

> Thanks for your comments; the resolution proposed by Carsten is ok with

And with me.

> Magnus - do you want us to produce an updated draft already for this, or

Please produce a new draft. That way I can go to IETF last call as soon 
as the draft becomes available.

Cheers

Magnus Westerlund