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

[Donald Eastlake]

Hi Paul,

Version -09 has been uploaded with the intent that it resolve your comments.

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


On Tue, Jul 5, 2016 at 9:32 AM, Paul Kyzivat  wrote:
> On 7/4/16 11:35 PM, Donald Eastlake wrote:
>>
>> Hi Paul,
>>
>> I believe we are generally in agreement.
>>
>> On the table in the IANA Considerations, I have read
>> https://tools.ietf.org/html/draft-leiba-cotton-iana-5226bis-15#section-1.1
>> and I can understand why you commented as you did. But, since all the
>> table entries were created by IANA actions, I still think the draft is
>> OK in having that table in the IANA Considerations Section. This is
>> not a case of including some technical specification in with the IANA
>> Considerations.  It's still all code points.
>
>
> OK. It is not a big deal.
>
> Thanks,
> Paul
>
>
>> Thanks,
>> Donald
>> ===
>>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>  155 Beaver Street, Milford, MA 01757 USA
>>  d3e...@gmail.com
>>
>>
>> On Mon, Jul 4, 2016 at 6:50 PM, Paul Kyzivat 
>> wrote:
>>>
>>> Donald,
>>>
>>> On 7/4/16 5:26 PM, Donald Eastlake wrote:


 Hi Paul,

 Thanks for your comments. Sorry for the delay in response.
 Please see below.
>>>
>>>
>>>
>>> No problem. I was just concerned that my review hadn't been received.
>>>
>>>
 On Mon, Jun 27, 2016 at 6:46 PM, Paul Kyzivat 
 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-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.



 Right. How about

Addr Sets End: The unsigned integer byte number, within the IA
APPsub-TLV value part, of the last byte of the last Address Set,
where the first byte is numbered 1. This will be the number of the
byte just before ...
>>>
>>>
>>>
>>> OK. If you count starting from one. (I don't, but it is your draft.)
>>>
> (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.



 Yup, it say "IANA has allocated" because they are already allocated. See


 http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml
>>>
>>>
>>>
>>> OK.
>>>
> 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.



 I disagree. It's "IANA Considerations", not "IANA Allocation Actions".
 Someone looking for code points is likely look in the IANA
 Considerations section.  All the values shown are from the same IANA
 registry.  I can see no advantage to splitting this table between two
 different parts of the draft.
>>>
>>>
>>>
>>> When I wrote this comment I had in mind the following that I recently
>>> read:
>>>
>>>
>>> https://tools.iet

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

[Peter Yee]

Draft -10 has just been published and it addresses my concerns.  So:

Summary: This draft is ready for publication as a Proposed Standard. [Ready]

-Peter

-Original Message-
From: Peter Yee [mailto:pe...@akayla.com] 
Sent: Tuesday, July 05, 2016 1:07 PM
To: draft-ietf-trill-channel-tunnel@ietf.org
Cc: gen-art@ietf.org; i...@ietf.org
Subject: Gen-ART Telechat review of draft-ietf-trill-channel-tunnel-09

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

The nits noted in the Last Call review will be addressed in a new version of
the draft, as already discussed with one of the authors.  This review is
posted in order to make the Telechat deadline, as the date for the next
draft is not known to this reviewer.  The previous (Last Call) review can be
found here:
https://www.ietf.org/mail-archive/web/gen-art/current/msg13423.html


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

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

[Pierre-Anthony Lemieux]

Hi Vijay,

A revised I-D that adds a note under "Rules for Lexical Equivalence"
is available at [1].

[1] https://www.ietf.org/id/draft-pal-eidr-urn-2016-02.txt

Best,

-- Pierre

On Tue, Jul 5, 2016 at 10:25 AM, Pierre-Anthony Lemieux
 wrote:
> Hi Vijay,
>
>> I will appreciate if the "including 'urn:eidr:'" part made it into the draft.
>
> Ok.
>
> BTW, should I plan on creating a new I-D before the scheduled
> telechat, or after?
>
> Thanks,
>
> -- Pierre
>
> On Tue, Jul 5, 2016 at 10:21 AM, Vijay K. Gurbani  wrote:
>> Pierre: Thank you for attending to my comment.  More inline.
>>
>> On 07/02/2016 03:30 PM, Pierre-Anthony Lemieux wrote:
>>>
>>> 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:".
>>
>>
>> I will appreciate if the "including 'urn:eidr:'" part made it into the
>> draft.  Implementers have varying level understanding as they attempt
>> to divine RFC text.  So to the extent that we can make our intent
>> explicit with a few additional strokes of the pen (or the keyboard), we
>> are all the more better off for it.
>>
>> Cheers,
>>
>> - vijay
>> --
>> Vijay K. Gurbani, Bell Laboratories, Nokia Networks
>> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
>> Email: v...@bell-labs.com / vijay.gurb...@nokia-bell-labs.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 review of draft-holmberg-dispatch-rfc7315-updates

[Ralph Droms]

I am the assigned Gen-ART reviewer for this draft. The General AreaReview Team (Gen-ART) reviews all IETF documents being processedby the IESG for the IETF Chair.  Please treat these comments justlike any other last call comments.For more information, please see the FAQ at.Document: draft-holmberg-dispatch-rfc7315-updates-07Reviewer: Ralph DromsReview Date: 2016-07-05IETF LC End Date: 2016-07-18IESG Telechat date: Summary: This draft is basically ready for publication, but has nits that should be fixed before publication.Major issues: NoneMinor issues:I had some difficulty unraveling the relationship among the text in section 3.3.2, 3.3.3, 4 and RFC 7315.  Section 3.3.2 specifies the inclusion of the NPLI option in the P-Access-Network-Info header field.  Section 4 does not include text about the NPLI option in the updates to RFC 7315, and I can't find any reference to the NPLI option in RFC 7315.  Is the intention that the text in section 3.3.2 constitutes new Internet Standard behavior, not reflected in the update to RFC 7315, am I missing something or am I completely confused?Section 3.3.3 specifies the inclusion of the IOI option in the P-Charging-Vector header field.  In this case, I am not sure if this specification represents a change to  existing text in RFC 7315 or new behavior.I would be happy to hear that I am completely confused; otherwise, I suggest some text be added to clarify that sections 3.3.2 and 3.3.3 also specify some behaviors in addition to explaining the text in section 4.Nits/editorial comments:In section 3.2, it would reduce potential confusion to consistently name the header field referenced in each bullet; e.g.:OLD:  o  P-Called-Party-ID: Delete statement that the header field can appear in SIP responses.  Add statement that the P-Called-Party-ID header field can appear in the SIP REFER method.NEW:  o  P-Called-Party-ID: Delete statement that the P-Called-Party-ID header field can appear in SIP responses.  Add statement that the P-Called-Party-ID header field can appear in the SIP REFER method.Section 3.3.1:OLD:  This following sections describe, for individual P- header fields,  the 3GPP use-cases that are base for the updates.NEW:  The following sections describe, for individual P- header fields,  the 3GPP use-cases that are the basis for the updates.Section 3.3.2: uniformly capitalize "Network Provided Location Information".Section 3.3.2: 3GPP TS 23.228 needs a citation of the referenced document.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Donald Eastlake]

Hi Peter,

Version -10 has been uploaded with the intent of resolved your GENART
review comments.

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


On Tue, Jul 5, 2016 at 4:06 PM, 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 wait for direction from your document shepherd or AD
> before posting a new version of the draft.  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.
>
> The nits noted in the Last Call review will be addressed in a new version of
> the draft, as already discussed with one of the authors.  This review is
> posted in order to make the Telechat deadline, as the date for the next
> draft is not known to this reviewer.  The previous (Last Call) review can be
> found here:
> https://www.ietf.org/mail-archive/web/gen-art/current/msg13423.html
>
>

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

[Gen-art] Review: draft-ietf-nfsv4-scsi-layout-06.txt

[Joel M. Halpern]

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-nfsv4-scsi-layout-06.txt
Parallel NFS (pNFS) SCSI Layout
Reviewer: Joel M. Halpern
Review Date: 5-July-2016
IETF LC End Date: 12-July-2016
IESG Telechat date: N/A

Summary: This document is ready for publication as a Proposed Standard.

The reviewer notes that he fouund the document quite readable, but 
nonetheless made no effort to review the storage details.


Major issues:

Minor issues:

Nits/editorial comments:
It seems likely that the cross-reference in section 3.3 paragraph 1 
which points to section 2.1 is actually intended to point to section 3.1


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

[Gen-art] Gen-ART Telechat 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 wait for direction from your document shepherd or AD
before posting a new version of the draft.  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.

The nits noted in the Last Call review will be addressed in a new version of
the draft, as already discussed with one of the authors.  This review is
posted in order to make the Telechat deadline, as the date for the next
draft is not known to this reviewer.  The previous (Last Call) review can be
found here:
https://www.ietf.org/mail-archive/web/gen-art/current/msg13423.html


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

[Gen-art] A *new* batch of IETF LC reviews - 2016-07-05

[A. Jean Mahoney]

Hi all,

The following reviewers have assignments:

Reviewer  LC end  Draft
-
Russ Housley  2016-07-29  draft-sweet-rfc2911bis-09


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 updated template is included below.

Thanks,

Jean

---

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

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

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

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

[Pierre-Anthony Lemieux]

Hi Alexey,

Will do.

Best,

-- Pierre

On Tue, Jul 5, 2016 at 10:35 AM, Alexey Melnikov
 wrote:
> Hi,
>
> On 05/07/2016 18:25, Pierre-Anthony Lemieux wrote:
>>
>> Hi Vijay,
>>
>>> I will appreciate if the "including 'urn:eidr:'" part made it into the
>>> draft.
>>
>> Ok.
>>
>> BTW, should I plan on creating a new I-D before the scheduled
>> telechat, or after?
>
> You can post a new version any time. Before the telechat would be slightly
> better.
>
>> Thanks,
>>
>> -- Pierre
>>
>> On Tue, Jul 5, 2016 at 10:21 AM, Vijay K. Gurbani 
>> wrote:
>>>
>>> Pierre: Thank you for attending to my comment.  More inline.
>>>
>>> On 07/02/2016 03:30 PM, Pierre-Anthony Lemieux wrote:

 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:".
>>>
>>>
>>> I will appreciate if the "including 'urn:eidr:'" part made it into the
>>> draft.  Implementers have varying level understanding as they attempt
>>> to divine RFC text.  So to the extent that we can make our intent
>>> explicit with a few additional strokes of the pen (or the keyboard), we
>>> are all the more better off for it.
>>>
>>> Cheers,
>>>
>>> - vijay
>>> --
>>> Vijay K. Gurbani, Bell Laboratories, Nokia Networks
>>> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
>>> Email: v...@bell-labs.com / vijay.gurb...@nokia-bell-labs.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

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

[Alexey Melnikov]

Hi,

On 05/07/2016 18:25, Pierre-Anthony Lemieux wrote:

Hi Vijay,


I will appreciate if the "including 'urn:eidr:'" part made it into the draft.

Ok.

BTW, should I plan on creating a new I-D before the scheduled
telechat, or after?
You can post a new version any time. Before the telechat would be 
slightly better.

Thanks,

-- Pierre

On Tue, Jul 5, 2016 at 10:21 AM, Vijay K. Gurbani  wrote:

Pierre: Thank you for attending to my comment.  More inline.

On 07/02/2016 03:30 PM, Pierre-Anthony Lemieux wrote:

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


I will appreciate if the "including 'urn:eidr:'" part made it into the
draft.  Implementers have varying level understanding as they attempt
to divine RFC text.  So to the extent that we can make our intent
explicit with a few additional strokes of the pen (or the keyboard), we
are all the more better off for it.

Cheers,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: v...@bell-labs.com / vijay.gurb...@nokia-bell-labs.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

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

[Pierre-Anthony Lemieux]

Hi Vijay,

> I will appreciate if the "including 'urn:eidr:'" part made it into the draft.

Ok.

BTW, should I plan on creating a new I-D before the scheduled
telechat, or after?

Thanks,

-- Pierre

On Tue, Jul 5, 2016 at 10:21 AM, Vijay K. Gurbani  wrote:
> Pierre: Thank you for attending to my comment.  More inline.
>
> On 07/02/2016 03:30 PM, Pierre-Anthony Lemieux wrote:
>>
>> 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:".
>
>
> I will appreciate if the "including 'urn:eidr:'" part made it into the
> draft.  Implementers have varying level understanding as they attempt
> to divine RFC text.  So to the extent that we can make our intent
> explicit with a few additional strokes of the pen (or the keyboard), we
> are all the more better off for it.
>
> Cheers,
>
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Nokia Networks
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
> Email: v...@bell-labs.com / vijay.gurb...@nokia-bell-labs.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

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

[Vijay K. Gurbani]

Pierre: Thank you for attending to my comment.  More inline.

On 07/02/2016 03:30 PM, Pierre-Anthony Lemieux wrote:

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


I will appreciate if the "including 'urn:eidr:'" part made it into the
draft.  Implementers have varying level understanding as they attempt
to divine RFC text.  So to the extent that we can make our intent
explicit with a few additional strokes of the pen (or the keyboard), we
are all the more better off for it.

Cheers,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: v...@bell-labs.com / vijay.gurb...@nokia-bell-labs.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 Last Call review of draft-ietf-nfsv4-multi-domain-fs-reqs-09

[Brian E Carpenter]

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-nfsv4-multi-domain-fs-reqs-09.txt
Reviewer: Brian Carpenter
Review Date: 2016-07-05
IETF LC End Date: 2016-07-06
IESG Telechat date:

Summary: Ready with issues


Comment: I was asked to review -08 but found -09 has been posted, with
 considerable changes, during Last Call.


Minor issues:
-

"This document provides guidance on the deployment of..."

Sounds more like a BCP than a Proposed Standard to me. As I read through the
document, it describes alternatives and differing scenarios. That also seems
like BCP to me. One example:

> 7.  Resolving Multi-domain Authorization Information
>
>   When an RPCSEC_GSS principal is seeking access to files on an NFSv4
>   server, after authenticating the principal, the server must obtain in
>   a secure manner the principal's authorization context information
>   from an authoritative source such as the name service in the
>   principal's NFSv4 Domain.

That's underspecified for a standard but perfect for a description of
best practice.

The choices between lower-case and upper-case "must" seem fairly arbitrary.
There are only 5 instances of "MUST" and one "REQUIRED". Maybe this document 
just
doesn't need RFC2119 keywords?

  ** Downref: Normative reference to an Informational RFC: RFC 1813

This reference was added in the -09 version. I believe it should be
Informative instead of Normative. If not, a new Last Call mentioning
the downref is necessary.

  ** Obsolete normative reference: RFC 1831 (Obsoleted by RFC 5531)

This needs to be fixed.

___
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-ice-dualstack-fairness-03

[Meral Shirazipour]

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-ice-dualstack-fairness-03
Reviewer: Meral Shirazipour
Review Date: 2016-07-05
IETF LC End Date:  2016-07-08
IESG Telechat date: NA


Summary:
This draft is ready to be published as BCP RFC but I have some comments.

Major issues:

Minor issues:

Nits/editorial comments:
-[Page 2], "arguable be better">"arguably be better"
-[Page 2], "types know">"types known"
-[Page 8], Section 7.1 and 7.2 have the same title, is that by choice?
-[Page 9], Section 10.1, first reference ([I-D.ietf-ice-rfc5245bis])to be 
updated to latest version.
-Also on [Page 4] Reference to "section 4.1.2.1" of [I-D.ietf-ice-rfc5245bis], 
it would be good to list the section title too (in case the numbering changes 
in the final version).

Best Regards,
Meral
---
Meral Shirazipour
Ericsson Research
www.ericsson.com
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Paul Kyzivat]

On 7/4/16 11:35 PM, Donald Eastlake wrote:

Hi Paul,

I believe we are generally in agreement.

On the table in the IANA Considerations, I have read
https://tools.ietf.org/html/draft-leiba-cotton-iana-5226bis-15#section-1.1
and I can understand why you commented as you did. But, since all the
table entries were created by IANA actions, I still think the draft is
OK in having that table in the IANA Considerations Section. This is
not a case of including some technical specification in with the IANA
Considerations.  It's still all code points.


OK. It is not a big deal.

Thanks,
Paul


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


On Mon, Jul 4, 2016 at 6:50 PM, Paul Kyzivat  wrote:

Donald,

On 7/4/16 5:26 PM, Donald Eastlake wrote:


Hi Paul,

Thanks for your comments. Sorry for the delay in response.
Please see below.



No problem. I was just concerned that my review hadn't been received.



On Mon, Jun 27, 2016 at 6:46 PM, Paul Kyzivat 
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-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.



Right. How about

   Addr Sets End: The unsigned integer byte number, within the IA
   APPsub-TLV value part, of the last byte of the last Address Set,
   where the first byte is numbered 1. This will be the number of the
   byte just before ...



OK. If you count starting from one. (I don't, but it is your draft.)


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



Yup, it say "IANA has allocated" because they are already allocated. See

http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml



OK.


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.



I disagree. It's "IANA Considerations", not "IANA Allocation Actions".
Someone looking for code points is likely look in the IANA
Considerations section.  All the values shown are from the same IANA
registry.  I can see no advantage to splitting this table between two
different parts of the draft.



When I wrote this comment I had in mind the following that I recently read:

https://tools.ietf.org/html/draft-leiba-cotton-iana-5226bis-15#section-1.1


(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