Drafts
directories.
This draft is a work item of the Network Modeling WG of the IETF.
Title : Handling Long Lines in Inclusions in
Internet-Drafts and RFCs
Authors : Kent Watsen
Adrian Farrel
Qin Wu
Fi
Hi,
Since you indicated that you thought your draft was ready for adoption
by the working group, I have done a quick review. I realise that this
is work in progress and does not need to be perfect or even complete
at this stage, so I have tried to just pick out some points to tidy up
the document
Thanks Dan.
Deborah, good to go.
Adrian
-Original Message-
From: Pce On Behalf Of dan...@olddog.co.uk
Sent: 17 June 2019 23:03
To: pce@ietf.org
Subject: Re: [Pce] I-D Action: draft-ietf-pce-stateful-hpce-10.txt
Hi All,
This revision of the I-D adjusts the number of document authors,
the fold is a space
(' ') character. If no such location can be found, then exit
(this text content cannot be folded)
Best,
Adrian
From: Kent Watsen
Sent: 17 June 2019 19:53
To: Adrian Farrel
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-artwork
internet-dra...@ietf.org> wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Network Modeling WG of the IETF.
Title : Handling Long Lines in Inclusions in
Internet-Drafts and RFCs
Author
Hi,
Picking up on Dhruv's request, I did a quick review as co-chair. It's
after the end of WG last call, but life is full of little
disappointments.
Enjoy!
Adrian
===
Please reduce to five or fewer authors on the front page or provide the
shepherd with a good reason why not.
---
Please
Adrian Farrel has requested publication of draft-ietf-pce-stateful-hpce-09 as
Informational on behalf of the PCE working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-hpce/
___
Pce mailing list
Thanks, Dan,
I'm checking the diffs and then I'll do the shepherd write-up and move the
document along.
Best,
Adrian
-Original Message-
From: Daniel King On Behalf Of dan...@olddog.co.uk
Sent: 10 June 2019 13:21
To: adr...@olddog.co.uk
Cc: pce@ietf.org
Subject: RE: [Pce] Review of
Very happy to have more comments and help to clarify our text.
At this stage the authors believe they have addressed all comments received
during working group last call and from the shepherd’s review. But (of course)
any review that points up a problem or suggests a clarification is a good
Adrian Farrel has requested publication of
draft-ietf-pce-stateful-pce-auto-bandwidth-09 as Proposed Standard on behalf of
the PCE working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-auto-bandwidth
All,
Obviously we have cut some slack for the documents that are further
advanced.
But a number of you have asked that your drafts be considered for WG last
call, and a few are in the queue (see the lists on the wiki at
https://trac.ietf.org/trac/pce/). If you are hoping that your document will
Hi,
I saw only one comment on this document in IETF last call.
Stephen Farrell's SecDir review
(https://datatracker.ietf.org/doc/review-ietf-pce-inter-area-as-applicabilit
y-07-secdir-lc-farrell-2019-05-29/) asks a question which might or might not
be a nit.
> I'm not sure if this is a nit or
Hi,
In Prague we had a discussion of draft-ietf-pce-enhanced-errors.
My recollection is that we decided that there was no great hurry to push
this document to completion, but that we didn't want to abandon it.
Checking back with the minutes, there was an objective that we encourage
authors of
Hi Stephane,
Thanks again for the thoroughness of your review and the time it has taken to
herd the necessary cats.
* BGP ERROR HANDLING:
I don’t see the “error handling” behavior associated with this attribute
(discard, treat-as-withdraw…)
>>>
>>> I think the errors are covered by
On Behalf Of Adrian Farrel
Sent: Thursday, May 23, 2019 4:48 AM
To: 'Rajesh M' ; 'Loa Andersson'
Cc: 'SPRING WG' ; i...@ietf.org
Subject: Re: [spring] draft-ali-6man-spring-srv6-oam-00
Hi all,
I don't think that a loose statement of recommendation is quite enough.
Trivially, the IPv6 header
Hi all,
I don't think that a loose statement of recommendation is quite enough.
Trivially, the IPv6 header must come first and the upper layer header must come
last.
I think that although the inclusion of the two destination options headers is
optional, their positions are quite tightly
Hi,
Thanks, Dan, for your response here.
Just to follow up on one point:
>> 2. In section 3.2.1 or section 4.1 if the originator sends PCC or PCE
>> sends an open with P flag =0 can the response open be sent with a
>> P flag =1 and if yes what should be the action of the originator. I
>> did
Hi,
Thanks, Dan, for your response here.
Just to follow up on one point:
>> 2. In section 3.2.1 or section 4.1 if the originator sends PCC or PCE
>> sends an open with P flag =0 can the response open be sent with a
>> P flag =1 and if yes what should be the action of the originator. I
>> did
Thanks Lou,
[speaking as an author]
This draft represents the coming together of two different approaches to the
same problem. The authors worked hard to merge and reach consensus, and the
current revision contains the product.
This document certainly addresses my personal requirement which is
Hi,
Noting that the draft (and hence the draft alias) has my email address correct.
No, I'm not aware of any IPR that applies to this draft.
Thanks,
Adrian
-Original Message-
From: Lou Berger
Sent: 12 May 2019 22:18
To: Kent Watsen ; adr...@olddog.co.uk;
bill...@huawei.com;
Robert,
Coincidence is a mighty thing, but attributing coincidence to planning is the
slippery slope you spoke of.
Drawing conclusions about an “overall strategy” that I might be part of is
potentially offensive. Should I be offended?
Let’s just do the work and stop second guessing
Robert,
Coincidence is a mighty thing, but attributing coincidence to planning is the
slippery slope you spoke of.
Drawing conclusions about an “overall strategy” that I might be part of is
potentially offensive. Should I be offended?
Let’s just do the work and stop second guessing
Hey Robert,
Thanks for your response, but I think you are not taking my requests at face
value.
> I think you are on a very slippery slope here :) Hope you are
> double diamond skier !
As it happens. But perhaps that is not wholly relevant.
> With point you are making here you
Hi chairs,
I hate to sound like a broken record. I just want to get this issue
clarified before we get to a late stage and risk being forced to start
again.
RFC 8200 defers to RFC 4291 for the definition of an IPv6 address. RFC 4291
has a somewhat simplistic and possibly historic
Well, since it's Upload Friday, I posted the new revision, but let me know if
you think more changes are needed.
Adrian
-Original Message-
From: BESS On Behalf Of Adrian Farrel
Sent: 24 April 2019 18:38
To: stephane.litkow...@orange.com;
draft-ietf-bess-nsh-bgp-control-pl...@ietf.org
stem. This section seems to
be relevant to the question you are asking.
But this second section seems to have it all covered by modelling exactly the
flowspec function used in BGP flow specification and adding an extended
community for SFC.
So, I think nothing else is needed for this issue.
Thanks,
Hello authors,
Sorry about the clunk as this draft shifted between shepherd.
I have some fairly minor review comments (below). Could you please address
these in a new revision.
Meanwhile, I will start on the shepherd write-up ready to move ahead as
quickly as possible.
Thanks,
Adrian
---
Odd
Hi Vijay,
The thing about central computation is that you can use any algorithm you like.
You could use a CSPF modification of Dijkstra. You could use AI. You could do
modified random walk.
Unlike a distributed computation that needs to be consistent across the network
to avoid looping,
Hi WG,
We currently have a working group last call on
draft-ietf-pce-association-diversity that will expire on 4/30.
During this last call we received notification of an IPR disclosure. You can
find this at https://datatracker.ietf.org/ipr/3493/
As part of the last call, the chairs request
ow
MPLS packets run over, then an unwanted IP packet may send to this tunnel-end
IP/UDP, and the router can't filter the packet by MPLS label stack (is there
MPLS ACL?).
Thanks
Jingrong
-Original Message-
From: Adrian Farrel [mailto:adr...@olddog.co.uk]
Sent: Monday, April 15, 201
-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Adrian Farrel
Sent: Monday, April 15, 2019 9:05 PM
To: bruno.decra...@orange.com
Cc: lsr@ietf.org
Subject: Re: [Lsr] Status of draft-ietf-isis-encapsulation-cap
Nice response, Bruno.
Thanks.
Adrian
-Original Message-
From: b
Thanks Xiaohu,
That at least indicates that you would like to see an RFC published.
But I wonder whether the WG has given up on this work? Two years is a long time
to make no advances and to have no demands for publication.
I wonder why no one has cared in the interim.
Best,
Adrian
As a general response, Ben, I would say that PCEP is only catching up with
GMPLS in this document. Thus, everything it is doing wrt bandwidth has been
built for some while in GMPLS RSVP-TE implementations.
It is probable that more careful references to the GMPLS signalling RFCs would
address
Hi Martin,
It was a general policy during the development of PCEP to make space for flags
in the various objects, and this has turned out to be useful in some cases.
So, I think the authors were continuing that approach.
But I agree, if you make the field, you should make the registry.
Thanks,
So far you have all been very quiet.
Thanks,
Adrian
-Original Message-
From: Pce On Behalf Of Adrian Farrel
Sent: 13 March 2019 22:01
To: pce@ietf.org
Subject: [Pce] Working Group last call on draft-ietf-pce-stateful-hpce-06
Hi working group,
This email starts a working group last
Hi,
Good afternoon. My name is Adrian and I'll be your Document Shepherd for
this journey.
As this draft is progressing through working group last call, I thought I
would do my review now and save a little time later.
These comments may seem a little negative, but I hope you can address them
Thanks for this poll, Bruno,
Before taking up work on this draft, would it be worth working with 6man to
check that the repurposing of IPv6 addresses would be unlikely to cause a
great fight? It would probably be better to not have two WGs fighting.
And, in case someone is confused by my
Hi Tianran, working group,
Tl;dr -- I support adoption
I read Juergen's very substantive comments, and I probably need to go back
and re-read them. Juergen is a beacon for how IETF participants should
contribute constructively and in detail.
His detailed comments and suggestions for improvement
Hi working group,
This email starts a working group last call for
draft-ietf-pce-stateful-hpce-06.
I would like to hear messages of support or concern about this draft.
If you support its progression towards publication as an RFC, please let us
know that you have read the latest revision, and
Hi authors,
In preparation for Working Group last call on this draft, I'd like all
authors and contributors to confirm on the list that they are in compliance
with IETF IPR rules.
Please respond (copying the mailing list) to say one of:
I am not aware of any IPR applicable to this draft that
Thanks David,
Subject experts we have. Your review of readability etc. was most welcome.
Adrian
-Original Message-
From: David Schinazi via Datatracker
Sent: 12 March 2019 22:20
To: gen-...@ietf.org
Cc: pce@ietf.org; i...@ietf.org; draft-ietf-pce-stateful-pce-p2mp@ietf.org
Adrian Farrel has requested publication of draft-ietf-pce-applicability-actn-10
as Informational on behalf of the PCE working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-pce-applicability-actn/
___
Pce
Hi Young,
This looks good to me.
Hope the WG can provide some more input, especially from implementers.
Best,
Adrian
-Original Message-
From: Leeyoung
Sent: 11 March 2019 23:57
To: adr...@olddog.co.uk; pce@ietf.org
Cc: draft-lee-pce-flexible-g...@ietf.org
Subject: RE: Chair review of
Thanks Cheng,
(and thanks for answering the question "why do you want to be on the
agenda?")
We'll be building the agenda next week and will get back to you.
Adrian (for the chairs)
-Original Message-
From: Chengli (Cheng Li)
Sent: 08 March 2019 09:21
To: pce@ietf.org
Cc:
nded
recipient(s) is prohibited. If you receive this e-mail in error, please
notify the sender by
phone or email immediately and delete it!
> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Adrian Farrel
> Sent: 25 February 2019 18:24
> To: pce@ie
Thanks again Stephane,
I think we have closure on most (but not all) of your points. I'll post another
revision now because it makes the incremental changes easier to process. But we
can have another go round if any of the unresolved issues merit it.
One thing to push back on from before was
Hi authors,
I see you posted -02 and so I have given it a quick review. I spent my time
on the early sections because those are the ones that introduce the ideas to
the new reader.
Feel free to discuss, although the changes are basically editorial.
Best,
Adrian
===
Abstract
OLD
This
>> Now that IETF has officially moved to XML as the sole format
>
> I'm not sure what you mean, can you provide a pointer? AFAICT,
> the latest published RFC is still only available as txt and pdf.
>
> If the only format was XML, why bother with any line breaking at all?
I think maybe the IETF
>> The days of scraping from plain-text RFCs are over [1]. Extracting,
>> if needed at all, should be from the XML, where there are no such
>> issues. Extracting from the plain-text output makes about as much
>> sense as extracting from the HTML or PDF outputs.
>
> I am confused. Are you saying
an a less intuitive solution
> with more noise that works for 100% of the cases.
>
>
>
>
>
> /martin
>
>
>
>
>
>
>
> >
>
> > If we want to have control of layout and be able to strip extra
>
> > whitespace then my argument
Hi,
As this document is being polled for adoption, I thought it might be
useful to do a review.
My comments are not blocking for adoption, but can be addressed in a
version if/when the draft becomes a WG document.
Thanks for the work.
Adrian
===
Abstract
No need to write "Segment Routing
Hello Stephane,
Thanks for this review. It is very thorough and has helped improve the document.
We have posted an update to the draft, and there are responses to your review,
below.
Thanks,
Adrian
> The document is globally well written with good examples that help the
> understanding.
>
\
\9012345
…and…
The quick brown fox\
\ jumps over the lazy dog
So, my point is, if and only if we do not care about these “spaces on the fold”
cases, we can operate with a single slash.
Cheers,
Adrian
From: Joel Jaeggli
Sent: 27 February 2019 06:31
To: Adrian Farrel
Cc
Hey.
I've been having this discussion with Kent off-line, but thought it should
come to the list.
I don't think it is a good idea to have two approaches. While it would be
relatively easy to code for both approaches, it seems to add a degree of
confusion if both have to be handled by the
Bruno, all,
I didn't pay much attention to this work when it first came out, but looking
more closely now, I think there is a useful function described here.
Obviously there is some polish needed, but that's OK at this stage in the
process and doesn't stop adoption.
I support the WG picking
This draft has been around the block a bit, but certainly needs to progress
because a lot of other things are dependent on it.
Fortunately after plenty of review and updates (thanks to the authors), I
think it is now ready to become an RFC.
Adrian
-Original Message-
From: spring On
is available from the on-line Internet-Drafts
directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.
Title : Gateway Auto-Discovery and Route Advertisement for
Segment Routing Enabled Domain Interconnection
Authors : Adrian Farrel
from the on-line Internet-Drafts
directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.
Title : BGP Control Plane for NSH SFC
Authors : Adrian Farrel
John Drake
Eric Rosen
.
Brgds,
-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Adrian Farrel
Sent: Monday, February 25, 2019 18:39
To: bess@ietf.org
Subject: Re: [bess] I-D Action: draft-ietf-bess-nsh-bgp-control-plane-06.txt
All,
Thanks for the comments we received during WG last call
Enabled ServiceS WG of the IETF.
Title : BGP Control Plane for NSH SFC
Authors : Adrian Farrel
John Drake
Eric Rosen
Jim Uttaro
Luay Jalil
Filename
that this draft
really should be advanced.
Thanks,
Adrian
-Original Message-
From: Pce On Behalf Of Adrian Farrel
Sent: 08 February 2019 11:34
To: pce@ietf.org
Subject: [Pce] WG Last Call on draft-ietf-pce-applicability-actn
Hi WG,
draft-ietf-pce-applicability-actn seems to be ready
Hello,
Speedy reply from you: thanks.
> Thanks for your shepherd/LC review of this draft. Here's our comment
> (inline under YL>>).
>
> Diff file is also provided for your verifications of all the changes between
> v.8 and v.9.
OK. But (obviously?) please wait until the end of last call as
That's a good review, Robert, thank you.
The changes look achievable to me, and I'm sure the author team can work to
include them.
Cheers,
Adrian
--
Want to buy a signed copy of a book of fairy stories for adults of all ages?
Send me an email and I'll bring one to Prague for you.
"Tales from
Hi,
Thanks for some really good feedback on this draft. It is very helpful to
the chairs when you explain clearly why you hold an opinion.
There is good support for this work, it is in charter, and it looks like a
reasonable number of people will help work on the draft.
So, let's adopt it.
Hi,
As this document is being polled for adoption, I thought I should review
it. There are a considerable number of nits, but nothing that prevents
adoption in my view. In the event that this document is adopted, I
think the authors would do well to address the changes shortly
afterwards. If
Nice review, thanks Andy.
Adrian
From: Andrew G. Malis
Sent: 18 February 2019 21:04
To:
Cc: rtg-...@ietf.org; draft-ietf-pce-stateful-pce-p2mp@ietf.org;
pce@ietf.org
Subject: RtgDir review: draft-ietf-pce-stateful-pce-p2mp-10.txt
Hello,
I have been selected as the Routing
Adrian Farrel has requested publication of draft-ietf-pce-stateful-pce-p2mp-09
as Proposed Standard on behalf of the PCE working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-p2mp/
___
Pce
Looks good to me.
Thanks!
I'll wait to see -09 posted.
A
-Original Message-
From: Dhruv Dhody
Sent: 07 February 2019 04:25
To: adr...@olddog.co.uk; draft-ietf-pce-stateful-pce-p...@ietf.org
Cc: pce@ietf.org; 'Dhruv Dhody'
Subject: RE: [Pce] Shepherd review of
Hi,
As we take this document through WG last call, it would be helpful if you
could confirm the situation with regard to IPR that might apply to the
draft.
I see that none has so far been disclosed.
Could you answer:
"No, I am not aware of any IPR applicable to this draft"
Or
"Yes, I am
Hi WG,
draft-ietf-pce-applicability-actn seems to be ready to progress towards
publication.
This email starts a two week working group last call (ends on 23rd
February).
During this time, please read the draft and make comments for improvement.
If you then support its publication please let us
Thanks Dan/co-authors,
This revision addressed my concerns.
I told Dhruv, and he seems to have pushed the draft forward.
Cheers,
Adrian
-Original Message-
From: Pce On Behalf Of dan...@olddog.co.uk
Sent: 06 February 2019 18:40
To: pce@ietf.org
Subject: [Pce] Updates RE: I-D Action:
> All editorial comments are accepted and updated in the working
> copy. Please let me know if there is any issue.
All good.
>> 6.1
>>
>> The following bit of RBNF echoes something we did in the base stateful
>> draft and which has caused confusion / errata to be raised because it
>> looks
Hi WG,
Please read and review draft-lee-pce-flexible-grid-03 and send your comments
to the mailing list.
Should we adopt it? Why / why not?
What needs to be fixed before/after adoption?
Is this a draft you would be willing to work on? Do you plan to implement?
This poll will run until 20th
Authors, Contributors, WG,
As part of preparation for WG Adoption:
Are you aware of any IPR that applies to drafts identified above?
Please state either:
"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"
If so, has this IPR been
Hi,
I have picked up this document as Shepherd and I have done a "final"
review before the document is passed on to the AD with a publication
request. Jon had started work on this, and I have folded in his
comments.
Pretty much everything we have here is editorial in nature, but there
are quite
Hi,
We had rather limited response to the poll for adoption of this draft.
Although no one objected, the voices in favour were not enough to convince
us that the WG cares about this work.
Possibly this fell into a hole at Christmas. Possibly folk were put off by
the draft having expired.
Hi,
As you know, Dhruv was the WG secretary for PCE (and a very good job he did
of it, too).
With his elevation to co-chair, we're looking for a new secretary, and we'd
love to hear from some volunteers. You can email direct to the chairs at
pce-cha...@ietf.org
The position doesn't take up a
Hi Stephane,
I am not aware of any IPR that has not already been disclosed against this
document.
Thanks,
Adrian
From: BESS On Behalf Of
stephane.litkow...@orange.com
Sent: 21 January 2019 13:06
To: bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] WGLC, IPR and implementation
Hey Wim,
Thanks for (not ) reading.
Yes, MPLS-SFC was certainly in mind, but we wrote the initial document only for
NSH, and so the document is named for that and fully scoped for that.
I believe that draft-ietf-mpls-sfc-encapsulation is “only” an interface
encapsulation of NSH.
Stephane,
Thanks for bringing this back for another last call.
I think that the approach documented in this document is a fine solution for
a somewhat limited SFC deployment. It has the benefits of using existing
techniques and tools, and satisfies the need for a quick deployment solution
-Drafts
directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.
Title : BGP Control Plane for NSH SFC
Authors : Adrian Farrel
John Drake
Eric Rosen
Jim Uttaro
lable from your favourite online bookseller.
Or contact me to receive a signed copy by mail.
-Original Message-
From: Satya Mohanty (satyamoh)
Sent: 14 December 2018 23:17
To: Rabadan, Jorge (Nokia - US/Mountain View) ; Adrian
Farrel ; rtg-...@ietf.org;
draft-ietf-bess-evpn-df-election
All,
I read the draft this morning and have no objections, per se. There is
obviously a lot of editorial work to be done, but that is fine and normal at
this stage.
The main challenge I found was determining exactly what the purpose of the
extensions was. I would welcome a clearer statement up
Hi Chairs,
I'm trying to think of ways that the WG participants can get a bet view of
what process work is pending and when to expect it.
At each IETF meeting you present a useful slide showing the "WG documents at
or near last call"
For example, at IETF 103 you showed
, Adrian Farrel wrote:
> Hi Bruno,
>
>> Speaking as an individual contributor and co-author:
>> - I think that this is fine to make a difference between an inconsistency
> from
>>a (one) faulty sender, and an inconsistency from two correct senders but
> with
>
)
Sent: 07 December 2018 17:12
To: Adrian Farrel ; rtg-...@ietf.org
Cc: draft-ietf-bess-evpn-df-election-framework@ietf.org; i...@ietf.org;
bess@ietf.org
Subject: Re: Rtgdir last call review of
draft-ietf-bess-evpn-df-election-framework-06
Hi Adrian,
Thank you very much for your detailed
Reviewer: Adrian Farrel
Review result: Has Nits
Hello,
I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request
Brilliant! Thanks, Dhruv.
I think we are down to two points.
>> 3.1.1. is a lot better, thanks.
>>
>> You have...
>>The inclusion of this TLV in an OPEN object indicates that the H-PCE
>>extensions are supported by the PCEP speaker. The child PCE MUST
>>include this TLV and set the
ales from North Wales brought to you for Christmas
https://www.feedaread.com/profiles/8604/
Available from your favourite online bookseller.
Or contact me to receive a signed copy by mail.
From: Adrian Farrel [mailto:adr...@olddog.co.uk]
Sent: Thursday, December 06, 2018 12:35 PM
To: 'Ahmed Bashandy
Hi Dhruv, Authors,
Thanks for -06 and -07 addressing comments, and -08 fixing the ToC.
I have just been through the diffs comparing against my review comments. You
seem to addressed most of my concerns, but not quite all of them. You also
introduced a couple of new issues
Thanks for the
I think that for "bandwidth calendaring" we might reference 8413.
I *think* "on-demand engineering" is simply the converse. That is, traffic
engineering / path computation at the time of request for service delivery.
That is "what we have always done" and might not qualify for a specific
protect against bugs otherwise the document is
contradicting itself
Thanks again for the thorough review
Ahmed
On 12/3/18 2:28 PM, Adrian Farrel wrote:
Hi all,
Thanks to the authors for the multiple revisions since -17. I reviewed the
Diff.
All of my review comments along the way seem to hav
While I'm on a roll reviewing PCE documents, and while Young is being
active, I just had a look at his new revision on this draft.
Glad that it is alive again because we seem to have a number of documents
that relate to it.
Only a few comments, but I think tidying these gets us close to "done".
Hi all,
It seems like draft-ietf-pce-applicability-actn is probably approaching
ready to go forward, so I did a review. The document looks to be in pretty
good shape: I found a list of nits (below), but with these fixed I think the
draft would be ready for last call.
Thanks,
Adrian
--
Hi all,
Thanks to the authors for the multiple revisions since -17. I reviewed the
Diff.
All of my review comments along the way seem to have been addressed and I
support moving to publication (soon).
One thing, in Section 2.5.
An implementation MUST NOT allow the MCCs belonging
Hi Haomian,
Thanks for continuing to move this work forward.
As I said back in October, I think the topic is in scope for the working group.
I have read this recent version of the draft and think it is ready for adoption.
Although the previous adoption poll did not have a lot of support, no
Thanks!
Was a useful Discuss, and good to be moving the cluster forward.
Adrian
> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Eric Rescorla
> Sent: 08 November 2018 04:28
> To: The IESG
> Cc: netmod-cha...@ietf.org; netmod@ietf.org; joe...@gmail.com;
Last item on the agenda...
Multicast Within SR-MPLS A Comparative ReviewIan 20 15:30
A
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: 06 November 2018 07:26
To: Stig Venaas; spring@ietf.org
Cc: Zafar Ali (zali)
Subject: Re: [spring] Multicast
v Lhotka wrote:
> > On Tue, 2018-10-23 at 16:27 +0200, Martin Bjorklund wrote:
> > > Ladislav Lhotka wrote:
> > > > On Tue, 2018-10-23 at 14:45 +0100, Adrian Farrel wrote:
> > > > > Hi,
> > > > >
> > > > > 1. I think you m
Hi,
1. I think you miss the point. While example XML/JSON YANG is included in
drafts, and while the authors are allowed to produce those drafts as txt files,
or while the authors want to achieve pretty-to-read formatting, this work falls
into the scope of those authors.
2. Yes, the authors
401 - 500 of 1373 matches
Mail list logo
