Subject: [manet] DLEP-14: Credit Windowing (Section 9)

From: RJ Atkinson <[email-masked]>
Date: Wed, 24 Jun 2015 15:51:38 -0400

Hi,

  First, I am a big fan of the Credit Windowing mechanism
currently specified as “optional” in Section 9.

  I think it would be helpful if that were pulled out of
the DLEP base specification and into a separate I-D,
with every intention that both drafts would progress together.

  Doing so would make DLEP-15 just the mandatory items
and mandatory capabilities, but would retain the Credit-Windowing
capability in its own focused, smaller, document with
an explicit requirement that anything claiming to implement
this separate Credit-Windowing document MUST do the whole
Credit-Windowing capability as per that RFC-to-be.  

  This separation approach also would make it simpler (more clear) 
whether a particular DLEP-capable product supported that 
Credit-Windowing capability.  If a user wanted that capability, 
they could say that they want a widget that not only implements 
RFC-DLEP-Base-Spec but also implements RFC-DLEP-Credit-Windowing.  
Implementers of both could have both RFCs listed on their data sheets.

  The other benefit is that the DLEP base specification would be
shorter so that someone first coming up to speed on basic DLEP
could do so more quickly.

Thanks,

Ran

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Thu, 25 Jun 2015 13:10:58 +0000

Ran,

The option of splitting the Credit Extensions out into a separate document was thoroughly discussed, both on-list, and in the DLEP design team. The DT closed work at IETF 89 (London), reaching consensus on this and other issues. The consensus was to leave the Credit Windowing descriptions in the "core" document. No contrary opinions were expressed on-list, until now. 

So at this point, with the spec having already cleared WGLC, we're going to leave Credit Extensions in the base doc. 

Regards,
Stan

> -----Original Message-----
> From: manet [mailto:[email-masked]] On Behalf Of RJ Atkinson
> Sent: Wednesday, June 24, 2015 3:52 PM
> To: [email-masked]
> Subject: [manet] DLEP-14: Credit Windowing (Section 9)
> 
> 
> Hi,
> 
>   First, I am a big fan of the Credit Windowing mechanism currently specified
> as “optional” in Section 9.
> 
>   I think it would be helpful if that were pulled out of the DLEP base
> specification and into a separate I-D, with every intention that both drafts
> would progress together.
> 
>   Doing so would make DLEP-15 just the mandatory items and mandatory
> capabilities, but would retain the Credit-Windowing capability in its own
> focused, smaller, document with an explicit requirement that anything
> claiming to implement this separate Credit-Windowing document MUST do
> the whole Credit-Windowing capability as per that RFC-to-be.
> 
>   This separation approach also would make it simpler (more clear) whether a
> particular DLEP-capable product supported that Credit-Windowing capability.
> If a user wanted that capability, they could say that they want a widget that
> not only implements RFC-DLEP-Base-Spec but also implements RFC-DLEP-
> Credit-Windowing.
>   The other benefit is that the DLEP base specification would be shorter so
> that someone first coming up to speed on basic DLEP could do so more
> quickly.
> 
> Thanks,
> 
> Ran
> 
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 25 Jun 2015 09:22:22 -0400

> On 25  Jun 2015, at 09:10 , Ratliff, Stanley <[email-masked]> wrote:
> 
> The option of splitting the Credit Extensions out into a separate document was thoroughly discussed, both on-list, and in the DLEP design team. The DT closed work at IETF 89 (London), reaching consensus on this and other issues.

Stan,

- Design Teams do not get to make decisions for WGs.
- Design Teams propose items to a WG for WG review.
- So the Design Team discussion above is a bit of a Red Herring,
  from an IETF process perspective.

Further, in-person meetings are SECONDARY to on-list discussion.
For example, any potential consensus item in an in-person meeting
needs to be confirmed via the WG mailing list.

> The consensus was to leave the Credit Windowing descriptions
> in the "core" document. No contrary opinions were expressed on-list,
> until now. 

Maybe so.  Now there are other opinions, so we should have the
discussion again.  I provided concrete reasoning in my proposal, 
which reasoning no one has disagreed with in any technical terms.

Note that in any case, I very much want the Credit-Windowing
capability to move forward in parallel with the DLEP base spec.

> So at this point, with the spec having already cleared WGLC,
> we're going to leave Credit Extensions in the base doc. 

  We either can discuss it again now here or we can discuss it 
again in future during IETF Last Call.  

  From an IETF process perspective, the DLEP-14 document very clearly 
needs a revision — and that revision will need another WG Last Call 
regardless of this issue.

  It will reduce time to RFC if we have that discussion here and now.

Cheers,

Ran

---

From: John Dowdell <[email-masked]>
Date: Thu, 25 Jun 2015 14:57:24 +0100

Ran,

I've only been at IETF meetings for a few years, and was a member of the 
design team for DLEP. Your comments are noted, but I've never actually 
seen a working group take a decision in the way that a business project 
team would. In practice, working group members either seem to care or 
not, and if they care they usually seem to post regularly on the topic, 
or are invited to become part of a design or author team.

The design team in this case was a group of individuals who had all 
regularly posted to the list on this topic for a good two years prior to 
the formation of the DT. Despite asking frequently, both on-list and 
off-list, including radio manufacturers and system integrators that I 
would occasionally meet, few other opinions were ever expressed on-list. 
Many members of the design team have implementations, which yielded 
valuable experience in what worked and what didn't, and this went back 
into the draft. We're now four and a half years since draft-00. I know 
there are major organisations waiting for DLEP to get finished so they 
can inform their own strategies and development cycles, and for that 
they need a stable and implementable specification that those of us who 
have a stake in this protocol can agree on.

I don't for a second dispute your right to make suggestions or propose 
text or provide review based on implementation experience with this or a 
similar protocol, but those who do care about this draft have lived and 
breathed it for at least the four and a half years it has already 
existed. I would just ask you to consider your comments in the light of 
this situation.

John

---

From: Justin Dean <[email-masked]>
Date: Thu, 25 Jun 2015 10:42:16 -0400

I'm going to +1 for keeping it as one draft.  I see merit in breaking it up
into two (and that may still happen) but I also see the value in having it
within a single draft.  It allows reading DLEP for the first time to see
how to go about writing an extension without having to know about another
draft RFC.  We did something similar for SMF and it worked well there too.
Unless there is further comments on list supporting breaking the document
up I don't think rough WG consensus has changed on this issue just become
more rough.

Others please comment one way or another as the editor team is working hard
to rev the document and assuming consensus isn't nearly as good as knowing.

Justin Dean

On Thu, Jun 25, 2015 at 9:57 AM, John Dowdell <[email-masked]>
wrote:

>>> The option of splitting the Credit Extensions out into a separate
>>> document was thoroughly discussed, both on-list, and in the DLEP design
>>> team. The DT closed work at IETF 89 (London), reaching consensus on this
>>> and other issues.
>>>
>> Stan,
>>
> design team for DLEP. Your comments are noted, but I've never actually seen
> a working group take a decision in the way that a business project team
> would. In practice, working group members either seem to care or not, and
> if they care they usually seem to post regularly on the topic, or are
> invited to become part of a design or author team.
>
> off-list, including radio manufacturers and system integrators that I would
> occasionally meet, few other opinions were ever expressed on-list. Many
> members of the design team have implementations, which yielded valuable
> experience in what worked and what didn't, and this went back into the
> draft. We're now four and a half years since draft-00. I know there are
> major organisations waiting for DLEP to get finished so they can inform
> their own strategies and development cycles, and for that they need a
> stable and implementable specification that those of us who have a stake in
> this protocol can agree on.
>
> breathed it for at least the four and a half years it has already existed.
> I would just ask you to consider your comments in the light of this
> situation.
>
> John
>
>

---

From: "MATTY, Steven" <[email-masked]>
Date: Thu, 25 Jun 2015 14:56:12 +0000

+1 from me, whilst not presently having any interest in credit windowing, it does serve as a good example on DLEP extensions and at this late day I really don’t want to delay DLEP’s onward march through standards track.

From: manet [mailto:[email-masked]] On Behalf Of Justin Dean
Sent: Thursday, June 25, 2015 3:42 PM
To: John Dowdell
Cc: [email-masked]
Subject: Re: [manet] DLEP-14: Credit Windowing (Section 9)

I'm going to +1 for keeping it as one draft.  I see merit in breaking it up into two (and that may still happen) but I also see the value in having it within a single draft.  It allows reading DLEP for the first time to see how to go about writing an extension without having to know about another draft RFC.  We did something similar for SMF and it worked well there too.  Unless there is further comments on list supporting breaking the document up I don't think rough WG consensus has changed on this issue just become more rough.

Others please comment one way or another as the editor team is working hard to rev the document and assuming consensus isn't nearly as good as knowing.
Justin Dean

This email (including any attachments) may contain confidential
and/or privileged information or information otherwise protected
from disclosure. If you are not the intended recipient, please
notify the sender immediately, do not copy this message or any
attachments and do not use it for any purpose or disclose its
content to any person, but delete this message and any attachments
from your system. Airbus Defence and Space Limited disclaims any and all liability if this email transmission was virus corrupted,
altered or falsified.
-o-
Airbus Defence and Space Limited, Registered in England and Wales No. 2449259
Registered Office:
Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England

---

From: Lou Berger <[email-masked]>
Date: Thu, 25 Jun 2015 11:07:20 -0400

> So at this point, with the spec having already cleared WGLC, we're going to leave Credit Extensions in the base doc. 

Stan,
    A couple of points on the extension:

1) Per my review IMO the current definition of the extension is
insufficient to ensure interoperable implementations -- I think this can
readily be fixed by including parallel descriptions and mechanisms from
RFC5578 -- but it will take time to get this done.

2) Optional functionality in a base spec is generally not a great idea
from the process / IETF standards perspective.  In particular, if a user
specifies/requires, or a vendor claims conformance with, an RFC, there
is no way to know if the perfectly conformant implementations will
interoperate / support the optional functionality. 

I think both points, particularly the second, support separating out the
credit extension.  From a WG process standpoint I don't see this as
anyway a reset or back step.  I've seen (and as chair even initiated)
late stage document splits/merges multiple times and it isn't a big deal.

Lou

---

From: Rick Taylor <[email-masked]>
Date: Thu, 25 Jun 2015 15:11:05 +0000

This is a +1 for one draft from me.

It was always intended to stay in the draft as a 'worked example' of an 
extension.

Also, I have enough typing to do already ;)

Rick

On 25/06/15 15:56, MATTY, Steven wrote:
> +1 from me, whilst not presently having any interest in credit
> windowing, it does serve as a good example on DLEP extensions and at
> this late day I really don’t want to delay DLEP’s onward march through
> standards track.
>
> *From:*manet [mailto:[email-masked]] *On Behalf Of *Justin Dean
> *Sent:* Thursday, June 25, 2015 3:42 PM
> *To:* John Dowdell
> *Cc:* [email-masked]
> *Subject:* Re: [manet] DLEP-14: Credit Windowing (Section 9)
>
> I'm going to +1 for keeping it as one draft.  I see merit in breaking it
> up into two (and that may still happen) but I also see the value in
> having it within a single draft.  It allows reading DLEP for the first
> time to see how to go about writing an extension without having to know
> about another draft RFC.  We did something similar for SMF and it worked
> well there too.  Unless there is further comments on list supporting
> breaking the document up I don't think rough WG consensus has changed on
> this issue just become more rough.
>
> Others please comment one way or another as the editor team is working
> hard to rev the document and assuming consensus isn't nearly as good as
> knowing.
>
> Justin Dean
>

---

From: John Dowdell <[email-masked]>
Date: Thu, 25 Jun 2015 16:14:39 +0100

+1 from me too.

On 25/06/15 15:56, MATTY, Steven wrote:
> I'm going to +1 for keeping it as one draft.  I see merit in breaking 
> it up into two (and that may still happen) but I also see the value in 
> time to see how to go about writing an extension without having to 
> know about another draft RFC.  We did something similar for SMF and it 
> worked well there too.  Unless there is further comments on list 
> supporting breaking the document up I don't think rough WG consensus 
> has changed on this issue just become more rough.
>
> hard to rev the document and assuming consensus isn't nearly as good 
> as knowing.
>
>

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Thu, 25 Jun 2015 15:28:02 +0000

I think the credit windowing extension needs significant work.  I have
looked briefly at implementing it and I felt like I had to do a lot of
guesswork/assumptions to make sense of it.  I'm concerned that fixing this
will delay the main DLEP draft.  So, I'm in favor of splitting them.

David

From:  Justin Dean <[email-masked]>
Date:  Thursday, June 25, 2015 at 10:42 AM
To:  John Dowdell <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  Re: [manet] DLEP-14: Credit Windowing (Section 9)

I'm going to +1 for keeping it as one draft.  I see merit in breaking it up
into two (and that may still happen) but I also see the value in having it
within a single draft.  It allows reading DLEP for the first time to see how
to go about writing an extension without having to know about another draft
RFC.  We did something similar for SMF and it worked well there too.  Unless
there is further comments on list supporting breaking the document up I
don't think rough WG consensus has changed on this issue just become more
rough.  

Justin Dean

On Thu, Jun 25, 2015 at 9:57 AM, John Dowdell <[email-masked]>
wrote:
>>> The option of splitting the Credit Extensions out into a separate document
>>> was thoroughly discussed, both on-list, and in the DLEP design team. The DT
>>> closed work at IETF 89 (London), reaching consensus on this and other
>>> issues.
>> Stan,
>> 
> design team for DLEP. Your comments are noted, but I've never actually seen a
> working group take a decision in the way that a business project team would.
> In practice, working group members either seem to care or not, and if they
> care they usually seem to post regularly on the topic, or are invited to
> become part of a design or author team.
> 
> The design team in this case was a group of individuals who had all regularly
> posted to the list on this topic for a good two years prior to the formation
> of the DT. Despite asking frequently, both on-list and off-list, including
> radio manufacturers and system integrators that I would occasionally meet, few
> other opinions were ever expressed on-list. Many members of the design team
> have implementations, which yielded valuable experience in what worked and
> what didn't, and this went back into the draft. We're now four and a half
> years since draft-00. I know there are major organisations waiting for DLEP to
> get finished so they can inform their own strategies and development cycles,
> and for that they need a stable and implementable specification that those of
> us who have a stake in this protocol can agree on.
> 
> I don't for a second dispute your right to make suggestions or propose text or
> provide review based on implementation experience with this or a similar
> protocol, but those who do care about this draft have lived and breathed it
> for at least the four and a half years it has already existed. I would just
> ask you to consider your comments in the light of this situation.
> 
> John
> 
>