ks!
>
> I can post a rev++ addressing all discussion thus far, and then an
> unchanged draft-ietf-opsawg-...-00
>
> Thanks!
>
> Carlos.
>
> On Wed, May 8, 2024 at 4:14 AM Adrian Farrel <mailto:adr...@olddog.co.uk>> wrote:
>
> Thanks Henk,
>
> Apologies for the
of an “Experimental
Use” range in the same registry.
So, I guess I retract my suggested changes.
Cheers,
Adrian
From: Adrian Farrel
Sent: 08 May 2024 09:07
To: 'Dhruv Dhody'
Cc: draft-ietf-pce-pcep...@ietf.org; pce@ietf.org
Subject: [Pce] Re: Changes for PCEP-LS IANA Considerations
Thanks Henk,
Apologies for the fatuous original name of this draft (but it worked to get
everyone's attention ;-)
- Yes, your suggested new name works for me.
- Since you ask, as one of the editors, I commit to a "pro-active alignment",
making changes as requested by the WG, and paying
nks!
Dhruv
On Mon, May 6, 2024 at 3:04 AM Adrian Farrel mailto:adr...@olddog.co.uk> > wrote:
Hi,
Thanks for posting the adopted draft.
I think we need to make the following changes so catch all of the IANA
issues associated with being Experimental.
Cheers,
Adrian
===
New sectio
Hi,
Thanks for posting the adopted draft.
I think we need to make the following changes so catch all of the IANA
issues associated with being Experimental.
Cheers,
Adrian
===
New section...
6.2. Experimental Error-Types and Error-Values
This experiment uses a single Experimental Use
Hello Henk,
No I'm not aware of any IPR the pertains to the content of this draft.
Adrian
-Original Message-
From: OPSAWG On Behalf Of Henk Birkholz
Sent: 02 May 2024 16:49
To: opsawg ;
draft-pignataro-opsawg-oam-whaaat-question-m...@ietf.org
Subject: [OPSAWG] IPR Call for
That sounds like a good point, Dhruv.
Cheers,
Adrian
From: OPSAWG On Behalf Of Dhruv Dhody
Sent: 01 May 2024 11:52
To: Henk Birkholz
Cc: OPSAWG
Subject: Re: [OPSAWG] WG Adoption Call for
draft-pignataro-opsawg-oam-whaaat-question-mark-03
Hi,
I support adoption.
Just one
Hi Henk,
It should come as no surprise that I would be happy to see this adopted.
I want to note that, as is always the case in the IETF, adoption would mean
that the working group can change every word of the document and even decide to
abandon the document. So Carlos and I are listening to
If any allocation had been made (early or otherwise), I'd see it here
https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
and here
https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml
right?
A
Thanks, Julien.
Once upon a time, I was quite skeptical about this idea, and unhappy to see it progress. But I have become used to the idea, and two things help me believe we should adopt this:
1. As an Experiment, this can be tried out and
Hi PCE,
After some discussions with Dhruv about how and why we wrote RFC 8356,
Haomian and I have posted a new draft to allow Experimental error codes in
PCEP.
In summary, 8356 created space for Experimental PCEP messages, objects,
TLVs.
The assumption (see Appendix A) was that you could do
Thanks, Ron, for showing some of your typical charity and moderation. I have
just been catching up on the SPRING list (a lot can happen in one day) and when
I got to Antione’s email I was upset enough to start write to the chairs to ask
them to bring some better behaviour back to the
Hi Tony,
Queue closed so a question on email.
First: I think this is good work. I don't know how we document this to
experiment with it. I suspect it needs some pretty sophisticated simulation
because the rate of deployment is going to be such that the operators will
not want to experiment in
tional protocol work to resolve any
issues using the procedures described in RFC 4775 and RFC 4929.
Kind regards,
Adrian Farrel, MPLS Working Group Co-Chair
(On behalf of the MPLS Working Group and Co-Chairs)
Joe Clarke, OPSAWG Co-Chair
(On behalf of the
chairs copying either mailing list. We do intend
moving fairly quickly on this, but will wait until after MPLS has met (IETF
Tuesday) before sending anything.
Cheers,
Adrian (for the MPLS WG chairs)
-Original Message-
From: mpls On Behalf Of Adrian Farrel
Sent: 08 March 2024 15:37
To: 'mpls
OK, there are some fun discussion points here.
CHAIRS: Note well, we have moved well beyond the original points in my
RTG-DIR review
In line and trying to focus.
[Linda2] Yes, need IANA registry. Reflected in -7
[AF3] OK. I see the registry. I think you still have work to do on it
Hi again,
Thanks for continuing to engage in this discussion.
This email is me getting out of the way of further progress of this draft.
Cheers,
Adrian
[snip]
[Linda2] Let me try again. How about the following write-up?
"To ensure security, enterprise traffic between their
Thanks, Linda.
I am now looking at the -06 version you posted.
I am doing some heavy snipping in this thread. Look for [AF2]
Adrian
[Linda] How about the following rearrangement of the Intro section?
Enterprises connecting to Cloud DC may find significant benefits in leveraging
Hi Linda,
Thank you for your careful consideration of my review.
In line…
Cheers,
Adrian
From: rtg-dir On Behalf Of Linda Dunbar
Sent: 16 February 2024 20:16
To: Yingzhen Qu ; Adrian Farrel
Cc: rtg-...@ietf.org; draft-dmk-rtgwg-multisegment-sdwan@ietf.org;
rtgwg@ietf.org
I am also as confused as Alex :-)
The OPSAWG charter says:
The Operations and Management Area receives occasional proposals for
the development and publication of RFCs dealing with operational and
management topics that are not in scope of an existing working group
The NMOP charter
Reviewer: Adrian Farrel
Review result: Has Issues
Hello,
draft-dmk-rtgwg-multisegment-sdwan-05.txt
I have been selected to do a routing directorate "early" review of this
draft.
The routing directorate will, on request from the working group chair,
perform an "early" revi
.
Linda
-Original Message-
From: Adrian Farrel mailto:adr...@olddog.co.uk> >
Sent: Saturday, February 3, 2024 3:54 PM
To: last-c...@ietf.org <mailto:last-c...@ietf.org>
Cc: andrew-i...@liquid.tech <mailto:andrew-i...@liquid.tech> ;
bess-cha...@ietf.org <mailto:bess-ch
the resolutions in two separate emails. This one addresses the
comments to Section 3.1.2. Will have another email addressing the remaining
comments.
Can you check if the resolutions to your comments inserted below are
acceptable?
Thank you,
Linda
-Original Message-
From: Adrian Farrel
Thanks a lot to Jeff for this comment.
The MPLS chairs have discussed this, and we are in agreement that this work
should be taken to BFD. BFD will then work out whether it needs to be taken as
a separate draft or folded into a revision of 5884.
Thanks to the authors for their work, and
Hi,
I read this document again as part of its second Last Call. I have a
few comments that should ideally be fixed before passing the draft on
to the RFC Editor. (I ran out of steam around Section 6, sorry.)
Thanks,
Adrian
===
I wondered about the implementation status of this document. One
.
Looking forward to a fruitful debate,
Nigel and Adrian
===
Internet-Draft draft-davis-nmop-incident-terminology-00.txt is now
available.
Title: Some Key Terms for Incident Management
Authors: Nigel Davis
Adrian Farrel
Name:draft-davis-nmop-incident
too generally, while others already have perfect definitions,
that will lead to something similar to this document to bring the good into the
light.
Further comments in line…
From: Greg Mirsky
Sent: 12 January 2024 00:09
To: Carlos Pignataro ; Adrian Farrel
Cc: Ops Area WG ; IETF IPPM
too generally, while others already have perfect definitions,
that will lead to something similar to this document to bring the good into the
light.
Further comments in line…
From: Greg Mirsky
Sent: 12 January 2024 00:09
To: Carlos Pignataro ; Adrian Farrel
Cc: Ops Area WG ; IETF IPPM
warded message -
From: Carlos Pignataro mailto:cpign...@gmail.com> >
Date: Fri, Jan 5, 2024 at 3:38 PM
Subject: New I-D -> Guidelines for Charactering "OAM"
To: Ops Area WG mailto:ops...@ietf.org> >, Adrian Farrel
mailto:adr...@olddog.co.uk> >
Hi, Ops Area WG,
Ever
then I think it is time to remove the section or add a note that the
>> issues have been resolved. If not, then we need a plan to resolve them!
>
> This text indeed seems outdated. We will work with the chairs to figure
> out what to do with it.
>
> The issues related
Hey SPRING,
Please be aware of this working group last call in MPLS. Review comments
greatly appreciated and should be sent to the MPLS list.
Last call ends 9th January at 9am GMT
Cheers,
Adrian
-Original Message-
From: mpls On Behalf Of Adrian Farrel
Sent: 18 December 2023 20:47
olutions presented in a single document?”) to show that you can mix compression flavours in the same SID list. That means that advertising both flavours of C-SID is both possible and acceptable. So you can’t gloss over answering what happens when both flavours are present: how do you choose?
I suppose that I don’t object to the definition of new abbreviations if people
are keen.
Personally, I don’t get the value of “inb-OAM” compared with “in-band OAM”.
It’s not like it can be said faster (one additional syllable to say it) and it
only saves four characters in typing.
[Adding the NMOP list - which is currently called NETMO]
It's a month later.
Nigel and I have been working on the first version of key terminology. We've
actually made some progress (perhaps slower than our initial enthusiasm
might have suggested).
We're just putting the last polish
Hey there,
So, it's over a year since Bruno asked this question, and eight months since
the current revision expired.
I don' see anything on the list, and there was no mention in the meeting at
IETF-118.
Can we have a status and plan, please?
It's OK if the authors have decided to
Hi again Francois,
Thanks for your patience while I got back from Prague.
I have looked through the diffs and respond in line below.
This is good work, and captures very nearly everything. I snipped out every
point of agreement.
Best,
Adrian
>> 0. Please get into the habit
Hi,
I've read the new version of this draft.
I think it is ready for publication, but you have used smart quotes for
the apostrophes in the Abstract and Introduction.
Thanks for all the work.
Adrian
-Original Message-
From: Pce On Behalf Of julien.meu...@orange.com
Sent: 09 November
Reviewer: Adrian Farrel
Review result: Not Ready
Hi,
I have been asked to provide a Routing Directorate review of this
document as it is prepared for working group last call.
This document provides a set of seven YANG modules that can be used for
configuring and monitoring aspects of QoS
So, my view is that CATS is specifically chartered to look at these metrics.
I think the metrics could equally be applied in ALTO (as I said at IETF-117
in the ALTO WG meeting).
I had hoped that we might hold an interim to discuss metrics, but progress
has been slow.
That said, the CATS list
Hi Jordi,
Thanks for the heads-up on this meeting. It will clearly be of interest to
the CATS working group although it is unclear from your brief summary of the
issue whether you intend exposure of information to "the application" (by
which I think you may mean the programs running on a host)
Hi Jordi,
Thanks for the heads-up on this meeting. It will clearly be of interest to
the CATS working group although it is unclear from your brief summary of the
issue whether you intend exposure of information to "the application" (by
which I think you may mean the programs running on a host)
Thanks Qin,
I checked against your proposed resolution of my review comments and I don't
see any issues.
Cheers,
Adrian
-Original Message-
From: netmod On Behalf Of Qin Wu
Sent: 23 October 2023 11:28
To: NETMOD Group
Subject: [netmod] RE I-D Action: draft-ietf-netmod-node-tags-11.txt
Hi,
I just saw draft-united-tvr-schedule-yang posted.
Please be aware that OPSAWG is working on YANG modules for scheduling as
well.
draft-ietf-opsawg-ucl-acl was just recently adopted, but the Wg has
determined that the scheduling aspects should be generalised and pulled out
into a separate
Thanks for asking, Joe.
Yes, I think that the WG should be working on ACs. Yes, I think that this
set of I-Ds form the basis for what needs to be covered.
I am *slightly* queasy about there being four documents. I'd be happier if
some consolidation were possible. But I have no concrete
As I said in my original comment, I'd like to see this separation. Various
recent conversations suggest that scheduling (services, resources, ACLs,
etc.) is becoming a Big Thing. Having a common model to facilitate this
would be really helpful.
QUESTION FOR THE CHAIRS
If this is split out,
, but the short answer is that
any of the authors have the right to grant rights on behalf of all the authors
because of the "joint" work nature.
Yours,
Joel
On 10/6/2023 9:19 AM, Adrian Farrel wrote:
Thanks, Joel.
That’s really helpful.
Pedantically, suppose there was
, and it is within the authors remit to
do so.
Yours,
Joel
On 10/6/2023 8:54 AM, Adrian Farrel wrote:
Hi Matthew,
I support this being a WG document.
IANAL. I don’t understand the process by which an author who previously said
“no derivative works” for an I-D is able to relax
Hi Matthew,
I support this being a WG document.
IANAL. I don't understand the process by which an author who previously said
"no derivative works" for an I-D is able to relax that constraint in a new
revision. Maybe simply posting a new revision without the constraint is
enough. Maybe the
Thanks Ran,
I’ll try to get to that soon.
Adrian
From: chen@zte.com.cn
Sent: 01 October 2023 18:42
To: d...@dhruvdhody.com; adr...@olddog.co.uk
Cc: pce@ietf.org; draft-chen-pce-b...@ietf.org
Subject: Re: [Pce] WG Adoption of draft-chen-pce-bier-11
Hi Dhruv，
Thanks for
Hi,
I have no objection to the working group taking on this draft although
I suspect that the community of interest is quite small, so there is
some concern about proper review and WG consensus. Hopefully this
adoption poll will secure a few promises of future review.
A few editorial
Hi,
This review is in answer to Joel's request on the mailing list. I come to
this document without a lot of history on SRH compression (although
I had some chats with Cheng Li, which helped me to not embarrass
myself with some of my more stupid questions) and I have deliberately
not read any of
Hi Lou,
Yes, it is totally appropriate that we revisit this guidance. A lot has been
learned in the five years since 8407 and the long list of updates already in
this draft show that there is work to be done.
Adopt and work.
Cheers,
Adrian
-Original Message-
From: netmod On Behalf Of
Hi Tianran,
I think this is a timely piece of work that should be adopted. I commit
to further reviews if it is adopted.
A few minor comments on this version, below. Nothing that needs to be
fixed before adoption.
There is a meta-question: should the schedule model be moved out into
Hey Joel,
I have not been following the SRv6 compression work closely, so I believe I
fill the criteria for the detailed review for clarity and implementability. I'd
be particularly interested in what issues (if any :-) are thrown up by the
effort of clarifying the text.
I can't look at the
Just dropping this into the email archive with no more intention than to
collect information in one place...
One of the inventors listed for the patent in this disclosure (Magnus
Westerlund) was on the IESG at the time that this document was evaluated for
publication and balloted "No Objection".
ome
explanation of whether it is specific to known implementations or more
generally applicable.
Cheers,
Adrian
From: Mr. Jaehoon Paul Jeong
Sent: 27 July 2023 06:05
To: Rifaat Shekh-Yusef ; Adrian Farrel
; Linda Dunbar
Cc: Independent Submissions Editor (Eliot Lear) ; Roman
Danyliw ; i2
which will need to start using the new values before shipping. Note
that there is a Private Use part of the registry available for early
implementation and prototyping.
Thanks,
Francois
On 26 Jul 2023 at 10:46:13, Adrian Farrel mailto:adr...@olddog.co.uk> > wrote:
Hi,
Yo
Hi,
You have an impressive Implementation Status section. Well done for
compiling this and keeping it up to date.
I note that a number of IANA assignments are marked as TBA while others have
been assigned from the First Come First Served part of the registry.
This leads me to two things:
1.
Please copy CCAMP into these discussions as the WG actively writing YANG models
for optical elements in the network.
Cheers,
Adrian
From: netmod On Behalf Of David Sinicrope
Sent: 24 July 2023 22:11
To: netmod@ietf.org
Cc: david.sinicr...@ericsson.com
Subject: [netmod] Broadband Forum
Thanks Reese,
Thanks for taking the time to read and comment.
All comments accepted and addressed except...
> Please consider redrawing the figures using SVG instead of ASCII.
> Especially Figure 4 would greatly benefit from this enhancement.
I think Figure is about as complex as they get, and
Thanks Behcet.
The "n.d." is an artefact of xml2rfc. I'll leave that for the RFC Editor to worry about.
We could add an abreviations section if anyone feels strongly (I don't, and I'm not looking for extra work :-)
Briefly in line with [AF2]
Tl;dr All is good.
Adrian
-Original Message-
From: Qin Wu
Sent: 05 July 2023 05:14
To: adr...@olddog.co.uk; 'Kent Watsen' ; netmod@ietf.org
Subject: RE: [netmod] WGLC on node-tags-09
Hi, Adrian:
-邮件原件-
发件人: Adrian Farrel [mailto:adr...@olddog.co.uk
Thanks Qin,
In line...
Adrian
== Discussion ==
Section 7.
I'm not completely comfortable with the way you use the base identity
node-tag-type to capture the variants defined in the IANA registry shown in
9.2. What happens when another document defines a new IETF tag type?
Is it necessary to
Thanks.
Looks like all my comments have been addressed.
Adrian
From: 程伟强
Sent: 27 June 2023 15:08
To: spring ; i-d-announce
Cc: Stewart Bryant ; Adrian Farrel
Subject: Re:[spring] I-D Action: draft-ietf-spring-mpls-path-segment-09.txt
Hi,
We just updated the draft
Hi,
That was a quick and thorough update, thanks!
I like this draft
Cheers,
Adrian
-Original Message-
From: I-D-Announce On Behalf Of
internet-dra...@ietf.org
Sent: 07 June 2023 11:44
To: i-d-annou...@ietf.org
Subject: I-D Action: draft-ma-opsawg-ucl-acl-03.txt
A New
Reviewer: Adrian Farrel
Review result: Has Issues
Hello
I have been selected to do a Routing Directorate early review of this draft..
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery. I
reviewed revision -07.
The Routing Directorate will, on request from the working group
Resending this cos somehow by autocomplete got mangled.
Adrian
-Original Message-
From: Adrian Farrel
Sent: 22 May 2023 09:59
To: 'ops...@ietf.com'
Cc: 'draft-ma-opsawg-ucl-...@ietf.org'
Subject: A review of draft-ma-opsawg-ucl-acl
Hi all,
I think that enhancing our ability
In the past, I would have agreed with Tom on this.
But we are routinely seeing a pause of more than 200 days between a WG issuing a Publication Request and the AD starting their review (which leads to updates and discussion before IETF last call). IANA don't do
Hi,
I looked at revision -07
This is a really big document and would probably benefit from a more
detailed review than I was able to give it. But it looks fine and ready to
progress to me.
A couple of nits.
Section 4.3 might usefully describe that this is an additional requirement.
Hi Jordi / all,
I reviewed this draft at revision -05 and had quite a pile of comments.
Looking at -08, I think all my comments were addressed.
My relatively quick read through of the current revision found no issues and
so I think the document is now ready to move forward.
Note that
Hi,
I have reviewed this draft during the normal working group process, and
I just re-read it as part of working group last call. I believe the
function defined is useful, and I think the draft is ready to advance
towards publication once my list of small points have been addressed.
Cheers,
Hi,
Just a quick comment in last call for this draft.
Would it be a good idea to also give some steer to future documents?
Something like "It is intended that all future OSPF documents use this
revised terminology even when they reference the RFCs updated by this
document."
That could go in
Hey Julian.
Yes, let's move this little draft forward quickly and ensure PCEP can be as
secure as possible.
A
-Original Message-
From: Pce On Behalf Of julien.meu...@orange.com
Sent: 27 March 2023 10:49
To: pce@ietf.org
Subject: [Pce] Adoption Poll for draft-dhody-pce-pceps-tls13-02
[Spring cc'ed because, well, you know, SR. I wonder whether 6man and 6ops
should care as well.]
tl;dr
I think this is a good initiative and worth discussion. Thanks
for the draft.
I am particularly reminded of two MPLS-related discussions:
- The first was the introduction of Ethertype
[Spring cc'ed because, well, you know, SR. I wonder whether 6man and 6ops
should care as well.]
tl;dr
I think this is a good initiative and worth discussion. Thanks
for the draft.
I am particularly reminded of two MPLS-related discussions:
- The first was the introduction of Ethertype
the CATS problems and where the gaps are. So
we would certainly welcome learning more about SAN and the use cases that the
authors hope to address.
Thanks,
Adrian
From: Cats On Behalf Of Adrian Farrel
Sent: 26 March 2023 05:57
To: 'Eric Vyncke (evyncke)' ; c...@ietf.org
Cc: int-area@ietf.org
Thanks Eric, that’s helpful.
The agenda slot is:
Tuesday, March 28, 2023
17:00-18:00 Tuesday Afternoon Session IV
The agenda item and related drafts are as shown below.
4. Service aware network (SAN) framework and data plane solutions - Daniel
Huang
Hi Richard,
This is a great resource. Thanks for the effort.
In view of the review of draft-ietf-alto-new-transport just in from Martin
Thomson, I wonder about adding a feature column for “TIPS” and maybe one for
“HTTP version”
A
From: alto On Behalf Of Y. Richard Yang
Sent: 23
> Many thanks for your comments, I have accepted most of the comments
> from you, and would like to discuss with you about the rest. Please see my
> reply inline.
Great. Thanks, Cheng. Continuing the discussion in line.
Snipped all of the resolved stuff.
> Because we have a lots of comments. It
Hi again, Dhruv.
Still not pushing this idea, but still trying to make sure it is correctly
understood….
Of course an (unpopular) option would be to tell the PCE WG that it is not
acceptable to use the RSVP-TE registries in this way, and let them know that
if they want to specify paths
Looks like I was somewhat right with “unpopular”
Of course an (unpopular) option would be to tell the PCE WG that it is not
acceptable to use the RSVP-TE registries in this way, and let them know that
if they want to specify paths for other uses they should use a new PCEP ERO
and RRO
Hi,
Here is my WG last call review of this document. Thanks to the authors
for all of the work that has gone in.
[A note for the chairs: Was this last call shared with SPRING?]
Cheers,
Adrian
===
Abstract
The Source Packet Routing in Networking (SPRING) architecture
In fact, although
Hi,
You may recall that, back in the early days, the plan for PCEP was that it
was used to determine the paths that were to be signalled in MPLS-TE and to
report on those paths.
To that end, the ERO and RRO in PCEP messages follow the same construction
as those used in RSVP-TE. That is, they are
Hey, Richard!
I see nothing wrong in what you describe here.
Actually, this is really good text and cut’n’paste may be your friend in terms
of adding clarity to your draft.
A
From: Y. Richard Yang
Sent: 20 February 2023 04:45
To: IETF ALTO ; Adrian Farrel ; Qin (Bill)
Wu
Subject: Re: [Can] Clean copy CAN charter updated
Just to close the loop, the charter (still below) that Adrian distributed
today looks good enough to me.
Yours,
Joel
On 2/12/2023 3:07 PM, Adrian Farrel wrote:
> Hi,
>
> Per the planned schedule, here is a -00-03.txt re
Hi,
Prompted by the new revision and Qin's email, I decided to have a look
at this latest version of draft-ietf-alto-new-transport.
Thanks to the authors for all the effort put in to add this important
functions to ALTO.
I hope these comments help.
Best,
Adrian
===
First thing to say is that
Hi,
Tl;dr I support the adoption of this draft.
As a co-author of RFC 8283, I take an interest in this work and the
wider applicability of PCECC. I've also been interested in how SID
allocation is coordinated, and this seems like a reasonable solution.
Given that we have procedures and
As promised, I’m commenting into this thread as well. Picking Dhruv’s email
from the thread because it best captures my feelings on the work.
As I noted in the review I just posted, there seem to be a few (small but
important) clarifications and changes to the previous specs that need to be
Hi,
This is another fly-by review as I just saw the new revision of the
draft pop up. I think it is important and helpful that implementers of
IETF protocol work get together to document their experiences with the
technology, so thanks to the authors for their work.
However, I am concerned when
I have a fly-by response to this which is to say that "service degraded" is not the same as "service down".
Consider a p2mp service where one leaf is suddenly not reachable. You might say that the contracted service is not being delivered, but it will often be
Hi all,
I reviewed this document a couple of times as it progressed through the
working group, and my comments were addressed.
Here is an additional, small point. In Section 2 you have:
When Path Segment is not allocated from the SRGB pool, the
intermediate nodes MUST not see the Path
Hi,
After the discussions at the interim in June and with the ADs at IETF-114,
we have kept a lowish profile within the IETF for our work on Semantic
Networking.
But we had a useful workshop at SigComm on the Future of Internet Routing
and Addressing, and that prompted us to not give up on our
Wfm, thnx
-Original Message-
From: Russ Housley
Sent: 14 October 2022 14:58
To: Adrian Farrel
Cc: draft-dhody-pce-pceps-tl...@ietf.org; pce@ietf.org
Subject: Re: Thinking about draft-dhody-pce-pceps-tls13
Maybe the phrase should be: PCEP implementations that support TLS 1.3 MUST
makes all the concerns go away.
Cheers,
Adrian
-Original Message-
From: Russ Housley
Sent: 14 October 2022 13:46
To: Adrian Farrel
Cc: draft-dhody-pce-pceps-tl...@ietf.org; pce@ietf.org
Subject: Re: Thinking about draft-dhody-pce-pceps-tls13
Adrian:
TLS 1.2 does not have
rial in RFCs.
If we put in text about not retaining it, people later who had not seen
the discussion would find that confusing.
Yours,
Joel
On 10/14/2022 6:27 AM, Adrian Farrel wrote:
> Hi Joel, chairs.
>
> Thanks for working on this.
>
> Can I ask, just for clarification
Hi Joel, chairs.
Thanks for working on this.
Can I ask, just for clarification, what the conclusion is on whether this
section is going to remain in the document when it becomes an RFC. I find the
text a little confusing because it talks about "an I-D [that] is ready for WG
last call", but
Hi,
Thanks for kicking off work to get PCEP able to work with TLS1.3.
This is important.
However... :-)
I think it would be helpful to clarify that statements about what
implementations must or must not do (etc.) should be scoped as
"implementations of this document." That is, you are not
Hi,
Discussion of this document seemed to fizzle out in August, and the last
email seems to be Qin saying "I'm happy to make no change if no change is
needed."
Where does that leave us with regards to the WG last call comments and the
discussion at IETF-114?
Thanks,
Adrian
Gredler
; JP Vasseur (jvasseur) ;
meral.shirazip...@polymtl.ca; Adrian Farrel
Subject: RE: [Lsr] Lars Eggert's Discuss on
draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)
John -
So you are suggesting that Section 4 of the draft be modified to say:
"This introdu
Gredler
; JP Vasseur (jvasseur) ;
meral.shirazip...@polymtl.ca; Adrian Farrel
Subject: RE: [Lsr] Lars Eggert's Discuss on
draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)
John -
So you are suggesting that Section 4 of the draft be modified to say:
"This introdu
1 - 100 of 1371 matches
Mail list logo
