Thanks Harald
> - Some speling erors were noted, but I didn't have time to write them
down.
Nice ;-)
We'll work on polishing the document.
Now, something I have never understood is at what point in the process we
should respin the draft. So we let is complete IESG review, or do we
respin as soo
> Adrian, are you holding the edit token on the document? In that case, if
I
> get around to writing up the speling misteak I found, should I just send
> that to you?
I'm a good place to send it.
JP will do the edits, btu I am the gatekeeper.
A
___
Ge
Hi Harald,
Thanks for your comments on this I-D.
> (Impressively long authors' section!)
>
> This is not an unreasonable document. However, I cannot recommend
> that it be published as-is.
>
> The chief reason is that it does not properly define its target mission.
> For a document that is a requ
Hi Harald,
Thanks for your detailed review. Seisho and I have been through the
comments in fine detail (with Seisho doing the work as editor, and me
supplying English language text suggestions).
Most of your suggestions are fine and we have been able to make edits
which we'll publish as soon as w
Thanks Russ!
> Minor Concerns:
>
> In section 3, there is a discussion that includes ODU0, ODU2e, and ODU4,
> but these terms are not defined in the paragraph or in the terminology
> section. I realize that these are ODUj values, but ODUflex is an ODUj,
> and it is included in the terminology se
Hello,
You said...
> Actually, my problem was that the terminology section talks about LO ODUj
while
> Section 3 just uses ODUj. Does this mean LO ODUj, HO ODUj, or either one? Can
> you clarify?
The document has tried to be careful to use ODUj when describing LO and ODUk
when talking about HO.
Thanks,
I added an RFC editor note.
Adrian
> From: Mike Shand
> Sent: 18 December 2013 14:24:51 (UTC) Dublin, Edinburgh, Lisbon, London
> To: Les Ginsberg (ginsberg); Romascanu, Dan (Dan); gen-art@ietf.org
> Cc: draft-ietf-isis-rfc1142-to-historic@tools.ietf.org
> Subject: Re: Gen-ART review
Thanks David,
Stored for future updates.
Adrian
> -Original Message-
> From: Black, David [mailto:david.bl...@emc.com]
> Sent: 30 December 2013 02:46
> To: General Area Review Team (gen-art@ietf.org); attila.tak...@ericsson.com;
> donald.fe...@alcatel-lucent.com; he...@huawei.com
> Cc: B
Hi Russ,
Thanks for the review.
> Question:
>
> Should this document be an update to the MPLS-TP Framework (RFC 5921)?
> I am not sure. RFC 5921 does make it clear that it covers only point-
> to-point transport paths. The answer may be further complicated by
> the fact that RFC 5921 is joint
Hi Roni,
Thanks for taking the time.
> Minor issues:
> 1. In section 3.2 (a): I noticed that the policy to update the registry
according
> to section 5 is standard action so it should be the same here since this is
an
> update to the registry.
Hmmm, but I don't think so.
Section 5 (and the exi
Sut mae, Elwyn-gwas,
[snip]
> Politics! OK - How about we add to either s9.1.1 or s9.2 something like:
I don't think it is politics at all, and I don't really like that Huub
referenced this as IETF and ITU-T since both documents are IETF standards track
work.
There are some people who want to d
Thanks Robert,
I also noted some of these process concerns as shepherding AD, but took over the
document half way through IETF last call. I am currently in discussion with the
authors about the best way forward.
Cheers,
Adrian
From: ietf [mailto:ietf-boun...@ietf.org] On Behalf Of Robert Spar
Hi Elwyn,
Thanks for your pursuit of excellence.
I understand from the document editor that there is a revision in waiting to be
posted that clears up some remaining nits from your review.
However, in line...
> Summary:
> Almost ready. There are a couple of points which I raised at Last Call
>
Hi Elwyn,
> > I understand from the document editor that there is a revision in waiting to
be
> > posted that clears up some remaining nits from your review.
> I haven't seen this as yet, nor the psc-updates new version.
PSC-updates just posted (got stuck in a tools snafu).
Update to this I-D is
Hi Brian,
> Minor issues:
> -
>
> The document is scoped for MPLS substrates, but I see very little in it that
> requires MPLS. Archtecturally, it is quite general. Was there any
> consideration of making it applicable to a non-MPLS substrate?
>
> > 3.4.7. Scalability
> >
> > The
Thanks for your time, Roni.
Adrian
From: ietf [mailto:ietf-boun...@ietf.org] On Behalf Of Roni Even
Sent: 03 April 2014 11:48
To: draft-ietf-mpls-lsp-ping-ttl-tlv@tools.ietf.org
Cc: gen-art@ietf.org; i...@ietf.org
Subject: Gen-ART LC review of draft-ietf-mpls-lsp-ping-ttl-tlv-07
I am the
Thanks Robert,
Will be interested to hear author/shepherd responses to this.
Adrian
> -Original Message-
> From: L2vpn [mailto:l2vpn-boun...@ietf.org] On Behalf Of Robert Sparks
> Sent: 07 April 2014 20:41
> To: General Area Review Team;
draft-ietf-l2vpn-vpls-ldp-mac-...@tools.ietf.org;
Hi David,
Thanks for the review.
To pick out one of your points:
> This MIB contains many writable objects, so the authors should
> take note of the IESG statement on writable MIB modules:
>
> http://www.ietf.org/iesg/statement/writable-mib-module.html
>
> I did not see this mentioned in
Hi Christer,
Thanks for your efforts.
> Editorial nits:
>
> Section 1 (Introduction):
>-
>
> Q_1:
>
> s/two MIB modules/two Management Information Base (MIB) modules
Note that "MIB" is found as "well known" at
http://www.rfc-editor.org/rfc-style-guide/abbrev
Ben,
Thanks for the time and effort.
Adrian
> -Original Message-
> From: ietf [mailto:ietf-boun...@ietf.org] On Behalf Of Ben Campbell
> Sent: 27 August 2014 22:25
> To: Haleplidis Evangelos
> Cc: draft-ietf-forces-model-extension@tools.ietf.org; gen-art@ietf.org;
> i...@ietf.org
> S
Hi Martin,
I firmly believe that all reviews are good reviews, and thank you for the time
you have put into this.
You'll understand, of course, the squawking noise made by the authors who
received your review the day after the IESG discussed your document on the
telechat. In fact, the last Discus
Resend with Martin's correct email
> -Original Message-
> From: iesg [mailto:iesg-boun...@ietf.org] On Behalf Of Adrian Farrel
> Sent: 17 October 2014 12:05
> To: martin.thom...@andrew.com
> Cc: draft-ietf-l2vpn-evpn@tools.ietf.org; gen-art@ietf.org; i...@ie
> BTW, since these are just editorial changes, I will just give them to the
> RFC editor, unless you want me to check the new rev in.
Give them the edits and ask whether they'd like a new rev.
Thanks,
Adrian
___
Gen-art mailing list
Gen-art@ietf.org
All,
This document has completed IETF last call, but it seems to me that this
conversation may not be complete yet. Please continue it and try to reach
resolution.
The document is on the IESG telechat for 11/25 and I am confident that you will
reach some agreement (if only agreement to disagree)
Thanks Russ,
That looks reasonable and tractable.
Adrian
> -Original Message-
> From: ietf [mailto:ietf-boun...@ietf.org] On Behalf Of Russ Housley
> Sent: 09 November 2014 22:42
> To: IETF; ccamp-cha...@tools.ietf.org; draft-ietf-ccamp-rwa-
> info@tools.ietf.org
> Cc: General Area R
Thanks for the nits, Peter.
We'll be sure to look at them if the document is open again before being passed
to the RFC editor.
Adrian
> -Original Message-
> From: ietf [mailto:ietf-boun...@ietf.org] On Behalf Of Peter Yee
> Sent: 09 December 2014 08:09
> To: draft-ietf-l3vpn-end-system.
Hi, reading out of context...
"Sparse augmentation" is a term of art for MIB modules.
It means that the table rows are not augmented 1:1. Only those rows that are
wanted to be augmented, are augmented.
A
From: Elwyn Davies [mailto:elw...@folly.org.uk]
Sent: 14 December 2014 19:29
To: Sam Al
Thanks, Peter.
Adrian
> -Original Message-
> From: ietf [mailto:ietf-boun...@ietf.org] On Behalf Of Peter Yee
> Sent: 24 December 2014 20:18
> To: draft-ietf-pce-rfc7150bis@tools.ietf.org
> Cc: gen-art@ietf.org; i...@ietf.org
> Subject: Gen-ART LC review for draft-ietf-pce-rfc7150bis-0
Authors,
Fortunately Francis has not found any issues of substance.
Please fold these nits into the revision you are producing to address the IESG
Comments from last Thursday's telechat.
Thanks,
Adrian
>
> From: francis.dup...@fdupont.fron Behalf OfFranci
Thanks Joel.
Adrian
> -Original Message-
> From: Joel Halpern [mailto:j...@joelhalpern.com]
> Sent: 12 February 2015 23:38
> To: gen-art@ietf.org; maria.ines.rob...@ericsson.com; IETF discussion list
> Cc: Adrian Farrel; r...@ietf.org
> Subject: Re: [Gen-art] revie
Tom,
Thanks for the detailed review. Much appreciated. Late is better than not at
all, and one day is not the end of the world.
> Please resolve these comments along with any other Last Call comments
> you may receive.
Well, we'll handle the comments, of course, but we'll make a special trip to
Tom,
Thanks for the review
> Nits/editorial comments:
>
> The Ombudsteam is taken for granted from Section 2 onwards. It would be
> nice to mention in the Introduction that the IESG mentioned
> Ombudspersons in its statement of anti-harassment policy [1], but did
> not define the procedures
And thanks Meral for the review
And thanks Bruno for the response with which I agree.
Adrian
> -Original Message-
> From: Loa Andersson [mailto:l...@pi.nu]
> Sent: 05 March 2015 11:09
> To: bruno.decra...@orange.com; draft-ietf-mpls-lsp-ping-
> registry@tools.ietf.org; meral.shirazip.
@ietf.org; George Swallow; Vanson
> Lim; Sam Aldrin; mpls-cha...@ietf.org; Adrian Farrel
> Subject: Re: Last Call Review: draft-ietf-mpls-proxy-lsp-ping-03
>
> Thank you for your update (version -04).
>
> I cannot see any changes in the -04 version responding to my minor
>
Hi Peter,
This all looks good.
The changes are small, but it would be worth catching them in a new revision.
Please post it when you have it, no need to check with me.
Once you've done that, we'll hand it over to Alvaro as the incoming AD, and he
can put it on an IESG telechat.
Cheers,
Adrian
Forwarding on behalf of Alexey.
From: Alexey Melnikov [mailto:alexey.melni...@isode.com]
Sent: 10 May 2015 17:22
To: adr...@olddog.co.uk
Subject: Fwd: [Gen-art] Gen-ART telechat review of
draft-ietf-idr-ls-distribution-10
Hi Adrian,
I am having some problems with the tools.ietf.org alias expa
Hello David,
Responding as a contributing author who wants to see this work move forward
promptly...
Many thanks for taking the time to review.
> Minor issues:
>
> [1] 3.2.5 - the last bullet item is not completely clear to me. What
> does it mean for two slot compositions to be the same? Is
s for the response - this note contains the follow-ups on nits/editorial
items. All of these are nits or editorial, and hence I defer to the editors'
discretion on what (if anything) to do about them. The two suggestions for
text revisions in your response will definitely improve the draft,
Hi Robert,
Thanks for reading.
> Summary: Ready for publication as a Proposed Standard
Excellent diagnosis :-)
> One thing I'd like to check, and I suspect this pokes at a conversation
> that has already happened (as hinted in the acknowledgements section):
>
> The discussion of managements sy
Hi Daniele,
> Thanks for the careful review and your comments.
> I pretty much agree with Adrian's reply but I think explicitly having some
> backward compatibility text in the draft could be helpful.
>
> Adrian, authors, I'd suggest changing section 5 from "Manageability
> Considerations" to "Ba
his point.
Cheers,
Adrian
--
Read my latest...
Tales from the Wood - Eighteen new fairy tales
http://www.feedaread.com/books/Tales-from-the-Wood-9781786100924.aspx
http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924
Or buy from me direct.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Hi Joel,
Thanks for your time.
> The introduction describes RFC1264 as requiring at least one
> implementation. The general requirement in RFC 1264 is multiple
> implementations, at least two independent. While it is a minor issue,
> this document should characterize RFC 1264 more carefull
Hi Brian,
Thanks for the time.
> Major issues:
> -
>
> > 5. Building on Existing Protocols
>
> I find it hard to read the introduction to this section and understand
> why the draft is proposed for BCP rather than Informational.
I will punt this question direct to the responsible
I agree with Hannes on this.
However, if the document was to highlight strongly that the data is "a
non-routing related capability" (if that's what we believe!) and stress that the
information "that does not change frequently" (perhaps with some explanation of
"frequently") I believe that might he
Elwyn,
Thanks for the review.
> Summary:
> Almost ready. I found this a well-written and mostly readily comprehensible
> document although it contains a couple of instances of unexplained SDN/PCE
> jargon (notably 'southbound'). My main concern is that the archtecture
> suggests that extensions
Thanks Elwyn,
Clarified in the next revision.
Adrian
> -Original Message-
> From: Teas [mailto:teas-boun...@ietf.org] On Behalf Of Elwyn Davies
> Sent: 28 August 2017 20:24
> To: gen-art@ietf.org
> Cc: draft-ietf-teas-pce-central-control@ietf.org; i...@ietf.org;
t...@ietf.org
> Subje
nd changes look helpful.
Best wshes,
Elwyn
Sent from Samsung tablet.
Original message ----
From: Adrian Farrel
Date: 04/09/2017 10:47 (GMT+00:00)
To: 'Elwyn Davies' , gen-art@ietf.org
Cc: draft-ietf-teas-pce-central-control@ietf.org, i...@ietf.org,
t...@ietf.org
Thanks Robert,
> I don't have text to suggest, but please look at the first bullet of section
5.
> The explanation here was less helpful than the other bullets. Demonstrating
the
> confusion due to the reuse of the word "service" doesn't help clarify the
> confusion. I wonder if there's more conve
Top-posting 'cos I'm lazy.
We need to be careful to not confuse two aspects of security in this model.
One is security in the use of the model: who can read and write to the
operator, whether the data is protected in transit, etc.
The other is security within the VPN that is modelled: how sites s
Thanks for the time, Robert.
Adrian
> -Original Message-
> From: ietf [mailto:ietf-boun...@ietf.org] On Behalf Of Robert Sparks
> Sent: 26 January 2018 20:14
> To: gen-art@ietf.org
> Cc: draft-farrel-sfc-convent@ietf.org; i...@ietf.org; s...@ietf.org
> Subject: Genart last call review
Thanks Joel,
There's a lot to digest here. The chairs will work with the authors on a
response.
Adrian
> -Original Message-
> From: Joel Halpern [mailto:j...@joelhalpern.com]
> Sent: 25 February 2018 01:00
> To: gen-art@ietf.org
> Cc: l...@ietf.org; i...@ietf.org;
> draft-ietf-l2sm-l2v
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 the
Hey Robert,
Some detailed responses.
The revision will be posted when the authors have signed off.
Regards,
Adrian
> The 2nd sentence of the introduction is complex. It should
> be easy to simplify.
Done
> It would help to place the reference to draft-ietf-mpls-spring-entropy
> label at "If e
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-art@ietf.org
Cc: p...@ietf.org; i...@ietf.org; draft-ietf-pce-stateful-pce-p2mp@ietf.org
Subject
Thanks Harald,
> For background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html.
>
> Document: draft-ietf-ccamp-gmpls-ason-lexicography-06.txt
> Reviewer: Harald Tveit Alvestrand
> Date: Jan 14, 2006
> Trigger: IESG telechat submission for Informational
> Summary: R
jiri"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Kireeti Kompella"
<[EMAIL PROTECTED]>; "Adrian Farrel" <[EMAIL PROTECTED]>; "Alex Zinin"
<[EMAIL PROTECTED]>; "Bill Fenner" <[EMAIL PROTECTED]>
Sent: Monday, February
Forwarding to Lou's new email address.
Adrian
- Original Message -
From: <[EMAIL PROTECTED]>
To: ; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Wednesday, August 09, 2006 4:59 PM
Subject: Gen ART review of draft-ietf-
Model", RFC 4208, October 2005.
Thanks,
Adrian
- Original Message -
From: "Lou Berger" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Adrian Farrel" <[EMAIL PROTECTED]>; ; "Lou Berger"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTE
David: Thanks for your review. See in-line for responses.
MPLS WG: FYI
Ross/Bill: Please let me know if you would like a new revision at this stage
Thanks,
Adrian
- Original Message -
From: <[EMAIL PROTECTED]>
I am the assigned Gen-ART reviewer for
draft-ietf-mpls-p2mp-oam-reqs-0
Hi Eric,
(Note change in Cheng Yin's email)
(Added Deborah as CCAMP chair)
I am the Gen-ART assigned Last Call Reviewer for this
document.
Oh good, that'll keep us on our toes.
In section 1.1, you say:
"This document does not preclude a route exclusion from
listing arbitrary nodes or net
Good morning Spencer,
Thanks for the review.
Summary: This document is on the right track for publication as a BCP, but
some work is still needed.
Comments:
I have lots of questions, but most are requests for greater clarity - I
would not expect Brian to DISCUSS based on most of the questio
Suresh,
Many thanks for the review:
Substantial:
* General comment about backward compatibility
I think legacy transit nodes resetting the Call ID to zero on transmission
is a major issue that needs to be addressed more visibly in the draft.
Why? It is not common practice to in
Maybe someone could clarify the progress of the IS-IS RFCs from
Informational to Standards Track.
It seems to me that this operation has been progressing for the longest
time, and it is leaving everyone in a state of mild confusion about what
they should be doing.
For example, if it is the i
Francis,
Many thanks.
We'll hold on to these comment in case we need to respin. Otherwise, I will
check during Auth-48 that the RFC Editor has caught them all.
One note in line.
Cheers,
Adrian
Comments: there are only some editorial comments, i.e., things which
should
be handled by the RF
Hi Eric,
Many thanks.
Summary:
===
This document is not ready for publishing as a Proposed Standard.
Some points require clarifications.
Comments:
The following paragraph (section 2) seems inconsistent with the
text in subsequent sections: it seems that it is saying that any
com
If in doubt, expand acronyms.
But see also http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
Thanks,
Adrian
> Abstract:
>
> Please expand OSPF on first use.
>
> Section 1.3, first paragraph:
>
> Please expand OSPF on first use.
___
Ge
Thanks Gonzalo!
Cheers,
Adrian
- Original Message -
From: "Gonzalo Camarillo" <[EMAIL PROTECTED]>
To: "Gonzalo Camarillo" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "Magnus
Westerlund (KI/EAB)" <[EMAIL PROTECTED]>;
Sent: Thursday, May 15, 2008 12:09 PM
Subject: Re: Gen-art review of d
Hi Ben,
Thanks for the time and effort.
Responding as an author not as a WG chair...
Section 2.1, paragraph 3:
The last sentence is confusing. "...until the LSR that can process it."
does not seem to describe an event that one can wait "until". Should it
say "...until it reaches the LSR..
Hi Ben,
Oops, I messed up the Gen-ART review boilerplate. Please mentally insert
the following text at the top of my review:
I think we'll let you off just this once.
Document: draft-ietf-mpls-te-scaling-analysis-03
Reviewer: Ben Campbell
Review Date: 2008-11-25
IETF LC End Date: 2008-11-3
and these have been fixed. I see no other issues.
||Has the
||Document Shepherd personally reviewed this version of the
||document and, in particular, does he or she believe this
||version is ready for forwarding to the IESG for publication?
|
| Adrian Farrel i
Thanks Robert,
We're converging.
This is probably a naive question, but what happens if a PCC sets the
OF flag in a request, doesn't provide a OF object, and the OF object
in the response has a function code the client has never heard of
before? (If this is clear, where in the document suit
Sure. Whatever.
Actually I am completely baffled by this comment as the terminology section
in this I-D is Section 2. We are talking about the same I-D aren't we?
draft-ietf-ccamp-pc-and-sc-reqs-06.txt
All I see after the Abstract is a section with RFC 2119 language. Maybe this
should be ton
Thanks,
Minor issues: IMHO it is just a typo but in 4 page 9: DNS -> DoS
Yup.
Nits/editorial comments:
- 7.1 page 12: Singlaling -> Siglaling
Very good ;-)
- 8 page 13: J.-P -> Jean-Philippe
Cheers,
Adrian
___
Gen-art mailing list
Gen-art@ie
Hi Ben,
Thanks for your review.
Dimitri, need your help!
See in line below.
Adrian
Minor issues:
-- Section 9.1:
This section shows the sub-TLV types as TBD, but at least some of the
references sections specify type numbers.
OK, I found section 9.1
| ValueSub-TLV
Thanks David!
Comments:
I am concerned about Section 6.2's recommendation for MIB
extension work. Is the work to extend the MIB underway? How
important is that MIB extension to manageability (hence
usability in practice) of this protocol?
No, the work on MIB extensions has not been started.
Hi Ben,
New revision just out fixes the issues.
Thanks again.
Adrian
- Original Message -
From: "Ben Campbell"
To: "PAPADIMITRIOU Dimitri"
Cc: "Adrian Farrel" ; "General Area Review Team"
; ;
Sent: Tuesday, March 17, 2009 7:54 PM
Subje
Thanks Francis,
I'll catch these with an update after IETF last call completes
Adrian
- Original Message -
From: "Francis Dupont"
To:
Cc: ; ; ;
Sent: Friday, April 17, 2009 1:09 PM
Subject: review of draft-ietf-mpls-p2mp-te-mib-08.txt (full)
I have been selected as the General
Hi,
- Rule of 5 authors. The draft lists 6 authors, of which 2 of them are
listed as Editors. While this is not an impediment for its
publication, certainly it brakes the RFC Editor's rule of 5 authors.
I'm waiting for guidance from Loa and Adrian on this one.
I thought I sent this.
Documen
Thanks Sean,
Summary: This draft is basically ready for publication (informational
with no RFC 2119 requirements terminology), but has nits that should be
fixed before publication.
I ran it through ID-nits:
- is a pre-5378 disclaimer needed?
Will look at this, but I believe not.
- draft-iet
All,
I propose the following RFC Editor note...
Section 1
OLD
Although both static and dynamic configuration of MPLS-TP transport
paths (including Operations, Administration and Maintenance (OAM) and
protection capabilities) is required by this document, it MUST be
possible for operator
Francis,
Get a conformant dictionary :-)
Compliant has two meanings. The most used would describe a submissive
person.
Conformant has the same meaning as the other meaning of compliant.
Lou, were you proposing that a further change is made here?
Can you handle it in Auth48?
A
- Original
Thanks Francois,
Good to have your review.
Coming as it does, after both IETF last call and IESG review, we will try to
sort your comments by importance and pass them on as pointers to the RFC
Editor.
Cheers,
Adrian
- Original Message -
From: "Francis Dupont"
To:
Cc: ; ;
; ;
Hi Suresh,
Please resolve these comments along with any other Last Call comments
you may receive.
Well, we won't treat these as "any other Last Call comments" as they arrived
almost two months after the end of the last call period.
However, we do value your review and thank you for your com
Thanks Francis,
Summary: Ready
Good to know.
Nits/editorial comments:
- in 1 page 2: in theory you should expend the VPN abbrev (it is not
in http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
marked as well known even IMHO it should, so the "in theory")
Yup
- 2.1.4 page 3:
Hi Miguel,
I think IANA owns the MIB module.
You're right, we should chase IANA to make sure they understand what to do.
Lou, can you ping them?
A
- Original Message -
From: "Miguel A. Garcia"
To: ; ;
;
Cc: "General Area Review Team"
Sent: Thursday, February 04, 2010 8:08 AM
Subj
Hi Dimitri,
Looking at your response to David Black's review, I think an update to the
draft is needed. I'd like to get it onto an IESG agenda before Anaheim as it
has several Ethernet drafts backed up behind it.
Sections 5.1.4, 5.2.1 and 8 have me confused about the
Attributes Flags TLV:
-
Ah thanks, I had only checked the datatracker. I guess this will pop out on
Monday when the Secretariat get to work.
It seems to address the points.
Thanks.
Adrian
- Original Message -
From: "Lou Berger"
To: "Adrian Farrel"
Cc: "PAPADIMITRIOU Dimitri&q
elecom.com; 'gen-
a...@ietf.org'
Cc: Black, David; Lou Berger; Adrian Farrel; cc...@ietf.org
Subject: Gen-ART review of draft-ietf-ccamp-gmpls-mln-extensions-11
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http
Thanks Miguel!
Minor issues:
- I noticed that the draft, although it uses normative verbs, they are all
written in lower case. Additionally, there is no dependency to RFC 2119. I
guess this is done on purpose because the draft is Informational. Is this
the intention?
In the past the IETF h
Please resolve these comments along with any other Last Call comments you
may receive.
Will try, but it may be hard to reach resolution on some of them :-)
Major issues: None
Minor issues: None
Nits/editorial comments: None
Many thanks for taking the time to read and review.
Adrian
__
David,
Thanks for this.
Authors: please consider these comments as part of the IETF last call, and
come to resolution (possibly needing RFC Editor comments or a new revision).
Thanks,
Adrian
- Original Message -
From:
To: ; ;
; ;
Cc: ; ; ;
; ;
Sent: Thursday, August 26, 2010 6
Thanks David,
[snip]
The following 3 IANA-related nits still need attention:
- In Section 4.1, remove the note to IANA after 2) and instead
insert this instruction into Section 7.
This is already the first bullet point in Section 7.
The RFC Editor will spot "suggested value" in 4.1 and updat
...@att.com; John Mullooly (jmullool);
> tsch...@nlayer.net; George Swallow (swallow); Adrian Farrel; General Area
> Review Team
> Subject: RE: Gen-ART review of draft-ietf-mpls-ip-options-05.txt
>
>
> Hi Miguel,
>
> Many thanks for your review.
>
> Regarding your
Hi,
IETF last call completed without further comments.
Can I suggest
OLD
When a Group-to-RP mapping entry is created in the
pimGroupMappingTable in the PIM-STD MIB[RFC5060], it would be
acceptable to have an entry with an RP with address type 'unknown'
and a PimMode of Dense Mode or
Hi David,
Thanks for continuing to discuss.
> [A] I remain surprised that the forwarding table in each node is not
considered to
> be an attack target (i.e., asset to be protected).
What did you have in mind?
Do you believe someone with a wrench might break into the router and steal the
routing
Thanks Brian,
RFC Editor is just polling to add PIM to the list of well-known acronyms.
A
> -Original Message-
> From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
> Sent: 18 January 2011 01:24
> To: draft-ietf-pim-registry@tools.ietf.org; General Area Review Team
> Subject
Thanks for the review and these minor points.
Russ, I'm going to capture Ben's review in a Comment attached to my Yes ballot,
and the authors can come back and pick them up after the IESG review complete.
Cheers,
Adrian
> -Original Message-
> From: Ben Campbell [mailto:b...@nostrum.com]
Thanks Roni,
> Nits/editorial comments:
>
> 1. Need to expand LDP when first mentioned.
LDP is a recognised acronym at
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt and does not need
to be expanded.
Cheers,
Adrian
___
Gen-art mailing
LC review of draft-ietf-mpls-lsp-ping-enhanced-dsmap-09
>
> On 05/24/2011 03:15, Adrian Farrel wrote:
> > Thanks Roni,
> >
> >> > Nits/editorial comments:
> >> >
> >> > 1. Need to expand LDP when first mentioned.
> > LDP is a recognised
Hi Ben,
Thanks for reading.
> Nits/editorial comments:
>
> -- section 1, paragraph 4: "...with relation to the programming..."
>
> ... in relation to...
Yeah. RFC Editor note if Stewart is watching (although I'm guessing the RFC
Editor might just fix this anyway).
> -- 3.1, last paragraph:
>
1 - 100 of 130 matches
Mail list logo
