Subject: [Anima] Forwarding direction of Reference model document

From: Sheng Jiang <[email-masked]>
Date: Wed, 22 Jul 2015 09:21:19 +0000

Hi, Michael B and other contributors of reference model document,

With my WG chair hat on, I have getton upset a little bit by the current form of reference model document and how it went in last two update. The current document have many good contents with a few components that would be essential for autonomic network. 

However, our ANIMA WG does NOT charter to do all aspects of autonomic network yet. The current charter requests us to focus on AN infrastructure only. The AN infrastructure, by charter definition, only contains three components: GRASP, ACP and bootstrap. So, for now, the main purpose of the reference model document SHOULD be to decribe how these three components work together as a whole. Michael did mention to me, there are many concepts, including Autonomic Service Agent, etc., are necessary to be mentioned for readers to understand the functionality and purpose of AN infrastructure. It would be fine to mention or give brief description of such concepts in the document. But we should NOT go details for mechanism design. In our charter, the reference model is an Informational document. So, it should not contain any standard track specifications.

The chairs are also considering to form a design team for reference model, too. It would be helpful by clearly describe the scope and the boundary in the design team charter.

Best regards,

Sheng

---

From: John Strassner <[email-masked]>
Date: Wed, 22 Jul 2015 04:29:16 -0700

Hi Sheng,

> However, our ANIMA WG does NOT charter to do all aspects of
> autonomic network yet. The current charter requests us to focus on
> AN infrastructure only. The AN infrastructure, by charter definition,
> only contains three components: GRASP, ACP and bootstrap.

<jcs>
I'm confused. If I read the charter, it appears to contradict your
assertion.
Viz: "It is essential that these components and solutions fit together as an
integrated whole. For this reason, a reference document will be
developed in parallel with the individual specifications.

The initial set of work items is limited to the above list to stay
focused and avoid 'boiling the ocean'. "

Note that the last paragraph in the above quote occurs AFTER stating
that it is essential to work on the reference document.
</jcs>

> But we should NOT go details for mechanism design. In our charter,
> the reference model is an Informational document.

<jcs>
Where in the current reference model is there enough detail that
specifies mechanism design? I think that we are still well above that.
</jcs>

> So, it should not contain any standard track specifications.

<jcs>
I don't think it does.
</jcs>

> The chairs are also considering to form a design team for reference
> model, too.

<jcs>
We already have a design team for the reference model, don't we?
</jcs>

regards,
John

On Wed, Jul 22, 2015 at 2:21 AM, Sheng Jiang <[email-masked]> wrote:

> With my WG chair hat on, I have getton upset a little bit by the current
> form of reference model document and how it went in last two update. The
> current document have many good contents with a few components that would
> be essential for autonomic network.
>
> However, our ANIMA WG does NOT charter to do all aspects of autonomic
> network yet. The current charter requests us to focus on AN infrastructure
> only. The AN infrastructure, by charter definition, only contains three
> components: GRASP, ACP and bootstrap. So, for now, the main purpose of the
> reference model document SHOULD be to decribe how these three components
> work together as a whole. Michael did mention to me, there are many
> concepts, including Autonomic Service Agent, etc., are necessary to be
> mentioned for readers to understand the functionality and purpose of AN
> infrastructure. It would be fine to mention or give brief description of
> such concepts in the document. But we should NOT go details for mechanism
> design. In our charter, the reference model is an Informational document.
> So, it should not contain any standard track specifications.
>
> The chairs are also considering to form a design team for reference model,
> too. It would be helpful by clearly describe the scope and the boundary in
> the design team charter.
>
> Best regards,
>
> Sheng
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

-- 
regards,
John

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 22 Jul 2015 13:56:51 +0000

Replies in lines.

Sheng

> only contains three components: GRASP, ACP and bootstrap.

<jcs>
I'm confused. If I read the charter, it appears to contradict your assertion.
Viz: "It is essential that these components and solutions fit together as an
integrated whole. For this reason, a reference document will be
developed in parallel with the individual specifications.

<Sheng> That's exactly charter text said: focus on three individual specifications and reference model, which describes how these three componnets fit together as an integrated whole. Giving our discussion during the WG forming period, it is clear. However, it could be read differently for whom did not participate in that period. If so, it is now time to clarify it from the chair perspective.

<jcs>

> So, it should not contain any standard track specifications.

<jcs>
I don't think it does.
</jcs>
<Sheng>
That's great. Then, it may be some materials, that presented on Monday session, but not in the document yet, have crossed the line. Just make sure it would not become newly added content in the next version.
</Sheng>

<jcs>

<Sheng>
No. For now, it is a group of individual to organize by themselves to work on an individual draft. The group does not have a clear charter and goals with timeframe. Either they have been approved by WG chairs and the responsible AD.
</Sheng>

Best regards,

Sheng
regards,
John

On Wed, Jul 22, 2015 at 2:21 AM, Sheng Jiang <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Michael B and other contributors of reference model document,

Best regards,

Sheng
_______________________________________________
Anima mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/anima

--
regards,
John

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 22 Jul 2015 15:09:41 +0000

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Sheng Jiang
> Sent: 22 July 2015 11:21
> To: [email-masked]
> Subject: [Anima] Forwarding direction of Reference model document
> 
> With my WG chair hat on, I have getton upset a little bit by the current form
> of reference model document and how it went in last two update. 

No need to get upset - just send a mail :-)   And no need to wait for two document versions for that ;-) 

> The
> current document have many good contents with a few components that
> would be essential for autonomic network.
> 
> components: GRASP, ACP and bootstrap. So, for now, the main purpose of
> the reference model document SHOULD be to decribe how these three
> components work together as a whole. Michael did mention to me, there
> are many concepts, including Autonomic Service Agent, etc., are necessary
> to be mentioned for readers to understand the functionality and purpose of
> AN infrastructure. It would be fine to mention or give brief description of
> such concepts in the document. But we should NOT go details for
> mechanism design. In our charter, the reference model is an Informational
> document. So, it should not contain any standard track specifications.

Well, it goes a little beyond the reader understanding. For example, the discussion whether an ASA or a Node gets an address is fundamental to the addressing scheme, multiplexing concept in GRASP, etc. So for very basic decisions we do need to see the overall architecture, and make certain decisions now that may not be explicit in the charter. 

But I wholeheartedly agree with you that there must be limits to the details we put in. 

Frankly, I don't see an easy way to clearly define what is in and out of scope. the best way I can come up with is: Everything we need to understand to get the design of the chartered items right (also long term) is definitely in scope in the reference document. 

I interpret your mail as the general intention to keep it more focused. We'll look into this.

> too. It would be helpful by clearly describe the scope and the boundary in

I'm not sure I see the need for a formalised design team, but I don't object either.  

Charter proposal, based on the above: 
This design team writes the reference document, following the current WG charter. It describes a high level overall architecture of a network with autonomic functions, with a focus on chartered WG items, which need to be described in detail, to understand how the chartered components work together. Non-chartered items may be described briefly for the purposes of understanding the overall approach, and to ensure that decisions taken now do not conflict the overall model later on. They must be clearly marked with (*). 

The respective milestone from the WG charter is: 
Dec 2016 - Submit reference model to IESG (Informational)

Thoughts? 
Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Jul 2015 03:20:52 +1200

One quick comment on the draft charter:

I would make it "They must be clearly identified." instead of
"They must be clearly marked with (*)." I am only thinking that
for the final RFC version, we might choose to use something
other than *. We might even be able to use italics by then,
with the new RFC Format.

Regards
   Brian

---

From: Laurent Ciavaglia <[email-masked]>
Date: Wed, 22 Jul 2015 18:06:41 +0200

Hello,

I think we should keep this document focused and as concise as possible 
(seems like a shared/agreed concern).

Being a reference model, we have to consider also forward-looking items 
to ensure a minimal good design and avoid obvious future incompatibilities.

My understanding is that such forward-looking items would appear as 
summarized section(s) in the reference model document, and have 
corresponding ID(s) detailing the topic.

I don't think we need yet another design team. So far, Michael and the 
group of co-authors managed to make progress quite efficiently.

Best regards, Laurent.

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Secure Cloud Networking

Bell Labs | Alcatel Lucent

phone: +33 160 402 636

email: [email-masked] 
<mailto:[email-masked]>

linkedin: laurentciavaglia <http://fr.linkedin.com/in/laurentciavaglia/>

address: Route de Villejust | 91620 Nozay | France

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 22 Jul 2015 17:28:25 +0000

From: Laurent Ciavaglia [mailto:[email-masked]]
Sent: 22 July 2015 18:07
To: Michael Behringer (mbehring); Sheng Jiang; [email-masked]
Subject: Re: [Anima] Forwarding direction of Reference model document

Hello,

I think we should keep this document focused and as concise as possible (seems like a shared/agreed concern).

Being a reference model, we have to consider also forward-looking items to ensure a minimal good design and avoid obvious future incompatibilities.

My understanding is that such forward-looking items would appear as summarized section(s) in the reference model document, and have corresponding ID(s) detailing the topic.

MB: That is my understanding as well.
Michael

I don't think we need yet another design team. So far, Michael and the group of co-authors managed to make progress quite efficiently.

Best regards, Laurent.

-----Original Message-----

Sent: 22 July 2015 11:21

To: [email-masked]<mailto:[email-masked]>

The

the design team charter.

Thoughts?

Michael

Best regards,

Sheng

Anima mailing list

Anima mailing list

--

Laurent Ciavaglia
Secure Cloud Networking

phone: +33 160 402 636
email: [email-masked]<mailto:[email-masked]>
linkedin: laurentciavaglia<http://fr.linkedin.com/in/laurentciavaglia/>
address: Route de Villejust | 91620 Nozay | France

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 22 Jul 2015 17:28:35 +0000

ack

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: 22 July 2015 17:21
> I would make it "They must be clearly identified." instead of "They must be
> clearly marked with (*)." I am only thinking that for the final RFC version, we
> might choose to use something other than *. We might even be able to use
> italics by then, with the new RFC Format.
> 
> Regards
>    Brian
> 
> >> With my WG chair hat on, I have getton upset a little bit by the
> >> current form of reference model document and how it went in last two
> update.
> >
> >> network yet. The current charter requests us to focus on AN
> >> infrastructure only. The AN infrastructure, by charter definition,
> >> only contains three
> >> components: GRASP, ACP and bootstrap. So, for now, the main purpose
> >> of the reference model document SHOULD be to decribe how these three
> >> are many concepts, including Autonomic Service Agent, etc., are
> >> necessary to be mentioned for readers to understand the functionality
> >> and purpose of AN infrastructure. It would be fine to mention or give
> >> brief description of such concepts in the document. But we should NOT
> >> go details for mechanism design. In our charter, the reference model
> >> is an Informational document. So, it should not contain any standard track
> specifications.
> >
> > Well, it goes a little beyond the reader understanding. For example, the
> discussion whether an ASA or a Node gets an address is fundamental to the
> addressing scheme, multiplexing concept in GRASP, etc. So for very basic
> decisions we do need to see the overall architecture, and make certain
> decisions now that may not be explicit in the charter.
> >
> > Frankly, I don't see an easy way to clearly define what is in and out of
> scope. the best way I can come up with is: Everything we need to
> understand to get the design of the chartered items right (also long term) is
> definitely in scope in the reference document.
> >
> >> model, too. It would be helpful by clearly describe the scope and the
> >> boundary in the design team charter.
> >
> > This design team writes the reference document, following the current
> WG charter. It describes a high level overall architecture of a network with
> autonomic functions, with a focus on chartered WG items, which need to be
> described in detail, to understand how the chartered components work
> together. Non-chartered items may be described briefly for the purposes of
> understanding the overall approach, and to ensure that decisions taken now
> do not conflict the overall model later on. They must be clearly marked with
> (*).
> >