Subject: [forces] FW: New Version Notification for draft-haleplidis-forces-model-extension-00.txt

From: "Haleplidis Evangelos" <[email-masked]>
Date: Tue, 2 Oct 2012 01:06:00 +0300

Greetings to the list,

This draft describes some extensions in the model schema of the LFB library based mostly on the experience of the openflow library.

Comments and suggestions are more than welcome.

Regards,
Evangelos Haleplidis.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, October 02, 2012 12:37 AM
> To: [email-masked]
> Subject: New Version Notification for draft-haleplidis-forces-model-
> extension-00.txt
> 
> 
> A new version of I-D, draft-haleplidis-forces-model-extension-00.txt
> has been successfully submitted by Evangelos Haleplidis and posted to
> the IETF repository.
> 
> Filename:	 draft-haleplidis-forces-model-extension
> Revision:	 00
> Title:		 ForCES Model Extension
> Creation date:	 2012-10-01
> WG ID:		 Individual Submission
> Number of pages: 19
> URL:             http://www.ietf.org/internet-drafts/draft-haleplidis-forces-model-extension-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-haleplidis-forces-model-extension
> Htmlized:        http://tools.ietf.org/html/draft-haleplidis-forces-model-extension-00
> 
> 
> Abstract:
>    Forwarding and Control Element Separation (ForCES) defines an
>    architectural framework and associated protocols to standardize
>    information exchange between the control plane and the forwarding
>    plane in a ForCES Network Element (ForCES NE).  RFC5812 has defined
>    the ForCES Model provides a formal way to represent the
> capabilities,
>    state, and configuration of forwarding elements within the context
> of
>    the ForCES protocol, so that control elements (CEs) can control the
>    FEs accordingly.  More specifically, the model describes the logical
>    functions that are present in an FE, what capabilities these
>    functions support, and how these functions are or can be
>    interconnected.
> 
>    RFC5812 has been around for two years and experience in its use has
>    shown room for extensions without a need to alter the protocol while
>    retaining backward compatibility with older xml libraries.
> 
> 
> 
> 
> The IETF Secretariat

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 2 Oct 2012 06:10:49 -0400

Greetings Evangelos,

My comments:

1) On Complex Metadata
I think this is a useful extension. Can you be more precise as to what in OF
uses complex metadata?

2) DataType and Metadata Optional Default Value

I am not clear on this one.
We can define default values on per component level.
If the component is a complex, this rule still applies to all individual scalar
components within the complex component.
What is missing?

3)  Optional Frame Produced
This sounds to me like an errata.
We allow input to be a packet and/or metadata.
We also allow output to be a packet and/or metadata.
If you can point to which text in 5812 implies that an output
MUST have packet data, then an errata would seem reasonable.

4) Strengthening the XML
Some of these things in our implementation are taken care of by our own tools
because they are common sense (having the same ID for different things is one)
and none of the other ones are a problem in real life; the only ones we cant
catch span multiple xml files (since we dont keep state); having said that
i can see that it would be useful for the schema to catch things when
possible at XML
validation time. Question: Did you actually test the xml changes
against the different
error use cases?

General comment:
I think it would be useful for each use case section to show the
accompanying xml change
piece and then have one large section with all the changes. RFC 5812
illustrates this approach.

cheers,
jamal

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Tue, 2 Oct 2012 14:08:03 +0300

Greetings Jamal,

Thanks for the comments.

Please see inline.

Regards,
Evangelos Haleplidis.

> From: Jamal Hadi Salim [mailto:[email-masked]]
> Sent: Tuesday, October 02, 2012 1:11 PM
> To: Haleplidis Evangelos
> Cc: [email-masked]
> Subject: Re: [forces] FW: New Version Notification for draft-
> haleplidis-forces-model-extension-00.txt
> 
> Greetings Evangelos,
> 
> My comments:
> 
> 1) On Complex Metadata
> I think this is a useful extension. Can you be more precise as to what
> in OF uses complex metadata?
> 

[ΕΗ] From my understanding, OF uses complex metadata in two separate
occasions:
1. The ActionSet metadata, which is a list of actions to be performed at the
end of the pipeline.
2. When a packet is received from a controller it may be accompanied by a
list of actions to be performed on it prior to be sent on the flow table
pipeline.

> If the component is a complex, this rule still applies to all
> individual scalar components within the complex component.
> What is missing?

[ΕΗ] Take for example the FlowTables component in the OFFlowTables.
It's an array, with each row a struct of {
	FlowEntries (array)
	FlowTableCounter (struct)
	MissBehaviour (atomic)
}

Now, the FlowTableCounter is struct of{
	ReferenceCount (uint32)
	PacketLookups (uint64)
	PacketMatches (uint64)
}

Now, with the current schema, if I wanted to add a default value of 0 to the
counters, the only place I can add a default value is at the top level of
the FlowTables component (meaning the initial array of FlowEntries etc).
This means that I must set default values for all components. I cannot
individually set each or all counters to 0.

Additionally, in the current OF-lib definition the FlowTableCounters is a
struct of a pre-defined datatype called TableCounterType, specified in the
dataTypeDef sections (and a struct also). I am unable to set these default
values.

With the model extension, it is possible to provide optional default values
both in the datatype definitions, and also inside complex data types.

> If you can point to which text in 5812 implies that an output MUST have
> packet data, then an errata would seem reasonable.
> 

[ΕΗ] Basically it is enforced by the xml schema.
The text in section "3.2.1 LFB Outputs" in page 18 defines it clearly:

" The information sent on that port is a
   pair of a packet and associated metadata, one of which may be empty.
   (If both were empty, there would be no output.)"

But in section " 4.7.3.<outputPorts> Element to Define LFB Outputs" it says:

" The <outputPort> element MUST contain the following elements:"
...
" <product> lists the allowed frame formats." 
... 
" The <product> element MAY also
      contain the list of emitted (generated) metadata."

In a very strict approach, we could change one of the text above to
"<product> MAY lists the allowed frame formats."

> 4) Strengthening the XML
> Some of these things in our implementation are taken care of by our own
> tools because they are common sense (having the same ID for different
> things is one) and none of the other ones are a problem in real life;
> the only ones we cant catch span multiple xml files (since we dont keep
> state); having said that i can see that it would be useful for the
> schema to catch things when possible at XML validation time. Question:
> Did you actually test the xml changes against the different error use
> cases?
> 

[ΕΗ] Yes. And they work fine - of course the same applies here. The xml
validation defined in this draft occurs only in a single xml file, not in
multiple.

> accompanying xml change piece and then have one large section with all
> the changes. RFC 5812 illustrates this approach.
> 

[ΕΗ] Good idea, thanks. Will do that in the next revision.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 2 Oct 2012 07:30:03 -0400

> list of actions to be performed on it prior to be sent on the flow table

Ok, makes sense. Can you please provide such illustrative text when
you update the draft?

> the FlowTables component (meaning the initial array of FlowEntries etc).

Did you mean the only place you can set the defaults is in  FlowTableCounter
definition?

> individually set each or all counters to 0.

So i can see one use case where this would make sense. not sure if this
is what you are referencing above:
Example if i used struct FlowTableCounter in multiple places and wanted
different default values (example in ref1 i wanted all fields to have a default
of 0 and in ref2 of FlowTableCounter  wanted a default of 1).

> both in the datatype definitions, and also inside complex data types.

I think this is possibly what I was talking about above?

> "<product> MAY lists the allowed frame formats."

I dont think there was any intent in creating some magical packet data
output even when none existed.
Ok, definitely an errata. Joel?

> validation defined in this draft occurs only in a single xml file, not in

If you have tested them - can you please annotate which ones require that
you have multiple LFB definitions in one XML file and which ones will catch
issues regardless.
I know for example that metadata IDs are global and would require IANA
involvement - so likelihood of conflict is small.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 2 Oct 2012 07:31:31 -0400

> involvement - so likelihood of conflict is small.

I will also make the point that these are enhancements as opposed to
extensions and that section should be labelled as such in the draft text.

cheers,
jamal

---

From: Joel <[email-masked]>
Date: Tue, 02 Oct 2012 09:18:58 -0400

I agree, the text in 4.7.3 is too strict.  Our intention was as stated 
in 3.2.1.  An errata works for me.

Yours,
Joel

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Wed, 3 Oct 2012 00:43:12 +0300

Greetings Jamal,

Please see inline.

Regards,
Evangelos Haleplidis.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jamal Hadi Salim
> Sent: Tuesday, October 02, 2012 2:30 PM
> To: Haleplidis Evangelos
> Cc: [email-masked]
> > 1. The ActionSet metadata, which is a list of actions to be performed
> > at the end of the pipeline.
> > 2. When a packet is received from a controller it may be accompanied
> > by a list of actions to be performed on it prior to be sent on the
> > flow table pipeline.
> 
> Ok, makes sense. Can you please provide such illustrative text when you
> update the draft?
> 
> > Now, with the current schema, if I wanted to add a default value of 0
> > to the counters, the only place I can add a default value is at the
> > top level of the FlowTables component (meaning the initial array of
> FlowEntries etc).
> 
> Did you mean the only place you can set the defaults is in
> FlowTableCounter definition?
> 

[ΕΗ] No, the only place I can set the default value is at the FlowTables
component level. I can't set it at the FlowTableCounter definition. Like
this:
FlowTables
Array{
	struct of {
		FlowEntries (array)
            FlowTableCounter (struct)
		MissBehaviour (atomic)
	}
}
Default value of FlowTables = ...

> different default values (example in ref1 i wanted all fields to have a
> default of 0 and in ref2 of FlowTableCounter  wanted a default of 1).
> 

[ΕΗ] That's one use case.

> > Additionally, in the current OF-lib definition the FlowTableCounters
> > is a struct of a pre-defined datatype called TableCounterType,
> > specified in the dataTypeDef sections (and a struct also). I am
> unable
> > to set these default values.
> >
> > With the model extension, it is possible to provide optional default
> > values both in the datatype definitions, and also inside complex data
> types.
> >
> 

[ΕΗ] No. What I meant, is that when you define a dataTypeDef, you can assign
optional default value for the datatype. Therefore if you define a counter
datatype, you can set a default value of zero, without having to set it
multiple times if you use it multiple times in an LFB definition.
However, in order to avoid ambiguity, the text specifies that if a default
value is added later in a component definition of an LFB, then the default
value in the component definition takes precedence.

Additionally, this extension allows default values in metadata as well.

> Ok, definitely an errata. Joel?

[ΕΗ] Besides the need to change the text, we need also change the schema to
make it optional, since the schema enforces that as well.

> > [ΕΗ] Yes. And they work fine - of course the same applies here. The
> > xml validation defined in this draft occurs only in a single xml
> file,
> > not in multiple.
> 
> If you have tested them - can you please annotate which ones require
> that you have multiple LFB definitions in one XML file and which ones
> will catch issues regardless.

[ΕΗ] The current schema validation unfortunately occurs within one single
XML file. 

> cheers,
> jamal
> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 3 Oct 2012 06:49:42 -0400

Greetings Evangelos,

> Default value of FlowTables = ...

That will look weird and i am not sure how youd write it out in the
xml. But i take it you can do this because components can have default
values and the FlowTables is a component. I guess i am struggling to
see the relevance of this specific use case. You could specify the
the counters to be zero at the datatype definition of Flow counter
and solve your problem.

> [ΕΗ] That's one use case.

And it can specify things at LFB component level now i realize i can
solve my problem here as well (so i dont need any schema extension).

> value in the component definition takes precedence.

Which makes sense.

> Additionally, this extension allows default values in metadata as well.

We can already have default value in metadata I believe.

I think the only ugly thing that seems to stick out at this point is the
way you would define things for something as deeply nested as
the FlowTables.

> make it optional, since the schema enforces that as well.

Ok.  Please prepare the errata.

> [ΕΗ] The current schema validation unfortunately occurs within one single

Which is fine; just need to highlight that fact.

cheers,
jamal

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Thu, 4 Oct 2012 16:18:06 +0300

Greetings Jamal,

Please see inline,

Regards,
Evangelos Haleplidis.

> Sent: Wednesday, October 03, 2012 1:50 PM
> To: Haleplidis Evangelos
> Cc: [email-masked]
> > [ΕΗ] No, the only place I can set the default value is at the
> > FlowTables component level. I can't set it at the FlowTableCounter
> > definition. Like
> > this:
> > FlowTables
> > Array{
> >         struct of {
> >                 FlowEntries (array)
> see the relevance of this specific use case. You could specify the the
> counters to be zero at the datatype definition of Flow counter and
> solve your problem.
> 

[ΕΗ] The problem is that I cannot define it at the datatype definition.
There is no default value in the original schema that allows datatypes to
have default values.
The only place where default value is allowed is at the definition of a
component of an LFB and only on the beginning of that definition. And there
is no formal way to say "only that component (counter) has that default
value.

> 
> >> So i can see one use case where this would make sense. not sure if
> >> this is what you are referencing above:
> >> Example if i used struct FlowTableCounter in multiple places and
> >> wanted different default values (example in ref1 i wanted all fields
> >> to have a default of 0 and in ref2 of FlowTableCounter  wanted a
> default of 1).
> >>
> >

[ΕΗ] You can't solve it if all counters are a complex datatype (which in
this case it is). As above you can't define in a formal way which counters
will get which values.

> > [ΕΗ] No. What I meant, is that when you define a dataTypeDef, you can
> > assign optional default value for the datatype. Therefore if you
> > define a counter datatype, you can set a default value of zero,
> > without having to set it multiple times if you use it multiple times
> in an LFB definition.
> > However, in order to avoid ambiguity, the text specifies that if a
> > default value is added later in a component definition of an LFB,
> then
> > the default value in the component definition takes precedence.
> 
> Which makes sense.
> 

[ΕΗ] You're right, the schema allows it but only in the definition of the
input port of an LFB if the metadata is optional.
This extension allows you to define metadata at the metadata definition
itself. However if nobody finds this useful, it can always be removed if
nobody sees any value. The reason it was included was from the OF spec which
specified that the Action Set is empty by default. But that can also be
defined in the input port as well.

> I think the only ugly thing that seems to stick out at this point is
> the way you would define things for something as deeply nested as the
> FlowTables.
> 

[ΕΗ] You cannot define default values for nested components. 
Even for a simple complex structure there is no formal way to say that. For
example:
        <component componentID="1">
          <name>foobar</name>
          <synopsis>foobar</synopsis>
          <struct>
            <component componentID="1">
              <name>foo</name>
              <synopsis>foo</synopsis>
              <typeRef>uint32</typeRef>
            </component>
            <component componentID="2">
              <name>bar</name>
              <synopsis>bar</synopsis>
              <typeRef>uint32</typeRef>
            </component>
          </struct>
          <defaultValue>???</defaultValue>
        </component>

There is no way to formally define with no ambiguity the default value of
the struct, or even one of the fields.

> > [ΕΗ] Besides the need to change the text, we need also change the
> > schema to make it optional, since the schema enforces that as well.
> 

[ΕΗ] For the text:
Page 65
Initial Text:
<product> lists the allowed frame formats...
Proposed Text:
<product> MAY lists the allowed frame formats...

Also, I think it should be valuable to say in the end:
The <product> element MUST contain at least either a frame format or a
metadata.

For the XML schema:
Page 95

Initial text:
      <xsd:element name="frameProduced">
New text:
      <xsd:element name="frameProduced" minOccurs="0">

> > [ΕΗ] The current schema validation unfortunately occurs within one
> > single XML file.
> 

[ΕΗ] Ok.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 5 Oct 2012 07:34:13 -0400

Greetings Evangelos,

> There is no default value in the original schema that allows datatypes to

Now that i think about it - you probably dont want datatype definition to
allow for default values (since you cant have default values when the
permission is read-only). So you are right, datatypes cant have default
values.

> is no formal way to say "only that component (counter) has that default

Ok, sensible then; although i am still conflicted on the value of the proposal.
Perhaps Joel will chime in.

> input port of an LFB if the metadata is optional.

I recall during the early discussions - the point made was this was the only
time it made sense to have a default value for metadatum. i.e.
If you receive metadata, it will always have a value. If it is optional and you
dont receive it, then you may need to produce one from a default value.

> defined in the input port as well.

Refer to my comment above.

>           <defaultValue>???</defaultValue>

Would the following not work?:
 <component componentID="1">
          <name>foobar</name>
          <synopsis>foobar</synopsis>
          <struct>
            <component componentID="1">
              <name>foo</name>
              <synopsis>foo</synopsis>
              <typeRef>uint32</typeRef>
              <defaultValue>1234</defaultValue>
            </component>
            <component componentID="2">
              <name>bar</name>
              <synopsis>bar</synopsis>
              <typeRef>uint32</typeRef>
              <defaultValue>5678</defaultValue>
            </component>
          </struct>
        </component>

I think it would be a problem if the typeref was a complex struct.

> Initial Text:

The errata would need to be entered on the RFC IETF tools website.

cheers,
jamal

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Mon, 8 Oct 2012 01:51:45 +0300

Greetings Jamal, 

Please see inline.

Regards,
Evangelos Haleplidis.

> Sent: Friday, October 05, 2012 2:34 PM
> To: Haleplidis Evangelos
> Cc: [email-masked]
> On Thu, Oct 4, 2012 at 9:18 AM, Haleplidis Evangelos 
> <[email-masked]>
> wrote:
> 
> 
> > There is no default value in the original schema that allows
> datatypes
> > to have default values.
> 
> Now that i think about it - you probably dont want datatype definition 
> to allow for default values (since you cant have default values when 
> the permission is read-only). So you are right, datatypes cant have 
> default values.
> 

[ΕΗ] Hm... why can't you have default values when the permission is
read-only?
Counters could be read-only. The value of the read-only component can be
changed by the FE. 
I don't think that having a default value is a problem in this case.

> > The only place where default value is allowed is at the definition 
> > of a component of an LFB and only on the beginning of that definition.
> > And there is no formal way to say "only that component (counter) has 
> > that default value.
> 
> > [ΕΗ] You're right, the schema allows it but only in the definition 
> > of the input port of an LFB if the metadata is optional.
> 
> I recall during the early discussions - the point made was this was 
> the only time it made sense to have a default value for metadatum. i.e.
> If you receive metadata, it will always have a value. If it is 
> optional and you dont receive it, then you may need to produce one 
> from a default value.
> 
> > This extension allows you to define metadata at the metadata 
> > definition itself. However if nobody finds this useful, it can 
> > always be removed if nobody sees any value. The reason it was 
> > included was from the OF spec which specified that the Action Set is 
> > empty by default. But that can also be defined in the input port as
well.
> Refer to my comment above.

[ΕΗ] Ok. I think that we can remove that.

> >> I think the only ugly thing that seems to stick out at this point 
> >> is the way you would define things for something as deeply nested 
> >> as
> the
> >> FlowTables.
> >>
> >

[ΕΗ] This is what the new draft is trying to push.
I agree it may be a problem, but that problem can be encountered on the
current model as well. 
At least in the new one, you could get a default value in a deeply nested
component.

> The errata would need to be entered on the RFC IETF tools website.

[ΕΗ] Ok. Errata created.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 8 Oct 2012 14:37:02 -0400

Sorry, meant to a respond-all...

---------- Forwarded message ----------
From: Jamal Hadi Salim <[email-masked]>
Date: Mon, Oct 8, 2012 at 2:32 PM
Subject: Re: [forces] FW: New Version Notification for
draft-haleplidis-forces-model-extension-00.txt
To: Haleplidis Evangelos <[email-masked]>

Greetings Evangelos,

> I don't think that having a default value is a problem in this case.

I was going to say lets hear what Joel has to say - but my memory cells
triggered: The FE can set whatever initial value it wishes - which may
be the default value. That is separate from what the CE can write to it.
The permissions reflect what the CE can do to the component.
Having default values means in absence of the CE writing some value, there
will be something default written to the component.

> At least in the new one, you could get a default value in a deeply nested

Can you provide an example of how that would work?
How would one describe a default for component foo.bar.goo.gah?
What i showed would work for foo.bar without any changes.

cheers,
jamal

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Wed, 17 Oct 2012 14:37:52 +0300

Greetings Jamal,

Please see inline.

Regards,
Evangelos Haleplidis.

> > Counters could be read-only. The value of the read-only component can
> > be changed by the FE.
> Having default values means in absence of the CE writing some value,
> there will be something default written to the component.

[ΕΗ] Isn't that what the default value is? In the absence of a CE doing a
SET, the FE sets a default value. 
Do I miss something?

> > I agree it may be a problem, but that problem can be encountered on
> > the current model as well.
> > At least in the new one, you could get a default value in a deeply
> > nested component.
> 

[ΕΗ] Sorry but no.
What you showed:
<component componentID="1">
          <name>foobar</name>
          <synopsis>foobar</synopsis>
          <struct>
            <component componentID="1">
              <name>foo</name>
              <synopsis>foo</synopsis>
              <typeRef>uint32</typeRef>
              <defaultValue>1234</defaultValue>
            </component>
            <component componentID="2">
              <name>bar</name>
              <synopsis>bar</synopsis>
              <typeRef>uint32</typeRef>
              <defaultValue>5678</defaultValue>
            </component>
          </struct>
        </component>
Is not applicable with the current schema. This is only applicable:
<component componentID="1">
          <name>foobar</name>
          <synopsis>foobar</synopsis>
          <struct>	
            <component componentID="1">
              <name>foo</name>
              <synopsis>foo</synopsis>
              <typeRef>uint32</typeRef>
            </component>
            <component componentID="2">
              <name>bar</name>
              <synopsis>bar</synopsis>
              <typeRef>uint32</typeRef>
            </component>
          </struct>
	   <defaultValue>value</defaultValue>
        </component>

So, to answer your question on how to describe foo.bar.goo.gah, since
default value is optional you can do even the following (added a doo and gag
as well):
         <name>foobargoogah</name>
         <synopsis>foo.bar.goo.gah</synopsis>
         <struct>
            <component componentID="1">
               <name>foo</name>
               <synopsis>foo</synopsis>
               <struct>
                  <component componentID="1">
                     <name>bar</name>
                     <synopsis>bar</synopsis>
                     <struct>
                        <component componentID="1">
                           <name>goo</name>
                           <synopsis>goo</synopsis>
                           <struct>
                              <component componentID="1">
                                 <name>gah</name>
                                 <synopsis>gah</synopsis>
                                 <typeRef>uint32</typeRef>
					   <defaultValue>0</defaultValue>
                              </component>
			            <component componentID="2">	
			               <name>gag</name>
			               <synopsis>gag</synopsis>
			               <typeRef>uchar</typeRef>
                           </struct>
                        </component>
                     </struct>
                  </component>
               </struct>
            </component>
            <component componentID="2">	
               <name>doo</name>
               <synopsis>doo</synopsis>
               <typeRef>uchar</typeRef>
		   <defaultValue>0</defaultValue>
         </struct>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 18 Oct 2012 09:10:08 -0400

Greetings Evangelos,

> SET, the FE sets a default value.

As i recall the discussion was:
If you have read-only ACL, the CE cant set anything - given permissions are
on what _the CE can do_  i.e the point of reference is the CE not the FE.
Example, capabilities are read-only by definition. Yes, the FE sets them
but they dont have default values.

> Is not applicable with the current schema.

Why is it not applicable? A component can have a default
value; even when it is embedded inside another component.

>This is only applicable:

If the schema insists on that - i believe it is unintended.
Does the RFC text also say the same thing?

cheers,
jamal

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Fri, 19 Oct 2012 23:52:53 +0300

Greetings Jamal,

> Does the RFC text also say the same thing?

[ΕΗ] The schema insists on that. The RFC text does not specify what happens
if there is a compound data structure. It simply says the defaultValue is
optional but at the component level.

Now that I read the text more closely and in the defaultValue's light, I
think that we MUST ensure that all read-reset components have a default
value. How else would the FE know which value it should reset it to?

Also, I have a question. In the model document it says: "The CE can read and
reset this resource, but cannot set it to an arbitrary value."

Does this mean: 
"When the CE reads the value, the value is reset"
Or
"The CE can either read or reset the value"

If it's the first, I didn't find any reference in the text (I missed it?)
If it's the second, with what command will the CE reset the value of the
read-reset component?

Regards,
Evangelos Haleplidis.

---

From: Joel <[email-masked]>
Date: Fri, 19 Oct 2012 16:57:00 -0400

Read only and read-rest values are set to whatever the FE wants. 
Default values are for things the CE should set, but might not.
(For example, a default value for a counter makes no sense.)

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 19 Oct 2012 17:14:00 -0400

Greetings Evangelos,

On Fri, Oct 19, 2012 at 4:52 PM, Haleplidis Evangelos <[email-masked]> wrote:
> [ΕΗ] The schema insists on that.

Definitely errata.

>The RFC text does not specify what happens

Indeed - thats why i was saying it is harder do a complex struct's selective
defaults if they were deeply nested (in the example i gave).

> If it's the second, with what command will the CE reset the value of the

Traditional definition of read-reset is: when i read something you reset it to
0. But i think it would be more powerful to be able to define a default value
(optionally) which defines a different reset value.

cheers,
jamal