Subject: Re: Proto Requirement - Weigh in Please (was: re:[FORCES] Issue Summary: Inter-FE Topology requirements)

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 26 Sep 2003 13:46:17 -0400

I would prefer the replacement text.

I can live with the original text, given the change in the architectural text.

What actually would address the problem better would be some way of saying
that the solution has to allow for carrying this information.  I realize
that some folks have read the current text to mean that.  Other folks have
read it more strictly.  How about:
    The ForCES protocol or information carried in the ForCES protocol MUST
allow
    those FEs which have inter-FE topology information to provide that
information
    to the CE(s).  (refer to section 5, requirement 10)

Yours,
Joel M. Halpern

At 10:37 AM 9/26/2003 -0700, you wrote:
>All,
>
>It appears that there is some concern around the second
>of the two recommendations made, specifically to change
>the MUST to a MAY in the protocol requirement to provide
>a method to deliver inter-FE topology information from
>FEs to CEs.
>
>Patrick & I would like to do an explicit consensus
>call on this matter to settle the question. Please
>send a note to the list stating one of the following:
>
>* Retain original text
>    The ForCES protocol MUST allow the FEs to provide their topology
>    information (topology by which the FEs in the NE are connected) to
>    the CE(s). (refer to section 5, requirement# 10)
>
>* Replace MUST with MAY in original text
>    The ForCES protocol MAY allow the FEs to provide their topology
>    information (topology by which the FEs in the NE are connected) to
>    the CE(s). (refer to section 5, requirement# 10)
>
>* Some other alternative (please provide text).
>
>Thanks,
>David
>
>
>-----Original Message-----
>From: Forwarding and Control Element Separation
>[mailto:[email-masked]] On Behalf Of Avri Doria
>Sent: Thursday, September 25, 2003 9:15 PM
>To: [email-masked]
>Subject: Re: [FORCES] Issue Summary: Inter-FE Topology requirements
>
>
>I am fine with the first change (architecture) but uncomfortable with
>the second (protocol).
>
>I believe the protocol, as designed, should be able to carry.  That
>would the protocol requirement.
>
>I believe it may or may not be called on to do so. That is an
>implementation detail.
>
>a.
>
>On fredag, sep 26, 2003, at 12:39 Asia/Seoul, Putzolu, David wrote:
>
> > All,
> >
> > Thanks for the discussion on the topic of inter-FE topology.
> > There are two sections of the requirements document that have
> > caused discussion here - Section 5 #10, which is an
> > architectural requirement, and Section 7 #10, which is a
> > protocol requirement.
> >
> > Patrick & I have followed the list discussion and conferred
> > with the ADs.  We suggest resolving this issue as follows:
> >
> > Issue #1: The architecture requirement (S5#10) says that FE's
> > must be able to provide to CEs the topology by which the FEs
> > in the NE are connected.  We suggest rolling this back to
> > what the requirement was in requirements-01:
> >
> >    10) In a ForCES NE, the CE(s) MUST be able to learn the topology by
> >    which the FEs in the NE are connected.
> >
> > This is suggested because it is possible for CEs to learn
> > topology information without the FEs having to provide
> > it, and there are real systems that operate in such a fashion.
> >
> >
> > Issue #2: The protocol requirement (S7#10) says that the ForCES
> > protocol must provide a mechanism to carry inter-FE topology
> > info to the CE.  Given the resolution to issue#1, it is clear
> > that a mechanism to deliver topology information is not always
> > used in the Fp reference point (because the element providing
> > topology information might not be a FE).  As such, we recommend
> > changing S7#10 from a MUST to a MAY.  If a protocol author
> > believes that topology information is sufficiently important,
> > then they may include it in their protocol.  However,
> > if a protocol author believes it is not necessary then they may
> > omit it.   It will be up to the WG as a whole to determine during
> > protocol selection the incremental value from including such
> > mechanisms (for those protocols that choose to do so).
> >
> > Finally, there is also a procedural issue, in that this document
> > is in the RFC editor's queue and as such it is a strange
> > time to be changing the contents.  Patrick & I believe the
> > necessary changes can be made during the author's 48 hour
> > period, which has not started yet.
> >
> > We believe that the above recommendations are consistent
> > with the statements and general consensus of the list.
> > If anyone has an objection to this resolution, or would like
> > to suggest different replacement text, please make this known.
> >
> > Thanks,
> > David and Patrick
> >

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 26 Sep 2003 14:16:45 -0400

I think that the toning down to may (lowercase) would deliver the same
semantics in the message as your text below. I would have prefered total
removal since we do actually allow for _any_ FE attributes to be
retrieved (including proprietary ones).

cheers,
jamal

---

From: Avri Doria <[email-masked]>
Date: Sat, 27 Sep 2003 08:34:20 +0900

I am fine with Joel's rewrite.
a.

---

From: Weiming Wang <[email-masked]>
Date: Sat, 27 Sep 2003 09:20:49 +0800

I'm afraid in some cases CE is also interested in knowing if FE can or can not provide its FE topology information. 
This means the Fp protocol MUST allow FEs to provide topology information even the FEs do not actually 
have topology in hand. 
Therefore, I prefer the original one.  With the change in the sec5 requirement 10,  the requirement discussed is ok.

weiming