Subject: Re: [forces] Last Call: <draft-ietf-forces-protoextension-04.txt> (ForCES Protocol Extensions) to Proposed Standard

From: S Moonesamy <[email-masked]>
Date: Fri, 08 Aug 2014 00:34:36 -0700

Hello,

[Cc to iesg@ as it may be better not to have this discussion on the 
mailing list mentioned in the announcement]

At 12:59 30-07-2014, The IESG wrote:
>The IESG has received a request from the Forwarding and Control Element
>Separation WG (forces) to consider the following document:
>- 'ForCES Protocol Extensions'
>   <draft-ietf-forces-protoextension-04.txt> as Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2014-08-13. Exceptionally, comments may be
>sent to [email-masked] instead. In either case, please retain the

I took a quick look at draft-ietf-forces-protoextension-04.  In Section 5:

   "A a new sub-registry for EXTENDEDRESULT-TLV Result Values needs to be
    created.  The codes 0x00-0xff are mirrored from the RESULT-TLV Result
    Values sub-registry and must not be allocated.  The codes 0x100-0x200
    are reserved for private use as described earlier and the codes
    0x200-0xffffffff are reserved for future use; these codes will be
    allocated on First Come First Served basis and require specification
    as well approval of an expert review."

The assignment requirements for the new sub-registry are:

    (a) First Come First Served

    (b) Specification Required

    (c) Expert Review

Could the working group explain what the above means?

I took a quick look at the mailing list archives ( 
http://www.ietf.org/mail-archive/web/forces/current/maillist.html ) 
from December 6, 2012 to August 1, 2014.  There was a comment from 
Joel on 9 June ( 
http://www.ietf.org/mail-archive/web/forces/current/msg04825.html 
).  There was a WGLC on June 17 ( 
http://www.ietf.org/mail-archive/web/forces/current/msg04828.html 
).  The Last Call was sent out on June 30 ( 
http://www.ietf.org/mail-archive/web/forces/current/msg04875.html 
).  According to the Shepherd write-up:

   "The extensions are straightforward, and there was no difficulty in coming
    to consensus on all points described. There were suggested extensions for
    earlier versions of the document that were not included based on 
discussions
    in the WG for the sake of simplicity. At least one implementation has
    validated some of the features described in the document.
    We believe the working group is solidly behind this document."

Given that the Forces mailing list archive does not show any review 
(excluding the one from the Area Director) or significant comments 
during that period I fail to understand how the document shepherd 
determined that the "working group is solidly behind this 
document".  The "coming to consensus" looks like nobody in the 
working group said anything substantive above the draft.

This proposed "Proposed Standard" is supposed to reflect the 
consensus of the IETF.  I don't see how the IESG can make such a 
determination given the silent Working Group Last Call and Last 
Call.  I found it hard to believe that all the members of the IESG 
attended the working group sessions to get a sense of whether the 
working group is solidly behind this document.  I glanced at the blue 
sheets for a working group session ( 
http://www.ietf.org/proceedings/88/bluesheets/bluesheets-88-forces-01.pdf 
) and it showed that there was only one Area Director attending that session.

I'll highlight a few points from RFC 2418:

   "Decisions reached during a face-to-face meeting about topics
    or issues which have not been discussed on the mailing list,
    or are significantly different from previously arrived mailing
    list consensus MUST be reviewed on the mailing list."

   "The Chair should make sure that discussions on the list are
    summarized and that the outcome is well documented (to avoid
    repetition)."

   "As a general practice, the Working Group Chair and Document Editor
    positions are filled by different individuals to help ensure that
    the resulting documents accurately reflect the consensus of the
    working group and that all processes are followed."

   "Once that a WG has determined at least rough consensus exists within
    the WG for the advancement of a document the following ...".

My summary is:

   (a) There hasn't been any noteworthy discussion on the mailing list.

   (b) The write-up mentions "consensus" whereas the public record
       only shows silence.

   (c) There isn't any mention on the mailing list that there was
       even rough consensus within the working group for the
       advancement of the document.

The most appropriate boilerplate text for this (intended) Proposed 
Standard would be:

   "It represents the consensus of the IESG.  It has received review
    by the IESG and a few directorates and has been approved for
    publication by the Internet Engineering Steering Group (IESG)."

Regards,
S. Moonesamy

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 8 Aug 2014 07:43:36 -0400

Hi SM,

> Could the working group explain what the above means?

0x200-0xffffffff are reserved for future use to be allocated on FCFS
using expert review.
Codes 0x100-0x200 are available free to use by a deployment as
long there is agreement between two inter-operating sides on their
semantics.
Suggestions on how this could be clarified?

> (excluding the one from the Area Director) or significant comments during
> that period I fail to understand how the document shepherd determined that
> the "working group is solidly behind this document".  The "coming to
> consensus" looks like nobody in the working group said anything substantive
> above the draft.
>

It is a small draft with very simple updates.
There was some controversy on earlier versions of the draft.
Those controversies were removed. There was really nothing to disagree on.

> This proposed "Proposed Standard" is supposed to reflect the consensus of
> the IETF.  I don't see how the IESG can make such a determination given the
> silent Working Group Last Call and Last Call.  I found it hard to believe
> that all the members of the IESG attended the working group sessions to get
> a sense of whether the working group is solidly behind this document.  I
> glanced at the blue sheets for a working group session (
> http://www.ietf.org/proceedings/88/bluesheets/bluesheets-88-forces-01.pdf )
> and it showed that there was only one Area Director attending that session.
>

On 99% of our meetings only our relevant area director attends.  There has been
the odd occasion where we had both ADs attend.
Why is presence of only one AD an issue? As far as i remember, the AD
has *never*
missed a single meeting or is unaware of a single decision we reached on
this or other documents.
Other individual IESG members get to decide during the publication process.

> The most appropriate boilerplate text for this (intended) Proposed Standard
> would be:
>

Look at the minutes, listen to the audio and review the slides.

This is a chartered WG item. Volunteers put time into it and folks
implemented. There is no controversy to merit any discussions.
The mailing list does not capture all the discussions.

Here's a cutnpaste on the last time the draft was discussed
at the meetings (IETF 88).

------
Protocol Update (13:31):
Slides: http://tools.ietf.org/agenda/88/slides/slides-88-forces-4.pdf
        http://www.ietf.org/proceedings/88/slides/slides-88-forces-4.pdf
Draft: http://tools.ietf.org/html/draft-jhs-forces-protoextenstion-01
Jamal Hadi Salim
        - There was strong resistance so far against table append.
        Agreed to remove table append.
        Jamal plans to write another document in the future to cover
        table append vs replace vs exclusivity.
        -Table Range Query looks solid from implementation experience.
         A single success(to get/delete) is considered an overall success..
        -Extended Result TLV
                Add an 8-bit field for result causes
                Rick Taylor: 2 Qs
                        What encoding for strings? UTF-8
                        Prefer integer code rather than natural language
                        string result.
        -Large Sparse Data
                Sparse data TLV has 16 bit length.  This is too
                small since ILVs have 32-bit lengths.  There is a mismatch.
                Q: Convert the count from bytes to words for a "new" TLV?
                Joel Halpern: TLV meaning mixing is a bad idea.
                 So answer is No, since this change of meaning is surprising.
                 Better off: Don't solve this problem, please.
                Rick Taylor: Can't change length based on type.
                Rich G?: Length is length is length
                Weiming Wang: Is this a question of efficiency?
                  Designed the ILV - may need large I.
-------

Discussions are useful - but not when they are unnecessary
(aka Australian Parliament Bike Shed).

cheers,
jamal

> Regards,
> S. Moonesamy
> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 8 Aug 2014 15:26:32 -0400

SM,

On Fri, Aug 8, 2014 at 1:17 PM, S Moonesamy <[email-masked]> wrote:
> Hi Jamal,
>
> At 04:43 08-08-2014, Jamal Hadi Salim wrote:
>>
> My question was about the assignment requirements. :-)  I'll explain; let's
> say I would like to request a code point from that sub-registry.  What do I
> have to do to get that code point?  Would I, for example, have to contact a
> Designated Expert when the sub-registry policy is "First Come First
> Served"?.  The (IETF) definition for "First Come First Served" is:
>
>   "Assignments are made to anyone on a first come, first served basis.
>    There is no substantive review of the request, other than to ensure
>    that it is well-formed and doesn't duplicate an existing assignment."
>
> What does IANA need to see in the specification to assign that code point to
> me?  Do I have to bother the Routing Area Director to sponsor a RFC for me
> to get that code point?
>

If two people ask for the same code - then fcfs is used. The expert is
consulted always.
If that intent in the doc is not clear - help us come with better wording.
Feel free to mutilate the paragraph we have;->

> My point was that the IESG members are making a determination of IETF
> Consensus.  Let's assume that I am objecting to publication on consensus
> grounds.

I  believe it would be within the realm of your rights to object, but
please dont work on assumptions. It is better to get insight.

>It would be questionable if the other Area Directors say that "we
> took the relevant Area Director's word, we did not see any comments on
> [email-masked], we believe that there is IETF Consensus".
>

I think the general trend is to give the AD the benefit of doubt. If there
are loopholes to be closed , i think that is a separate discussion.

>
> I did put in some time to comment about this draft. :-)

Sorry if we missed your earlier comments; there is still room to resolve any
thing you brought up in the past that was missed. (Re)send either private mail
or email to the list.

>As I mentioned in
> my previous message, there isn't anything substantive to show that there
> were volunteers who reviewed this chartered WG item.
>
> The message at
> http://www.ietf.org/mail-archive/web/forces/current/msg04880.html mentions
> that:
>
>
>   "There was some controversy on earlier versions of the draft."
>
> The above quoted paragraph mentions that:
>
>
>   "There is no controversy to merit any discussions."
>
> I cannot tell whether there was controversy or not.

When this document was published as a WG document those controversial
issues were removed. So this document, as articulated by the shepherd,
has no controversy. Does that make sense?
I pointed to one meetings minutes but if you go backwards, things will
make more sense.
Again:
This is a simple document to a simple update (as you acknowledge).
My comment on bike-shedding was more to make the point that
we shouldnt have discussions just because we can.

>May I ask who
> implemented this specification?
>

Perhaps the question is motivated because you see some technical flaw
in the spec? It would help to point what that is so we can either
provide clarification or fix something. [Example, the comments from
the security directorate tried to point out to some possible security issues.
We provided clarification.]

To satisfy your curiosity:
I can only vaguely respond that there are implementations that
run in real serious deployments that have implemented the majority
of the spec - ongoing with implementation to complete the spec.

>
> Thanks for the above extract of the minutes.
>

That is  a sample space of one meeting (i only looked at the minutes
for that meeting because you posted the meeting bluesheets). There
were controversies on the original individual draft. That was the tail end
of the discussions.

*Not everything* happens on lists. That is why we need meetings
and a water fountain.
There was more than one meeting where discussions happened
in regards to the eventual draft. But lets look at the meeting you brought up:
I am pretty sure if you listened to the audio of just that one meeting
you will get a better feeling of what the minute taker missed.
And if you attended that meeting, you will get even better view.
And if you participated earlier even more sense.

> The IESG could describe my messages about the draft as the Australian
> Parliament Bike Shed in response to my point about:
>
>
> It would also have to respond to the point about the determination of
> consensus by the WG Chair or Document Shepherd.
>
> I note that there was a comment about another draft from this working group:
>
>    "I notice that the Adrian's AD review commented about the lack of working
>     group review, while the shepherd writeup comments that the working group
>     had a solid consensus on this draft. On the surface, those comments seem
>     to conflict."
>
> The bottom line is that the IESG would be approving a boilerplate which is
> misleading as the average reader would believe that some minima of the
> process details have been followed.
>

Well, I hope there is clarity in my comments.

cheers,
jamal

---

From: S Moonesamy <[email-masked]>
Date: Fri, 08 Aug 2014 10:17:01 -0700

Hi Jamal,
>Suggestions on how this could be clarified?

My question was about the assignment requirements. :-)  I'll explain; 
let's say I would like to request a code point from that 
sub-registry.  What do I have to do to get that code point?  Would I, 
for example, have to contact a Designated Expert when the 
sub-registry policy is "First Come First Served"?.  The (IETF) 
definition for "First Come First Served" is:

What does IANA need to see in the specification to assign that code 
point to me?  Do I have to bother the Routing Area Director to 
sponsor a RFC for me to get that code point?

>It is a small draft with very simple updates.

Yes.

>Those controversies were removed. There was really nothing to disagree on.

[snip]

My point was that the IESG members are making a determination of IETF 
Consensus.  Let's assume that I am objecting to publication on 
consensus grounds.  It would be questionable if the other Area 
Directors say that "we took the relevant Area Director's word, we did 
not see any comments on [email-masked], we believe that there is IETF 
Consensus".

>Look at the minutes, listen to the audio and review the slides.

[snip]

>The mailing list does not capture all the discussions.

I did put in some time to comment about this draft. :-)  As I 
mentioned in my previous message, there isn't anything substantive to 
show that there were volunteers who reviewed this chartered WG item.

The message at 
http://www.ietf.org/mail-archive/web/forces/current/msg04880.html 
mentions that:

I cannot tell whether there was controversy or not.  May I ask who 
implemented this specification?

The bottom line is that the IESG would be approving a boilerplate 
which is misleading as the average reader would believe that some 
minima of the process details have been followed.

Regards,
S. Moonesamy

---

From: Barry Leiba <[email-masked]>
Date: Fri, 8 Aug 2014 15:42:25 -0400

> If that intent in the doc is not clear - help us come with better wording.

That is not FCFS; that is Expert Review, or perhaps Specification
Required.  You can (actually, should) then give instructions to the
designated expert about what she should consider in her review.

Confusing registration policies are one of the biggest problems we
have with IANA considerations.  Read RFC 5226 -- or, better, read
draft-leiba-cotton-iana-5226bis, and look at Section 4 carefully.  If
you want to require a specification, then use "Specification
Required"; a designated expert will be appointed to review the
specifications and approve (or not) the registrations.  If you want an
expert to review registration requests, but you do *not* require a
specification, then use "Expert Review".  In either case, provide
instructions to the expert, saying what factors to consider in the
review, and when it is and is not appropriate to deny or push back on
a request.

If you really do want everyone who asks for a registration to get it,
with no review at all, then "First Come First Served" is your guy.
But remember that there is only the barest sanity check made for that
(IANA will make sure the request has the required information and
doesn't appear to be spam), and there is no technical review
whatsoever.

Please do not mix multiple policy names in the same sentence, thinking
that saying more words helps.  The terms are already defined in 5226
(and 5226bis); use them.

Barry

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 8 Aug 2014 16:04:36 -0400

On Fri, Aug 8, 2014 at 3:42 PM, Barry Leiba <[email-masked]> wrote:

> specifications and approve (or not) the registrations.

If Specification Required implicitly also means expert review is needed
then that is what we need. I thought you had to explicitly state each.
Thanks for the detail - I will update the doc.

cheers,
jamal

---

From: Joel <[email-masked]>
Date: Fri, 08 Aug 2014 16:07:50 -0400

Yes, I believe that  "Specification Required" as per RFC 5226 does what 
we want in terms of the registry.
Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 8 Aug 2014 16:19:47 -0400

SM,

On Fri, Aug 8, 2014 at 3:49 PM, S Moonesamy <[email-masked]> wrote:
> Hi Jamal,
>
> At 12:26 08-08-2014, Jamal Hadi Salim wrote:
>>
> I prefer to leave that to one to the Area Directors while I peck on the
> process issue. :-)
>

Barry Leiba provided clarity ;->

> If the above means listening to higher authority, such as what is said by an
> Area Director, well, you know ... :-)
>

Authority should always be questioned. There are limits (such as challenging the
AD on authority of whether the world is round instead of being so
obviously flat).
But micro-managing an AD's trust managing a WG is not a scalable solution.

> I was referring to my first message which you responded to.  To be fair,
> your responsiveness is better than what I am used to in the IETF.
>

Ok, sorry - I was scratching my head trying to remember a discussion.

> The above paragraph does not name any implementations or provide any public
> information about the real serious deployments issues.
>

We dont want to name any implementations - unless process requires us to.
There are some implementations that were named in the past (two interop
RFCs were published, but they dont apply to this spec).

> I did not listen to the audio.  The IESG may be able to use that to justify
> its decision.   However, that can be challenged.
>

My point on not making assumptions is that your sample space is very
limited to reach a conclusion that there was no consensus. If you really
want to make that claim fairly then you need to do more homework
(or as i pointed to get insight). There are a lot of factors involved other
than looking at who posted on the list.

cheers,
jamal

---

From: S Moonesamy <[email-masked]>
Date: Fri, 08 Aug 2014 12:49:17 -0700

Hi Jamal,
>Feel free to mutilate the paragraph we have;->

I prefer to leave that to one to the Area Directors while I peck on 
the process issue. :-)

>please dont work on assumptions. It is better to get insight.

If the above means listening to higher authority, such as what is 
said by an Area Director, well, you know ... :-)

>are loopholes to be closed , i think that is a separate discussion.

Ok.

>thing you brought up in the past that was missed. (Re)send either private mail

I was referring to my first message which you responded to.  To be 
fair, your responsiveness is better than what I am used to in the IETF.

>has no controversy. Does that make sense?

That makes sense.

>we shouldnt have discussions just because we can.

I agree that we shouldn't have discussions just because we can.

>We provided clarification.]

I was homing on the process angle.

>of the spec - ongoing with implementation to complete the spec.

The above paragraph does not name any implementations or provide any 
public information about the real serious deployments issues.

>And if you participated earlier even more sense.

I did not listen to the audio.  The IESG may be able to use that to 
justify its decision.   However, that can be challenged.

I'll raise the process issue on [email-masked].

>Well, I hope there is clarity in my comments.

There is.  Thanks for the diligent response.

Regards,
S. Moonesamy

---

From: Pete Resnick <[email-masked]>
Date: Fri, 8 Aug 2014 15:34:38 -0500

A couple of points about the discussion of the writeup and coming to 
consensus:

>> has no controversy. Does that make sense?

Sure, but do keep in mind that the writeup is there to help out the IESG 
during Last Call and IESG Review. If there was a big controversy about 
going with technology A and the WG fought it out, but in the end decided 
that technology B solved the same problem as A and was uncontroversial, 
the shepherd needs to decide if there's some chance that someone will 
bring up A again, either in Last Call or in IESG Review. If so, it might 
be a good idea to mention in the writeup, "We had a big controversy 
about technology A in that some people thought that it killed kittens, 
but in the end we went with technology B, which solved the same problem 
and created extra-cuddly kittens". Simply saying, "No controversy about 
B" is OK, but it doesn't give us much to go on if A gets brought up 
again. Either way, it's a judgment call.

>> And if you participated earlier even more sense.

Let's be very careful here. Yes, lots of stuff does get done at 
face-to-face meetings, and by design teams, and sometimes by the water 
fountain or at a bar. But in the end, *all* of those things need to make 
it to the list. We've got to have written documentation *somewhere* 
about the decisions that were made, and folks who were not able to show 
up in person need to be able to review (and possibly challenge) them. If 
all we're talking about is a "feeling" and a "sense" of the discussion 
being missed, that's OK. But if the minute taker is missing the essence 
of what decision was made and why, that's not good. We *must* be able to 
find out that information, and (at least given our procedures now) it 
must be on the mailing list.

You didn't say that any of the actions and decisions were missing from 
the minutes, but I think that's what SM heard.

> I'll raise the process issue on [email-masked].

And let's not do that unless we know that a process issue actually 
exists. No, the IESG does not go back and listen to the audio to justify 
decisions. Like everyone else, we try to rely on the mailing list, 
what's in the document, and what's in the writeup.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 8 Aug 2014 18:01:29 -0400

On Fri, Aug 8, 2014 at 4:34 PM, Pete Resnick <[email-masked]> wrote:

> during Last Call and IESG Review. If there was a big controversy about going
> with technology A and the WG fought it out, but in the end decided that
> technology B solved the same problem as A and was uncontroversial, the
> shepherd needs to decide if there's some chance that someone will bring up A
> again, either in Last Call or in IESG Review. If so, it might be a good idea
> to mention in the writeup, "We had a big controversy about technology A in
> that some people thought that it killed kittens, but in the end we went with
> technology B, which solved the same problem and created extra-cuddly
> kittens". Simply saying, "No controversy about B" is OK, but it doesn't give
> us much to go on if A gets brought up again. Either way, it's a judgment
> call.
>

In this case it was a toss up, I think.
The original document was an individual contribution. As author, I wouldnt
say i was ecstatic about some things we removed. But we need to make progress.
We cant keep debating things that could be resolved later.

To quote the last meeting discussion:
-----
        There was strong resistance so far against table append.
        Agreed to remove table append.
        Jamal plans to write another document in the future to cover
        table append vs replace vs exclusivity.
-----

So there is intent to later publish a mininal informational document.
Infact our implementation already has some of those original idea.
In retrospect we could have stated that history - but i believe the shepherd
was refering to the current document (or its 4th revision when he did
the writeup).

>
> Let's be very careful here. Yes, lots of stuff does get done at face-to-face
> meetings, and by design teams, and sometimes by the water fountain or at a
> bar. But in the end, *all* of those things need to make it to the list.
> We've got to have written documentation *somewhere* about the decisions that
> were made, and folks who were not able to show up in person need to be able
> to review (and possibly challenge) them. If all we're talking about is a
> "feeling" and a "sense" of the discussion being missed, that's OK. But if
> the minute taker is missing the essence of what decision was made and why,
> that's not good. We *must* be able to find out that information, and (at
> least given our procedures now) it must be on the mailing list.
>
> You didn't say that any of the actions and decisions were missing from the
> minutes, but I think that's what SM heard.
>

I think i was being defensive to the statement there was "no consensus". I may
have even felt a little offended but i realize it was meant with good intention.

cheers,
jamal

---

From: S Moonesamy <[email-masked]>
Date: Fri, 08 Aug 2014 14:42:38 -0700

Hi Pete,
At 13:34 08-08-2014, Pete Resnick wrote:
>face-to-face meetings, and by design teams, and sometimes by the 
>water fountain or at a bar. But in the end, *all* of those things 
>need to make it to the list. We've got to have written documentation 
>*somewhere* about the decisions that were made, and folks who were 
>not able to show up in person need to be able to review (and 
>possibly challenge) them. If all we're talking about is a "feeling" 
>and a "sense" of the discussion being missed, that's OK. But if the 
>minute taker is missing the essence of what decision was made and 
>why, that's not good. We *must* be able to find out that 
>information, and (at least given our procedures now) it must be on 
>the mailing list.
>
>You didn't say that any of the actions and decisions were missing 
>from the minutes, but I think that's what SM heard.

My point is, as you mentioned above: "We *must* be able to find out 
that information, and (at least given our procedures now) it must be 
on the mailing list".  I looked at the Forces mailing list archive to 
get a sense of the discussion.  I found the following messages:

I-d-announce:

http://www.ietf.org/mail-archive/web/forces/current/msg04727.html
http://www.ietf.org/mail-archive/web/forces/current/msg04791.html
http://www.ietf.org/mail-archive/web/forces/current/msg04821.html
http://www.ietf.org/mail-archive/web/forces/current/msg04822.html
http://www.ietf.org/mail-archive/web/forces/current/msg04874.html

Other:
http://www.ietf.org/mail-archive/web/forces/current/msg04765.html
http://www.ietf.org/mail-archive/web/forces/current/msg04768.html
http://www.ietf.org/mail-archive/web/forces/current/msg04823.html
http://www.ietf.org/mail-archive/web/forces/current/msg04824.html
http://www.ietf.org/mail-archive/web/forces/current/msg04825.html

WGLC:

http://www.ietf.org/mail-archive/web/forces/current/msg04827.html
http://www.ietf.org/mail-archive/web/forces/current/maillist.html
http://www.ietf.org/mail-archive/web/forces/current/msg04846.html
http://www.ietf.org/mail-archive/web/forces/current/msg04848.html

AD Review:

http://www.ietf.org/mail-archive/web/forces/current/msg04866.html
http://www.ietf.org/mail-archive/web/forces/current/msg04868.html

Last Call:

The discussion was mainly between the author and the Document 
Shepherd.  There was a comment from Joel.

There wasn't any decisions taken to the mailing list.  There isn't 
anything on [email-masked].  Would a person who has not been attending 
the face-to-face meetings be able to understand the decisions?  I 
don't think so (see URLs provided above).  Would that person be able 
to find out whether there has actually been public review and some 
level of agreement?  What the person would find is the above URLs and 
agreement between the author, the Document Shepherd and some 
directorate reviews.  This is what that IESG might also be looking at 
as it decides whether there is IETF Consensus.  You (used in a 
general sense) only have formal reviews on which to base the decision.

>exists. No, the IESG does not go back and listen to the audio to 
>justify decisions. Like everyone else, we try to rely on the mailing 
>list, what's in the document, and what's in the writeup.

There are some points such as what is explained above which might not 
be apparent.  The process issue is that the documentation does not 
show the decisions and actions.  What the IESG would be approving is, 
in my opinion, lazy consensus.  It is possible to challenge that IESG decision.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Fri, 08 Aug 2014 14:57:31 -0700

Hi Jamal,
>than looking at who posted on the list.

There is a message from Pete Resnick to which I replied to.  I would 
prefer if we take up the discussion about consensus on that exchange 
if you are okay with that.

Regards,
S. Moonesamy

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 9 Aug 2014 11:50:53 +0100

Let me pick an email in the middle of the thread and then top-post :-)

I would prefer that in questions of whether there was consensus, the debate was addressed by the other WG chair (not the one who is an author of this document).
I would prefer that questions about what the shepherd write-up says were addressed by the document shepherd.

I think that the questions raised in this thread are valuable but need context.

The Shepherd write-up is primarily a communication between the document shepherd and the responsible AD (me). I am capable of following up on issues that are unclear or seem like fudge. i can do that publically or privately. I can require that the write-up is updated or leave it fallow. Any passer-by who reads the write-up and has concerns can raise them to me or on the public list (as has happened).

Shepherd write-ups do not call consensus nor should they claim consensus. They should report facts (what happened, what was seen on the list, etc.). I don't think you could appeal a shepherd write-up for what it says about consensus although you might make counter claims to the responsible AD.

The ForCES working group is winding down and close to closing. It has a few more documents to push out and nearly all of the work has been done on these. Getting anything out of the working group at this stage beyond absence of dissent will be impractical. As AD I am choosing between:
- shut the WG and have only ISE RFCs on ForCES
- shut the WG and allow AD Sponsored RFCs on ForCES
- let the WG wrap up what is in hand.
I choose the latter for efficiency and best hope of document review.

Cheers,
Adrian

> -----Original Message-----
> From: iesg [mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
> Sent: 08 August 2014 21:20
> To: S Moonesamy
> Cc: [email-masked]; The IESG; Evangelos Haleplidis
> Subject: Re: [forces] Last Call: <draft-ietf-forces-protoextension-04.txt> (ForCES
> Protocol Extensions) to Proposed Standard
> 
> SM,
> 
> public

---

From: S Moonesamy <[email-masked]>
Date: Sat, 09 Aug 2014 09:28:49 -0700

Hi Adrian,
>Let me pick an email in the middle of the thread and then top-post :-)

Ok. :-)

>I would prefer that in questions of whether there was consensus, the 
>debate was addressed by the other WG chair (not the one who is an 
>author of this document).

Ok.

>The Shepherd write-up is primarily a communication between the 
>document shepherd and the responsible AD (me). I am capable of 
>following up on issues that are unclear or seem like fudge. i can do 
>that publically or privately. I can require that the write-up is 
>updated or leave it fallow. Any passer-by who reads the write-up and 
>has concerns can raise them to me or on the public list (as has happened).

Ok.

>Shepherd write-ups do not call consensus nor should they claim 
>consensus. They should report facts (what happened, what was seen on 
>the list, etc.). I don't think you could appeal a shepherd write-up 
>for what it says about consensus although you might make counter 
>claims to the responsible AD.

It would be very difficult to appeal a Shepherd write-up.  For what 
it is worth, it has never been done before.

>The ForCES working group is winding down and close to closing. It 
>has a few more documents to push out and nearly all of the work has 
>been done on these. Getting anything out of the working group at 
>this stage beyond absence of dissent will be impractical. As AD I am 
>choosing between:

Ok.

Regards,
S. Moonesamy

---

From: Evangelos Haleplidis <[email-masked]>
Date: Mon, 11 Aug 2014 08:09:48 -0400

Greetings,

Apologies for the late reply but I'm currently in vacations and will be for
another two weeks with tentative access and time to read emails.

Regarding the shepherd writeup, I was, as Jamal noted, referring to the
latest document version, where all of the issues that were controversial
and were in fact challenged, specifically by Joel, removed. In hindsight, I
should probably have included them in the writeup. But it was not an issue
of A or B, rather of A or not A, and choosing not A to achieve consensus
(Jamal did note that he was not actually happy with some of the removed
items)

Now in regards to consensus,  after resolving these issues there was no
more conflicts or objections, I thought that the wg did not object anymore
to the new version, taken into account that these changes are small and
make sense to be included in the protocol.

With regards,
Evangelos Haleplidis
On Aug 9, 2014 8:10 PM, "S Moonesamy" <[email-masked]> wrote:

>> debate was addressed by the other WG chair (not the one who is an author of
>> this document).
>> The Shepherd write-up is primarily a communication between the document
>> shepherd and the responsible AD (me). I am capable of following up on
>> issues that are unclear or seem like fudge. i can do that publically or
>> privately. I can require that the write-up is updated or leave it fallow.
>> Any passer-by who reads the write-up and has concerns can raise them to me
>> or on the public list (as has happened).
>>
>
> Ok.
>
>  Shepherd write-ups do not call consensus nor should they claim consensus.
>> They should report facts (what happened, what was seen on the list, etc.).
>> I don't think you could appeal a shepherd write-up for what it says about
>> consensus although you might make counter claims to the responsible AD.
>>
>
> It would be very difficult to appeal a Shepherd write-up.  For what it is
> worth, it has never been done before.
>
>  The ForCES working group is winding down and close to closing. It has a
>> few more documents to push out and nearly all of the work has been done on
>> these. Getting anything out of the working group at this stage beyond
>> absence of dissent will be impractical. As AD I am choosing between: