The IP over ATM Mailing List Archive by date

[Susan Symington <susan@backup.mitre.org>]

James,

These "broad brush" comments, as you say, don't strike me as good enough
reasons to hold up the document for any significant amount of time.  They
appear to be stylistic (rather than technical) objections to the document.
Yes, we all want the document to be such that it can be implemented correctly. 
I believe that that has already been achieved.   Here are some specific responses
to your suggestions:

a) Elimination of use of the passive voice, while it may be nice stylistically,
is certainly not essential from a technical standpoint.  If something is unclear,
whether because of use of the passive voice or not, then ask Grenville to make that
specific thing more clear.  Going through the whole document to eliminate use of
the passive voice seems like overkill.  If you want to do it and you can do it really 
really quickly and it's okay with Grenville, fine.  But don't hold up the document
because it's not stylistically the way you want it to be.

b) Putting all common header processing into a single section also strikes me
as a stylistic comment also.  Perhaps it would be nice.  How long would it
take and is it worth it?  What really is gained?  Can't it be done later after
the document goes to proposed status?

c) Again, if there are specific ambiguities about end system behaviour that need to 
be cleared up, then by all means let's get those specific things cleared up.  What 
exactly do you mean by "reduce the distinction" between the mesh and server cases.
Please be specific about your objection. 

Could the document be improved?  Of course, what document couldn't.  Does it need to
be improved in order for people to implement it correctly?  I, for one, don't think so.

-susan

> 
> 
> Tim:
>    I'd like to see this document get out too.  I agree that continual 
> improvement is not a good use of time.  However, I would also like to
> make sure the document we turn into an RFC is easy for everyone,
> especially those new to the field, to implement correctly.
> 
> I have a few "broad brush" suggestions along these lines.  Of course,
> having made them I feel obliged to offer to help to implement them.
> 
> 1) I would like to see the use of the passive voice eliminated, at
>    least in the specification part of the document.  A number of 
>    requests for clarification seem to relate to the use of the passive
>    voice.
> 
> 2) I would like us to take Grenville's emphasis on the header and elements
>    of procedure even further and pull all "common header" processing
>    into a single section.
> 
> 3) I would like to see us make an attempt to reduce the distinction
>    (implied or inferred !!) between the mesh and server cases.  We need
>    to ensure the end-station behaviour is as simple to understand as we
>    can make it.
> 
> Comments ?
> -james
> 
> ____________________________________________________________________________
> James W. Watt,     james@newbridge.com                   Ph: +1 613 591-3600
> Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:+1 613 591-3680