RE: Planned changes to registration payments & deadlines
Hi, I understand that there is a need to structure the meeting fees and I have no problem with the suggested structure I do not understand why you need to pay when you register. The fee toady depends on when you pay and not when you register. In my case working for an enterprise the registration where you have to provide your personal information is done by me while the payment is done by the purchasing department using my registration link. Having to pay at the registration means that either they need to put my personal information or that we need to do it together. Why is it important to pay when you register if the fee is based on the payment day? Roni Even -Original Message- From: ietf [mailto:ietf-boun...@ietf.org] On Behalf Of Andrew Sullivan Sent: Monday, April 23, 2018 7:20 PM To: i...@ietf.org; ietf-announce@ietf.org Subject: Planned changes to registration payments & deadlines Dear colleagues, As part of its report provided ahead of the IETF 101 meeting and mentioned during the plenary session presentation, the IAOC advised the community that there could be an increase to meeting fees in the future. After an examination of our finances and meeting attendance, we have good news. We plan to adopt minimal changes to the registration fee structure and deadlines, starting with IETF 103. Early-Bird registration fee remains at the same dollar amount as previously.. We are able to do this in part because of a change in procedure: beginning with IETF 103, we will require payment upon registration, and we will move the deadline for Early Bird registration to a date in line with other meetings and conferences. We have also created a late registration fee. This fee recognizes costs imposed by late uncertainty in paid registration numbers, such as adjusting expected numbers with the hotels and venues and needing to provide for on-site printing of registration materials. Our refund policies remain the same: we provide a full refund to those denied visas, but otherwise retain 10% of the registration fee for cancellations received by the end of the Monday of the meeting (and provide no refunds thereafter). Here is the summary of the fee schedule and deadlines we intend to adopt beginning with IETF 103: TypeFee (US$) Deadline Early Bird 7007 weeks before Monday of meeting Standard 8752 weeks before Monday of meeting Late ( site) 1000none Full Time Student 150none Day Pass 375none Payment is due at registration. Registration will open no later than 12 weeks before the meeting (note that there is a different discussion ongoing about registration opening time; this is merely a commitment about the latest committed opening time). As we implement this, we plan to remove the option of cash payment for registration on site. Cash payments represent a risk to both the Secretariat staff and the organization (because cash has to be carried around), so we believe that existing options are preferable to accepting cash payments. This decision comes after three years without any change in the fees or the fee deadlines. Comments to the IAOC on timing or other matters may be sent directly to the IAOC at i...@ietf.org; or if intended to be viewed by the wider community may be sent to i...@ietf.org. Feedback provided within two weeks of this note (that is, by 8 May at 00:00 UTC) will be considered before the IAOC adopts the final policy. Best regards, Andrew Sullivan For the IAOC
Gen-ART LC review of draft-ietf-mpls-tp-rosetta-stone-12
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-mpls-tp-rosetta-stone-12 Reviewer: Roni Even Review Date:2013-10-12 IETF LC End Date: 2013-10-16 IESG Telechat date: Summary: This draft is ready for publication as an Informational RFC. Major issues: Minor issues: Nits/editorial comments:
RE: Gen-ART LC review of draft-ietf-repute-model-08
Hi, My understanding is that you can have a downref to an informational document as long as it is mentioned in the writeup and in the IETF LC. This is not a reason to make this document a standard track document if it should be informational. Roni From: Murray S. Kucherawy [mailto:superu...@gmail.com] Sent: 07 September, 2013 10:41 AM To: Roni Even Cc: draft-ietf-repute-model@tools.ietf.org; ietf; General Area Review Team Subject: Re: Gen-ART LC review of draft-ietf-repute-model-08 Hi Roni, sorry again for the delay. On Sat, Aug 31, 2013 at 4:27 AM, Roni Even ron.even@gmail.com wrote: I was asked to review the 08 version but my comments from 07 were not addressed and I did not see any response. So I am resending my previous review As for making it a standard track document, I am not sure since it looks to me as an overview and not standard. And there is no normative language in the document. Roni Even It was changed to Proposed Standard because of rules around referencing it normatively from other documents that are seeking Proposed Standard status. 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. [...] Minor issues: I was wondering why the Further Discussion section 9.3 is part of the security section. I think it should be a separate section. The wording of 9.3 is meant to be security-specific, but that's buried in the word use. I'll make it more clear. Nits/editorial comments: Section 3 the end of 2nd paragraph mechansisms to mechanisms Fixed. Thanks again, -MSK
Gen-ART LC review of draft-ietf-repute-model-08
I was asked to review the 08 version but my comments from 07 were not addressed and I did not see any response. So I am resending my previous review As for making it a standard track document, I am not sure since it looks to me as an overview and not standard. And there is no normative language in the document. Roni Even 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-repute-model-07 Reviewer: Roni Even Review Date:2013-8-20 IETF LC End Date: 2013-8-29 IESG Telechat date: Summary: This draft is ready for publication as an Informational RFC. Major issues: Minor issues: I was wondering why the Further Discussion section 9.3 is part of the security section. I think it should be a separate section. Nits/editorial comments: Section 3 the end of 2nd paragraph mechansisms to mechanisms
RE: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp-ping-12
Hi, I am not sure you responded to my latest email. Having the policy for TLV type 1 here is not enough in my view since I only look at RFC4379 and create a new TLV type I will not know that I have to register it also for the type 21 if it will not be mentioned As for the vendor specific see my other email Roni -Original Message- From: Mach Chen [mailto:mach.c...@huawei.com] Sent: 29 August, 2013 11:33 AM To: Roni Even; draft-ietf-mpls-return-path-specified-lsp- ping@tools.ietf.org Cc: ietf@ietf.org; gen-...@ietf.org Subject: RE: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp- ping-12 Hi Roni, Thanks for your detailed review and comments! Please see my reply inline... From: Roni Even [mailto:ron.even@gmail.com] Sent: Wednesday, August 28, 2013 9:06 PM To: draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org Cc: ietf@ietf.org; gen-...@ietf.org Subject: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp-ping-12 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-mpls-return-path-specified-lsp-ping-12 Reviewer: Roni Even Review Date:2013-8-28 IETF LC End Date: 2013-9-4 IESG Telechat date: Summary: This draft is almost ready for publication as a standard track RFC. Major issues: Minor issues: I am not clear on the sub-TLV in section 6.2 1. If a new sub-TLV is defined for TLV type 1 do they need also to be added to TLV type 21. This should be clear, and if there is some relation I think it should be reflected in the IANA registry for TLV type 1 Yes, type 21 TLV intends to reuse existing and future defined sub-TLVs for type TLV 1. And in Section 3.3, it has already stated this, it says: The Target FEC sub-TLVs defined in [RFC4379] provide a good way to identify a specific return path. The Reply Path TLV can carry any sub-TLV defined for use in the Target FEC Stack TLV that can be registered. So, for Section 6.2, to make it cleaner and more explicit, how about this change: Old: No assignments of sub-TLVs in the range of 0-16383 and 32768-49161 are made directly for TLV Type 21, sub-TLVs in these ranges are copied from the assignments made for TLV Type 1. Assignments of sub-... New: No assignments of sub-TLVs in the range of 0-16383 and 32768-49161 are made directly for TLV Type 21, sub-TLVs in these ranges are copied from the assignments (including existing and future allocations) made for TLV Type 1. Assignments of sub-... 2. For the vendor or private use why a difference policy than the rest of the sub-TLV registry This document does not make any changes to the Vendor and Private use definition, range and policy as defined in RFC4379. In RFC4379, it's policy is defined different from other ranges. Nits/editorial comments: 1. In section 3.4 I assume that TC is traffic class. It will be good to expand and have reference. OK, will fix it when all last call comments received. Best regards, Mach
RE: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp-ping-12
Hi, This text is OK if one wants to implement this draft. My concern was about the consistency of the IANA registration so that if someone defines a new TLV type 1 based on RFC4379, IANA will know that it must update also the registry for TLV type 21. If you see no such problem, I have no concerns Roni -Original Message- From: Mach Chen [mailto:mach.c...@huawei.com] Sent: 29 August, 2013 1:05 PM To: Roni Even; draft-ietf-mpls-return-path-specified-lsp- ping@tools.ietf.org Cc: ietf@ietf.org; gen-...@ietf.org Subject: RE: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp- ping-12 Hi Roni, How about this: No assignments of sub-TLVs in the range of 0-16383 and 32768-49161 are made directly for TLV Type 21, sub-TLVs in these ranges are copied from the assignments made for TLV Type 1 and kept the same as that for TLV Type 1. All sub-TLVs in these ranges (include existing and future defined) defined for TLV Type 1 apply to TLV Type 21. Assignments of sub-... Best regards, Mach -Original Message- From: Roni Even [mailto:ron.even@gmail.com] Sent: Thursday, August 29, 2013 5:21 PM To: Mach Chen; draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org Cc: ietf@ietf.org; gen-...@ietf.org Subject: RE: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp-ping-12 Hi, I am not sure you responded to my latest email. Having the policy for TLV type 1 here is not enough in my view since I only look at RFC4379 and create a new TLV type I will not know that I have to register it also for the type 21 if it will not be mentioned As for the vendor specific see my other email Roni -Original Message- From: Mach Chen [mailto:mach.c...@huawei.com] Sent: 29 August, 2013 11:33 AM To: Roni Even; draft-ietf-mpls-return-path-specified-lsp- ping@tools.ietf.org Cc: ietf@ietf.org; gen-...@ietf.org Subject: RE: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp- ping-12 Hi Roni, Thanks for your detailed review and comments! Please see my reply inline... From: Roni Even [mailto:ron.even@gmail.com] Sent: Wednesday, August 28, 2013 9:06 PM To: draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org Cc: ietf@ietf.org; gen-...@ietf.org Subject: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp-ping-12 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-mpls-return-path-specified-lsp-ping-12 Reviewer: Roni Even Review Date:2013-8-28 IETF LC End Date: 2013-9-4 IESG Telechat date: Summary: This draft is almost ready for publication as a standard track RFC. Major issues: Minor issues: I am not clear on the sub-TLV in section 6.2 1. If a new sub-TLV is defined for TLV type 1 do they need also to be added to TLV type 21. This should be clear, and if there is some relation I think it should be reflected in the IANA registry for TLV type 1 Yes, type 21 TLV intends to reuse existing and future defined sub-TLVs for type TLV 1. And in Section 3.3, it has already stated this, it says: The Target FEC sub-TLVs defined in [RFC4379] provide a good way to identify a specific return path. The Reply Path TLV can carry any sub-TLV defined for use in the Target FEC Stack TLV that can be registered. So, for Section 6.2, to make it cleaner and more explicit, how about this change: Old: No assignments of sub-TLVs in the range of 0-16383 and 32768-49161 are made directly for TLV Type 21, sub-TLVs in these ranges are copied from the assignments made for TLV Type 1. Assignments of sub-... New: No assignments of sub-TLVs in the range of 0-16383 and 32768-49161 are made directly for TLV Type 21, sub-TLVs in these ranges are copied from the assignments (including existing and future allocations) made for TLV Type 1. Assignments of sub-... 2. For the vendor or private use why a difference policy than the rest of the sub-TLV registry This document does not make any changes to the Vendor and Private use definition, range and policy as defined in RFC4379. In RFC4379, it's policy is defined different from other ranges. Nits/editorial comments: 1. In section 3.4 I assume that TC is traffic class. It will be good to expand and have reference. OK, will fix it when all last call comments received. Best regards, Mach
RE: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp-ping-12
Hi, This is OK . I have no concerns Roni -Original Message- From: Loa Andersson [mailto:l...@pi.nu] Sent: 29 August, 2013 2:46 PM To: Roni Even Cc: 'Mach Chen'; draft-ietf-mpls-return-path-specified-lsp- ping@tools.ietf.org; gen-...@ietf.org; ietf@ietf.org Subject: Re: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp- ping-12 Roni, tnx - the authors should add words in the IANA section requesting that IANA add this the pointed in the registry; they normally do anyway, but writing it down should not be a problem. As for Vendor Private RFC 4379 says: Values from Vendor Private ranges MUST NOT be registered with IANA; however, the message MUST contain an enterprise code as registered with the IANA SMI Private Network Management Private Enterprise Numbers. For each name space that has a Vendor Private range, it must be specified where exactly the SMI Private Enterprise Number resides; see below for examples. In this way, several enterprises (vendors) can use the same code point without fear of collision. The way I read this is that the paragraph does two things (1) defines the allocation policy (in this case that vendor private won't be assigned by IANA) and (2) put a restriction on the vendor private (sub-)TLVs; they must contain a private enterprise number. Up to now I've thought the restriction on the format was global for all vendor private sub-TLVs that are used by TLV for LSP Ping. However we put words to the same effect in e.g. 6424, wo there is no reason not to do it here also. A pointer to RFC4379 should be enough e.g.: For the vendor private sub-TLVs defined for this document, the same allocation policies and requirement on the sub-TLV format that is specified for vendor private sub-TLVs in RFC4379 [RFC4379] appliacable. Would that cover you concern? /Loa On 2013-08-29 12:24, Roni Even wrote: Hi, This text is OK if one wants to implement this draft. My concern was about the consistency of the IANA registration so that if someone defines a new TLV type 1 based on RFC4379, IANA will know that it must update also the registry for TLV type 21. If you see no such problem, I have no concerns Roni -Original Message- From: Mach Chen [mailto:mach.c...@huawei.com] Sent: 29 August, 2013 1:05 PM To: Roni Even; draft-ietf-mpls-return-path-specified-lsp- ping@tools.ietf.org Cc: ietf@ietf.org; gen-...@ietf.org Subject: RE: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp- ping-12 Hi Roni, How about this: No assignments of sub-TLVs in the range of 0-16383 and 32768-49161 are made directly for TLV Type 21, sub-TLVs in these ranges are copied from the assignments made for TLV Type 1 and kept the same as that for TLV Type 1. All sub-TLVs in these ranges (include existing and future defined) defined for TLV Type 1 apply to TLV Type 21. Assignments of sub-... Best regards, Mach -Original Message- From: Roni Even [mailto:ron.even@gmail.com] Sent: Thursday, August 29, 2013 5:21 PM To: Mach Chen; draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org Cc: ietf@ietf.org; gen-...@ietf.org Subject: RE: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp-ping-12 Hi, I am not sure you responded to my latest email. Having the policy for TLV type 1 here is not enough in my view since I only look at RFC4379 and create a new TLV type I will not know that I have to register it also for the type 21 if it will not be mentioned As for the vendor specific see my other email Roni -Original Message- From: Mach Chen [mailto:mach.c...@huawei.com] Sent: 29 August, 2013 11:33 AM To: Roni Even; draft-ietf-mpls-return-path-specified-lsp- ping@tools.ietf.org Cc: ietf@ietf.org; gen-...@ietf.org Subject: RE: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp- ping-12 Hi Roni, Thanks for your detailed review and comments! Please see my reply inline... From: Roni Even [mailto:ron.even@gmail.com] Sent: Wednesday, August 28, 2013 9:06 PM To: draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org Cc: ietf@ietf.org; gen-...@ietf.org Subject: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp-ping-12 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-mpls-return-path-specified-lsp-ping-12 Reviewer: Roni Even Review Date:2013-8-28 IETF LC End Date: 2013-9-4 IESG Telechat date: Summary: This draft is almost ready for publication as a standard track RFC. Major issues: Minor issues: I am not clear on the sub-TLV
RE: Gen-ART LC review ofdraft-ietf-mpls-return-path-specified-lsp-ping-12
HI, I do not follow all the MPLS work, this Gen-ART review is done during the IETF LC. I would think that your point should have been discussed in the WG before sending the return path ping to publication. BTW: I took a quick look at draft-andersson-mpls-lsp-ping-upd-00 third paragraph of section 2 and I am not sure that the return path ping is influenced since it does not use all the sub-tlv from tlv type 1 so it should be a separate registry Roni -Original Message- From: t.p. [mailto:daedu...@btconnect.com] Sent: 29 August, 2013 6:33 PM To: Roni Even; draft-ietf-mpls-return-path-specified-lsp- ping@tools.ietf.org Cc: gen-...@ietf.org; ietf@ietf.org Subject: Re: Gen-ART LC review ofdraft-ietf-mpls-return-path-specified-lsp- ping-12 Roni I find it difficult to know whether to agree with you or not since there is another gorilla operating in this namespace, namely draft-andersson-mpls-lsp-ping-upd-00 which sort of gives the option of taking out the sub-TLV types of a TLV Type into a separate registry which can then be referenced by the specifications of several TLV Types. This I-D formally calls for no action by IANA, except that it implies a reorganisation of the registries which IANA might well already have executed - certainly, the registries no longer look the same as they did a few months ago although that might also be a coincidence. You make reference to the registry set up by RFC6426 but you should be aware that what is now in the IANA registries is not what was there when that RFC was approved; rather, it has changed as alluded to above.. If draft-andersson-mpls-lsp-ping-upd-00 is approved, and my perception is that IANA assumes it has been, then this, return-path I-D would appear to be barking up the wrong tree and needs revising to reflect the new IANA structure, namely that it needs to update the title which already exists Sub-TLVs for TLV Types 1 and 16 to become Sub- TLVs for TLV Types 1 and 16 and 21 whereupon things start to fall into place draft-andersson-mpls-lsp-ping-upd-00 also updates RFC4379 which, if accepted, means, I think, that this I-D need not. All very technically sound but we seem to have our processes upside down. There is of course a lengthy history to this that is not material to the current discussion. Tom Petch - Original Message - From: Roni Even ron.even@gmail.com To: 'Mach Chen' mach.c...@huawei.com; draft-ietf-mpls-return-path- specified-lsp-ping@tools.ietf.org Cc: gen-...@ietf.org; ietf@ietf.org Sent: Thursday, August 29, 2013 11:24 AM Subject: RE: Gen-ART LC review ofdraft-ietf-mpls-return-path-specified-lsp-ping-12 Hi, This text is OK if one wants to implement this draft. My concern was about the consistency of the IANA registration so that if someone defines a new TLV type 1 based on RFC4379, IANA will know that it must update also the registry for TLV type 21. If you see no such problem, I have no concerns Roni -Original Message- From: Mach Chen [mailto:mach.c...@huawei.com] Sent: 29 August, 2013 1:05 PM To: Roni Even; draft-ietf-mpls-return-path-specified-lsp- ping@tools.ietf.org Cc: ietf@ietf.org; gen-...@ietf.org Subject: RE: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp- ping-12 Hi Roni, How about this: No assignments of sub-TLVs in the range of 0-16383 and 32768-49161 are made directly for TLV Type 21, sub-TLVs in these ranges are copied from the assignments made for TLV Type 1 and kept the same as that for TLV Type 1. All sub-TLVs in these ranges (include existing and future defined) defined for TLV Type 1 apply to TLV Type 21. Assignments of sub-... Best regards, Mach -Original Message- From: Roni Even [mailto:ron.even@gmail.com] Sent: Thursday, August 29, 2013 5:21 PM To: Mach Chen; draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org Cc: ietf@ietf.org; gen-...@ietf.org Subject: RE: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp-ping-12 Hi, I am not sure you responded to my latest email. Having the policy for TLV type 1 here is not enough in my view since I only look at RFC4379 and create a new TLV type I will not know that I have to register it also for the type 21 if it will not be mentioned As for the vendor specific see my other email Roni -Original Message- From: Mach Chen [mailto:mach.c...@huawei.com] Sent: 29 August, 2013 11:33 AM To: Roni Even; draft-ietf-mpls-return-path-specified-lsp- ping@tools.ietf.org Cc: ietf@ietf.org; gen-...@ietf.org Subject: RE: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp- ping-12 Hi Roni, Thanks for your detailed review and comments! Please see my reply inline
Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp-ping-12
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-mpls-return-path-specified-lsp-ping-12 Reviewer: Roni Even Review Date:2013-8-28 IETF LC End Date: 2013-9-4 IESG Telechat date: Summary: This draft is almost ready for publication as a standard track RFC. Major issues: Minor issues: I am not clear on the sub-TLV in section 6.2 1. If a new sub-TLV is defined for TLV type 1 do they need also to be added to TLV type 21. This should be clear, and if there is some relation I think it should be reflected in the IANA registry for TLV type 1 2. For the vendor or private use why a difference policy than the rest of the sub-TLV registry Nits/editorial comments: 1. In section 3.4 I assume that TC is traffic class. It will be good to expand and have reference.
RE: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp-ping-12
Hi Loa, See inline Roni -Original Message- From: Loa Andersson [mailto:l...@pi.nu] Sent: 28 August, 2013 5:20 PM To: Roni Even Cc: draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org; gen- a...@ietf.org; ietf@ietf.org Subject: Re: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp- ping-12 Roni, Thanks for an insightful review, you have captured much of what we been struggling with when it comes to the IANA allocations. On 2013-08-28 15:06, 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-mpls-return-path-specified-lsp-ping-12 Summary: This draft is almost ready for publication as a standard track RFC. Major issues: Minor issues: I am not clear on the sub-TLV in section 6.2 1. If a new sub-TLV is defined for TLV type 1 do they need also to be added to TLV type 21. Yes the document says Directly copied from TLV Type 1, MUST NOT be assigned the intention is that this applies to future sub-TLVs also. I guess it could be changed to Directly copied from TLV Type 1 (including future allocations for TLV Type 1, MUST NOT be assigned if that makes thing clearer. This should be clear, and if there is some relation I think it should be reflected in the IANA registry for TLV type 1 I guess that makes sense - but it has not been the what we've done earlier - I think we could add this where needed by directly communicate this to IANA. [Roni Even] I think that the directive for future allocation must be clear both in the IANA registry and the document for example look at http://tools.ietf.org/html/rfc6426#section-7.3 I also think that is this case this document updates RFC4379 . 2. For the vendor or private use why a difference policy than the rest of the sub-TLV registry We don't assign vendor private use at all, so by default it is different. I don't see that it could be different. [Roni Even] RFC4379 says If a TLV or sub-TLV has a Type that falls in the range for Vendor Private Use, the Length MUST be at least 4, and the first four octets MUST be that vendor's SMI Private Enterprise Number, in network octet order. The rest of the Value field is private to the vendor. /Loa Nits/editorial comments: 1. In section 3.4 I assume that TC is traffic class. It will be good to expand and have reference. -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
Gen-ART LC review of draft-ietf-repute-model-07
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-repute-model-07 Reviewer: Roni Even Review Date:2013-8-20 IETF LC End Date: 2013-8-29 IESG Telechat date: Summary: This draft is ready for publication as an Informational RFC. Major issues: Minor issues: I was wondering why the Further Discussion section 9.3 is part of the security section. I think it should be a separate section. Nits/editorial comments: Section 3 the end of 2nd paragraph mechansisms to mechanisms
Gen-ART IETF LC review of draft-allen-dispatch-imei-urn-as-instanceid-10
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-allen-dispatch-imei-urn-as-instanceid-10 Reviewer: Roni Even Review Date:2013-8-5 IETF LC End Date: 2013-8-16 IESG Telechat date: Summary: This draft is almost ready for publication as an Informational RFC. Major issues: Minor issues: Why is it going to be an Informational RFC, considering that there is a lot of normative language in the document. Nits/editorial comments: According to RFC editor guidelines (http://www.rfc-editor.org/policy.html#policy.abstract) the abstract section should not contain citations unless they are completely defined within the Abstract.
Gen-ART LC review of draft-merkle-tls-brainpool-02
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-merkle-tls-brainpool-02 Reviewer: Roni Even Review Date:2013-6-30 IETF LC End Date: 2013-7-23 IESG Telechat date: Summary: This draft is almost ready for publication as Standard track RFC. Major issues: Minor issues: In section 1 you reference TLS 1.0 and 1.1 usage based on RFC 4492. What about TLS 1.2 usage specified in RFC5246 A.7 Nits/editorial comments: 1. In section 3 the registry name is EC Named Curve 2. In section 3 change suitability to suitable
Gen-ART LC review of draft-ietf-pkix-est-07
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-pkix-est-07 Reviewer: Roni Even Review Date:2013-6-22 IETF LC End Date: 2013-6-24 IESG Telechat date: 2013-6-27 Summary: This draft is ready for publication as Standard track RFC. This is not a comment, I read the draft and not being an expert in this area I found it clear for me to read. The document structure made it easier to read. Major issues: Minor issues: Nits/editorial comments: 1. In section 4.5.2 to use the the secp384r1 elliptic curve repeated the
RE: Gen-ART LC review of draft-ietf-mmusic-sdp-miscellaneous-caps-05
Hi Simo, This will be OK Roni From: simo.veikkolai...@nokia.com [mailto:simo.veikkolai...@nokia.com] Sent: 04 June, 2013 9:48 AM To: ron.even@gmail.com; draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org Cc: ietf@ietf.org; gen-...@ietf.org Subject: RE: Gen-ART LC review of draft-ietf-mmusic-sdp-miscellaneous-caps-05 Would adding a statement like this at the end of 3.1.2 address your concern: Exceptions for other network types, such as for the ATM network type defined in [RFC3108], require additional specifications. Regards, Simo From: ext Roni Even [mailto:ron.even@gmail.com] Sent: 4. kesäkuuta 2013 2:26 To: Veikkolainen Simo (Nokia-CTO/Espoo); draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org Cc: ietf@ietf.org; gen-...@ietf.org Subject: RE: Gen-ART LC review of draft-ietf-mmusic-sdp-miscellaneous-caps-05 Hi Simo, For the PSTN case the document explain how to construct the m-line PSTN is used based on the ccap using port 9. This is not specified for the ATM case. So if it is not mentioned it should be clear that using ccap for ATM is not specified and need another document Roni From: simo.veikkolai...@nokia.com [mailto:simo.veikkolai...@nokia.com] Sent: 31 May, 2013 1:14 PM To: ron.even@gmail.com; draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org Cc: ietf@ietf.org; gen-...@ietf.org Subject: RE: Gen-ART LC review of draft-ietf-mmusic-sdp-miscellaneous-caps-05 Hello Roni, Please see my answer below prefixed with [SV]. From: ext Roni Even [mailto:ron.even@gmail.com] Sent: 29. toukokuuta 2013 21:13 To: draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org Cc: ietf@ietf.org; gen-...@ietf.org Subject: Gen-ART LC review of draft-ietf-mmusic-sdp-miscellaneous-caps-05 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-mmusic-sdp-miscellaneous-caps-05 Reviewer: Roni Even Review Date:2013529 IETF LC End Date: 2013-64 IESG Telechat date: Summary: This draft is almost ready for publication as Standard track RFC. Major issues: Minor issues: 1. I can understand from the draft that when you have IP and PSTN nettype it is requires that the ccap will be for the PSTN. What happens if you want to have the ccap nettype as ATM to be used with IP in the c= [SV] If either endpoint does not support ATM, the c= line with the ATM address would not get used (either it is not offered, or the Answerer removes that from the SDP configurations). In case both endpoints actually support and want to use ATM as alternative to IP based bearer, the conventions in RFC3108 would need to be followed when crafting the SDP configurations. That said, I havent taken a detailed look at RFC3108 to see if the ATM based media can be negotiated using the SDP Capability Negotiation framework and its current extensions. Simo Nits/editorial comments:
RE: Gen-ART LC review of draft-ietf-mmusic-sdp-miscellaneous-caps-05
Hi Simo, For the PSTN case the document explain how to construct the m-line PSTN is used based on the ccap using port 9. This is not specified for the ATM case. So if it is not mentioned it should be clear that using ccap for ATM is not specified and need another document Roni From: simo.veikkolai...@nokia.com [mailto:simo.veikkolai...@nokia.com] Sent: 31 May, 2013 1:14 PM To: ron.even@gmail.com; draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org Cc: ietf@ietf.org; gen-...@ietf.org Subject: RE: Gen-ART LC review of draft-ietf-mmusic-sdp-miscellaneous-caps-05 Hello Roni, Please see my answer below prefixed with [SV]. From: ext Roni Even [mailto:ron.even@gmail.com] Sent: 29. toukokuuta 2013 21:13 To: draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org Cc: ietf@ietf.org; gen-...@ietf.org Subject: Gen-ART LC review of draft-ietf-mmusic-sdp-miscellaneous-caps-05 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-mmusic-sdp-miscellaneous-caps-05 Reviewer: Roni Even Review Date:2013-5-29 IETF LC End Date: 2013-6-4 IESG Telechat date: Summary: This draft is almost ready for publication as Standard track RFC. Major issues: Minor issues: 1. I can understand from the draft that when you have IP and PSTN nettype it is requires that the ccap will be for the PSTN. What happens if you want to have the ccap nettype as ATM to be used with IP in the c= [SV] If either endpoint does not support ATM, the c= line with the ATM address would not get used (either it is not offered, or the Answerer removes that from the SDP configurations). In case both endpoints actually support and want to use ATM as alternative to IP based bearer, the conventions in RFC3108 would need to be followed when crafting the SDP configurations. That said, I haven't taken a detailed look at RFC3108 to see if the ATM based media can be negotiated using the SDP Capability Negotiation framework and its current extensions. Simo Nits/editorial comments:
Gen-ART LC review of draft-ietf-mmusic-sdp-miscellaneous-caps-05
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-mmusic-sdp-miscellaneous-caps-05 Reviewer: Roni Even Review Date:2013-5-29 IETF LC End Date: 2013-6-4 IESG Telechat date: Summary: This draft is almost ready for publication as Standard track RFC. Major issues: Minor issues: 1. I can understand from the draft that when you have IP and PSTN nettype it is requires that the ccap will be for the PSTN. What happens if you want to have the ccap nettype as ATM to be used with IP in the c= Nits/editorial comments:
RE: Gen-ART LC review of draft-ietf-netmod-interfaces-cfg-10
Hi, This new text is OK. Thanks Roni -Original Message- From: Martin Bjorklund [mailto:m...@tail-f.com] Sent: 29 April, 2013 11:26 AM To: ron.even@gmail.com Cc: draft-ietf-netmod-interfaces-cfg@tools.ietf.org; ietf@ietf.org; gen-...@ietf.org Subject: Re: Gen-ART LC review of draft-ietf-netmod-interfaces-cfg-10 Hi, Roni Even ron.even@gmail.com wrote: Martin, Thanks for the response. I am OK with your responses to the nits. As for the comment on location I think I understand but what got me thinking was the examples. In E.1 An operator can configure a new interface by sending an edit-config containing: interface nc:operation=create namefastethernet-1/0/name /interface When the server processes this request, it will set the leaf type to ethernetCsmacd and location to 1/0. Thus, if the client performs a get-config right after the edit-config above, it will get: interface namefastethernet-1/0/name typeethernetCsmacd/type location1/0/location /interface I can see how the linkage between the location and name is done. I am not sure how the operator knows from the response what is the physical location without knowing the device type and manufacturer but at least the linkage is there and this is why I thought of it more as a logical device and not physical one. Ok. Since this is an example of a configuration of a physical interface, it is assumed that the operator somehow knows which physical port is being reconfigured -- somehow the operator must be able to know what the port where the new cable was inserted is called in the config. But it makes sense to be more clear about this. How about this change: OLD: The implementation restricts the names of the interfaces to one of fastethernet-N/M or gigabitethernet-N/M. The location of an interface is a string on the form N/M. The implementation auto-initializes the values for type and location based on the interface name. NEW: The implementation restricts the names of the interfaces to one of fastethernet-N/M or gigabitethernet-N/M. The location of an interface is a string on the form N/M. It is assumed that the operator is aware of this naming scheme. The implementation auto-initializes the values for type and location based on the interface name. When looking at E2.2 example (ditto for this example.) /martin An operator can configure a new interface by sending an edit-config containing: interface nc:operation=create nameacme-interface/name typeethernetCsmacd/type location1/0/location /interface Here the operator need to know the device to configure a specific interface and know how many interface exist and how they are named. So you assume that for this case this is known to the configuration. Roni -Original Message- From: Martin Bjorklund [mailto:m...@tail-f.com] Sent: 28 April, 2013 12:50 PM To: ron.even@gmail.com Cc: draft-ietf-netmod-interfaces-cfg@tools.ietf.org; ietf@ietf.org; gen-...@ietf.org Subject: Re: Gen-ART LC review of draft-ietf-netmod-interfaces-cfg-10 Hi, Thank you for your review. Comments inline. Roni Even ron.even@gmail.com 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-netmod-interfaces-cfg-10 Reviewer: Roni Even Review Date:2013-4-28 IETF LC End Date: 2013-5-3 IESG Telechat date: 2013-5-16 Summary: This draft is almost ready for publication as Standard track RFC. Major issues: Minor issues: 1. I had some problem understanding the location leaf. Section 3.2 has it as a string and says that The device uses the location string to identify the physical or logical entity that the configuration applies to. I am not sure how you identify physical location having no definition of the mapping. The sentence just before the quoted one above says: The format of this string is device- and type-dependent. and then the text says: How a client can learn which types and locations are present on a certain device is outside the scope of this document. So the exact procedure is currently left to the vendors, but may be standardized in a future document (if possible...) I saw the examples in Appendix E and it looked more to me as logical mapping but not physical since it attaches a name to something in the device but I am not clear how you know what it is physically in the device. If the name 0-n or n/m are real physical entities, I think that it should be specified some place. Nits/editorial comments
Gen-ART LC review of draft-ietf-netmod-interfaces-cfg-10
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-netmod-interfaces-cfg-10 Reviewer: Roni Even Review Date:2013-4-28 IETF LC End Date: 2013-5-3 IESG Telechat date: 2013-5-16 Summary: This draft is almost ready for publication as Standard track RFC. Major issues: Minor issues: 1. I had some problem understanding the location leaf. Section 3.2 has it as a string and says that The device uses the location string to identify the physical or logical entity that the configuration applies to. I am not sure how you identify physical location having no definition of the mapping. I saw the examples in Appendix E and it looked more to me as logical mapping but not physical since it attaches a name to something in the device but I am not clear how you know what it is physically in the device. If the name 0-n or n/m are real physical entities, I think that it should be specified some place. Nits/editorial comments: 1. In the introduction section maybe add to the first sentence a reference to RFC6244 with some text. 2. In section 2 are the must and should used as described in RFC2119, if yes need capital letters 3. In section 3.1 It is optional in the data model, but if the type represents a physical interface, it is mandatory, suggest having RFC2119 language It is OPTIONAL in the data model, but if the type represents a physical interface, it is MUST be specified
RE: Gen-ART LC review of draft-ietf-netmod-interfaces-cfg-10
Martin, Thanks for the response. I am OK with your responses to the nits. As for the comment on location I think I understand but what got me thinking was the examples. In E.1 An operator can configure a new interface by sending an edit-config containing: interface nc:operation=create namefastethernet-1/0/name /interface When the server processes this request, it will set the leaf type to ethernetCsmacd and location to 1/0. Thus, if the client performs a get-config right after the edit-config above, it will get: interface namefastethernet-1/0/name typeethernetCsmacd/type location1/0/location /interface I can see how the linkage between the location and name is done. I am not sure how the operator knows from the response what is the physical location without knowing the device type and manufacturer but at least the linkage is there and this is why I thought of it more as a logical device and not physical one. When looking at E2.2 example An operator can configure a new interface by sending an edit-config containing: interface nc:operation=create nameacme-interface/name typeethernetCsmacd/type location1/0/location /interface Here the operator need to know the device to configure a specific interface and know how many interface exist and how they are named. So you assume that for this case this is known to the configuration. Roni -Original Message- From: Martin Bjorklund [mailto:m...@tail-f.com] Sent: 28 April, 2013 12:50 PM To: ron.even@gmail.com Cc: draft-ietf-netmod-interfaces-cfg@tools.ietf.org; ietf@ietf.org; gen-...@ietf.org Subject: Re: Gen-ART LC review of draft-ietf-netmod-interfaces-cfg-10 Hi, Thank you for your review. Comments inline. Roni Even ron.even@gmail.com 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-netmod-interfaces-cfg-10 Reviewer: Roni Even Review Date:2013-4-28 IETF LC End Date: 2013-5-3 IESG Telechat date: 2013-5-16 Summary: This draft is almost ready for publication as Standard track RFC. Major issues: Minor issues: 1. I had some problem understanding the location leaf. Section 3.2 has it as a string and says that The device uses the location string to identify the physical or logical entity that the configuration applies to. I am not sure how you identify physical location having no definition of the mapping. The sentence just before the quoted one above says: The format of this string is device- and type-dependent. and then the text says: How a client can learn which types and locations are present on a certain device is outside the scope of this document. So the exact procedure is currently left to the vendors, but may be standardized in a future document (if possible...) I saw the examples in Appendix E and it looked more to me as logical mapping but not physical since it attaches a name to something in the device but I am not clear how you know what it is physically in the device. If the name 0-n or n/m are real physical entities, I think that it should be specified some place. Nits/editorial comments: 1.In the introduction section maybe add to the first sentence a reference to RFC6244 with some text. Ok, this probably makes sense. I will check w/ the WG and other documents. 2.In section 2 are the must and should used as described in RFC2119, if yes need capital letters Seciton 2 is more of a background, non-normative section. It lists some of the design objectives. 3.In section 3.1 It is optional in the data model, but if the type represents a physical interface, it is mandatory, suggest having RFC2119 language It is OPTIONAL in the data model, but if the type represents a physical interface, it is MUST be specified I think the first one should not be OPTIONAL, but the second one is correct. So I suggest this: It is defined as being optional in the data model, but if the type represents a physical interface, it MUST be specified. /martin
Gen-ART LC review of draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03
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-opsec-ipv6-implications-on-ipv4-nets-03 Reviewer: Roni Even Review Date:2013-4-6 IETF LC End Date: 2013-4-12 IESG Telechat date: Summary: This draft is ready for publication as an Informational RFC. Major issues: Minor issues: Nits/editorial comments: 1. I found this draft very informational but I was wondering if it will be better to have in the introduction and the abstract a sentence that will mention the target audience for this draft.
Gen-ART LC review of draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03
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-opsec-ipv6-implications-on-ipv4-nets-03 Reviewer: Roni Even Review Date:2013-4-6 IETF LC End Date: 2013-4-12 IESG Telechat date: Summary: This draft is ready for publication as an Informational RFC. Major issues: Minor issues: Nits/editorial comments: 1. I found this draft very informational but I was wondering if it will be better to have in the introduction and the abstract a sentence that will mention the target audience for this draft.
GenART LC review of draft-merkle-ikev2-ke-brainpool-03
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-merkle-ikev2-ke-brainpool-03 Reviewer: Roni Even Review Date:2013-3-25 IETF LC End Date: 2013-3-26 IESG Telechat date: Summary: This draft is almost ready for publication as an Informational RFC. Major issues: Minor issues: 1. In table 1 the Transform ID are specified as TBD1 to TBD4. I noticed that IANA have already assigned values 27-30. So they should be specified. If not it will be good to ask the RFC editor before publication to update the table. I saw that you only asked IANA to allocate values. 2. In the IANA section I did not understand to which table you are referring to For the new entries in the table of the Transform Type 4 repository, a reference to Section 2.3 of [IKE_DH_Req] shall be included in the column named Recipient Tests indicating the required checks for the other peer's Diffie-Hellman public keys. Nits/editorial comments:
Gen-ART LC review of draft-ietf-ancp-pon-04
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-ancp-pon-04 Reviewer: Roni Even Review Date:2013-2-12 IETF LC End Date: 2013-2-19 IESG Telechat date: Summary: This draft is ready for publication as an Informational RFC. Major issues: Minor issues: Nits/editorial comments: 1. OMCI is expanded very late in the document and not on the first usage.
Gen-ART LC review of draft-harkins-brainpool-ike-groups-04
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-harkins-brainpool-ike-groups-04 Reviewer: Roni Even Review Date:2013-2-13 IETF LC End Date: 2013-2-28 IESG Telechat date: Summary: This draft is ready for publication as an Informational RFC. Major issues: Minor issues: Nits/editorial comments:
Gen-ART LC review of draft-gp-obsolete-icmp-types-iana-01
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-gp-obsolete-icmp-types-iana-01 Reviewer: Roni Even Review Date:2013-1-21 IETF LC End Date: 2013-2-14 IESG Telechat date: Summary: This draft is ready for publication as Standard track RFC. Major issues: Minor issues: Nits/editorial comments:
GenART LC review of draft-ietf-rmt-fcast-07
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-rmt-fcast-07 Reviewer: Roni Even Review Date:2013-1-15 IETF LC End Date: 2013-1-22 IESG Telechat date: Summary: This draft is almost ready for publication as Standard track RFC. Major issues: Minor issues: 1. I had some problem when reading the document about what is mandatory to support. The distinction between what is required to be supported and used is mentioned in section 5. Also section 3.3 discusses what compliant implementation is, but section 5 provides the full information. I think that it will be better to move section 5 before or at the beginning of section 3 or as part of 3.3. no need to have the information twice. 2. In section 3.3 The support of GZIP encoding, or any other solution, remains optional. I think that support is mandatory. Nits/editorial comments: 1. In section 5.1 at the end of first table in-bound should be in-band 2. In section 6 in the paragraph after the bullet points possibly possibly 3. In section 7 This specification requires IANA to create two new registries I think there are three new registries. 4. In section 7.1 second paragraph registry registry
Gen-ART LC review of draft-daboo-ical-vcard-parameter-encoding-02
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-daboo-ical-vcard-parameter-encoding-02 Reviewer: Roni Even Review Date:2012-12-17 IETF LC End Date: 2012-12-14 IESG Telechat date: Summary: This draft is ready for publication as Standard track RFC. Major issues: Minor issues: Nits/editorial comments:
Gen-ART LC review of draft-ietf-appsawg-json-patch-08
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-appsawg-json-patch-08 Reviewer: Roni Even Review Date:2012-12-16 IETF LC End Date: 2012-12-25 IESG Telechat date: 2013-1-10 Summary: This draft is almost ready for publication. Major issues: Minor issues: 1. The document has as the intended status Informational while the last call says that the intended status is proposed standard? Nits/editorial comments: 1. In the IANA section the Encoding considerations: binary. I noticed that RFC 4627 has a broader description: Encoding considerations: 8bit if UTF-8; binary if UTF-16 or UTF-32 JSON may be represented using UTF-8, UTF-16, or UTF-32. When JSON is written in UTF-8, JSON is 8bit compatible. When JSON is written in UTF-16 or UTF-32, the binary content-transfer-encoding must be used.
Gen-ART LC review of draft-leiba-5322upd-from-group-06
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-leiba-5322upd-from-group-06 Reviewer: Roni Even Review Date:2012-10-17 IETF LC End Date: 2012-11-6 IESG Telechat date: Summary: This draft is almost ready for publication as a standard track RFC. Major issues: Minor issues: 1. It is not clear from the draft what the use case for using the group construct is. Section 3 talks about the issues with using the group construct and recommend limited use, but this is the only information. 2. Section 2.1 says If the sender field uses group syntax, the group MUST NOT contains more than one mailbox. Why use a group name for a single mailbox? Nits/editorial comments:
RE: Gen-ART LC review of draft-ietf-ccamp-rfc5787bis-05
Andy, Thanks Roni From: Malis, Andrew G (Andy) [mailto:andrew.g.ma...@verizon.com] Sent: 09 October, 2012 2:55 AM To: Roni Even; draft-ietf-ccamp-rfc5787bis@tools.ietf.org Cc: ietf@ietf.org; gen-...@ietf.org; Malis, Andrew G (Andy) Subject: Re: Gen-ART LC review of draft-ietf-ccamp-rfc5787bis-05 Roni, Thanks for your review, and sorry for the delay on the response, but we've also been working on incorporating other changes to the draft as well. To answer your question on section 6.1, that was a good catch. That should have said other than the first, rather than preceding the first. This will be corrected. To answer your question on section 10, the text is repeated in the subsections to make life easier for IANA, since they would probably have replicated it themselves anyway in the three registry listings. On your last comment, we agree with you that the more familiar reader will not have a problem. Thanks again, Andy From: Roni Even ron.even@gmail.com Date: Monday, August 13, 2012 14:07 To: draft-ietf-ccamp-rfc5787bis@tools.ietf.org draft-ietf-ccamp-rfc5787bis@tools.ietf.org Cc: ietf@ietf.org ietf@ietf.org, gen-...@ietf.org gen-...@ietf.org Subject: Gen-ART LC review of draft-ietf-ccamp-rfc5787bis-05 Resent-To: acee.lin...@ericsson.com, Adrian Farrell adr...@olddog.co.uk, Andrew Malis andrew.g.ma...@verizon.com, dbrung...@att.com, dimitri.papadimitr...@alcatel-lucent.com, lber...@labn.net 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-ccamp-rfc5787bis-05. Reviewer: Roni Even Review Date:2012-8-12 IETF LC End Date: 2012-8-17 IESG Telechat date: Summary: This draft is almost ready for publication as a standard track RFC. Major issues: Minor issues: In section 6.1 If specified more than once, instances preceding the first will be ignored and condition SHOULD be logged for possible action by the network operator. I am not sure what is meant by preceding the first. Nits/editorial comments: 1. The following note appears in section 10.1, 10.2 and 10.3. Note that the same values for the Inter-RA Export Upward sub-TLV and the Inter-RA Export Downward Sub-TLV MUST be used when they appear in the Link TLV, Node Attribute TLV, and Router Address TLV. - why not have it in section 10 before section 10.1. 2. I saw in appendix B that one of the changes from RFC 5787 was to clarify the terminology before defining extensions, I would have found it easier to read if the ASON hierarchy and the relation to OSPF in section 2 were presented in figures. This was more an issue to me as a reader not familiar with the terminology and I would like to think that the more familiar reader will not have problem.
RE: Gen-ART LC review of draft-ietf-ccamp-rfc5787bis-05
Andy, Thanks, I am OK Roni From: Malis, Andrew G (Andy) [mailto:andrew.g.ma...@verizon.com] Sent: 09 October, 2012 2:55 AM To: Roni Even; draft-ietf-ccamp-rfc5787bis@tools.ietf.org Cc: ietf@ietf.org; gen-...@ietf.org; Malis, Andrew G (Andy) Subject: Re: Gen-ART LC review of draft-ietf-ccamp-rfc5787bis-05 Roni, Thanks for your review, and sorry for the delay on the response, but we've also been working on incorporating other changes to the draft as well. To answer your question on section 6.1, that was a good catch. That should have said other than the first, rather than preceding the first. This will be corrected. To answer your question on section 10, the text is repeated in the subsections to make life easier for IANA, since they would probably have replicated it themselves anyway in the three registry listings. On your last comment, we agree with you that the more familiar reader will not have a problem. Thanks again, Andy From: Roni Even ron.even@gmail.com Date: Monday, August 13, 2012 14:07 To: draft-ietf-ccamp-rfc5787bis@tools.ietf.org draft-ietf-ccamp-rfc5787bis@tools.ietf.org Cc: ietf@ietf.org ietf@ietf.org, gen-...@ietf.org gen-...@ietf.org Subject: Gen-ART LC review of draft-ietf-ccamp-rfc5787bis-05 Resent-To: acee.lin...@ericsson.com, Adrian Farrell adr...@olddog.co.uk, Andrew Malis andrew.g.ma...@verizon.com, dbrung...@att.com, dimitri.papadimitr...@alcatel-lucent.com, lber...@labn.net 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-ccamp-rfc5787bis-05. Reviewer: Roni Even Review Date:2012-8-12 IETF LC End Date: 2012-8-17 IESG Telechat date: Summary: This draft is almost ready for publication as a standard track RFC. Major issues: Minor issues: In section 6.1 If specified more than once, instances preceding the first will be ignored and condition SHOULD be logged for possible action by the network operator. I am not sure what is meant by preceding the first. Nits/editorial comments: 1. The following note appears in section 10.1, 10.2 and 10.3. Note that the same values for the Inter-RA Export Upward sub-TLV and the Inter-RA Export Downward Sub-TLV MUST be used when they appear in the Link TLV, Node Attribute TLV, and Router Address TLV. - why not have it in section 10 before section 10.1. 2. I saw in appendix B that one of the changes from RFC 5787 was to clarify the terminology before defining extensions, I would have found it easier to read if the ASON hierarchy and the relation to OSPF in section 2 were presented in figures. This was more an issue to me as a reader not familiar with the terminology and I would like to think that the more familiar reader will not have problem.
Gen-ART LC review of draft-ietf-6man-dad-proxy-05
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-6man-dad-proxy-05 Reviewer: Roni Even Review Date:2012-9-25 IETF LC End Date: 2012-10-3 IESG Telechat date: Summary: This draft is ready for publication as a standard track RFC. Major issues: Minor issues: Nits/editorial comments: 1. In section 3.1 Duplicate Address Dectection should be Duplicate Address Detection.
RE: Proposed IETF Meeting Calendar 2018 - 2022
Hi, One request about IETF 110 21 - 26 March 2021. March 27 is Jewish Passover (Pesach) so the 26th will not work for those who observe this major Holiday Roni Even From: wgchairs-boun...@ietf.org [wgchairs-boun...@ietf.org] on behalf of IETF Administrative Director [i...@ietf.org] Sent: Thursday, September 06, 2012 10:15 PM To: IETF Announcement List Cc: i...@ietf.org; i...@iab.org; ietf@ietf.org; wgcha...@ietf.org Subject: Proposed IETF Meeting Calendar 2018 - 2022 All; Below are suggested Meeting dates for 2018 - 2022, IETF's 101 - 115. The IAOC is soliciting the community's feedback before adopting. Comments appreciated to ietf@ietf.org by 20 September 2012. Ray 2018 IETF 10118-23 March 2018 IETF 10222-27 July 2018 IETF 1034 - 9 November 2018 2019 IETF 10424 - 29 March 2019 IETF 10521 - 26 July 2019 IETF 10617 - 22 November 2019 2020 IETF 10722 - 27 March 2020 IETF 10826 - 31 July 2020 IETF 10915 - 20 November 2020 2021 IETF 11021 - 26 March 2021 IETF 11125 - 30 July 2021 IETF 1127 - 12 November 2021 2022 IETF 11320 - 25 March 2022 IETF 11424 - 29 July 2022 IETF 1156 - 11 November 2022
Gen-ART LC review of draft-ietf-sieve-imap-sieve-06
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-sieve-imap-sieve-06 Reviewer: Roni Even Review Date:2012-8-22 IETF LC End Date: 2012-8-29 IESG Telechat date: Summary: This draft is ready for publication as a standard track RFC. Major issues: Minor issues: Nits/editorial comments: 1. At the end of section 3.7 and 3.8 acton should be action
Gen-ART LC review of draft-ietf-ccamp-rfc5787bis-05
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-ccamp-rfc5787bis-05. Reviewer: Roni Even Review Date:2012-8-12 IETF LC End Date: 2012-8-17 IESG Telechat date: Summary: This draft is almost ready for publication as a standard track RFC. Major issues: Minor issues: In section 6.1 If specified more than once, instances preceding the first will be ignored and condition SHOULD be logged for possible action by the network operator. I am not sure what is meant by preceding the first. Nits/editorial comments: 1. The following note appears in section 10.1, 10.2 and 10.3. Note that the same values for the Inter-RA Export Upward sub-TLV and the Inter-RA Export Downward Sub-TLV MUST be used when they appear in the Link TLV, Node Attribute TLV, and Router Address TLV. - why not have it in section 10 before section 10.1. 2. I saw in appendix B that one of the changes from RFC 5787 was to clarify the terminology before defining extensions, I would have found it easier to read if the ASON hierarchy and the relation to OSPF in section 2 were presented in figures. This was more an issue to me as a reader not familiar with the terminology and I would like to think that the more familiar reader will not have problem.
GenART LC review of draft-ietf-ipfix-ie-doctors-03
Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-ipfix-ie-doctors-03. Reviewer: Roni Even Review Date:2012-7-15 IETF LC End Date: 2012-7-17 IESG Telechat date: Summary: This draft is almost ready for publication as an Informational RFC. Major issues: Minor issues: 1. The registration procedure should mention NetFlow V9 expert review for 0-128. I think that in the IANA section it will be good to suggest update also for the Registration procedure and Reference of the IPFIX Information Elements registry. 2. Section 5.1 should reference RFC5226 and say if it clarifies RFC5226 or adds some procedure. 3. In section 5.2 is there a need for a specification to explain the change. The text is not clear about it. 4. Section 5.3 say Names of deprecated or obsolete Information Elements MUST NOT be reused. What about the elementID can it be re-used? Nits/editorial comments: 1. Section 4.2 third paragraph applications can to use reduced-size should be applications can use reduced-size 2. Section 4.8 first paragraph enumerates those which Information Elements should be enumerates those Information Elements 3. In section 10.1 these are described in and Section 10.3 I did not understand the in and, I assume something is missing here.
genART review of draft-claise-export-application-info-in-ipfix-09
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-claise-export-application-info-in-ipfix-09 Reviewer: Roni Even Review Date:2012-7-15 IETF LC End Date: 2012-7-19 IESG Telechat date: Summary: This draft is ready for publication as an Informational RFC. Major issues: Minor issues:
GenART LC review of draft-hoffman-tao-as-web-page-02
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-hoffman-tao-as-web-page-02 Reviewer: Roni Even Review Date:2012-6-28 IETF LC End Date: 2012-7-13 IESG Telechat date: Summary: This draft is ready for publication as an Informational RFC. Major issues: Minor issues: In the section 2 the second sentence is The initial content for the Tao web page will come from the last Internet-Draft that was meant to replace RFC 4677.. I was wondering if this information is important to this document when published. If it is maybe rephrase it to The initial content for the Tao web page is based on the last Internet-Draft that was meant to replace RFC 4677. I also suggest that maybe it will be good to have an informative reference to it. Nits/editorial comments: 1. Section 1 second paragraph led instead of lead 2. Section 2 third paragraph proposed instead of propsed
RE: GenART LC review of draft-ietf-nea-pt-tls-05
Hi, I am OK with your responses. The only thing I am not sure is about using PEN 0 defined in the registry. Decimal | Organization | | Contact | | | Email | | | | 0 Reserved Internet Assigned Numbers Authority ianaiana.org I was wondering how this enterprise number should be specified since it appears as Reserved in the registry. I have no specific suggestion Roni From: Paul Sangster [mailto:paul_sangs...@symantec.com] Sent: Wednesday, June 13, 2012 7:56 PM To: Roni Even; draft-ietf-nea-pt-tls@tools.ietf.org Cc: 'IETF'; gen-...@ietf.org; n...@ietf.org Subject: RE: GenART LC review of draft-ietf-nea-pt-tls-05 Thanks for the detailed review, comments are in-lined. From: Roni Even [mailto:ron.even@gmail.com] Sent: Monday, June 04, 2012 2:20 PM To: draft-ietf-nea-pt-tls@tools.ietf.org Cc: 'IETF'; gen-...@ietf.org Subject: GenART LC review of draft-ietf-nea-pt-tls-05 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-nea-pt-tls-05 Reviewer: Roni Even Review Date:2012-6-4 IETF LC End Date: 2012-6-13 IESG Telechat date: Summary: This draft is almost ready for publication as a standard track RFC. Major issues: Minor issues: 1. In section 3.2 Therefore, this specification requests the IANA reserve a TCP port number for use with the PT-TLS protocol upon publication of this specification as an Internet standard RFC. I think it will be better to have here the assigned port number and instruct the RFC editor to put the correct value. [PS:] Ok, we can reword this in hopes of getting a particular value (race condition with other upcoming RFCs). 2. In section 3.4.2.2 last paragraph you summarize the text from section 3.8 while in the paragraph above you provide the reference. Why do you need the last paragraph if 3.8 is referenced. [PS:] The goal of this section is to introduce and summarize the different phases of PT-TLS. We felt a brief discussion of the general message flow was helpful to the reader to understand what occurs during this phase (similar to what we did in the other sub-sections). Your correct that this information is covered later in more detail. 3. In various places you refer to SMI 0 as IETF SMI number while according to the table it is IANA SMI number. [PS:] I presume this is about the PEN 0 being for the IETF. Correct, it's the IETF's name space that administered by the IANA. What text would you like to see to make this more clear? Can we do it in one place, for example stating that the IETF name space is administered by the IANA? 4. I assume that all implementations MUST support message type vendor ID 0. Is this mentioned? [PS:] The purpose of this section was just to summarize and enumerate the message types for vendor id 0. I don't think it's a general rule that any message type defined in the IETF (IANA J) name space must (or should be) supported by all implementations. It will vary depending on the purpose of the message so that normative language is included in the descriptions of the message. 5. In section 3.5 and 6.1 you propose a policy of Expert Review with Specification Required . I think that according to RFC5226 expert review is implied if you select a specification required policy. [PS:] I agree, it says Specification Required also implies use of a Designated Expert. The policy is just Specification Required so we could remove the Expert Review with and make it clear it's the Specification Required IANA policy. 6. In section 3.6 on 9+ Recipients of messages of type 9 or higher that do not support the PT-TLS Message Type Vendor ID and PT-TLS Message Type of a received PT-TLS message MUST respond with a Type Not Supported PT-TLS error code in a PT-TLS Error message. I think this is true only for Message Type Vendor ID 0. [PS:] Thanks will reword this section to make it more clear. 7. In 3.7.1 for Max vers and prefs ver you say that they MUST be set to 1. I think it will be more correct here to say SHOULD since you explain afterwards that they may have other values. [PS:] I think this is a MUST. The next sentence just points out that this normative text might change in a future revision (which is not currently planned). 8. In section 3.7.2 the recipient SHOULD send. Why not make it a MUST here. [PS:] I ok with making this change, let's see what others think . 9. In section 3.7.2 The version selected MUST be within the Min Vers to Max Vers inclusive range sent in the Version Request Message I was expecting to see pref ver here. [PS:] Perf is just an informational (hint) preference. 10. In section 3.8.3 The SASL client authentication starts when the NEA
GenART LC review of draft-ietf-nea-pt-tls-05
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-nea-pt-tls-05 Reviewer: Roni Even Review Date:2012-6-4 IETF LC End Date: 2012-6-13 IESG Telechat date: Summary: This draft is almost ready for publication as a standard track RFC. Major issues: Minor issues: 1. In section 3.2 Therefore, this specification requests the IANA reserve a TCP port number for use with the PT-TLS protocol upon publication of this specification as an Internet standard RFC. I think it will be better to have here the assigned port number and instruct the RFC editor to put the correct value. 2. In section 3.4.2.2 last paragraph you summarize the text from section 3.8 while in the paragraph above you provide the reference. Why do you need the last paragraph if 3.8 is referenced. 3. In various places you refer to SMI 0 as IETF SMI number while according to the table it is IANA SMI number. 4. I assume that all implementations MUST support message type vendor ID 0. Is this mentioned? 5. In section 3.5 and 6.1 you propose a policy of Expert Review with Specification Required . I think that according to RFC5226 expert review is implied if you select a specification required policy. 6. In section 3.6 on 9+ Recipients of messages of type 9 or higher that do not support the PT-TLS Message Type Vendor ID and PT-TLS Message Type of a received PT-TLS message MUST respond with a Type Not Supported PT-TLS error code in a PT-TLS Error message. I think this is true only for Message Type Vendor ID 0. 7. In 3.7.1 for Max vers and prefs ver you say that they MUST be set to 1. I think it will be more correct here to say SHOULD since you explain afterwards that they may have other values. 8. In section 3.7.2 the recipient SHOULD send. Why not make it a MUST here. 9. In section 3.7.2 The version selected MUST be within the Min Vers to Max Vers inclusive range sent in the Version Request Message I was expecting to see pref ver here. 10. In section 3.8.3 The SASL client authentication starts when the NEA Server enters the PT-TLS Negotiation phase and its policy indicates that an authentication of the NEA Client is necessary but was not performed during the TLS handshake protocol my read of section 3.8 second paragraph is that it can be done even if was done in the TLS handshake so the last part of the sentence is not correct, if there is a policy you do it anyhow. This comment is also for the third paragraph. 11. In section 3.9 I noticed that you propose to send the entire original message. Isn't it enough to send only the message identifier. This is based on the last sentence of this section. 12. Most of the text in section 6.1 repeats RFC5226 but in your words. Are you trying to change some of RFC5226 text if not why write it in different words? Nits/editorial comments:
RE: Gen-ART LC review of draft-claise-export-application-info-in-ipfix-05
Hi Benoit, Your proposals are OK with me Roni From: Benoit Claise [mailto:bcla...@cisco.com] Sent: Wednesday, May 30, 2012 2:11 AM To: Roni Even Cc: draft-claise-export-application-info-in-ipfix@tools.ietf.org; gen-...@ietf.org; 'IETF'; me Subject: Re: Gen-ART LC review of draft-claise-export-application-info-in-ipfix-05 Hi Roni, [keeping only the open discussions] Hi Benoit, Thanks, see in-line Roni 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-claise-export-application-info-in-ipfix-05 Reviewer: Roni Even Review Date:2012-4-7 IETF LC End Date: 2012-4-17 IESG Telechat date: Summary: This draft is almost ready for publication as an Informational RFC. Major issues: Minor issues: In sections 2, 4.1 (PANA-L7), 5, 6.5 the draft points to information in Cisco web page. I could not locate and information that is referenced. The link is to the main Cisco web page. For example in section 6.5 it lists the selectorID as 1, where is this value located? The exact URsL are http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6555/ps6601/pre sentation_c96-629396.html and http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6558/ps6616/pro duct_bulletin_c25-627831.html As you can see from the URLs, there is a chance that those might change. Stephen Farrell had the same comment. RE: My concern was that going to Cisco web page I tried to search for the information using the search window and could not find it so I think that this link is not helpful for finding the information. Understood. We propose 1. to remove all references to [CISCO] in the draft, except in the appendix 2. to add the following text Appendix X (non normative) A reference to the Cisco Systems assigned numbers for the Application Id and the different attribute assignments can be found at [CISCO http://tools.ietf.org/html/draft-claise-export-application-info-in-ipfix-07 #ref-CISCO ]. [CISCO-APPLICATION-REGISTRY] http://www.cisco.com/go/application-registry 3. However, it will take a couple of days to set up this new URL. So we propose to add RFC-EDITOR NOTE: at the time of publication, if the [CISCO-APPLICATION-REGISTRY] is not available, this appendix must be removed Does it work for you? In section 7 I noticed that p2pTechnology, tunnelTechnology, and encryptedTechnology are already assigned in the IANA IPFIX Information elements so why assign them again as new? from RFC5102: The value of these identifiers is in the range of 1-32767. Within this range, Information Element identifier values in the sub-range of 1-127 are compatible with field types used by NetFlow version 9 [RFC3954 http://tools.ietf.org/html/rfc3954 ]. So basically, if Cisco has assigned those numbers already, they can reused in IANA. RE: The question is if you want the existing assignment to be used without change than why have this information in the IANA consideration in the first place. Because the IANA registry currently contain reserved for the corresponding IEs See 100-127 Reserved at http://www.iana.org/assignments/ipfix/ipfix.xml In section 7 I noticed that you request that the applicationDescription, applicationId, applicationName, classificationEngineId will receive elementid values from the range 0-127. My reading from section 4.2 is this is not required, maybe add text that will explain this request. See my previous remark. RE: OK, even though it should be clear that this applies to these specific selectors since you want them to be compatible with NetFlow version 9 and it is not a general request for using specific sub range for all selectors. Nits/editorial comments: 1. In section 4.1 last sentence what is the meaning of by theses specifications , I did not understand the context. 2. In section 6.6 to determine whether or the default HTTP port delete the or In section 6.6 The Classification Engine ID is 2 should be 3. All corrected in to-be-posted-version. Regards, Benoit. will be corrected. Thanks again. Regards, Benoit.
RE: Gen-ART LC review of draft-claise-export-application-info-in-ipfix-05
Hi Benoit, Thanks, see in-line Roni 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-claise-export-application-info-in-ipfix-05 Reviewer: Roni Even Review Date:2012-4-7 IETF LC End Date: 2012-4-17 IESG Telechat date: Summary: This draft is almost ready for publication as an Informational RFC. Major issues: Minor issues: In sections 2, 4.1 (PANA-L7), 5, 6.5 the draft points to information in Cisco web page. I could not locate and information that is referenced. The link is to the main Cisco web page. For example in section 6.5 it lists the selectorID as 1, where is this value located? The exact URsL are http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6555/ps6601/pre sentation_c96-629396.html and http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6558/ps6616/pro duct_bulletin_c25-627831.html As you can see from the URLs, there is a chance that those might change. Stephen Farrell had the same comment. RE: My concern was that going to Cisco web page I tried to search for the information using the search window and could not find it so I think that this link is not helpful for finding the information. For the definition of Classification engine IDs in section 4.1 for the non standard values like PANA-L3, PANA-L4, PANA-L7, PANA-L2, is there a requirement that the selector IDs will be publically available? Yes. Also, they would be exported with an IPFIX Options Template Record. An example of PANA-L3 was the IPFIX port, 4739, which was pre-reserved by IANA, 3 years before RFC5101 was published. RE: OK In section 4.2 However, an IANA L3 protocol encoding may encoded with 3 bytes. When is it encoded in 3 bytes, also figure 2 is not reflecting this example, I expected to see a 32 bit value according to the text and not a general figure. (small nit in the above sentence may be instead of may. Will be corrected. RE:OK In section 7 I noticed that p2pTechnology, tunnelTechnology, and encryptedTechnology are already assigned in the IANA IPFIX Information elements so why assign them again as new? from RFC5102: The value of these identifiers is in the range of 1-32767. Within this range, Information Element identifier values in the sub-range of 1-127 are compatible with field types used by NetFlow version 9 [RFC3954 http://tools.ietf.org/html/rfc3954 ]. So basically, if Cisco has assigned those numbers already, they can reused in IANA. RE: The question is if you want the existing assignment to be used without change than why have this information in the IANA consideration in the first place. In section 7 I noticed that you request that the applicationDescription, applicationId, applicationName, classificationEngineId will receive elementid values from the range 0-127. My reading from section 4.2 is this is not required, maybe add text that will explain this request. See my previous remark. RE: OK, even though it should be clear that this applies to these specific selectors since you want them to be compatible with NetFlow version 9 and it is not a general request for using specific sub range for all selectors. In the security section are there additional considerations when the applicationid information is coming from a proprietary classification engine about authentication of the information source? Not as far as I know. Maybe I'm missing something. Can you please elaborate. RE: No, this is OK for me. Nits/editorial comments: 1. In section 4.1 last sentence what is the meaning of by theses specifications , I did not understand the context. 2. In section 6.6 to determine whether or the default HTTP port delete the or In section 6.6 The Classification Engine ID is 2 should be 3. will be corrected. Thanks again. Regards, Benoit.
Gen-ART LC review of draft-melnikov-smtp-priority-13
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-melnikov-smtp-priority-13 Reviewer: Roni Even Review Date:2012-5-20 IETF LC End Date: 2012-5-28 IESG Telechat date: Summary: This draft is ready for publication as a standard track RFC. Major issues: Minor issues: Nits/editorial comments: 1. MUA is used but not expanded.
Gen-ART LC review of draft-ietf-ancp-pon-02
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. Sorry for the late review due to IET meeting. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-ancp-pon-02 Reviewer: Roni Even Review Date:2012-4-1 IETF LC End Date: 2012-3-30 IESG Telechat date: Summary: This draft is ready for publication as an Informational RFC. Major issues: Minor issues: Nits/editorial comments: In section 4 However, the broadcast capability on the PON enables the AN (OLT) to send one copy on the PON as opposed to N copies of a multicast channel on the PON serving N premises being receivers I think the being before the last word should be deleted General editorial comment is about page breaks which can be better like section 7 title is at the end of a page and the text is in the next page. Also some of the figures and their descriptions are split between pages.
RE: [AVTCORE] IPR requirements in document write-up
in that it appears (at least to me) to interpret the IETF's patent policy in a considerably more strict way than it is set out in the policy RFCs. I believe the IESG should reconsider the proto writeup. A few more comments inline On 3.21.2012 17:03 , Barry Leiba barryle...@computer.org wrote: Thanks for the text, I will use it. Roni I recommend you do not, for a few reasons: 1. You may not rewrite the PROTO template; that belongs to the IESG. Agreed (now that I'm aware of that this is an IESG-sanctioned template). 2. The question was worded as it is for a reason, and it should be left that way. The IESG wants to know whether there are any known IPR claims, whether declarations have been made to and considered by the working group, and whether formal IPR statements have been filed in the system. The middle one is as important as the last. Also agreed (with caveats, see below). 3. Stephan is incorrect when he says this: The reason is that disclosure is not required in many cases; for example, when the IPR in question is not owned by them or their employers. If you are aware of IPR that you do not own, you may and you should make a third-party disclosure. Barry, please read my language carefully. Perhaps I should have capitalized REQUIRED, but the text is clear and inline with yours. It's MAY and SHOULD for third party disclosures. But you are NOT *required* to do so by policy; there is no MUST. There are many good and valid reasons why there is no MUST (beyond that it's not in the policy docs). And, third party disclosures are not even a widely used current practice. Just look at the (comparatively low) number of third party disclosures. Look, I do patent work as my day job. I also do standards work In my current and previous job roles, I have looked at hundreds of patents of my current or previous employers, as well as occasionally at third party patents. Now, with this background, let's look at the template text again (numerals by me): (1) Are you aware of any IPR that applies to insert document name? (2) If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? For the majority of the documents I am working on, the answer to question (1) would be yes. The answer to question (2) would be quite often no. Based on my interpretation of the policy RFCs, I am in full compliance with language and spirit of the policy. I'm not doing anything fishy. I just don't talk about third party IPR, which is my right under the IETF's IPR policy. However, by providing answers to questions (1) and (2), the IESG would receive a signal that it is not entitled to receive (more precisely: that I'm not required to send, and not willing to send voluntarily, as it could get me personally into trouble), namely that there may be patents related to a document which the discloser is not willing, AND not obligated, to talk about. This is a policy change through the backdoor. Policy changes through the backdoor are bad. My suggestion was aimed to bring the template in compliance with what I believe is language and spirit of the policy. Thanks, Stephan You may, of course, ask the question of your working group in any way you like. But I suggest you ask it in a way that allows you to accurately answer the question asked in the PROTO template. Barry, incoming Applications AD Original Message From: Stephan Wenger [mailto:st...@stewe.org] Sent: Sunday, March 18, 2012 7:03 PM To: Roni Even; 'IETF AVTCore WG'; payl...@ietf.org Cc: 'Magnus Westerlund' Subject: Re: [AVTCORE] (no subject) Hi, There are many cases, where the answer to the first question is Yes, the answer to the second question is No, and people would still be in compliance with the assorted policy RFCs. The reason is that disclosure is not required in many cases; for example, when the IPR in question is not owned by them or their employers. Suggest that the second question should be something like: If so, has this IPR been disclosed when so required for in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? Stephan From: Roni Even ron.even@gmail.com Date: Sun, 18 Mar 2012 18:33:53 +0200 To: 'IETF AVTCore WG' a...@ietf.org, payl...@ietf.org Cc: 'Magnus Westerlund' magnus.westerl...@ericsson.com Subject: [AVTCORE] (no subject) Hi, The document write-up template for sending documents to publication has changed. In particular, we need to poll authors on their compliance with IETF IPR rules prior to moving a document to the publication in the WG process. See http://www.ietf.org/iesg/template/doc-writeup.html question 7. We plan to send the following email when a WG document
GenART last call review of draft-ietf-behave-nat64-learn-analysis-03
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-behave-nat64-learn-analysis-03 Reviewer: Roni Even Review Date:2012-3-13 IETF LC End Date: 2012-3-22 IESG Telechat date: Summary: This draft is ready for publication as an Informational RFC. Major issues: Minor issues: Nits/editorial comments: Section 5.1.1 third paragraph change to provided by some ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-melnikov-smtp-priority-09
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-melnikov-smtp-priority-09 Reviewer: Roni Even Review Date:2012-3-13 IETF LC End Date: 2012-3-28 IESG Telechat date: Summary: This draft is almost ready for publication as a standard track RFC. Major issues: Minor issues: 1. In section 4.2 In absence of both the MT-PRIORITY MAIL FROM parameter and the MT-Priority header field, other message header fields, such as Priority [RFC2156] and X-Priority, MAY be used for determining the priority under this Priority Message Handling SMTP extension. . My understanding from the third bullet in this section is that for this case the message priority is 0 so I am not clear what this sentence means and why is there a difference if the MT-PRIORITY or MT-Priority values do exist with regards to Priority and X-Priority for this case. 2. In section 8 MT-PRIORITY=3. I did not see where the MT-PRIORITY SMTP extension is specified and has the syntax of using = before the value. Nits/editorial comments: 1. MUA is used in section 1 but expanded only in section 5. 2. Some typos in section 5. syntatically - syntactically prioritiy - priority comminicate - communicate contraints -constraints 3. In section 10 for X.3.TBD3 Description: The message mas accepted I assume you meant was 4. In section D.2 first paragraph some typos focusses -focuses comparision - comparison ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-ietf-pcn-3-in-1-encoding-08
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-pcn-3-in-1-encoding-08 Reviewer: Roni Even Review Date:2012-2-23 IETF LC End Date: 2012-2-23 IESG Telechat date: Summary: This draft is ready for publication as a Standards Track RFC. Major issues: Minor issues: Nits/editorial comments: Section 1 4th paragraph tunnelling ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-ietf-dnsext-ecdsa-04
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-dnsext-ecdsa-04 Reviewer: Roni Even Review Date:2012-1-29 IETF LC End Date: 2012-2-7 IESG Telechat date: Summary: This draft is almost ready for publication as an Informational RFC. Major issues: The first IANA action is to update http://www.iana.org/assignments/ds-rr-types/ds-rr-types.txt which requires standard action for adding values. Minor issues: The important note in section 6 talks about the values in the examples. I am wondering why not update the document with the correct values after the IANA assignments by the RFC editor. Nits/editorial comments: ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-harkins-ipsecme-spsk-auth-06
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-harkins-ipsecme-spsk-auth-06 Reviewer: Roni Even Review Date:2012-1-24 IETF LC End Date: 2012-2-14 IESG Telechat date: Summary: This draft is ready for publication as an Experimental RFC. Major issues: Minor issues: Nits/editorial comments: 1. Section 2 bullet 3 Securty? 2. In section 4.1 The inverse function is defined such that the sum of an element and its inverse is 0: . This looks like a zero to me and I assume you meant the letter o ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART LC review of draft-kompella-l2vpn-l2vpn-07
Hi, I am OK with minor issue 2 now. Issue 3 was my only point Roni -Original Message- From: Kireeti Kompella [mailto:kire...@juniper.net] Sent: Friday, January 13, 2012 7:36 PM To: Roni Even Cc: Kireeti Kompella; draft-kompella-l2vpn-l2vpn@tools.ietf.org; gen-...@ietf.org; IETF-Discussion list Subject: Re: Gen-ART LC review of draft-kompella-l2vpn-l2vpn-07 On Jan 12, 2012, at 23:16 , Roni Even wrote: Hi, I looked at the 08 version and the major issues are addressed. What about minor issue number 3? Good point! I will fix (as Stewart suggests, maybe just remove the reference). To your minor issue (2), I've clarified the structure. Do you still want to see how it fits into the NLRI? Thanks, Kireeti. Roni Even -Original Message- From: Kireeti Kompella [mailto:kire...@juniper.net] Sent: Friday, September 16, 2011 10:23 PM To: Roni Even Cc: Kireeti Kompella; draft-kompella-l2vpn-l2vpn@tools.ietf.org; gen-...@ietf.org; IETF-Discussion list Subject: Re: Gen-ART LC review of draft-kompella-l2vpn-l2vpn-07 Hi Roni, On Sep 7, 2011, at 4:37 , 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. Thanks! Please resolve these comments along with any other Last Call comments you may receive. Document: draft-kompella-l2vpn-l2vpn-07 Reviewer: Roni Even Review Date: 2011-9-7 IETF LC End Date: 2011-9-27 IESG Telechat date: Summary: This draft is not ready for publication as an informational RFC. Major issues: The IANA considerations section says: the values already allocated are in Table 1 of Section 4. The allocation policy for new entries up to and including value 127 is Standards Action. The allocation policy for values 128 through 251 is First Come First Served. The values from 252 through 255 are for Experimental Use. Standards Action will be changed to Expert Review. Yet this is document is intended for Informational status which contradict the standard action. This is also true for the second registry defined. Is this document really an Informational one? My only comment is that it is not Historic. Minor issues: 1. In section 1.2.2 Since traditional Layer 2 VPNs (i.e., real Frame Relay circuits connecting sites) are indistinguishable from tunnel-based VPNs from the customer's point-of-view, migrating from one to the other raises few issues. What are the few issues? A subtlety: few issues means not many, not deep; it's a careful way of saying, just about no issues. A few issues would require elaboration. 2. In section 4 L2VPN TLVs can be added to extend the information carried in the NLRI, using the format shown in Figure 2. How is the TLV carried in the NLRI, in which field, section 4.1 only talk about the structure of the TLV. I'll take the figure from 3.2.2 of RFC 4761 and show where the TLVs go. 3. Section 4.2 refers to section 4 but I am not sure where this mechanism in section 4 is. Will clarify. Nits/editorial comments: 1. Section 3.1 is called network topology but the whole text is an example of a network topology. Maybe the title should be Example of a network toplogy. Sure. 2. Section 5 starts with As defined so far in the document .. But the using IP only is already discussed in previous sections. Do you have a suggestion for rewording? Thanks, Kireeti. ATT1..txt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART LC review of draft-kompella-l2vpn-l2vpn-07
Hi, I looked at the 08 version and the major issues are addressed. What about minor issue number 3? Roni Even -Original Message- From: Kireeti Kompella [mailto:kire...@juniper.net] Sent: Friday, September 16, 2011 10:23 PM To: Roni Even Cc: Kireeti Kompella; draft-kompella-l2vpn-l2vpn@tools.ietf.org; gen-...@ietf.org; IETF-Discussion list Subject: Re: Gen-ART LC review of draft-kompella-l2vpn-l2vpn-07 Hi Roni, On Sep 7, 2011, at 4:37 , 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. Thanks! Please resolve these comments along with any other Last Call comments you may receive. Document: draft-kompella-l2vpn-l2vpn-07 Reviewer: Roni Even Review Date: 2011-9-7 IETF LC End Date: 2011-9-27 IESG Telechat date: Summary: This draft is not ready for publication as an informational RFC. Major issues: The IANA considerations section says: the values already allocated are in Table 1 of Section 4. The allocation policy for new entries up to and including value 127 is Standards Action. The allocation policy for values 128 through 251 is First Come First Served. The values from 252 through 255 are for Experimental Use. Standards Action will be changed to Expert Review. Yet this is document is intended for Informational status which contradict the standard action. This is also true for the second registry defined. Is this document really an Informational one? My only comment is that it is not Historic. Minor issues: 1. In section 1.2.2 Since traditional Layer 2 VPNs (i.e., real Frame Relay circuits connecting sites) are indistinguishable from tunnel-based VPNs from the customer's point-of-view, migrating from one to the other raises few issues. What are the few issues? A subtlety: few issues means not many, not deep; it's a careful way of saying, just about no issues. A few issues would require elaboration. 2. In section 4 L2VPN TLVs can be added to extend the information carried in the NLRI, using the format shown in Figure 2. How is the TLV carried in the NLRI, in which field, section 4.1 only talk about the structure of the TLV. I'll take the figure from 3.2.2 of RFC 4761 and show where the TLVs go. 3. Section 4.2 refers to section 4 but I am not sure where this mechanism in section 4 is. Will clarify. Nits/editorial comments: 1. Section 3.1 is called network topology but the whole text is an example of a network topology. Maybe the title should be Example of a network toplogy. Sure. 2. Section 5 starts with As defined so far in the document .. But the using IP only is already discussed in previous sections. Do you have a suggestion for rewording? Thanks, Kireeti. ATT1..txt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART last call review of draft-ietf-dhc-vpn-option-14
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-dhc-vpn-option-14 Reviewer: Roni Even Review Date: 2012-1-1 IETF LC End Date: 2012-1-4 IESG Telechat date: 2012-1-5 Summary: This draft is ready for publication as a standard RFC. Major issues: Minor issues: Nits/editorial comments: 1. In section 3.2 Type and VSS Information -- see Section 35 should be 3.5 2. In section 3.3 This sub-option only only 3. In 3.5 last bullet not clear - and the length of the MUST be 1. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART last call review of draft-ietf-trill-rbridge-mib
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-trill-rbridge-mib-04 Reviewer: Roni Even Review Date: 2011-11-20 IETF LC End Date: 2011-11-29 IESG Telechat date: 2011-12-1 Summary: This draft is ready for publication as a standard RFC. Major issues: Minor issues: Nits/editorial comments: The last sentence in section 5.10 (TBD ...) hints that there is some work missing here in which case the draft is not ready. What is this sentence for? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-ietf-appsawg-rfc3462bis-02
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-appsawg-rfc3462bis-02 Reviewer: Roni Even Review Date: 2011-10-30 IETF LC End Date: 2011-10-23 IESG Telechat date: 2011-12-1 Summary: This draft is ready for publication as an standard track RFC. Major issues: Minor issues: Nits/editorial comments: ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-ietf-csi-dhcpv6-cga-ps-07
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-csi-dhcpv6-cga-ps-07 Reviewer: Roni Even Review Date: 2011-10-30 IETF LC End Date: 2011-11-4 IESG Telechat date: Summary: This draft is almost ready for publication as an informational RFC. Major issues: I do not have any editorial issues but I am not sure about the value of the document. I saw the IESG evaluation record https://datatracker.ietf.org/doc/draft-ietf-csi-dhcpv6-cga-ps/ballot/ and did not see any value with repeating the comments. So if the discuss are resolved the draft can be published. This is the reason that I summarized it as almost ready for publication. Minor issues: Nits/editorial comments: ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-ietf-mip4-nemo-haaro-06
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-mip4-nemo-haaro-06 Reviewer: Roni Even Review Date: 2011-10-29 IETF LC End Date: 2011-10-31 IESG Telechat date: 2011-11-3 Summary: This draft is almost ready for publication as an experimental RFC. Major issues: Minor issues: 1. The IANA section is not clear. It talks about three new tables but it was not clear to me which one they were and what is the extension policy for the tables. 2. Section 4.2 talks about realm compression. Is it always used when using prefix compression or can you just do prefix compression is there is no benefit from using the realm compression since it is a bit complicated. Nits/editorial comments: 1. Section 3.1 first paragraph alredy 2. Section 3.3.1 only be when change to only when and and and whose delete one of the and. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-vcarddav-kind-app-00
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-vcarddav-kind-app-00
Reviewer: Roni Even
Review Date: 2011-10-29
IETF LC End Date: 2011-10-20
IESG Telechat date: 2011-11-3
Summary: This draft is ready for publication as a standard track RFC.
Major issues:
Minor issues:
Nits/editorial comments:
I noticed that the example in section 3 is presented as XML but I did not
see any text about adding the new kind to the relax NG schema.
property-kind = element kind { element text { individual | group |
org | location }* }
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
RE: GenART LC review of draft-ietf-appsawg-rfc3462bis-01
Thanks, for the information. I will leave it up to you to decide if the information you provided me here should be in the document as backward interoperability information. Regards Roni From: Murray S. Kucherawy [mailto:m...@cloudmark.com] Sent: Monday, October 03, 2011 8:25 AM To: Roni Even; draft-ietf-appsawg-rfc3462bis@tools.ietf.org Cc: gen-...@ietf.org; 'IETF-Discussion list' Subject: RE: GenART LC review of draft-ietf-appsawg-rfc3462bis-01 The main implementations of multipart/report that I know of so far are ARF (RFC5965), DSN (RFC3464) and MDN (RFC3798). In the latter two cases, they repeat the requirement that, at time of generation, a DSN/MDN has to have multipart/report as the outermost MIME type, which is why it's safe to remove the restriction here. ARF specifically doesn't want the restriction, which was the impetus for this change; ARF wants to be able to send a message that is multipart/mixed containing many multipart/reports. According to discussion within the working group, experience suggests most implementations of RFC3462 have disregarded the restriction anyway, specifically to allow DSNs and MDNs to be forwarded around (inside message/* MIME parts). There has not been any report of interoperability problems as a result. This factored into the working group's consensus. -MSK From: Roni Even [mailto:ron.even@gmail.com] Sent: Sunday, October 02, 2011 10:51 PM To: Murray S. Kucherawy; draft-ietf-appsawg-rfc3462bis@tools.ietf.org Cc: gen-...@ietf.org; 'IETF-Discussion list' Subject: RE: GenART LC review of draft-ietf-appsawg-rfc3462bis-01 Hi, My mistake about the document type (cut and paste problem) As for me comment about multipart/report as part of another multipart MIME message, what will happen when an implementation based on RFC3462 will receive the report according this document. Will it be processed, ignored or take other behavior. Can the sender of the report know if it can send the report in another multipart MIME message. Thanks Roni Even From: Murray S. Kucherawy [mailto:m...@cloudmark.com] Sent: Monday, October 03, 2011 7:29 AM To: Roni Even; draft-ietf-appsawg-rfc3462bis@tools.ietf.org Cc: gen-...@ietf.org; 'IETF-Discussion list' Subject: RE: GenART LC review of draft-ietf-appsawg-rfc3462bis-01 Hi Roni, thanks for your comments. Two things in reply: First, this is not an Informational document, it's Standards Track. I don't know if that changes anything in your review, however. Second, Section 1 does describe the change being made between RFC3462 and this document, and the rationale for doing so. Was there some detail missing from there that was in the Appendix that you feel should be added? Thanks, -MSK From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Roni Even Sent: Saturday, October 01, 2011 6:31 AM To: draft-ietf-appsawg-rfc3462bis@tools.ietf.org Cc: gen-...@ietf.org; 'IETF-Discussion list' Subject: GenART LC review of draft-ietf-appsawg-rfc3462bis-01 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-appsawg-rfc3462bis-01 Reviewer: Roni Even Review Date: 2011-10-1 IETF LC End Date: 2011-10-10 IESG Telechat date: Summary: This draft is almost ready for publication as an informational RFC. Major issues: Minor issues: I noticed that the major change from RFC 3462 in the current version is to remove requirement that multipart/report not be contained in anything. The changes appear in appendix B which is to be removed in the published document. I think that it will be better to have the change from RFC 3462 be part of the main text and also discuss what are the backward interoperability issues if any. Nits/editorial comments: ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: GenART LC review of draft-ietf-appsawg-rfc3462bis-01
Hi, My mistake about the document type (cut and paste problem) As for me comment about multipart/report as part of another multipart MIME message, what will happen when an implementation based on RFC3462 will receive the report according this document. Will it be processed, ignored or take other behavior. Can the sender of the report know if it can send the report in another multipart MIME message. Thanks Roni Even From: Murray S. Kucherawy [mailto:m...@cloudmark.com] Sent: Monday, October 03, 2011 7:29 AM To: Roni Even; draft-ietf-appsawg-rfc3462bis@tools.ietf.org Cc: gen-...@ietf.org; 'IETF-Discussion list' Subject: RE: GenART LC review of draft-ietf-appsawg-rfc3462bis-01 Hi Roni, thanks for your comments. Two things in reply: First, this is not an Informational document, it's Standards Track. I don't know if that changes anything in your review, however. Second, Section 1 does describe the change being made between RFC3462 and this document, and the rationale for doing so. Was there some detail missing from there that was in the Appendix that you feel should be added? Thanks, -MSK From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Roni Even Sent: Saturday, October 01, 2011 6:31 AM To: draft-ietf-appsawg-rfc3462bis@tools.ietf.org Cc: gen-...@ietf.org; 'IETF-Discussion list' Subject: GenART LC review of draft-ietf-appsawg-rfc3462bis-01 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-appsawg-rfc3462bis-01 Reviewer: Roni Even Review Date: 2011-10-1 IETF LC End Date: 2011-10-10 IESG Telechat date: Summary: This draft is almost ready for publication as an informational RFC. Major issues: Minor issues: I noticed that the major change from RFC 3462 in the current version is to remove requirement that multipart/report not be contained in anything. The changes appear in appendix B which is to be removed in the published document. I think that it will be better to have the change from RFC 3462 be part of the main text and also discuss what are the backward interoperability issues if any. Nits/editorial comments: ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
GenART LC review of draft-ietf-appsawg-rfc3462bis-01
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-appsawg-rfc3462bis-01 Reviewer: Roni Even Review Date: 2011-10-1 IETF LC End Date: 2011-10-10 IESG Telechat date: Summary: This draft is almost ready for publication as an informational RFC. Major issues: Minor issues: I noticed that the major change from RFC 3462 in the current version is to remove requirement that multipart/report not be contained in anything. The changes appear in appendix B which is to be removed in the published document. I think that it will be better to have the change from RFC 3462 be part of the main text and also discuss what are the backward interoperability issues if any. Nits/editorial comments: ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-ietf-drinks-usecases-requirements-06
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-drinks-usecases-requirements-06 Reviewer: Roni Even Review Date: 2011-9-29 IETF LC End Date: 2011-10-3 IESG Telechat date: Summary: This draft is ready for publication as an informational RFC. Major issues: Minor issues: Nits/editorial comments: ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [payload] [Payload] Last Call: draft-ietf-payload-rfc3189bis-02.txt (RTP Payload Format for DV (IEC 61834) Video)) to Proposed Standard
Hi Qin, Thanks for the review see inline Roni From: payload-boun...@ietf.org [mailto:payload-boun...@ietf.org] On Behalf Of Qin Wu Sent: Tuesday, September 20, 2011 9:16 AM To: ietf@ietf.org Cc: payl...@ietf.org Subject: Re: [payload] [Payload] Last Call: draft-ietf-payload-rfc3189bis-02.txt (RTP Payload Format for DV (IEC 61834) Video)) to Proposed Standard Hi, I have just read this document and have some minor comments, hope it is not late to be taken into account. 1. Section 1: [Qin]: It looks this version extends RFC3189 to support some new features. However I can not see any dependency to RFC3189 in the introduction section until I read the last section in this document, is it more straigtforward and clear to merge the section 7,8 to the introduction section and clarify how this document is different from RFC3189. Roni: This document does not extend but obsolete RFC3189, so it should not reference it. As for the difference from RFC3189 I think it is better to have a separate section. 2. Section 3.1.1 3.1.1. Media Type Registration for DV Video Type name: video Subtype name: DV Required parameters: encode: type of DV format. Permissible values for encode are SD-VCR/525-60, SD-VCR/625-50, HD-VCR/1125-60, HD-VCR/1250-50, SDL-VCR/525-60, SDL-VCR/625-50, 314M-25/525-60, 314M-25/625-50, 314M-50/525-60, 314M-50/625-50, 370M/1080-60i, 370M/1080-50i, 370M/720-60p, 370M/720-50p, 306M/525-60 (for backward compatibility), and 306M/625-50 (for backward compatibility). [Qin]: In section 7, you claim you have removed SMPTE 306M, since it is covered by SMPTE 314M format. However in section 3.1.2, the value for SMPTE 306M is still kept in the encode list. So the question is where do you remove SMPTE 306M in this document? Why SMPTE 306M in the media type registration is still kept? Does this conflict with what you said in the section 7? The same comment applies in any place of this document where SMPTE 306M is still kept. Roni: Maybe change the first bullet of section 7 Removed SMPTE 306M, since it is covered by SMPTE 314M format To support for SMPTE 306M is only for backward interoperability, since it is covered by SMPTE 314M format 3. Section 3.1.1 Optional parameters: audio: whether the DV stream includes audio data or not. Permissible values for audio are bundled and none. Defaults to none. Encoding considerations: DV video can be transmitted with RTP as specified in RFC (This document). Other transport methods are not specified. Security considerations: See Section 4 of RFC (This document). Interoperability considerations: NONE [Qin]: Is it real that there is no interoperability consideration since Interoperability with Previous Implementations is discussed in the section 8 of this document? Roni: Good, add a reference to section 8 of this RFC 4. Section 3.2.1 Note that the examples in RFC3189 (older version of this document) provides incorrect SDP a=fmtp attribute usage. [Qin]: I believe it is not appropriate to spell this note out when this document is published but you may put it as errata or in the section 7. Roni: good point. Maybe discuss it in section 8, since this may be an interoperability issue Also not that the syntax a=fmtp:payload type encode=DV-video encoding audio=audio bundled Does not have ; before the audio while the examples have, I think that ; should separate between the parameters. 5. Section 3.2.1 The required parameter DV-video encoding specifies which type of DV format is used. The DV format name will be one of the following: SD-VCR/525-60 SD-VCR/625-50 HD-VCR/1125-60 HD-VCR/1250-50 SDL-VCR/525-60 SDL-VCR/625-50 314M-25/525-60 314M-25/625-50 314M-50/525-60 314M-50/625-50 370M/1080-60i 370M/1080-50i 370M/720-60p 370M/720-50p 306M/525-60 (for backward compatibility) 306M/625-50 (for backward compatibility) [Qin]: Why you need to repeat the same text in the section 3.1, why not just simply reference it described in the section 3.1. Roni: I do not see this as a major issue. It can stay from my point of view. 6. Section 3.2.1 In order to show whether the audio data is bundled into the DV stream or not, a format specific parameter is defined as below: [Qin]: s/ a format specifc parameter/ a format of specific parameter Roni: the current text is OK 7. Section 3.2.1 The optional parameter audio bundled will be one of the following: [Qin] s/one of the following/one of the following value. One question is: How do you distinguish between required parameter or optional parameter
Gen-ART LC review of draft-kompella-l2vpn-l2vpn-07
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-kompella-l2vpn-l2vpn-07 Reviewer: Roni Even Review Date: 2011-9-7 IETF LC End Date: 2011-9-27 IESG Telechat date: Summary: This draft is not ready for publication as an informational RFC. Major issues: The IANA considerations section says: the values already allocated are in Table 1 of Section 4. The allocation policy for new entries up to and including value 127 is Standards Action. The allocation policy for values 128 through 251 is First Come First Served. The values from 252 through 255 are for Experimental Use. Yet this is document is intended for Informational status which contradict the standard action. This is also true for the second registry defined. Is this document really an Informational one? Minor issues: 1. In section 1.2.2 Since traditional Layer 2 VPNs (i.e., real Frame Relay circuits connecting sites) are indistinguishable from tunnel-based VPNs from the customer's point-of-view, migrating from one to the other raises few issues. What are the few issues? 2. In section 4 L2VPN TLVs can be added to extend the information carried in the NLRI, using the format shown in Figure 2. How is the TLV carried in the NLRI, in which field, section 4.1 only talk about the structure of the TLV. 3. Section 4.2 refers to section 4 but I am not sure where this mechanism in section 4 is. Nits/editorial comments: 1. Section 3.1 is called network topology but the whole text is an example of a network topology. Maybe the title should be Example of a network toplogy. 2. Section 5 starts with As defined so far in the document .. But the using IP only is already discussed in previous sections. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-ietf-grow-geomrt-05
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-grow-geomrt-05 Reviewer: Roni Even Review Date:2011-8-20 IETF LC End Date: 2011-8-26 IESG Telechat date: 2011-8-25 Summary: This draft is ready for publication as a standard track RFC. Major issues: Minor issues: Nits/editorial comments: 1. Section 5 This section is to aide should be aid 2. Section 6 does not support the the delete the second the ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-ietf-bmwg-igp-dataplane-conv-meth-23
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-bmwg-igp-dataplane-conv-meth-23 Reviewer: Roni Even Review Date: 2011-8-16 IETF LC End Date: 2011-8-19 IESG Telechat date: Summary: This draft is ready for publication as an informational RFC. Major issues: Minor issues: I find that the document provides in depth testing procedures and reporting. What I think may be helpful is a recommendation about how many times to repeat each of the tests to get more accurate results. Is there any experience. Maybe it will be good to have some text on experience from actual testing that were done based on the document. Nits/editorial comments: I noticed that the issue of normative references was discussed and I had similar observation since the references in the terminology section are normative and Po11t is in draft forms. Did you consider why they are normative and not informative. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART last call review of draft-yevstifeyev-ion-report-06
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-yevstifeyev-ion-report-06 Reviewer: Roni Even Review Date:2011-7-31 IETF LC End Date: 2011-8-9 IESG Telechat date: Summary: This draft is ready for publication as an informational RFC. Major issues: Minor issues: I read in section 3.2 The IESG has determined that IONs will not be used in the future.It is clear that the IESG, IAB, and IAOC need the ability to publish documents that do not expire and are easily updated. Information published as web pages, including IESG Statements, are sufficient for this purpose. I was wondering that since the ION process required approval for the document to be published, what will be the approval process when using web pages. It is probably not part of this document but it is just a question and I see no problem with publishing this document. Nits/editorial comments: ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-ietf-6man-flow-3697bis-05
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-6man-flow-3697bis-05 Reviewer: Roni Even Review Date:2011-7-6 IETF LC End Date: 2011-7-13 IESG Telechat date: Summary: This draft is ready for publication as a standard track RFC. One nit Major issues: Minor issues: Nits/editorial comments: In section 3 fifth paragraph An alternative approach is to to use ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-ietf-roll-of0-14
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-of0-14 Reviewer: Roni Even Review Date:2011-6-27 IETF LC End Date: 2011-7-4 IESG Telechat date: Summary: This draft is ready for publication as a standard track RFC. Please note the Nits. Major issues: Minor issues: Nits/editorial comments: 1. The requirement language is usually in the terminology section and not with the abstract. 2. In section 7.2 first paragraph replace tthat with that 3. In section 7.2 third paragraph replace he current Version Number with the . ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-ietf-ftpext2-hosts-02
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-ftpext2-hosts-02 Reviewer: Roni Even Review Date:2011-6-21 IETF LC End Date: 2011-6-30 IESG Telechat date: 2011-6-30 Summary: This draft is ready for publication as a standard track RFC. Major issues: Minor issues: Nits/editorial comments: ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-faltstrom-5892bis-04
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-faltstrom-5892bis-04 Reviewer: Roni Even Review Date:2011-5-29 IETF LC End Date: 2011-6-6 IESG Telechat date: Summary: This draft is almost ready for publication as a standard track RFC. Major issues: 1. I am not sure how the IANA consideration section is in-line with the IANA consideration section of RFC5892. Maybe some clarification text would be helpful. 2. The IANA registry for derived property value has RFC 5892, does this draft want to change the reference, how will it be done. I think that it relates also to the issue of whether this draft updates RFC 5892. Minor issues: Nits/editorial comments: 1. In section 1 of three code points that where allocated should be were. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-ietf-mpls-lsp-ping-enhanced-dsmap-09
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-mpls-lsp-ping-enhanced-dsmap-09 Reviewer: Roni Even Review Date:2011-5-24 IETF LC End Date: 2011-5-30 IESG Telechat date: Summary: This draft is ready for publication as a standard track RFC. Major issues: Minor issues: Nits/editorial comments: 1. Need to expand LDP when first mentioned. 2. Section 3.3.1.1 The multipath data sub-TLV includes information multipath information delete the first information. 3. In section 3.3.1.2 When the Downstream Detailed Mapping TLV in sent in the echo response should be is sent. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART LC review of draft-ietf-mpls-lsp-ping-enhanced-dsmap-09
Hi Adrian, This is up to you reading the abbrev.expansion.txt I noticed that Some abbreviations are so well known that expansion is probably unnecessary. The RFC Editor exercises editorial judgment about whether a particular use of one of the well-known abbreviations requires expansion. So it will be up to the RFC editor. At least for me as a reader who is not familiar with all the abbreviations in the draft I found that even if they are expanded on the first usage it will be easier if all abbreviations are in one place in the document, but this may be a separate discussion on general draft structure. As for the abbrev.expansion.txt, it does not help since there is no reference to it in draft-ietf-mpls-lsp-ping-enhanced-dsmap and as mentioned some abbreviations have multiple expansions even in the RFC editor list (e.g. FEC). Roni -Original Message- From: Adrian Farrel [mailto:adr...@olddog.co.uk] Sent: Tuesday, May 24, 2011 1:16 PM To: 'Roni Even'; draft-ietf-mpls-lsp-ping-enhanced- dsmap@tools.ietf.org Cc: gen-...@ietf.org; 'IETF-Discussion list' Subject: RE: Gen-ART LC review of draft-ietf-mpls-lsp-ping-enhanced- dsmap-09 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-ietf-grow-geomrt-01
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-grow-geomrt-01 Reviewer: Roni Even Review Date:2011-4-26 IETF LC End Date: 2011-4-29 IESG Telechat date: Summary: This draft is ready for publication as an Informational RFC. Major issues: Minor issues: This is more out of curiosity 1. Why not include it in draft-ietf-grow-mrt-14 2. Why is it an Informational RFC and not standard track like the mrt draft. Nits/editorial comments: 1. Need to expand MRT when first mentioned. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART LC review of draft-harkins-ipsecme-spsk-auth-03
Hi Dan, About my first comment what I meant that section 6 sayFor the purposes of interoperability, a password pre-processing technique of None MUST be supported.. I now understand that in section 8.5 and 8.6 you say that the initiator may decide not to use the none technique and therefore may not find an interoperable mode. If the initiator will use none technique than you will have interoperability. Roni -Original Message- From: Dan Harkins [mailto:dhark...@lounge.org] Sent: Friday, April 22, 2011 3:39 AM To: Roni Even Cc: draft-harkins-ipsecme-spsk-auth@tools.ietf.org; gen- a...@ietf.org; 'IETF-Discussion list' Subject: Re: Gen-ART LC review of draft-harkins-ipsecme-spsk-auth-03 Hi Roni, Thank you for reviewing my draft. Comments inline On Mon, April 11, 2011 5:11 am, 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. Minor issues: 1. In section 8.5 and 8.6 the draft says that If no more password pre-processing techniques are supported the exchange MUST be terminated. Reading section 6, I thought that NONE MUST be supported for interoperability purpose. One of the valid techniques for password pre-processing is none. That doesn't mean that there isn't a technique, it means the technique is to perform no pre-processing on the password (treat it as a raw blob of bits). 2. In section 8.1 and in figure 1 and figure 2 is there a maximum value for counter? No there isn't, but it is doubtful the number will get very large. The probability that more than n iterations is necessary will be roughly (1-(r/2p))^n, where r is the order and p is the prime, and that number rapidly approaches zero as n increases. Nits/editorial comments: 1. In section 1 just before 1.1 you have suceed instead of succeed 2. In section 4 third bullet an instead of and 3. In section 4.2 Two elementx instead of Two elements 4. In section 5 second row authenticaiton should be authentication 5. In section 6 fourth row identitcal instead of identical Thank you for catching all of these. regards, Dan. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-harkins-ipsecme-spsk-auth-03
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-harkins-ipsecme-spsk-auth-03 Reviewer: Roni Even Review Date:2011-4-11 IETF LC End Date: 2011-4-23 IESG Telechat date: Summary: This draft is almost ready for publication as an Experimental RFC. Major issues: Minor issues: 1. In section 8.5 and 8.6 the draft says that If no more password pre-processing techniques are supported the exchange MUST be terminated. Reading section 6, I thought that NONE MUST be supported for interoperability purpose. 2. In section 8.1 and in figure 1 and figure 2 is there a maximum value for counter? Nits/editorial comments: 1. In section 1 just before 1.1 you have suceed instead of succeed 2. In section 4 third bullet an instead of and 3. In section 4.2 Two elementx instead of Two elements 4. In section 5 second row authenticaiton should be authentication 5. In section 6 fourth row identitcal instead of identical ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
GEn-ART last call review of draft-ietf-softwire-dual-stack-lite-07
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-softwire-dual-stack-lite-07 Reviewer: Roni Even Review Date:2011-4-10 IETF LC End Date: 2011-4-12 IESG Telechat date: Summary: This draft is ready for publication as standard track RFC. Major issues: None Minor issues: None Nits/editorial comments: 1. In section 8.3 NAT-44 appears without any reference or terminology expansion. 2. In section 8.5 liefetime should be lifetime 3. I am not sure what the recommendation in section 8.5 is. Is keep alive required or using PCP is recommended. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART LC review of draft-ietf-genarea-datatracker-community-07
Hi, I reviewed version 7 and all my comments were addressed. Roni Even -Original Message- From: Paul Hoffman [mailto:paul.hoff...@vpnc.org] Sent: Friday, March 11, 2011 6:08 AM To: Roni Even Cc: draft-ietf-genarea-datatracker-community@tools.ietf.org; gen- a...@ietf.org; 'IETF-Discussion list' Subject: Re: Gen-ART LC review of draft-ietf-genarea-datatracker- community-06 On 3/10/11 6:12 AM, 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. Thanks for the review. Everything on your list seemed fine, and will appear in the next draft. --Paul Hoffman ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-ietf-genarea-datatracker-community-06
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-genarea-datatracker-community-06 Reviewer: Roni Even Review Date:2011-3-10 IETF LC End Date: 2011-3-18 IESG Telechat date: Summary: This draft is almost ready for publication as Informational RFC. Major issues: Minor issues: 1. In section 1 The returned list of I-Ds and/or RFCs includes five columns, the current data tracker has six columns with an IPR column. Is this going to be removed. The whole document does not include it as an attribute. 2. In section 1.3 in the first bullet you do not have sent to RFC editor as a significant change. 3. Is section 1.5 still relevant or can you remove it already. 4. In section 2.3.1 first bullet you mention a view by group name. I did not see any definition of a group and a requirement to be able to name groups Nits/editorial comments: 1. In section 2.3.1 first paragraph after the user is of the net should be off 2. In section 2.3.2 second paragraph The default is to display is I-D filename . the second is not needed. 3. In appendix B 4 bullet you have cull did you mean null ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART LC review of draft-zhu-mobileme-doc-04
Hi, My impression from reading the document and according to figure 1 was that all end host communication was done in a UDP tunnel. So what is the relation of the TCP connection to BTMM. Roni Even From: Lixia Zhang [mailto:li...@cs.ucla.edu] Sent: Sunday, March 06, 2011 7:52 AM To: Roni Even Cc: draft-zhu-mobileme-doc@tools.ietf.org; gen-...@ietf.org; 'IETF-Discussion list' Subject: Re: Gen-ART LC review of draft-zhu-mobileme-doc-04 On Mar 4, 2011, at 6:01 AM, 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-zhu-mobileme-doc-04 Reviewer: Roni Even Review Date:2011-3-4 IETF LC End Date: 2011-3-18 IESG Telechat date: Summary: This draft is almost ready for publication as Informational RFC. Major issues: Minor issues: In section 5 and in section 6.1 second bullet you mention that the end to end connection is TCP while in other places like section 3, 4th paragraph you mention that UDP is used to tunnel packet end to end. So what are the TCP connections used for? section 3 talks about the use of UDP encapsulation for end host's data packets. section 5 and section 6.1 refer to TCP connections used by user applications running on end hosts. Nits/editorial comments: ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-zhu-mobileme-doc-04
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-zhu-mobileme-doc-04 Reviewer: Roni Even Review Date:2011-3-4 IETF LC End Date: 2011-3-18 IESG Telechat date: Summary: This draft is almost ready for publication as Informational RFC. Major issues: Minor issues: In section 5 and in section 6.1 second bullet you mention that the end to end connection is TCP while in other places like section 3, 4th paragraph you mention that UDP is used to tunnel packet end to end. So what are the TCP connections used for? Nits/editorial comments: ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-ietf-morg-multimailbox-search-06
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-morg-multimailbox-search-06 Reviewer: Roni Even Review Date:2011-2-20 IETF LC End Date: 2011-2-28 IESG Telechat date: Summary: This draft is ready for publication as Experimental RFC. Major issues: None Minor issues: None Nits/editorial comments: None ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-ietf-morg-multimailbox-search-06
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-morg-multimailbox-search-06 Reviewer: Roni Even Review Date:2011-2-20 IETF LC End Date: 2011-2-28 IESG Telechat date: Summary: This draft is ready for publication as Experimental RFC. Major issues: None Minor issues: None Nits/editorial comments: None ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART LC review of draft-ietf-shim6-multihome-shim-api-15
Hi Shinta,
I am OK with all your proposals
Thanks
Roni
-Original Message-
From: Shinta Sugimoto [mailto:shi...@sfc.wide.ad.jp]
Sent: Sunday, February 06, 2011 3:29 PM
To: Roni Even
Cc: draft-ietf-shim6-multihome-shim-api@tools.ietf.org; gen-
a...@ietf.org; 'IETF-Discussion list'
Subject: Re: Gen-ART LC review of draft-ietf-shim6-multihome-shim-api-
15
Dear Roni,
Thank you very much for your review. Please find my answers inline.
(11/02/01 17:27), 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-shim6-multihome-shim-api-15
Reviewer: Roni Even
Review Date:2011-2-1
IETF LC End Date: 2011-2-10
IESG Telechat date:
Summary: This draft is almost ready for publication as Informational
RFC.
Major issues:
Minor issues:
1.In section 8.2 the path exploration parameters are different from
RFC
5534, missing keep alive interval. Why the difference.
You are right. Keepalive Interval is missing in the parameter set that
we defined in our draft. We did not put in the draft as we thought that
the value will be determined according to the recommendation given in
RFC5534 (i.e., the interval should be set one-half to one-third of the
Keepalive Timeout value), but I agreed that we should make it explicit
in our draft.
I suggest to make the following changes in Section 8.2:
1) change the structure (shim_pathexplore{}) as follows:
struct shim_pathexplore {
uint16_t pe_probenum; /* # of initial probes */
uint16_t pe_keepaliveto; /* Keepalive Timeout */
uint16_t pe_keepaliveint; /* Keepalive Interval */
uint16_t pe_initprobeto; /* Initial Probe Timeout */
uint32_t pe_reserved; /* reserved */
};
2) Add pe_keepaliveint and its description as below.
pe_keepaliveint
Indicates interval of REAP keepalive messages in seconds to be
sent by
the host when there is no outbound traffic to the peer host. The value
shall be set according to the recommendation given in [RFC5534].
Does this sound reasonable to you?
2.In section 11.1 you discuss conflict resolution for SHIM6, is this
also relevant for HIP or is it a specific SHIM6 problem. This also
relates to the issue of conflict resolution discussed in the security
section.
No, the issue addressed in Section 11.1 is not relevant to HIP. It is
an
issue specific to SHIM6. Note that the concept of context forking is
not
defined in the HIP RFC. As for the texts in Section 14 (Security
Considerations), the texts in Section 14.1.1 apply to HIP and SHIM6.
When there is no indication of specific protocol name (i.e., HIP or
SHIM6), a term shim sub-layer refers to both HIP and SHIM6. This is an
assumption in this document.
3.The last sentence in appendix A Any solution is needed to overcome
the problem mentioned above is not clear, does it mean that there is
no
solution to the context forking problem. Section 11.1 claims that
using
the procedure described it addresses this issue, am I missing
something.
No, the issue discussed in Appendix A cannot be solved by the solution
(or I had better say recommendation) explained in section 11.1. They
are
simply different issues. With regard to the issue described in Appendix
A, there is no solution as far as I know. To avoid the confusion, I
suggest to change the last sentence of Appendix A as follows: It is
for
further study how to solve the issue described above. Does this make
sense?
Nits/editorial comments:
1.In 8.2 for pe_keepaliveto, what are the units, I assume it is
seconds.
Yes, you are right. Let us update the text to make it clear.
2.In section 7 section paragraph in which one ore should be in
which
one or
OK, thanks. Let us correct the typo.
Again, thank you very much for your review!
Regards,
Shinta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-ietf-shim6-multihome-shim-api-15
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-shim6-multihome-shim-api-15 Reviewer: Roni Even Review Date:2011-2-1 IETF LC End Date: 2011-2-10 IESG Telechat date: Summary: This draft is almost ready for publication as Informational RFC. Major issues: Minor issues: 1. In section 8.2 the path exploration parameters are different from RFC 5534, missing keep alive interval. Why the difference. 2. In section 11.1 you discuss conflict resolution for SHIM6, is this also relevant for HIP or is it a specific SHIM6 problem. This also relates to the issue of conflict resolution discussed in the security section. 3. The last sentence in appendix A Any solution is needed to overcome the problem mentioned above is not clear, does it mean that there is no solution to the context forking problem. Section 11.1 claims that using the procedure described it addresses this issue, am I missing something. Nits/editorial comments: 1. In 8.2 for pe_keepaliveto, what are the units, I assume it is seconds. 2. In section 7 section paragraph in which one ore should be in which one or ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART LC review of draft-ietf-pwe3-oam-msg-map-14
Yaakov, Yes this is what I mean Roni From: Yaakov Stein [mailto:yaako...@rad.com] Sent: Thursday, January 27, 2011 5:47 PM To: Roni Even; draft-ietf-pwe3-oam-msg-map@tools.ietf.org; gen-...@ietf.org Cc: 'IETF-Discussion list' Subject: RE: Gen-ART LC review of draft-ietf-pwe3-oam-msg-map-14 Roni Thanks for the nit-catching. I assume you RFC5087 not as a reference means you quote RFC5087 not as a reference. Due to Adrian's DISCUSS we are going to have to respin after the LC; I will fix all the nits you mention (and Russ' nit as well) at that time. Y(J)S From: Roni Even [mailto:even.r...@huawei.com] Sent: Sunday, January 23, 2011 09:17 To: draft-ietf-pwe3-oam-msg-map@tools.ietf.org; gen-...@ietf.org Cc: 'IETF-Discussion list' Subject: Gen-ART LC review of draft-ietf-pwe3-oam-msg-map-14 Hi, 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-pwe3-oam-msg-map-14 Reviewer: Roni Even Review Date:2011-1-23 IETF LC End Date: 2011-1-24 IESG Telechat date: Summary: This draft is ready for publication as a Standard track RFC. Major issues: Minor issues: Nits/editorial comments: 1. The document starts with Contributors and acknowledgments section. I think that this is not the major reason for the document and suggest moving these two sections to the end of the document. 2. In the Abbreviations and Conventions section which includes the terminology it may be good to reference the terminology from RFC3985. 3. Towards the end of section 7 and in the beginning of section 11 you RFC5087 not as a reference while in other places you have it as a reference. I think it should be written as a reference. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-arkko-dual-stack-extra-lite
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-arkko-dual-stack-extra-lite-03 Reviewer: Roni Even Review Date:2011-1-24 IETF LC End Date: 2011-2-10 IESG Telechat date: Summary: This draft is ready for publication. Major issues: Minor issues: This document has a standard track intended status. It looks to me more of informational type. Nits/editorial comments: ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-ietf-pwe3-oam-msg-map-14
Hi, 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-pwe3-oam-msg-map-14 Reviewer: Roni Even Review Date:2011-1-23 IETF LC End Date: 2011-1-24 IESG Telechat date: Summary: This draft is ready for publication as a Standard track RFC. Major issues: Minor issues: Nits/editorial comments: 1. The document starts with Contributors and acknowledgments section. I think that this is not the major reason for the document and suggest moving these two sections to the end of the document. 2. In the Abbreviations and Conventions section which includes the terminology it may be good to reference the terminology from RFC3985. 3. Towards the end of section 7 and in the beginning of section 11 you RFC5087 not as a reference while in other places you have it as a reference. I think it should be written as a reference. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-turner-ekpct-algs-update-02
Hi, 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-turner-ekpct-algs-update-02 Reviewer: Roni Even Review Date:2011-1-23 IETF LC End Date: 2011-2-8 IESG Telechat date: Summary: This draft is ready for publication as a Standard track RFC. Major issues: none Minor issues: None Nits/editorial comments: None ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART IETF LC review of draft-ietf-ecrit-lost-servicelistboundary
Hi Karl, I looked at the 05 version and it does not look like you fixed the nits Roni From: Karl Heinz Wolf [mailto:karlheinz.w...@nic.at] Sent: Friday, December 17, 2010 10:28 AM To: Roni Even; General Area Review Team; draft-ietf-ecrit-lost-servicelistboundary@tools.ietf.org Cc: IETF-Discussion list Subject: AW: Gen-ART IETF LC review of draft-ietf-ecrit-lost-servicelistboundary Roni, thank you for your review and please apologize my delayed response. I agree to your comments, the 2. one is really a good catch! Thank you, Karl -Ursprüngliche Nachricht- Von: ietf-boun...@ietf.org im Auftrag von Roni Even Gesendet: Sa 12/4/2010 4:41 An: 'General Area Review Team'; draft-ietf-ecrit-lost-servicelistboundary@tools.ietf.org Cc: 'IETF-Discussion list' Betreff: Gen-ART IETF LC review of draft-ietf-ecrit-lost-servicelistboundary Hi, 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-ecrit-lost-servicelistboundary-04 Reviewer: Roni Even Review Date: 2010-12-04 IETF LC End Date: 2010-12-14 IESG Telechat date: (if known) Summary: This draft is ready for publication as an Experimental RFC. There are some nits Major issues: Minor issues: Nits/editorial comments: 1. In the abstract the document starts with LoST, Please expand to Location-to-Service Translation 2. At the end of section 3.2 in the note, I think that the first getServiceListBoundary should be getServiceBoundary Roni Even ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART LC review of draft-ietf-sipcore-keep-10
Hi Christer, I am OK with all your responses regards Roni -Original Message- From: Christer Holmberg [mailto:christer.holmb...@ericsson.com] Sent: Saturday, January 01, 2011 12:20 PM To: Roni Even; gen-...@ietf.org; draft-ietf-sipcore- keep@tools.ietf.org Cc: 'IETF-Discussion list' Subject: RE: Gen-ART LC review of draft-ietf-sipcore-keep-10 Hi Roni, Summary: This draft is almost ready for publication as a Standard track RFC. Major issues: Minor issues: 1. In the document you mention that the keep alive can be negotiated in each direction. I understand the dialog case, is this true for the case of registration, if yes how is it done from the registrar. If not true maybe add some text in 4.2.2. Good point. It is NOT true for the case of registration, when sending of keep-alives can only be negotiated from the registering party to the registrar. I suggest adding the following text to the end of section 4.2.2: NOTE: Sending of keep-alives associated with a registration can only be negotiated in the direction from the registering SIP entity towards the registrar. - Nits/editorial comments: 1. In section 4.1 in the first note If a SIP entity has indicated willingness to receive keep-alives from an adjacent SIP entity, sending of keep-alives towards the same SIP entity needs to be separately negotiated. Who is the same SIP entity mentioned in the end of the sentence. I assume you meant towards the adjacent SIP entity. (I assume you mean Why instead of Who) You are correct. I propose to change to: towards that adjacent SIP entity, to make sure that the text is referring to the entity that indicated willingness to send keep-alives, and not some other adjacent SIP entity. 2. In the first paragraph of 4.3 and 4.4 you use must should it be MUST As far as I know it shall be must when referring to something defined in another specifiction. 3. In 4.3 in the third paragraph it MUST start to send keep-alives change to it MUST start sending keep-alives I'll change as suggested. 4. In figure 2 in the 200 OK response to Alice the VIA is missing. Correct. I'll change Alice: UAC;keep=30 to Via: Alice;keep=30. 5. In section 7.4 third paragraph When Alice receives the response, she determines from her Via header field that P1 is willing to receive keep-alives associated with the dialog. Should be Bob and not P1. Correct. I'll change as suggested. Thanks for your comments! Regards, Christer= ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-ietf-sipcore-keep-10
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-sipcore-keep-10 Reviewer: Roni Even Review Date:2010-12-28 IETF LC End Date: 2011-1-5 IESG Telechat date: Summary: This draft is almost ready for publication as a Standard track RFC. Major issues: Minor issues: 1. In the document you mention that the keep alive can be negotiated in each direction. I understand the dialog case, is this true for the case of registration, if yes how is it done from the registrar. If not true maybe add some text in 4.2.2. Nits/editorial comments: 1. In section 4.1 in the first note If a SIP entity has indicated willingness to receive keep-alives from an adjacent SIP entity, sending of keep-alives towards the same SIP entity needs to be separately negotiated. Who is the same SIP entity mentioned in the end of the sentence. I assume you meant towards the adjacent SIP entity. 2. In the first paragraph of 4.3 and 4.4 you use must should it be MUST 3. In 4.3 in the third paragraph it MUST start to send keep-alives change to it MUST start sending keep-alives 4. In figure 2 in the 200 OK response to Alice the VIA is missing. 5. In section 7.4 third paragraph When Alice receives the response, she determines from her Via header field that P1 is willing to receive keep-alives associated with the dialog. Should be Bob and not P1. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-ietf-roll-routing-metrics-14
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. 2. In section 2.1 in example 1 how is it known that all nodes MUST be main powered. Do you need to provide a value to prec field? 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) 4. In section 3.1 the flag field - how many bits, specify. 5. In section 3.2 figure 4 shows a flag field, how many bits, what is the value. 6. In section 6 according to rfc5226 IETF consensus is now IETF review. 7. In section 6.1 you should say that the table has the initial values and add which numbers are available for allocation. 8. In section 6.2 what values are available for allocation. Also say that currently the table is empty. 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 10.In section 6.3, are there more values allowed, can they be allocated. If not why have it managed by IANA. 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. 12.In section 6.3 New bit numbers may be allocated, how many bits are available. 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 14.Comment 12 and 13 are also true for section 6.4 and 6.5. Nits/editorial comments: 1. In section first paragraph object should be object 2. In section 4.3.2 first paragraph wich should be which ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART IETF LC review of draft-ietf-ecrit-lost-servicelistboundary
Hi, 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-ecrit-lost-servicelistboundary-04 Reviewer: Roni Even Review Date: 2010-12-04 IETF LC End Date: 2010-12-14 IESG Telechat date: (if known) Summary: This draft is ready for publication as an Experimental RFC. There are some nits Major issues: Minor issues: Nits/editorial comments: 1. In the abstract the document starts with LoST, Please expand to Location-to-Service Translation 2. At the end of section 3.2 in the note, I think that the first getServiceListBoundary should be getServiceBoundary Roni Even ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART last call review of draft-ietf-emu-eaptunnel-req-08
Hi Joe, Thanks Inline Roni -Original Message- From: Joe Salowey [mailto:jsalo...@cisco.com] Sent: Monday, November 29, 2010 7:42 AM To: Roni Even Cc: 'General Area Review Team'; draft-ietf-emu-eaptunnel- req@tools.ietf.org; 'IETF-Discussion list' Subject: Re: Gen-ART last call review of draft-ietf-emu-eaptunnel-req- 08 Hi Roni, Sorry I missed your first message, thank you for resending it. Comments in line below: Cheers, Joe On Nov 27, 2010, at 11:34 PM, Roni Even wrote: Hi, I sent the following review on October 25th but did not see and response. Roni Even 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-emu-eaptunnel-req-08 Reviewer: Roni Even Review Date:2010-10-25 IETF LC End Date: 2010-11-10 IESG Telechat date:2010-12-2 Summary: This draft is almost ready for publication as an Informational RFC. Major issues: Minor issues: 1. In section 2 why not reference RFC 2119 or at least copy the definition from RFC 2119 for the capitalized term. [Joe] We followed the convention used in RFC 5209 (NEA protocol requirements), because this document is defining requirements rather than the protocol itself. Roni - Ok so just some questions about the current text for example in section 3 you have The candidate tunnel method needs to support all of the use cases that are marked below as MUST. What do you mean by needs to - is this mandatory to support these use cases? Also in section 6.2 last paragraph is it must or MUST 2. In section 3.9 when you say if this technique is used, by this do you mean certificate -less or the flow defined in the previous sentence. [Joe] if this technique is used refers to certificatel-less authentication using the inner EAP method for client authentication without server authentication. Perhaps the following sentence would be clearer: If an inner EAP method is used for client authentication without full server validation the inner method MUST provide resistance to dictionary attack and a cryptographic binding between the inner method and the tunnel method MUST be established. ... Does this help? Roni: yes. 3. In section 4.6.3 the first paragraph defines the requirements for Cryptographic Binding. It looks to me like the rest of the section talks about a specific use case, so why is it in the requirements section and not in section 3. [Joe] The majority of section 4.6.3 discusses a possible mechanism to achieve cryptographic binding. While it is not specifically a requirement I think it supports the requirement defined in the first paragraph. I do not think it belongs in the use case section. Roni: OK, it was just that the second and third paragraph looked like to me like an example since the second paragraph starts with Cryptographic bindings are typically achieved so it looked like one use case to address the requirement in the first paragraph. Nits/editorial comments: ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-ietf-opsec-protect-control-plane-04
Hi, 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-opsec-protect-control-plane-04 Reviewer: Roni Even Review Date: 2010-11-28 IETF LC End Date: 2010-12-3 IESG Telechat date: (if known) Summary: This draft is ready for publication as an Informational RFC. There are some nits and minor issue. Major issues: Minor issues: The example in appendix A are using syntax with no reference. The text says that this is non normative text but I think that it will be good to have a reference to the document where the correct syntax is specified Nits/editorial comments: 1. The first sentence of section 1 Modern router architecture design maintains a strict separation of forwarding and routing control plane hardware and software. Talks about routing control plane while the next sentence and the rest of the document calls it router control plane 2. In section 2 third paragraph Additionally, there may be other vendor or implementation specific protection mechanisms that are on by default or always on. . I suggest changing the text are on and always on maybe to active or turned on. Thanks Roni Even ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART LC review of draft-ietf-opsec-protect-control-plane-04
Rodney, What I meant and I think Joel got it right is to add informative reference to the manuals/documents where you can see how to write policy similar to the ones in the appendix. BTW: You can make all changes after the IETF LC is finished (December 3rd) Roni -Original Message- From: Rodney Dunn [mailto:rod...@cisco.com] Sent: Sunday, November 28, 2010 6:09 PM To: Joel Jaeggli Cc: Roni Even; General Area Review Team; IETF-Discussion list; draft- ietf-opsec-protect-control-plane@tools.ietf.org Subject: Re: Gen-ART LC review of draft-ietf-opsec-protect-control- plane-04 Joel, I had responded offline to Roni to get clarification on the reference part. I wasn't clear as to what what the informative reference should be. Here was my response: rd The idea was that the text in the draft is normative but the configuration examples are not as they are many different ways for the configurations to be constructed to accomplish the same output. While some are more optimized from a number of lines perspective they didn't map clearly enough between the two examples or as clearly illustrate the example logic. I'm not sure what you meant by where the correct syntax is specified. The syntax used is correct just there are various ways it can be configured. Some actually come down to personal preference so there is no correct in the sense of implementation uniqueness. Can you clarify it for me? I updated the other two points and went with active on the second. Thanks, Rodney On 11/28/10 11:05 AM, Joel Jaeggli wrote: Active is fine, turned on And always on have different meanings however. I think we can fix appendix a with the appropriate informative reference as specified. Joel's widget number 2 On Nov 28, 2010, at 7:39, Roni Even ron.even@gmail.com mailto:ron.even@gmail.com wrote: Hi, 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/GenArtfaqhttp://wiki.t ools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-opsec-protect-control-plane-04 Reviewer: Roni Even Review Date: 2010-11-28 IETF LC End Date: 2010-12-3 IESG Telechat date: (if known) Summary: This draft is ready for publication as an Informational RFC. There are some nits and minor issue. Major issues: Minor issues: The example in appendix A are using syntax with no reference. The text says that this is non normative text but I think that it will be good to have a reference to the document where the correct syntax is specified Nits/editorial comments: 1.The first sentence of section 1 Modern router architecture design maintains a strict separation of forwarding and routing control plane hardware and software. Talks about routing control plane while the next sentence and the rest of the document calls it router control plane 2.In section 2 third paragraph Additionally, there may be other vendor or implementation specific protection mechanisms that are on by default or always on. . I suggest changing the text are on and always on maybe to active or turned on. Thanks Roni Even ___ Ietf mailing list Ietf@ietf.org mailto:Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART last call review of draft-ietf-emu-eaptunnel-req-08
Hi, I sent the following review on October 25th but did not see and response. Roni Even 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-emu-eaptunnel-req-08 Reviewer: Roni Even Review Date:2010-10-25 IETF LC End Date: 2010-11-10 IESG Telechat date:2010-12-2 Summary: This draft is almost ready for publication as an Informational RFC. Major issues: Minor issues: 1. In section 2 why not reference RFC 2119 or at least copy the definition from RFC 2119 for the capitalized term. 2. In section 3.9 when you say if this technique is used, by this do you mean certificate -less or the flow defined in the previous sentence. 3. In section 4.6.3 the first paragraph defines the requirements for Cryptographic Binding. It looks to me like the rest of the section talks about a specific use case, so why is it in the requirements section and not in section 3. Nits/editorial comments: ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART last call review of draft-ietf-emu-eaptunnel-req-08
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-emu-eaptunnel-req-08 Reviewer: Roni Even Review Date:2010-10-25 IETF LC End Date: 2010-11-10 IESG Telechat date: Summary: This draft is almost ready for publication as an Informational RFC. Major issues: Minor issues: 1. In section 2 why not reference RFC 2119 or at least copy the definition from RFC 2119 for the capitalized term. 2. In section 3.9 when you say if this technique is used, by this do you mean certificate -less or the flow defined in the previous sentence. 3. In section 4.6.3 the first paragraph defines the requirements for Cryptographic Binding. It looks to me like the rest of the section talks about a specific use case, so why is it in the requirements section and not in section 3. Nits/editorial comments: ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
