Re: [Gen-art] Gen-ART LC review of draft-ietf-trill-channel-tunnel-09

[Peter Yee]

Donald,

>> For cases of "[RFC5310] Based authentication" to "[RFC5310]-based 
>> authentication".  Watch for one instance of "RFC 5310 Based" as well.

>OK.

>(Nit-Nit: I think in the nit above, the first word should be Four.)

Ha!  (I hadn't actually counted the number of cases. )

>> Page 12, 1st paragraph, 2nd sentence: change "These constructed addresses"
>> to "A constructed address".

>Humm. I don't really like your suggested change. How about I change it to 
>"Such a constructed address ..."

Fine by me.

>> Page 21, Section 7, 3rd paragraph, 2nd sentence: delete "processing 
>> of".  Or change "processing" to "process".

>Instead, change the immediately following "decapsulating" to "decapsulated".

That works as well.

Thanks for considering my suggestions.

-Peter

___
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-trill-channel-tunnel-09

[Donald Eastlake]

Hi Peter,

Thanks for your thorough review. See below.

On Sat, Jul 2, 2016 at 2:33 AM, Peter Yee  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
> comment.  For background on Gen-ART, please see the FAQ at
> 
>
> Document: draft-ietf-trill-channel-tunnel-09
> Reviewer: Peter Yee
> Review Date: July 1, 2016
> IETF LC End Date: July  1, 2016
> IESG Telechat date: July 7, 2016
>
> Summary: This draft is basically ready for publication as a Proposed
> Standard, but has some nits that should be fixed before publication. [Ready
> with nits]
>
> This draft extends TRILL RBridge Channels so that they can transmit
> additional, tunneled message types.  Security services for RBridge Channel
> messages can be provisioned via RFC 5310 authentication and/or DTLS.  The
> draft is well-written and easy to understand in the larger TRILL context.
>
> Major issues: None
>
> Minor issues: None
>
> Nits:
>
> General:
>
> For cases of "[RFC5310] Based authentication" to "[RFC5310]-based
> authentication".  Watch for one instance of "RFC 5310 Based" as well.

OK.

(Nit-Nit: I think in the nit above, the first word should be Four.)

> Specific:

All of the following are OK unless noted otherwise right after that nit:

> Page 3, Section 1, 1st paragraph, last sentence: delete the comma following
> "link".
>
> Page 4, "HKDF" definition: Change "Hash based" to "HMAC-based".
>
> Page 4, "MTU" definition: add a period at the end of the definition for
> consistency.
>
> Page 4, "Sz" definition: change "Campus wide" to "Campus-wide".
>
> Page 6, 1st full paragraph, 1st sentence: suggest changing "RBridge Channel
> Extension Protocol" to "Extended RBridge Channel Protocol" as this is the
> usage throughout the rest of the document.
>
> Page 8, Section 3.1, 3rd sentence: insert "tunneled" before "data".  I hope
> this will help clarity when referring back to Figure 2.4 which includes
> "Tunneled Data".
>
> Page 8, Section 3.2, 1st sentence: append "(tunneled data)" after "payload".
> This is done for the same reason, although I'm not recommending doing this
> for all further occurrences of "payload" in other sections as I hope the
> connection is made by that point.
>
> Page 12, 1st paragraph, 1st sentence: change "link local" to "link-local".
>
> Page 12, 1st paragraph, 2nd sentence: change "These constructed addresses"
> to "A constructed address".

Humm. I don't really like your suggested change. How about I change it
to "Such a constructed address ..."

> Page 14, Section 4, 2nd paragraph, 1st sentence: change "use" to "used".
>
> Page 14, Section 4, 3rd paragraph, 1st sentence: change "DTLS based" to
> "DTLS-based".
>
> Page 14, Section 4, 4th paragraph, 2nd sentence: change "data accessible" to
> "data-accessible".
>
> Page 15, 1st partial paragraph, last sentence: insert "the" before
> "output-derived".
>
> Page 16, 1st bullet item: change "or" to "on".
>
> Page 17, 1st paragraph: delete the comma after "keying".
>
> Page 18, 2nd full paragraph, last sentence: change "secuirty" to "security".
>
> Page 20, Section 6.2, 1st paragraph: change "a" to "an".
>
> Page 21, Section 7, 3rd paragraph, 2nd sentence: delete "processing of".  Or
> change "processing" to "process".

Instead, change the immediately following "decapsulating" to "decapsulated".

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

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

[Gen-art] Gen-ART Last Call review of draft-ietf-trill-ia-appsubtlv [RESEND]

[Paul Kyzivat]

[Resending in case it wasn't received, since I have received no replies.]

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-trill-ia-appsubtlv
Reviewer: Paul Kyzivat
Review Date: 2016-06-27
IETF LC End Date: 2016-06-28
IESG Telechat date: 2016-07-07

Summary:

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


This is a well written document. I was generally able to follow it even 
though I know nothing about the subject.


Issues:

Major: 0
Minor: 7
Nits:  2

(1) MINOR: (Section 2)

"Addr Sets End" is described as follows:

o  Addr Sets End: The unsigned integer offset of the byte, within the
   IA APPsub-TLV value part, of the last byte of the last Address
   Set. This will be the byte just before the first sub-sub-TLV if
   any sub-sub-TLVs are present ...

But the remaining text of this section, and the examples, imply that 
this is really the length of the leading portion of this TLV ending with 
the last Address Set. The programmer in me says these differ by one, and 
that the implied definition is the reasonable one, while the action 
definition, and the name used to identify it, are wrong.


I expect it would be difficult at this point to rename this field, but 
at least the definition can be rewritten to be consistent with the 
intended usage.


(2) MINOR: (Section 5.1)

Normally I would expect this section to request IANA to assign new 
values from the AFN table for OUI...RBridge Port ID. However it is 
worded as "IANA has allocated". Perhaps this is because they have 
already been (pre)allocated. I have no problem with that if IANA is OK 
with it.


But IMO the references to IPv4...64-bit MAC are gratuitous and 
inappropriate in an IANA Considerations section. If it is desired to 
include a list of "useful" AFN values then that belongs in some other 
portion of the document.


(3) MINOR: (Section 5.1)

The "new" values here (OUI, MAC/24, MAC/40, IPv6/64) give "This 
document" as their reference. But anyone consulting the IANA registry 
and following it to this document would have difficulty finding any 
*definition* of these things.


Section 6 discusses some operational issues with them, but at best 
implies a definition. (RFC7042 might be considered a definition of OUI, 
though it doesn't seem to say how big it would be.)


I think what is needed are explicit definitions of all of these, 
including their widths. (In order to provide enough bits to complete a 
MAC/24 it must be at least 24 bits wide, but that would be bigger than 
needed for a MAC/40. So I guess it must be at least 24 bits, and when 
used to expand a MAC/24 or MAC/40 an appropriate number of its high 
order bits are used.)


It would be good for there to be a section, appearing in the TOC, for 
each of these so that someone coming here from the IANA registry will 
easily be able to find the definition.


(4) MINOR: (Section 5.2)

This section defines a new registry with Expert Review as the procedure 
for approving new entries. What I don't see is any guidance to the 
expert on appropriate criteria to use to judge suitability of new 
entries. Without any guidance, relying on the whim of the expert can 
lead to variable, and perhaps biased, results.


It would be good to give guidance on: what sorts of document reference 
are acceptable, what information needs to be included in the reference 
document, whether "special" values may be requested (versus just 
assignment in order requests are received), and the sorts of properties 
that are appropriate.


(5) MINOR: (Section 6)

This section talks about the handling of OUI and IPv6/64 when they 
appear in a Fixed Address sub-sub-TLV. It says nothing about their 
meaning if these appear elsewhere, such as in a Template. I presume this 
kind of usage is nonsense, but it would be better to explicitly state it.


(6) MINOR: (Section 6)

The description of IPv6/64 says:

For this purpose, an 48-bit MAC address is expanded to 64
bits as described in [RFC7042].

It wasn't entirely apparent to me what part of 7042 covers that. It 
would be helpful to provide the section where this aspect is specified. 
(After some study I guess that it is section 2.2.1.)


(7) MINOR: (Section A.2)

I believe that the values of both 'Length' and 'Address Sets End' are 
too small by 7 - presumably because they forgot to count the fixed 
fields. This also applies to the "alternative" using explict AFN encoding.


(8) NIT: (Section A.2)

Based on a very quick reading, ISTM that section 2.2.1 of 7042 suggests 
that the IPv6 addresses being constructed this way should start with 
0x02 rather than 0x20. But I'm far from sure I understand this 

Re: [Gen-art] Gen-ART review of draft-pal-eidr-urn-2016-01

[Pierre-Anthony Lemieux]

Hi Vijay,

I appreciate the review and comment.

> That is, are the schemes (urn, eidr) part of the case-insensitive string 
> match?

Yes, it looks like

"Lexical equivalence of EIDR-URN is defined by case-insensitive string match."

should say

"Lexical equivalence of URN-EIDR is defined by case-insensitive string match."

This would confirm that the entire URN-EIDR string defined in
"Declaration of syntactic structure" is considered for matching,
including "urn:eidr:".

In fact, it looks like all instances of "EIDR-URN" should be replaced
by "URN-EIDR" [ed.: this was missed in the original publication].

Does this make sense?

Best,

-- Pierre

On Thu, Jun 9, 2016 at 3:01 PM, Vijay K. Gurbani  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-pal-eidr-urn-2016-01
> Reviewer: Vijay K. Gurbani
> Review Date: Jun-09-2016
> IETF LC End Date: Jul-01-2016
> IESG Telechat date: Jun-30-2016
>
> This document is ready as an Informational.
>
> Major: 0
> Minor: 1
> Nits: 0
>
> Minor:
>
> - S2, Rules for Lexical Equivalence.  I think some more guidance should
>  be provided here.  Specifically, are the following two EIDRs the same?
>
>   urn:eidr:10.5240:7791-8534-2C23-9030-8610-5
>   10.5240:7791-8534-2C23-9030-8610-5
>
>  That is, are the schemes (urn, eidr) part of the case-insensitive
>  string match?
>
> Thanks,
>
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Nokia Networks
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
> Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@nokia.com
> Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

___
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-trill-channel-tunnel-09

[Peter Yee]

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
comment.  For background on Gen-ART, please see the FAQ at


Document: draft-ietf-trill-channel-tunnel-09
Reviewer: Peter Yee
Review Date: July 1, 2016
IETF LC End Date: July  1, 2016
IESG Telechat date: July 7, 2016

Summary: This draft is basically ready for publication as a Proposed
Standard, but has some nits that should be fixed before publication. [Ready
with nits]

This draft extends TRILL RBridge Channels so that they can transmit
additional, tunneled message types.  Security services for RBridge Channel
messages can be provisioned via RFC 5310 authentication and/or DTLS.  The
draft is well-written and easy to understand in the larger TRILL context.

Major issues: None

Minor issues: None

Nits:

General:

For cases of "[RFC5310] Based authentication" to "[RFC5310]-based
authentication".  Watch for one instance of "RFC 5310 Based" as well.

Specific:

Page 3, Section 1, 1st paragraph, last sentence: delete the comma following
"link".

Page 4, "HKDF" definition: Change "Hash based" to "HMAC-based".

Page 4, "MTU" definition: add a period at the end of the definition for
consistency.

Page 4, "Sz" definition: change "Campus wide" to "Campus-wide".

Page 6, 1st full paragraph, 1st sentence: suggest changing "RBridge Channel
Extension Protocol" to "Extended RBridge Channel Protocol" as this is the
usage throughout the rest of the document.

Page 8, Section 3.1, 3rd sentence: insert "tunneled" before "data".  I hope
this will help clarity when referring back to Figure 2.4 which includes
"Tunneled Data".

Page 8, Section 3.2, 1st sentence: append "(tunneled data)" after "payload".
This is done for the same reason, although I'm not recommending doing this
for all further occurrences of "payload" in other sections as I hope the
connection is made by that point.

Page 12, 1st paragraph, 1st sentence: change "link local" to "link-local".

Page 12, 1st paragraph, 2nd sentence: change "These constructed addresses"
to "A constructed address".

Page 14, Section 4, 2nd paragraph, 1st sentence: change "use" to "used".

Page 14, Section 4, 3rd paragraph, 1st sentence: change "DTLS based" to
"DTLS-based".

Page 14, Section 4, 4th paragraph, 2nd sentence: change "data accessible" to
"data-accessible".

Page 15, 1st partial paragraph, last sentence: insert "the" before
"output-derived".

Page 16, 1st bullet item: change "or" to "on".

Page 17, 1st paragraph: delete the comma after "keying".

Page 18, 2nd full paragraph, last sentence: change "secuirty" to "security".

Page 20, Section 6.2, 1st paragraph: change "a" to "an".

Page 21, Section 7, 3rd paragraph, 2nd sentence: delete "processing of".  Or
change "processing" to "process".


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