Subject: Re: [Gen-art] Gen-ART Review of draft-ietf-l2vpn-vpls-pe-etree-10

From: Jari Arkko <[email-masked]>
Date: Thu, 3 Dec 2015 14:07:54 +0200

Many thanks for your detailed review, Russ!

Yuanlong, will there be a new draft version or other edits before the draft
is approved?

Jari

On 17 Nov 2015, at 00:53, Jiangyuanlong <[email-masked]> wrote:

> 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.
>> 
>> 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].
>> 
> [YJ] Yes, all these should refer to [802.1Q-2014].
> 
>> 
>> Other Editorial Comments:
>> 
>> The Abstract should appear on the title page.
>> 
> [YJ] OK.
> 
>> 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.
>> 
> [YJ] All these will be updated to MEF 6.2.
> 
>> 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].
>> 
> [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:
>> s/5.3.1.PW Processing/5.3.1. PW Processing/
>> 
> [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:
>> 
>>              +----------------------------------------+
>>              |           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
> 
> 
> [YJ] OK.
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 3 Dec 2015 15:02:52 +0000

Hi Jari,

Yes, we'll be doing a new revision for addressing other comments.

I've asked for today's telechat if no discusses to mark it as approved, revised draft needed.

Much thanks Russ for your review!

Deborah

Sent from my iPhone

> On Dec 3, 2015, at 1:08 PM, Jari Arkko <[email-masked]> wrote:
>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 3 Dec 2015 17:40:04 +0200

> I got the message from the responsible AD that a new version shall be submitted only after the telechat.
> And all the resolutions will be included in that version.

Good, thanks!

Jari

---

From: Jiangyuanlong <[email-masked]>
Date: Thu, 3 Dec 2015 15:15:46 +0000

Hi Jari,

Thanks,
Yuanlong

> From: Jari Arkko [mailto:[email-masked]]
> Sent: Thursday, December 03, 2015 8:08 PM
> To: Jiangyuanlong; Russ Housley
> Cc: [email-masked]; IETF Gen-ART; IETF
> Subject: Re: [Gen-art] Gen-ART Review of draft-ietf-l2vpn-vpls-pe-etree-10
> 
> Yuanlong, will there be a new draft version or other edits before the draft is
> approved?
> 
> Jari
> 
> >> 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].
> >>
> >> s/Specification MEF 6.1/Specification MEF 6.1 [MEF6.1]/ Also,
> >> [MEF6.1] needs to be added as a normative reference.
> >>
> >> 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:

---

From: Russ Housley <[email-masked]>
Date: Fri, 11 Dec 2015 18:26:04 -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.

Document: draft-ietf-dnsop-edns-client-subnet-04
Reviewer: Russ Housley
Review Date: 2015-12-11
IETF LC End Date: 2015-12-21
IESG Telechat date: unknown

Summary:  Almost Ready

Major Concerns: 

In Section 6, the figure includes a line that begins with "7:".  This
is incorrect.  It should begin with "8:".

Section 7.2.1 ends with: "Implementations SHOULD document their chosen
behavior."  I have no objection to such documentation, but some advice
about where someone might find it would be useful.  I do not think you
are asking each implementation to write an Informational RFC.  Further,
the use of "SHOULD" in this sentence has nothing to do with the normal
RFC 2119 usage, which applies to the action taken by an implementation.

Section 7.5 says:

   Intermediate Nameservers supporting ECS MUST forward options with
   SOURCE PREFIX-LENGTH set to 0 (that is, completely anonymized).  Such
   options MUST NOT be replaced with more accurate address information.

   An Intermediate Nameserver MAY also forward ECS options with actual
   address information.  This information MAY match the source IP
   address of the incoming query, and MAY have more or fewer address
   bits than the Nameserver would normally include in a locally
   originated ECS option.

These two paragraphs appear to contradict each other.  I cannot figure
out what an Intermediate Nameservers that supports forwarding of ECS
options ought to do with regard to source address information.

Please divide the references into normative and informative.  The URIs
should be informative references.  URIs must be stable references, and
I do not think that [4] qualifies.

Minor Concerns:

The last paragraph of the Introduction provides information that is
useful to someone doing a review.  However, it is not clear to me that
this information belongs in the Informational RFC.  I think that it
would be sufficient to say:

   At least a dozen different client and server implementations have been
   written based on earlier versions of this specification.  The protocol
   is in active production use today.  While the implementations
   interoperate, there is varying behaviour around edge cases that were
   poorly specified.  Known incompatibilities are described in this
   document, and the authors believe that it is better to describe the
   system as it is working today, even if not everyone agrees with the
   details of the original specification [1].  The alternative is an
   undocumented and proprietary system.

If you accept this approach, then you might also look for "original
draft" elsewhere in the document ans make a compatible change.

In Section 6, I think it would be useful to say that the SCOPE
PREFIX-LENGTH in a response MUST be less than or equal to the SOURCE
PREFIX-LENGTH.

In Section 7.1.1, can you add a sentence or reference to explain "lame
delegation"?  I recognize that this type of error results when a name
server is designated as the authoritative server for a domain name and
that server does not have authoritative data.

Section 7.4 says: "Several other implementations, however, do not
support being able to mix positive and negative answers, and thus
interoperability is a problem."  Then, the next paragraph says that
this topic will be revisited in a future specification.  Is there any
advice that the authors can share as a step toward interoperability
that would be useful for implementers until the future specification
comes about?

There are many places in the document where is says: "This draft ...".
These should be changed to "This document" or "This specification" in
preparation for publication as an Informational RFC.

In Section 4, some of the terms being defined are followed by a colon,
and others are not.  Please be consistent.  I prefer the inclusion of
the colon.

In Section 7.5, it says:

   It is important that any Intermediate Nameserver that forwards ECS
   options received from their clients MUST fully implement the caching
   behaviour described in Section 7.3.

To me, "It is important that" and "MUST" are redundant.

In Section 11.3, it says:

   o  Recursive Resolvers MUST never send an ECS option with a SOURCE
      PREFIX-LENGTH providing more bits in the ADDRESS than they are
      willing to cache responses for.

I think it would be netter to reword this as a MUST NOT statement.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 14 Dec 2015 17:01:11 -0500

>
> NOTES TO AUTHORS: I went to try integrate these changes and discovered
that the most recently published version of the document is -04, but the
version in github  (
https://github.com/wkumari/draft-vandergaast-edns-client-subnet ) is
version -06.
I have rolled this back to -05 and published as that. There are 2 places
below when I need some help with text.

> IESG Telechat date: unknown
Thank you for taking the time to review this document.

> is incorrect.  It should begin with "8:".
Doh! Thanks.

> RFC 2119 usage, which applies to the action taken by an implementation.

Good point. I've updated this to be:
"This choice should be documented for the operator, for example in the user
manual. "
Does this work for you?

> options ought to do with regard to source address information.

Yup, that was confusing. How is: "An Intermediate Nameserver MAY forward
ECS options with address information. This information MAY match the source
IP address of the incoming query, and MAY have more or fewer address bits
than the Nameserver would normally include in a locally originated ECS
option. If an Intermediate Nameservers receives a query with SOURCE
PREFIX-LENGTH set to 0 it MUST forward the query as-is and MUST NOT replace
it with more accurate address information." ?

> I do not think that [4] qualifies.

Thank you.
These have been fixed.
[4] Has now been published as an ID, and so is now stable(r) -
 I-D.hardie-privsec-metadata-insertion

>    undocumented and proprietary system.
Thank you.
The current text was arrived at after many iterations - I *think* that your
text will still keep everyone happy and so have incorporated it.

> draft" elsewhere in the document ans make a compatible change.

Thank you.

> that server does not have authoritative data.

[ AUTHORS: This was a term that was left out of the terminology draft. Do
you have any suggestions for how we can reword this to remove the need for
the term? ]

> that would be useful for implementers until the future specification

[ AUTHORS: Any text for here? ]

> preparation for publication as an Informational RFC.
Thank you, done.

> and others are not.  Please be consistent.  I prefer the inclusion of

Thank you. Done.

> To me, "It is important that" and "MUST" are redundant.

Fair 'nuff.
Fixed.

> I think it would be netter to reword this as a MUST NOT statement.

Yup. thank you. Done.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 15 Dec 2015 17:19:26 +0000

Hi all,

I think it is much easier for reviewers to always be able to see the latest
version of a draft, and so I'm trying to integrate changes and then publish
new version often.

On Tue, Dec 15, 2015 at 11:50 AM David C Lawrence <[email-masked]> wrote:

> "... to distinguish the respone from one where the Authoritative
> Nameserver is not responsible for the name, which is a common
> convention for the REFUSED status."
>

Nice.
Integrated.

> The current situation is such that I think it is best just to say only
> something like, "It is recommended that no specific behaviour
> regarding negative answers be relied upon."
>
>
Done.

Posted -06

W

> Personally my proposal is going to be that negative answers be allowed
> to be scoped the same way that positive answers can be, but I don't
> expect it to be without some controversy and it wouldn't be right for
> me to insert by own bias into this document -- especially since Wilmer
> is one of the people who has said that he doesn't think ECS should be
> able to be used with negative answers.
>

---

From: David C Lawrence <[email-masked]>
Date: Tue, 15 Dec 2015 11:50:24 -0500