For some reason, the note I sent to the reflector
this morning apparently did not get there. Here was my reply to Offer's
note:
Offer, I am in full agreement with you. One
of the clauses in the Standard will be Definitions of Terms and Acronyms .
If there is confusion over the use of any terms, then that section should be
started immediately.
I believe that the Definitions of Terms and
Acronyms section should be a living document posted on our web site.
In a previous note I sent to Ed Massina, who volunteered to design our 802.17
web site, I stated that the web should have a section separate from meeting
papers that contains timeless documents, and evolving documents that transend
single meeting importance. I would strongly urge the generation of a
preliminary Definitions of Terms and Acronyms section for posting on the web
site and for discussion. As a living document each definition would have
its status indicated as either "proposed" or "accepted by the Working Group",
where 75% in favor is required to list the definition as accepted. Once
accepted, it would take 75% agreement to change that definition.
Are there any volunteers out there that would like
to come forward with a first pass of the Definitions of Terms and Acronyms
sections?
Best regards,
Robert D. Love President, LAN Connect Consultants 7105 Leveret
Circle Raleigh, NC 27615 Phone: 919
848-6773 Mobile: 919 810-7816 email: rdlove@xxxxxxxx
Fax: 720 222-0900
----- Original Message -----
Sent: Monday, January 08, 2001 3:08
PM
Subject: RE: Jan 15-17 meeting. I'm
confused, please help
I
guess, one thing we, definitely need to decide is boundary (in terms of the
OSI layers) of work. My default understanding is
MAC
layer but, we know that issues like priority and basic queing (of data &
control messages) require
the
boundary to extend towards data link. Also for ring protection, we may need
parameters, including
link
status which may take us to PHY too. Since we do not control all layers, we
need to decide
one
layer as our dominant area of work (I pre-assume MAC+ any additional sub
layer) and other in liasion capacity
(like 10G Ethernet group on PHY and IETF for
networking/data link)
Regards,
Devendra Tripathi
VidyaWeb, Inc
90 Great
Oaks Blvd #206
San Jose, Ca 95119
Tel: (408)226-6800,
Direct:
(408)363-2375
Fax: (408)226-6862
Bob,
I
guess I was not entirely clear. I agree that it may be premature to decide
what should be in RPR and what should not. Having said that, I believe that
agreeing on terminology and what each statement (in the requirements) means
will take us a long way ahead. I believe that it would be difficult to work
on a standard when we can't have at least a common language. I have already
encountered cases (in our group) where a certain word meant one think for
one person and another for someone else. In general, I believe it is
unhealthy to prolong such a situation.
Offer
Offer Pazy
Sr. Product Manager
Native Networks
15 Gonen St.
Petah Tikva 49170
Israel
The
Native Way = Ethernet Simplicity + SONET
Reliability
In reply to Offer Pazy's note attached, let
me express my point of view, which includes a belief that we must define
our requirements in a systematic fashion:
Based on almost two decades of deep
involvement in standards creation, it is my strong belief that an early
discussion that attempts to lock down what requirements are will produce a
huge amount of discussion, but few answers. It is also likely to
help polarize positions, making it more difficult to develop resolution
later on. Frankly, I am
concerned that it is too early to decide on any but the very highest level
objectives at the January interim meeting. In addition, we do have
other very high priority tasks in front of us, including the agreement on
how we will move this standards development process forward.
Certainly, we can include a discussion of
high level objectives at the January meeting. If there is time, we
can begin to drill down to see if there are areas where we have
concensus. I would be adverse to any lenghy discussions to defend
positions at this meeting. Rather, I would prefer to note where
there are multiple opinions, and document the different directions we may
decide to take, so we can solicit email discussion and papers at future
meetings to help resolve the issues.
Offer, I understand that it can be
frustrating to focus on process when there are real problems out there
that need to be solved, and decisions that must be made. In
addition, we must not spend too much time organizing, thereby losing time
precious development time. I propose that taking next weeks meeting
to define the playing field, and the rules, and to understand where the
issues are, rather than attempting to resolve them will prepare us to move
quickly on resolving issues from that point on.
Best regards,
Robert D. Love President, LAN Connect Consultants 7105 Leveret
Circle Raleigh, NC 27615 Phone: 919
848-6773 Mobile: 919
810-7816 email: rdlove@xxxxxxxx
Fax: 720 222-0900
----- Original Message -----
Sent: Saturday, January 06, 2001
12:40 PM
Subject: RE: Jan 15-17 meeting. I'm
confused, please help
Mike and others,
After reading the exchange below and Mike's tentative agenda, I'm
a bit uncertain as to what exactly we want to achieve in the upcoming
meeting. It is clear to me that significant portion of the time will
(and has to) be dedicated to bringing everybody new on board. We have
only two days and the question is how to we make sure that the rest of
the time is used productively.
Let me explain what I'm mostly interested in and what I believe
should be the first priority of the meeting: Requirements, Requirements,
Requirements. I've been spending a lot of time in the past two months
explaining to people what RPR is about. But beyond "dual-counter
rotating rings", I could not say anything else in any confidence. Most
people understand the issues and ask questions regarding specific
capabilities. All I have now (and I believe this is all we have) is an
unflushed and unsorted list of very high-level "things" that I've copied
from some presentations and from the white board and it is not
enough.
It is clear to me that the interim meeting does not make
decisions and that nailing down specific requirements may take a long
time, but at least I would like us to move in that
direction.
If possible, my goal for the meeting would be to come up with a
requirements list that is as specific as to be clearly understood by
everyone leaving as little as possible for ambiguity or "between the
lines" meaning. I expect that some issues will be controversial and I
don't expect we resolve this at the meeting. Nevertheless having such
concise and clear list will help us all focus and understand where we
agree and where we don't. We can establish a convention on how to mark
such issues.
Just as an illustration (I do not wish to start a debate on
these):
Fairness: Is the intention fairness within a node or within the
ring?
Congestion management/control: Is it management or control? Is it
CAC based (probably not)? Do we assume buffers or
not?
Again, these are just examples. Another outcome of such an effort
will be to have one list of requirements instead of several (there are
some differences between the various presentations and the
list we've prepared to the 802.3).
What do people think? Is it the right time and important enough
to focus on this in the upcoming meeting?
Offer Pazy
Sr. Product Manager
Native Networks
15 Gonen St.
Petah Tikva 49170
Israel
The
Native Way = Ethernet Simplicity + SONET
Reliability
Rob,
Thanks. I was trying to get the logistics.
Here is what I read from your comments
For us to complete the standard there are
many sections and sub sections to be written.
Before that can be done there are many
proposal to evaluate.
Before that can be done there are the
objectives and scope.
I propose a framework and then identify the
scope and objectives....
Network
single
Ring
Interconnected
Rings
Bridges and
router
MAC Layer
Data path
function
forwarding
filtering
error correction/detection
Control
Plane
header
definition
network size
header field definition
customer separation
header bit definition
L2
functions
Node discovery
Fairness
L3
interface
L1 management
I/F
L1
control
L1
Interfaces
Generic Packet interface
SONET
SDH
Gigabit Ethernet
DWDM
Digital Wrapper
Network Applications
Ring
interconnect
Transparent LAN
Service
ISP
Harry, here is my 2¢ on this one: I
would expect us to continue to refine our detailed scope and
objectives, going much further than the PAR input. I
anticipate that 802.17 will be doing a significant amount of voting
at the March plenary meeting, some of which will be establishing
things like objectives. Hopefully a great deal of the work
will have been done ahead of time, including at the upcoming
meeting, and via email discussion. All of this work should
fundamentally build on what the Study Group has previously decided,
even though the Study Group's output is not binding on the decisions
of the Working Group.
I don't know how much time will be
available at the January interim meeting to address the issue of
refinement of the Scope and Objectives. If there is time, I
think the topic will fit well with the meeting's overall
focus.
Best regards,
Robert D. Love President, LAN Connect Consultants 7105
Leveret Circle Raleigh, NC 27615 Phone:
919 848-6773 Mobile: 919
810-7816 email: rdlove@xxxxxxxx
Fax: 720 222-0900
----- Original Message -----
Sent: Tuesday, January 02,
2001 11:40 AM
Subject: Q: Jan 15-17
meeting
mike:
Are you gathering scope an objectives
to help defining the tasks in the schedule to complete the
standard?
Some of the scope
were discussed in previous meetings. Now that we are a WG are we
recapturing and additional detail scope
and objectives as confined in the PAR
and 5 Criteria?
Regards,
Harry
|