I want to support Anton's request regarding new solutions; its a good
idea to not put the "donkey before the cart" as he said yesterday.
--Tom
> Hi all,
>
> I believe that there has been a general agreement that there is some
> need for metadata in the transports.
>
> However, instead of doing the basic work needed to implement that
> agreement we are jumping straight to solutions.
>
> None of the drafts so far present:
>
> * What are the architectural touchpoints for metadata. Who and how can
> modify it. "We shall innovate in software by sticking more bits" is not
> an answer - it does not make a standard.
>
> * Who has access to metadata. What is the metadata security model?
> Example - are the circumstances under which the Tenant System may see
> some of the metadata?
>
> * How do you handle a packet with metadata incoming from somewhere
> else if you need to add you own. Overwrite? Label Stack? All formats
> presented so far do not answer that question or imply overwrite. If we
> look at what has been successful label stack is probably a better answer
> (despite imposing immediate limitations on size and format of metadata).
>
> * How do you query the metadata?
> * Are we going to define a protocol which peels off metadata and
> passes it for external processing?
> * Are we going to define an API?
> * If the security model will allow API to be queried from inside
> tenants how would it be handled architecturally - local or through a
> central "controller/API GW".
>
> Without these any metadata in an encaps is worthless - what is the point
> of having metadata if you cannot query it?
>
> This is just off the top of my head. This topic needs a proper
> requirement draft and if the req draft is successful it can ask to be an
> architecture annex to the main NVO3 arch. Once these are defined, we
> will need a draft on the query APIs and/or methods as these may limit
> what you can use as metadata (these may introduce extra limitations).
> Then, and only then, we should be defining metadata in transports (I
> suspect SFC will define them for us by that time anyway).
>
> A.
> _______________________________________________
> nvo3 mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nvo3
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
