SPRING WG:
At the suggestion of our AD, the WG Chairs have been discussing whether
it would be helpful to be more explicit, in I-Ds and RFCs we produce,
about the announced implementations and known interoperability tests
that have occurred. If the WG agrees, we would like to institute and
p
Hi Joel,
One suggestion, apart from "none to report" it might be a good idea to also
have a "not applicable" option for the WG's informational and architectural
documents to clearly distinguish between the the case of no implementation
exist v/s applicable.
Thanks!
Dhruv
On Wed, Aug 3, 2022 at 8
Thank you Dhruv for reading and commenting on the policy. While I think
the implementation and interoperability section will apply to even most
informational documents, I am happy to allow the option of "does not
apply" to cover those cases when it truly doesn't.
Yours,
Joel
On 8/10/2022 6:
to help a useful discussion
Regards
-éric
From: spring on behalf of Joel Halpern
Date: Wednesday, 3 August 2022 at 16:56
To: SPRING WG List
Subject: [spring] Proposed policy on reporting implementation and
interoperability
SPRING WG:
At the suggestion of our AD, the WG Chairs have been
List
*Subject: *[spring] Proposed policy on reporting implementation and
interoperability
SPRING WG:
At the suggestion of our AD, the WG Chairs have been discussing
whether it would be helpful to be more explicit, in I-Ds and RFCs we
produce, about the announced implementations and
On Thu, Aug 11, 2022 at 3:58 PM Eric Vyncke (evyncke) wrote:
> Bruno, Jim, Joel,
>
>
>
> Without any hat, or only with the experience of reviewing so many I-Ds
> from different areas and having implemented a couple of proof-of-concept
> implementations of various IETF drafts.
>
>
>
> The followin
, "spring@ietf.org" ,
Alvaro Retana , Andrew Alston
Subject: Re: [spring] Proposed policy on reporting implementation and
interoperability
On Thu, Aug 11, 2022 at 3:58 PM Eric Vyncke (evyncke)
mailto:40cisco@dmarc.ietf.org>> wrote:
Bruno, Jim, Joel,
Without any hat, or o
prior to publication.
Thanks,
Acee
*From: *spring on behalf of Tony Przygienda
*Date: *Friday, August 12, 2022 at 11:05 AM
*To: *"Eric Vyncke (evyncke)"
*Cc: *John Scudder , "spring@ietf.org"
, Alvaro Retana , Andrew
Alston
*Subject: *Re: [spring] Proposed policy on repo
Hi Joel,
First thank you & AD for initiating this.
Two questions/comments below:
#1:
> 2) Each implementation description MUST include either a statement that
> all MUST clauses in the draft / RFC are implemented, or a statement as to
> which ones are not implemented.
>
How can you allow any i
With regard to point 1 about MUSTs and implementations, we chose this
because we recognize the reality that what people say is an
implementation of an RFC may not include all the MUST clauses. If we
were protocol police, that would be a problem. In this case, we would
rather know about partia
Joel,
On #1 IMHO implementations of all MUSTs is what is necessary
for interoperability. If something is not needed for base
protocol functionality it should not be MUST in the first place. After all,
aren't we about assuring interoperable implementations here ?
As to #2 - no need for separate we
With regard to item 1, reasonable people may differ. If the working
group wants to require that all implementations listed in the
implementation section MUST implement all MUSTs, then we could do that.
But unless we hear from more people, that is not our current expectation.
With regard to
optional) features that aren’t covered by the specification but could potentially improve it may be discussed in the report for community benefits. Cheers,Jeff From: Joel HalpernSent: Wednesday, August 3, 2022 7:45 AMTo: SPRING WG ListSubject: [spring] Proposed policy on reporting implementation and
rove it may be
> discussed in the report for community benefits.
>
>
>
> Cheers,
>
> Jeff
>
>
>
> *From: *Joel Halpern
> *Sent: *Wednesday, August 3, 2022 7:45 AM
> *To: *SPRING WG List
> *Subject: *[spring] Proposed policy on reporting implementation and
&g
munity benefits.
Cheers,
Jeff
*From: *Joel Halpern <mailto:j...@joelhalpern.com>
*Sent: *Wednesday, August 3, 2022 7:45 AM
*To: *SPRING WG List <mailto:spring@ietf.org>
*Subject: *[spring] Proposed policy on reporting implementation
and interoperabil
features that aren’t
>> covered by the specification but could potentially improve it may be
>> discussed in the report for community benefits.
>>
>>
>>
>> Cheers,
>>
>> Jeff
>>
>>
>>
>> *From: *Joel Halpern
>> *Sent: *Wednesday,
Hi Joel/All,
Can the policy clarify some of the following points which are not
explicitly covered in its currently proposed text?
a) Whether a single implementation is sufficient or if we require at least
2 *independent* (i.e., by different implementors) ones?
b) There are some MUSTs that are ass
Joel & Spring chairs
I think this is a great idea and I support the proposal.
As Ketan pointed out I think there should be consistency at least across
all the routing area WGs related to normative language especially MUSTs in
a specification.
I don’t think we can say that 90% or even 99% of the
Thank you for your comments. I would like to see more discussion of
your in line points by the working group. For your initial questions
my personal comments are in line.
Yours,
Joel
On 8/19/2022 12:28 AM, Ketan Talaulikar wrote:
Hi Joel/All,
Can the policy clarify some of the following
Joel,
> I would be interested in hearing from the WG on this. My expectations is
> that if someone says they implement optional feature X, and X has MUSTs
> conditioned on it, then they have to explain whether they comply with those
> MUSTs.
>
When I look at BCP-14 or RFC2119 I do not see any dis
While what you propose may be cleaner, what Ketan asked about is a
common practice. So it seems useful to recognize that reality.
Yours,
Joel
On 8/19/2022 10:58 AM, Robert Raszuk wrote:
Joel,
I would be interested in hearing from the WG on this. My
expectations is that if someone sa
Hi Joel,
Would you mind providing a few such examples of reality in the published
standard track RFCs coming via Routing Area ?
Many thx,
Robert
On Fri, Aug 19, 2022 at 5:23 PM Joel Halpern wrote:
> While what you propose may be cleaner, what Ketan asked about is a common
> practice. So it
Hi Robert,
Let us consider RFC8402 which has a whole bunch of MUST clauses. An
implementation may choose not to support IGP Anycast Segment. The spec does
not say that any of the Segments are mandatory for SR. However, there are
some MUST clauses to follow should implementation support it.
I hope
Thx Ketan.
Yes indeed but this is an architecture document ... In such type of
documents it is hard to imagine an implementation report. You implement
protocol specification not an architecture.
I was more curious how many protocol extension RFCs say from IDR or LSR WGs
have such "issue".
Thx,
R
Hi Robert,
Indeed, writing implementation reports for architecture documents (which is
what we mostly do in SPRING WG) is more challenging than protocol specs.
This was my point as well. For an operator, considering a solution
deployment, perhaps the implementation report for the protocol spec is
Hey Ketan,
Ok so take RFC8667 as example. Let's assume implementation of SID/Label
Binding TLV is optional (is it really :) ?
So yes it has few MUSTs there ... but those MUSTs apply to protocol
encoding in the context of this TLV. And no implementation can cherry pick
to implement some MUSTs in t
2022 15:45
To: SPRING WG List
Subject: [spring] Proposed policy on reporting implementation and
interoperability
SPRING WG:
At the suggestion of our AD, the WG Chairs have been discussing whether it
would be helpful to be more explicit, in I-Ds and RFCs we produce, about the
announced
am strongly opposed to retaining that information in published RFCs.
>
> - I support am neutral on idea of continuing to record implementation
> status after publication if there is WG consensus.
>
>
>
> Thanks,
>
> Adrian
>
>
>
> *From:* spring *On Behalf Of *Joel
, 2022 11:54 PM
To: Adrian Farrel
Cc: SPRING WG List
Subject: Re: [spring] Proposed policy on reporting implementation and
interoperability
Hi Adrian,
I 100% agree with you.
However what I understood as "Implementation Section" requirement was as simple
a one paragraph including URL
.
Thanks,
Cheng
From: spring [mailto:spring-boun...@ietf.org]On Behalf Of Robert Raszuk
Sent: Saturday, August 20, 2022 11:54 PM
To: Adrian Farrel
Cc: SPRING WG List
Subject: Re: [spring] Proposed policy on reporting implementation and
interoperability
Hi Adrian,
I 100% agree
er publication if there is WG consensus.
>
>
>
> Thanks,
>
> Adrian
>
>
>
> From: spring On Behalf Of Joel Halpern
> Sent: 03 August 2022 15:45
> To: SPRING WG List
> Subject: [spring] Proposed policy on reporting implementation and
> interoperabil
continuing to record implementation status
after publication if there is WG consensus.
Thanks,
Adrian
From: spring On Behalf Of Joel Halpern
Sent: 03 August 2022 15:45
To: SPRING WG List
Subject: [spring] Proposed policy on reporting implementation and
interoperability
SPRING WG:
At the
32 matches
Mail list logo
