Re: [model] section 3.2.4 Metadata

On Wed, 2007-03-01 at 16:23 +0100, tom.petch wrote:
> I had few problems with 3.2.4, it seemed mostly clear and well expressed.  I was
> less clear at the end of -model how much of it was needed.

That is the major problem i had as well. Actually more than that is i
was weeding through irrelevant text trying to get to the relevant points
unnecessarily. There are also a lot of relevant (to the model) points
missing. Having said that i dont see it an issue if this section or a
variation of it was in an appendix or even better off as a separate doc.

> Two points are made in 3.2.4.1 that I would not like to lose:
> 
> - metadata may exist as part of the internal functioning of an FE but that is
> outside the scope of the model
> - the metadata defined in -model is only a model to make clear the operation
> of -protocol; it is -protocol to which a compliant implementation must conform
> 

I think these are valuable points which need to be captured regardless
of how the text ends being.
Ellen, I have offered to take a crack at sanitizing this section. I
think it is more than just getting rid of that section. If you look at
other equivalent text such as one on events etc - you will see
preciseness and brevity that is called for. Give me some time since i am
prioritizing going over the draft sequentially.
So i am putting this as an action item for me which i will probably get
back to when i go past section 5. I could make it higher priority if you
think thats more important than going over the rest of the draft first.

> That said, there are examples, probably many, where the model in an RFC does get
> taken literally by implementors, probably because it can be understood with more
> confidence than the protocol.  

Yes, this worries me a great deal as well and is subject of a different
thread of discussion with Joel.

> In this instance, I did not understand -protocol
> until I had read -model.

Which makes sense, IMO. For instance, the protocols hierachical
addressing concepts of class::instance::path certainly require knowledge
of the model.

cheers,
jamal

> Tom Petch
> 
> 
> ----- Original Message -----
> From: "Deleganes, Ellen M" <[email protected]>
> To: <[email protected]>
> Sent: Tuesday, January 02, 2007 11:44 PM
> Subject: Re: [model] section 3.2.4 Metadata
> 
> 
> <Sorry if you get this twice - I removed the digital signature, which
> seems to cause problems in people being able to see the email>
> 
> I see very little value in section 3.2.4.1 - mostly it is a long winded
> definition of metadata and only a small part of it says anything about
> how
> it relates to the ForCES model.
> 
> Isn't the paragraph under 3.2.4 sufficient to describe what we mean by
> metadata in the ForCES model? (e.g. it is the per-packet state that is
> passed from one LFB to another and that the only metadata model that is
> of
> concern to the ForCES model is the metadata that is passed from one LFB
> to
> another within an FE).
> 
> If no one will have heartburn about removing section 3.2.4.1, I will
> take it
> out and try to work on rewriting the rest of the section to make it more
> readable.
> 
> Regards,
> Ellen
> 
> -----Original Message-----
> From: Forwarding and Control Element Separation
> [mailto:[email protected]] On Behalf Of Jamal Hadi Salim
> Sent: Friday, December 29, 2006 7:56 AM
> To: [email protected]
> Subject: Re: [model] section 3.2.4 Metadata
> 
> On Thu, 2006-28-12 at 15:14 -0500, Joel M. Halpern wrote:
> > You could as well ask "where are the formal semantics of an LFB class
> > defined?"  After all, the CE has to understand what the FE will do
> > when asked to put an instance of an LFB class on a data path.
> >
> > The decision we took was to not formally define semantics.  Semantics
> > are defined textually.
> >
> > This is true of LFB operations.  It is also true of meta-data
> > semantics.  Typically, some LFB will produce the meta-data, with text
> > indicating that the meta-data is some result of manipulating a field
> > in a packet, or an entry in a table provided by the CE, or ...
> > (Yes, there is room for ambiguity.  Writers of the text describing
> > LFB classes need to do their best to make sure the English is clear.)
> > And another LFB might indicate that it uses some piece of meta-data
> > as an index in a table.
> >
> 
> Actually looking further into the text, I think i have found my answer
> in the schema. Are we both exhausted of this text?
> The definition of the metadatum is done in the LFB class (section 4
> shows it). Your example has <metadataDefs> and its usage well done in
> section 8. That helped.
> I think it would do a lot of justice to have the text on metadatum to
> reflect the simplicity found in section 4. A cleanup of the text is
> certainly needed.
> 
> More suggestion:  add some text on LFB capability of metadata - maybe a
> small extension to your example in section 8 would be useful.
> 
> cheers,
> jamal