Re: [model] section 3.2.4 Metadata

Jamal,

I think we're on the same page in terms of the entire text needing to be
rewritten or at least heavily edited. The section that I suggested
deleting was one of the obvious first things to do since only the two
items that Tom pointed out appeared to be of any value or meaning as far
as the model draft is concerned.

Throughout there is still a lot of superfluous and redundant text that
could be removed and/or streamlined. This section reads more like a
tutorial on metadata rather than how it is used in the context of the
ForCES model. 

I hadn't realized that you volunteered to rewrite this, go ahead. I
don't really have the time in any case.

Regards,
Ellen

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email protected]] On Behalf Of Jamal Hadi Salim
Sent: Thursday, January 04, 2007 6:52 AM
To: [email protected]
Subject: 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