Subject: [Fwd: Re: [Forces-protocol] Outline]

From: Patrick Droz <[email-masked]>
Date: Mon, 19 Apr 2004 14:57:51 +0200

Hi all,

I also definitely support Avri as an editor. And moreover, if current 
scheme can
not work well later (as Avri worried), I suggest WG to appoint Avri as 
the only
neutral editor.

Seems the 3+1 scheme can currently more widely be accepted, why not 
let's make a
consensus on it and then move ahead quickly?
------------------
Hi Hormuzd,

Followed is the email I wrote yesterday, but could not send out because the
failure of my mail server. I still want to post it for a reference. But 
anyway,
I agree with you that we need to move forward more quickly. Because now 
I can
not follow the forces-protocol list, I will reply to your and Jamal's 
followed
posts, maybe after monday.
------------------
Hormuzd,

If we are now writing an Informational RFC, I think it's reasonable to 
take a
specific first layer section for example descriptions, but if we are 
writing an
standard RFC, I think we'd better not to do like this. From my viewpoint, it
just looks a little ugly in a standard document, because we are mainly
introducing the specifications of the standard instead to introduce 
examples. by
saying this, I actully not object to take examples in the standard, but 
it is
just for more clear understanding of readers. If you think the examples 
are very
important, then they should not appear as examples. For instance, if you 
think
the establish of association or CE failover scenarios are very 
important, they'd
better to be included in a specific protocol description sections 
instead of as
examples.  You can go back to check the current RFCs for standards, it 
may be
not as often used as you said.

One alternative way is to take a section as "Implementation Notes" for some
important scenarios, while take some introductive examples to the Appendix.

Taking about TML requirements,  my feeling is it may be better to be 
appeared in

protocol overview somthing like
3. (Some section like protocol overview)
...
3. 1. The Protocol Layer (PL) and the Transportation Mapping Layer ( TML)
3. 2. TML Requirements (or some other word)
...
My another feeling is if we should call it 'requirements', or we may use 
other
word that is more relavent to describe TMP in PL.  To put it in protocol
overview may give us more time to have the the name decided after more
discussions on TML issues.

Anyway, I agree with you that this (to decide the outline) is not very 
difficult
thing after we have more discussions on important issues, my idea is 
just that
currently we may not need to strictly decide it.

Best Regards,
Weiming

----- Original Message -----
From: "Khosravi, Hormuzd M" <[email-masked]>
To: "Wang,Weiming" <[email-masked]>; <[email-masked]>
Sent: Friday, April 09, 2004 1:40 AM
Subject: RE: [Forces-protocol] Outline

Hi Weiming

You're right, I have not incorporated all your comments...I should have
explained a bit more in my last email..sorry about that.

I think Example Scenarios is an important section and should be part of
the main protocol sections. I have seen it in most RFCs/drafts that I
have read, it makes things easy to understand for the reader. Is there
any particular reason why it should be moved to the appendix ?
Also, I think TML Requirements should be a separate section. I agree
that protocol layering and TML will be introduced in Protocol Overview
but TML requirements is different from that, goes into more of the
details and deserves a separate section.

Based on latest comments from Ram, yourself, here is what I propose..

Abstract
1. Introduction
2. Definitions
3. Protocol Overview
4. Common Header
5. Protocol Messages
6. TML Requirements
7. Example Scenarios
8. Security Considerations
9. References
10. Acknowledgments
Appendix

Note that I have added an appendix, we can decide what goes into it
later.
Most folks have agreed with this initial outline, I would say lets go
with this for now, unless you have strong reasons not to. We can always
make changes later, once we get into more details.

regards
Hormuzd

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Wang,Weiming
Sent: Wednesday, April 07, 2004 7:30 PM
To: [email-masked]
Subject: Re: [Forces-protocol] Outline

If all ideas are incorparated, I suppose it may look like this:

Abstract
1. Introduction
2. Definitions
3. Protocol Overview (or other more intensive word than overview)
4. Common Header
5. Protocol Messages
6. Security Considerations
7. References
8. Acknowledgments
Appendix

Best Regards,
Weiming

----- Original Message -----
From: "Khosravi, Hormuzd M" <[email-masked]>

Weiming,

Thanks for your comments!
I am fine with the Definitions section. I have to agree with Jamal on
the Common Header, all other sections are present in most drafts/RFCs as
you have mentioned. Based on your, Jamal's comments here is what I
propose for the outline...

Abstract
1. Introduction
2. Definitions
3. Protocol Overview
4. Common Header
5. Protocol Messages
6. Example Scenarios
7. TML Requirements
8. Security Considerations
9. References
10. Acknowledgments

I completely agree with you that we need to start discussing protocol
overview/messages.

regards
Hormuzd

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Wang,Weiming

> Hormuzd,
> Some comments:
>
> On Tue, 2004-04-06 at 02:49, Khosravi, Hormuzd M wrote:
> > Here is an initial outline for the draft
> >
> > Abstract
> > 1. Introduction

[Weiming] I suppose we add
     2. Definitions

> > 2. Protocol Overview
> > 3. Common Header
[Weiming] The common header can be inside the overview. And also the
overivew
will explain the layering model of PL and TML, therefore the TML
requirements
can also be included in it.

> > 4. Protocol Messages
>
> Should we follow with protocol details after this?
> And should TML move to just below Protocol overview or were you
thinking
> protocol overview contains overview of TML as well?

[Weiming] Agreed as above.
> > 5. Example Scenarios

[Weiming] This section should be as an Appendix.

> > 6. TML Requirements

[Weiming]As mentioned above, this should be put early in the protocol
overview,
so that some protocol messages related to TML can be reasonably
understood.

> > 7. Security Considerations
>
> do security requirements belong to TML as well?
>
[Weiming]This section is still normally needed even TML will be more
responsible
for protocol security issues.

> > 8. References
> > 9. Acknowledgments
> >
> > Let me know what you guys think ?
> > We can add more details as we move along.
>
> I think its a good start and good idea to have this at this point. We
> probably shouldnt spend too much time on cosmetics right now because i
> think we can iron those out as we go on.
>
> cheers,
> jamal
>

[Weiming] To summarise, I think we may only need to give the first layer
outlines as follows,

1. Introduction
2. Definitions
3. Protocol Overview
4. Protocol Messages

All others are just normal ones and the more we need to discuss followed
is the
contents inside the overview and messages. As Jamal said, we can do it
along
with the issue discussions.

Yours,
Weiming

_______________________________________________
Forces-protocol mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/forces-protocol

_______________________________________________
Forces-protocol mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/forces-protocol

_______________________________________________
Forces-protocol mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/forces-protocol

-- 
   Dr. Patrick Droz 			| [email-masked]
   IBM Zurich Research Laboratory 	| http://www.zurich.ibm.com/~dro
   Saumerstrasse 4 			| Tel. +41-1-724-85-25 CH-8803
   Rueschlikon/Switzerland 		| Fax. +41-1-724-85-78