Hi Joel and all,
This is great initiative indeed. and I support it
I am talking from customer (and implementer) perspective: this information
could save a lot of time, because currently I have to find such details myself
during the interop testing.It is clear what vendors are worried that such info
could be used as a tool in marketing games as Adrian already said, but it can
be played in such way if only first implementations will be captured at the
time of publication (like I am king of the hill because I was first). Thus
some other form (such as wiki lin IDR WG, as Ketan mentioned) should exist and
updates about implementations can be put there. It might be easier than
updating RFCs while less formal.
Anyway the transparent and honest mechanism to track down the status of
implementations after publication is needed. Items 2 and 3 (reporting about
MUSTs and optional details) will give enough information.
The amount of information and details (what is implemented exactly, i.e. some
TLVs now are from private range because IANA did not allocate yet the numbers)
for a customer are more important at the moment than waiting for all MUSTs
will be implemented.
SY,Boris
On Monday, August 22, 2022, 05:00:45 AM GMT+3, Chengli (Cheng Li)
<c.l=40huawei....@dmarc.ietf.org> wrote:
Agree with Adrian and Robert, that is also my understanding of implementation
status section in a draft.
Copy from Adrian’s first email.
- I support the idea of capturing the implementations status of the SPRING work
during its development and at the time of publication request.
- I 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,
Cheng
From: spring [mailto:spring-boun...@ietf.org]On Behalf Of Robert Raszuk
Sent: Saturday, August 20, 2022 11:54 PM
To: Adrian Farrel <adr...@olddog.co.uk>
Cc: SPRING WG List <spring@ietf.org>
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 to an IETF wiki page.
Not actual list of vendors and features supported. That would be highly
inaccurate the moment it is posted.
Many thx,
Robert
On Sat, Aug 20, 2022 at 1:58 PM Adrian Farrel <adr...@olddog.co.uk> wrote:
Hi Joel,
Thanks for bringing this to the WG for discussion.
As one of the authors of RFC 7942 I want to comment on the idea of including
this “snapshot” status at the time of publication within the published RFC. I
think this changes the purpose of collecting the information and making it
public. It moves from being information that is valuable for assessing the
status of the work, to something that verges on a marketing statement. In
particular, companies that are able to get into the RFC reporting their
implementations will, forever, be named in the RFC as known implementations,
while other companies (perhaps those who waited for consensus before
implementing) will be excluded. This seems wrong, and while the text you
propose to include might make it clear that it is just a snapshot at the time
of publication, it will still be there as a public record. The IETF is not a
proxy marketing machine, and this information is not useful for the technical
content of the RFC.
When we wrote 7942, we thought about this quite a lot. That led us to include:
Authors are requested to add a note to the RFC Editor at the top of
this section, advising the Editor to remove the entire section before
publication, as well as the reference to RFC 7942.
But, at the same time, we described other places this information could be
stored and updated, if that is what the working group wants to do.
Personally, I don’t think it is the IETF’s job to record implementation status
after publication of an RFC, as this becomes very loaded and commercially
sensitive. It could be hard to police, and could become contentious.
So, in summary:
- I support the idea of capturing the implementations status of the SPRING work
during its development and at the time of publication request.
- I 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 <spring-boun...@ietf.org>On Behalf Of Joel Halpern
Sent: 03 August 2022 15:45
To: SPRING WG List <spring@ietf.org>
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 known interoperability tests that have occurred.
If the WG agrees, we would like to institute and post on the WG wiki the
following policy. The period for discussion and comment runs until
9-Sept-2022, to allow for folks who are on summer break:
All I-Ds that reach WG last call shall have an implementation section based on,
but somewhat more than, that described in RFC 7942 (BCP 205, Improving
Awareness of Running Code: The Implementation Status Section). Authors are
asked to collect information about implementations and include what they can
find out when that information is available for public disclosure. Documents
will not be blocked from publication if the authors fill in the section as
"none report" when they have made an effort to get information and not been
able to.
There are a couple of important additions to what is called for in RFC 7942.
We have confirmed with leadership that these changes are acceptable in terms of
IETF process:
1) We will retain the implementation status section when the draft is published
as an RFC. In order to do so, the section will begin with "this is the
implementation status as reported to the document editors as of <date>"
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.
3) each implementation description may include reports of what optional
elements of the draft / RFC are implemented.
Reports of interoperabiity testing are strongly encouraged. Including the
reports in the document is preferred. This may include a reference to longer
and more detailed testing reports available elsewhere. If there are no reports
of interoperability tests, then the section MUST state that no such reports
were received.
Yours,
Bruno, Jim, and Joel
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
