Subject: [eman] WG documents adoption

From: Benoit Claise <[email-masked]>
Date: Fri, 12 Nov 2010 23:42:20 +0800

Dear all,

 From the meeting minutes at: 
http://www.ietf.org/proceedings/79/minutes/eman.txt, we would like to 
stress the following

draft-quittek-power-monitoring-requirements-02

    Chair asked if the sense of the room was that this should be made a
    working group draft. No objections. Take to the list.

draft-claise-power-management-arch-02

    Chair asked if the sense of the room was that this should be made a
    working group draft. No objections. Take to the list.

draft-parello-eman-energy-aware-mib-00

    Chair asked if the sense of the room was that this should be made a
    working group draft. No objections. Take to the list.

If you object any of the documents becoming a WG item, let us know.
Note that, if a document becomes a WG item, the open issues discussed 
will have to be solved based on the group consensus.

Regards, Bruce and Benoit

---

From: Benoit Claise <[email-masked]>
Date: Mon, 22 Nov 2010 12:20:11 +0100

Dear all,

Since they were no objections, we asked the authors to publish the 3 
drafts below as EMAN WG documents.

Regards, Bruce and Benoit.
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Mon, 22 Nov 2010 07:59:05 -0600

Benoit,

You have stressed the following a couple of times now:

    Note that, if a document becomes a WG item, the open issues discussed
will have to be 
    solved based on the group consensus. 

Since I am new to the IETF I am unfamiliar with the actual implications of
this statement.  Could you perhaps explain a bit more about what this means
in practice for those who are less familiar with the nuances of IETF customs
and procedures?

I assume that adoption is done by group consensus and that future changes
will be done by group consensus so I am confused about what is different
between now and after adoption.  Does proposing changes or alternatives
become somehow more difficult after these have been adopted?  I am just
asking for clarification for the benefit of myself and possibly others on
the list.

I have provided some comments on the Requirements document but have not
heard back from Juergen as to whether the points I raised could be
addressed, or not, and some of these possibly had implications for the
framework / architecture document as well.

One example would be my request or suggestion that the references to IPFIX
be removed from the proposed requirements and that this issue be resolved
within the Architecture document.  I have concerns about the IETF EMAN
standard referencing IPFIX as being a required technology for a standards
conforming solution.  I understand the desire to have this approach
recognized as a standards conforming approach and I believe that this can be
easily accomodated in some way within the reference Architecture, but most
likely this will need to be considered an optional part of the standard and
not a required one.  I say this because acceptable management alternatives
for the efficient transfer of time series data are certainly possible and I
would like to see the standard accomodate those alternatives and not mandate
a specific solution as is currently being proposed.

So with respect to your statement above, is this something that could
customarily be easily addressed after adoption of Juergen's proposed
requirements or is this something that would be best handled as an alternate
proposal/draft to Juergen's which is put forward prior to the adoption of
either of the two alternatives?  

I just wish to understand the customary processes in this case to establish
some shared expectations on moving things forward.  I don't expect that even
in my current example that the group cannot come to some appropriate
agreement to address the concerns of all.

Thanks,

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: [email-masked] <mailto:[email-masked]> 
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein 

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Benoit Claise
Sent: Monday, November 22, 2010 6:20 AM
To: eman mailing list
Subject: Re: [eman] WG documents adoption

Dear all,

Since they were no objections, we asked the authors to publish the 3 drafts
below as EMAN WG documents.

	Dear all,
	
	From the meeting minutes at:
http://www.ietf.org/proceedings/79/minutes/eman.txt, we would like to stress
the following

		Chair asked if the sense of the room was that this should be
made a 
		working group draft. No objections. Take to the list.

		Chair asked if the sense of the room was that this should be
made a 
		working group draft. No objections. Take to the list.

		Chair asked if the sense of the room was that this should be
made a 
		working group draft. No objections. Take to the list.

	If you object any of the documents becoming a WG item, let us know.
	Note that, if a document becomes a WG item, the open issues
discussed will have to be solved based on the group consensus.

---

From: Benoit Claise <[email-masked]>
Date: Mon, 22 Nov 2010 15:32:13 +0100

Hi Bill,
> between now and after adoption.
When a document is an individual draft, you can give comments to the 
authors, but it's up to the authors to address them.
When a document is a WG item, the document belongs to the WG. As such, 
all comments should be addressed, based on the WG consensus.

> Does proposing changes or alternatives
> become somehow more difficult after these have been adopted?
That's the reverse: it should be easier, as the authors should at least 
respond to your comments.
> I am just
Sure.
> requirements
yes exactly.
> or is this something that would be best handled as an alternate
Btw, this specific issue of IPFIX was discussed in the context of the 
EMAN architecture, and I remembered that the feedback received was in 
favor of not mentioning IPFIX in the architecture, but at the same time, 
not preclude this potential adoption in the future.

A common good practice for document authors is to include a TO DO 
section at the beginning of each document, listing the points that need 
further discussion.

Regards, Benoit.
> Email: [email-masked]<mailto:[email-masked]>
> Phone: 614 367 5628
> Fax: 614 367 5965
>