Re: [Gen-art] Gen-ART LC review of draft-ietf-mmusic-sdp-mux-attributes-13

[Romascanu, Dan (Dan)]

Hi Suhas,

Thank you for your answer. Please see in-text.

Please start using droma...@gmail.com<mailto:droma...@gmail.com> as my 
preferred mail address. I will be retiring in two weeks (but continuing the 
IETF activities) and my Avaya address will soon become inactive.

Regards,

Dan


From: Suhas Nandakumar (snandaku) [mailto:snand...@cisco.com]
Sent: Thursday, August 18, 2016 9:29 PM
To: Romascanu, Dan (Dan); General Area Review Team
Cc: draft-ietf-mmusic-sdp-mux-attributes@tools.ietf.org; Suhas Nandakumar 
(snandaku)
Subject: Re: Gen-ART LC review of draft-ietf-mmusic-sdp-mux-attributes-13


Hello Dan



 Many thanks for your review. Apologies for the delayed response ( I just got 
back from vacation)



Please see inline for responses to concerns raised (with [[Suhas]] Markings)





Cheers

Suhas Nandakumar


From: Romascanu, Dan (Dan) <droma...@avaya.com<mailto:droma...@avaya.com>>
Sent: Monday, August 8, 2016 9:01 AM
To: General Area Review Team
Cc: 
draft-ietf-mmusic-sdp-mux-attributes@tools.ietf.org<mailto:draft-ietf-mmusic-sdp-mux-attributes@tools.ietf.org>
Subject: Gen-ART LC review of draft-ietf-mmusic-sdp-mux-attributes-13


I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



https://trac.tools.ietf.org/area/gen/trac/wiki/GenArtfaq<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.tools.ietf.org_area_gen_trac_wiki_GenArtfaq=CwMF-g=BFpWQw8bsuKpl1SgiZH64Q=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA=PcQwHEKZLeS5MO2yvCwLJ4Fw9Hwy3yLx9o4SH0yYZdw=yqb8cDj2OZ4NM4x6XD935ttCnC_-FK75_uOi0j0ZgDU=>



Document: draft-ietf-mmusic-sdp-mux-attributes-13

Reviewer: Dan Romascanu

Review Date: 8/8/16

IETF LC End Date: 8/10/16

IESG Telechat date: not known



Summary:



Ready with issues.



Major issues:

1.   My understanding is that this document undertakes the task of 
analyzing the multiplexing characteristics of the SDP attributes and 
classifying them based on this analysis. It also adds one new 'Multiplexing 
Category' registry, a 'Mux Category' column and new attributes to a number of 
SDP sub-registries. What is not clear to me is what is the process by which new 
attribute values are to be added. The sub-registries in 15.2.x - can new values 
be added? Or new  sub-registries created because of the need to support a new 
protocol that defined SDP attributes? What is the policy and the registration 
process? I hope that my question makes sense, in case it does not, please 
explain why.



[[Suhas]] - Section 15.XXX defines the following ways of dealing with the 
future extensions



a) Adding a new Multiplexing category

   The process here is to have a new specification that explains the new 
Multiplexing category and its purpose in the SDP Attribute multiplexing as 
defined in Section 15.1



b) Adding a new SDP attribute to any of the sub-registries

Any future specifications that defines new SDP attributes must analyze the 
multiplexing characteristics for the newly defined attribute and  specify the 
appropriate "Mux Category" for the same as well.



c) Updating the category assignments  (Say from TBD to something different)

 This needs a new specification with the updated category. (more details 
below)



Section 15.2 and its sub-sections defines how the Mux Category for the SDP 
attributes analyzed in the current draft are added to SDP Parameters IANA 
registry.



please let me know if we need to add more clarifications on any of the above



DR: thanks, makes sense, but some clarification text would be necessary. My 
understanding is that the policy to update all the above is 'Specification 
Required'. This needs to be explicitly stated.



Minor issues:

1.   The use of B - 'Both' terminology used to indicate that an attribute 
is specified S - Session Level and M - Medial Level (e.g. in Section 5) may be 
confusing, as there is a third possible level SR - Source Level. Actually S + M 
would probably be more clear.



[[Suhas]] - Good point Dan. I see 2 options to progress.



   Option 1 - Same as your suggestion of going with S+M

   Option 2 - Clarify the use of 'B' in Section 5's introductory paragraph as
* B - Both ( implies attribute applies to both the Session and Media 
level)

DR: any of the two proposed solutions would work. Option 2 is fine if you 
prefer it.



The only positive thing about Option 2 is that the changes are minimal. Please 
advice.



2.   Section 5.54 includes a note referring to the TBD content. 'As per 
section 9.1 of [I-D.ietf-mmusic-sdp-bundle-negotiation],  there exists no 
publicly available specification that defines procedures for 
multiplexing/demultiplexing fax protocols flows over a sin

Re: [Gen-art] Gen-ART LC review of draft-ietf-radext-datatypes-04.txt

[Romascanu, Dan (Dan)]

Hi Alan,

Thanks for the quick response. The planned edits seem to address all the issues 
that I raised. There are good chances that I will just say 'I am happy' when I 
will see the revised I-D.

Regards,

Dan


From: Gen-art [gen-art-boun...@ietf.org] on behalf of Romascanu, Dan (Dan)
Sent: Tuesday, August 09, 2016 6:28 PM
To: General Area Review Team
Cc: rad...@ietf.org; draft-ietf-radext-datatypes@tools.ietf.org
Subject: [Gen-art] Gen-ART LC review of draft-ietf-radext-datatypes-04.txt


I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



https://trac.tools.ietf.org/area/gen/trac/wiki/GenArtfaq<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.tools.ietf.org_area_gen_trac_wiki_GenArtfaq=CwMFAg=BFpWQw8bsuKpl1SgiZH64Q=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA=A146UD4syR9uGHj3mNEcdcuht-Sznx47S9gyH87tBfU=pbahG3QoEuw2lLVL8Vw1XGd--c3Ak_-FexGmP-_DqyY=>



Document: draft-ietf-radext-datatypes-04.txt

Reviewer: Dan Romascanu

Review Date: 8/9/16

IETF LC End Date: 8/17/16

IESG Telechat date: 8/18/16



Summary:



Ready with issues.



This is an important document that tries to bring clarification to a number of 
different interpretations and recommendations around the RADIUS specifications. 
Being familiar – up to a certain point – with the history, I believe that it’s 
long due and that it will be very useful. There are however a number of issues 
which I believe need to be clarified before the document is approved by the 
IESG.



Major issues:



1.   Although the document makes the claim that it does not impact previous 
specifications and implementations, I am not sure this is completely the case. 
For example, the statement in RFC 6158, section 2.1 about ‘all other data 
formats (than the ones defined there) being NOT RECOMMENDED is obsolete by this 
document. I think that there is a need to make clear what is not longer valid 
or recommended in specifications that this document updates.

2.   This document creates a new IANA registry and updates another one. 
There is no mention however about the policy of adding new entries or making 
other modifications to the new registry. A reminder of the RADIUS Attribute 
Type registry policy would also help.



Minor issues:



1.   In section 3.5 – there is no mention that the string length is limited 
to 253 octets. This is obvious if we assume the definition of  “string” 
sticking with previous RADIUS documents, and clear by the fact that “concat” 
deals in 3.6 with transport of more than 253 octets, but for clarity I believe 
that this needs to be explicitly stated.

2.   It is not clear why the Prefix-Length value greater than 128 for 
ipv6prefix in 3.10 and greater than 32 for ipv4prefix in 3.11 need only SHOULD 
be treated as “invalid attributes”. Why not MUST? If there are exception cases 
it would be good to explain them.



Nits/editorial comments:



1.   Section 2.1.4: The paragraph that starts with ‘The “Value” field 
should be given ….’ needs to use capitalized SHOULD to be consistent with the 
paragraph that refer to the “Name” and “Format” fields.






___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART LC review of draft-ietf-mmusic-sdp-mux-attributes-13

[Romascanu, Dan (Dan)]

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



https://trac.tools.ietf.org/area/gen/trac/wiki/GenArtfaq



Document: draft-ietf-mmusic-sdp-mux-attributes-13

Reviewer: Dan Romascanu

Review Date: 8/8/16

IETF LC End Date: 8/10/16

IESG Telechat date: not known



Summary:



Ready with issues.



Major issues:

1.   My understanding is that this document undertakes the task of 
analyzing the multiplexing characteristics of the SDP attributes and 
classifying them based on this analysis. It also adds one new 'Multiplexing 
Category' registry, a 'Mux Category' column and new attributes to a number of 
SDP sub-registries. What is not clear to me is what is the process by which new 
attribute values are to be added. The sub-registries in 15.2.x - can new values 
be added? Or new  sub-registries created because of the need to support a new 
protocol that defined SDP attributes? What is the policy and the registration 
process? I hope that my question makes sense, in case it does not, please 
explain why.



Minor issues:

1.   The use of B - 'Both' terminology used to indicate that an attribute 
is specified S - Session Level and M - Medial Level (e.g. in Section 5) may be 
confusing, as there is a third possible level SR - Source Level. Actually S + M 
would probably be more clear.

2.   Section 5.54 includes a note referring to the TBD content. 'As per 
section 9.1 of [I-D.ietf-mmusic-sdp-bundle-negotiation],  there exists no 
publicly available specification that defines procedures for 
multiplexing/demultiplexing fax protocols flows over a single 5-tuple.  Once 
such a specification is available, the multiplexing category assignments for 
the attributes in this section could be revisited.' Assuming the missing 
specification will be publicly available sometime in the future - how will this 
information be added? Revise this RFC? The question applies to other TBD marked 
in the 'Mux Category' column of the tables in Section 5 (in 5.42, 5.44, ...)



Nits/editorial comments:

1.   In the table at 5.6 - repetition 'section Section'



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART IETF LC review of draft-ietf-hip-rfc6253-bis-08

[Romascanu, Dan (Dan)]

Please disregard this - wrong I-D name in the subject line.

I sent a corrected version.

Regards,

Dan


From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Romascanu, Dan 
(Dan)
Sent: Thursday, July 7, 2016 5:32 PM
To: General Area Review Team
Cc: draft-hardy-pdf-mime@tools.ietf.org
Subject: [Gen-art] Gen-ART IETF LC review of draft-ietf-hip-rfc6253-bis-08


I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair. Please wait for direction from your document shepherd or AD before 
posting a new version of the draft.



For more information, please see the FAQ at



<https://trac.tools.ietf.org/area/gen/trac/wiki/GenArtfaq><https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.tools.ietf.org_area_gen_trac_wiki_GenArtfaq-26gt-3B=CwQFAg=BFpWQw8bsuKpl1SgiZH64Q=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA=AyhyRHseIb7KXH8tfY_AtqV0W2CNoyGjEbDlcYKuTK4=ueIei6thx_uucwLd00irmU-2d-d3OZR6DmsdMo_xASk=>.



Document: draft-hardy-pdf-mime-02

Reviewer: Dan Romascanu

Review Date: 07/07/16

IETF LC End Date: 07/21/16

IESG Telechat date:



Summary: Ready.



This informational document which obsoletes RFC 3778 provides an overview of 
the PDF format and updates the media type registration of "application/pdf" by 
aligning it with RFC 6838. I am no expert in application formats, but the 
document seems to be well informed and clearly written. A couple of nits 
generate id-nits warnings (updating RFC 3778 is not mentioned in the Abstract, 
one unused reference) that can be easily fixed during the RFC Editor processing.



Major issues:



Minor issues:



Nits/editorial comments:



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART IETF LC review of draft-hardy-pdf-mime-02

[Romascanu, Dan (Dan)]

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair. Please wait for direction from your document shepherd or AD before 
posting a new version of the draft.



For more information, please see the FAQ at



.



Document: draft-hardy-pdf-mime-02

Reviewer: Dan Romascanu

Review Date: 07/07/16

IETF LC End Date: 07/21/16

IESG Telechat date:



Summary: Ready.



This informational document which obsoletes RFC 3778 provides an overview of 
the PDF format and updates the media type registration of "application/pdf" by 
aligning it with RFC 6838. I am no expert in application formats, but the 
document seems to be well informed and clearly written. A couple of nits 
generate id-nits warnings (updating RFC 3778 is not mentioned in the Abstract, 
one unused reference) that can be easily fixed during the RFC Editor processing.



Major issues:



Minor issues:



Nits/editorial comments:



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART IETF LC review of draft-ietf-hip-rfc6253-bis-08

[Romascanu, Dan (Dan)]

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair. Please wait for direction from your document shepherd or AD before 
posting a new version of the draft.



For more information, please see the FAQ at



.



Document: draft-hardy-pdf-mime-02

Reviewer: Dan Romascanu

Review Date: 07/07/16

IETF LC End Date: 07/21/16

IESG Telechat date:



Summary: Ready.



This informational document which obsoletes RFC 3778 provides an overview of 
the PDF format and updates the media type registration of "application/pdf" by 
aligning it with RFC 6838. I am no expert in application formats, but the 
document seems to be well informed and clearly written. A couple of nits 
generate id-nits warnings (updating RFC 3778 is not mentioned in the Abstract, 
one unused reference) that can be easily fixed during the RFC Editor processing.



Major issues:



Minor issues:



Nits/editorial comments:



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Telechat Review of draft-ietf-hip-rfc6253-bis-09

[Romascanu, Dan (Dan)]

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair. Please wait for direction from your document shepherd or AD before 
posting a new version of the draft.



For more information, please see the FAQ at



< https://trac.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>



Document: draft-ietf-hip-rfc6253-bis-09

Reviewer: Dan Romascanu

Review Date: 7/6/2016

IETF LC End Date: 12/28/2015

IESG Telechat date: 7/7/2016



Summary:



Ready. The issues raised in my LC review were addressed. Thank you.



Major issues:


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] draft-ietf-calext-extensions-03 (was: RE: Assignments for the 2016-06-30 Telechat)

[Romascanu, Dan (Dan)]

Perfect timing. My only pending issue is addressed. From the Gen-ART point pf 
view this document is Ready. 

Thanks and Regards,

Dan


> -Original Message-
> From: Cyrus Daboo [mailto:cy...@daboo.name]
> Sent: Wednesday, June 29, 2016 5:04 PM
> To: Romascanu, Dan (Dan); A. Jean Mahoney; General Area Review Team
> Cc: draft-ietf-calext-extensions@tools.ietf.org
> Subject: Re: draft-ietf-calext-extensions-03 (was: RE: [Gen-art] Assignments
> for the 2016-06-30 Telechat)
> 
> Hi Dan,
> 
> --On June 29, 2016 at 1:44:03 PM + "Romascanu, Dan (Dan)"
> <droma...@avaya.com> wrote:
> 
> > Hi,
> >
> > There was no update to this document since my previous review. My
> > original review raised two issues - one was clarified by explanations
> > from Alexey (thanks!); the other is about the document status (should
> > it be marked as 'Updates RFC 5545'?). I did not see that addressed. It
> > would be nice to get an answer, but I do not believe this is a show-stopper.
> 
> A new -04 version of the draft has just been published with your review
> issues addressed.
> 
> 
> --
> Cyrus Daboo

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] draft-ietf-calext-extensions-03 (was: RE: Assignments for the 2016-06-30 Telechat)

[Romascanu, Dan (Dan)]

Hi,

There was no update to this document since my previous review. My original 
review raised two issues - one was clarified by explanations from Alexey 
(thanks!); the other is about the document status (should it be marked as 
'Updates RFC 5545'?). I did not see that addressed. It would be nice to get an 
answer, but I do not believe this is a show-stopper. 

Regards,

Dan


> -Original Message-
> From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of A. Jean
> Mahoney
> Sent: Friday, June 24, 2016 1:34 AM
> To: General Area Review Team
> Subject: [Gen-art] Assignments for the 2016-06-30 Telechat
> 
> 
> Dan Romascanu 16-06-22 draft-ietf-calext-extensions-03 **
> 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC review for draft-ietf-calext-extensions-03

[Romascanu, Dan (Dan)]

Hi Alexey - thanks for the quick response. I found answers to issues 2-3 in RFC 
5545 indeed.

Issue 1 would still deserve clarification, although I do not consider it a 
show-stopper.

Regards,

Dan


From: Alexey Melnikov [mailto:alexey.melni...@isode.com]
Sent: Tuesday, June 21, 2016 4:01 PM
To: Romascanu, Dan (Dan); General Area Review Team
Cc: draft-ietf-calext-extensions@tools.ietf.org
Subject: Re: [Gen-art] Gen-ART LC review for draft-ietf-calext-extensions-03


Hi Dan,

Thank you for your review.

On 21/06/2016 12:48, Romascanu, Dan (Dan) wrote:

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



< https://trac.tools.ietf.org/area/gen/trac/wiki/GenArtfaq 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.tools.ietf.org_area_gen_trac_wiki_GenArtfaq=CwICAg=BFpWQw8bsuKpl1SgiZH64Q=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA=azY-8O9zKU_qyQsIatC9huyRk-QxiYF2J3tY-yt8SWE=Lejj6aBY4lSWw3Rk7wGB75sQItp6gprPZgz3nBBp4-c=%20>
 >.



Document: draft-ietf-calext-extensions-03

Reviewer: Dan Romascanu

Review Date: 6/21/16

IETF LC End Date: 6/22/16

IESG Telechat date: 7/7/16



Summary: A clear document, almost ready from the Gen-ART point of view. I 
recommend to clarify the two minor issues below before approval.



Major issues:



Minor issues:



1.   Should not this document be marked as 'Updates RFC 5545'? The document 
recommends that all properties not defined in 5545 always include a "VALUE" 
parameter if the type is other than "TEXT" It also modifies some existing 
properties and defines new properties and elements that bring into the standard 
extension elements added by vendors into their specification.
This is a good question. Cyrus?


2.   I had a hard time understanding some of the details in 5.7 
(REFRESH-INTERVAL Property). These may be however due to my lack of familiarity 
with the style of iCal definitions and notations - so only explanations may be 
sufficient. First I do not understand what is covered under Property 
Parameters: what means 'IANA and non-standard property parameters'
These are defined in RFC 5545. There is some text and ABNF covering these. 
Basically these property parameters are for extensibility.


3.   that can be defined here - and why here? Maybe an example would help. 
Second in the format definition: dur-value ... consisting of a positive 
duration of time - should not units be specified here as well? Last, I did not 
understand VALUE=DURATION:P1W - maybe it's just me missing the notation
I think both of these are defined in RFC 5545.

Best Regards,
Alexey

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART LC review for draft-ietf-calext-extensions-03

[Romascanu, Dan (Dan)]

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



< https://trac.tools.ietf.org/area/gen/trac/wiki/GenArtfaq 

 >.



Document: draft-ietf-calext-extensions-03

Reviewer: Dan Romascanu

Review Date: 6/21/16

IETF LC End Date: 6/22/16

IESG Telechat date: 7/7/16



Summary: A clear document, almost ready from the Gen-ART point of view. I 
recommend to clarify the two minor issues below before approval.



Major issues:



Minor issues:



1.   Should not this document be marked as 'Updates RFC 5545'? The document 
recommends that all properties not defined in 5545 always include a "VALUE" 
parameter if the type is other than "TEXT" It also modifies some existing 
properties and defines new properties and elements that bring into the standard 
extension elements added by vendors into their specification.

2.   I had a hard time understanding some of the details in 5.7 
(REFRESH-INTERVAL Property). These may be however due to my lack of familiarity 
with the style of iCal definitions and notations - so only explanations may be 
sufficient. First I do not understand what is covered under Property 
Parameters: what means 'IANA and non-standard property parameters' that can be 
defined here - and why here? Maybe an example would help. Second in the format 
definition: dur-value ... consisting of a positive duration of time - should 
not units be specified here as well? Last, I did not understand 
VALUE=DURATION:P1W - maybe it's just me missing the notation



Nits/editorial comments:



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART telechat review for draft-ietf-rtgwg-bgp-routing-large-dc

[Romascanu, Dan (Dan)]

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please wait for direction from your document shepherd or AD before 
posting a new version of the draft.



For more information, please see the FAQ at



< https://trac.tools.ietf.org/area/gen/trac/wiki/GenArtfaq 

 >.


Document: draft-ietf-rtgwg-bgp-routing-large-dc

Reviewer: Dan Romascanu

Review Date: 6/13

IETF LC End Date: 6/6

IESG Telechat date: 6/16



Summary:

The document is ready. It explains in a clear and detailed manner the 
operational experience in the design of large data centers using L3 only 
devices, Clos topology and BGP as routing protocol. I am not a routing expert, 
so I cannot validate all the statements made in the document, but the 
explanation seems clear and makes sense. The only comment I had in my IETF LC 
review was related to the lack of expansion of some of the acronyms (e.g. ASN, 
FIB ,etc.) - the issue was fixed in the revised version (11).



Major issues:



Minor issues:



Nits/editorial comments:

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-ietf-rtgwg-bgp-routing-large-dc

[Romascanu, Dan (Dan)]

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



< https://trac.tools.ietf.org/area/gen/trac/wiki/GenArtfaq 

 >.


Document: draft-ietf-rtgwg-bgp-routing-large-dc

Reviewer: Dan Romascanu

Review Date: 5/16

IETF LC End Date: N/A

IESG Telechat date: 6/2



Summary:

The document is ready. It explains in a clear and detailed manner the 
operational experience in the design of large data centers using L3 only 
devices, Clos topology and BGP as routing protocol. I am not a routing expert, 
so I cannot validate all the statements made in the document, but the 
explanation seems clear and makes sense. The only comment I have is related to 
the lack of expansion of some of the acronyms (e.g. ASN, FIB ,etc.) - even if 
they are obvious for routing experts it would help to expand them at first 
occurrence.



Major issues:



Minor issues:



Nits/editorial comments:



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] draft-ietf-rtgwg-bgp-routing-large-dc-10

[Romascanu, Dan (Dan)]

Alia, Jeff,

I am the designed Gen-ART reviewer of draft-ietf-rtgwg-bgp-routing-large-dc-10. 
I notice that this is a RTGWG document and is on the agenda of the telechat on 
5/19, but no IETF Last Call was conducted. Can you shortly explain the reasons? 
Did you intentionally decide to skip IETF LC, or is this an omission? Another 
question - this document has a strong operational topic - did it go through an 
OPS-DIR review?

Thanks and Regards,

Dan

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Geb-ART Telechat review of draft-ietf-bfd-seamless-ip-04

[Romascanu, Dan (Dan)]

Thanks – if the AD is happy, than I am happy as well.

Regards,

Dan


From: Carlos Pignataro (cpignata) [mailto:cpign...@cisco.com]
Sent: יום ד 04 מאי 2016 18:59
To: Romascanu, Dan (Dan)
Cc: General Area Review Team; draft-ietf-bfd-seamless-ip@tools.ietf.org
Subject: Re: Geb-ART Telechat review of draft-ietf-bfd-seamless-ip-04

Hi, Dan,

Thanks for following up.

Alvaro, as responsible AD, responded as you can see here: 
https://www.ietf.org/mail-archive/web/gen-art/current/msg13149.html

Thanks,

— Carlos.

On May 4, 2016, at 6:46 AM, Romascanu, Dan (Dan) 
<droma...@avaya.com<mailto:droma...@avaya.com>> wrote:

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please wait for direction from your document shepherd or AD before 
posting a new version of the draft.

For more information, please see the FAQ at

< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq >.

Document: draft-ietf-bfd-seamless-ip-04
Reviewer: Dan Romascanu
Review Date: 2016/5/4
IETF LC End Date: 2016/4/12
IESG Telechat date: 2016/5/5

Summary: Ready with one issue

The document is well written and complete, but requires a good understanding of 
BFD (RFC 5880, RFC 5881) and of the use-cases 
(draft-ietf-bfd-seamless-use-case) document.

In my initial review I raised two issues. One was accepted and an editorial 
change was made in draft-04. The second one was:

-  This document extends the usage of port 3785 adding the function of 
being the destination port for the S-BFD echo packets. Should not this be 
regarded as an update of RFC 5881 and mentioned as such on the front page?

The authors answered the following:

-  I do not have a strong opinion one way or another — I will leave 
this one to the AD’s guidance, and I am happy to mark this document as updating 
RFC 5881 if that’s the preferred direction

No change was made. I would like to make sure that the responsible AD has seen 
this comment. It’s not a show-stopper, but I still believe that marking this 
document as an update to RFC 5881 is better.

Major issues:

Minor issues:

Nits/editorial comments:

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Geb-ART Telechat review of draft-ietf-bfd-seamless-ip-04

[Romascanu, Dan (Dan)]

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please wait for direction from your document shepherd or AD before 
posting a new version of the draft.

For more information, please see the FAQ at

< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq >.

Document: draft-ietf-bfd-seamless-ip-04
Reviewer: Dan Romascanu
Review Date: 2016/5/4
IETF LC End Date: 2016/4/12
IESG Telechat date: 2016/5/5

Summary: Ready with one issue

The document is well written and complete, but requires a good understanding of 
BFD (RFC 5880, RFC 5881) and of the use-cases 
(draft-ietf-bfd-seamless-use-case) document.

In my initial review I raised two issues. One was accepted and an editorial 
change was made in draft-04. The second one was:


-  This document extends the usage of port 3785 adding the function of 
being the destination port for the S-BFD echo packets. Should not this be 
regarded as an update of RFC 5881 and mentioned as such on the front page?

The authors answered the following:


-  I do not have a strong opinion one way or another - I will leave 
this one to the AD's guidance, and I am happy to mark this document as updating 
RFC 5881 if that's the preferred direction

No change was made. I would like to make sure that the responsible AD has seen 
this comment. It's not a show-stopper, but I still believe that marking this 
document as an update to RFC 5881 is better.

Major issues:

Minor issues:

Nits/editorial comments:


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Review of draft-ietf-bfd-seamless-ip-03

[Romascanu, Dan (Dan)]

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq >.



Document: draft-ietf-bfd-seamless-ip-03

Reviewer: Dan Romascanu

Review Date: 2016/3/29

IETF LC End Date: 2016/4/12

IESG Telechat date: 2016/5/5



Summary: Ready with minor issues



The document is well written and complete, but requires a good understanding of 
BFD (RFC 5880, RFC 5881) and of the use-cases 
(draft-ietf-bfd-seamless-use-case) document. A few minor issues are listed 
below, it would be good to address them, but none is a show-stopper.



Major issues:



Minor issues:



1.   This document extends the usage of port 3785 adding the function of 
being the destination port for the S-BFD echo packets. Should not this be 
regarded as an update of RFC 5881 and mentioned as such on the front page?

2.   In the IANA considerations section - when this I-D is approved and 
becomes an RFC, should not the Reference (REQUIRED) become this RFC - a more 
stable reference that the draft-akiya-bfd-seamless-ip?



Nits/editorial comments:


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-ietf-bfd-seamless-base-08

[Romascanu, Dan (Dan)]

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq >.



Document: draft-ietf-bfd-seamless-base-08

Reviewer: Dan Romascanu

Review Date: 2016/3/29

IETF LC End Date: 2016/4/12

IESG Telechat date: 2016/5/5



Summary: Ready with minor issues



The document is well written and complete, but requires a good understanding of 
BFD (RFC 5880) and of the use-cases (draft-ietf-bfd-seamless-use-case) 
document. A few minor issues are listed below, it would be good to address 
them, but none is a show-stopper.



Major issues:



Minor issues:



1.   In the introduction I see the following:



Ø One key aspect of the mechanism described in this document eliminates
   the time between a network node wanting to perform a continuity test
   and completing the continuity test.



I am wondering if this is really what is intended. If I understand correctly, 
S-BFD does not eliminate the continuity test but the set-up states transitions 
before the continuity test starts. Would not that rather be '... and starting 
the continuity test.'?



2.   In the last paragraph of Section 5:



Ø  Note that incoming S-BFD control packets may be IPv4, IPv6 or MPLS
   based.



If these are the only three options I suggest that the text explicitly specify 
this. If other options are possible or may be possible in the future I suggest 
that the text also clarifies this



Nits/editorial comments:


1.   Second paragraph in Section 3: s/allocated toby a remote 
node/allocated to by a remote node/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] IANA and AUTH48 (Was: Re: Gen-ART LC review of draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-02)

[Romascanu, Dan (Dan)]

Of course. It's just that sometimes ADs (maybe not nowadays, but I may have 
sinned once or more when I was an AD) leave 'simple' edits to the RFC Editor. 
Which should be fine unless you forget to mention these in the RFC Editor notes 
:-) 

Regards,

Dan


> -Original Message-
> From: joel jaeggli [mailto:joe...@bogus.com]
> Sent: Monday, March 21, 2016 6:00 PM
> To: Romascanu, Dan (Dan); Jari Arkko; The IESG
> Cc: General Area Review Team; draft-ietf-opsawg-hmac-sha-2-usm-snmp-



> To be clear though In general I'd vastly prefer to send a document to the rfc
> editor that is correct. so holding for edits seems like the most appropriate
> first order step.
> 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] IANA and AUTH48 (Was: Re: Gen-ART LC review of draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-02)

[Romascanu, Dan (Dan)]

Hi,

Obviously, an explicit RFC Editor note would solve the problem in the majority 
if not all the foreseeable cases. The burden is on the AD and to some extent to 
the IESG who should minute the decision as 'Approved. RFC Editor Note.' and 
maybe add 'IANA-related edit' in the minutes to make sure the issue is not 
forgotten (there may be multiple items in the RFC Editor notes). 

Regards,

Dan
 

> -Original Message-
> From: Jari Arkko [mailto:jari.ar...@piuha.net]
> Sent: Thursday, March 17, 2016 10:12 AM
> To: Romascanu, Dan (Dan); The IESG
> Cc: General Area Review Team; draft-ietf-opsawg-hmac-sha-2-usm-snmp-
> new@tools.ietf.org
> Subject: IANA and AUTH48 (Was: Re: [Gen-art] Gen-ART LC review of draft-
> ietf-opsawg-hmac-sha-2-usm-snmp-new-02)
> 
> (Adding the IESG)
> 
> First, thanks for the review, Dan! I have balloted no-obj.
> 
> As for the question about IANA and AUTH48, I'm a bit conflicted there. More
> checking is good, but I don't want to add more things to do in AUTH48.
> 
> But I'd like to understand where the issue really was. I guess the issue was
> that a discussion between the authors and IANA resulted in doing the right
> thing, but no body remembered to bring the update back to the I-D.
> 
> I don't know when this happened, but it could already have happened while
> the document was in IESG processing.
> 
> This seems to be a more general problem, in that we often say "we'll fix it in
> AUTH48", but don't actually edit docs or place RFC Ed notes. I'd like to
> suggest that whenever we plan to do something in AUTH48, at least an RFC
> Editor's note about the matter (not necessarily the final edit) needs to be
> added to the tracker before approval. This ensures that the RFC Editor would
> see the issue.
> 
> Thoughts?
> 
> Jari
> 
> On 18 Jan 2016, at 11:54, Romascanu, Dan (Dan) <droma...@avaya.com>
> wrote:
> 
> > I am the assigned Gen-ART reviewer for this draft. The General Area
> > Review Team (Gen-ART) reviews all IETF documents being processed by
> > the IESG for the IETF Chair.  Please treat these comments just like
> > any other last call comments.
> >
> > For more information, please see the FAQ at
> >
> > http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq
> >
> > Document: draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-02.txt
> > Reviewer: Dan Romascanu
> > Review Date: 1/18/16
> > IETF LC End Date: 1/18/16
> > IESG Telechat date: (if known):
> >
> > Summary:
> >
> > Ready.
> >
> > This document is an update that fixes a problem with RFC 7360 where
> MODULE-IDENTITY was defined as { snmpModules 235 } rather than { mib-2
> 235 } as advised by the MIB Doctors and recommended by IANA. The rest of
> the content is identical with RFC 7360.
> >
> >
> > Major issues:
> >
> > There is a process issue that the IESG, IANA and the RFC Editor should
> check (maybe they already did it) in order to avoid such situations in the
> future. Is IANA involved in AUTH 48 last review of the document? If they are
> not, maybe they should be. In this case the MIB Doctors recommendation
> was implemented by IANA in the registry, but the content of the document
> was not fixed, and nobody at AUTH 48 discovered the problem.
> >
> > Minor issues:
> >
> > Nits/editorial comments:
> >
> >
> > ___
> > Gen-art mailing list
> > Gen-art@ietf.org
> > https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-ietf-tsvwg-behave-requirements-update

[Romascanu, Dan (Dan)]

Thank you for the quick update. All the (minor) issues that I raised were 
addressed. From the Gen-ART point of view this document is ready.

Regards,

Dan


From: mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com]
Sent: Tuesday, February 16, 2016 11:04 AM
To: Romascanu, Dan (Dan); General Area Review Team
Cc: draft-ietf-tsvwg-behave-requirements-update@tools.ietf.org
Subject: RE: Gen-ART review of draft-ietf-tsvwg-behave-requirements-update

Hi Dan,

FWIW, an updated version integrating your comments is available online:

URL:
https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-behave-requirements-update-07.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dietf-2Dtsvwg-2Dbehave-2Drequirements-2Dupdate-2D07.txt=BQMFAw=BFpWQw8bsuKpl1SgiZH64Q=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA=0qyKTXEWRvvAYjVyo0MxjLa8JvZ4zy_ZU8cEPgVUnqU=CpStSt24iP_FQr8EReGKp-eoCAGaZPuHAIuS-3W56DE=>
Status: 
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-behave-requirements-update/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtsvwg-2Dbehave-2Drequirements-2Dupdate_=BQMFAw=BFpWQw8bsuKpl1SgiZH64Q=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA=0qyKTXEWRvvAYjVyo0MxjLa8JvZ4zy_ZU8cEPgVUnqU=TItSLr3x5EUoFzZU9nBKy6SU4sSHQmC16ZjOSaRuv_8=>
Htmlized:   
https://tools.ietf.org/html/draft-ietf-tsvwg-behave-requirements-update-07<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtsvwg-2Dbehave-2Drequirements-2Dupdate-2D07=BQMFAw=BFpWQw8bsuKpl1SgiZH64Q=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA=0qyKTXEWRvvAYjVyo0MxjLa8JvZ4zy_ZU8cEPgVUnqU=M5GiCIgxCYHAX2gO2obdN0JLk9-p28WBwo_ssSWUaP0=>
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-behave-requirements-update-07<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dtsvwg-2Dbehave-2Drequirements-2Dupdate-2D07=BQMFAw=BFpWQw8bsuKpl1SgiZH64Q=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA=0qyKTXEWRvvAYjVyo0MxjLa8JvZ4zy_ZU8cEPgVUnqU=2CGxScRN0aajF_jrT99wlwBtF67oPM_UeSdERu_LoCM=>

Thank you.

Cheers,
Med

De : Romascanu, Dan (Dan) [mailto:droma...@avaya.com]
Envoyé : lundi 15 février 2016 17:31
À : BOUCADAIR Mohamed IMT/OLN; General Area Review Team
Cc : 
draft-ietf-tsvwg-behave-requirements-update@tools.ietf.org<mailto:draft-ietf-tsvwg-behave-requirements-update@tools.ietf.org>
Objet : RE: Gen-ART review of draft-ietf-tsvwg-behave-requirements-update

Hi Med,

Thank you for the quick answer and for addressing my comments. Your suggestions 
are fine with me.

Regards,

Dan


From: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> 
[mailto:mohamed.boucad...@orange.com]
Sent: Monday, February 15, 2016 6:29 PM
To: Romascanu, Dan (Dan); General Area Review Team
Cc: 
draft-ietf-tsvwg-behave-requirements-update@tools.ietf.org<mailto:draft-ietf-tsvwg-behave-requirements-update@tools.ietf.org>
Subject: RE: Gen-ART review of draft-ietf-tsvwg-behave-requirements-update

Hi Dan,

Thank you for the review.

Please see inline.

Cheers,
Med

De : Romascanu, Dan (Dan) [mailto:droma...@avaya.com]
Envoyé : lundi 15 février 2016 17:18
À : General Area Review Team
Cc : 
draft-ietf-tsvwg-behave-requirements-update@tools.ietf.org<mailto:draft-ietf-tsvwg-behave-requirements-update@tools.ietf.org>
Objet : Gen-ART review of draft-ietf-tsvwg-behave-requirements-update


I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



< 
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq<https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.tools.ietf.org_area_gen_trac_wiki_GenArtfaq=BQMFAw=BFpWQw8bsuKpl1SgiZH64Q=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA=ZC04CHRXTc4mZGTQ1SDzY8k4-iq-WKS6FwdW1xbjofw=faCxz22-2duDulDbAWv3aWHO3iJ5naIHyqseY1pxc40=>>



Document:  draft-ietf-tsvwg-behave-requirements-update-06

Reviewer: Dan Romascanu

Review Date: 2/15/16

IETF LC End Date: 2/16/16

IESG Telechat date:



Summary: This document is ready with minor issues.



Major issues:



None



Minor issues:



1.   The text in the second and third paragraphs in section 2.2 is rather 
confusing. Do these belong to updates, or should they be under Notes?



Ø  Admittedly, the NAT has to verify whether received TCP RST packets belong to 
a connection. This verification check is required to avoid off-path attacks.



Ø  If the NAT removes immediately the NAT mapping upon receipt of a TCP RST 
message, stale connections may be maintained by endpoints if the first RST 
message is lost between the NAT and the recipient.



If they belong to Updates 'Admittedly' needs to be d

Re: [Gen-art] Gen-ART review of draft-ietf-tsvwg-behave-requirements-update

[Romascanu, Dan (Dan)]

Hi Med,

Thank you for the quick answer and for addressing my comments. Your suggestions 
are fine with me.

Regards,

Dan


From: mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com]
Sent: Monday, February 15, 2016 6:29 PM
To: Romascanu, Dan (Dan); General Area Review Team
Cc: draft-ietf-tsvwg-behave-requirements-update@tools.ietf.org
Subject: RE: Gen-ART review of draft-ietf-tsvwg-behave-requirements-update

Hi Dan,

Thank you for the review.

Please see inline.

Cheers,
Med

De : Romascanu, Dan (Dan) [mailto:droma...@avaya.com]
Envoyé : lundi 15 février 2016 17:18
À : General Area Review Team
Cc : 
draft-ietf-tsvwg-behave-requirements-update@tools.ietf.org<mailto:draft-ietf-tsvwg-behave-requirements-update@tools.ietf.org>
Objet : Gen-ART review of draft-ietf-tsvwg-behave-requirements-update


I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



< 
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq<https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.tools.ietf.org_area_gen_trac_wiki_GenArtfaq=BQMFAw=BFpWQw8bsuKpl1SgiZH64Q=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA=ZC04CHRXTc4mZGTQ1SDzY8k4-iq-WKS6FwdW1xbjofw=faCxz22-2duDulDbAWv3aWHO3iJ5naIHyqseY1pxc40=>>



Document:  draft-ietf-tsvwg-behave-requirements-update-06

Reviewer: Dan Romascanu

Review Date: 2/15/16

IETF LC End Date: 2/16/16

IESG Telechat date:



Summary: This document is ready with minor issues.



Major issues:



None



Minor issues:



1.   The text in the second and third paragraphs in section 2.2 is rather 
confusing. Do these belong to updates, or should they be under Notes?



Ø  Admittedly, the NAT has to verify whether received TCP RST packets belong to 
a connection. This verification check is required to avoid off-path attacks.



Ø  If the NAT removes immediately the NAT mapping upon receipt of a TCP RST 
message, stale connections may be maintained by endpoints if the first RST 
message is lost between the NAT and the recipient.



If they belong to Updates 'Admittedly' needs to be dropped, 'has to verify' 
becomes 'SHOULD verify', etc.

Else, if these are rather notes they should be labeled Notes or Clarification



[Med] These are notes. What about making this change?



OLD:


  Admittedly, the NAT has to verify whether received TCP RST packets
  belong to a connection.  This verification check is required to
  avoid off-path attacks.

  If the NAT removes immediately the NAT mapping upon receipt of a
  TCP RST message, stale connections may be maintained by endpoints
  if the first RST message is lost between the NAT and the
  recipient.



NEW:



  Notes:

  *   Admittedly, the NAT has to verify whether received TCP RST packets

  belong to a connection.  This verification check is required to

  avoid off-path attacks.



  * If the NAT removes immediately the NAT mapping upon receipt of a

  TCP RST message, stale connections may be maintained by endpoints

  if the first RST message is lost between the NAT and the

  recipient.







2.   In section 5:



Ø  This update is compliant with the stateful NAT64 [RFC6146] that clearly 
specifies three binding information bases (TCP, UDP, ICMP).



As the focus of this document is NAT44, I do not believe that 'compliant' is 
the right word. Probably 'consistent' would be more appropriate.



[Med] I changed it to "consistent" in my local copy. Thank you for catching 
this.



3.   EIF is never expanded

[Med] Fixed.



Nits/editorial comments:


None.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-ietf-tsvwg-behave-requirements-update

[Romascanu, Dan (Dan)]

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>



Document:  draft-ietf-tsvwg-behave-requirements-update-06

Reviewer: Dan Romascanu

Review Date: 2/15/16

IETF LC End Date: 2/16/16

IESG Telechat date:



Summary: This document is ready with minor issues.



Major issues:



None



Minor issues:



1.   The text in the second and third paragraphs in section 2.2 is rather 
confusing. Do these belong to updates, or should they be under Notes?



Ø  Admittedly, the NAT has to verify whether received TCP RST packets belong to 
a connection. This verification check is required to avoid off-path attacks.



Ø  If the NAT removes immediately the NAT mapping upon receipt of a TCP RST 
message, stale connections may be maintained by endpoints if the first RST 
message is lost between the NAT and the recipient.



If they belong to Updates 'Admittedly' needs to be dropped, 'has to verify' 
becomes 'SHOULD verify', etc.

Else, if these are rather notes they should be labeled Notes or Clarification



2.   In section 5:



Ø  This update is compliant with the stateful NAT64 [RFC6146] that clearly 
specifies three binding information bases (TCP, UDP, ICMP).



As the focus of this document is NAT44, I do not believe that 'compliant' is 
the right word. Probably 'consistent' would be more appropriate.



3.   EIF is never expanded



Nits/editorial comments:


None.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Telechat Gen-ART review for draft-ietf-ippm-checksum-trailer-05

[Romascanu, Dan (Dan)]

Hi,

This document is again on the agenda of the 2/4 telechat. My previous Telechat 
review stands. The document is ready.

Thanks and Regards,

Dan


From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Romascanu, Dan 
(Dan)
Sent: Wednesday, January 06, 2016 5:09 PM
To: General Area Review Team
Cc: draft-ietf-ippm-checksum-trailer@tools.ietf.org
Subject: Re: [Gen-art] Telechat Gen-ART review for 
draft-ietf-ippm-checksum-trailer-05

This document is on the agenda of the telechat tomorrow. My previous Telechat 
review stands. The document is ready.

Thanks and Regards,

Dan


From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Romascanu, Dan 
(Dan)
Sent: Monday, November 30, 2015 3:59 PM
To: General Area Review Team
Cc: 
draft-ietf-ippm-checksum-trailer@tools.ietf.org<mailto:draft-ietf-ippm-checksum-trailer@tools.ietf.org>
Subject: [Gen-art] Telechat Gen-ART review for 
draft-ietf-ippm-checksum-trailer-05


I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq<https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.tools.ietf.org_area_gen_trac_wiki_GenArtfaq=BQMFAw=BFpWQw8bsuKpl1SgiZH64Q=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA=NMPxI88b49Rd87R2XmkgqLhVC4Bz2IhydB-0MwJ2T0s=LW6pxGWbYoxVERnO34-bGIf3JGqbGPADKYJ0QzhJ_Ms=>



Document: draft-ietf-ippm-checksum-trailer-05

Reviewer:  Dan Romascanu

Review Date: 11/30/15

IETF LC End Date: 10/28/15

IESG Telechat date: 12/3/15



Summary: Ready



The document is ready, the (minor) issues raised in my previous review were all 
addressed.



Major issues:



Minor issues:



Nits/editorial comments:


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq

[Romascanu, Dan (Dan)]

I am the assigned Gen-ART reviewer for this draft. The General Area

Review Team (Gen-ART) reviews all IETF documents being processed

by the IESG for the IETF Chair.  Please treat these comments just

like any other last call comments.



For more information, please see the FAQ at



http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq



Document: draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-02.txt

Reviewer: Dan Romascanu

Review Date: 1/18/16

IETF LC End Date: 1/18/16

IESG Telechat date: (if known):



Summary:



Ready.



This document is an update that fixes a problem with RFC 7360 where 
MODULE-IDENTITY was defined as { snmpModules 235 } rather than { mib-2 235 } as 
advised by the MIB Doctors and recommended by IANA. The rest of the content is 
identical with RFC 7360.





Major issues:



There is a process issue that the IESG, IANA and the RFC Editor should check 
(maybe they already did it) in order to avoid such situations in the future. Is 
IANA involved in AUTH 48 last review of the document? If they are not, maybe 
they should be. In this case the MIB Doctors recommendation was implemented by 
IANA in the registry, but the content of the document was not fixed, and nobody 
at AUTH 48 discovered the problem.



Minor issues:



Nits/editorial comments:



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART LC review of draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-02

[Romascanu, Dan (Dan)]

I am the assigned Gen-ART reviewer for this draft. The General Area

Review Team (Gen-ART) reviews all IETF documents being processed

by the IESG for the IETF Chair.  Please treat these comments just

like any other last call comments.



For more information, please see the FAQ at



http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq



Document: draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-02.txt

Reviewer: Dan Romascanu

Review Date: 1/18/16

IETF LC End Date: 1/18/16

IESG Telechat date: (if known):



Summary:



Ready.



This document is an update that fixes a problem with RFC 7360 where 
MODULE-IDENTITY was defined as { snmpModules 235 } rather than { mib-2 235 } as 
advised by the MIB Doctors and recommended by IANA. The rest of the content is 
identical with RFC 7360.





Major issues:



There is a process issue that the IESG, IANA and the RFC Editor should check 
(maybe they already did it) in order to avoid such situations in the future. Is 
IANA involved in AUTH 48 last review of the document? If they are not, maybe 
they should be. In this case the MIB Doctors recommendation was implemented by 
IANA in the registry, but the content of the document was not fixed, and nobody 
at AUTH 48 discovered the problem.



Minor issues:



Nits/editorial comments:



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART LC Review of draft-ietf-hip-rfc6253-bis-06

[Romascanu, Dan (Dan)]

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq 

 >.



Document: draft-ietf-hip-rfc6253-bis-06

Reviewer: Dan Romascanu

Review Date: 1/7/2016

IETF LC End Date: 12/28/2015

IESG Telechat date:



Summary: On the right track



The document is well structured, but there are a number of issues that must be 
fixed before it is approved by the IESG.



Major issues:



1.   The Type number values mentioned in Section 2 (after the certificate 
types table) refer to the values in RFC 6253 (that go to 8) and not in the 
values in this document.

2.   The IANA Considerations section needs in my opinion to be re-written. 
RFC 6263 was an Experimental RFC, this document has an Intended Status of 
Standards Track, it cannot just refer to the content of the document that it is 
obsoleting.

3.   A new Certificate type registry needs to be defined in my opinion. 
Older values in the registry were 0 to 8, this document should not use values 
of 0 to 4 in the same registry while some of the values have different 
semantics.



Minor issues:



1.   The front page does not provide the initials of the first name of the 
authors. This may seem a nit, but there may be tools that are used with 
processing the initials of the authors name.

2.   Inconsistent use of CERT (the parameter in RFC 7401) and Cert (as in 
Cert group, Cert count, etc.). Any special reason not to write consistently 
CERT every place?

3.   I am missing a section that would remain in the document (unlike 
Appendix B which I suspect will be taken out at publication) and that shortly 
lists the changes from RFC 6253 and their motivation.



Nits/editorial comments:



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Telechat Gen-ART review for draft-ietf-ippm-checksum-trailer-05

[Romascanu, Dan (Dan)]

This document is on the agenda of the telechat tomorrow. My previous Telechat 
review stands. The document is ready.

Thanks and Regards,

Dan


From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Romascanu, Dan 
(Dan)
Sent: Monday, November 30, 2015 3:59 PM
To: General Area Review Team
Cc: draft-ietf-ippm-checksum-trailer@tools.ietf.org
Subject: [Gen-art] Telechat Gen-ART review for 
draft-ietf-ippm-checksum-trailer-05


I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq<https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.tools.ietf.org_area_gen_trac_wiki_GenArtfaq=BQMFAw=BFpWQw8bsuKpl1SgiZH64Q=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA=NMPxI88b49Rd87R2XmkgqLhVC4Bz2IhydB-0MwJ2T0s=LW6pxGWbYoxVERnO34-bGIf3JGqbGPADKYJ0QzhJ_Ms=>



Document: draft-ietf-ippm-checksum-trailer-05

Reviewer:  Dan Romascanu

Review Date: 11/30/15

IETF LC End Date: 10/28/15

IESG Telechat date: 12/3/15



Summary: Ready



The document is ready, the (minor) issues raised in my previous review were all 
addressed.



Major issues:



Minor issues:



Nits/editorial comments:


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Telechat Review of draft-leiba-netmod-regpolicy-update-02

[Romascanu, Dan (Dan)]

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq



Document: draft-leiba-netmod-regpolicy-update-02

Reviewer:  Dan Romascanu

Review Date: 01/06/16

IETF LC End Date: 12/21/15

IESG Telechat date: 01/07/16



Summary: Ready



A short, clear and useful document. The issue raised in the first Gen-ART 
review was addressed with appropriate edits.



Major issues:



Minor issues:



Nits/editorial comments:


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Telechat Review of

[Romascanu, Dan (Dan)]

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq



Document: draft-ietf-appsawg-http-problem-02

Reviewer:  Dan Romascanu

Review Date: 12/15/15

IETF LC End Date: 12/4/15

IESG Telechat date: 12/17/15



Summary: Ready



A very useful, clear and well written document.



The only minor issue that I raised in my first review was clarified in an email 
exchange and no edits were required.



Major issues:



Minor issues:



Nits/editorial comments:


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Telechat Review of draft-ietf-appsawg-http-problem-02

[Romascanu, Dan (Dan)]

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq



Document: draft-ietf-appsawg-http-problem-02

Reviewer:  Dan Romascanu

Review Date: 12/15/15

IETF LC End Date: 12/4/15

IESG Telechat date: 12/17/15



Summary: Ready



A very useful, clear and well written document.



The only minor issue that I raised in my first review was clarified in an email 
exchange and no edits were required.



Major issues:



Minor issues:



Nits/editorial comments:


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Review of draft-leiba-netmod-regpolicy-update-01

[Romascanu, Dan (Dan)]

Hi Barry,

Thanks for the quick reply and for addressing my comment. 

> Should IETF consensus be to accept a registration
> from an Informational document, that's fine.
> Perhaps it's not likely, but that'd be up to the consensus of the IETF, which 
> is
> the point here.

I am fine with this approach but this is not what the text of the 
'motivational' part of the Internet-Draft says. Currently there is an 
a-synchronism between the text that explains what the I-D tries to do and the 
action it recommends. 

Regards,

Dan


> -Original Message-
> From: barryle...@gmail.com [mailto:barryle...@gmail.com] On Behalf Of
> Barry Leiba
> Sent: Monday, December 14, 2015 4:26 PM
> To: Romascanu, Dan (Dan)
> Cc: General Area Review Team; draft-leiba-netmod-regpolicy-
> update@tools.ietf.org
> Subject: Re: Gen-ART Review of draft-leiba-netmod-regpolicy-update-01
> 
> > The problem is that the “IETF Review” policy is not restricted to
> > Experimental RFCs which seems to be the motivation of the document.
> > Informational RFCs can also be subject to IETF Review for example. The
> > IANA Considerations section does either instruct IANA to consider only
> > Standards Track and Experimental RFCs. I believe that this needs to be
> > clarified in Section 2, and the registry be marked “IETF Review – see
> > [RFC ]” so that people asking for allocation be directed to the
> clarification of the policy.
> 
> I believe that no clarification is needed.  There's no reason at all to put
> restrictions on registrations beyond what IETF consensus is at the time the
> registration is requested.  Should IETF consensus be to accept a registration
> from an Informational document, that's fine.
> Perhaps it's not likely, but that'd be up to the consensus of the IETF, which 
> is
> the point here.
> 
> The non-normative text you cite describes what prompted us to do this.
> The normative text is the description of IETF Review in BCP 26.
> 
> Barry


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Review of draft-leiba-netmod-regpolicy-update-01

[Romascanu, Dan (Dan)]

This looks good to me. 

Thanks and Regards,

Dan


> -Original Message-
> From: barryle...@gmail.com [mailto:barryle...@gmail.com] On Behalf Of
> Barry Leiba
> Sent: Monday, December 14, 2015 6:26 PM
> To: Romascanu, Dan (Dan)
> Cc: General Area Review Team; draft-leiba-netmod-regpolicy-
> update@tools.ietf.org
> Subject: Re: Gen-ART Review of draft-leiba-netmod-regpolicy-update-01
> 
> > I am fine with this approach but this is not what the text of the
> 'motivational' part of the Internet-Draft says. Currently there is an a-
> synchronism between the text that explains what the I-D tries to do and the
> action it recommends.
> 
> OK, well, you know I'm always in favour of more clarity.  So how does this
> sound?:
> 
> OLD
>This document changes that
>registration policy to "IETF Review", which also allows registrations
>from certain well reviewed Experimental RFCs.
> 
> NEW
>This document changes that
>registration policy to "IETF Review", which also allows registrations
>from certain well reviewed Experimental RFCs, or, for example,
>corrections to registry errors from Informational RFCs, with IETF
>review and consensus.
> 
> END
> 
> Barry
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Telechat Gen-ART review for draft-ietf-ippm-checksum-trailer-05

[Romascanu, Dan (Dan)]

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq



Document: draft-ietf-ippm-checksum-trailer-05

Reviewer:  Dan Romascanu

Review Date: 11/30/15

IETF LC End Date: 10/28/15

IESG Telechat date: 12/3/15



Summary: Ready



The document is ready, the (minor) issues raised in my previous review were all 
addressed.



Major issues:



Minor issues:



Nits/editorial comments:


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of 04 draft-ietf-appsawg-http-problem-01

[Romascanu, Dan (Dan)]

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq



Document: draft-ietf-appsawg-http-problem-01

Reviewer:  Dan Romascanu

Review Date: 11/30/15

IETF LC End Date: 12/4/15

IESG Telechat date:



Summary: Ready (with one clarification question).



A very useful, clear and well written document.



Major issues:



Minor issues:



One question which may be a matter of clarification rather than an issue:



In Section 3:



Ø  If such additional members are defined, their names SHOULD start with a 
letter (ALPHA, as per [RFC5234]) and SHOULD consist of characters from ALPHA, 
DIGIT, and "_" (so that it can be serialized in formats other than JSON), and 
SHOULD be three characters or longer.



What is the rationale here for the SHOULDs? What are the exception cases that 
require using SHOULD rather than MUST in this paragraph?



Nits/editorial comments:

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review for draft-ietf-ippm-checksum-trailer-03

[Romascanu, Dan (Dan)]

Hi Al,

Thanks for the explanation, this helped me a lot.


1.   It may be useful to insert a paragraph that provides this explanation

2.   Makes sense - no change needed.

Regards,

Dan


From: MORTON, ALFRED C (AL) [mailto:acmor...@att.com]
Sent: Friday, October 23, 2015 1:32 AM
To: Romascanu, Dan (Dan); General Area Review Team
Cc: draft-ietf-ippm-checksum-trailer@tools.ietf.org
Subject: RE: Gen-ART review for draft-ietf-ippm-checksum-trailer-03

Hi Dan,
I'll wade-in as Document Shepherd and begin to answer your questions,
Al

1.   It is not clear to me how backwards compatibility is ensured. How do 
implementations make distinction between OWAMP or TWAMP packets that use 
timestamp update and Checksum Complement rather than timestamp update and UDP 
checksum update? Is a mix of senders/receivers (for OWAMP) or 
senders/reflectors (for TWAMP) that some support and some do not support 
Checksum Complement possible?

[ACM]
Yes, the mix is possible, because the receiver stack performs normally
and evaluates checksums. Inserting the time stamp at a lower layer and
keeping the checksum accurate by providing the checksum-complement octets at the
same lower layer is a sender-only process.

2.   The last paragraph in section 4 reads: 'The concept described in this 
document is intended to be used only in unauthenticated or in authenticated 
mode.' This seems either a mistake, or I did not understand what it means and 
some clarification is needed.

[ACM]
In OWAMP and TWAMP, there are three Modes of operation for the Core protocol
(without optional extensions):
Unauthenticated (completely in the clear)
Authenticated
Encrypted

Authenticated mode does not calculate the HMAC over the timestamps and packet 
padding
fields in the Test Session packets, where checksum complement is used.
So, after lower layer placement of the timestamp and checksum-complement,
the HMAC is still valid.

Encrypted Mode requires the Timestamps of test packets to be encrypted,
so timestamps cannot be inserted at lower layers before transmission,
(unless you are also re-encrypting, then the checksum complement has little 
value,
as Tal points out).

Section 3.4 explains this, and provides limited *WAMP background
on the modes.

Hope this helps,
Al



From: Romascanu, Dan (Dan) [mailto:droma...@avaya.com]
Sent: Thursday, October 22, 2015 11:55 AM
To: General Area Review Team
Cc: 
draft-ietf-ippm-checksum-trailer@tools.ietf.org<mailto:draft-ietf-ippm-checksum-trailer@tools.ietf.org>
Subject: Gen-ART review for draft-ietf-ippm-checksum-trailer-03


I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



< 
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq<https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.tools.ietf.org_area_gen_trac_wiki_GenArtfaq=BQMFAg=BFpWQw8bsuKpl1SgiZH64Q=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA=nJVpve6nf4_IRNZwgYgb3Wvwua190G7VDeX_tVtAfcY=77sOZhtQIK_EQ0NICPaIIQs0bTXgAPQT9SLzjuCjoyE=>>.



Document: draft-ietf-ippm-checksum-trailer-03

Reviewer: Dan Romascanu

Review Date: 10/22/15

IETF LC End Date: N/A

IESG Telechat date: N/A



Summary:



This document is ready for publication. I have a couple of minor issues that 
need clarification and can be solved easily by minor editing.



Major issues:



Minor issues:



1.   It is not clear to me how backwards compatibility is ensured. How do 
implementations make distinction between OWAMP or TWAMP packets that use 
timestamp update and Checksum Complement rather than timestamp update and UDP 
checksum update? Is a mix of senders/receivers (for OWAMP) or 
senders/reflectors (for TWAMP) that some support and some do not support 
Checksum Complement possible?

2.   The last paragraph in section 4 reads: 'The concept described in this 
document is intended to be used only in unauthenticated or in authenticated 
mode.' This seems either a mistake, or I did not understand what it means and 
some clarification is needed.



Nits/editorial comments:



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review for draft-ietf-ippm-checksum-trailer-03

[Romascanu, Dan (Dan)]

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.



Document: draft-ietf-ippm-checksum-trailer-03

Reviewer: Dan Romascanu

Review Date: 10/22/15

IETF LC End Date: N/A

IESG Telechat date: N/A



Summary:



This document is ready for publication. I have a couple of minor issues that 
need clarification and can be solved easily by minor editing.



Major issues:



Minor issues:



1.   It is not clear to me how backwards compatibility is ensured. How do 
implementations make distinction between OWAMP or TWAMP packets that use 
timestamp update and Checksum Complement rather than timestamp update and UDP 
checksum update? Is a mix of senders/receivers (for OWAMP) or 
senders/reflectors (for TWAMP) that some support and some do not support 
Checksum Complement possible?

2.   The last paragraph in section 4 reads: 'The concept described in this 
document is intended to be used only in unauthenticated or in authenticated 
mode.' This seems either a mistake, or I did not understand what it means and 
some clarification is needed.



Nits/editorial comments:



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-ietf-v6ops-siit-eam-01

[Romascanu, Dan (Dan)]

Looks good to me. Thanks again for addressing my comment. 

Regards,

Dan


> -Original Message-
> From: Tore Anderson [mailto:t...@redpill-linpro.com]
> Sent: Thursday, October 15, 2015 11:27 AM
> To: Jari Arkko
> Cc: Romascanu, Dan (Dan); General Area Review Team; draft-ietf-v6ops-siit-
> eam@tools.ietf.org
> Subject: Re: [Gen-art] Gen-ART review of draft-ietf-v6ops-siit-eam-01
> 
> * Jari Arkko
> 
> > >When translating a packet between IPv4 and IPv6, an SIIT
> > >implementation MUST individually translate each IP address it
> > >encounters in the packet's IP headers (including any IP headers
> > >contained within ICMP errors) according to Section 3.3, except for
> > >any address for which Section 4 explicitly states that the EAM
> > >algorithm MUST NOT be used.
> >
> > I think this makes sense, and I at least feel this is better text than
> > the original. Thanks.
> 
> Hello Jari,
> 
> My co-author felt the above was a bit too "conjunction-overflowy", so we
> ended up with the following:
> 
>Unless otherwise specified in Section 4, an SIIT implementation MUST
>individually translate each IP address it encounters in the packet's
>IP headers (including any IP headers contained within ICMP errors)
>according to Section 3.3.
> 
> This is in draft-ietf-v6ops-siit-eam-02. I hope you see this too as an
> improvement over the original?
> 
> Tore

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] New Version Notification for draft-ietf-ospf-rfc4970bis-06.txt

[Romascanu, Dan (Dan)]

Thank you for addressing my comments in a fast and efficient manner. 

Regards,

Dan


> -Original Message-
> From: Acee Lindem (acee) [mailto:a...@cisco.com]
> Sent: Friday, October 09, 2015 4:04 AM
> To: OSPF WG List
> Cc: Romascanu, Dan (Dan)
> Subject: FW: New Version Notification for draft-ietf-ospf-rfc4970bis-06.txt
> 
> This version includes Dan Romascanu’s Gen-ART review commments.
> 
> Thanks,
> 
> Acee
> 
> 
> 
> On 10/8/15, 8:59 PM, "internet-dra...@ietf.org" <internet-dra...@ietf.org>
> 
> wrote:
> 
> 
> 
> >
> 
> >A new version of I-D, draft-ietf-ospf-rfc4970bis-06.txt
> 
> >has been successfully submitted by Acee Lindem and posted to the
> 
> >IETF repository.
> 
> >
> 
> >Name:draft-ietf-ospf-rfc4970bis
> 
> >Revision:06
> 
> >Title:   Extensions to OSPF for Advertising Optional Router
> Capabilities
> 
> >Document date:   2015-10-08
> 
> >Group:   ospf
> 
> >Pages:   15
> 
> >URL:

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-ietf-ospf-rfc4970bis-04

[Romascanu, Dan (Dan)]

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq



Document: draft-ietf-ospf-rfc4970bis-04

Reviewer: Dan Romascanu

Review Date: 10/8/15

IETF LC End Date: 10/8/15

IESG Telechat date: 10/15/15



Summary:

The document is ready with one issue for clarification and minor editorial 
observations.



Major issues:

None



Minor issues:



There seems to be an inconsistency between the way padding of the value fields 
in the value TLVs is defined in section 2.1, and in 2.3 and 2.5 respectively.



In 2.1 we have: 'The padding is composed of zeros'



In 2.2 we have: 'The format of the TLVs within the body of an RI LSA is defined 
as in Section 2.1' This would include the V (value) field, thus the padding.



However, in 2.3 and 2.5 the definitions of the value fields stipulate they are 
'padded with undefined bits'



Why this inconsistency?



Nits/editorial comments:



1.   If the TLV definitions within the body of the RI LSA are identical, it 
would have been better to separate this in a distinct sub-section.

2.   Please include a reference to the Vendor Enterprise Code in section 5.2

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-ietf-v6ops-siit-eam-01

[Romascanu, Dan (Dan)]

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq



Document: draft-ietf-v6ops-siit-eam-01

Reviewer: Dan Romascanu

Review Date: 9/20/15

IETF LC End Date: 9/22/15

IESG Telechat date: (if known)



Summary:



This is very well written document. I liked the problem statement and the 
examples which were very useful for the easy understanding of the problem and 
of the solution. There are a few minor issues that may be just nits or easy 
editorial issues. I suggest these to be discussed between the authors and the 
RFC Editor before the document is published.



Major issues:



Minor issues:



Nits/editorial comments:



1.   In the second paragraph of the Introduction I suggest s/The Explicit 
Address Mapping Table does not replace/Translation using the Explicit Address 
Mapping Table does not replace/

2.   In section 2 I would suggest s/doing so may result in a new set of 
undesired properties/doing so may result in a new set of undesired consequences/

3.   Section 3.2:

   When translating a packet between IPv4 and IPv6, an SIIT
   implementation MUST individually translate each IP address it
   encounters in the packet's IP headers (including any IP headers
   contained within ICMP errors) according to Section 3.3.  See
   Section 4 for certain exceptions to this rule.



   As we are talking about exceptions to the rule, is not SHOULD more 
appropriate than MUST?



4.   Sections 4.2.1 and 4.2.2 present two alternative approaches for 
hairpinning support. Yet, the opening sentence in 4.2.1. a keyworded MUST, 
while the opening sentence in 4.2.2. does not:



   When the simple hairpinning feature is enabled, the translator MUST

   behave according to the following rules when translating from IPv4 to

   IPv6:



   When the intrinsic hairpinning feature is enabled, the translator

   behaves as follows when receiving an IPv6 packet:



   It seems that either MUST is to be used in both, either in none.





Regards,



Dan







___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-ietf-pals-vccv-for-gal-05

[Romascanu, Dan (Dan)]

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq



Document: draft-ietf-pals-vccv-for-gal-05

Reviewer: Dan Romascanu

Review Date: 9/4/15

IETF LC End Date:

IESG Telechat date:



Summary: this document is ready with minor issues



Major issues:



None



Minor issues:


1.   Section 3 includes the following text:

   When the PW CW is not used, the Type 4 MPLS VCCV Control Channel (CC)
   type defined in this section MAY be used.  This is referred to as
   VCCV CC Type4 throughout the rest of this of this document.  VCCV
   Type 4 uses the encapsulation shown in Figure 1 in which the presence
   of a GAL at the end of the MPLS label stack indicates that the packet
   carries a VCCV message.

Two issues here:

-  Line 3 includes a disturbing typo as the type is referred to in the 
rest of the document as 'VCCV CC Type 4' (with a space)

-  I understand the MAY in the second line to be directed to the 
implementers and this is fine. However, what about the operators who own 
network devices that have implemented this option? From reading the first 
section I indirectly get that the operators SHOULD activate this option. Maybe 
a separate paragraph can include this recommendation.


2.   Manageability Considerations - is there a requirement for all devices 
in a given network to activate the new type support, or a mix of routers 
supporting and not-supporting this option does not cause a problem?

3.   Section 9.1 - I assume that at publication Bit X (0x0Y) is supposed to 
be changed to Bit 3 (0x08)

Regards,

Dan

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART telechat review of draft-ietf-hybi-permessage-compression

[Romascanu, Dan (Dan)]

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 wait for direction from your document shepherd or AD before posting a 
new version of the draft.



Document: draft-ietf-hybi-permessage-compression

Reviewer: Dan Romascanu

Review Date: 7/6/15

IETF LC End Date: 6/24/15

IESG Telechat date: 7/9/15



Summary: Ready, the issues raised in the Gen-ART review were addressed, thank 
you



Major issues:



Minor issues:



Nits/editorial comments:




___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review for draft-ietf-xmpp-dna-10

[Romascanu, Dan (Dan)]

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-xmpp-dna-10

Reviewer: Dan Romascanu

Review Date: 7/6/15

IETF LC End Date: 7/8/15

IESG Telechat date: (if known)



Summary:

Ready

Very well written document - as all XMPP documents. Requires a lot of extra 
reading for the non-expert, including three non-IETF documents but these are 
freely available and all comes together nicely.

Major issues:

None

Minor issues:

None

Nits/editorial comments:

None

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-ietf-hybi-permessage-compression

[Romascanu, Dan (Dan)]

Hi,

Thank you for addressing my comments and clarifying the issues.

I am fine with the proposed resolutions.

Regards,

Dan


From: Takeshi Yoshino [mailto:tyosh...@google.com]
Sent: Tuesday, June 23, 2015 9:52 AM
To: Barry Leiba
Cc: Romascanu, Dan (Dan); General Area Review Team; 
draft-ietf-hybi-permessage-compression@tools.ietf.org
Subject: Re: Gen-ART review of draft-ietf-hybi-permessage-compression

Thank you for review, Dan.

On Wed, Jun 17, 2015 at 12:08 AM, Barry Leiba 
barryle...@computer.orgmailto:barryle...@computer.org wrote:
Hi, Dan, and thanks for the review.

 I do not know if this is an issue, but I am asking the question. Some
 implementations are mentioned in the write-up, but they seem to have been
 written and deployed based on very old versions of the document – 05 and
 earlier, dating three years back. I am wondering if this is a problem of the
 write-up not being updated. If not – have the changes brought to the
 document since draft-05 impacted the negotiation and algorithms described in
 the document?

The history here is that the working group sent the document to me at
version -05, and I reviewed it and sent it back for more editorial
work -- I found it very hard to read and often unclear.
Unfortunately, the editorial work took two years and many revisions to
complete, but I think the result is clear and easy to read, and I'm
happy with the result.  But that work did not make technical changes
to the protocol, so implementations of -05 are still implementations
of -22... unless, of course, they were based on any misunderstandings
of an unclear document.  I think the likelihood of that last is low,
because the implementors were involved in the development of the
document.

Here're the non-editorial changes happened since -05:

-10 added hints. This is optional feature. Shouldn't impact interoperability.

-10 made it mandatory for clients to support client_no_context_takeover (at 
this point it was called c2s_no_context_takeover) parameter in an extension 
response. This shouldn't introduce any spec issue, I think.

-15 renamed s2c_ to server_ and c2s_ to client_. I think everyone has followed 
this change in this 1.5 year.

On the minor issues:
I'm ambivalent about changing the musts and must not to 2119 key
words.  I think you know that I'm not a fan of overuse of those key
words.  On the other hand, they do apply fine here as key words, and I
have no objection to changing them.  I'll leave that up to the author
and shepherd.

Nits 1 and 2 are correct, and should be fixed; thanks.  For nit 3, I'm
happy to have the acknowledgments section reflect the author's voice.

Changing must to MUST in Section 5:

From 2 perspectives, I prefer not to capitalize them:
- (a) These sentences are describing what/how constraints have to be negotiated 
for the DEFLATE based compressed communication channel just as an example.
- (b) These sentences are not explaining requirements that implementors must 
follow for interoperability, but just things they have to do to make DEFLATE 
based compression/decompression work correctly.

Because of (b), I'd like to keep these must keeps uncapitalized. I'm 
ambivalent about (a) regarding MUST and may the following sentences

   In a PMCE negotiation offer, the client MUST inform the server of its
   LZ77 window size so that the server uses an LZ77 window size that is

   LZ77 window size of the client.  In a PMCE negotiation offer, the
   client may inform the maximum LZ77 window size the client can afford

We can consider these to be kind of quotes of conformance requirements. 
Actually, we're defining them later in the same doc. So, I'd like to keep this 
MUST and change the may in the second sentence to MAY for consistency. Does 
this look good to you?



Changing must not to MUST NOT in Section 8.2.1: Agreed. I'll fix it.



Nit 1: Removed the redundant extension.

Nit 2: Added explanation of the significance of the values 0 and 1 as follows:

   Meaning
  The message is compressed or not.  RSV1 is set for compressed
  messages and unset for uncompressed messages.

Nit 3: Changed to Thanks to as you suggested.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-ietf-hybi-permessage-compression

[Romascanu, Dan (Dan)]

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at



https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.tools.ietf.org_area_gen_trac_wiki_GenArtfaqd=AwICAgc=BFpWQw8bsuKpl1SgiZH64Qr=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFAm=hGLCrvRMbwg7aF87DUcj1kzIZxtq-RxIeVZwskYlZUws=JAEyywKQRPrtTGWFwQ10cWxvPlWJJMPtFco6XfIaGDge=
 
https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.tools.ietf.org_area_gen_trac_wiki_GenArtfaqd=AwICAgc=BFpWQw8bsuKpl1SgiZH64Qr=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFAm=hGLCrvRMbwg7aF87DUcj1kzIZxtq-RxIeVZwskYlZUws=JAEyywKQRPrtTGWFwQ10cWxvPlWJJMPtFco6XfIaGDge=%20
 .



Please resolve these comments along with any other Last Call comments you may 
receive.



Document: draft-ietf-hybi-permessage-compression-21

Reviewer: Dan Romascanu

Review Date: 6/16/15

IETF LC End Date: 6/24/15

IESG Telechat date: 7/9/15



Summary: Ready with minor issues



I do not know if this is an issue, but I am asking the question. Some 
implementations are mentioned in the write-up, but they seem to have been 
written and deployed based on very old versions of the document - 05 and 
earlier, dating three years back. I am wondering if this is a problem of the 
write-up not being updated. If not - have the changes brought to the document 
since draft-05 impacted the negotiation and algorithms described in the 
document?



Major issues:



Minor issues:



1.   In Section 5:



   The server must keep the original
   bytes of data that it recently compressed and sent to the client.
   The client must keep the result of decompressing the bytes of data
   that it recently received from the server.

   The two 'must' here seem to deserve capitalization.



2.   In Section 8.2.1:



Note that

   for non-final fragments, the removal of 0x00 0x00 0xff 0xff must not

   be done.

'must not' here seems to deserve capitalization.



Nits/editorial comments:



1.   In Section 4: 'One PMCE extension is defined ...' - the word extension 
can be dropped, E already stands for extension

2.   In Section 10.2 - It would be good to explain in 'Meaning' the 
significance of the values 0 and 1 of the RSV1 bit

3.   In section 11:  s/Thank you to the following people/Thanks to the 
following people/





___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Review for draft-ietf-xmpp-6122bis

[Romascanu, Dan (Dan)]

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/GenArtfaqhttps://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.tools.ietf.org_area_gen_trac_wiki_GenArtfaqd=AAMFAwc=BFpWQw8bsuKpl1SgiZH64Qr=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFAm=r8UFfP-NUIqoQixcKqofblfdzNSaZvjkRfw3L7VsyHcs=DCDmXhyc7XoNYI-SEtLco1iUd9vIjB8nxVWrudr4dV0e=.



Please resolve these comments along with any other Last Call comments you may 
receive.



Document: 
https://art.tools.ietf.org/tools/art/genart/index.cgi/t=965/doc?selected_doc=draft-ietf-xmpp-6122bis

Reviewer: Dan Romascanu

Review Date: 5/27/15

IETF LC End Date: 6/3/15

IESG Telechat date:



Summary:



Ready with one issue which I believe is worth discussing.



Major issues:



I have a concern about backwards compatibility and migration. In the migration 
between 6122 and 6122bis deployments it is possible that previously-valid JIDs 
might no longer be valid or previously-invalid JIDs become valid. Because of 
this the Introduction says that operators of XMPP services are advised to 
perform careful testing before migrating accounts and other data.



In a dialog with Peter Saint-Andre (document author) I asked if  there are any 
recommendations that could be made to the application designers and operators 
respectively to ease the migration?



His answer pointed to section 6 (actually I think that 6.1 applies) in in 
draft-ietf-precis-saslprepbis. I believe that a pointer to that section in a 
'migration / backwards compatibility' section would be useful for the 
application designers. What about the operators, however? Can more details 
about what operator should test to ensure compatible migration of users and 
applications be provided  beyond what is mentioned in the introduction?



Minor issues:



Nits/editorial comments:



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART telechat review of 07 draft-ietf-dane-smtp-with-dane-17

[Romascanu, Dan (Dan)]

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 wait for direction from your document shepherd or AD before posting a 
new version of the draft.



Document: 07   draft-ietf-dane-smtp-with-dane-17

Reviewer: Dan Romascanu

Review Date: 5/27/15

IETF LC End Date: 5/7/15

IESG Telechat date: 5/28/15



Summary:



Ready.

The minor issues that I raised in my previous review were addressed. Thank you.



Major issues:



None



Minor issues:



None



Nits/editorial comments:

None

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] A *new* batch of IETF LC reviews - 2015-05-21

[Romascanu, Dan (Dan)]

Hi Jean,

I assume that you mean

 Dan Romascanu 2015-06-03   draft-ietf-xmpp-6122bis-22

(and not 2015-05-03)

Otherwise, GenArt needs to provide time machines to its members :-) 

Regards,

Dan


 -Original Message-
 From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of A. Jean
 Mahoney
 Sent: Thursday, May 21, 2015 11:44 PM
 To: General Area Review Team
 Subject: [Gen-art] A *new* batch of IETF LC reviews - 2015-05-21
 
 Hi all,
 
 The following reviewers have assignments:
 
 Reviewer  LC end   Draft
 -
 Alexey Melnikov   2015-06-01   draft-ietf-oauth-spop-11
 
 Brian Carpenter   2015-06-01   draft-ietf-dime-congestion-flow-attributes-01
 
 Christer Holmberg 2015-06-03   draft-ietf-httpbis-tunnel-protocol-04
 
 Dan Romascanu 2015-05-03   draft-ietf-xmpp-6122bis-22
 
 Wassim Haddad 2015-06-01   draft-ietf-oauth-introspection-08
 
 
 I have made the assignments in the review tool:
 https://urldefense.proofpoint.com/v2/url?u=http-
 3A__art.tools.ietf.org_tools_art_genart_d=AwICAgc=BFpWQw8bsuKpl1S
 giZH64Qr=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFAm=IYbHvu9q
 v5Z3Qjx5qOVLUjVHp0bxjPll7nyVuJYj5TEs=BlIUJqNNg2IK7KdWGkhsxWCvTl
 X0yMa1B100kc2es0we=
 
 And the assignments are captured in the spreadsheets:
 https://urldefense.proofpoint.com/v2/url?u=http-
 3A__wiki.tools.ietf.org_dav_genart_gen-
 2Dart.htmld=AwICAgc=BFpWQw8bsuKpl1SgiZH64Qr=I4dzGxR31OcNXCJ
 fQzvlsiLQfucBXRucPvdrphpBsFAm=IYbHvu9qv5Z3Qjx5qOVLUjVHp0bxjPll7n
 yVuJYj5TEs=WkNpNZV1je8vUr1oi8F1Epd7KP2McHIKI2II3ts69aEe=
 https://urldefense.proofpoint.com/v2/url?u=http-
 3A__wiki.tools.ietf.org_dav_genart_gen-2Dart-2Dby-
 2Dreviewer.htmld=AwICAgc=BFpWQw8bsuKpl1SgiZH64Qr=I4dzGxR31O
 cNXCJfQzvlsiLQfucBXRucPvdrphpBsFAm=IYbHvu9qv5Z3Qjx5qOVLUjVHp0b
 xjPll7nyVuJYj5TEs=m0sFwxR21KO1Gpn1u4k6xEJU9wvGlY7oDorQEmcjDjc
 e=
 
 The standard template is included below.
 
 Thanks,
 
 Jean
 
 ---
 
 I am the assigned Gen-ART reviewer for this draft. For background on Gen-
 ART, please see the FAQ at
 
 https://urldefense.proofpoint.com/v2/url?u=http-
 3A__wiki.tools.ietf.org_area_gen_trac_wiki_GenArtfaqd=AwICAgc=BFp
 WQw8bsuKpl1SgiZH64Qr=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsF
 Am=IYbHvu9qv5Z3Qjx5qOVLUjVHp0bxjPll7nyVuJYj5TEs=7nLlZ3H8RPnsaLs
 iVUOJKpuLzI0n5kWsbvk3uYUytiMe= .
 
 Please resolve these comments along with any other Last Call comments you
 may receive.
 
 Document:
 Reviewer:
 Review Date:
 IETF LC End Date:
 IESG Telechat date: (if known)
 
 Summary:
 
 Major issues:
 
 Minor issues:
 
 Nits/editorial comments:
 
 
 ___
 Gen-art mailing list
 Gen-art@ietf.org
 https://urldefense.proofpoint.com/v2/url?u=https-
 3A__www.ietf.org_mailman_listinfo_gen-
 2Dartd=AwICAgc=BFpWQw8bsuKpl1SgiZH64Qr=I4dzGxR31OcNXCJfQzvl
 siLQfucBXRucPvdrphpBsFAm=IYbHvu9qv5Z3Qjx5qOVLUjVHp0bxjPll7nyVuJ
 Yj5TEs=rKNxUR6SE9lfeU4pVU3q7OHt-bkqZALsEiC8acr8nyke=

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-ietf-dane-smtp-with-dane-16

[Romascanu, Dan (Dan)]

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at



https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.tools.ietf.org_area_gen_trac_wiki_GenArtfaqd=AwICAgc=BFpWQw8bsuKpl1SgiZH64Qr=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFAm=mb_ePFTrh4SrJtyhoUSSxm3VeVCCfkSyGSgcyusg8UAs=DcFaQTeDfxbYZdHOC8LSldAdZ87N4zFiXuKx99Z2seUe=
 
https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.tools.ietf.org_area_gen_trac_wiki_GenArtfaqd=AwICAgc=BFpWQw8bsuKpl1SgiZH64Qr=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFAm=mb_ePFTrh4SrJtyhoUSSxm3VeVCCfkSyGSgcyusg8UAs=DcFaQTeDfxbYZdHOC8LSldAdZ87N4zFiXuKx99Z2seUe=%20
 .



Please resolve these comments along with any other Last Call comments you may 
receive.



Document: draft-ietf-dane-smtp-with-dane-16

Reviewer: Dan Romascanu

Review Date: 5/6/15

IETF LC End Date: 5/7/15

IESG Telechat date: (if known)



Summary:



Ready with minor comments.

I liked the operational considerations section and the security consideration 
section - very useful in putting this work in the context of other similar 
contributions.



Major issues:



None.



Minor issues:



As the document uses heavily the term 'downgrade' (downgrade attack, 
downgrade-resistant) it would be nice to either explain or provide a reference 
for what it means in the context of this work.



Nits/editorial comments:



The last paragraph in section 2.2.1, page 15 has a comment marked twice by --. 
This may be an editorial left-over to be corrected.





___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Telechat Gen-ART review of draft-ietf-tsvwg-port-use-07.txt

[Romascanu, Dan (Dan)]

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 wait for direction from your document shepherd or AD before posting a 
new version of the draft.



Document: draft-ietf-tsvwg-port-use-07.txt

Reviewer: Dan Romascanu

Review Date: 2/17/2015

IETF LC End Date:  12/22/2014

IESG Telechat date: 2/19/2015



Summary: Ready



Thank you for addressing my (minor) comments in the initial review



Major issues:



Minor issues:



Nits/editorial comments:



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Last Call: draft-ietf-ippm-rate-problem-08.txt (Rate Measurement Test Protocol Problem Statement) to Informational RFC

[Romascanu, Dan (Dan)]

Looks good. Thanks for addressing my concerns. 

Regards,

Dan


 -Original Message-
 From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of MORTON,
 ALFRED C (AL)
 Sent: Saturday, January 10, 2015 1:33 AM
 To: i...@ietf.org
 Cc: gen-art@ietf.org; ops-...@ietf.org; i...@ietf.org
 Subject: Re: [Gen-art] Last Call: draft-ietf-ippm-rate-problem-08.txt (Rate
 Measurement Test Protocol Problem Statement) to Informational RFC
 
 Ben, Dan, Greg,
 
 Version 09 of -ippm-rate-problem draft addresses your comments to great
 extent.
 
 Although Ben's (GEN-ART) suggestion to clarify the figure in the Intro was
 adopted, it seems reasonable to leave out the Figure numbers since the two
 figures are referenced one time each and they are only 3 lines high (so not
 likely to move far, if at all).
 
 Dan's (OPS-DIR) comments have been addressed (following e-mail
 exchange) by inserting a new section on Operational Considerations where
 we have compromised on the text.
 
 Greg's comments have been addressed to the extent possible without re-
 visiting the Toronto compromise which only involved section 5.
 Other comments cite WG agreements that have not actually been discussed
 AFAIK, or refer to purely OPTIONAL features in the memo.
 
 regards,
 Al
 
 
 From: IETF-Announce [ietf-announce-boun...@ietf.org] On Behalf Of The
 IESG [iesg-secret...@ietf.org]
 Sent: Monday, December 08, 2014 9:43 AM
 To: IETF-Announce
 Cc: i...@ietf.org
 Subject: Last Call: draft-ietf-ippm-rate-problem-08.txt (Rate Measurement
 Test Protocol Problem Statement) to Informational RFC
 
 The IESG has received a request from the IP Performance Metrics WG (ippm)
 to consider the following document:
 - 'Rate Measurement Test Protocol Problem Statement'
   draft-ietf-ippm-rate-problem-08.txt as Informational RFC
 
 The IESG plans to make a decision in the next few weeks, and solicits final
 comments on this action. Please send substantive comments to the
 i...@ietf.org mailing lists by 2014-12-22. Exceptionally, comments may be
 sent to i...@ietf.org instead. In either case, please retain the beginning of
 the Subject line to allow automated sorting.
 
 Abstract
 
 
This memo presents an access rate-measurement problem statement for
test protocols to measure IP Performance Metrics.  The rate
measurement scenario has wide-spread attention of Internet access
subscribers and seemingly all industry players, including regulators.
Key test protocol aspects require the ability to control packet size
on the tested path and enable asymmetrical packet size testing in a
controller-responder architecture.
 
 
 
 
 
 The file can be obtained via
 https://urldefense.proofpoint.com/v2/url?u=http-
 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2Drate-
 2Dproblem_d=AwICAgc=BFpWQw8bsuKpl1SgiZH64Qr=I4dzGxR31OcNX
 CJfQzvlsiLQfucBXRucPvdrphpBsFAm=EKLRXCpGDaNYiJ9WjJgA2LRIdn0QDiC
 yaT1frtYfg8Ys=TnJHba-sAmj9BdGxYeMgYS-qoQBHT0QgbNSFjZ8snboe=
 
 IESG discussion can be tracked via
 https://urldefense.proofpoint.com/v2/url?u=http-
 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2Drate-
 2Dproblem_ballot_d=AwICAgc=BFpWQw8bsuKpl1SgiZH64Qr=I4dzGxR3
 1OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFAm=EKLRXCpGDaNYiJ9WjJgA2LRIdn
 0QDiCyaT1frtYfg8Ys=8MzkfnznQ4g4XC4ZfldXKZFpASLAK89Cf4ELdsZWIZ0e
 =
 
 
 No IPR declarations have been submitted directly on this I-D.
 
 
 ___
 Gen-art mailing list
 Gen-art@ietf.org
 https://urldefense.proofpoint.com/v2/url?u=https-
 3A__www.ietf.org_mailman_listinfo_gen-
 2Dartd=AwICAgc=BFpWQw8bsuKpl1SgiZH64Qr=I4dzGxR31OcNXCJfQzvl
 siLQfucBXRucPvdrphpBsFAm=EKLRXCpGDaNYiJ9WjJgA2LRIdn0QDiCyaT1frt
 Yfg8Ys=Q8ccS1OgnV3UQ8TqslGmcf_Dz8hcuFK1jGvVfV6os7ce=

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Telechat review of draft-ietf-tls-prohibiting-rc4-01

[Romascanu, Dan (Dan)]

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 wait for direction from your document shepherd or AD before posting a 
new version of the draft.



Please resolve these comments along with any other Last Call comments you may 
receive.



Document: draft-ietf-tls-prohibiting-rc4-01

Reviewer: Dan Romascanu

Review Date: 1/7/2015

IETF LC End Date: 12/10/2014

IESG Telechat date: 1/8/2014



Summary: Ready with nits



This is a clear and straightforward document, which requires the client and 
server TLS implementations to not use the RC4 cipher suites, and lists in an 
appendix the cipher suites defined for TLS use RC4.

The document was not updated since my initial review, so the only nit I 
mentioned in that review is still to be fixed.





Major issues:



None



Minor issues:



None



Nits/editorial comments:



There is one nit easy to fix - bracketed references of the RFCs updated by this 
document. are used in the Abstract. These need to be replaced by textual 
references to the RFCs.


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART 2nd LC review of draft-ietf-softwire-map-t-08

[Romascanu, Dan (Dan)]

I am the assigned Gen-ART reviewer for this draft. For background on

Gen-ART, please see the FAQ at



https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.tools.ietf.org_area_gen_trac_wiki_GenArtfaqd=AAICAgc=BFpWQw8bsuKpl1SgiZH64Qr=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFAm=wU47cwzdbQA3EthgiqiHsK8wRMdaCD1eucz7eZT_jp4s=9eC4mYiWqVGeaX_6SSW4A5vbej46w2gZDsZtVb0JKmIe=
 
https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.tools.ietf.org_area_gen_trac_wiki_GenArtfaqd=AAICAgc=BFpWQw8bsuKpl1SgiZH64Qr=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFAm=wU47cwzdbQA3EthgiqiHsK8wRMdaCD1eucz7eZT_jp4s=9eC4mYiWqVGeaX_6SSW4A5vbej46w2gZDsZtVb0JKmIe=%20
 .



Please resolve these comments along with any other Last Call comments

you may receive.



Document:  draft-ietf-softwire-map-t-08

Reviewer: Dan Romascanu

Review Date: 12/16/14

IETF LC End Date: 12/29/14

IESG Telechat date: not yet



Summary: Ready



The last pending issue from my initial review was resolved by changing the 
Intended Status of the document from Experimental to Standards Track



Major issues:



Minor issues:



Nits/editorial comments:





___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-murdock-nato-nid-02.txt

[Romascanu, Dan (Dan)]

Hi Barry,

This looks reasonable, thanks for the timely response and for addressing my 
comments. I suggest that the editor also fixes the text in section 7. 

Regards,

Dan


 -Original Message-
 From: barryle...@gmail.com [mailto:barryle...@gmail.com] On Behalf Of
 Barry Leiba
 Sent: Wednesday, November 19, 2014 8:53 PM
 To: Romascanu, Dan (Dan)
 Cc: gen-art@ietf.org; draft-murdock-nato-nid@tools.ietf.org
 Subject: Re: Gen-ART review of draft-murdock-nato-nid-02.txt
 
 Thanks for the review, Dan.
 
  1.   The document does not expand the acronym NATO at the first
  occurrence. Moreover, in section 7 it mentions 'that a standards body,
  like NATO' which is misleading - as NATO is not a standards body. I
  suggest to use the full name in the title and abstract, expand the
  acronym at first occurrence and correct the text in Section 7.
 
 The AD/shepherd agrees.
 
  2.   The abstract and introduction should make clear that this is a
  request made according to RFC 3406 for a formal URN space type, as
  described in Section 4.3 of RFC 3406.
 
 I suppose that I agree with that, too, though I think it's less important.  
 But
 something like this should do nicely:
 
 OLD
This document describes a Uniform Resource Name (URN) namespace for
assignment by NATO.  The current primary use is for uniquely
identifying Extensible Markup Language (XML) artifacts that provide
information about NATO message text formats and service
specifications as described in various NATO standards [4],
instructions and publications.
 
 NEW
This document allocates a formal Uniform Resource Name (URN)
namespace for assignment by the North Atlantic Treaty Organization
(NATO), as specified in RFC 3406.  The current primary use is for
uniquely identifying Extensible Markup Language (XML) artifacts
that provide information about NATO message text formats and
service specifications as described in various NATO standards,
instructions and publications.
 
 END
 
 (That also removes the reference ([4]) in the abstract, as the RFC Editor
 doesn't allow references in abstracts.)  And then a similar change in the
 Introduction section.
 
  I could not find in the summary written by the AD shepherd an
  indication whether this review occurred.
 
 The AD/shepherd apologises profusely for his typo: the writeup said uri-
 review, where it should have said urn-nid.  I've corrected the error in the
 writeup, and, yes, the review happened.
 
 Ira, I'm going to move the document into IESG Evaluation state now.
 Please update the I-D as soon as you can with the above minor changes.
 Thanks.
 
 Barry

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-murdock-nato-nid-02.txt

[Romascanu, Dan (Dan)]

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-murdock-nato-nid-02.txt

Reviewer: Dan Romascanu

Review Date: 11/19/14

IETF LC End Date: 11/19/14

IESG Telechat date: 11/25/14



Summary: Almost Ready



Major issues:



1.   The document does not expand the acronym NATO at the first occurrence. 
Moreover, in section 7 it mentions 'that a standards body, like NATO' which is 
misleading - as NATO is not a standards body. I suggest to use the full name in 
the title and abstract, expand the acronym at first occurrence and correct the 
text in Section 7.

2.   The abstract and introduction should make clear that this is a request 
made according to RFC 3406 for a formal URN space type, as described in Section 
4.3 of RFC 3406.

3.   As per RFC 3406, section 4.3:



Ø The proposed template

Ø should be sent to the:

Ø

Øurn-...@apps.ietf.org

Ø mailing list to allow for a two week discussion period for clarifying

Ø the expression of the registration information, before the IESG

Ø reviews the document.

Ø



I could not find in the summary written by the AD shepherd an indication 
whether this review occurred.



Minor issues:



Nits/editorial comments:





___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Telechat review of draft-ietf-softwire-map-t-06.txt

[Romascanu, Dan (Dan)]

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.



Document: http://www.ietf.org/id/draft-ietf-softwire-map-t-06.txt

Reviewer: Dan Romascanu

Review Date: 10/28/2014

IETF LC End Date: 10/10/2014

IESG Telechat date: 10/30/2014



Summary:



Ready with issues.



One issue from my initial review was not clarified IMO.



The status of this document is Experimental. It is not clear why. There are no 
experimental documents in the softwire WG charter, and the status of the 
'sister' document draft-ietf-softwire-map is Standards Track. Why the 
difference?

The discussion around that issue shows that the editors seem to be in 
disagreement with the chairs about the status of the document. See mail 
http://www.ietf.org/mail-archive/web/gen-art/current/msg10713.html. I suggest 
that the IESG discussed this issue before approving the document.


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Telechat Review of draft-ietf-grow-ix-bgp-route-server-operations-03.txt

[Romascanu, Dan (Dan)]

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: 
http://www.ietf.org/id/draft-ietf-grow-ix-bgp-route-server-operations-03.txt

Reviewer: Dan Romascanu

Review Date: 9/18/14

IETF LC End Date: 9/22/14

IESG Telechat date: 10/16/14



Summary:



This document was not updated since my initial review, so my comments still 
stand.



A useful and very well written document, with a few minor issues that need 
clarification and fixes before publication



Major issues:



None



Minor issues:



1.   The reference [RS-ARCH] mentioned in 4.2.1.1 and 4.2.1.2 is not 
reachable (Error 404). As the understanding of the issues described in the two 
sections depend on this reference, a valid reference is required.

2.   Section 4.2.1.3 uses the term 'flat layer 2 network' which has at 
least two meanings depending on the context or layer - either one VLAN space at 
the link layer (as to differentiate from Customer VLAN and Provider VLAN) or a 
bridged network with no routers between the bridged segments. Clarification is 
needed.

3.   The usage of keywords is inconsistent in a few place. In 4.6.1 the 
'should' in the second paragraph needs to be capitalized. In 4.6.3 we have a 
capitalized SHOULD, but then a non-capitalized 'may' for statements that both 
seem to describe requirements of the same level.

4.   I am doubt that Section 4.7 is that useful. On one hand reliability of 
layer 2 forwarding is not in my opinion such a big issue, and measures can be 
taken a the link layer to improve it (use lags or redundant paths). Second the 
recommended mitigation (RFC 5881 BFD) is described as non-optimal, with no 
other alternative. I would just drop this section completely.



Nits/editorial comments:



1.   The English syntax of the second paragraph in the Abstract is broken.

2.   In the introduction there is a mention of 'using shared Layer-2 
networking media such as Ethernet'. Actually Ethernet is seldom used nowadays 
as a shared media, I would just recommend saying 'using data link layers 
protocols such as Ethernet'

3.   In section 4.2 s/optimization technique is implemented/optimization 
technique that is implemented/





___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Telechat review of draft-ietf-softwire-map-t-05.txt

[Romascanu, Dan (Dan)]

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.



Document: http://www.ietf.org/id/draft-ietf-softwire-map-t-05.txt

Reviewer: Dan Romascanu

Review Date: 10/6/2014

IETF LC End Date: 10/10/2014

IESG Telechat date: 10/16/2014



Summary:



Almost Ready.



There was no updated version of this document since I sent the original review. 
My previous comments still stand.



The document is well written and the technical content is clear. There are 
however a number of issues which I recommend to be clarified before the 
document is approved.



Major issues:



1.   It is unclear to me how this document fits into the charter of the 
softwire WG. The MAP-T solution defined in this document is described in the 
Introduction as:



Ø  The MAP-T solution differs from MAP-E in
the use of IPv4-IPv6 translation, rather than encapsulation, as the form of 
IPv6 domain transport.



However, the WG charter says:



 IPv4/IPv6 translation mechanisms, new addressing schemes, and block address 
 assignments are out of scope.



Is this a different type of IPv4-IPv6 translation than the one considered by 
the original charter out-of-scope? Did the scope of the WG change in time, but 
the charter was not updated? Some clarification is needed.



2.   The status of this document is Experimental. It is not clear why. 
There are no experimental documents in the softwire WG charter, and the status 
of the 'sister' document draft-ietf-softwire-map is Standards Track. Why the 
difference?

3.   The document uses the term MAP without expanding it. It is probably 
supposed to be 'Mapping of Address and Port'. However, the title of 
draft-ietf-softwire-map identifies MAP as the expansion of 'Mapping of Address 
and Port with Encapsulation' and never uses the MAP-E expansion used here. The 
terminology and abbreviations in the two documents must be aligned.

4.Section 5 says:



Ø The MAP-T algorithmic mapping rules are identical to those in
   Section 5 of the MAP-E specification [I-D.ietf-softwire-map], with
   the exception of Section 5.4 concerning the forwarding of traffic to/
   from IPv4 nodes outside the MAP-T.



If such is the case draft-ietf-softwire-map needs to be a Normative Reference. 
This Section cannot be fully understood and implemented without 
draft-ietf-softwire-map.



Minor issues:



1.   The 2119 keywords are used in an inconsistent manner in some places. 
Take as an example Section 10. The subsections describe three mechanism that 
deal with fragmentation and path MTU discovery. Section 10.3 uses SHOULD 
language while section 10.1 and 10.2 uses 'recommended' or 'has to'.

2.   Appendix A uses the IPv4 address 1.2.3.4 as an example address which 
is against the guidance in RFC 5735.



Nits/editorial comments:



1.   BMR and FMR occur in the text a few times before they are expanded in 
section 8.1 - please expand at first occurrence

2.   In the Introduction s/end-end/end-to-end/ and s/optimalise/optimize/

3.   3. Section 7.1 - the first sentence has no verb in it

4.   Also in in Section 7.1 - the last paragraph can be dropped - this was 
already said in the section

5.   In Section 9 I cannot make sense of the sentence that starts with 'In 
the return ...'



Regards,



Dan



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] ***SPAM*** 12.315 (5) RE: Gen-ART Telechat review of draft-ietf-softwire-map-t-05.txt

[Romascanu, Dan (Dan)]

Hi Wojciech,

I believe that I understand the situation. We should probably let the IESG 
decide on this matter.

Thanks and Regards,

Dan



From: Wojciech Dec (wdec) [mailto:w...@cisco.com]
Sent: Monday, October 13, 2014 5:46 PM
To: Romascanu, Dan (Dan); gen-art@ietf.org
Cc: draft-ietf-softwire-map-t@tools.ietf.org
Subject: Re: Gen-ART Telechat review of draft-ietf-softwire-map-t-05.txt

Hello Dan,

Thank you for you comments. I'm reading an updated draft, however there is one 
point that I am unable to address fully:

2.2.   The status of this document is Experimental. It is not clear why. 
There are no experimental documents in the softwire WG charter, and the status 
of the 'sister' document draft-ietf-softwire-map is Standards Track. Why the 
difference?

Together with the other authors, we fully agree that the draft does not fit the 
experimental status, as in it actually uses standards track technology 
(NAT64) as well as the sister (standard track) MAP. There also are a number of 
reports about MAP-T testing 
(http://tools.ietf.org/html/draft-cordeiro-experience-mapt-01 ), and a handful 
of commercial implementations. As Xing commented earlier on, the decision on 
the track was made by the WG by means of a coin toss, which in our opinion 
wasn't based on technical merits.

Regards,
W. Dec


From: Romascanu, Dan (Dan) droma...@avaya.commailto:droma...@avaya.com
Date: Monday, 13 October 2014 16:14
To: gen-art@ietf.orgmailto:gen-art@ietf.org 
gen-art@ietf.orgmailto:gen-art@ietf.org
Cc: 
draft-ietf-softwire-map-t@tools.ietf.orgmailto:draft-ietf-softwire-map-t@tools.ietf.org
 
draft-ietf-softwire-map-t@tools.ietf.orgmailto:draft-ietf-softwire-map-t@tools.ietf.org
Subject: Gen-ART Telechat review of draft-ietf-softwire-map-t-05.txt
Resent-From: 
draft-alias-boun...@tools.ietf.orgmailto:draft-alias-boun...@tools.ietf.org
Resent-To: congx...@cernet.edu.cnmailto:congx...@cernet.edu.cn, 
cuiy...@tsinghua.edu.cnmailto:cuiy...@tsinghua.edu.cn, 
o...@cisco.commailto:o...@cisco.com, 
satoru.matsush...@tm.softbank.co.jpmailto:satoru.matsush...@tm.softbank.co.jp,
 suresh.krish...@ericsson.commailto:suresh.krish...@ericsson.com, 
ted.le...@nominum.commailto:ted.le...@nominum.com, 
tets...@ipinfusion.commailto:tets...@ipinfusion.com, Wojciech Dec 
w...@cisco.commailto:w...@cisco.com, Xing Li 
x...@cernet.edu.cnmailto:x...@cernet.edu.cn
Resent-Date: Monday, 13 October 2014 16: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.



Document: http://www.ietf.org/id/draft-ietf-softwire-map-t-05.txt

Reviewer: Dan Romascanu

Review Date: 10/6/2014

IETF LC End Date: 10/10/2014

IESG Telechat date: 10/16/2014



Summary:



Almost Ready.



There was no updated version of this document since I sent the original review. 
My previous comments still stand.



The document is well written and the technical content is clear. There are 
however a number of issues which I recommend to be clarified before the 
document is approved.



Major issues:



1.   It is unclear to me how this document fits into the charter of the 
softwire WG. The MAP-T solution defined in this document is described in the 
Introduction as:



Ø  The MAP-T solution differs from MAP-E in
the use of IPv4-IPv6 translation, rather than encapsulation, as the form of 
IPv6 domain transport.



However, the WG charter says:



 IPv4/IPv6 translation mechanisms, new addressing schemes, and block address 
 assignments are out of scope.



Is this a different type of IPv4-IPv6 translation than the one considered by 
the original charter out-of-scope? Did the scope of the WG change in time, but 
the charter was not updated? Some clarification is needed.



2.   The status of this document is Experimental. It is not clear why. 
There are no experimental documents in the softwire WG charter, and the status 
of the 'sister' document draft-ietf-softwire-map is Standards Track. Why the 
difference?

3.   The document uses the term MAP without expanding it. It is probably 
supposed to be 'Mapping of Address and Port'. However, the title of 
draft-ietf-softwire-map identifies MAP as the expansion of 'Mapping of Address 
and Port with Encapsulation' and never uses the MAP-E expansion used here. The 
terminology and abbreviations in the two documents must be aligned.

4.Section 5 says:



Ø The MAP-T algorithmic mapping rules are identical to those in
   Section 5 of the MAP-E specification [I-D.ietf-softwire-map], with
   the exception of Section 5.4 concerning the forwarding of traffic to/
   from IPv4 nodes outside the MAP-T.



If such is the case draft-ietf-softwire-map needs to be a Normative Reference. 
This Section cannot be fully understood and implemented without 
draft-ietf-softwire-map.



Minor issues:



1.   The 2119 keywords are used in an inconsistent manner in some places

[Gen-art] Gen-ART review of draft-ietf-softwire-map-t-05

[Romascanu, Dan (Dan)]

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: http://www.ietf.org/id/draft-ietf-softwire-map-t-05.txt

Reviewer: Dan Romascanu

Review Date: 10/6/2014

IETF LC End Date: 10/10/2014

IESG Telechat date: 10/16/2014



Summary:



Almost Ready.



The document is well written and the technical content is clear. There are 
however a number of issues which I recommend to be clarified before the 
document is approved.



Major issues:



1.   It is unclear to me how this document fits into the charter of the 
softwire WG. The MAP-T solution defined in this document is described in the 
Introduction as:



Ø  The MAP-T solution differs from MAP-E in
the use of IPv4-IPv6 translation, rather than encapsulation, as the form of 
IPv6 domain transport.



However, the WG charter says:



 IPv4/IPv6 translation mechanisms, new addressing schemes, and block address 
 assignments are out of scope.



Is this a different type of IPv4-IPv6 translation than the one considered by 
the original charter out-of-scope? Did the scope of the WG change in time, but 
the charter was not updated? Some clarification is needed.



2.   The status of this document is Experimental. It is not clear why. 
There are no experimental documents in the softwire WG charter, and the status 
of the 'sister' document draft-ietf-softwire-map is Standards Track. Why the 
difference?

3.   The document uses the term MAP without expanding it. It is probably 
supposed to be 'Mapping of Address and Port'. However, the title of 
draft-ietf-softwire-map identifies MAP as the expansion of 'Mapping of Address 
and Port with Encapsulation' and never uses the MAP-E expansion used here. The 
terminology and abbreviations in the two documents must be aligned.

4.Section 5 says:



Ø The MAP-T algorithmic mapping rules are identical to those in
   Section 5 of the MAP-E specification [I-D.ietf-softwire-map], with
   the exception of Section 5.4 concerning the forwarding of traffic to/
   from IPv4 nodes outside the MAP-T.



If such is the case draft-ietf-softwire-map needs to be a Normative Reference. 
This Section cannot be fully understood and implemented without 
draft-ietf-softwire-map.



Minor issues:



1.   The 2119 keywords are used in an inconsistent manner in some places. 
Take as an example Section 10. The subsections describe three mechanism that 
deal with fragmentation and path MTU discovery. Section 10.3 uses SHOULD 
language while section 10.1 and 10.2 uses 'recommended' or 'has to'.

2.   Appendix A uses the IPv4 address 1.2.3.4 as an example address which 
is against the guidance in RFC 5735.



Nits/editorial comments:



1.   BMR and FMR occur in the text a few times before they are expanded in 
section 8.1 - please expand at first occurrence

2.   In the Introduction s/end-end/end-to-end/ and s/optimalise/optimize/

3.   3. Section 7.1 - the first sentence has no verb in it

4.   Also in in Section 7.1 - the last paragraph can be dropped - this was 
already said in the section

5.   In Section 9 I cannot make sense of the sentence that starts with 'In 
the return ...'



Regards,



Dan







___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review for draft-ietf-grow-ix-bgp-route-server-operations

[Romascanu, Dan (Dan)]

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: 
http://www.ietf.org/id/draft-ietf-grow-ix-bgp-route-server-operations-03.txt

Reviewer: Dan Romascanu

Review Date: 9/18/14

IETF LC End Date: 9/22/14

IESG Telechat date: none



Summary:



A useful and very well written document, with a few minor issues that need 
clarification and fixes before publication



Major issues:



None



Minor issues:



1.   The reference [RS-ARCH] mentioned in 4.2.1.1 and 4.2.1.2 is not 
reachable (Error 404). As the understanding of the issues described in the two 
sections depend on this reference, a valid reference is required.

2.   Section 4.2.1.3 uses the term 'flat layer 2 network' which has at 
least two meanings depending on the context or layer - either one VLAN space at 
the link layer (as to differentiate from Customer VLAN and Provider VLAN) or a 
bridged network with no routers between the bridged segments. Clarification is 
needed.

3.   The usage of keywords is inconsistent in a few place. In 4.6.1 the 
'should' in the second paragraph needs to be capitalized. In 4.6.3 we have a 
capitalized SHOULD, but then a non-capitalized 'may' for statements that both 
seem to describe requirements of the same level.

4.   I am doubt that Section 4.7 is that useful. On one hand reliability of 
layer 2 forwarding is not in my opinion such a big issue, and measures can be 
taken a the link layer to improve it (use lags or redundant paths). Second the 
recommended mitigation (RFC 5881 BFD) is described as non-optimal, with no 
other alternative. I would just drop this section completely.



Nits/editorial comments:



1.   The English syntax of the second paragraph in the Abstract is broken.

2.   In the introduction there is a mention of 'using shared Layer-2 
networking media such as Ethernet'. Actually Ethernet is seldom used nowadays 
as a shared media, I would just recommend saying 'using data link layers 
protocols such as Ethernet'

3.   In section 4.2 s/optimization technique is implemented/optimization 
technique that is implemented/





___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review for draft-ietf-tictoc-security-requirements

[Romascanu, Dan (Dan)]

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: 
https://datatracker.ietf.org/doc/draft-ietf-tictoc-security-requirements/

Reviewer: Dan Romascanu

Review Date: 7/14/14

IETF LC End Date: 7/16/14

IESG Telechat date:



Summary:



A well written, clear and useful document documenting the security threats and 
the requirements on the deployment and activation of security protocols and 
options in the context of the time protocols with focus on NTP and PTP. Ready 
with a few non-blocking issues.



Major issues:



None



Minor issues:

1.   I am wondering if section 5.4 'Availability' says anything different 
from what is already said in 5.1.3. which already talked about authentication 
of slaves impact on availability

2.   Section 5.6.1 - 'The cryptographic keys MUST be refreshed frequently' 
- some definition of or detail about 'frequently' is required to make this 
requirement actionable



Nits/editorial comments:



1.   Title of section 5.1.2 is printed differently than other titles at the 
same level of indent

2.   Section 5.2 - s/implemented/implemented

3.   Section 5.3 -  s/tamper with slaves' delay computation/tamer with the 
slaves' delay computation/

4.   Section 5.6.2 - Security Association has different meaning in other 
context. Is not this section really about Association Protocol?

5.   Why is Summary of Requirements a separate section (6)?

6.   It looks to me that the references for NTPv4 and IEEE1588 should be 
Normative - it does not make much sense to read this document without a fair 
understanding of these.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [xmpp] Gen-ART review for draft-ietf-xmpp-websocket-07

[Romascanu, Dan (Dan)]

OK, I accept this, but in this case the text in the I-D should probably be 
worded slightly different:


  The WebSocket XMPP sub-protocol deviates from the standard method of

 constructing and using XML streams as defined in [RFC6120] by

 adopting the message framing provided by WebSocket to delineate the

 stream open and close headers, stanzas, and other top-level stream

 elements.


‘deviates’ IMO suggests a change to the base specification, not just an 
optional new binding.

Regards,

Dan


From: Richard Barnes [mailto:r...@ipv.sx]
Sent: Tuesday, July 08, 2014 9:59 PM
To: Dave Cridland
Cc: Romascanu, Dan (Dan); draft-ietf-xmpp-websocket@tools.ietf.org; 
gen-art@ietf.org; Jari Arkko; x...@ietf.org
Subject: Re: [xmpp] [Gen-art] Gen-ART review for draft-ietf-xmpp-websocket-07

On Tue, Jul 8, 2014 at 12:20 PM, Dave Cridland 
d...@cridland.netmailto:d...@cridland.net wrote:
On 8 July 2014 16:49, Romascanu, Dan (Dan) 
droma...@avaya.commailto:droma...@avaya.com wrote:
Hi Dave,

An implementor of RFC 6120 does not know that the XMPP over Websockets binding 
option exists at all. It did not exist by the time 6120 was written, so of 
course, they can do without it. Now that the binding exist, the option should 
be visible IMO.


OK, but why is this case different to, for example, an IMAP extension, where we 
don't say Updates: 3501 every time - indeed, qresync got serious push-back 
over the Updates there.

I agree.  This document does not update RFC 6120.  If an implementation of RFC 
6120 does not support this transport, then it will never need to know about the 
framing changes.  If it does, then it will.  The two are separate.

Updates is not a mechanism for advertising additional features.
--Richard



Dave.

___
xmpp mailing list
x...@ietf.orgmailto:x...@ietf.org
https://www.ietf.org/mailman/listinfo/xmpp

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [xmpp] Gen-ART review for draft-ietf-xmpp-websocket-07

[Romascanu, Dan (Dan)]

wfm

Thanks and Regards,

Dan


 -Original Message-
 From: Peter Saint-Andre [mailto:stpe...@stpeter.im]
 Sent: Wednesday, July 09, 2014 5:39 PM
 To: Romascanu, Dan (Dan); Richard Barnes; Dave Cridland
 Cc: draft-ietf-xmpp-websocket@tools.ietf.org; gen-art@ietf.org; Jari
 Arkko; x...@ietf.org
 Subject: Re: [xmpp] [Gen-art] Gen-ART review for draft-ietf-xmpp-
 websocket-07
 
 On 7/9/14, 7:16 AM, Romascanu, Dan (Dan) wrote:
  OK, I accept this, but in this case the text in the I-D should
  probably be worded slightly different:
 
 The WebSocket XMPP sub-protocol deviates from the standard
 method
  of
 
constructing and using XML streams as defined in [RFC6120] by
 
adopting the message framing provided by WebSocket to delineate
 the
 
stream open and close headers, stanzas, and other top-level stream
 
elements.
 
  'deviates' IMO suggests a change to the base specification, not just
  an optional new binding.
 
 How about this:
 
 OLD
 The WebSocket XMPP sub-protocol deviates from the standard method of
 constructing and using XML streams as defined in [RFC6120] by
 adopting the message framing provided by WebSocket to delineate the
 stream open and close headers, stanzas, and other top-level stream
 elements.
 
 NEW
 The framing method for the binding of XMPP to WebSocket differs
 from the framing method for the TCP binding as defined in [RFC6120];
 in particular, the WebSocket binding adopts the message framing
 provided by WebSocket to delineate the stream open and close
 headers, stanzas, and other top-level stream elements.
 
 Peter

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review for draft-ietf-xmpp-websocket-07

[Romascanu, Dan (Dan)]

Hi Jari,

The authors actually responded - see 
http://www.ietf.org/mail-archive/web/gen-art/current/msg10306.html. 

They pushed back on my #1 - I am still not convinced by their argument (as the 
protocol does change by adding a different mapping) but I would not block the 
document for this purpose. 
The proposed changes for the rest are fine. 

Regards,

Dan
 

 -Original Message-
 From: Jari Arkko [mailto:jari.ar...@piuha.net]
 Sent: Tuesday, July 08, 2014 7:58 AM
 To: Romascanu, Dan (Dan)
 Cc: gen-art@ietf.org; draft-ietf-xmpp-websocket@tools.ietf.org;
 x...@ietf.org
 Subject: Re: [Gen-art] Gen-ART review for draft-ietf-xmpp-websocket-07
 
 Thanks for the review, Dan.
 
 I would like to see some thoughts from the editors regarding the two points
 that you raised.
 
 Jari
 
 On 02 Jul 2014, at 09:00, Romascanu, Dan (Dan) droma...@avaya.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: https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/
  Reviewer: Dan Romascanu
  Review Date: 7/2/2014
  IETF LC End Date: 7/4/2014
  IESG Telechat date: 7/10/2014
 
  Summary: ready with minor issues
 
  Major issues:
 
  None
 
  Minor issues:
 
  1.   In order to accommodate the Websocket binding this document
 describes several deviations from RFC6120. For example, in Section 3.3 it
 says:
  The WebSocket XMPP sub-protocol deviates from the standard method of
 constructing and using XML streams as defined in [RFC6120] by
 adopting the message framing provided by WebSocket to delineate the
 stream open and close headers, stanzas, and other top-level stream
 elements.
I am wondering whether it would not be appropriate to reflect 
  this
 in the document header by adding Updates RFC6120
 
  2.   In Section 3.6.1:
 
 If the server wishes at any point to instruct the client to move to a
 different WebSocket endpoint (e.g. for load balancing purposes), the
 server MAY send a close/ element and set the see-other-uri
 attribute to the URI of the new connection endpoint (which MAY be for
 a different transport method, such as BOSH (see [XEP-0124] and
 [XEP-0206]).
 
  I do not understand the usage of MAY in this paragraph. Is there
 another method to move to a different Web socket endpoint that is
 described here or some other place? In not, why is not the first MAY at least
 a SHOULD? The second usage seems to describe a state of facts, so it needs
 not be capitalized at all.
 
 
  Nits/editorial comments:
 
  In Section 3.1 I believe that the example should be preceded by some text
 that indicates that this is an example, such as: 'An example of a successful
 handshake and start of session follows:'
 
 
  ___
  Gen-art mailing list
  Gen-art@ietf.org
  https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [xmpp] Gen-ART review for draft-ietf-xmpp-websocket-07

[Romascanu, Dan (Dan)]

Hi Dave,

An implementor of RFC 6120 does not know that the XMPP over Websockets binding 
option exists at all. It did not exist by the time 6120 was written, so of 
course, they can do without it. Now that the binding exist, the option should 
be visible IMO.

The language you use in the I-D actually seems to support this:

 The WebSocket
 XMPP sub-protocol deviates from the standard method of constructing and using
 XML streams as defined in [RFC6120] by adopting the message framing provided 
 by
 WebSocket to delineate the stream open and close headers, stanzas, and other
 top-level stream elements.

Regards,

Dan


From: Dave Cridland [mailto:d...@cridland.net]
Sent: Tuesday, July 08, 2014 6:30 PM
To: Romascanu, Dan (Dan)
Cc: Jari Arkko; draft-ietf-xmpp-websocket@tools.ietf.org; gen-art@ietf.org; 
x...@ietf.org
Subject: Re: [xmpp] [Gen-art] Gen-ART review for draft-ietf-xmpp-websocket-07

On 8 July 2014 10:06, Romascanu, Dan (Dan) 
droma...@avaya.commailto:droma...@avaya.com wrote:
Hi Jari,

The authors actually responded - see 
http://www.ietf.org/mail-archive/web/gen-art/current/msg10306.html.

They pushed back on my #1 - I am still not convinced by their argument (as the 
protocol does change by adding a different mapping) but I would not block the 
document for this purpose.
The proposed changes for the rest are fine.

I genuinely don't understand why adding an additional binding should require an 
Updates.

I understand Updates to be an indicator that implementors of (in this case) 
RFC 6120 would need to read this document as well, and I don't believe that to 
be the case.

In particular, implementors of RFC 6120 don't need to care about this document 
unless they *also* want to do XMPP over Websockets, in the same way that 
implementors of Websockets don't need to care about this document unless they 
*also* want to send XMPP over them.

Of course, readers of this document are required to read both RFC 6120 and the 
Websockets spec, but that's what Normative References are for.

Dave.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review for draft-ietf-xmpp-websocket-07

[Romascanu, Dan (Dan)]

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: https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/

Reviewer: Dan Romascanu

Review Date: 7/2/2014

IETF LC End Date: 7/4/2014

IESG Telechat date: 7/10/2014



Summary: ready with minor issues



Major issues:



None



Minor issues:



1.   In order to accommodate the Websocket binding this document describes 
several deviations from RFC6120. For example, in Section 3.3 it says:

The WebSocket XMPP sub-protocol deviates from the standard method of

   constructing and using XML streams as defined in [RFC6120] by

   adopting the message framing provided by WebSocket to delineate the

   stream open and close headers, stanzas, and other top-level stream

   elements.

  I am wondering whether it would not be appropriate to reflect 
this in the document header by adding Updates RFC6120



2.   In Section 3.6.1:



   If the server wishes at any point to instruct the client to move to a

   different WebSocket endpoint (e.g. for load balancing purposes), the

   server MAY send a close/ element and set the see-other-uri

   attribute to the URI of the new connection endpoint (which MAY be for

   a different transport method, such as BOSH (see [XEP-0124] and

   [XEP-0206]).



I do not understand the usage of MAY in this paragraph. Is there 
another method to move to a different Web socket endpoint that is described 
here or some other place? In not, why is not the first MAY at least a SHOULD? 
The second usage seems to describe a state of facts, so it needs not be 
capitalized at all.





Nits/editorial comments:



In Section 3.1 I believe that the example should be preceded by some text that 
indicates that this is an example, such as: 'An example of a successful 
handshake and start of session follows:'



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review for draft-salgueiro-dispatch-websocket-sipclf

[Romascanu, Dan (Dan)]

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: 
http://www.ietf.org/id/draft-salgueiro-dispatch-websocket-sipclf-01.txt

Reviewer: Dan Romascanu

Review Date: 6/2/2014

IETF LC End Date: 6/10/2014

IESG Telechat date: not scheduled yet



Summary:



This document which updates the SIP Common Log Format (CLF) defined in RFC 6873 
with a new Transport Flag for the RFC 7118 SIP WebSocket transport is ready.



Major issues:



None



Minor issues:



None



Nits/editorial comments:


None

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] GenART review of draft-ietf-dhc-dhcpv4-over-dhcpv6

[Romascanu, Dan (Dan)]

Hi Qi,

Thanks for the answer and for addressing my comments. The proposed edits look 
fine.

Regards,

Dan


From: Qi Sun [mailto:sunqi.csnet@gmail.com]
Sent: Monday, May 12, 2014 7:37 AM
To: Romascanu, Dan (Dan)
Cc: gen-art@ietf.org; draft-ietf-dhc-dhcpv4-over-dhcpv6@tools.ietf.org
Subject: Re: GenART review of draft-ietf-dhc-dhcpv4-over-dhcpv6

Dear Dan,

Thanks for your review and comments. We have some proposed changes to the -07 
version. Please see inline.

Best Regards,
Qi

On Apr 28, 2014, at 6:05 PM, Romascanu, Dan (Dan) 
droma...@avaya.commailto:droma...@avaya.com wrote:
Minor issues:

1.   In section 10:

   When the server receives a DHCPv4-query message from a client, it
   searches for the DHCPv4 Message option.  The server discards the
   packet without this option.  The server MAY notify an administrator
   about the receipt of a malformed packet.  The mechanism for this
   notification is out of scope for this document.

It would be good to clarify the behavior of the server beyond possibly 
notifying an administrator at the receipt of a malformed packet. Is the packet 
discarded?

[Qi] The original text is a little odd. How about the following text:
OLD:
   When the server receives a DHCPv4-query message from a client, it
   searches for the DHCPv4 Message option.  The server discards the
   packet without this option.  The server MAY notify an administrator
   about the receipt of a malformed packet.  The mechanism for this
   notification is out of scope for this document.

NEW:
   When the server receives a DHCPv4-query message from a client, it
   searches for the DHCPv4 Message option.  The server discards a packet
   without this option.  In addition, the server MAY notify an
   administrator about the receipt of this malformed packet.  The
   mechanism for this notification is out of scope for this document.



2.   I believe that [RFC3527] should rather be a Normative Reference. Even 
if the use of a Link Selection sub-option is under a 'may' - it cannot be 
implemented unless RFC3527 is read.

[Qi] When we wrote the related text, we didn't try to detail it for actually 
implement. And during the develop of DHCPv4 over DHCPv6 (and WGLC), the working 
group hasn't showed intention to do anything about that. So it might be better 
by taking out some text:
OLD:
   The server may also act as a DHCPv4 relay agent and forward the
   DHCPv4 packet to a normal DHCPv4 server.  In this case, the server
   would need to set the giaddr to one of its own addresses and add
   Relay Agent Information option (82), including a Link Selection
   suboption [RFC3527] with the IPv4 subnet to assign a DHCPv4 address
   from, as mentioned above.  There are other complexities with this
   solution as enough information needs to be retained (or included in a
   Relay Agent Information option) to be able to return the response
   back to the client; how this might be done is outside the scope of
   this document.
NEW:
   Alternatively, the server may act as a DHCPv4 relay agent and forward
   the DHCPv4 packet to a normal DHCPv4 server.  The details of of
   such a solution have not been considered by the working group;
   describing that solution is out of scope of this document and is left
   as future work should the need for it arise.

Would the new text be OK?

Nits/editorial comments:

In the introduction there is reference to the 'DHCP leasequery'. Actually in 
RFC 4388 one can find Leasequery either capitalized (in the title) or ALL-CAPS 
in the text.

[Qi] Thanks. Have updated accordingly.




___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] GenART review of draft-ietf-dhc-dhcpv4-over-dhcpv6

[Romascanu, Dan (Dan)]

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: http://www.ietf.org/id/draft-ietf-dhc-dhcpv4-over-dhcpv6-07.txt

Reviewer: Dan Romascanu

Review Date: 4/28/14

IETF LC End Date: 4/29/14

IESG Telechat date:



Summary: Ready, with a few small issues



Major issues: None



Minor issues:



1.   In section 10:


   When the server receives a DHCPv4-query message from a client, it
   searches for the DHCPv4 Message option.  The server discards the
   packet without this option.  The server MAY notify an administrator
   about the receipt of a malformed packet.  The mechanism for this
   notification is out of scope for this document.

It would be good to clarify the behavior of the server beyond possibly 
notifying an administrator at the receipt of a malformed packet. Is the packet 
discarded?


2.   I believe that [RFC3527] should rather be a Normative Reference. Even 
if the use of a Link Selection sub-option is under a 'may' - it cannot be 
implemented unless RFC3527 is read.





Nits/editorial comments:



In the introduction there is reference to the 'DHCP leasequery'. Actually in 
RFC 4388 one can find Leasequery either capitalized (in the title) or ALL-CAPS 
in the text.





___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Telechat Review for draft-ietf-idr-aigp-17

[Romascanu, Dan (Dan)]

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 wait for direction from your document shepherd or AD before posting a 
new version of the draft.



Document: https://datatracker.ietf.org/doc/draft-ietf-idr-aigp/

Reviewer: Dan Romascanu

Review Date: 4/23/14

IETF LC End Date: 4/8/14

IESG Telechat date: 4/24/14



Summary: Ready



Major issues:



Minor issues:



Nits/editorial comments:

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review for draft-ietf-idr-aigp-16

[Romascanu, Dan (Dan)]

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-idr-aigp-16

Reviewer: Dan Romascanu

Review Date: 4/2/14

IETF LC End Date: 4/8/14

IESG Telechat date: (if known)



Summary:



Ready



Major issues:



None



Minor issues:



None



Nits/editorial comments:



In Section 3.4.1 in page 8:



Ø  The AIGP attribute may be added only to routes that satisfy one of the 
following conditions:



It seems to me that in order to be consistent with similar statements in the 
same section the 'may' here needs to be a capitalized RFC 2119 MAY

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review for draft-ietf-mpls-ldp-applicability-label-adv-02

[Romascanu, Dan (Dan)]

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-ldp-applicability-label-adv-02

Reviewer: Dan Romascanu

Review Date: 2/24/14

IETF LC End Date: 2/24/14

IESG Telechat date:



Summary: ready with minor issues



Major issues:



Minor issues:



In the table in 2.2 - the RFC column points to RFC 5036 for the first two 
entries. Actually RFC 5036 defines only the range for LDP FEC types, but says 
nothing about the values. The right information seems to be ' (this RFC)' 
or '5036 and  (this RFC)'



Nits/editorial comments:


Some acronyms are not expanded at first occurrence - FEC, LSR


Regards,

Dan

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART telechat review of draft-ietf-pwe3-iccp-13.txt

[Romascanu, Dan (Dan)]

Hi Samer,

Thank you for your response and for addressing my comments. I am fine with the 
proposed solutions. At this point in the process the change control of the 
document is with the shepherding AD, so please wait for his instructions about 
when to update the document. 

Regards,

Dan


 -Original Message-
 From: Samer Salam (ssalam) [mailto:ssa...@cisco.com]
 Sent: Wednesday, February 19, 2014 8:30 PM
 To: Andrew G. Malis; Romascanu, Dan (Dan)
 Cc: gen-art@ietf.org; draft-ietf-pwe3-iccp@tools.ietf.org; BOCCI Matthew
 Subject: Re: Gen-ART telechat review of draft-ietf-pwe3-iccp-13.txt
 
 Hi Dan,
 
 Thank you for your review. Please find responses inlineŠ
 
 Hi Andy,
 
 Please let us know when we can go ahead an update the draft to address the
 review comments.
 
 
 Regards,
 Samer
 
 On 2014-02-19 6:31 AM, Andrew G. Malis agma...@gmail.com wrote:
 
 Dan,
 
 Thanks for the review (twice!).
 
 Authors,
 
 Could you please respond to Dan's review and comments?
 
 Thanks,
 Andy
 
 
 On Wed, Feb 19, 2014 at 3:23 AM, Romascanu, Dan (Dan)
 droma...@avaya.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 wait for direction from your document shepherd or AD before
 posting a  new version of the draft.
 
 
 
 
 
  Document: draft-ietf-pwe3-iccp-13.txt
 
  Reviewer: Dan Romascanu
 
  Review Date: 2/19/14
 
  IETF LC End Date: 2/11/14
 
  IESG Telechat date: 2/20/14
 
 
 
  Summary:
 
 
 
  Ready with issues. I did not see any answer from the editors or
 shepherd to  the issues raised in the IETFLC Gen-ART review and there
 was no revision of  the document since then. Although none of the
 issues raised seems to be  blocking, I believed that they should be
 considered and answered as part of  the IETF Last Call Comments.
 
 
 
  This is a complex but well written document. It is ready, a number of
 minor  issues need clarification and possibly editing. Some nits also
 may be  considered to fix
 
 
 
  Major issues:
 
 
 
  None
 
 
 
  Minor issues:
 
 
 
  1.   The document (and the name of the protocol defined here) uses
 the
  notion of 'chassis'. However there is no definition or reference to a
 definition that would clarify what a 'chassis' is.
 
 Good point, will add a definition to that effect.
 
 
  2.   In section 7.2.2.1 - I am not a fan of transferring
 information in
  text format like in the Disconnect Cause String - no interoperability
 results if there no agreement on a finite set of causes. Anyway -
 should  this not be UTF-8 format?
 
 This is meant to relay information to a human user, and not intended to be
 used to take any automated actions. Will clarify that it is UTF-8.
 
 
  3.   Similar question in Section 7.2.4 - why is Aggregator Name a
 text?
  Why not using AggregatorID as per IEEE 802.1AX?
 
 The AggregatorID is already part of the TLV. The name is to enhance human
 usability, same reason as above.
 
 
  4.   In Section 7.2.5 - if Port Speed corresponds to the ifHighSpeed
  object in the IF-MIB, should not also Port (interface) name
 correspond to  ifName truncated to 20 characters whenever possible?
 
 
 Agreed, will update accordingly.
 
 
 
 
 
  Nits/editorial comments:
 
 
 
  1.   Some acronyms need expansion at the first occurrence - e.g.
 POP, CO
 
 Will update the draft accordingly.
 
 
  2.   In section 3.3/i: PE nodes MAY be collocated or remote - this
 MAY
  needs not be capitalized.
 
 Will fix.
 
 
  3.   The first two lines in the diagram in page 16 are mis-aligned
 
 Will fix.
 
 
  4.   The diagrams in 7.1.1., 7.1.5   end at 16-bit boundary with the
  last field defined for optional sub-TLVs. Is this intentional? Do they
  suggest that the number of octets is always 4*n + 2? What happens else?
 
 No that was not intentional. Will add text to clarify that there are no
 such assumptions.
 
 
  5.   In section 7.3.1:' -ii. PW ID TLV or generalized PW ID TLV' I
 think
  what is meant is actually ' -ii. One of PW ID TLV or generalized PW ID
 TLV'
 
 Will update.
 
 
 
 
 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Telechat review of draft-ietf-dane-registry-acronyms-03

[Romascanu, Dan (Dan)]

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 wait for direction from your document shepherd or AD before posting a 
new version of the draft.



Document: draft-ietf-dane-registry-acronyms-03

Reviewer: Dan Romascanu

Review Date: 2/19/14

IETF LC End Date:

IESG Telechat date: 2/19/14



Summary:



Ready. All issues mentioned in the IETFLC Gen-ART review were addressed. Thank 
you.



Major issues:



Minor issues:



Nits/editorial comments:

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART telechat review of draft-ietf-pwe3-iccp-13.txt

[Romascanu, Dan (Dan)]

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 wait for direction from your document shepherd or AD before posting a 
new version of the draft.



Document: draft-ietf-pwe3-iccp-13.txt

Reviewer: Dan Romascanu

Review Date: 2/19/14

IETF LC End Date: 2/11/14

IESG Telechat date: 2/20/14



Summary:



Ready with issues. I did not see any answer from the editors or shepherd to the 
issues raised in the IETFLC Gen-ART review and there was no revision of the 
document since then. Although none of the issues raised seems to be blocking, I 
believed that they should be considered and answered as part of the IETF Last 
Call Comments.



This is a complex but well written document. It is ready, a number of minor 
issues need clarification and possibly editing. Some nits also may be 
considered to fix



Major issues:



None



Minor issues:



1.   The document (and the name of the protocol defined here) uses the 
notion of 'chassis'. However there is no definition or reference to a 
definition that would clarify what a 'chassis' is.

2.   In section 7.2.2.1 - I am not a fan of transferring information in 
text format like in the Disconnect Cause String - no interoperability results 
if there no agreement on a finite set of causes. Anyway - should this not be 
UTF-8 format?

3.   Similar question in Section 7.2.4 - why is Aggregator Name a text? Why 
not using AggregatorID as per IEEE 802.1AX?

4.   In Section 7.2.5 - if Port Speed corresponds to the ifHighSpeed object 
in the IF-MIB, should not also Port (interface) name correspond to ifName 
truncated to 20 characters whenever possible?





Nits/editorial comments:



1.   Some acronyms need expansion at the first occurrence - e.g. POP, CO

2.   In section 3.3/i: PE nodes MAY be collocated or remote - this MAY 
needs not be capitalized.

3.   The first two lines in the diagram in page 16 are mis-aligned

4.   The diagrams in 7.1.1., 7.1.5   end at 16-bit boundary with the last 
field defined for optional sub-TLVs. Is this intentional? Do they suggest that 
the number of octets is always 4*n + 2? What happens else?

5.   In section 7.3.1:' -ii. PW ID TLV or generalized PW ID TLV' I think 
what is meant is actually ' -ii. One of PW ID TLV or generalized PW ID TLV'


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-ietf-pwe3-iccp-13.txt

[Romascanu, Dan (Dan)]

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-iccp-13.txt

Reviewer: Dan Romascanu

Review Date: 2/10/14

IETF LC End Date: 2/11/14

IESG Telechat date:



Summary:



Ready with issues.



This is a complex but well written document. It is ready, a number of minor 
issues need clarification and possibly editing. Some nits also may be 
considered to fix



Major issues:



None



Minor issues:



1.   The document (and the name of the protocol defined here) uses the 
notion of 'chassis'. However there is no definition or reference to a 
definition that would clarify what a 'chassis' is.

2.   In section 7.2.2.1 - I am not a fan of transferring information in 
text format like in the Disconnect Cause String - no interoperability results 
if there no agreement on a finite set of causes. Anyway - should this not be 
UTF-8 format?

3.   Similar question in Section 7.2.4 - why is Aggregator Name a text? Why 
not using AggregatorID as per IEEE 802.1AX?

4.   In Section 7.2.5 - if Port Speed corresponds to the ifHighSpeed object 
in the IF-MIB, should not also Port (interface) name correspond to ifName 
truncated to 20 characters whenever possible?





Nits/editorial comments:



1.   Some acronyms need expansion at the first occurrence - e.g. POP, CO

2.   In section 3.3/i: PE nodes MAY be collocated or remote - this MAY 
needs not be capitalized.

3.   The first two lines in the diagram in page 16 are mis-aligned

4.   The diagrams in 7.1.1., 7.1.5   end at 16-bit boundary with the last 
field defined for optional sub-TLVs. Is this intentional? Do they suggest that 
the number of octets is always 4*n + 2? What happens else?

5.   In section 7.3.1:' -ii. PW ID TLV or generalized PW ID TLV' I think 
what is meant is actually ' -ii. One of PW ID TLV or generalized PW ID TLV'

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART telechat review for draft-ietf-clue-telepresence-requirements

[Romascanu, Dan (Dan)]

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-clue-telepresence-requirements-07.txt

Reviewer: Dan Romascanu

Review Date: 2/5/2014

IETF LC End Date: 11/27/2013

IESG Telechat date: 2/6/2014



Summary:

Ready - all issues raised in my LC review were addressed. Thanks.



Major issues:



Minor issues:



Nits/editorial comments:



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART telechat review for draft-ietf-stox-core-09

[Romascanu, Dan (Dan)]

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-stox-core

Reviewer: Dan Romascanu

Review Date: 2/5/2014

IETF LC End Date: 12/11/2013

IESG Telechat date: 2/6/2014



Summary:



Ready.



Major issues:



Minor issues:



Nits/editorial comments:



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART telechat review of draft-ietf-p2psip-rpr-11

[Romascanu, Dan (Dan)]

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.


Document: draft-ietf-p2psip-rpr-11

Reviewer: Dan Romascanu

Review Date: 2/5/2014

IETF LC End Date: 2013/09/30

IESG Telechat date: 2/6/2014



Summary:



Ready. All issues raised in the LC review were addressed. Thanks.



Major issues:



Minor issues:



Nits/editorial comments:



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [dane] Gen-ART Review of draft-ietf-dane-registry-acronyms-03

[Romascanu, Dan (Dan)]

Looks good, thank you for addressing my comments.

Regards,

Dan


From: Olafur Gudmundsson [mailto:o...@ogud.com]
Sent: יום ה 16 ינואר 2014 22:46
To: Romascanu, Dan (Dan)
Cc: gen-art@ietf.org; draft-ietf-dane-registry-acronyms@tools.ietf.org; 
d...@ietf.org
Subject: Re: [dane] Gen-ART Review of draft-ietf-dane-registry-acronyms-03


On Jan 15, 2014, at 10:11 AM, Romascanu, Dan (Dan) 
droma...@avaya.commailto:droma...@avaya.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: http://www.ietf.org/id/draft-ietf-dane-registry-acronyms-03.txt
Reviewer: Dan Romascanu
Review Date: 1/15/2014
IETF LC End Date: 1/23/2014
IESG Telechat date:

Summary:
Ready with issues

Major issues:
None – it’s a simple, clear and useful document.

thanks



Minor issues:
1.   In Section 2.3 the I-D recommends that the values in reference column 
for SHA-256 and SHA-512 refer to [RFC 6698] while the IANA Considerations 
section in RFC 6698 recommends and the registry entries in the TLSA Matching 
Types table 
athttp://www.iana.org/assignments/dane-parameters/dane-parameters.xhtml  point 
to [RFC 6234].

Good Catch, fixed


2.   As this I-D updates the registries with a column for acronyms, it 
seems more accurate that the reference columns of all tables mention both  [RFC 
6698] and [RFC ] (this RFC)

I'm not sure if I agree, all this document does is to change the format of the 
registries it is not the definitions of any table entry.
But I think it would be good to change the reference for each of the registries 
to point to both RFC6698 and RFC

I propose adding to each registry sections the following text:
Update reference for this registry to include both [RFC6698] and 
[RFC-this-document]


Nits/editorial comments:
In the Introduction section:

‘This document updates the IANA registry definition for TLSA
   record to add a column with acronym for each specified field’
s/acronym/an acronym/


Fixed

thanks

  Olafur

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Review of draft-ietf-dane-registry-acronyms-03

[Romascanu, Dan (Dan)]

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: http://www.ietf.org/id/draft-ietf-dane-registry-acronyms-03.txt

Reviewer: Dan Romascanu

Review Date: 1/15/2014

IETF LC End Date: 1/23/2014

IESG Telechat date:



Summary:

Ready with issues



Major issues:

None - it's a simple, clear and useful document.



Minor issues:

1.   In Section 2.3 the I-D recommends that the values in reference column 
for SHA-256 and SHA-512 refer to [RFC 6698] while the IANA Considerations 
section in RFC 6698 recommends and the registry entries in the TLSA Matching 
Types table at 
http://www.iana.org/assignments/dane-parameters/dane-parameters.xhtml  point to 
[RFC 6234].

2.   As this I-D updates the registries with a column for acronyms, it 
seems more accurate that the reference columns of all tables mention both  [RFC 
6698] and [RFC ] (this RFC)



Nits/editorial comments:

In the Introduction section:

'This document updates the IANA registry definition for TLSA

   record to add a column with acronym for each specified field'

s/acronym/an acronym/









___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-ietf-isis-rfc1142-to-historic-00

[Romascanu, Dan (Dan)]

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-isis-rfc1142-to-historic-00
Reviewer: Dan Romascanu
Review Date: 12/17/13
IETF LC End Date: 12/24/13
IESG Telechat date: 

Summary: Ready

Major issues:

Minor issues:

It may be more cautious refer to the 'latest available' version of the IS-IS 
standard as we cannot be completely sure that the Second Edition will also be 
the very last one. Suggested change in Section 1: 

OLD: 

   All references to IS-IS should be to ISO/IEC 10589:2002, Second
   Edition and RFC 1142 is only of historic interest.

NEW: 

   All references to IS-IS should be to the latest edition of the IS-IS
   standard (currently ISO/IEC 10589:2002, Second
   Edition) and RFC 1142 is only of historic interest.

Nits/editorial comments:




___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review for draft-ietf-stox-core-07

[Romascanu, Dan (Dan)]

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-stox-core-07
Reviewer: Dan Romascanu
Review Date: 12/9/13
IETF LC End Date: 12/11/13
IESG Telechat date: 

Summary:
Ready

Major issues:
None

Minor issues:
None

Nits/editorial comments:

1. Please expand XSF at first occurrence
2. It would be good to find some other wording for 'This document inaugurates a 
series of SIP-XMPP interworking specifications'. For example 'This document 
provides information for a series of SIP-XMPP interworking specifications'


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [Stox] Gen-ART review for draft-ietf-stox-core-07

[Romascanu, Dan (Dan)]

 -Original Message-
 From: Peter Saint-Andre [mailto:stpe...@stpeter.im]
 
 How about s/inaugurates/provides the basis for/ ?
 

Fine. 

Thanks, 

Dan

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Telechat review for draft-ietf-soc-load-control-event-package-11

[Romascanu, Dan (Dan)]

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 wait for direction from your document shepherd or AD before posting a 
new version of the draft.

Document: draft-ietf-soc-load-control-event-package-11
Reviewer: Dan Romascanu
Review Date: 12/3/13 (for the telechat)
IETF LC End Date:
IESG Telechat date: 12/5/13

Summary: ready - all issues raised in the IETF LC review were addressed by 
edits or clarified by explanations.

Major issues:

Minor issues:

Nits/editorial comments:


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review for draft-ietf-soc-load-control-event-package-10.txt

[Romascanu, Dan (Dan)]

Hi Charles,

No, this is not a strong comment. Actually all my comments were listed as 
‘minor’ thus non-blocking vs. a document I appreciate as of good quality. Thank 
you for the dialog and for considering my comments.

Regards,

Dan





From: charles.newy...@gmail.com [mailto:charles.newy...@gmail.com] On Behalf Of 
Charles Shen
Sent: Monday, November 25, 2013 11:06 AM
To: Romascanu, Dan (Dan)
Cc: gen-art@ietf.org; 
draft-ietf-soc-load-control-event-package@tools.ietf.org; 
sip-overl...@ietf.org
Subject: Re: Gen-ART review for draft-ietf-soc-load-control-event-package-10.txt

Hi Dan,

On Mon, Nov 25, 2013 at 1:09 AM, Romascanu, Dan (Dan) 
droma...@avaya.commailto:droma...@avaya.com wrote:


Also, in the same list of requirements I miss an explicit requirement on 
persistency.


This part I am not sure if I understand clearly, could you please elaborate a 
bit?

 [[DR]] In section 5.3, second paragraph there are a couple of references to 
the persistency of subscriptions of neighboring SIP entities and periodic 
refresh. Should not this be mentioned explicitly in the list in Section 4?

I see what you mean. In fact I tend to think of this as one of those 
micro-aspects that have been covered by existing macro-clauses. Specifically, 
as Section 5.3 says:


 Key to this is the fact that following initial

   subscription, the notifier sends a notification without a body if no

   load filtering policy is defined (Section 
6.7http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-11#section-6.7),
 and that the

   subscription needs to be refreshed periodically to make it

   persistent, as described in Section 
4.1http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-11#section-4.1
 and Section 4.2 of [RFC6665]http://tools.ietf.org/html/rfc6665#section-4.2.

The behavior of notifier sending a notification following initial subscription 
is mandated in Section 6.7 of this document. And the behavior of periodic 
refresh is specified in Section 4.1 and Section 4.2 of RFC 6665.

Both this document and RFC 6665 have already been explicitly listed in Section 
4 of this document. So they seem to have covered the persistency issue.

That said, I am open to add another explicit clause for this aspect if you 
really feel strongly about it. Please let me know. Thanks again!

Charles



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review for draft-ietf-soc-load-control-event-package-10.txt

[Romascanu, Dan (Dan)]

Hi,

Thank you for addressing my comments. See in-line.

Regards,

Dan



From: charles.newy...@gmail.com [mailto:charles.newy...@gmail.com] On Behalf Of 
Charles Shen
Sent: Sunday, November 24, 2013 9:53 AM
To: Romascanu, Dan (Dan)
Cc: gen-art@ietf.org; 
draft-ietf-soc-load-control-event-package@tools.ietf.org; 
sip-overl...@ietf.org
Subject: Re: Gen-ART review for draft-ietf-soc-load-control-event-package-10.txt

Dear Dan,

Thank you very much for your review. Please see inline.

On Tue, Nov 19, 2013 at 10:36 PM, Romascanu, Dan (Dan) 
droma...@avaya.commailto:droma...@avaya.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-soc-load-control-event-package-10.txt
Reviewer: Dan Romascanu
Review Date: 11/19/13
IETF LC End Date: 11/19/13
IESG Telechat date: (if known)

Summary: The document is ready, there are a few minor issues which are worth 
being clarified.

Major issues: None.

Minor issues:

1. I had some issues with the examples in the introduction.

  There are three common examples of legitimate short-term increases in
   call volumes.  Viewer-voting TV shows or ticket giveaways may
   generate millions of calls within a few minutes.  Call volume may
   also spike during special holidays such as New Year's Day and
   Mother's Day. Finally, callers may want to reach friends and family
   in natural disaster areas such as those affected by hurricanes.  When
   possible, only calls traversing overloaded servers should be
   throttled under those conditions.

I am not sure what the term 'legitimate' means here. I would rather say that 
the paragraph rather deals with increases in call volumes that happen at 
predictable moments in time (assuming here that the time a hurricane hits a 
certain geographic zone is predicted by weather forecasters). There would be 
one more example to add here - the end-of-season (of month, of year) peaks in 
phone orders.

There is another category of unpredicted/unpredictable events which is 
mentioned a few paragraphs later, and which puts a slightly different set of 
requirements. The list already includes earthquakes or terrorist attacks, it 
may add the increase in traffic on call centers that provide troubleshooting 
services when a mass service fails.

A slight re-organization of this text would improve clarity.


I have re-organized the contents a bit around the direction you suggested, 
please let me know if that solves the clarity issue.
[[DR]] The re-organized text in draft-11 looks fine.



2. In Section 4 - Design Requirements:

  o  The solution should draw upon experiences from related PSTN
  mechanisms where applicable.

I have no clue what this section means in the absence of a reference and/or a 
list of what PSTN mechanisms are to be considered.

The references have been added.


Also, in the same list of requirements I miss an explicit requirement on 
persistency.


This part I am not sure if I understand clearly, could you please elaborate a 
bit?

 [[DR]] In section 5.3, second paragraph there are a couple of references to 
the persistency of subscriptions of neighboring SIP entities and periodic 
refresh. Should not this be mentioned explicitly in the list in Section 4?


3. In Section 5.4 in the compliance list - I believe that compliance to the SIP 
Event Notification Framework [RFC 6665] should be added.


Added.


Thanks!

Charles

Nits/editorial comments:




___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt

[Romascanu, Dan (Dan)]

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-clue-telepresence-requirements-06.txt
Reviewer: Dan Romascanu
Review Date: 11/21/13
IETF LC End Date: 11/27/13
IESG Telechat date: (if known)

Summary: It's a good and well written document, almost ready, but a number of 
issues should be clarified before approval. 

Major issues:

1. The definitions of Left and Right in Section 3 use an entry article in 
Wikipedia ('Stage Directions'). I am both uncomfortable with the usage of 
Wikipedia articles (subject to change, subject to attacks) as references, and I 
also believe that the current definitions (@11/21/13, US morning hours) are 
ambiguous. Actually the Wikipedia article does not include definitions for Left 
and Right, and speaks about 'house left' (equal to 'stage right') and 'house 
right' (equal to 'stage left'). If another specification in CLUE will use the 
terms defined here it is not clear which one is meant. 

2. In REQMT-1d it is not clear what 'the extent of individual video captures' 
means

3. In REQMT-2d it is not clear what 'the extent of individual audio captures' 
means

4. REQMT-10: The solution MUST make it possible for endpoints without
  support for telepresence extensions to participate in a
  telepresence session with those that do.

More clarity is needed to explain what level of participation in a session (and 
what limitations) are expected from endpoints that do not support the 
telepresence extensions. I assume there are limitations, otherwise extensions 
would not be needed. 

5. REQMT-15 (last bullet): I could not really figure out what is meant here

*  There can be variation in placement, number and size of
 presentations

6. REQMT-16:  The solution MUST include extensibility mechanisms.

What 'extensibility' is meant here? Extending the telepresence sessions, or 
extending the specifications for new functionality in the future? 


Minor issues:

1. If this is the first and basic document to be read by somebody who starts to 
browse through the CLUE specifications, it would be good to define or expand 
some place in the introduction what CLUE is. 

2. In the Introduction Section I see: 

  These
   requirements are for the specification, they are not requirements on
   the telepresence systems implementing the solution/protocol that will
   be specified.

But then all requirements in section 5 start by 'The solution ...' which is 
ambiguous. It would be good to mention (again) in section 5 that by what is 
meant by the 'solution' is the definition of the protocol, not the 
implementation. 

3. I will defer to the Security Review to comment whether REQMT-18 is enough 
from a security point of view - especially as the information about media 
captures may include explicitly or implicitly details about equipment on each 
site, etc. To me it seems a little bit too vague. 

Regards,

Dan

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review for draft-ietf-soc-load-control-event-package-10.txt

[Romascanu, Dan (Dan)]

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-soc-load-control-event-package-10.txt
Reviewer: Dan Romascanu
Review Date: 11/19/13
IETF LC End Date: 11/19/13
IESG Telechat date: (if known)

Summary: The document is ready, there are a few minor issues which are worth 
being clarified. 

Major issues: None.

Minor issues:

1. I had some issues with the examples in the introduction. 

  There are three common examples of legitimate short-term increases in
   call volumes.  Viewer-voting TV shows or ticket giveaways may
   generate millions of calls within a few minutes.  Call volume may
   also spike during special holidays such as New Year's Day and
   Mother's Day. Finally, callers may want to reach friends and family
   in natural disaster areas such as those affected by hurricanes.  When
   possible, only calls traversing overloaded servers should be
   throttled under those conditions.

I am not sure what the term 'legitimate' means here. I would rather say that 
the paragraph rather deals with increases in call volumes that happen at 
predictable moments in time (assuming here that the time a hurricane hits a 
certain geographic zone is predicted by weather forecasters). There would be 
one more example to add here - the end-of-season (of month, of year) peaks in 
phone orders. 

There is another category of unpredicted/unpredictable events which is 
mentioned a few paragraphs later, and which puts a slightly different set of 
requirements. The list already includes earthquakes or terrorist attacks, it 
may add the increase in traffic on call centers that provide troubleshooting 
services when a mass service fails. 

A slight re-organization of this text would improve clarity. 

2. In Section 4 - Design Requirements: 

  o  The solution should draw upon experiences from related PSTN
  mechanisms where applicable.

I have no clue what this section means in the absence of a reference and/or a 
list of what PSTN mechanisms are to be considered. 

Also, in the same list of requirements I miss an explicit requirement on 
persistency. 

3. In Section 5.4 in the compliance list - I believe that compliance to the SIP 
Event Notification Framework [RFC 6665] should be added. 

Nits/editorial comments:




___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Telechat review for draft-ietf-6man-ext-transmit-04

[Romascanu, Dan (Dan)]

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 wait for direction from your document shepherd or AD before posting a 
new version of the draft.

Document: draft-ietf-6man-ext-transmit-04
Reviewer: Dan Romascanu
Review Date: 10/9/13
IETF LC End Date: 9/20/13
IESG Telechat date: 10/10/13

Summary: Ready. Thank you for addressing the concern expressed in the IETF LC 
review. 

Major issues:

Minor issues:

Nits/editorial comments:




___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART telechat review for draft-ietf-sipcore-rfc4244bis-11

[Romascanu, Dan (Dan)]

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 wait for direction from your document shepherd or AD before posting a 
new version of the draft.

Document: draft-ietf-sipcore-rfc4244bis-11
Reviewer: Dan Romascanu
Review Date: 10/9/13
IETF LC End Date: 9/20/12
IESG Telechat date: 10/10/13

Summary: Ready

Major issues:

Minor issues:

Nits/editorial comments:




___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART LC review of draft-ietf-p2psip-rpr-10

[Romascanu, Dan (Dan)]

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-p2psip-rpr-10
Reviewer: Dan Romascanu
Review Date: 9/30/13
IETF LC End Date: 9/30/13
IESG Telechat date: 

Summary: Ready with minor and editorial issues

Major issues:

Minor issues:

[I-D.ietf-p2psip-drr] is an Informational Reference. It is mentioned in several 
places, out of which at least one makes reading the referred document mandatory 
for anybody who intends to write an implementation of this document. This place 
is Section 7 which states: 

 This document uses the new RELOAD overlay configuration element,
   route-mode, inside each configuration element, as defined in DRR
   document [I-D.ietf-p2psip-drr].

Nits/editorial comments:

1. Section 3.1 RPR includes just one sub-section 3.1.1 with a similar title. It 
looks like the division of the text in a subsection is not needed. 

2. The title of Section 3.2 is 'Scenarios where RPR can be beneficial'. In fact 
only 3.2.3 describes such a scenario, while 3.2.1 and 3.2.2 describe cases 
which would ease deployment of RPR (managed environments, bootstrap nodes). In 
other words 3.2.1 and 3.2.2 describe cases when RPR could be deployed and 3.2.3 
a case when RPR should be deployed. 

3. In Section 6.2.2: 

 The option value is illustrated in the following figure, defining the
   ExtensiveRoutingModeOption structure:

However no figure follows. 



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART LC review of draft-ietf-p2psip-rpr-10

[Romascanu, Dan (Dan)]

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-p2psip-rpr-10
Reviewer: Dan Romascanu
Review Date: 9/30/13
IETF LC End Date: 9/30/13
IESG Telechat date: 

Summary: Ready with minor and editorial issues

Major issues:

Minor issues:

[I-D.ietf-p2psip-drr] is an Informational Reference. It is mentioned in several 
places, out of which at least one makes reading the referred document mandatory 
for anybody who intends to write an implementation of this document. This place 
is Section 7 which states: 

 This document uses the new RELOAD overlay configuration element,
   route-mode, inside each configuration element, as defined in DRR
   document [I-D.ietf-p2psip-drr].

Nits/editorial comments:

1. Section 3.1 RPR includes just one sub-section 3.1.1 with a similar title. It 
looks like the division of the text in a subsection is not needed. 

2. The title of Section 3.2 is 'Scenarios where RPR can be beneficial'. In fact 
only 3.2.3 describes such a scenario, while 3.2.1 and 3.2.2 describe cases 
which would ease deployment of RPR (managed environments, bootstrap nodes). In 
other words 3.2.1 and 3.2.2 describe cases when RPR could be deployed and 3.2.3 
a case when RPR should be deployed. 

3. In Section 6.2.2: 

 The option value is illustrated in the following figure, defining the
   ExtensiveRoutingModeOption structure:

However no figure follows. 



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review for draft-ietf-dhc-dhcpv6-solmaxrt-update-05 (second review - for IESG telechat)

[Romascanu, Dan (Dan)]

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 wait for direction from your document shepherd or AD before posting a 
new version of the draft.

Document: draft-ietf-dhc-dhcpv6-solmaxrt-update-05
Reviewer: Dan Romascanu
Review Date: 9/22/13
IETF LC End Date: 9/3/13
IESG Telechat date: 9/26/13

Summary: This document is ready. 

The two issues raised in my review on draft-ietf-dhc-dhcpv6-solmaxrt-update-03 
were addressed - one by accepting the proposed edit, the second by text in the 
proposed rechartering of the WG

Major issues:

Minor issues:

Nits/editorial comments:



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review for draft-ietf-6man-ext-transmit-03

[Romascanu, Dan (Dan)]

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-ext-transmit-03
Reviewer: Dan Romascanu
Review Date: 9/19/2013
IETF LC End Date: 9/20/2013
IESG Telechat date: (if known)

Summary:

Ready (with one minor issue for clarification)

The document is very well written, clearly justified, and the actions required 
from IANA are described in details together with their rationale. 

Major issues:

Minor issues:

I have only one procedural issue, which should be evaluated IMO by the IESG but 
should not prevent the document to be approved. Runing id-nits flags a downref 
because of a normative reference to RFC 5201 (experimental). I see that this 
was also mentioned in the shepherd submission. However the downref was not 
mentioned in the IETF LC. 

Note that I would be fine also with moving this reference to an Informational 
Reference as it only provides a pointer for one of the initial values in the 
Extension Header Types registry


Nits/editorial comments:




___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Review for draft-ietf-storm-iscsimib-04

[Romascanu, Dan (Dan)]

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 wait for direction from your document shepherd or AD before posting a 
new version of the draft.

Document: draft-ietf-storm-iscsimib-04.txt
Reviewer: Dan Romascanu
Review Date: 8/25/13
IETF LC End Date: 1/28/13
IESG Telechat date: 8/29/13

Summary: Ready - All issues raised in the IETF LC review were addressed. Thanks 
to the authors for the responsiveness and cooperation. 

Major issues:

Minor issues:

Nits/editorial comments:

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Review for draft-ietf-storm-iscsimib-04

[Romascanu, Dan (Dan)]

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 wait for direction from your document shepherd or AD before posting a 
new version of the draft.

Document: draft-ietf-storm-iscsimib-04.txt
Reviewer: Dan Romascanu
Review Date: 8/25/13
IETF LC End Date: 1/28/13
IESG Telechat date: 8/29/13

Summary: Ready - All issues raised in the IETF LC review were addressed. Thanks 
to the authors for the responsiveness and cooperation. 

Major issues:

Minor issues:

Nits/editorial comments:

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-ietf-dhc-dhcpv6-solmaxrt-update-03

[Romascanu, Dan (Dan)]

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-dhcpv6-solmaxrt-update-03
Reviewer: Dan Romascanu
Review Date: 8/25/13
IETF LC End Date: 9/3/13
IESG Telechat date: (if known)

Summary: Ready with minor issues

Major issues: None

Minor issues:

1. My understanding is that although the default values of SOL_MAX_RT and 
INF_MAX_RT were the same in RFC 3315, and now they are change to similar 
values, there is no mandatory behavior defined for servers to set them at the 
same values using the new override options. If this is the case then the 
Abstract should say 

OLD: 

... override the client's default value for SOL_MAX_RT
   and INF_MAX_RT with a new value.

NEW: 

... override the client's default value for SOL_MAX_RT
   and INF_MAX_RT with new values.

If I am wrong, and the values of the two parameters are always identical at 
defalult or after changes, then something needs to be said on this respect in 
Section 8 (DHCPv6 Server Behavior)

2. This is not a document problem but a WG management issue. I could not find 
anything in the dhc WG charter that corresponds to this document, so I cannot 
say whether this document meets the conditions of the 'contract with the IESG'. 
Actually the charter seems not to have been updated for five years, if not 
more. I guess that with Ralph as an author all is OK, but an update of the 
charter seems to be needed. 
 

Nits/editorial comments:

Section 7: 

OLD:

   a DHCPv6 client MUST silently ignore any SOL_MAX_RT or INF_MAX_RT
   values that are less than 60 or more than 86400.


New:

   A DHCPv6 client MUST silently ignore any SOL_MAX_RT or INF_MAX_RT
   values that are less than 60 or more than 86400.


Regards,

Dan

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art