Subject: Re: comments on protocol draft

From: Weiming Wang <[email-masked]>
Date: Mon, 9 Aug 2004 21:26:41 +0800

Hi Alan,

----- Original Message -----
From: "Alan DeKok" <[email-masked]>
To: "Wang,Weiming" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 09, 2004 3:14 AM
Subject: Re: comments on protocol draft

> Wang,Weiming wrote:
> > Sorry not to make a reply sooner owing to some business.
>
>    The same applies here, but "business" for me is "new daughter".
[Weiming] Congratulations for your new daughter.
>
> > [Weiming] It is obvious very valuble to evaluate the scheme to organize the
> > protocol in the way RFC3588 uses. I also appreciate the ABNF used there. Now
I
> > think what we need to discuss more to decide if we should take the scheme
is,
> >
> > 1) how many TLVs we may have in the protocol layer,
>
>    The TLV's in the protocol layer should be enough to implement the
> protocol.  What you've done already in the draft is probably most of
> what you'll need.
>
> > 2)how the TLVs conform with the Model work.
>
>    Steve & Zsolt have an "lfb attributes" draft, which I think applies here.
[Weiming] I'll appreciate it very much if TLVs can also be defined
simultaneously there.
>
> > For 1),  if there are many TLVs that should be defined by protocol layer, I
> > think it is surely worth using the way as RFC 3588. A little difference of
RFC
> > 3588 with ForCES is, we have a specific FE model document associated with
the
> > base protocol.
>
>    I'm not sure what you're referring to here.  The protocol draft isn't
> a model, and the ForCES model draft doesn't define a protocol.  They
> should be kept separate.
[Weiming] I just refered the actual TLVs for things like LFB attributes, etc.
>
> > As a result, I just wonder if some of the attributes TLVs should
> > be defined in the model or not.
>
>    The LFB attributes should be defined in an LFB model document.  The
> format of those attributes could be defined in a separate document.
[Weiming] Is it something like a separate "FE data model"?  I'm glad if it is.
>
> > For 2),  I just see currently there may be a missing work between the
protocol
> > and the model, that is, how entities (incuding attributes, capabilities,
events,
> > etc) will be eventually coded in protocol and who is in charge of such
coding
> > definition. I think this will affect the PDU definition in protocol also. If
> > this is defined by model, I think the TLV format can be more uniform and
there
> > will be much less TLVs in protocol, or else, there will be more. We actually
> > have left this as an open issue in the protocol text.
> > [/Weiming]
>
>    The ForCES model document is already very large.  I don't think any
> more should go into it.
>
>    One additional point is that we should try to make clear that the
> model is *independent* of the protocol.  That is, the model uses XML,
> but the representation of data by XML in the model has nothing to do
> with the encoding of data in the protocol.
[Weiming] I'm actually not very much clear of this before. More question is why
we don't start up the Data model right now to pave the gap between  the protocol
and the 'independent' model as you mentioned.
> ...
> > [Weiming] This actually refers to the question "if we should allow using
> > recursive TLVs (TLV in TLV)". We will evaluate it.
>
>    The RADIUS & AAA (diameter) groups have discussed this extensively.
> There are few clear benefits one way or the other.
[Weiming] We are actually having a discussion in the protocol team for this. I
really appreciate if you can join us for the discussion.

>    Alan DeKok.

Thank you.
Weiming

---

From: Alan DeKok <[email-masked]>
Date: Sun, 8 Aug 2004 15:14:52 -0400

> protocol in the way RFC3588 uses. I also appreciate the ABNF used there. Now I
> think what we need to discuss more to decide if we should take the scheme is,
>

> think it is surely worth using the way as RFC 3588. A little difference of RFC
> 3588 with ForCES is, we have a specific FE model document associated with the
> base protocol.

> For 2),  I just see currently there may be a missing work between the protocol
> and the model, that is, how entities (incuding attributes, capabilities, events,
> etc) will be eventually coded in protocol and who is in charge of such coding
> this is defined by model, I think the TLV format can be more uniform and there

...

   Alan DeKok.