[Gen-art] Gen-ART Early review of draft-brownlee-svg-rfc-07

[Suresh Krishnan]

I am the assigned Gen-ART reviewer for draft-brownlee-svg-rfc-07

For background on Gen-ART, please see the FAQ at
.

 

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

 

Summary: This draft is on track to be published as an Informational RFC,
but I have some suggestions that the authors may like to consider.


* Meta comment


It is not clear how the SVGs will be included in the RFCs? Will they be
included as inline XML? Can you please clarify.


* Section 1


Last paragraph: It is not really true that diagrams in RFCs are not
normative. e.g. The ordering of fields in a packet is specified by a
packet format diagram and the text only describes the contents of the
fields (and not necessarily the structure of the packet itself). Is this
paragraph necessary?


* Section 4


Shouldn't we also be discussing the "role" attribute in the
accessibility context?


I also found that the Web Accessibility Initiative's ARIA primer to be a
good introduction in addition to the SVG-ARIA reference.
http://www.w3.org/TR/wai-aria-primer/


* Sections 5.2 and 5.3


The meta language used in these sections (especially 5.3) is a bit
confusing. Is the goal of such languages to also go into the
presentation details as they do now? I think it would be more
illustrative if the example languages are made a bit simpler. e.g. I use
the mscgen program a lot in my day job and the language used by mscgen
is a bit simpler and illustrates the message sequence more clearly.


http://www.mcternan.me.uk/mscgen/


Thanks

Suresh


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

Re: [Gen-art] Gen-ART LC Review of draft-ietf-forces-model-extension-03

[Ben Campbell]

On Aug 20, 2014, at 5:00 PM, Haleplidis Evangelos  wrote:

> 
> [ΕΗ] I discussed with Joel with regards to the copyright issues.
> The short answer is that this document draws directly from RFC5812 and
> relies on RFC5812 for such issues (as it uses the same boilerplate).
> 
> Is this satisfactory?
> 

Hrmm. So it does. I somehow had it in my head it had the older boilerplate. I 
must have gotten that from one of the draft versions So, never mind :-)

(It's interesting that IDNits apparently looked at the date of publication of 
the first 00 draft, not the RFC. I'm curious the history of what happened with 
RFCs that were in-process works and had changes in authorship at the time 5378 
was published--but that's not this draft's problem and should probably happen 
in a bar discussion.)

[...]

>> 
>> In this particular case, it's not clear to me if the MUST actually
>> constrains a choice vs being a statement of fact. If you believe it to
>> be the former then I am okay with it. The rewording might help.
>> 
> 
> [ΕΗ] I reworded it and provided also an example. The text now reads:
> 
> "When optional access type for components within a struct are defined, these
> components's access type MUST override the access type of the struct. For
> example if a struct has an access type of read-write but has a component
> that is a read-only counter, the counter's access type MUST be read-only."
> 
> I believe that it is an implementation constraint as there are two
> possibilities (override or not). With the "MUST" we constrain it to one
> (override).
> 
> I also changed the two "it MUST be ignored" to "the access type MUST be
> ignored" to better specify what "it" is.
> 

This helps. 

For the record, my suggestion on more active voice was to say what must do the 
ignoring. But I think what you've got is good enough.

[...]


>> 
>> No, I am not one.  Hopefully this will get a SecDir review as well. But
>> that sort of review usually goes better if the Security Consideration
>> section shows your reasoning, along the lines of listing the high-level
>> types of changes, and for each, why it has no new security impact. Your
>> response contains more of that sort of thing; it might help to add it
>> (or parts of it) to the draft.
>> 
>> I was a bit concerned that the default version for inheritance could be
>> an issue, but you addressed that elsewhere.
>> 
>> [...]=
> 
> [ΕΗ] Ok, added part of this. Now the security considerations read the
> following:
> 
> This document adds only a few constructs to the initial model defined in
> RFC5812, namely namely a new event, some new properties and a way to define
> optional access types and complex metadata. These constructs do not change
> the nature of the the initial model. In addition this document addresses and
> clarifies an issue with the inheritance model by introducing the version of
> the derivedFrom LFB class.
> Thus the security considerations defined in RFC5812 applies to this document
> as well as the changes proposed here are simply constructs to write XML
> library definitions, as where in RFC5812 and have no effect on security
> semantics with the protocol.
> 

You might consider adding something to say that the inheritance model change 
also does not change the security considerations. (Maybe it makes things 
better, by removing the potential for choosing a wrong parent class? Not sure 
if that's a security issue, unless there was some kind of parent-assertion 
attack.)

 It does seem like the inheritance change is a bona-fide extension, not just a 
clarification, since you added the version attribute.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC Review of draft-ietf-forces-model-extension-03

[Haleplidis Evangelos]

Greetings Ben,

Thank you for your response. Please see inline.

Regards,
Evangelos Haleplidis.

> From: Ben Campbell [mailto:b...@nostrum.com]
> 
> Hi, thanks for the response. Comments inline. I've removed sections
> that don't seem to need further comment.

[ΕΗ] Same here! :)

> >> -- IDNits points out that this draft may need the pre-RFC5378
> >> boilerplate, due to content from RFC 5812. It does appear to include
> >> substantial amounts of XML schema from 5812. While the publication
> >> date of 5812 post-dates RFC5378, there were many revisions of the
> >> draft form that pre-date 5378 by some time. So unless the author has
> >> gotten permission from all 5812 authors (and I note that author list
> >> changed several times prior to publication), this draft and any
> >> resulting RFC may well need the boilerplate.
> >>
> >
> > [ΕΗ] Thank you for catching this as I have very little experience
> with
> > this kind of issues.
> > As I have not asked permission from the RFC5812 authors, what should
> > be the proper way to resolve this issue?
> > Ask for permission or use a previous boilerplate?
> 
> Asking permission is the best choice, because it would allow you to
> publish this one with the "fully complies" boilerplate. That has the
> advantage of allowing any future IETF works incorporate content from it
> without having the same issue.
> 
> But that may be a tricky thing to do. I note that the drafts leading up
> to the publication of RFC5812 rotate through a number of authors at
> different times. It may be a bit tricky to figure out the proper list
> of authors to ask permission from. Therefore I would not object if you
> went with the pre-5378 boilerplate. Details are in section 6.d.iii. of
> http://trustee.ietf.org/license-info/IETF-TLP-4.htm .
>   
> If you are using xml2rfc, the tool can insert the boilerplate for you.
> For details, see http://xml2rfc.ietf.org and scroll down to the light-
> green box that talks about the IETF Trust Legal Provisions boilerplate.
> 

[ΕΗ] I discussed with Joel with regards to the copyright issues.
The short answer is that this document draws directly from RFC5812 and
relies on RFC5812 for such issues (as it uses the same boilerplate).

Is this satisfactory?

> 
> >
> >> Minor issues:
> >>
> >> -- section 2.3, 3rd paragraph:
> >>
> >> The 2119 language in this paragraph seems more like description of
> >> procedures. You really only need 2119 language when you want to
> >> constrain some choice an implementor might make. Also, in the two
> >> cases of "MUST be ignored", please consider using active voice?
> (That
> >> is, who or what must ignore it?)
> >>
> >
> > [ΕΗ] In this specific case (I will reword it) the MUST is a
> constraint
> > that the implementer has to conform for interoperability. Otherwise
> > the model would mean something different from one implementer to the
> > other, e.g. for A's implementation the struct's component may have an
> > access type of "read-write" but for B it may mean "read-only". The
> > MUST there defines that when you define a struct component's access
> > type, it MUST override the whole struct's access type.
> 
> In this particular case, it's not clear to me if the MUST actually
> constrains a choice vs being a statement of fact. If you believe it to
> be the former then I am okay with it. The rewording might help.
> 

[ΕΗ] I reworded it and provided also an example. The text now reads:

"When optional access type for components within a struct are defined, these
components's access type MUST override the access type of the struct. For
example if a struct has an access type of read-write but has a component
that is a read-only counter, the counter's access type MUST be read-only."

I believe that it is an implementation constraint as there are two
possibilities (override or not). With the "MUST" we constrain it to one
(override).

I also changed the two "it MUST be ignored" to "the access type MUST be
ignored" to better specify what "it" is.

> >
> >> -- section 2.4, 2nd paragraph:
> >>
> >> This also seems like a description of general procedures that
> doesn't
> >> really need 2119 language.
> >
> > [ΕΗ] Again I think that the MUST is something that is needed for
> > interoperability issues. The BecomesEqualTo MUST generate only one
> > event when the component reaches that specific value and not while it
> is there.
> >
> >>
> >> -- section 2.4, bulleted paragraph:
> >>
> >> Is this similar to saying that eventBecomesEqualTo effectively
> >> becomes an eventChanged after achieving the target value? Once the
> >> value changes from the target by V or more, does it reset the
> >> becomesEqualTo trigger?
> >>
> >
> > [ΕΗ] No, it does not effectively become an eventChanged. The
> > difference is that it will only be triggered ONCE when the value is
> > changed and not continuously.
> 
> You might consider something like:
> 
> " The event is triggered only when the value of the targeted component
> becomes equal to the

Re: [Gen-art] Gen-ART Last Call review draft-ietf-tcpm-fastopen-09

[Scharf, Michael (Michael)]

As document shepherd, I agree.

A small addon: I think that the suggested text for -10 sent around as response 
to Barry Leiba's review would be OK.

I have just compared it to the GenArt review. At first sight, the following nit 
is not addressed:

  [Page 7], 'Fast Open Cookie Option', it would be more familiar to IETF 
community to call "Kind" field "Type", unless there was a reason for this 
differentiation

However, not changing the text in this case seems fine to me, given that the 
term "kind" is used on 
http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml.

In addition, some acronyms may indeed not be expanded on first use, but I think 
the RFC editor will fix this anyway.

Michael


> -Original Message-
> From: Martin Stiemerling [mailto:mls.i...@gmail.com]
> Sent: Wednesday, August 20, 2014 7:14 PM
> To: Jari Arkko; Yuchung Cheng
> Cc: meral.shirazip...@ericsson.com; gen-art@ietf.org; draft-ietf-tcpm-
> fastopen@tools.ietf.org
> Subject: Re: [Gen-art] Gen-ART Last Call review draft-ietf-tcpm-
> fastopen-09
> 
> I would suggest to wait with any updated version until Friday, 8/22.
> Many IESG members are still reading the -09 version and it is usually
> confusing, if there is an updated draft in the meantime.
> 
> Thanks,
> 
>Martin
> 
> Am 20.08.14 um 13:12 schrieb Jari Arkko:
> > Thanks for the review & suggested edits. Is there a new draft version
> forthcoming?
> >
> > Jari
> >
> > On 29 Jul 2014, at 20:22, Yuchung Cheng  wrote:
> >
> >>
> >>
> >>
> >> On Wed, Jul 23, 2014 at 9:06 AM, Meral Shirazipour
>  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-tcpm-fastopen-09
> >>>
> >>> Reviewer: Meral Shirazipour
> >>>
> >>> Review Date: 2014-07-23
> >>>
> >>> IETF LC End Date:   2014-07-23
> >>>
> >>> IESG Telechat date: NA
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Summary:
> >>>
> >>> This draft is ready to be published as Experimental RFC, but I have
> some comments.
> >>>
> >>>
> >>>
> >>> Nits/editorial comments:
> >>>
> >>> -Abstract says "thus saving up to one full round trip time (RTT)":
> by just reading the abstract one would think 1.5 RTT since initial 3WHS
> is avoided.
> >>>
> >>> Reading the rest of the draft clarifies this though. Suggestion :
> >>>
> >>>
> >>>
> >>> "
> >>>
> >>> TFO allows data to be carried in the SYN and SYN-ACK packets
> >>>
> >>> and consumed by the receiving end during 'an' initial
> connection
> >>>
> >>> handshake, 'and' saves up to one full round trip time (RTT)
> compared
> >>>
> >>> to the standard TCP, ..
> >>>
> >>> "
> >>
> >> Sounds good except it's "the" initial connection.
> >>
> >>>
> >>>
> >>>
> >>> -[page 4] "MSL", to spell out at first use "maximum segment
> lifetime" (or please consider mentioning reference to key TCP RFCs in
> Terminology section).
> >> ok
> >>>
> >>>
> >>>
> >>> -General: Also few other acronyms used without spelling out at
> first use, please consider those as well.
> >>>
> >>>
> >>>
> >>> -[Page 7], 'Fast Open Cookie Option', it would be more familiar to
> IETF community to call "Kind" field "Type", unless there was a reason
> for this differentiation.
> >>
> >> OK
> >>
> >>>
> >>> -[Page 10] please remove extra space (page break) if not needed.
> >>>
> >>>
> >>>
> >>> -[Page 12], typo "connection-sharding"--->"connection-sharing"
> >>>
> >>>
> >>>
> >>> -[page 14] "as a application"--->"as an application"
> >>>
> >>>
> >>>
> >>> -[Page 17], typo "Neverthless"--->"Nevertheless"
> >>>
> >>>
> >>>
> >>> -[Page 18], typo "meet the the">"meet the"
> >>>
> >>>
> >>>
> >>> -[Page 21], typo "in Section Section 4.1.1">"in Section 4.1.1"
> >>>
> >>>
> >>>
> >>> -[Page 21] please remove extra space (page break) if not needed.
> >>>
> >>>
> >> OK except it is the connection-sharding, not connection sharing. The
> two are opposite. To avoid confusion, I would rephrase to "If
> experiments with TFO find that it encourages applications to use more
> parallel connections, cookie-in-FIN may  prove to be a useful
> alternative"?
> >>
> >> I'd upload a new version soon. Thanks for the review.
> >>
> >>>
> >>> Best Regards,
> >>>
> >>> Meral
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ---
> >>>
> >>> Meral Shirazipour
> >>>
> >>> Ericsson
> >>>
> >>> Research
> >>>
> >>> www.ericsson.com
> >> ___
> >> 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 Last Call review draft-ietf-tcpm-fastopen-09

[Martin Stiemerling]

I would suggest to wait with any updated version until Friday, 8/22. 
Many IESG members are still reading the -09 version and it is usually 
confusing, if there is an updated draft in the meantime.


Thanks,

  Martin

Am 20.08.14 um 13:12 schrieb Jari Arkko:

Thanks for the review & suggested edits. Is there a new draft version 
forthcoming?

Jari

On 29 Jul 2014, at 20:22, Yuchung Cheng  wrote:





On Wed, Jul 23, 2014 at 9:06 AM, Meral Shirazipour 
 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-tcpm-fastopen-09

Reviewer: Meral Shirazipour

Review Date: 2014-07-23

IETF LC End Date:   2014-07-23

IESG Telechat date: NA





Summary:

This draft is ready to be published as Experimental RFC, but I have some 
comments.



Nits/editorial comments:

-Abstract says "thus saving up to one full round trip time (RTT)": by just 
reading the abstract one would think 1.5 RTT since initial 3WHS is avoided.

Reading the rest of the draft clarifies this though. Suggestion :



"

TFO allows data to be carried in the SYN and SYN-ACK packets

and consumed by the receiving end during 'an' initial connection

handshake, 'and' saves up to one full round trip time (RTT) compared

to the standard TCP, ..

"


Sounds good except it's "the" initial connection.





-[page 4] "MSL", to spell out at first use "maximum segment lifetime" (or 
please consider mentioning reference to key TCP RFCs in Terminology section).

ok




-General: Also few other acronyms used without spelling out at first use, 
please consider those as well.



-[Page 7], 'Fast Open Cookie Option', it would be more familiar to IETF community to call 
"Kind" field "Type", unless there was a reason for this differentiation.


OK



-[Page 10] please remove extra space (page break) if not needed.



-[Page 12], typo "connection-sharding"--->"connection-sharing"



-[page 14] "as a application"--->"as an application"



-[Page 17], typo "Neverthless"--->"Nevertheless"



-[Page 18], typo "meet the the">"meet the"



-[Page 21], typo "in Section Section 4.1.1">"in Section 4.1.1"



-[Page 21] please remove extra space (page break) if not needed.



OK except it is the connection-sharding, not connection sharing. The two are opposite. To 
avoid confusion, I would rephrase to "If experiments with TFO find that it 
encourages applications to use more parallel connections, cookie-in-FIN may  prove to be 
a useful alternative"?

I'd upload a new version soon. Thanks for the review.



Best Regards,

Meral





---

Meral Shirazipour

Ericsson

Research

www.ericsson.com

___
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

[Gen-art] Gen-art LC review of draft-ietf-ippm-lmap-path-05

[Elwyn Davies]

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

.

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

Document: draft-ietf-ippm-lmap-path-05.txt
Reviewer: Elwyn Davies
Review Date: 20 August 2014
IETF LC End Date: 22 August 2014
IESG Telechat date: (if known) -

Summary:
Almost ready for the IESG with a few minor nits.

Major issues:
None

Minor issues:
None

Nits/editorial comments:
s1, para 2:

   This topic has been previously developed in section 5.1 of [RFC3432],
   and as part of the updated framework for composition and aggregation,
   section 4 of [RFC5835] (which may also figure in the LMAP work

^^^

   effort).

 ^^^
The bracketed phrase sounds as if it is a comment on work in progress: 
I think it needs a different version for the long term when this becomes 
an RFC - either (if this is to do with the development of this 
specification) it did or didn't figure - but it could be something that 
is relevant to implementation/usage of the specification - I can't tell 
(yet? or indeed after reading the full draft) - in which case it needs 
rephrasing appropriately.


s3.1:

A reference path is a serial combination of ... links, ...
A piece of extreme pedantry probably:  How would this apply to ECMP or 
Multi-Link Trunking connections where there is some parallelism in the link?


s3.3/s3.4 et seq:  Would it be better to use Dedicated Component and 
Shared Component (rather than ...ed component) to make it clear that the 
combination is the defined term?  Capitalization of these and other 
terms (Managed/Un-managed) etc should be consistent throughout.


s3.4/s4: I think Service Demarcation (Point) could be usefully treated 
as another piece of terminology definition and the current text in s4 
moved to s3 - and placed before s3.4 so that s3.4 then refers to the 
previous definition.


s4: Expand acronyms on first use please: "LTE UE" (in Service 
Demarcation) and "GRA GW" [The last two are currently  expanded in the 
caption of Figure 1 in s5].


s5, items 2C and 2D: s/from point/from the point/

s5, Notes, first bullet: s/Some use the terminology "on-net" and 
"off-net"/The terminology "on-net" and "off-net" is sometimes used/


s5, Notes, fourth bullet:

  the remote end of the connecting link is an equivalent point
  for some methods of measurement (To Be Specified Elsewhere).


Does the 'To Be Specified Elsewhere' mean that something has not yet 
been done that was intended to be done?  Maybe the RFC 5835 comment???


s5, Notes, last bullet: s/The GW of first transit/The GW of the first 
transit/


s7, bullet #1: s/The CPE is/The CPE consists of a/



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

Re: [Gen-art] Gen-ART Last Call review draft-ietf-tcpm-fastopen-09

[Jari Arkko]

Thanks for the review & suggested edits. Is there a new draft version 
forthcoming?

Jari

On 29 Jul 2014, at 20:22, Yuchung Cheng  wrote:

> 
> 
> 
> On Wed, Jul 23, 2014 at 9:06 AM, Meral Shirazipour 
>  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-tcpm-fastopen-09
> >
> > Reviewer: Meral Shirazipour
> >
> > Review Date: 2014-07-23
> >
> > IETF LC End Date:   2014-07-23
> >
> > IESG Telechat date: NA
> >
> >
> >
> >
> >
> > Summary:
> >
> > This draft is ready to be published as Experimental RFC, but I have some 
> > comments.
> >
> >
> >
> > Nits/editorial comments:
> >
> > -Abstract says "thus saving up to one full round trip time (RTT)": by just 
> > reading the abstract one would think 1.5 RTT since initial 3WHS is avoided.
> >
> > Reading the rest of the draft clarifies this though. Suggestion :
> >
> >
> >
> > "
> >
> > TFO allows data to be carried in the SYN and SYN-ACK packets
> >
> >and consumed by the receiving end during 'an' initial connection
> >
> >handshake, 'and' saves up to one full round trip time (RTT) compared
> >
> >to the standard TCP, ..
> >
> > "
> 
> Sounds good except it's "the" initial connection.
> 
> >
> >
> >
> > -[page 4] "MSL", to spell out at first use "maximum segment lifetime" (or 
> > please consider mentioning reference to key TCP RFCs in Terminology 
> > section).
> ok
> >
> >
> >
> > -General: Also few other acronyms used without spelling out at first use, 
> > please consider those as well.
> >
> >
> >
> > -[Page 7], 'Fast Open Cookie Option', it would be more familiar to IETF 
> > community to call "Kind" field "Type", unless there was a reason for this 
> > differentiation.
> 
> OK
> 
> >
> > -[Page 10] please remove extra space (page break) if not needed.
> >
> >
> >
> > -[Page 12], typo "connection-sharding"--->"connection-sharing"
> >
> >
> >
> > -[page 14] "as a application"--->"as an application"
> >
> >
> >
> > -[Page 17], typo "Neverthless"--->"Nevertheless"
> >
> >
> >
> > -[Page 18], typo "meet the the">"meet the"
> >
> >
> >
> > -[Page 21], typo "in Section Section 4.1.1">"in Section 4.1.1"
> >
> >
> >
> > -[Page 21] please remove extra space (page break) if not needed.
> >
> >
> OK except it is the connection-sharding, not connection sharing. The two are 
> opposite. To avoid confusion, I would rephrase to "If experiments with TFO 
> find that it encourages applications to use more parallel connections, 
> cookie-in-FIN may  prove to be a useful alternative"?
> 
> I'd upload a new version soon. Thanks for the review.
> 
> >
> > Best Regards,
> >
> > Meral
> >
> >
> >
> >
> >
> > ---
> >
> > Meral Shirazipour
> >
> > Ericsson
> >
> > Research
> >
> > www.ericsson.com
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last review Call draft-ietf-core-observe-14

[Jari Arkko]

Thanks for your review, Meral. I have also read this document, and fully 
support its publication as an RFC. Thanks for the hard work, all!

Jari

On 08 Aug 2014, at 19:55, Meral Shirazipour  
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-core-observe-14
> Reviewer: Meral Shirazipour
> Review Date: 2014-08-08
> IETF LC End Date:   2014-08-08
> IESG Telechat date: NA
>  
>  
> Summary:
> This draft is ready to be published as Standard RFC.
>  
> Nits/editorial comments:
> -[Page 12], "entry with with"--typo-->"entry with"
> -[Page 13], "when the the age"--typo-->"when the age"
>  
>  
> Best Regards,
> Meral
> ---
> Meral Shirazipour
> Ericsson
> Research
> www.ericsson.com
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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-tictoc-security-requirements

[Jari Arkko]

Thanks for the reviews and updates, Dan et al. These reviews are important for 
me to understand which documents I need to look at closer, and in reducing my 
review load. Not to mention improving the quality of IETF RFCs :-)

Jari

On 21 Jul 2014, at 18:11, Romascanu, Dan (Dan)  wrote:

> Looks good.
>  
> Thanks,
>  
> Dan
>  
>  
> From: Tal Mizrahi [mailto:ta...@marvell.com] 
> Sent: Monday, July 21, 2014 8:01 AM
> To: Romascanu, Dan (Dan); gen-art@ietf.org; Karen ODonoghue 
> (odonog...@isoc.org); Yaakov Stein (yaako...@rad.com); Brian Haberman 
> (br...@innovationslab.net)
> Cc: draft-ietf-tictoc-security-requirements@tools.ietf.org
> Subject: RE: Gen-ART review for draft-ietf-tictoc-security-requirements
>  
> Thanks Dan,
>  
> The updated draft has been posted:
> http://datatracker.ietf.org/doc/draft-ietf-tictoc-security-requirements/
>  
> Regards,
> Tal.
>  
> From: Romascanu, Dan (Dan) [mailto:droma...@avaya.com] 
> Sent: Sunday, July 20, 2014 4:51 PM
> To: Tal Mizrahi; gen-art@ietf.org; Karen ODonoghue (odonog...@isoc.org); 
> Yaakov Stein (yaako...@rad.com); Brian Haberman (br...@innovationslab.net)
> Cc: draft-ietf-tictoc-security-requirements@tools.ietf.org
> Subject: RE: Gen-ART review for draft-ietf-tictoc-security-requirements
>  
> Hi Tal,
>  
> Thanks for addressing my comments. I can live with the two references being 
> Informational.
>  
> Regards,
>  
> Dan
>  
>  
> From: Tal Mizrahi [mailto:ta...@marvell.com] 
> Sent: Sunday, July 20, 2014 10:03 AM
> To: Romascanu, Dan (Dan); gen-art@ietf.org; Karen ODonoghue 
> (odonog...@isoc.org); Yaakov Stein (yaako...@rad.com); Brian Haberman 
> (br...@innovationslab.net)
> Cc: draft-ietf-tictoc-security-requirements@tools.ietf.org
> Subject: RE: Gen-ART review for draft-ietf-tictoc-security-requirements
>  
> Hi Dan,
>  
> Thanks for the comments.
> I have updated the draft based on the comments below, and will post an 
> updated version tomorrow, once the I-D submission tool is reopened.
>  
> One small comment:
>  
> > 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.
>  
> We had a bit of discussion about this question recently. Normative references 
> specify documents that must be read to understand or implement the technology 
> in the new RFC. Brian and Karen observed that this document could be 
> understood even without reading NTPv4 or IEEE 1588; for example, a reader who 
> is interested in a completely new time protocol can benefit from this 
> document without having to read NTPv4 and IEEE 1588. Therefore these 
> documents are listed under the informative reference list.
>  
> Thanks,
> Tal.
>  
> From: Romascanu, Dan (Dan) [mailto:droma...@avaya.com] 
> Sent: Monday, July 14, 2014 6:00 PM
> To: gen-art@ietf.org
> Cc: draft-ietf-tictoc-security-requirements@tools.ietf.org
> Subject: Gen-ART review for draft-ietf-tictoc-security-requirements
>  
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
> please see the FAQ at
>  
> .
>  
> 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.

Re: [Gen-art] review: draft-ietf-appsawg-json-merge-patch-06

[Jari Arkko]

Thanks for your review, Joel.

On 01 Aug 2014, at 19:31, Joel M. Halpern  wrote:

> Ignore my minor comment.  I re-read the pseudo-code and realized what was 
> going on.  No problem at all.  It is indeed ready to publish.
> 
> Yours,
> Joel
> 
> On 8/1/14, 12:28 PM, Joel M. Halpern wrote:
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at
>> 
>> .
>> 
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>> 
>> Document: draft-ietf-appsawg-json-merge-patch-06
>> JSON Merge Patch
>> Reviewer: Joel M. Halpern
>> Review Date: 1-Aug-2014
>> IETF LC End Date: 8-Aug-2014
>> IESG Telechat date: 21-Aug-2014
>> 
>> Summary: This document is ready for publication as a Proposed Standard
>> 
>> Major issues:
>> 
>> Minor issues:
>> I will check separately with the authors about one confusion regard
>> when something is an object, the pseudo-code, and the next to last
>> example in the appendix.
>> 
>> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] LC review of draft-ietf-l3vpn-pmsi-registry-03.txt

[Jari Arkko]

Thanks for your review, Alexey!

Jari

On 03 Aug 2014, at 21:14, Alexey Melnikov  wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> 
> .
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-l3vpn-pmsi-registry-03
> Reviewer: Alexey Melnikov
> Review Date: 3-Aug-2014
> IETF LC End Date: 9-Aug-2014
> IESG Telechat date: N/A
> 
> Summary: This document is ready for publication as a Proposed Standard
> 
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC review of draft-ietf-opsec-lla-only-07

[Jari Arkko]

Hi,

I’m wondering which of the below issues have been corrected in the most recent 
version of the draft. Have the authors seen the review? Some of the comments at 
least have been taken into account, so the answer is probably yes.

But I do not see e-mails from the authors on this topic in my Inbox, so I want 
to check.

Jari

On 08 Apr 2014, at 09:58, Peter Yee  wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> 
> 
> Please resolve these comments along with any other Last Call comments you
> may receive.
> 
> Document: draft-ietf-opsec-lla-only-07
> Reviewer: Peter Yee
> Review Date: April-7-2014
> IETF LC End Date: April-7-2014
> IESG Telechat date: TBD
> 
> Summary: This draft is basically ready for publication as an Informational
> RFC, but has issues that should be fixed before publication. [Ready with
> issues.]
> 
> This document discusses the (controversial) use of IPv6 link-local addresses
> on router infrastructure links.  I don't find all of the arguments for use
> of link-local addresses to be terribly compelling, but I'm not utterly
> averse to the document's publication as a summary of some of the pros and
> cons for those who desire to configure their routers in the manner
> prescribed.  There may be other reasons that should be taken into
> consideration, but I lack a network operator's experience to discuss them.
> 
> Minor:
> 
> Page 4, 4th paragraph: I don't buy this argument.  DNS can be simplified for
> non-link-local addresses by simply not registering those addresses in DNS.
> Use of link-local addresses isn't a requirement to simplify DNS.
> 
> Page 4, 5th paragraph, 2nd sentence: SSH brute force password attacks aren't
> really reduced unless the reduction is simply not being able to attack a
> single router over multiple interfaces in parallel.  A better scheme for
> reducing SSH brute force password attacks might be to limit the rate of
> responses to SSH login attempts in the face of repeated failures.
> Considering dropping this marginal example.
> 
> Page 4, 6th paragraph, 1st sentence: I'm not sure what is meant by "the same
> result".  Is this in reference to all 5 paragraphs that precede the 6th?  If
> so, you might wish to elaborate with "the same results as the above" .
> However, if the same results can be obtained without going to link-local
> addressing as this paragraph indicates, why is the use of link-local
> addressing being suggested?  The paragraph might do well to explain why one
> scheme is preferable over the other.
> 
> Page 6, 1st partial paragraph: the argument is made that "more work" is
> required to discover all of an IXPs loopback interface addresses before a
> generic attack can be mounted.  This wouldn't seem to be a lot of upfront
> work and once it has been done, the advantage is negated.  I don't find the
> argument particularly persuasive.  
> 
> Nits:
> 
> Page 2, Section 2 title: change "Address" to "Addressing".
> 
> Page 3, second paragraph: change "non link-local" to "non-link-local".
> 
> Page 4, 1st paragraph, 3rd sentence: change "accellerated" to "
> accelerated".
> 
> Page 4, 5th paragraph, 2nd sentence: delete the comma after "[RFC4987])" and
> change the "or" to "and".
> 
> Page 6, 1st full paragraph, 1st sentence: change "allow" to "allows" and
> insert "an" before "MPLS LSP".
> 
> 
>   -Peter Yee
> 
> 
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC review of draft-ietf-dnsop-as112-dname-04

[Jari Arkko]

Thank you for your review, Roni.

Jari

On 25 Jul 2014, at 18:01, Roni Even  wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
> please see the FAQ at 
> .
> 
> Please resolve these comments along with any other Last Call comments you may 
> receive.
> 
> Document:  draft-ietf-dnsop-as112-dname-04
> Reviewer: Roni Even
> Review Date:2014–7-25
> IETF LC End Date: 2014–7-29
> IESG Telechat date:
>  
> Summary: This draft is ready for publication as an Informational RFC.
>  
>  
> Major issues:
>  
> Minor issues:
>  
>  
> Nits/editorial comments:
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Last Call review of draft-ietf-dnsop-rfc6304bis-04

[Jari Arkko]

Thank you for your review, Tom!

jari

On 17 Aug 2014, at 12:14, Tom Taylor  wrote:

> It appears I messed up the distribution list. Please use the list in this 
> E-mail for any replies.
> 
> Tom Taylor
> 
> 
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-dnsop-rfc6304bis-04
> Reviewer: Tom Taylor
> Review Date: 15 August 2014
> IETF LC End Date: 29 July 2014
> IESG Telechat date: (if known)
> 
> Summary: This draft is ready to go.
> 
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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-tram-auth-problems-04

[Jari Arkko]

Brian et al: Thank you for the review and re-review, and addressing the 
comments.

Jari

On 15 Aug 2014, at 05:25, Brian E Carpenter  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-tram-auth-problems-04.txt
> Reviewer: Brian Carpenter
> Review Date: 2014-08-15
> IETF LC End Date: 2014-08-08
> IESG Telechat date: 2014-08-21
> 
> Summary:  Ready
> 
> 
> Comment:
> 
> 
> Thanks for addressing my previous comments.
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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-karp-bfd-analysis

[Jari Arkko]

Thanks for your review, Scott.

Jari

On 18 Aug 2014, at 03:18, Scott Brim  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-karp-bfd-analysis-06
> Reviewer: Scott Brim
> Review Date: 2014-08-17
> IETF LC End Date: 2014-08-12
> IESG Telechat date: 2014-08-21
> 
> Summary: This draft is ready for publication as an Informational RFC.
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art