Subject: Re: [nvo3] Proposed timeline for publishing Requirements

From: Carter Bullard <[email-masked]>
Date: Sun, 1 Feb 2015 09:29:20 -0500

Benson and Matthew,
I cannot agree with this line of thinking.  Of course there is benefit in having the requirements documented regardless if there are ever any solutions delivered.  And how can solutions be successfully developed, tested and verified without a published requirements document ??

There are many processes available for modifying the document after publication.
Many people have put in effort.  Finish this phase, get something successful out of the process and then move on to phase 2.

Carter

Carter Bullard • CTO
150 E 57th Street Suite 12D
New York, New York 10022-2795
Phone +1.212.588.9133 • Mobile +1.917.497.9494

> On Jan 31, 2015, at 10:13 PM, Benson Schliesser <[email-masked]> wrote:
> 
> Dear NVO3 Contributors -
> 
> As mentioned during the virtual interim meeting last week, Matthew and I have been discussing when to publish the various NVO3 requirements documents. Our view is that there is no real value in publishing requirements if we fail to also deliver solutions. Further, we expect that the process of developing solutions will enhance our collective understanding, and therefore put NVO3 in a better position to evaluate whether the requirements documents are complete.
> 
> Finally, in some cases it may not make sense to have requirements documents that are separate from the solution. In other words, it is possible that the requirements may simply be a section of a solution document. This would need to be evaluated after we have a more firm idea of what the solution documentation might look like.
> 
> Thus, it is our proposal that we should update the milestones to reflect that the requirements will be published at the same time as the solutions. We welcome any feedback on this proposal within the next two weeks.
> 
> Cheers,
> -Benson & Matthew
> 
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: Benson Schliesser <[email-masked]>
Date: Thu, 05 Feb 2015 14:25:35 -0500

Hi, Carter. Thanks for your feedback. I have some comments inline below.

I'd also like to encourage all other contributors to provide feedback 
over the next week.

Carter Bullard wrote:
> I cannot agree with this line of thinking. Of course there is benefit in
> having the requirements documented regardless if there are ever any
> solutions delivered. And how can solutions be successfully developed,
> tested and verified without a published requirements document ??

To be clear, the requirements are already published as I-D documents. 
The question is if and when to publish them as RFC documents.

I don't believe anybody is waiting for the requirements to be published 
as RFC documents before submitting solutions. If I'm wrong about that 
I'd appreciate specific feedback on that.

> Many people have put in effort. Finish this phase, get something
> successful out of the process and then move on to phase 2.

We are already in "phase 2" as of our rechartering in late 2014. The WG 
is currently encouraged (indeed required) to produce solutions for NVO3 
overlays. Publishing the requirements documents is not a requirement of 
our current charter.

That being said, I do acknowledge that many people have worked on the 
requirements documents, and I plan to make sure they get appropriate 
credit in the end. That's not really an issue here, as far as I'm concerned.

As a chair, for me the only salient question is how to make sure that 
NVO3 produces good and useful protocol specifications. If you have 
thoughts specifically on how this question applies to the requirements 
drafts then I'd appreciate additional feedback.

Cheers,
-Benson

> On Jan 31, 2015, at 10:13 PM, Benson Schliesser <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> Dear NVO3 Contributors -
>>
>> As mentioned during the virtual interim meeting last week, Matthew and
>> I have been discussing when to publish the various NVO3 requirements
>> documents. Our view is that there is no real value in publishing
>> requirements if we fail to also deliver solutions. Further, we expect
>> that the process of developing solutions will enhance our collective
>> understanding, and therefore put NVO3 in a better position to evaluate
>> whether the requirements documents are complete.
>>
>> Finally, in some cases it may not make sense to have requirements
>> documents that are separate from the solution. In other words, it is
>> possible that the requirements may simply be a section of a solution
>> document. This would need to be evaluated after we have a more firm
>> idea of what the solution documentation might look like.
>>
>> Thus, it is our proposal that we should update the milestones to
>> reflect that the requirements will be published at the same time as
>> the solutions. We welcome any feedback on this proposal within the
>> next two weeks.
>>
>> Cheers,
>> -Benson & Matthew
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Carter Bullard <[email-masked]>
Date: Fri, 6 Feb 2015 12:25:38 -0500

Benson,
I apologize if I’m way off base here, but it seems to me that the first task that
the working group took on is unfinished.   The IETF doesn’t normally charter WGs
to generate I-D’s, normally the task is to generate RFCs.  And of course
the probability of the WG generating an RFC on its second charter, is probably
equal to the WGs ability to generate RFC’s on its first.

Carter

> On Feb 5, 2015, at 2:25 PM, Benson Schliesser <[email-masked]> wrote:
> 
> I'd also like to encourage all other contributors to provide feedback over the next week.
> 
> Carter Bullard wrote:
> To be clear, the requirements are already published as I-D documents. The question is if and when to publish them as RFC documents.
> 
> I don't believe anybody is waiting for the requirements to be published as RFC documents before submitting solutions. If I'm wrong about that I'd appreciate specific feedback on that.
> 
> We are already in "phase 2" as of our rechartering in late 2014. The WG is currently encouraged (indeed required) to produce solutions for NVO3 overlays. Publishing the requirements documents is not a requirement of our current charter.
> 
> That being said, I do acknowledge that many people have worked on the requirements documents, and I plan to make sure they get appropriate credit in the end. That's not really an issue here, as far as I'm concerned.
> 
> As a chair, for me the only salient question is how to make sure that NVO3 produces good and useful protocol specifications. If you have thoughts specifically on how this question applies to the requirements drafts then I'd appreciate additional feedback.
> 
> Cheers,
> -Benson
> 
>

---

From: Melinda Shore <[email-masked]>
Date: Fri, 06 Feb 2015 10:10:15 -0900

> equal to the WGs ability to generate RFC’s on its first.

I don't think this is quite fair and I don't think it's particularly
accurate.  RFCs are expensive to publish, in terms of the level of
effort required from a large number of people, ranging from working
group participants to the IESG to the RFC editor.  Furthermore, since
resource are badly constrained, doing one thing means taking resources
away from another.  Right now, the IETF is quite bogged down and it's
taking years to get useful specifications through the process and
into publication.  Because of this it is not at all clear to me that
taking resources away from publishing protocol specs to publish more
requirements/problem statement/etc. documents is a very good tradeoff.

Requirements documents are primarily *useful* to people who develop
protocols, etc.  They aren't that useful to implementers (I don't
think I've ever gone back and looked at a requirements document while
implementing a protocol - I look at the specifications).  I think
it's very clearly in the interest of pretty much everybody but
the requirements document editors (because of their interest in
getting an RFC published with their names on it) to be a bit
more flexible so that we can have a somewhat more nimble IETF.

Melinda

---

From: Carter Bullard <[email-masked]>
Date: Fri, 6 Feb 2015 14:58:26 -0500

Hey Melinda,
Most of the NVO3 requirements documents will expire before June, all
will have expired before Sept.  If they are documents of good quality and
usefulness, then the RFC process will not be onerous, and you will have
a few design goals that won’t expire into oblivion.  If the documents suck,
then they aren't helpful to people that think of themselves as designers, or
implementors, or just people for that matter, and need to be fixed.   Unless
of course, the requirements documents disagree with the direction that a
few vendors want to go in, then we definitely don’t want to publish those,
better to let them expire, and start again.

I suggest that without formalization of the requirements, you aren’t going to
get a protocol that meets many of them, or a process that serves more
than a few companies.  We’ve got many examples of poor protocols in
the IETF, possibly the result of a nimble IETF.

Carter

> On Feb 6, 2015, at 2:10 PM, Melinda Shore <[email-masked]> wrote:
>

---

From: Melinda Shore <[email-masked]>
Date: Fri, 06 Feb 2015 11:02:56 -0900

On 2/6/15 10:58 AM, Carter Bullard wrote:
> than a few companies. 

Indeed.  Pity about that HTTP thing - it had so much promise.

Melinda

---

From: Carter Bullard <[email-masked]>
Date: Fri, 6 Feb 2015 15:15:18 -0500

Hey Melinda,
If you’re point is that you have to go back to 1999 to find an IETF protocol that
was successful, then seems that you’re in agreement with my point.

Carter

> On Feb 6, 2015, at 3:02 PM, Melinda Shore <[email-masked]> wrote:
>

---

From: Melinda Shore <[email-masked]>
Date: Fri, 06 Feb 2015 11:35:33 -0900

> was successful, then seems that you’re in agreement with my point.

I'm not.  HTTPbis doesn't have a requirements document, either,
nor do a large number of other successful protocols.  Arguably
the IETF produced more useful, relevant documents back when
requirements documents and whatnot were not the norm.

I think that in general requirements documents are helpful to
the process of specification and have some historical value, but
at this point it's very clearly the case that the IETF process
has slowed down to the point that it's gotten nearly impossible
to publish documents in a timely way.  It's happened at the same
time that documents that used not to be part of the process -
problem statements, requirements documents, gap analyses, and
so on - have become part of the culture.  There's nothing in
any IETF process document that requires them.  Allow me to repeat
that: there's nothing in any IETF process document that requires
them.  So, to the extent that they're useful, yay, to the extent
that they bog the IETF down in non-specification work, boo.

Melinda

---

From: Carter Bullard <[email-masked]>
Date: Fri, 6 Feb 2015 16:08:41 -0500

Melinda, 
Maybe you should go back further.  How about say RFC 985, 1009, 1716, and 1812.
Four RFCs devoted solely to trying to get the requirements for routers down.
At a time when some of the best work was done.

The original charter for NVO3 states that optional requirements documents could
be generated, from which solutions would be implemented.  The WG decided to
go down the optional route, in order to go after solutions.  The original charter
stated that these solutions would come from requirements documents.  I interpret
that to mean that the requirements would be IETF documents, which I interpret to
be RFCs.

The only issue is, if you can proceed successfully, then proceed.  Experience
suggests that formal goals help a WG to be successful.  Httpbis had simple
requirements, catalog security properties and provide improved bindings of
semantics to underlying transport, no need for a requirements document there.
Not like it needed to change an application protocol much to be successful, and
the charter left a lot unspecified to allow for whatever else anybody wanted to
throw in.  No mention in the charter that the WG would work through requirements
documents to reach solutions.

If you think NVO3 is an equivalent to Httpbis, then I’m at a disadvantage, as I’m not
that good at thinking at that level.

Its up to the WG to decide if it can proceed successfully without formal
requirements.  My opinion is that there are a lot of ‘ time to market ‘ pressures
that will compel implementations to be less than adequate, and without
good control over the design goals, these implementations will get leverage
over the market that the WG is trying to influence.  Which would be a shame.

Carter

> On Feb 6, 2015, at 3:35 PM, Melinda Shore <[email-masked]> wrote:
>

---

From: Liyizhou <[email-masked]>
Date: Sat, 7 Feb 2015 07:26:57 +0000

Hi Benson,

Specifically talking about the document draft-ietf-nvo3-hpvr2nve-cp-req, VDP protocol with some extensions can be used as a solution. VDP was designed by IEEE 802.1. So it would be more convenient to be extended there.

The co-authors would like to suggest to take the following actions for this specific requirement draft:

1. We will add a section to describe the VDP applicability and enhancement needs. 
2. Send out the liaison to IEEE 802.1 based on the updated version for their information. 
3. After another round of editing, publish the document as RFC to be used as a stable base for easy reference.

Cheers,
Yizhou

-----Original Message-----
From: nvo3 [mailto:[email-masked]] On Behalf Of Benson Schliesser
Sent: Sunday, February 01, 2015 11:14 AM
To: [email-masked]
Subject: [nvo3] Proposed timeline for publishing Requirements

Dear NVO3 Contributors -

Cheers,
-Benson & Matthew

---

From: "Black, David" <[email-masked]>
Date: Sat, 7 Feb 2015 17:52:37 +0000

Carter,

> At a time when some of the best work was done.

Perhaps you should think more about the types and contents of requirements
documents.  Those four router requirements RFCs contain *implementation*
requirements for routers, and analogous implementation requirements are
to be found in almost every IETF protocol specification.

In contrast, the NVO3 requirements documents (and I'm an author of some
of them) are protocol *design* requirements documents; they do not contain
implementation requirements (those go into the protocol specs).  There is a
difference, really there is ...

Just for grins, I dug up a design concerns draft of mine (it includes
design requirements) from over a decade ago:

	http://tools.ietf.org/html/draft-black-rdma-concerns-00

That draft accomplished its intended purpose of influencing the WG's design
activity; in that case, publication as an RFC was not needed (and in fact
the draft even said so up front).

Thanks,
--David

> From: nvo3 [mailto:[email-masked]] On Behalf Of Carter Bullard
> Sent: Friday, February 06, 2015 4:09 PM
> To: Melinda Shore
> Cc: [email-masked]
> Subject: Re: [nvo3] Proposed timeline for publishing Requirements
> 
> Melinda,
> If you think NVO3 is an equivalent to Httpbis, then I'm at a disadvantage, as
> I'm not
> requirements.  My opinion is that there are a lot of ' time to market '
> pressures
> >> If you're point is that you have to go back to 1999 to find an IETF
> protocol that
> >> was successful, then seems that you're in agreement with my point.
> >

---

From: Carter Bullard <[email-masked]>
Date: Sat, 7 Feb 2015 13:14:48 -0500

Hey David,
Its pretty simple … Reading only from the NVO3 charter, which I believe is the only relevant IETF process document for the NVO3 WG, and skipping to the paragraphs that describe how the protocols will be developed....

The NVO3 WG may produce requirements for a network virtualization control plane, and will select, extend, and/or develop one protocol for each of the functional interfaces identified to support the architecture. 

I interpret that to mean that a requirements document will identify functional interfaces, from which one protocol will be selected, extended and/or developed.  I think that document should be an RFC.
The NVO3 WG may produce requirements for network virtualization data planes based on encapsulation of virtual network traffic over an IP- based underlay data plane. Such requirements should consider OAM and  security. Based on these requirements the WG will select, extend, and/or  develop one or more data plane encapsulation format(s).

I interpret that to mean that a requirements document will be used to select, extend, and/or develop one or more data plane encapsulation format(s).  I think that document should be an RFC.

My only point, is that if you do not take whatever requirements documents you have to RFC, then you will not have completed the dependent task defined in the WG charter for developing NVO3 protocols.  Yes you have an architecture RFC,  great, first step in the charter.  Next step is “may produce requirements”.  Great, but if you move on to “select, extend and/or develop” you need to have formalized the requirements to the point where you can identify the functional interface.  That I believe would be an in the form of an RFC.

I hope you can understand my position.  It is simply a superficial interpretation of the WG charter, and why I suggest that you should take any requirements documents that the WG would like to use, to RFC.

Carter

> On Feb 7, 2015, at 12:52 PM, Black, David <[email-masked]> wrote:
> 
> Carter,
>

---

From: "Black, David" <[email-masked]>
Date: Sat, 7 Feb 2015 18:32:16 +0000

Carter,

And the place where you and I part company is the emphasis placed on “process” (e.g., “the only relevant IETF process document for the NVO3 WG”) - I’m interested in seeing this WG deliver results ... both the WG charter and requirements documents are tools that can contribute to achieving that goal, but the focus should be on the goal, not the tools used to achieve it, IMHO.

Thanks,
--David (chair or past chair of 5 IETF WGs)

From: Carter Bullard [mailto:[email-masked]]
Sent: Saturday, February 07, 2015 1:15 PM
To: Black, David
Cc: [email-masked]
Subject: Re: [nvo3] Proposed timeline for publishing Requirements

Hey David,

   Carter

   On Feb 7, 2015, at 12:52 PM, Black, David <[email-masked]<mailto:[email-masked]>> wrote:

   Carter,

   Thanks,
   --David

   -----Original Message-----
   From: nvo3 [mailto:[email-masked]] On Behalf Of Carter Bullard
   Sent: Friday, February 06, 2015 4:09 PM
   To: Melinda Shore
   Cc: [email-masked]<mailto:[email-masked]>
   Subject: Re: [nvo3] Proposed timeline for publishing Requirements

   Melinda,

   The only issue is, if you can proceed successfully, then proceed.  Experience
   suggests that formal goals help a WG to be successful.  Httpbis had simple
   requirements, catalog security properties and provide improved bindings of
   semantics to underlying transport, no need for a requirements document there.
   Not like it needed to change an application protocol much to be successful,
   and
   the charter left a lot unspecified to allow for whatever else anybody wanted
   to
   throw in.  No mention in the charter that the WG would work through
   requirements
   documents to reach solutions.

   Carter

   On Feb 6, 2015, at 3:35 PM, Melinda Shore <[email-masked]<mailto:[email-masked]>> wrote:

   Hey Melinda,

   protocol that

   Melinda

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

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

---

From: Carter Bullard <[email-masked]>
Date: Sat, 7 Feb 2015 13:52:42 -0500

David,
And it is still pretty simple.  Want to do something different from what is in the charter, change the charter.
But as long as the charter specifies a process, the WG should follow that process.

As a charter member of the Internet Society, I think charters are important.
But I do not think that my opinion is more than that of a normally quiet active WG member.

Carter

> On Feb 7, 2015, at 1:32 PM, Black, David <[email-masked]> wrote:
> 
> Carter,
>  
> On Feb 7, 2015, at 12:52 PM, Black, David <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Carter,
> 
> 
>           http://tools.ietf.org/html/draft-black-rdma-concerns-00 <http://tools.ietf.org/html/draft-black-rdma-concerns-00>
> 
> From: nvo3 [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Carter Bullard
> Cc: [email-masked] <mailto:[email-masked]>
> On Feb 6, 2015, at 3:35 PM, Melinda Shore <[email-masked] <mailto:[email-masked]>> wrote:
> 
> https://www.ietf.org/mailman/listinfo/nvo3 <https://www.ietf.org/mailman/listinfo/nvo3>
> 
> https://www.ietf.org/mailman/listinfo/nvo3 <https://www.ietf.org/mailman/listinfo/nvo3>

---

From: Melinda Shore <[email-masked]>
Date: Sat, 07 Feb 2015 10:12:01 -0900

> But as long as the charter specifies a process, the WG should follow

The charter is negotiable as the working group makes (or doesn't
make) progress, and despite your assertions to the contrary, there
are other documents that govern working group process.  If I had
to put it in standards language, the charter is informative and
the process RFCs are normative.

Out of curiosity, I went to look at what your experience with the
IETF has been, and I found that you've submitted no drafts
(and consequently have no working group drafts, which means that
you haven't gotten a document through the working group process),
and if you've attended a meeting it hasn't been in the last year
and a half.  The reason that I was curious about this is that your
understanding about what the process is is significantly
different from those with substantial experience with IETF
process.  You've been making an awful lot of assertions about what
it is - what's your basis for it?

Melinda

---

From: Carter Bullard <[email-masked]>
Date: Sat, 7 Feb 2015 15:40:50 -0500

Hey Melinda,
I’ve been involved with the IETF from the beginning, over 30 years now, and
there are a lot of ways to contribute to the process.  There was a call for opinions
on the list, and I offered an opinion.  This is about the only thing that makes the
IETF the IETF, the ability to contribute through the mailing list.  Chair didn’t like
my response and asked others to chime in.  Great, but no one has taken up the
call, except you and David with aspirations to make good protocols but not
do too much work, and strange confrontational statements about how charters
don’t matter and that HTTP is a great protocol.

It would be nice to hear from others on this topic.

Carter

> On Feb 7, 2015, at 2:12 PM, Melinda Shore <[email-masked]> wrote:
>

---

From: Thomas Narten <[email-masked]>
Date: Mon, 09 Feb 2015 08:26:20 -0500

On Sat, 7 Feb 2015 13:52:42 -0500, Carter Bullard wrote:

> David, And it is still pretty simple.  Want to do something different from
> what is in the charter, change the charter.  But as long as the charter
> specifies a process, the WG should follow that process.

You quoted the charter as saying it would do requirements. Please note
the "may" in those sentences, not "will":

  The NVO3 WG may produce requirements for a network virtualization
  control plane, ...

...

  The NVO3 WG may produce requirements for network virtualization data 
  planes based on encapsulation of virtual network traffic over an IP-
  based underlay data plane.

That wording was intentional, becuase a number of folk feel that while
requirements can be useful, but they are a means to an end, not an end
itself.

I'm with others that would prefer to see requirements published as
RFCs only if tightly coupled with an actual substantive
document. Requirements for requirements sake are just not a good use
of anyone's time, and all-to-often take focus/cycles away for the
presumed actual purpose of a WG.

Thomas

---

From: Carter Bullard <[email-masked]>
Date: Mon, 9 Feb 2015 11:52:06 -0500

Hey Alia,
Thanks for responding. I’m not disappointed.  I think a requirements RFC for the data plane would improve the result, and possibly save a few meetings worth of time, but you won’t know until you go down one path, and see where you end up at the end.

And I hate to keep harping on what seems so simple to me.  But how does a WG proceed with “Based on these requirements the WG will select, extend and/or develop ...” without a description of "these requirements" ???   This is a challenge for the chairs and AD, and if they don’t see an issue then who am I to point it out.

Maybe the only real hurdle is if the I-Ds that are going to be used conform to BCP 78 and 79, and 6702, and had some form of Last Call.
  
Carter

> On Feb 9, 2015, at 10:21 AM, Alia Atlas <[email-masked]> wrote:
> 
> Carter,
> 
> I wrote the charter with the WG chairs.  That paragraph says "may" because it is NOT a
> requirement for the WG to produce a protocol requirements draft.  It says may because it
> is up to the WG chairs.  I would prefer not to see drafts progressing if they don't need to
> live as RFCs and be useful for a long period of time.   These types of drafts can become
> either meaningless (out of sync when the protocol spec is written) or simply unneeded for
> future (everything relevant is in the protocol spec).
> 
> I understand that you are disappointed with Benson's call.  
> 
> Regards,
> Alia
> 
> 
> 
> On Sat, Feb 7, 2015 at 1:52 PM, Carter Bullard <[email-masked] <mailto:[email-masked]>> wrote:
> David,
>> On Feb 7, 2015, at 1:32 PM, Black, David <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Carter,
>>  
>> From: Carter Bullard [mailto:[email-masked] <mailto:[email-masked]>]

---

From: Alia Atlas <[email-masked]>
Date: Mon, 9 Feb 2015 10:21:33 -0500

Carter,

I wrote the charter with the WG chairs.  That paragraph says "may" because
it is NOT a
requirement for the WG to produce a protocol requirements draft.  It says
may because it
is up to the WG chairs.  I would prefer not to see drafts progressing if
they don't need to
live as RFCs and be useful for a long period of time.   These types of
drafts can become
either meaningless (out of sync when the protocol spec is written) or
simply unneeded for
future (everything relevant is in the protocol spec).

Regards,
Alia

On Sat, Feb 7, 2015 at 1:52 PM, Carter Bullard <[email-masked]> wrote:

> And the place where you and I part company is the emphasis placed on
> “process” (e.g., “the only relevant IETF process document for the NVO3 WG”)
> - I’m interested in seeing this WG deliver results ... both the WG charter
> and requirements documents are tools that can contribute to achieving that
> goal, but the focus should be on the goal, not the tools used to achieve
> it, IMHO.
>
> Thanks,
> *From:* Carter Bullard [mailto:[email-masked] <[email-masked]>]
> *Sent:* Saturday, February 07, 2015 1:15 PM
> *To:* Black, David
> *Cc:* [email-masked]
> *Subject:* Re: [nvo3] Proposed timeline for publishing Requirements
>
> Hey David,
> Its pretty simple … Reading only from the NVO3 charter, which I believe is
> the only relevant IETF process document for the NVO3 WG, and skipping to
> the paragraphs that describe how the protocols will be developed....
>
>
> The NVO3 WG may produce requirements for a network virtualization control
> plane, and will select, extend, and/or develop one protocol for each of the
> functional interfaces identified to support the architecture.
>
>
> I interpret that to mean that a requirements document will identify
> functional interfaces, from which one protocol will be selected, extended
> and/or developed.  I think that document should be an RFC.
> The NVO3 WG may produce requirements for network virtualization
> data planes based on encapsulation of virtual network traffic over an
> IP- based underlay data plane. Such requirements should consider OAM
> and  security. Based on these requirements the WG will select, extend,
> and/or  develop one or more data plane encapsulation format(s).
> I interpret that to mean that a requirements document will be used to
> select, extend, and/or develop one or more data plane encapsulation
> format(s).  I think that document should be an RFC.
>
> My only point, is that if you do not take whatever requirements documents
> you have to RFC, then you will not have completed the dependent task
> defined in the WG charter for developing NVO3 protocols.  Yes you have an
> architecture RFC,  great, first step in the charter.  Next step is “may
> produce requirements”.  Great, but if you move on to “select, extend and/or
> develop” you need to have formalized the requirements to the point where
> you can identify the functional interface.  That I believe would be an in
> the form of an RFC.
>
> I hope you can understand my position.  It is simply a superficial
> interpretation of the WG charter, and why I suggest that you should take
> any requirements documents that the WG would like to use, to RFC.
>
> Carter
>
>
>
>
> From: nvo3 [mailto:[email-masked] <[email-masked]>] On
> Behalf Of Carter Bullard