Subject: Gen-ART Review of draft-ietf-l2vpn-vpls-pe-etree-10

From: Russ Housley <[email-masked]>
Date: Fri, 13 Nov 2015 12:27:54 -0500

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-l2vpn-vpls-pe-etree-10
Reviewer: Russ Housley
Review Date: 2015-11-13
IETF LC End Date: 2015-11-24
IESG Telechat date: unknown

Summary:  Almost Ready

Major Concerns: None

Minor Concerns:

Sections 4.1 and 5.3.1 inclues a reference to [802.1Q-2011].  Should
this be the 2014 version of the document?  If not, please add the
informative reference for [802.1Q-2011].

Other Editorial Comments:

The Abstract should appear on the title page.

Section 3 needs a reference for MEF 6.1:
s/Specification MEF 6.1/Specification MEF 6.1 [MEF6.1]/
Also, [MEF6.1] needs to be added as a normative reference.

Section 3 needs a reference for IEEE 802.1Q-2003:
s/B.1.3 of IEEE 802.1Q-2003/B.1.3 of IEEE 802.1Q-2003 [802.1Q-2003]/
Also, please add an informative reference for [802.1Q-2003].

Third level section headings do not have space between the section
number and the section title.  For example:
s/5.3.1.PW Processing/5.3.1. PW Processing/

In Fig 4, there is room to shift the figure to the right, this will
allow the "AC" labels to fit better on the left:

              +----------------------------------------+
              |           VPLS-capable PE model        |
              |   +---------------+          +------+  |
              |   |               |==========|TVSI-1|------------
   +---+  AC  |   |               ------------      |------------ PWs
   |CE |----------|     Bridge    ------------      |------------
   +---+      |   |               | Root &   +------+  |
              |   |     Module    | Leaf VLAN   o      |
              |   |               |             o      |
              |   |               |             o      |
              |   |               |             o      |
              |   |               |             o      |
   +---+  AC  |   |               |   VLAN-n +------+  |
   |CE |----------|               ------------VSI-n |-------------
   +---+      |   |               |==========|      |------------- PWs
              |   |               |     ^    |      |-------------
              |   +---------------+     |    +------+  |
              |                         |              |
              +-------------------------|--------------+
                            LAN emulation Interface

          Figure 4  A VPLS PE Model for E-Tree with a Single T-VSI

---

From: Jiangyuanlong <[email-masked]>
Date: Mon, 16 Nov 2015 22:53:17 +0000

Russ,

Thanks a lot for your review and good observations.
Please see my comments in line.

Best regards,
Yuanlong

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Saturday, November 14, 2015 1:28 AM
> To: [email-masked]
> Cc: IETF Gen-ART; IETF
> Subject: Gen-ART Review of draft-ietf-l2vpn-vpls-pe-etree-10
> 
> 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.
> 
> Sections 4.1 and 5.3.1 inclues a reference to [802.1Q-2011].  Should this be
> the 2014 version of the document?  If not, please add the informative
> reference for [802.1Q-2011].
> 
[YJ] Yes, all these should refer to [802.1Q-2014].

> The Abstract should appear on the title page.
[YJ] OK.

> s/Specification MEF 6.1/Specification MEF 6.1 [MEF6.1]/ Also, [MEF6.1]
> needs to be added as a normative reference.
> 
[YJ] All these will be updated to MEF 6.2.

> s/B.1.3 of IEEE 802.1Q-2003/B.1.3 of IEEE 802.1Q-2003 [802.1Q-2003]/ Also,
> please add an informative reference for [802.1Q-2003].
> 
[YJ] Yes, we will add an informative reference for [802.1Q-2003].

> Third level section headings do not have space between the section number
> and the section title.  For example:
[YJ] OK.

> In Fig 4, there is room to shift the figure to the right, this will allow the "AC"
> labels to fit better on the left:
> 

[YJ] OK.

---

From: Russ Housley <[email-masked]>
Date: Wed, 25 Nov 2015 17:49:35 -0500

Document: draft-ietf-eppext-tmch-smd-03
Reviewer: Russ Housley
Review Date: 2015-11-25
IETF LC End Date: 2015-12-04
IESG Telechat date: unknown

Summary:  Not Ready

Major Concerns: 

Section 1 needs to be expanded; it needs to provide the answers to the
following questions.  Does the presence or absence of a digital
signature on the mark impact its handling?  What is the purpose of the
digital signature?  Who is applying the signature?  Why are they
signing?

In section 2.1, the document says: "A <mark:name> MUST be specified in
case <mark:org> is not specified."  I see two possible ways to interpret
this statement.  One way is that <mark:name> must always be included.
The other way is that <mark:name> must be include if <mark:org> is not.
I think you mean the second interpretation.  Please clarify.

In Section 2.1. the document says: "A <mark:org> MUST be specified in
case <mark:name> is not specified."  As above, there are two possible
ways to interpret this sentence.  Please clarify.

In Section 2.3, there is not enough information provided to validate
the digital signature.  It seems to me that the digital signature can
be validated using the public key of a trust anchor or the public key
obtained from a valid X.509 certification path originating with a
trust anchor.  If I have understood that properly, then RFC 5280 is
needed as a normative reference.  In addition, most protocols that
make use of certificates perform some checks on the certificate
subject name.  If any certificate that chains to the trust anchor is
as good as any other, then this should be stated explicitly.  Otherwise
the checks the determine that this is an appropriate certificate for
this mark need to be specified.

In the IANA Considerations, the authors are listed as the contacts for
the name space and schema registrations.  Since this is a standards
track document, is the IESG a better point of contact for these entries
in the IANA registry?

Minor Concerns:

Section 2.5 has this heading: "Appendix A. base64 encoded signedMark".
If it is intended to be an Appendix, then it should be moved to the
end of the document.

Sections 3.1 and 3.2 include "Copyright (c) 2012 ...".  Is this the
correct year for the copyright?

The Security Considerations might make suggestions about
canonicalization to avoid breaking the XML digital signature.

Section 5 talks about "special suggestions".  I have no idea what
that means.