Re: [Gen-art] Genart telechat review of draft-ietf-trill-transport-over-mpls-07

[Alissa Cooper]

Stewart, thanks for your review. I entered a No Objection ballot.

Alissa

> On Mar 2, 2018, at 3:25 PM, Stewart Bryant  wrote:
> 
> Reviewer: Stewart Bryant
> Review result: Ready with Issues
> 
> 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-ietf-trill-transport-over-mpls-07
> Reviewer: Stewart Bryant
> Review Date: 2018-03-02
> IETF LC End Date: 2018-03-06
> IESG Telechat date: 2018-03-08
> 
> Summary: An understandable document. The only comment of note is the 
> conflation
> of PW headers and MPLS headers. There are a couple of easy to fix nits.
> 
> Major issues: None
> 
> Minor issues:
> 
> 6. Packet Processing Between Pseudowires
> 
> In this section you conflate PW headers and MPLS headers.
> The PW label is a type of  MPLS label, although it has its own forwarding
> instruction, but the control word is not part of MPLS.
> 
> Nits/editorial comments:
> 
> There is an ASCII art error in Fig 1 on the line containing Tenant1 Site1
> 
> The terms PE device and PE router seem to be used interchangeably.  Is this an
> error, or are they distinct devices.
> 
> The VTSD must be capable of forming TRILL adjacency with the
> SB> Should be "forming a TRILL adjacency"
> 
> 
> ___
> 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] Genart last call review of draft-ietf-teas-rsvp-ingress-protection-13

[Alissa Cooper]

Robert, thanks for your review. Huaimo, thanks for your responses. I think with 
the final change agreed between Huaimo and IANA, Section 8 should be good to 
go. I entered a No Objection ballot.

Alissa

> On Mar 1, 2018, at 10:43 AM, Robert Sparks  wrote:
> 
> I'm fine with the way you handled all my editorial suggestions.
> 
> I'm still uncomfortable with what you are asking IANA to do. I think at this 
> point you need to have a conversation with your AD.
> 
> As -14 is written, you are trying to put a value in a part of the class 
> names, class numbers, and class types registry at a codepoint that requires 
> "Standards Action" (Range 0-119). Maybe I'm misremembering, but I don't 
> _think_ you can do that with an Experimental document.
> 
> The language you have for the subregistry that you are _NOT_ asking IANA to 
> create at this time still implies that it exists as a registry (with 
> discussions of initial values and future assignment policies). Instead, I 
> think you need something like "During this experiment, the types of the new 
> subobjects are defined by the following table in this document. If the 
> concept proceeds to the standards track, these will move to an IANA 
> maintained registry" or some similar language.
> 
> Again, get your ADs advice on what to do next here.
> 
> RjS
> 
> 
> On 2/28/18 8:18 PM, Huaimo Chen wrote:
>> Hi Robert,
>> 
>> Thank you very much for your time and valuable comments.
>> Answers to them are inline below with prefix [HC].
>> Would you mind reviewing them to see if they address the issues?
>> 
>> Best Regards,
>> Huaimo
>> -Original Message-
>> From: Robert Sparks [mailto:rjspa...@nostrum.com]
>> Sent: Wednesday, February 21, 2018 12:20 PM
>> To: gen-art@ietf.org
>> Cc: i...@ietf.org; t...@ietf.org; 
>> draft-ietf-teas-rsvp-ingress-protection@ietf.org
>> Subject: Genart last call review of 
>> draft-ietf-teas-rsvp-ingress-protection-13
>> 
>> Reviewer: Robert Sparks
>> Review result: Not Ready
>> 
>> 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
>> 
>> .
>> 
>> Document: draft-ietf-teas-rsvp-ingress-protection-13
>> Reviewer: Robert Sparks
>> Review Date: 2018-02-21
>> IETF LC End Date: 2018-03-01
>> IESG Telechat date: 2018-03-08
>> 
>>  Summary: Not Ready for publication as an Experimental RFC
>> 
>> I found this document hard to read. I encourage a significant editorial pass 
>> that focuses on presenting the core ideas early, and simplifies the language 
>> used throughout the document.
>> [HC] We have presented the core ideas early and simplify the language used in
>> the document accordingly.
>> 
>> 
>> Major Issues:
>> 
>> 1) The IANA considerations section is unclear. You ask IANA to put something 
>> in "Class Names, Class Numbers, and Class Types" at 
>> .
>> But there is no registry with that title on that page. (Nor is there a 
>> registry with a structure matching the row you are asking IANA to add.) Did 
>> you mean the registry at 
>> ?
>> [HC] Yes. You are right. We have corrected it in the document.
>> 
>> 
>> If so, the number you are suggesting is in a "Reserved for Private Use" 
>> range.
>> If that _was_ your target, the structure of your requested record does not 
>> match the structure of the existing registry. Please clarify.
>> [HC] We are considering a new C-Type under the existing Protection Class.
>> The related text has be updated accordingly as below:
>> Upon approval of this document, IANA is requested to assign a new
>> Class Type or C-Type under Class Number 37 and Class Name PROTECTION
>> located at > rsvpparameters.xhtml#rsvp-parameters-39>, as follows:
>> 
>> Value Description   Reference
>> - ---   -
>>   4Type 4 INGRESS_PROTECTION   This Document
>> 
>> 
>> The instructions to IANA for what to do when this document moves to the 
>> standards track are inappropriate. You can say that you anticipate that the 
>> future document that moves the idea to the standard track expects to create 
>> a new registry under rsvp-te-parameters, but this document cannot instruct 
>> IANA to do so.
>> [HC] We have revised the text according to your suggestion as below:
>> It is anticipated that the future document that moves the idea to the
>> standard track expects IANA to create and maintain a new registry under
>> PROTECTION object class, Class Number 37, C-Type 4. Initial values for
>> the registry are given below. The 

[Gen-art] Genart telechat review of draft-ietf-6lo-rfc6775-update-14

[Peter Yee]

Reviewer: Peter Yee
Review result: Ready with Issues

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-ietf-6lo-rfc6775-update-14
Reviewer: Peter Yee
Review Date: 2018-03-07
IETF LC End Date: 2018-03-06
IESG Telechat date: 2018-04-05

Summary: This document updates RFC 6775 with an Extend Address Registration
Option and various changes/simplifications.  There are some questions I have
that should be addressed along with a list of nits. [Ready with issues.]

I am aware that this is a review against draft -14.  Unfortunately, I started
the review before -15 was released and I lack the time to go back and start
with draft -15.  I hope that most of my comments remain relevant and useful.

Major issues:  None

Minor issues:

Page 6, 2nd paragraph: why is the capability for multiple registrations only
"RECOMMENDED"?  It's not entirely clear why one would not want to follow this
recommendation.  The second sentence says "It is also RECOMMENDED to provide
new mechanisms..."  To whom is this recommendation made - the working group? 
It's not clear why this recommendation is here and stated in RFC 2119 form.

Page 11, Section 4.6, 5th paragraph, last sentence: it's not clear to me how
the 6LN knows this is the case.

Page 19, Section 7.1.2, 4th paragraph, last sentence: the sentence reads: "Once
the 6LR is known to support this specification, the 6LN MUST obey this
specification."  Isn't that only true with respect to that 6LR, not necessarily
all 6LRs with which the 6LN may be communicating?  If so, perhaps that point
should be clarified in the text.

Page 20, Section 7.3, 3rd paragraph: what's the definition of "reasonable".  If
guidance on what reasonable can't be given other than to say it's device and
deployment dependent, is the guidance useful?  Or are there known guidelines
that are easily derived from the device type and perhaps less so from the
deployment parameters?

Page 21, Section 8, 2nd paragraph: the paragraph notes an expectation of a
secure MAC in order to work.  Is that a realistic assumption?  Or is that a
requirement and the whole scheme (potentially) falls apart if a secure MAC is
not being used?

Page 22, 1st partial bullet item, last sentence: I may be confused, but why
would a larger lifetime be appropriate for a node that moves compared to one
that is relatively static?  Wouldn't the mobile node do better with a smaller
lifetime so its registration doesn't linger on a 6LR that is simply not aware
that the node has moved (and probably failed to deregister from it)?

Page 36, Req5.3: the requirement reads: "6LoWPAN ND security mechanisms SHOULD
lead to small packet sizes".  Should that really say that their use SHOULD NOT
lead to large packets?  I can't imagine a security mechanism that makes a
packet smaller.

Page 36, Req5.6: You may wish to expand this beyond CCM* as IEEE 802.15.4y is
being spun up to make IEEE 802.15.4 algorithm agile.  At a minimum, this will
likely add 256-bit key sizes and allow the use of GCM as a peer to CCM*.

Nits/editorial comments:

General:

I mark these nits in order to save the RFC Editor a bit of work later on in the
process and to make comprehension easier for all readers.  Take these as you
will.

General:

Throughout the document, change "a NA" to "an NA".  Change "a NS" to "an NS". 
Change "a LLN" to "an LLN".  Change "a RPL" to "an RPL" unless RPL is typically
spoken as "ripple" and not spelled out.  Change "a EARO" to "an EARO".  Change
"a EDAR" to "an EDAR".  Change "a RUID" to "an RUID" unless it pronounced like
"druid" without the leading 'd'.

Change "ARO option" to "ARO".  Change "EARO option" to "EARO".  Change "SLLAO
option" to "SLLAO".

Change any use of "IEEE Std." to "IEEE Std" and leave a space after "Std". 
Yes, the IEEE is aware that it would be more grammatical to use "Std.", but
they don't.

Make sure each use of "i.e." and "e.g." is followed by a comma.

Change "replacement to" to "replacement for".

Replace "BLUETOOTH" with "Bluetooth".  And if you're going to use "(R)" for
Bluetooth, consider that IEEE says, "The term EUI-64 is trademarked by IEEE and
should be so identified."

Change "TimeSlotted" to "Timeslotted" to match IEEE Std 802.15.4 usage.

Change "Dependant" to "Dependent".

Specific:

Page 1, Authors: change "cisco" to "Cisco" or "Cisco Systems" to reflect the
official name of the company.

Page 1, Abstract: change "low power" to "low-power".

Page 3, Section 1, 1st paragraph, 1st sentence: change "Low Power" to
"Low-Power".

Page 3, Section 1, "Registration" bullet item: change "a IPv6" to "an IPv6".

Page 4, "Extended LLN" definition: change "MultiLink" to "Multilink" or
"Multi-Link" or 

Re: [Gen-art] review of draft-ietf-netmod-syslog-model-21.txt

[Alissa Cooper]

Francis, thanks for your review. I have entered a No Objection ballot.

Alissa

> On Mar 5, 2018, at 5:27 PM, Francis Dupont  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
> 
> .
> 
> Document: draft-ietf-netmod-syslog-model-21.txt
> Reviewer: Francis Dupont
> Review Date: 20180225
> IETF LC End Date: 20180228
> IESG Telechat date: unknown
> 
> Summary: Ready
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits/editorial comments: 
> (I took my notes on version 21 but I have version 23 in front of me)
> 
> - ToC page 2 and 6 page 27 (title): Acknowledgements -> Acknowledgments
> 
> - 1 page 3: acknowledgement -> acknowledgement
> 
> - 4.1 page 10: do the same than 1.1 page 3: refer to RFC8174 too
>  for keywords.
> 
> - 4.1 page 18 (advanced-compare): spectify -> specify
> 
> - 4.1 page 23 (remote transport and tls) (twice):
>  specified: an ipv4 address, an ipv6 address, ipv4->IPv4 and ipv6->IPv6
> 
> - 6 page 27: there is no "and" between the two last names and no
>  final dot so I am afraid the list was truncated (BTW obviously iy is
>  not the case but please add a final dot, i.e.:
>  Aleksandr Zhdankin -> Aleksandr Zhdankin.
> 
> Note I trust the Yang tools to have checked the syntax.
> 
> Regards
> 
> francis.dup...@fdupont.fr
> 
> ___
> 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] Genart telechat review of draft-ietf-teas-rsvp-egress-protection-14

[Alissa Cooper]

Stewart, thanks for your reviews of this document. Huaimo, thanks for your 
responses. I have entered a No Objection ballot.

Alissa

> On Mar 5, 2018, at 4:44 PM, Huaimo Chen  wrote:
> 
> Hi Steward,
> 
>Thank you very much for your time and your valuable comments.
>We have updated the document to address the nits according to your 
> suggestions.
> 
> Best Regards,
> Huaimo
> -Original Message-
> From: Stewart Bryant [mailto:stewart.bry...@gmail.com] 
> Sent: Monday, March 05, 2018 2:32 PM
> To: gen-art@ietf.org
> Cc: draft-ietf-teas-rsvp-egress-protection@ietf.org; i...@ietf.org; 
> t...@ietf.org
> Subject: Genart telechat review of draft-ietf-teas-rsvp-egress-protection-14
> 
> Reviewer: Stewart Bryant
> Review result: Ready with Nits
> 
> 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-ietf-teas-rsvp-egress-protection-??
> Reviewer: Stewart Bryant
> Review Date: 2018-03-05
> IETF LC End Date: 2018-02-27
> IESG Telechat date: 2018-03-08
> 
> Summary: This is much improved since the earlier version I reviewed.
> 
> I do have a concern about the use of the term "egress" when I think that it 
> should be "egress node" or some such other network object.
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits/editorial comments:
> 
> The authors often use the term egress on its own when I think they mean 
> egress PE or egress node or egress LSR. If my English concern is correct, 
> this should be addressed before this goes to the RFC Editor else  Auth48 will 
> be a painful process for all concerned.
> 
> ___
> 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] [TLS] Genart last call review of draft-ietf-tls-tls13-24

[David Benjamin]

+1. If anything, the existing "buggy implementation" alert codes should get
folded together. (But I don't think it's worth making that change at this
stage either.) E.g. decode_error vs illegal_parameter vs
unexpected_message are rather useless distinctions and trying to get them
"right" adds complexity. Even with the granularity is it is, TLS's alert
codes needlessly expose benign differences in implementation strategy.
Adding even finer granularity would make all this worse.

My experience is also that this sort of thing would not actually help much.

On Tue, Mar 6, 2018 at 11:05 PM Eric Rescorla  wrote:

> Without taking a position on the security matter: this has been part of
> the TLS design for 20+ years, and therefore has had multiple LCs and WG and
> IETF consensus, so it would take a pretty strong set of arguments to change
> now. I've debugged a lot of TLS interop issues, and as a practical matter,
> I don't think this would help that much to justify making a change.
> -Ekr
>
>
> On Tue, Mar 6, 2018 at 2:35 PM, Colm MacCárthaigh 
> wrote:
>
>>
>>
>> On Fri, Mar 2, 2018 at 8:00 PM, Dale Worley  wrote:
>>
>>> - There are about 28 error codes but nearly 150 places where the text
>>>   require the connection to be aborted with an error -- and hence,
>>>   nearly 150 distinct constraints that can be violated.  There are 19
>>>   alone for "illegal_parameter".  I would like to see an "alert
>>>   extension value" which assigns a distinct "minor" code to each
>>>   statement in the text that requires an error response (with
>>>   implementations being allowed to be a bit sloppy in providing the
>>>   correct minor code).
>>>
>>
>> Your review is incredibly deep, comprehensive and I learned a lot from
>> it. I want to pick out just one small piece, but don't mean that to
>> diminish how thorough it was!
>>
>> On the specific suggestion of having more granular error codes, I think
>> this is a dangerous direction to take lightly; there's at least one
>> instance where granular TLS alert messages have directly led to security
>> issues by acting as oracles that aided the attacker.
>>
>> There's a general conjecture that the more information that is provided
>> to attackers, the more easily they can leverage into a compromise.
>> Personally I believe that conjecture, and would actually prefer to see
>> fewer signals, ideally as few as one big error code. There is a trade-off
>> against debugability, but I've only seen a handful of people have the
>> skills to debug low level TLS issues and it doesn't seem worth the risk.
>> Others disagree, which is valid, but it's at least an area of reasonable
>> contention.
>>
>> --
>> Colm
>>
>
> ___
> TLS mailing list
> t...@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art