Re: [Gen-art] Gen-ART LC review of draft-ietf-roll-routing-metrics-14
Thanks Roni. On Jan 16, 2011, at 2:07 PM, rontlv wrote: Hi JP, Thanks, I am OK with all your responses Roni From: JP Vasseur [mailto:j...@cisco.com] Sent: Friday, January 14, 2011 8:44 AM To: Roni Even Cc: gen-art@ietf.org; draft-ietf-roll-routing-metrics@tools.ietf.org; IETF-Discussion list Subject: Re: Gen-ART LC review of draft-ietf-roll-routing-metrics-14 Hi Roni, Thanks for your thorough review - please see in line JP On Dec 20, 2010, at 7:14 PM, Roni Even wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-roll-routing-metrics-14 Reviewer: Roni Even Review Date:2010–12–20 IETF LC End Date: 2011–1–5 IESG Telechat date: Summary: This draft is almost ready for publication as an Standard track RFC. Major issues: No Major issues Minor issues: 1. In section 2.1 after figure 1 you specify the different fields. Please specify the size in bits of the flags field the A-field and the prec field. JP Done. 2. In section 2.1 in example 1 how is it known that all nodes MUST be main powered. JP In this example, we first explain how the headers flags are determined. To help clarify I modified the text: OLD: As far as the constraint is concerned, if the constraint signalled in the DIO message is not satisfied, the advertising node is just not selected as a parent by the node that processes the DIO message. NEW: As far as the constraint is concerned, the object body will carry a node energy constraint object defined in Section 3.1 indicating that nodes must be mains-powered: if the constraint signalled in the DIO message is not satisfied, the advertising node is just not selected as a parent by the node that processes the DIO message. Do you need to provide a value to prec field? JP As indicated earlier, the Prec field is only useful when a DAG Metric Container contains several Routing Metric objects. In this example, there is just one metric (the node energy is a constraint). 3. In section 3.1 and throughout the document when you define the different object you have “recommended value=xx”. I think that since this draft defines the table and create the initial table in the IANA consideration section these are the actual values. So maybe say that these are the actual values as specified in section 6 (6.1) JP We added recommended values until IANA confirms. 4. In section 3.1 the flag field – how many bits, specify. JP Done. 5. In section 3.2 figure 4 shows a flag field, how many bits, what is the value. JP Done. 6. In section 6 according to rfc5226 “IETF consensus” is now “IETF review”. JP Fixed. 7. In section 6.1 you should say that the table has the initial values and add which numbers are available for allocation. JP Done. 8. In section 6.2 what values are available for allocation. Also say that currently the table is empty. JP Done. 9. In section 6.2 is there a reason to create an empty table. Why not do it when there is a request to define a TLV JP Just to have the registry already in place. There is more than likely be TLVs defined in a very near future. This also allows to make sure that all TLVs have the same structure. 10.In section 6.3, are there more values allowed, can they be allocated. If not why have it managed by IANA. JP The A field is a 3-bit field and there are currently 4 defined values. 11.After the table in section in section 6.3 there is a request to create another table. Maybe it should be in a separate section. JP This is just because we put all registries belonging to the Routing Metric/Constraint Common Header in the same section. 12.In section 6.3 “New bit numbers may be allocated”, how many bits are available. JP The text was misplaced, thanks. 13.The same paragraph in section 6.3 also talks about the registration policy, is it different from the one that is common in section 6, why specify it again. Also look at comment 6 JP This was a duplicate. Fixed. 14.Comment 12 and 13 are also true for section 6.4 and 6.5. JP Fixed too. Nits/editorial comments: 1. In section first paragraph “object” should be “object” 2. In section 4.3.2 first paragraph “wich” should be “which” JP Fixed. Many Thanks. These changes are all incorporated in revision 15. JP. ___ Ietf mailing list i...@ietf.org https://www.ietf.org/mailman/listinfo/ietf __ Information from ESET NOD32 Antivirus, version of virus signature database 5785 (20110113) __ The message was checked by ESET NOD32 Antivirus. http
Re: [Gen-art] review of draft-ietf-pce-monitoring-04.txt
Here you are, the new revision addressing all Gen-art review comments has been posted. Many Thanks. JP. On May 28, 2009, at 9:47 PM, Ross Callon wrote: Last call is over. Please respin (I see the most recent version dated January 2009). thanks, Ross -Original Message- From: JP Vasseur [mailto:jvass...@cisco.com] Sent: 28 April 2009 01:37 To: Ross Callon Cc: Francis Dupont; General Area Review Team; JP Vasseur; Jean-Louis Le Roux; y.ikej...@ntt.com Subject: Re: review of draft-ietf-pce-monitoring-04.txt Ah yes, I thought the IETF LC was ended. Will respin right after that. Thanks Ross. JP. On Apr 25, 2009, at 7:10 AM, Ross Callon wrote: You need to wait for the IETF last call to end before respinning. Once the IETF last call ends, then yes please respin. Thanks, Ross -Original Message- From: JP Vasseur [mailto:jvass...@cisco.com] Sent: 24 April 2009 02:05 To: Francis Dupont; Ross Callon Cc: General Area Review Team; JP Vasseur; Jean-Louis Le Roux; y.ikej...@ntt.com Subject: Re: review of draft-ietf-pce-monitoring-04.txt Many Thanks Francis. Ross, do you want me to address those comments and respin ? Thanks. JP. On Apr 23, 2009, at 11:46 PM, Francis Dupont wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-pce-monitoring-04.txt Reviewer: Francis Dupont Review Date: 2009-04-22 IETF LC End Date: 2009-04-27 IESG Telechat date: unknown Summary: Not Ready Major issues: none but some minor issues which should need another cycle. Minor issues: - 1 page 5: as the PCReq/PCReq seem to come from nowhere in 3.1 page 8 IMHO it is the right place to introduce them, for instance (it should be hard to be simpler) add after the first path computation request the comment (PCReq message). Perhaps this is not the right thing but it should be clear from the introduction the document both specifies new messages and new objects, and these new objects can be used in PCReq/PCRep too. - 4.1 page 12: incompatible requirement There SHOULD NOT be more than one instance of the MONITORING object with PCRep syntax (response-list) - 4.1 page 13: even if MONITORING object has no optional TLV currently defined, the format of these TLVs must be specified. I propose the PCEP generic TLV format, RFC 5440 7.1. - 4.3 page 16: the variance of time is a squared time. I propose to switch to standard deviation (ecart type in French, the square root of the variance) - 8.6 page 23: CONGESTION object has no defined flag. (this is not editorial because of IANA review/processing) Nits/editorial comments: - Abstract page 2 is in one block, I suggest to insert a line break before In PCE-based - Requirements Language page 2 should be moved in the terminology section - ToC page 3 / 8.3 page 21: New Error-Type and Error-Values - New Error-Values - ToC page 3 and 10 page 23: Acknowledgements - Acknowledgments - 1 page 4: IGP - Interior Gateway Protocol (IGP) - 1 page 4: troubeshooting - troubleshooting - 1 page 4: more than one PCE is - are? - 1 page 4: BRPC - Backward Recursive PCE-based Computation (BRPC) - 1 page 5: bolean - boolean - 1 page 5: By In band - By in band - 1 page 5 and many other places: e.g. - e.g., - 3 page 6: PCEMonReq - PCMonReq - 3 page 6: too many in this document (wording) - 3.1 page 8: insert a line break between: svec-list::=SVEC[svec-list] request-list::=request[request-list] - 3.1 page 8: Section 4.2.) - Section 4.2) - 3.1 page 8: charaterize - characterize - 3.1 page 9: PCMonreq - PCMonReq - 3.2 page 11: PROC-TIME and CONGESTION are defined further (8. [56]). where NO-PATH is defined? - 4.1 page 13: choose between Monitoring-id-number and monitoring- id- number - 4.1 page 13: a wrap back to one is unclear, 0x + 1 == 0, not 1. If the value zero is reserved this should be more explicit. - 4.3 page 15 1): Min, Average, Max and Variance - minimum, maximum, average and variance - 4.2 page 15 2): Procesing-time - Processing-time - 4.4 page 17: currently defined: - currently defined. - 6 page 18: value=Reception of an unacceptable number of unknown PCEP message. - value=5 Reception of an unacceptable number of unrecognized PCEP message. (i.e., put the reason value and correct meaning with a closing , BTW there are two occurrences to fix) - 6 page 19: in the next hop PCE: such next-hop choose between next-hop and next hop (I prefer the second). - 6 page 19: extra Upon receiving a PCMonRep message - 6 page 19: carrries - carries - 6 page 19: Multi-destination - multi-destination - 8.2 page 20 (last line): are defined in this document. - are defined in this document: - 8.3 page 21: as it doesn't define new error-type(s) I propose: New Error-Type and Error-Values - New Error-Values - 8.3
Re: [Gen-art] review of draft-ietf-pce-monitoring-04.txt
Ah yes, I thought the IETF LC was ended. Will respin right after that. Thanks Ross. JP. On Apr 25, 2009, at 7:10 AM, Ross Callon wrote: You need to wait for the IETF last call to end before respinning. Once the IETF last call ends, then yes please respin. Thanks, Ross -Original Message- From: JP Vasseur [mailto:jvass...@cisco.com] Sent: 24 April 2009 02:05 To: Francis Dupont; Ross Callon Cc: General Area Review Team; JP Vasseur; Jean-Louis Le Roux; y.ikej...@ntt.com Subject: Re: review of draft-ietf-pce-monitoring-04.txt Many Thanks Francis. Ross, do you want me to address those comments and respin ? Thanks. JP. On Apr 23, 2009, at 11:46 PM, Francis Dupont wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-pce-monitoring-04.txt Reviewer: Francis Dupont Review Date: 2009-04-22 IETF LC End Date: 2009-04-27 IESG Telechat date: unknown Summary: Not Ready Major issues: none but some minor issues which should need another cycle. Minor issues: - 1 page 5: as the PCReq/PCReq seem to come from nowhere in 3.1 page 8 IMHO it is the right place to introduce them, for instance (it should be hard to be simpler) add after the first path computation request the comment (PCReq message). Perhaps this is not the right thing but it should be clear from the introduction the document both specifies new messages and new objects, and these new objects can be used in PCReq/PCRep too. - 4.1 page 12: incompatible requirement There SHOULD NOT be more than one instance of the MONITORING object with PCRep syntax (response-list) - 4.1 page 13: even if MONITORING object has no optional TLV currently defined, the format of these TLVs must be specified. I propose the PCEP generic TLV format, RFC 5440 7.1. - 4.3 page 16: the variance of time is a squared time. I propose to switch to standard deviation (ecart type in French, the square root of the variance) - 8.6 page 23: CONGESTION object has no defined flag. (this is not editorial because of IANA review/processing) Nits/editorial comments: - Abstract page 2 is in one block, I suggest to insert a line break before In PCE-based - Requirements Language page 2 should be moved in the terminology section - ToC page 3 / 8.3 page 21: New Error-Type and Error-Values - New Error-Values - ToC page 3 and 10 page 23: Acknowledgements - Acknowledgments - 1 page 4: IGP - Interior Gateway Protocol (IGP) - 1 page 4: troubeshooting - troubleshooting - 1 page 4: more than one PCE is - are? - 1 page 4: BRPC - Backward Recursive PCE-based Computation (BRPC) - 1 page 5: bolean - boolean - 1 page 5: By In band - By in band - 1 page 5 and many other places: e.g. - e.g., - 3 page 6: PCEMonReq - PCMonReq - 3 page 6: too many in this document (wording) - 3.1 page 8: insert a line break between: svec-list::=SVEC[svec-list] request-list::=request[request-list] - 3.1 page 8: Section 4.2.) - Section 4.2) - 3.1 page 8: charaterize - characterize - 3.1 page 9: PCMonreq - PCMonReq - 3.2 page 11: PROC-TIME and CONGESTION are defined further (8. [56]). where NO-PATH is defined? - 4.1 page 13: choose between Monitoring-id-number and monitoring-id- number - 4.1 page 13: a wrap back to one is unclear, 0x + 1 == 0, not 1. If the value zero is reserved this should be more explicit. - 4.3 page 15 1): Min, Average, Max and Variance - minimum, maximum, average and variance - 4.2 page 15 2): Procesing-time - Processing-time - 4.4 page 17: currently defined: - currently defined. - 6 page 18: value=Reception of an unacceptable number of unknown PCEP message. - value=5 Reception of an unacceptable number of unrecognized PCEP message. (i.e., put the reason value and correct meaning with a closing , BTW there are two occurrences to fix) - 6 page 19: in the next hop PCE: such next-hop choose between next-hop and next hop (I prefer the second). - 6 page 19: extra Upon receiving a PCMonRep message - 6 page 19: carrries - carries - 6 page 19: Multi-destination - multi-destination - 8.2 page 20 (last line): are defined in this document. - are defined in this document: - 8.3 page 21: as it doesn't define new error-type(s) I propose: New Error-Type and Error-Values - New Error-Values - 8.3 page 21: has been created - was created? - 9 page 23: denail - denial - 9 page 23: shapping - shaping - 10 page 23: Acknowledgements - Acknowledgments (IETF spelling) - 11 page 23-24: take the occasion to update references, for instance: I-D.ietf-pce-pcep - RFC5440 (this is usually done by the RFC Editor but as it seems you should publish a new/fixed version of the document..,) Regards francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org
Re: [Gen-art] Gen-ART review of draft-ietf-roll-urban-routing-reqs-02.txt (corrected Subject)
Thanks for the review Brian. We're finalizing the proposed comments and Tim/Mischa will go back to you. Thanks. JP. On Dec 14, 2008, at 12:20 AM, Brian E Carpenter wrote: Thanks, Tim, I'll look forward to the next version then. As far as the MUST/SHOULD language is concerned, I'll be interested to see the IESG's current view; my personal view is that capitalisation isn't needed for design requirements. Brian On 2008-12-14 11:29, Tim Winter wrote: Brian, reviewers, I second Mischa's thanks for your time to read and comment. Please find my additional comments inline. Thanks, -Tim Mischa Dohler wrote: Dear Brian, Apologies for not having responded earlier but this is the first time I have seen these comments - I am not sure why your first attempt didn't get through. Many thanks for having taken your time to read and comment on the document. You can find my comments in-line. I would expect that my co-authors will also reply asap. Kind regards, Mischa. _ Dr Mischa Dohler Senior Researcher CTTC, Barcelona Tel: +34 93 645 2900 Fax: +34 93 645 2901 Mob: +34 6 7909 4007 www.cttc.es/home/mdohler _ I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-roll-urban-routing-reqs-02.txt Reviewer: Brian Carpenter Review Date: 2008-12-13 IESG Telechat date: 18 December 2008 Summary: Almost ready, clarifications suggested Comments: Requirements Language The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119 [RFC2119]. Well, I've read 2119 many times, and I still don't understand how it can be applied to requirements documents. It seems quite clear that it's intended for use in protocol standards. I suggest that using English (i.e. lower case must, should, etc.) is more appropriate. MISCHA: Please, discuss this with JP Vasseur and Christian Jacquenet as I have absolutely no preferences but they seem to have. Thanks. Tim: Based on feedback when the document was in the WG, the document was structured to separate informative text by using `should, must, ...' from specific normative requirements for the routing protocol(s) using `SHOULD, MUST, ...' 3.1.3. Routers ... Routers may but generally do not suffer from any form of (long-term) resource constraint, except that they need to be small and sufficiently cheap. This surprises me. In disaster recovery situations (e.g. after a major storm with prolonged power cuts) it seems that the routers will be completely dependent on battery lifetime. MISCHA: They will indeed but only over a relatively short time. We are generally talking about lifetimes of a decade or slightly more. 6.2. Parameter Constrained Routing ... Routing within urban sensor networks SHOULD require the U-LLN nodes to dynamically compute, select and install different paths towards a same destination, depending on the nature of the traffic. From this perspective, such nodes SHOULD inspect the contents of traffic payload for making routing and forwarding decisions: for example, the analysis of traffic payload should encourage the enforcement of forwarding policies based upon aggregation capabilities for the sake of efficiency. The second half of this seems highly dubious to me. It encourages layer violation, and this is known to be a performance issue for routers. It will complicate the router, slow it down, and increase its cost and power consumption. (It also won't work for encrypted payloads.) There's no particular reason to believe that this would be a useful tradeoff, since the aggregation is presumably in the upstream direction (away from sensors and actuators, and towards servers) where the power and bandwidth issues will presumably be less critical. If there is a desire to achieve traffic-based path selection, a simpler mechanism than deep packet inspection should be used. I don't want to stray too far into solutionism, but diffserv comes to mind. In any case this is written as an implementation requirement, not a requirement on the routing protocol. The requirement stated in 6.4. Support of Highly Directed Information Flows seems much closer to what is needed. MISCHA: I agree with your comment. Tim, what is your thought on this? Could you maybe change this part of the document? Note that Phil also had alluded to the problem with violating e2e provisioning in the case of data aggregation. Tim: I do understand the concern. There are certainly security implications and end-to-end implications. I would however note that there may be hops
[Gen-art] Re: Gen-art review of draft-ietf-ccamp-inter-domain-pd-path-comp-05.txt
Hi,
On Aug 17, 2007, at 5:06 PM, BRUNGARD, DEBORAH A, ATTLABS wrote:
Much thanks Elwyn -
JP - I scanned quickly and they seem to be fair comments - very
helpful
as another perspective. The fixes look to be largely descriptive
clarifications and editorial. Can you handle the updates on this
document when the rest of the IESG comments have been received?
I surely will.
Thanks.
JP.
Deborah
-Original Message-
From: Elwyn Davies [mailto:[EMAIL PROTECTED]
Sent: Friday, August 17, 2007 12:33 PM
To: General Area Review Team
Cc: Mary Barnes; [EMAIL PROTECTED]; ccamp-
[EMAIL PROTECTED];
IETF Discussion; JP Vasseur; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Gen-art review of
draft-ietf-ccamp-inter-domain-pd-path-comp-05.txt
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-ccamp-inter-domain-pd-path-comp-05.txt
Reviewer: Elwyn Davies
Review Date: 16 Aug 2007
IETF LC End Date: 16 Aug 2007
IESG Telechat date: (if known) 23 Aug 2007
Summary:
I think this document needs significant work on the core
description of
the algorithm. I found s4 to be difficult to read and it appears to
contain a number of ambiguities and inconsistencies that should be
fixed
before it goes to the IESG. The various sub-cases and routes through
the algorithm are not very clearly expressed IMO. That being said, I
think this is essentially a descriptive problem rather than any
issue of
principle. There are also a number of editorial issues (mostly need
for
acronym expansion) that need fixing in due course.
Comments:
s3.1: To avoid the sense of surprise when a Path message appears in
the
last bullet, I would suggest s/The path (ERO)/The path (specified
by an
ERO in an RSVP-TE Path message)/
s4, para 2/3: Presumably para 3 is talking about the 'next hop' being
loose or abstract as is implied by items 1) and 2). It would be
good to
make this clear. It would also be worth inserting a sentence
making it
clear that if the next hop is strict there isn't anything to do, since
otherwise one has to scan the entire section to verify that this is
the
case. It is just possible that I have misunderstood what is going on
and some of the stuff *does* apply to strict hops - in which case the
section needs a whole lot more clarity. There also needs to be some
words about the 'simple abstract node' case.
s4: Sending of PathErr. This section states that PathErr messages
'SHOULD be sent' in several places. Whilst this is consistent with
RFC
3209, both of these documents appear to be (or may be) inconsistent
with
RFC 2205 which does not appear to provide any alternative to sending a
PathErr when there is a problem processing a Path message. If it is
deemed correct to allow not sending the PathErr, reasoning should be
given as to why this might be desirable, and what is the alternative
(presumably silently ignoring the message?) and its consequences.
s4, item 1): I think the first sentence ('If the next hop is not
present in the TED.') is probably redundant and is certainly
confusing.
Part of the confusion is that the rest of the item appears to only
concern loose next hops but there is no pointer to what happens
with the
other case of abstract nodes. I think the description would be more
logical with the paragraph on abstract nodes, from later in the
section,
moved to before item 1). In that way the case splitting
(strict/loose/abstract) would be much clearer. BTW doesn't the simple
abstract case have to do some of the non-simple work?
s4, item 1, bullet 2: Which domain has to be PSC? The current one or
the one containing the next hop?
s4, item 1: Worth making even clearer that *both* conditions have
to be
satisfied.
s4, item 1: 'If the next-hop is reachable, then it SHOULD find a
domain
boundary LSR...': What does 'it' represent here? The path necessarily
crosses the boundary (unless we have some very weird topology
here ;-) )
so there is *something* on the domain boundary. What else could it
find
on the boundary? I think this is probably a badly expressed story
about
some other point. Reflecting on this, it strikes me that this is the
key point where the routing information is pulled into the TE and this
is very poorly expressed IMO.
s4, item 1: 'the ABR in the case of inter-area TE or the ASBR in the
next-hop AS in the case of inter-AS TE should be the signaled loose
next-hop in the ERO': Does this mean in the expanded ERO or the
original one? If it is the original one, how is the implementor
supposed to check it is an ABR/ASBR?
s4, item 2): The term 'ERO expansion' is not defined in any of the
standards - it is referred to as an alternative shorthand in RFC 4736
(requirements doc). It needs to be defined.
s4
Re: [Gen-art] Gen-ART review of draft-ietf-isis-caps-07.txt
Hi Vijay, Thanks for your comments. We'll definitely incorporate the required fixes. JP. On Mar 8, 2007, at 11:57 AM, Vijay K. Gurbani wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-isis-caps-07.txt Reviewer: Vijay K. Gurbani Review Date: 8 March 2007 IESG Telechat date: 12 March 2007 Summary: This draft is ready for publication as a Proposed Standard RFC. Comments: This document defines a new optional IS-IS TLV named CAPABILITY. As a generalist reviewing a document out of my domain expertise, I evaluated it mostly for content. Besides noticing the fact that the number of authors in Section 10 is more than the number of authors listed at the top of the draft, I have nothing else to comment on (fix: maybe the remaining are Contributors)? Oh, one more thing: the draft needs the new boilerplate statements. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: [EMAIL PROTECTED],bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: GEN-ART review of draft-ietf-ccamp-loose-path-reopt-01
Hi Harald, Thanks for your reply (and your review) - see in line On Feb 5, 2006, at 7:12 AM, Harald Tveit Alvestrand wrote: Good that it was helpful! One outstanding issue. --On 2. februar 2006 11:22 -0500 JP Vasseur [EMAIL PROTECTED] wrote: - The order in which the two mechanisms are introduced in section 2 and 4 was confusing to me at first read. I think it would flow better if the midpoint to headend signalling was mentioned first, and the headend to midpoint mechanism was defined afterwards, saying something like - A head-end LSR to trigger on every LSR whose next hop is a loose hop or an abstract node the re-evaluation of the current path in order to detect a potential more optimal path, which may result in the mid-point LSR using the mechanism above to signal the existence of such a more optimal path (Note: The English of the paragraph reads oddly, given that the bullets do not form complete sentences without the introductory text; it's possible to do this better, I think.) I kept the same order (because the first mechanism is likely to be the one more commonly used - that said, they're not exclusive) but I reworded a bit since indeed clarify could be improved. Thanks. isn't the answer to the headend-to-midpoint query an instance of the midpoint-to-headend signal? from the doc, I understood it as if the headend can't tell the difference between a spontaneous reoptimization and a reoptimization done in response to a headend query - but there may be a difference I missed. You did not miss anything ;-) but in the mid-point notification case there are other cases that we handle such as the reoptimization for path maintenance and so on ... Thus starting with the head-end control function is more didactic ;-) Not terribly important! Good, thanks. I'll repost today to move forward. Just a process- oriented question. What is the logical next step after having addressed the gen-art review comments ? Thanks. Cheers. JP. ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: GEN-ART review of draft-ietf-ccamp-loose-path-reopt-01
On Nov 3, 2005, at 5:48 PM, Adrian Farrel wrote: 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. will sure do, Thanks. JP. A ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
