Martin Thomson | 24 Apr 23:51 2014
Picon

Gen-ART review of draft-ietf-opsawg-large-flow-load-balancing-11

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-opsawg-large-flow-load-balancing-11
Reviewer: Martin Thomson
Review Date: 2014-04-24
IETF LC End Date: 2014-05-06
IESG Telechat date: (if known)

Summary: Basically ready.  Looks like a pretty straightforward, even
commonsense, coverage of the ways that flow distribution might be
achieved and a need for it identified.

Major issues: None

Minor issues: Or questions, really.

There's not a lot of discussion about the costs of maintaining an
exception list for rebalanced flows.  A hash-based distribution is
going to cost essentially zero state because the outbound path can be
determined on a per-packet basis, but as soon as you start
redistributing, there is an added state cost (and potential increase
in lookup times).  That probably needs some discussion.

This plays into the security considerations, which I think need to
(Continue reading)

A. Jean Mahoney | 24 Apr 22:43 2014

A *new* batch of IETF LC reviews - 2014-04-24

Hi all,

The following reviewers have assignments:

Reviewer          LC end       Draft
---------------------------------------------------------------------
Elwyn Davies      2014-05-16   draft-pal-eidr-urn-01

Francis Dupont    2014-05-02   draft-ietf-ipsecme-esp-ah-reqts-07

Joel Halpern      2014-05-06   draft-ietf-mpls-extended-admin-group-05

Martin Thomson    2014-05-06   draft-ietf-opsawg-large-flow-load-balancing-11

Meral Shirazipour 2014-05-07   draft-ietf-appsawg-uri-get-off-my-lawn-04

Peter Yee         2014-05-21   draft-eastlake-iana-cfm-considerations-01

I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

The standard template is included below.

Thanks,

Jean
(Continue reading)

Wassim Haddad | 23 Apr 19:31 2014
Picon

Gen-ART Review of draft-ietf-straw-b2bua-loop-detection-04

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

Document: draft-ietf-straw-b2bua-loop-detection-04
Reviewer: Wassim Haddad
Review Date: 23 Apr 2014
IETF LC End Date: 25 Apr 2014
IETF Telechat Date: 24 Apr 2014

Summary: This draft is ready to be published as proposed standard

Major Issues: None

Minor Issues: none

Regards,

Wassim H.



_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Romascanu, Dan (Dan | 23 Apr 14:55 2014

Gen-ART Telechat Review for draft-ietf-idr-aigp-17

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 <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Eric Osborne | 21 Apr 22:20 2014

Addressing comments on draft-ietf-mpls-psc-updates-03.txt

Folks-

  I have posted draft-ietf-mpls-psc-updates-04.  It addresses the
gen-art comments as well as other feeback received on this list from
the v-03 last call.  I also shuffled things around so that the section
order made more sense.

  This draft elicited a comment and a warning from idnits.  I believe
they are both OK to disregard:

1)

  -- The draft header indicates that this document updates RFC6378, but the
     abstract doesn't seem to directly say this.  It does mention RFC6378
     though, so this could be OK.

It's pretty clear that the document updates rfc6378.

2)

  == Missing Reference: 'RFC-ietf-mpls-psc-updates-04' is mentioned on line
     412, but not defined

This is a self-reference which needs to be updated with the RFC number
for this draft.

  I expect this to be good to go, but given the amount of reshuffling
and new text I'd like to give folks one more shot at tweaking the
language.

The meat of the work is in section 2.2.  Adrian, Elwyn - this contains
the majority of the changes based on gen-art feedback and other
discussions on the list.  Please give this the once-over at your
convenience.

eric
Elwyn Davies | 19 Apr 01:34 2014

Gen-art early review of draft-hoffman-xml2rfc-04.txt

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>.

This is an "early review" requested by Heather Flanagan as part of the 
development of xml2rfc version 3.

Document: draft-hoffman-xml2rfc-04.txt
Reviewer: Elwyn Davies
Review Date: 19 April 2014
IETF LC End Date: N/A
IESG Telechat date: (if known) N/A

Summary:

Major issues:

Minor issues:
s1.1/s1.1.1:
I think it would good to split up the text in s1.1 into two parts.  The
text from para 2 ("The design criteria of the changes..") up to and
including the para starting "The canonical RFCs will not have..." is
about the design rationale and probably deserves a separate section.
s1.1.1 should be a sub-section of this new section.  The remainder of
s1.1 is then *really* the change list.  

ss2.11, 2.37, 2.42, 2.47: <city> and other components of <postal>:
Should these elements be allowed to be any unicode characters with an
 <at> ascii attribute as per fullname?

ss2.16, 2.17, 2.18 <dl> and components:  I think the definition list
needs a bit more work.
- <dd> doesn't seem to have a way of getting blank lines into a
definition.  I think it needs the same alternative 'sequence of one or
more <t>'s as allowed for <ol> and <ul>.
- <dd> should allow subsidiary <dl>'s as content.
- Is there any reason why a <dd> shouldn't include <texttable> (and
indeed any other type of list entry)?  Currently <texttable> only occurs
as a child of <section>. 
- Should the author be allowed any control over the amount of indent for
the definition part?  I realize that we are trying to avoid controlling
the formatting explicitly, but there may be aesthetic/readbility reasons
why the author may want the indent to be a controllable.  One reason is
where there are two or more logically related definition lists, maybe
in different sections or just separated by other text.  The author may
wish to have the same amount of indent in these lists so that the reader
is not distracted by the different amount of indent.  My suggestion
would be to allow the author to specify a text string whose length is
used to determine the indent - this avoids any need to specify units or
worry about line length.  Presumably the default would be 'a bit longer
than the longest definition term in the list' although I am not sure
what happens if you have a very long label/term and the definition start
on the same line.
- This brings me on to another issue.  A convention often used in
definition or dictionary lists is that if the label/term is longer than
the hanging indent, the label is allowed to run over the top of the
definition but the definition starts on the same line as the term.  I am
not clear if this can be achieved with the specification as is.  I would
like to be able to achieve this (see next point).
- The 'hanging' attribute is used to specify that the term is or is not
on a separate line.  If hanging is false is the intention that the
definition will be indented?  Or is this left up to the whim of the
formatter?  Currently all list entries are indented (although you could
perhaps use a zero indent - I have never tried!) so it would probably
worth being explicit about what is intended.  If the intention is not to
indent, then it might be useful to have an additional value for spacing
that also adds space between the label line and the definition.

s2.22.7 figure/ <at> title attr:  There is currently no way to incorporate
font characteristic changes in the title (bold etc).  In v2 this has
never been an issue, but it might be desirable to be able to allow font
changes in future.  Maybe this could be done by allowing a <title>
element instead of the attribute and modify the title to allow font
changes - that would also allow the document title to include font
changes as well.  This would probably apply to <texttable> as well.

s2.33 <ol>: The <ol> element does not cater for the cases like 
<list style="format R(%d)" counter="req"> 
that allows ordered lists to be numbered across multiple
instances/sections without having to manually keep track of the counter
start value in each separate <ol>.  An example can be found in 
RFC 5772, s3.6.1 et seq.  This would need the counter attribute to
reappear on this element.  The discussion of the possibility of
specifying a hangIndent as per the comments on <dl> above is also
relevant because the length of the label is dependent on the number and
it is better to use the same indent for all related lists.  Having a
counter="variable-name" attribute would also alter the effect of start -
counter variable should be left unchanged if specified and start is not
specified.  'Default' counter (known as .COUNTER in v2) is reset to 1 if
neither counter nor start is specified. 

Nits/editorial comments:
========================
s1.1, 2nd set of bullets, 1st bullet: Expand RNG

ss1.1, 2.36, 2.37, App B: s/postalline/postalLine/ (this has been
discussed on the mailing list and does make it more comprehensible.

s1.1:  I think it would be worth giving an overview of what is being
done to list handling here, probably as a new subsection to go with with
the rebranded s1.1.1.  It is IMO the other really major change that
users will have to get their heads round.

s2.2 <author>:  Probably worth  mentioning that it is not used when
<author> is used in <reference>.  Maybe also worth flagging that
<facsimile> is deprecated.

s2.4 <area>: s/this document applies to/to which this document relates/
Should probably mention that the areas/names might change over time.
(Are there any historical areas that need to be considered?  I don't
think so but I can't be sure.)

s2.5 <artwork>: Could be useful to mention use of CDATA here.  I would
be inclined to add 'accessed via a URI' to the discussion of the src
attribute.

s2.5.5 src attr: Are there any restrictions on the URI to be used?  In
particular is file: allowed? 

s2.5.5 src attr: Does this need an associated 'scale' attribute so that
the graphic can be displayed as intended?

s2.5.6 type attr, last para: s/mainatin/maintain/

s2.5.6 type attr: I think 'xml' would be an essential extra.  Also
probably 'message-flow' and maybe 'protocol-format' or some such as a
variant on ascii-art specifically identifying one of the many wire
format descriptions. 

s2.6.3 initials attr: An example would help ... say 'e.g., for J. Edgar
Hoover initials="J. E."'

ss2.7, 2.25, 2.52 <b>, <i>, <tt>:  I presume the intention is that the
effects of these font characteristic specifiers should be cumulative
(i.e., <i> just italic text <b> bold italic text </b> italic text</i>)
etc.  Whatever is intended should be explained (maybe a common section
back at the beginning?) I assume that  <i><b><i></i></b></i> would be
legal but that the inner <i> would have no additional effect in each
case.  Maybe processors could issue a warning.

s2.8 <back>: Worth noting that <sections> are appendices here.

s2.9 <blockquote>/s2.9.2 cite attr: I am not keen on requiring the cite
value to be a URL.  Wouldn't it be more natural for it to be a reference
anchor with an optional attribute specifying the location within the
reference, thus:
   <blockquote anchor="bq1" cite="RFC1918" location="Section 2.5 -or-
page 3">Some quoted text........</blockquote>

[I am not sure about the attribute name 'location' but nothing better
springs to mind just now.]

Would this then come out (in ASCII) as:

... previous text with quoted lines indented after it:
   Some quoted text.......
           ([RFC1918], Section 2.5)
Followed by text after the  <at> blockquote.  The reference should probably
be right justified.

How would the anchor be referenced?  Maybe "[RFC1918], Section 2.5"

s2.10 <c>: I have suggested further on that  <at> ttcol should have an align
attribute.  If this is agreed, my idea would be that the alignment
applies to all the cells in the column headed by the relevant  <at> ttcol.

s2.13 <country>:  Once upon a time I thought that we were supposed to be
using two letter country codes from ISO 3166. As per RFC 2629, s2.2.2.

s2.15 <date>: Where do we put 'vague date' strings? Must say I have
never tried a vague date in a reference.  

s2.15.1 day attr:  Note that it is the day *number*. 

s2.15 <date>/s2.15.2 month attr: Is there any reason why we can't allow 
month numbers here as an official alternative?  I think we can still do
the calculation! Better check the style guide to see how dates are
printed out: Presumably the intention is we stick with 16 April 2014
etc.

s2.16 <dd>: I think this should be able to have 

s2.18 <dt>, para 1:  Cut and paste error, I think. Replace with 
'The term being defined by an entry in a definition list.' 

s2.15.3 year attr: Should probably reinforce that it is a 4 digit year
number (or explicitly that it can be 2 digit?)

s2.20 <eref>: Might be worth mentioning that the content and the  <at> target
attr would be combined if the output format can represent hyperlinks.

s2.22 <figure>, para 1: s/postamable/postamble/

s2.22.6 suppress-title attr:  Reversing the meaning of the true/false
values would make more sense (as discussed elsewhere).  Comment also
applies to s2.49.4.

s2.22.7 title attr:  The autogenerated title is combined with the
contents of the attribute  in v2 - I think this could be clarified (I
misread it): Try s/the title gets an/the title is combined with an/.
Also applies to s2.49.5.

s2.23 <format>:  I like 'depredated'!  Unfortunately I guess we have to
s/Depredated/Deprecated/.

s2.29 <li>:  Should one or more <texttable>'s be allowed in the content?

s2.33.3 style attr: It would be useful to specify  what happens after
z/Z in the letter cases (I *think* v2 does aa, ab, ac etc.).  Somewhere
there is an RFC that exercises this.  I believe that if you go back far
enough in the xml2rfc mailing list (say about 2005) there is some
discussion of this.

s2.33.3 style attr: It would probably be very occasionally useful to be
able to specify the field width of the % formats.

s2.37 <postalline>: As suggested on the mailing list it would be more
readable if this were <postalLine>.  As suggested previously this might
need an ascii equivalent.

ss2.38/2.39 <postamble>/<preamble>: Is there ever a need for multiple
paras in a pre-/postamble?  I think I have seen <vspace> in some cases.
Should multiple <t>'s be allowed?

s2.40 <reference>: This is, I believe, still under discussion.  One
point is that the id case may want to specify the version of the id
explicitly (defaulting to the most recent).  The content model is not
right: It is either empty or one <front> plus optional <seriesInfo>,
<format>, <innerRefContent>, <annotation>'s.  <innerRefContent> is
defined but hasn't made it into <reference yet>.
In para 6: s/refernence/reference/

ss2.40.2/2.40.3 series/document attrs:  These are specified as mandatory
but this doesn't work if the <front> specification option is used.

ss2.43.7/2.43.10 obsoletes/updates attrs: Probably ought to specify
whether or not white space is allowed.

s2.44 <section>: Might be worth saying explicitly that it can be empty.

s2.48 <t>: Should <texttable> be allowed within <t>?  As mentionaed
above there are some other places where <t> might be a child (<dd> and
maybe <note>).

s2.49 <texttable>: See previous discussion as to whether <texttable>
should be used elsewhere.  See also comments on s2.22.6 and s2.22.7.

s2.50 <tindent>: Could <tindent>'s appear inside list elements?

s2.51 <title>: Could this be allowed <b>, <i> and <tt>in the content?

s2.53 <ttcol>:  The content model should probably allow for <b>, <i> and
<tt>.

Appendix B looks to match OK except for <reference>.
Vijay K. Gurbani | 17 Apr 17:34 2014

Gen-ART review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-05

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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

Document: draft-ietf-l2vpn-vpls-inter-domain-redundancy-05
Reviewer: Vijay K. Gurbani
Review Date: Apr-17-2014
IETF LC End Date: Apr-24-2014
IESG Telechat date: Not known.

This document is ready as a Proposed Standard but has some nits and a
minor issue that should be looked at.

Major: 0
Minor: 1
Nits:  7

Minor:

- Section 7, paragraph 2: Okay to use MD5?  Or something stronger...?

Nits:

- Section 1, paragraph 1:
   s/is to provide/provides/

- Section 1, paragraph 2:
   s/options introduced./options are introduced./

- Section 3: What is an "ASBR"?  If it is a well-known term in the
  domain, I suspect you don't need to expand it ...

- Section 3: s/agreements(SLAs)./agreements (SLAs).

- Section 7, first paragraph: s/will have/has/

- Section 7, second paragraph:
  s/ICCP is now/If ICCP is/

- Section 7: You use "pseudowire" here whereas in most of the
  remaining document you used "PW".  You may want to be consistent.

Thanks,

- vijay
--

-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg <at> {bell-labs.com,acm.org} / vijay.gurbani <at> alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq
Black, David | 17 Apr 01:30 2014

Gen-ART review of draft-ietf-bfd-mib-17

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-bfd-mib-17
Reviewer: David L. Black
Review Date: April 16, 2014
IETF LC End Date: April 28, 2014

Summary: This draft is on the right track, but has open issues
		described in the review.

This draft is a MIB module for the BFD protocol, which is an important low-
level routing protocol.  The draft is reasonable for a MIB draft; one needs
to go read the protocol documents to understand how the protocol works, and
significant portions of the text are derived from the usual MIB "boilerplate"
as one would expect.  The "Brief Description of MIB Objects" is indeed
brief, but reasonable.  The shepherd writeup indicates that there are
multiple implementations.

Major issues:

This MIB contains many writable objects, so the authors should
take note of the IESG statement on writable MIB modules:

	http://www.ietf.org/iesg/statement/writable-mib-module.html

I did not see this mentioned in the shepherd writeup.  If the OPS Area
has not been consulted, I strongly suggest doing so during IETF Last
Call, e.g., starting with Benoit Claise (AD).

Minor issues:

The security considerations section includes considerations for
unauthorized modification of bfdSessAdminStatus and bfdSessOperStatus,
but omits the corresponding considerations for bfdAdminStatus and
bfdSessNotificationsEnable.  Both of the latter objects are global,
so significant damage can be inflicted via these objects with a
small number of unauthorized modifications, so they need to be
included in the first list of sensitive objects.

I suggest that the authors recheck the entire MIB to ensure that
every object or table that should be included in the security
considerations section is appropriately included.

Also, as a General Variable, would bfdSessNotificationsEnable be better
named bfdNotificationsEnable, as it's not in the BFD Session Table?

I did not see a compliance requirement for a system that only
implements BFD protocol version 0.  That absence should at least be
mentioned somewhere.  For example, if this reflects a considered and
deliberate decision by the WG, that should be mentioned in the
introduction.

Nits/editorial comments:

In the security considerations for authentication-related objects:

OLD
   In order for these sensitive information
   from being improperly accessed, implementers MAY wish to disallow
   access to these objects.
NEW
   In order to prevent this sensitive information
   from being improperly accessed, implementers MAY disallow
   access to these objects.

idnits 2.13.01 found a truly minor nit that should be corrected when
the draft is next revised:

  == Outdated reference: A later version (-05) exists of
     draft-ietf-bfd-tc-mib-04

it also generated a warning that probably does not reflect an actual problem:

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     http://trustee.ietf.org/license-info for more information.)

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------
A. Jean Mahoney | 17 Apr 00:03 2014

Assignments for the 2014-04-24 Telechat

Hi all,

The following reviewers have assignments:

Reviewer            LC end       Draft
------------------------------------------------------------------------------------
Dan Romascanu          TR2014-02-24 
draft-ietf-mpls-ldp-applicability-label-adv-03 *

Dan Romascanu          TR2014-04-08 draft-ietf-idr-aigp-17 *

Roni Even              TR2014-02-28 draft-housley-pkix-oids-02 *

Russ Housley           TR2013-12-16 draft-ietf-opsec-vpn-leakages-04 **

Tom Taylor             TR2014-04-23 draft-ietf-precis-framework-15 **

* Earlier draft reviewed
** Already reviewed

I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

For your convenience, the review boilerplate template is included below.

Note that reviews should ideally be posted to the gen-art mailing list
by COB on Tuesday:
http://wiki.tools.ietf.org/area/gen/trac/wiki/

Jean

-------------------------------------------------------------------

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:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:
A. Jean Mahoney | 16 Apr 23:26 2014

A *new* batch of IETF LC reviews - 2014-04-16

Hi all,

The following reviewers have assignments:

Reviewer          LC end       Draft
---------------------------------------------------------------------
Alexey Melnikov   2014-04-25   draft-ietf-salud-alert-info-urns-12

Ben Campbell      2014-04-30   draft-ietf-radext-dtls-10

Brian Carpenter   2014-04-25   draft-ietf-rtcweb-use-cases-and-requirements-14

Christer Holmberg 2014-04-28   draft-ietf-bfd-tc-mib-05

Dan Romascanu     2014-04-29   draft-ietf-dhc-dhcpv4-over-dhcpv6-07

David Black       2014-04-28   draft-ietf-bfd-mib-17

Vijay Gurbani     2014-04-24   draft-ietf-l2vpn-vpls-inter-domain-redundancy-05

Wassim Haddad     2014-04-25   draft-ietf-straw-b2bua-loop-detection-04

I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

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

<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:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:
Ben Campbell | 15 Apr 21:28 2014

Re: Gen-ART LC/Telechat Review of draft-ietf-v6ops-64share-09

Hi,

Version 10 addresses all of my comments on version 09.

Thanks!

Ben.

On Apr 1, 2014, at 6:14 PM, Vízdal Aleš <ales.vizdal <at> t-mobile.cz> wrote:

> Dear Ben, all,
>  
> Many thanks for your review. An updated I-D has been submitted.
>  
> Please see inline.
>  
> > -----Original Message-----
> > From: Ben Campbell [mailto:ben <at> nostrum.com]
> > Sent: Friday, March 21, 2014 8:25 PM
> > To: draft-ietf-v6ops-64share.all <at> tools.ietf.org
> > Cc: gen-art <at> ietf.org Team (gen-art <at> ietf.org)
> > Subject: Gen-ART LC/Telechat Review of draft-ietf-v6ops-
> > 64share-09
> >
> > I am the assigned Gen-ART reviewer for this draft. For
> > background on Gen-ART, please see the FAQ at <
> > http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> >
> > Please wait for direction from your document shepherd or AD
> > before posting a new version of the draft.
> >
> > Document: draft-ietf-v6ops-64share-09
> > Reviewer: Ben Campbell
> > Review Date: 2014-03-21
> > IETF LC End Date: long time ago
> > IESG Telechat date: 2014-03-27
> >
> > Note: I somehow missed this assignment at last call time.
> > Therefore this review serves as both a last call and an IESG
> > telechat review.
> >
> > Summary: This draft is mostly ready for publication as an
> > informational RFC. I have a few editorial comments that might
> > be worth considering prior to publication.
> >
> > Major issues: None
> >
> > Minor issues: None
> >
> > Nits/editorial comments:
> >
> > -- Section 1, paragraph 1:
> >
> > Can you elaborate on what it means to "extend" The prefix to
> > a LAN link? Are we talking about routing IPv6 traffic from
> > other local devices (on the LAN) across the 3gpp link, for
> > example, like one might do when tethering devices to a phone
> > or mobile hotspot?
>  
> Yes, this is the case.
>  
> > Can you offer a reference for "the 3GPP specification"?
> >
> > Can you offer a reference for "the 3GPP specification"?
>  
> Done.
>  
> > -- paragraph 2: "This can be achieved by receiving the Router
> > Advertisement (RA) [RFC4861] announced globally unique /64
> > IPv6 prefix from the 3GPP radio interface and then
> > advertising"
> >
> > What does these things. The UE?
>  
> Yes, the UE. Ref to the UE has been added.
>  
> > Please expand RA on first mention.
>  
> Done.
>  
> >
> > -- section 3, R-1:
> >
> > Please expand SLAAC on first use.
>  
> Done.
>  
> > -- section 4.2, 1st paragraph: "The 3GPP RA /64 prefix
> > information is used to configure NDP on the LAN and assigns
> > itself an address on the LAN link."
> >
> > The prefix information assigns itself an address? I don't
> > think that's what you mean to say.
>  
> Fixed, please review.
>  
> > -- section 4.2, step 7:
> >
> > Please expand DAD on first use.
>  
> Done.
>  
> Cheers,
> Ales
> 
> Zásady komunikace, které společnost T-Mobile Czech Republic a.s. užívá při sjednávání
smluv, jsou uvedeny zde http://www.t-mobile.cz/zasady. Není-li v zásadách uvedeno jinak,
nepředstavuje tato zpráva konečný návrh na uzavření či změnu smlouvy ani přijetí takového
návrhu. The communication principles which T-Mobile Czech Republic a.s. applies when negotiating
contracts are defined here http://www.t-mobile.cz/principles. Unless otherwise stated in the
principles, this message does not constitute the final offer to contract or an amendment of a contract or
acceptance of such offer.

Gmane