[forces] FW: New Version Notification for draft-ietf-forces-model-extension-05.txt

["Haleplidis Evangelos" <[e-mail]>]

Greetings to the list,

The model extension draft was updated yesterday. There was a small issue with the default values for datatypes, but with the help and suggestions by Joel this was resolved.

The problem was that allowing typeRef and atomic values to have default values directly could create confusion and didn't make sense, as you may had multiple default value definitions in one place (e.g. if you created an LFB component this is atomic and both could have default values). 

So, the solution, suggested by Joel, was to move the default value from typeRef and atomic to the dataTypeDefinition altogether, similar to the component definition in LFBs.

So in effect the goal of having default values in datatypes is achieved in a simpler and cleaner way.

Now, there is a small overhead penalty. In order to define, e.g. a struct with 5 components with different default values, a developer would have to create 5 new datatypes. However the simplicity and gains are better that the alternative. In addition this scheme supports hierarchical default values. E.g. Define an data type once (e.g. an IPv4 address), and reuse it to define different default values as different datatypes as needed (localhost, broadcast, etc.). 

Examples are provided in the draft.

On a final notice, the following formal restrictions on default values were defined in order to remove ambiguity:

   1.  Default Values MUST be ignored if the data type is not an atomic
       or a base data type.

   2.  When a datatype X with default value A is referenced from a
       datatype Y with a default value B, the default value of the
       datatype that references overrides the referenced default value,
       e.g. in this case Y's default value will be B.

   3.  Default Values of LFB components overrides any default value
       specified from the dataTypeDef definition.

   4.  Default Values of datatypes reference in capabilities or metadata
       MUST be ignored.

Regards,
Evangelos Haleplidis.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Friday, September 12, 2014 12:57 AM
> To: Evangelos Haleplidis; Evangelos Haleplidis
> Subject: New Version Notification for draft-ietf-forces-model-
> extension-05.txt
> 
> 
> A new version of I-D, draft-ietf-forces-model-extension-05.txt
> has been successfully submitted by Evangelos Haleplidis and posted to
> the IETF repository.
> 
> Name:		draft-ietf-forces-model-extension
> Revision:	05
> Title:		ForCES Model Extension
> Document date:	2014-09-11
> Group:		forces
> Pages:		30
> URL:            http://www.ietf.org/internet-drafts/draft-ietf-forces-
> model-extension-05.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-forces-
> model-extension/
> Htmlized:       http://tools.ietf.org/html/draft-ietf-forces-model-
> extension-05
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-ietf-forces-
> model-extension-05
> 
> Abstract:
>    This memo extends the Forwarding and Control Element Separation
>    (ForCES) model defined in RFC 5812 and updates RFC5812 to allow
>    complex datatypes for metadata, optional default values for
>    datatypes, optional access types for structures.  It fixes an issue
>    with Logical Functional Block (LFB) inheritance.  It also introduces
>    two new features a new event condition BecomesEqualTo and LFB
>    properties.  The changes introduced in this memo do not alter the
>    protocol and retain backward compatibility with older LFB models.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> The IETF Secretariat