Re: [Gen-art] Genart telechat review of draft-ietf-ace-cbor-web-token-12

[Dan Romascanu]

Hi Jim,

See also Section 4.12 in RFC 8126 for the use of multiple policies in
combination.

I believe that what the document tries to say is:

Register R is divided into four different ranges R1, R2, R3, R4 (defining
the value limits may be useful)

Values in range R1 are allocated according to policy P1 in the case that ...
Values in range R2 are allocated according to policy P2 in the case that ...
Values in range R3 are allocated according to policy P3 in the case that ...
Values in range R4 are allocated according to policy P4 in the case that ...

Regards,

Dan




On Tue, Feb 27, 2018 at 8:44 AM, Dan Romascanu  wrote:

>
>
> On Mon, Feb 26, 2018 at 11:47 PM, Jim Schaad 
> wrote:
>
>>
>>
>>
>>
>> *From:* Dan Romascanu [mailto:droma...@gmail.com]
>> *Sent:* Monday, February 26, 2018 1:19 PM
>> *To:* Jim Schaad 
>> *Cc:* gen-art ; a...@ietf.org; ietf ;
>> draft-ietf-ace-cbor-web-token@ietf.org
>> *Subject:* Re: Genart telechat review of draft-ietf-ace-cbor-web-token-12
>>
>>
>>
>> Hi Jim,
>>
>> Thank you for your answer and for addressing my comments.
>>
>> On item #2:
>>
>>
>>
>> On Mon, Feb 26, 2018 at 10:12 PM, Jim Schaad 
>> wrote:
>>
>>
>>
>> > -Original Message-
>> > From: Dan Romascanu [mailto:droma...@gmail.com]
>> >
>>
>>
>>
>> ...
>>
>> >
>> > 2. I am a little confused by the definition of policies in Section 9.1:
>> >
>> >Depending upon the values being requested, registration requests are
>> >evaluated on a Standards Track Required, Specification Required,
>> >Expert Review, or Private Use basis [RFC8126] after a three-week
>> >review period on the cwt-reg-rev...@ietf.org mailing list, on the
>> >advice of one or more Designated Experts.
>> >
>> > How does this work? The request is forwarded to the designated expert,
>> > he/she make a recommendation concerning the policy on the mail list, and
>> > depending on the feedback received a policy is selected? Who establishes
>> > consensus?
>> >
>> > Frankly, I wonder if this can work at all. Are there other examples of
>> four
>> > different policies for the same registry, applied on a case-to-case
>> basis?
>>
>> This is the same approach that is being used for the COSE registries.  As
>> an example, you can look at https://www.iana.org/assignmen
>> ts/cose/cose.xhtml#algorithms.
>>
>> Part of the issue about this is that the JOSE/JWT registries do have the
>> same different policies, but that differences are hidden from the IANA
>> registry.  Since they allow for a URI to be used as the identifier of a
>> field, only the plain text versions are registered.  Thus I can use "
>> http://augustcellars.com/JWT/My_Tag"; as an identifier.  Since for CBOR
>> the set of tag values is closed and does not have this escape (nor would
>> one want the length of the tag) it is necessary to have this break down of
>> tag fields.
>>
>>
>>
>>
>> This does not seem to be exactly the same approach. The COSE RFC 8152
>> defines the registry policy in a different manner. There is only one policy
>> that is proposed 'Expert Review' and than the Expert Review Instructions
>> are used to define the cases when a Standards Track specification is
>> required. No such text exists in the current I-D. There is no separation of
>> the values space in the registry according to the type of assignment here,
>> as  in RFC 8152.
>>
>>
>>
>> [JLS] The policies look to be the same to me, but I may be missing
>> something that you are seeing..  Remember that Specification Required
>> implies Expert review.
>>
>>
>>
>> Hi Jim,
>
> You seem to miss the exact definition of policies. Please see RFC 8126,
> Section 4. Expert Review and Specification Required are two different
> policies, even if one implies the other. Your document defines multiple
> policies for the same registry, without making clear which is to be used
> and when. This is unusual.
>
> Regards,
>
> Dan
>
>
>
>
___
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-ace-cbor-web-token-12

[Dan Romascanu]

On Mon, Feb 26, 2018 at 11:47 PM, Jim Schaad  wrote:

>
>
>
>
> *From:* Dan Romascanu [mailto:droma...@gmail.com]
> *Sent:* Monday, February 26, 2018 1:19 PM
> *To:* Jim Schaad 
> *Cc:* gen-art ; a...@ietf.org; ietf ;
> draft-ietf-ace-cbor-web-token@ietf.org
> *Subject:* Re: Genart telechat review of draft-ietf-ace-cbor-web-token-12
>
>
>
> Hi Jim,
>
> Thank you for your answer and for addressing my comments.
>
> On item #2:
>
>
>
> On Mon, Feb 26, 2018 at 10:12 PM, Jim Schaad 
> wrote:
>
>
>
> > -Original Message-
> > From: Dan Romascanu [mailto:droma...@gmail.com]
> >
>
>
>
> ...
>
> >
> > 2. I am a little confused by the definition of policies in Section 9.1:
> >
> >Depending upon the values being requested, registration requests are
> >evaluated on a Standards Track Required, Specification Required,
> >Expert Review, or Private Use basis [RFC8126] after a three-week
> >review period on the cwt-reg-rev...@ietf.org mailing list, on the
> >advice of one or more Designated Experts.
> >
> > How does this work? The request is forwarded to the designated expert,
> > he/she make a recommendation concerning the policy on the mail list, and
> > depending on the feedback received a policy is selected? Who establishes
> > consensus?
> >
> > Frankly, I wonder if this can work at all. Are there other examples of
> four
> > different policies for the same registry, applied on a case-to-case
> basis?
>
> This is the same approach that is being used for the COSE registries.  As
> an example, you can look at https://www.iana.org/
> assignments/cose/cose.xhtml#algorithms.
>
> Part of the issue about this is that the JOSE/JWT registries do have the
> same different policies, but that differences are hidden from the IANA
> registry.  Since they allow for a URI to be used as the identifier of a
> field, only the plain text versions are registered.  Thus I can use "
> http://augustcellars.com/JWT/My_Tag"; as an identifier.  Since for CBOR
> the set of tag values is closed and does not have this escape (nor would
> one want the length of the tag) it is necessary to have this break down of
> tag fields.
>
>
>
>
> This does not seem to be exactly the same approach. The COSE RFC 8152
> defines the registry policy in a different manner. There is only one policy
> that is proposed 'Expert Review' and than the Expert Review Instructions
> are used to define the cases when a Standards Track specification is
> required. No such text exists in the current I-D. There is no separation of
> the values space in the registry according to the type of assignment here,
> as  in RFC 8152.
>
>
>
> [JLS] The policies look to be the same to me, but I may be missing
> something that you are seeing..  Remember that Specification Required
> implies Expert review.
>
>
>
> Hi Jim,

You seem to miss the exact definition of policies. Please see RFC 8126,
Section 4. Expert Review and Specification Required are two different
policies, even if one implies the other. Your document defines multiple
policies for the same registry, without making clear which is to be used
and when. This is unusual.

Regards,

Dan
___
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-ace-cbor-web-token-12

[Benjamin Kaduk]

On Mon, Feb 26, 2018 at 11:03:07AM -0800, Dan Romascanu wrote:
> 
> 1. CWT is derived from JWT (RFC 7519) using CBOR rather than JSON for 
> encoding.
> The rationale as explained in the document is related to efficiency for some
> IoT systems. The initial claims registry defined in Section 9.1 is identical
> (semantically) with the initial claims registry defined in Section 10.1 of RFC
> 7519. Is this parallelism supposed to continue? If the two registries will
> continue to evolve in parallel, maybe there should be a mechanism at IANA to
> make this happen. Was this discussed by the WG? Maybe there is a need to
> include some text about the relationship between the two registries.

The shepherd writeup includes a note to the IESG recommending that
there be overlap between the experts for the CWT and JWT registries:

  Since near-total overlap is expected between the CWT and JWT
  registry contents, overlap in the corresponding pools of Experts
  would be useful, to help ensure that the appropriate amount of
  overlap between the registries is maintained.

So I expect that the right thing will happen in practice, though
you're probably right that having some text in the document itself
(and the registry template as well) would be a good safety net.

-Benjamin

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

Re: [Gen-art] [Ace] Genart telechat review of draft-ietf-ace-cbor-web-token-12

[Benjamin Kaduk]

On Mon, Feb 26, 2018 at 11:19:04PM +0200, Dan Romascanu wrote:
> Hi Jim,
> 
> Thank you for your answer and for addressing my comments.
> 
> On item #2:
> 
> 
> 
> On Mon, Feb 26, 2018 at 10:12 PM, Jim Schaad  wrote:
> 
> >
> >
> > > -Original Message-
> > > From: Dan Romascanu [mailto:droma...@gmail.com]
> > >
> >
> > ...
> 
> > >
> > > 2. I am a little confused by the definition of policies in Section 9.1:
> > >
> > >Depending upon the values being requested, registration requests are
> > >evaluated on a Standards Track Required, Specification Required,
> > >Expert Review, or Private Use basis [RFC8126] after a three-week
> > >review period on the cwt-reg-rev...@ietf.org mailing list, on the
> > >advice of one or more Designated Experts.
> > >
> > > How does this work? The request is forwarded to the designated expert,
> > > he/she make a recommendation concerning the policy on the mail list, and
> > > depending on the feedback received a policy is selected? Who establishes
> > > consensus?
> > >
> > > Frankly, I wonder if this can work at all. Are there other examples of
> > four
> > > different policies for the same registry, applied on a case-to-case
> > basis?
> >
> > This is the same approach that is being used for the COSE registries.  As
> > an example, you can look at https://www.iana.org/
> > assignments/cose/cose.xhtml#algorithms.
> >
> > Part of the issue about this is that the JOSE/JWT registries do have the
> > same different policies, but that differences are hidden from the IANA
> > registry.  Since they allow for a URI to be used as the identifier of a
> > field, only the plain text versions are registered.  Thus I can use "
> > http://augustcellars.com/JWT/My_Tag"; as an identifier.  Since for CBOR
> > the set of tag values is closed and does not have this escape (nor would
> > one want the length of the tag) it is necessary to have this break down of
> > tag fields.
> >
> >
> >
> >
> This does not seem to be exactly the same approach. The COSE RFC 8152
> defines the registry policy in a different manner. There is only one policy
> that is proposed 'Expert Review' and than the Expert Review Instructions
> are used to define the cases when a Standards Track specification is
> required. No such text exists in the current I-D. There is no separation of
> the values space in the registry according to the type of assignment here,
> as  in RFC 8152.

The template in section 9.1.1 has the different policies for the
different integer ranges, under the 'Claim Key' section.  Kathleen
(IIRC) already noted that this should probably be repeated in the
introductory part of section 9.1 as well, and that will be done
before the document is sent to the IESG.

-Benjamin

___
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-trill-vendor-channel-00

[Donald Eastlake]

Hi Joel,

On Mon, Feb 26, 2018 at 1:24 PM, Joel Halpern  wrote:

> Reviewer: Joel Halpern
> Review result: 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 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-vendor-channel-00
> Reviewer: Joel Halpern
> Review Date: 2018-02-26
> IETF LC End Date: 2018-03-06
> IESG Telechat date: 2018-03-08
>
> Summary: This document is ready for publication as a Proposed Standard
>
> Major issues: N/A
>
> Minor issues: N/A
>
> Nits/editorial comments:
> Why does the acknowledgements say:
> "The document was prepared in raw nroff. All macros used were
> defined
> within the source file."
> ?
>

Why not? It's true. I've seen a number of draft with credit in them for MS
Word templates and the like. Shouldn't people know their are still drafts
being prepared with nroff?

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

Re: [Gen-art] Genart telechat review of draft-ietf-ace-cbor-web-token-12

[Jim Schaad]

 

 

From: Dan Romascanu [mailto:droma...@gmail.com] 
Sent: Monday, February 26, 2018 1:19 PM
To: Jim Schaad 
Cc: gen-art ; a...@ietf.org; ietf ; 
draft-ietf-ace-cbor-web-token@ietf.org
Subject: Re: Genart telechat review of draft-ietf-ace-cbor-web-token-12

 

Hi Jim,

Thank you for your answer and for addressing my comments. 

On item #2: 



 

On Mon, Feb 26, 2018 at 10:12 PM, Jim Schaad mailto:i...@augustcellars.com> > wrote:



> -Original Message-
> From: Dan Romascanu [mailto:droma...@gmail.com  ]
>

 

... 

>
> 2. I am a little confused by the definition of policies in Section 9.1:
>
>Depending upon the values being requested, registration requests are
>evaluated on a Standards Track Required, Specification Required,
>Expert Review, or Private Use basis [RFC8126] after a three-week
>review period on the cwt-reg-rev...@ietf.org 
>   mailing list, on the
>advice of one or more Designated Experts.
>
> How does this work? The request is forwarded to the designated expert,
> he/she make a recommendation concerning the policy on the mail list, and
> depending on the feedback received a policy is selected? Who establishes
> consensus?
>
> Frankly, I wonder if this can work at all. Are there other examples of four
> different policies for the same registry, applied on a case-to-case basis?

This is the same approach that is being used for the COSE registries.  As an 
example, you can look at 
https://www.iana.org/assignments/cose/cose.xhtml#algorithms.

Part of the issue about this is that the JOSE/JWT registries do have the same 
different policies, but that differences are hidden from the IANA registry.  
Since they allow for a URI to be used as the identifier of a field, only the 
plain text versions are registered.  Thus I can use 
"http://augustcellars.com/JWT/My_Tag"; as an identifier.  Since for CBOR the set 
of tag values is closed and does not have this escape (nor would one want the 
length of the tag) it is necessary to have this break down of tag fields.




 

This does not seem to be exactly the same approach. The COSE RFC 8152 defines 
the registry policy in a different manner. There is only one policy that is 
proposed 'Expert Review' and than the Expert Review Instructions are used to 
define the cases when a Standards Track specification is required. No such text 
exists in the current I-D. There is no separation of the values space in the 
registry according to the type of assignment here, as  in RFC 8152. 

 

[JLS] The policies look to be the same to me, but I may be missing something 
that you are seeing..  Remember that Specification Required implies Expert 
review.

Regards,

Dan

 

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

Re: [Gen-art] [6tisch] Genart telechat review of draft-ietf-6tisch-6top-protocol-09

[Brian E Carpenter]

Thanks, those changes look good.

Regards
   Brian

On 27/02/2018 05:31, Qin Wang wrote:
> Hi Bian,
> Thank you for your comments. Please see inline.
> 
> 
> 
> On Friday, February 23, 2018 6:11 PM, Brian E Carpenter 
>  wrote:
>  
> 
>  Hi Qin, see in line:
> 
> On 24/02/2018 04:16, Qin Wang wrote:
>> Hi Brian,
>> Thank you very much for your comments. Please see inline.
>>
>> On Monday, February 19, 2018 6:22 PM, Brian Carpenter 
>>  wrote: 
>>
>>   Reviewer: Brian Carpenter
>> Review result: Ready with Issues
>>
>> Gen-ART Last Call review of draft-ietf-6tisch-6top-protocol-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 treat these comments just
>> like any other last call comments.
>>
>> For more information, please see the FAQ at
>> .
>>
>> Document: draft-ietf-6tisch-6top-protocol-09.txt
>> Reviewer: Brian Carpenter
>> Review Date: 2018-02-20
>> IETF LC End Date: 2018-??-??
>> IESG Telechat date: 2018-03-06
>>
>> Summary: Ready with issues
>> 
>>
>> Comment:
>> 
>>
>> This is a Last Call review despite the subject field. When will the Last
>> Call be started?
>>
>> Major issues:
>> -
>>
>> In section 3.1.1 "2-step 6P Transaction" there seems to be a race condition
>> if A's timeout expires while B's Response is in flight. Can the 6top layer
>> prevent the L2 Ack being sent? (And similar race conditions seem to be
>> possible in the 3-step transaction.)
>>
>> [Qin] Firstly, sincethe L2 Ack is sent by L2 according to IEEE802.15.4, 6top 
>> layer cannot preventit happen. Secondly, the race condition described above 
>> unlikely happens,because it is required that “The value of the 6P Timeout 
>> should be larger thanthe longest possible time it can take for the exchange 
>> to finish.” (3.4.4)
> 
> I'm sorry but that sounds like magic. Then whole point of race conditions is 
> that
> they happen in *very* unlikely cases such as the exchange taking 10 times 
> normal
> for some reason. If it only happens one time in ten million it is still a 
> problem.
> So I think you need to state what happens - maybe the inconsistency will be
> discovered later? That's fine for something considered highly unlikely.
> [Qin] Add following textin both section 3.1.1 and 3.1.2
> In case a race conditionhappens during the communication, the TSCH schedule 
> of node A may becomeinconsistent with the TSCH schedule of node B. 6top 
> handles the schedule inconsistency in the way described in Section3.4.6.2
>>
>>> 3.4.3.  Concurrent 6P Transactions
>>>
>>>   Only a single 6P Transaction between two neighbors, in a given
>>>   direction, can take place at the same time.  That is, a node MUST NOT
>>>   issue a new 6P Request to a given neighbor before having received the
>>>   6P Response for a previous request to that neighbor, except when the
>>>   previous 6P Transaction has timed out.  If a node receives a 6P
>>>   Request from a given neighbor before having sent the 6P Response to
>>>   the previous 6P Request from that neighbor, it MUST send back a 6P
>>>   Response with a return code of RC_RESET (as per Figure 36).  A node
>>>   receiving RC_RESET code MUST abort the transaction and consider it
>>>   never happened.
>>
>> It isn't clear to me whether the RC_RESET aborts the first, the second,
>> or both transactions.
>>
>> [Qin] change textto “abort the second transaction”
> 
> OK! 
>> Minor issues:
>> -
>>
>>> 1.  Introduction
>> ...
>>>   6P
>>>   allows a node to communicate with a neighbor to add/delete TSCH cells
>>>   to one another.
>>
>> This sentence is almost unintelligible because of the sequence to...to...to.
>> Does it mean this?:
>>
>>   6P allows neighbours to add or delete TSCH cells in each other.
>>
>> [Qin] Because we want to emphasize that communication between two nodes is 
>> the way to add/deletecells, we change text to “6P allows a node to 
>> communicate with a neighbor toadd/delete TSCH cells in each other”
>  
> 
> OK, that will be less confusing.
>  
>>> 3.4.1.  Version Checking
>>
>> This may be a pointless worry, but is there a DOS attack of some kind
>> by sending rubbish version numbers?
>>
>> [Qin] I think thatnot only the field of Version Number, but also other 
>> fields, such as the fieldof Command Identifier can be filled with rubbish 
>> for DOS attack. So, I wonderif it is necessary for Version Number field to 
>> be treated differently. 
>>
>> I would like asksecurity people to help on the question.
> 
> Maybe you need to mention in the Security Considerations that you have
> no protection against a bad actor sending rubbish as a DOS. If all
> nodes are authenticated when they join the network, this seems an
> acceptable risk. 
> [Qin] Add text intoSecurity Consideration sectionThe 6P protocol does not 
> provide protection against DOS attacks w

Re: [Gen-art] Genart telechat review of draft-ietf-ace-cbor-web-token-12

[Dan Romascanu]

Hi Jim,

Thank you for your answer and for addressing my comments.

On item #2:



On Mon, Feb 26, 2018 at 10:12 PM, Jim Schaad  wrote:

>
>
> > -Original Message-
> > From: Dan Romascanu [mailto:droma...@gmail.com]
> >
>
> ...

> >
> > 2. I am a little confused by the definition of policies in Section 9.1:
> >
> >Depending upon the values being requested, registration requests are
> >evaluated on a Standards Track Required, Specification Required,
> >Expert Review, or Private Use basis [RFC8126] after a three-week
> >review period on the cwt-reg-rev...@ietf.org mailing list, on the
> >advice of one or more Designated Experts.
> >
> > How does this work? The request is forwarded to the designated expert,
> > he/she make a recommendation concerning the policy on the mail list, and
> > depending on the feedback received a policy is selected? Who establishes
> > consensus?
> >
> > Frankly, I wonder if this can work at all. Are there other examples of
> four
> > different policies for the same registry, applied on a case-to-case
> basis?
>
> This is the same approach that is being used for the COSE registries.  As
> an example, you can look at https://www.iana.org/
> assignments/cose/cose.xhtml#algorithms.
>
> Part of the issue about this is that the JOSE/JWT registries do have the
> same different policies, but that differences are hidden from the IANA
> registry.  Since they allow for a URI to be used as the identifier of a
> field, only the plain text versions are registered.  Thus I can use "
> http://augustcellars.com/JWT/My_Tag"; as an identifier.  Since for CBOR
> the set of tag values is closed and does not have this escape (nor would
> one want the length of the tag) it is necessary to have this break down of
> tag fields.
>
>
>
>
This does not seem to be exactly the same approach. The COSE RFC 8152
defines the registry policy in a different manner. There is only one policy
that is proposed 'Expert Review' and than the Expert Review Instructions
are used to define the cases when a Standards Track specification is
required. No such text exists in the current I-D. There is no separation of
the values space in the registry according to the type of assignment here,
as  in RFC 8152.

Regards,

Dan
___
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-ace-cbor-web-token-12

[Jim Schaad]

> -Original Message-
> From: Dan Romascanu [mailto:droma...@gmail.com]
> Sent: Monday, February 26, 2018 11:03 AM
> To: gen-art@ietf.org
> Cc: a...@ietf.org; i...@ietf.org; draft-ietf-ace-cbor-web-token@ietf.org;
> droma...@gmail.com
> Subject: Genart telechat review of draft-ietf-ace-cbor-web-token-12
> 
> Reviewer: Dan Romascanu
> Review result: Almost 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 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-ace-cbor-web-token-12
> Reviewer: Dan Romascanu
> Review Date: 2018-02-26
> IETF LC End Date: 2018-03-06
> IESG Telechat date: 2018-03-08
> 
> Summary:
> 
> This is a clear and detailed specification, which is almost ready for
> publications. There are however a couple of issues that I recommend to be
> discussed and addressed before the document is approved.
> 
> Major issues:
> 
> 1. CWT is derived from JWT (RFC 7519) using CBOR rather than JSON for
> encoding.
> The rationale as explained in the document is related to efficiency for some
> IoT systems. The initial claims registry defined in Section 9.1 is identical
> (semantically) with the initial claims registry defined in Section 10.1 of RFC
> 7519. Is this parallelism supposed to continue? If the two registries will
> continue to evolve in parallel, maybe there should be a mechanism at IANA to
> make this happen. Was this discussed by the WG? Maybe there is a need to
> include some text about the relationship between the two registries.

This is probably a YMMV answer.   Personally, I expect that there is going to 
be divergence between the two registries but I currently do not have any 
examples to support this answer.  The main reason for my supposition that I am 
guessing that CWT may be used in a wider set of situations, but again I cannot 
support this.

> 
> 2. I am a little confused by the definition of policies in Section 9.1:
> 
>Depending upon the values being requested, registration requests are
>evaluated on a Standards Track Required, Specification Required,
>Expert Review, or Private Use basis [RFC8126] after a three-week
>review period on the cwt-reg-rev...@ietf.org mailing list, on the
>advice of one or more Designated Experts.
> 
> How does this work? The request is forwarded to the designated expert,
> he/she make a recommendation concerning the policy on the mail list, and
> depending on the feedback received a policy is selected? Who establishes
> consensus?
> 
> Frankly, I wonder if this can work at all. Are there other examples of four
> different policies for the same registry, applied on a case-to-case basis?

This is the same approach that is being used for the COSE registries.  As an 
example, you can look at 
https://www.iana.org/assignments/cose/cose.xhtml#algorithms.

Part of the issue about this is that the JOSE/JWT registries do have the same 
different policies, but that differences are hidden from the IANA registry.  
Since they allow for a URI to be used as the identifier of a field, only the 
plain text versions are registered.  Thus I can use 
"http://augustcellars.com/JWT/My_Tag"; as an identifier.  Since for CBOR the set 
of tag values is closed and does not have this escape (nor would one want the 
length of the tag) it is necessary to have this break down of tag fields.

Jim


> 
> I would also observe that this is different from the policy defined for the
> parallel registry for JWT (Section 10.1 in RFC 7519) which is Specification
> Required.
> 
> Minor issues:
> 
> Nits/editorial comments:
> 


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

[Gen-art] Genart telechat review of draft-ietf-ace-cbor-web-token-12

[Dan Romascanu]

Reviewer: Dan Romascanu
Review result: Almost 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 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-ace-cbor-web-token-12
Reviewer: Dan Romascanu
Review Date: 2018-02-26
IETF LC End Date: 2018-03-06
IESG Telechat date: 2018-03-08

Summary:

This is a clear and detailed specification, which is almost ready for
publications. There are however a couple of issues that I recommend to be
discussed and addressed before the document is approved.

Major issues:

1. CWT is derived from JWT (RFC 7519) using CBOR rather than JSON for encoding.
The rationale as explained in the document is related to efficiency for some
IoT systems. The initial claims registry defined in Section 9.1 is identical
(semantically) with the initial claims registry defined in Section 10.1 of RFC
7519. Is this parallelism supposed to continue? If the two registries will
continue to evolve in parallel, maybe there should be a mechanism at IANA to
make this happen. Was this discussed by the WG? Maybe there is a need to
include some text about the relationship between the two registries.

2. I am a little confused by the definition of policies in Section 9.1:

   Depending upon the values being requested, registration requests are
   evaluated on a Standards Track Required, Specification Required,
   Expert Review, or Private Use basis [RFC8126] after a three-week
   review period on the cwt-reg-rev...@ietf.org mailing list, on the
   advice of one or more Designated Experts.

How does this work? The request is forwarded to the designated expert, he/she
make a recommendation concerning the policy on the mail list, and depending on
the feedback received a policy is selected? Who establishes consensus?

Frankly, I wonder if this can work at all. Are there other examples of four
different policies for the same registry, applied on a case-to-case basis?

I would also observe that this is different from the policy defined for the
parallel registry for JWT (Section 10.1 in RFC 7519) which is Specification
Required.

Minor issues:

Nits/editorial comments:


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

[Gen-art] Genart telechat review of draft-ietf-trill-vendor-channel-00

[Joel Halpern]

Reviewer: Joel Halpern
Review result: 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 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-vendor-channel-00
Reviewer: Joel Halpern
Review Date: 2018-02-26
IETF LC End Date: 2018-03-06
IESG Telechat date: 2018-03-08

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

Major issues: N/A

Minor issues: N/A

Nits/editorial comments:
Why does the acknowledgements say:
"The document was prepared in raw nroff. All macros used were defined
within the source file."
?


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

[Gen-art] review of draft-ietf-hip-dex-06.txt

[Francis Dupont]

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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-hip-dex-06.txt
Reviewer: Francis Dupont
Review Date: 20180224
IETF LC End Date: 20180226
IESG Telechat date: unknown

Summary: Ready

Major issues: None

Minor issues: None

Nits/editorial comments: 
 - ToC page 3: you use the US spelling of Acknowledgments in the ToC
  and the English one (acknowledgements) in the technical body.
  Even when it is not very consistent I believe this follows RFC 7401
  choice so I am fine with this.

 - 2.1 page 6: please add/move to RFC 8174 which updates RFC 2119 fixing
  the keyword case silly issue.

 - 2.2 page 6: perhaps "sort" should be added here?

 - 2.3 page 7 (twice): (c.f.  Section 3)  -> (see Section 3) or
  simply (Section 3)

 - 4.1.3.2 page 16 (at end of line): e.g. -> e.g.,

 - 5.3.3 page 25: I don't believe the critical property for
  random value is to be "uniformly distributed" (for instance
  I could have put "unpredictable"). I leave this to the security
  directorate who should propose a better wording if they don't like
  the current one...

 - 5.3.4 page 26: same comment.

 - 6.1 page 27: this section does not really explain what is the puzzle
  (it only stands the equation to verify) but I remember the explaination
  was before with a reference to 6.1 so I have no concern.

 - 6.2.1 sender 3 page 27: hidden dependency on the sort definition
  for HOST_g/HOST_l so gl/lg keys. Yes it is in 6.3 but 6.3 is after.

 - 6.3 pages and 30: sort is used page 29 and defined after page 30,
  this is why IMHO the question to move the definition to 2.2 notation
  is a good one...

 - 6.3 page 30: / is not associative so ceil(L/RHASH_len/8) is bad.
  The text shows it must be ceil(L/(RHASH_len/8)) (vs ceil((L/RHASH_len)/8))

 - 6.5 1. page 31: Otherwise, it must drop the packet. -> MUST

 - 6.6 1. page 33: the system should process the R1 packet -> or SHOULD
  or (I prefer) the system processes the R1 packet

 - 6.6 8. page 34: The R1 packet may have the A-bit set -> can
  (not better from a language point of view but clearer and BTW
   used for instance in 6.10...)

 - 6.6 13. page 34: it may either resend an I1 packet -> MAY? (cf 11.)

 - 6.7 5. page 36: Otherwise, the system should process the received I2 ->
  or SHOULD or (better) processes (and drop -> drops)

 - 6.7 15. page 37:
 If the A-bit is set, the Initiator's HIT is anonymous and should
 not be stored permanently. -> IMHO SHOULD NOT or directly MUST NOT

 - 6.9 page 39: If a NOTIFY packet is received in state I2-SENT, this
   packet may be an I2 reception acknowledgement of the optional
   -> replace "may be" by "can be" or (better) "is"

 - 7 page 40: Please put "If a Responder is not under high load, #K
   SHOULD be 0." in its own paragraph (i.e. add a break before "If").
   It makes clearer this sentence is a requirement when the text before
   is the rationale.

 - 8 page 40: " either supports HIP DEX or HIPv2 must be able to detect"
  -> MUST or "has to"

 - 8 pages 40 and 41: I think that the first and last paragraphs of
  section 8 say the same thing. Should you keep both?

 - 9 page 41: I'd like to see a formal proof of the DEX protocol.
  I believe you share this wish as you cite SIGMA.

 - 9 page 42: I'd like to go further and recommend (lower case) the
  use of a RNG (vs PRNG) when available (hopefully no longer an exception).

 - 9 page 42: Hence, HIP DEX HITs should not be use -> SHOULD or
  ought to?

Thanks

francis.dup...@fdupont.fr

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

Re: [Gen-art] review of draft-ietf-sidr-slurm-06.txt

[David Mandelberg]

On 02/26/2018 11:24 AM, Francis Dupont wrote:

  - authors' addresses page 17: I am not sure that to be affilated to
   his own personal organization is to be "unaffiliated"... IMHO the
   problem is the XML schema requires the organization field to be set (:-).


I think that's a hold-over from when I worked for Google and didn't feel 
like going through Google's approval process to get permission to list 
my affiliation. Now, I do business under the legal entity David 
Mandelberg, LLC, but I never really intended to use that name anywhere 
other than taxes/banks/etc. Would it be better to list that instead of 
unaffiliated? Or maybe "self-employed" or some other phrase?


--
Freelance cyber security consultant, software developer, and more
https://david.mandelberg.org/

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

[Gen-art] Genart telechat review of draft-ietf-6man-ndpioiana-02

[Dan Romascanu]

Reviewer: Dan Romascanu
Review result: Almost 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 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-6man-ndpioiana-02
Reviewer: Dan Romascanu
Review Date: 2018-02-26
IETF LC End Date: 2018-03-06
IESG Telechat date: 2018-04-05

Summary:

This is a simple and straightforward document, fixing an omission in RFC 6275,
which updated RFC 4861 without explicitly marking it as such,  and failed to
create a registry to avoid conflicts. The content of the document looks fine,
but there are several minor issues that I would recommend to be considered and
discussed before approval and publication.

Major issues:

Minor issues:

1. As this document fixes a problem created by RFC 6275 which was was not
marked as updating RFC 4861, and did not create a registry to avoid conflicts,
it looks like this RFC (if approved) should also update RFC 6275.

2. Section 3 includes a reference to [IANA-TBD] which is not defined in the
document.

3. As the new registry contains one bit defined by RFC 6275, it seems that
[RFC6275] should also be a Normative Reference.

4. Section 4 - It would be good to capitalize Standards Action, and refer to
RFC 8126 as reference (also to be added)

Nits/editorial comments:

1. The Abstract and the Introduction contain a sentence with broken syntax:

'The purpose of this document is to request that IANA to create a new registry
...'

2. Several acronyms in the document are not explicitly expanded: ND, PIO, NDP


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

[Gen-art] review of draft-ietf-sidr-slurm-06.txt

[Francis Dupont]

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-sidr-slurm-06.txt
Reviewer: Francis Dupont
Review Date: 20180217
IETF LC End Date: 20180221
IESG Telechat date: unknown

Summary: Ready

Major issues: None

Minor issues: None

Nits/editorial comments: 
 - ToC page 2 and 6 page 14 (title): Security considerations ->
  Security Considerations

 - ToC page 2 and 7 page 14: Acknowledgements -> Acknowledgments

 - 1 page 3: please expand the TA abbrev (it is the only occurrence BTW).

 - 1.1. page 3: add a reference to RFC 8174 which updates RFC 2119 fixing
  the keyword case silly issue.

 - 2 page 3: please introduce the RP abbrev before (RP is not well known
  because it has 4 different meanings. Here it is not ambiguous but
  for instance RP does not stand for the beginning of RPKI...)

 - 3.1 page 4: [RFC8259]format -> [RFC8259]format (missing space).

 - 3.1 page 4: for me the right reference to JSON specs is ECMA-404.
  Now I don't know the policy of the IETF about this particular point
  (anyway if this must be fixed this will be by the RFC Editor?)

 - 3.2 page 5: I leave the choice to introduce FQDN to you (for me
  it is more than well known but it is not in RFC Editor list
  https://www.rfc-editor.org/materials/abbrev.expansion.txt)

 - 3.2 page 5: MUST in " all targets must be acceptable"?

 - 3.3 page 6 example 1: "asn": 65536 -> "asn": 65536,
  (missing comma which leads to incorrect JSON)

 - 3.3 page 7 example 2: another missing comma at the same position.

 - 3.4.1 page 7: I have no idea whether "subsume" is common English or not,
  one of the authors is from China so I believe it is...

 - 3.4.2 page 8: please introduce the SKI abbrev.

 - 3.4.2 page 8 and 3.5.2 page 10: the document does not specify what
  is the encoding. I suppose it is BER? If you believe it is not useful
  you can keep the document as it is (i.e. not adding new encoding details).
  Note for the public key 3.5.2 says DER.

 - 3.6 pages 11 and 12: there are JSON pretty-printers available if you
  like (I even have one :-). (I don't mean 3.6 JSON is not well indented,
  just signal there are tools in the case you don't already know).
 
 - 4.2 page 13 (twice): Y,Z -> Y, Z

 - 6 page 14: strange (to me) comma in "by the RPKI, to that RP."

 - authors' addresses page 17: China -> PR China or CN

 - authors' addresses page 17: I am not sure that to be affilated to
  his own personal organization is to be "unaffiliated"... IMHO the
  problem is the XML schema requires the organization field to be set (:-).

Regards

francis.dup...@fdupont.fr

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

Re: [Gen-art] [6tisch] Genart telechat review of draft-ietf-6tisch-6top-protocol-09

[Qin Wang]

Hi Bian,
Thank you for your comments. Please see inline.



On Friday, February 23, 2018 6:11 PM, Brian E Carpenter 
 wrote:
 

 Hi Qin, see in line:

On 24/02/2018 04:16, Qin Wang wrote:
> Hi Brian,
> Thank you very much for your comments. Please see inline.
> 
> On Monday, February 19, 2018 6:22 PM, Brian Carpenter 
>  wrote: 
> 
>  Reviewer: Brian Carpenter
> Review result: Ready with Issues
> 
> Gen-ART Last Call review of draft-ietf-6tisch-6top-protocol-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 treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> .
> 
> Document: draft-ietf-6tisch-6top-protocol-09.txt
> Reviewer: Brian Carpenter
> Review Date: 2018-02-20
> IETF LC End Date: 2018-??-??
> IESG Telechat date: 2018-03-06
> 
> Summary: Ready with issues
> 
> 
> Comment:
> 
> 
> This is a Last Call review despite the subject field. When will the Last
> Call be started?
> 
> Major issues:
> -
> 
> In section 3.1.1 "2-step 6P Transaction" there seems to be a race condition
> if A's timeout expires while B's Response is in flight. Can the 6top layer
> prevent the L2 Ack being sent? (And similar race conditions seem to be
> possible in the 3-step transaction.)
> 
> [Qin] Firstly, sincethe L2 Ack is sent by L2 according to IEEE802.15.4, 6top 
> layer cannot preventit happen. Secondly, the race condition described above 
> unlikely happens,because it is required that “The value of the 6P Timeout 
> should be larger thanthe longest possible time it can take for the exchange 
> to finish.” (3.4.4)

I'm sorry but that sounds like magic. Then whole point of race conditions is 
that
they happen in *very* unlikely cases such as the exchange taking 10 times normal
for some reason. If it only happens one time in ten million it is still a 
problem.
So I think you need to state what happens - maybe the inconsistency will be
discovered later? That's fine for something considered highly unlikely.
[Qin] Add following textin both section 3.1.1 and 3.1.2
In case a race conditionhappens during the communication, the TSCH schedule of 
node A may becomeinconsistent with the TSCH schedule of node B. 6top handles 
the schedule inconsistency in the way described in Section3.4.6.2
> 
>> 3.4.3.  Concurrent 6P Transactions
>>
>>   Only a single 6P Transaction between two neighbors, in a given
>>   direction, can take place at the same time.  That is, a node MUST NOT
>>   issue a new 6P Request to a given neighbor before having received the
>>   6P Response for a previous request to that neighbor, except when the
>>   previous 6P Transaction has timed out.  If a node receives a 6P
>>   Request from a given neighbor before having sent the 6P Response to
>>   the previous 6P Request from that neighbor, it MUST send back a 6P
>>   Response with a return code of RC_RESET (as per Figure 36).  A node
>>   receiving RC_RESET code MUST abort the transaction and consider it
>>   never happened.
> 
> It isn't clear to me whether the RC_RESET aborts the first, the second,
> or both transactions.
> 
> [Qin] change textto “abort the second transaction”

OK! 
> Minor issues:
> -
> 
>> 1.  Introduction
> ...
>>   6P
>>   allows a node to communicate with a neighbor to add/delete TSCH cells
>>   to one another.
> 
> This sentence is almost unintelligible because of the sequence to...to...to.
> Does it mean this?:
> 
>   6P allows neighbours to add or delete TSCH cells in each other.
> 
> [Qin] Because we want to emphasize that communication between two nodes is 
> the way to add/deletecells, we change text to “6P allows a node to 
> communicate with a neighbor toadd/delete TSCH cells in each other”
 

OK, that will be less confusing.
 
>> 3.4.1.  Version Checking
> 
> This may be a pointless worry, but is there a DOS attack of some kind
> by sending rubbish version numbers?
> 
> [Qin] I think thatnot only the field of Version Number, but also other 
> fields, such as the fieldof Command Identifier can be filled with rubbish for 
> DOS attack. So, I wonderif it is necessary for Version Number field to be 
> treated differently. 
> 
> I would like asksecurity people to help on the question.

Maybe you need to mention in the Security Considerations that you have
no protection against a bad actor sending rubbish as a DOS. If all
nodes are authenticated when they join the network, this seems an
acceptable risk. 
[Qin] Add text intoSecurity Consideration sectionThe 6P protocol does not 
provide protection against DOS attacks which involves sending garbage.

Regards
    Brian
 
> ThanksQin
ThanksQin
> ___
> 6tisch mailing list
> 6ti...@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
> 
> 
>    
> 


   ___

[Gen-art] Review Assignments

[Jean Mahoney]

Hi all,

The following reviewers have assignments:

For telechat 2018-03-08

Reviewer   Type  LC end Draft
Stewart Bryant Telechat  2018-03-06 
draft-ietf-trill-transport-over-mpls-07
Brian CarpenterTelechat  2018-03-06 draft-ietf-trill-multi-topology-05
Francis Dupont Last Call 2018-02-28 draft-ietf-netmod-syslog-model-22
Roni Even  Telechat  2018-03-06 
draft-ietf-trill-directory-assisted-encap-09
Joel Halpern   Telechat  2018-03-06 draft-ietf-trill-vendor-channel-00
Matthew Miller Telechat  2018-03-06 draft-ietf-trill-over-ip-15
Pete Resnick   Telechat  2018-03-07 draft-ietf-netmod-rfc6087bis-18
Dan Romascanu  Telechat  2018-03-06 draft-ietf-ace-cbor-web-token-12
Meral Shirazipour  Telechat  2018-02-22 draft-ietf-bier-mvpn-10 *
Meral Shirazipour  Telechat  2018-03-06 
draft-ietf-trill-multilevel-unique-nickname-05
Robert Sparks  Telechat  2018-03-06 draft-ietf-trill-smart-endnodes-08
Dale WorleyLast Call 2018-03-02 draft-ietf-tls-tls13-24

For telechat 2018-04-05

Reviewer   Type  LC end Draft
Stewart Bryant Telechat  2018-03-30 draft-ietf-i2rs-rib-data-model-10
Francis Dupont Telechat  2018-03-20 draft-ietf-tls-record-limit-02
Francis Dupont Last Call 2018-02-21 draft-ietf-sidr-slurm-06
Vijay Gurbani  Last Call 2018-03-06 
draft-ietf-teas-scheduled-resources-06
Dan Romascanu  Last Call 2018-03-16 draft-ietf-rmcat-sbd-10
Dan Romascanu  Telechat  2018-03-06 draft-ietf-6man-ndpioiana-02
Peter Yee  Telechat  2018-03-06 draft-ietf-6lo-rfc6775-update-14

Last calls:

Reviewer   Type  LC end Draft
Elwyn Davies   Last Call 2018-02-26 
draft-ietf-anima-autonomic-control-plane-13
Francis Dupont Last Call 2018-02-26 draft-ietf-hip-dex-06
Robert Sparks  Last Call 2018-03-06 draft-ietf-mmusic-rid-13

* Other revision previously reviewed
** This revision already reviewed

Next in the reviewer rotation:

  Francis Dupont
  Roni Even
  Fernando Gont
  Vijay Gurbani
  Wassim Haddad
  Joel Halpern
  Christer Holmberg
  Russ Housley
  Jouni Korhonen
  Paul Kyzivat

The LC and Telechat review templates are included below:
---

-- Begin LC Template --
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: 

-- End LC Template --

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

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

-- End Telechat Template --


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

[Gen-art] Genart last call review of draft-ietf-pce-lsp-setup-type-08

[Roni Even]

Reviewer: Roni Even
Review result: Almost 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-pce-lsp-setup-type-??
Reviewer: Roni Even
Review Date: 2018-02-26
IETF LC End Date: 2018-03-06
IESG Telechat date: 2018-04-05

Summary:
The document is almost ready for publication as standard track RFC
Major issues:

Minor issues:
1. in section 7.2 "The allocation policy for this new registry  should be by
IETF Consensus" why not use one of RFC8126 well known policies?

Nits/editorial comments:


___
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-hip-rfc4423-bis-18

[jmh.direct]

These changes very nicely address my concerns.b You should check with your 
chair,and AD before submitting a,revision.
Thank you,Joel


Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone
 Original message From: Miika Komu  
Date: 2/26/18  06:56  (GMT-05:00) To: Joel Halpern , 
gen-art@ietf.org Cc: draft-ietf-hip-rfc4423-bis@ietf.org, hip...@ietf.org, 
i...@ietf.org Subject: Re: Genart last call review of 
draft-ietf-hip-rfc4423-bis-18 
Hi Joel,

thanks for the nice review! My suggested changes for HIP architecture 
document are below (in "diff" format).

On 02/18/2018 07:33 AM, Joel Halpern wrote:
> Reviewer: Joel Halpern
> 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 treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-hip-rfc4423-bis-18
> Reviewer: Joel Halpern
> Review Date: 2018-02-17
> IETF LC End Date: 2018-02-26
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: This document is ready for publication as an Informational RFCs.
>   The following comments may be useful for the authors to consider.
> 
> Major issues: N/A
> 
> Minor issues:
>  In the table in section 2.2 (Terms specific to this and other HIP
>  documents) the Host Identity Hash is defined as "The cryptographic hash
>  used in creating the Host Identity Tag from the Host Identity."  I am
>  pretty sure the last word should be Identifier, not Identity,, which
>  matches the meanings and the usage in the following term.

agreed. Suggested change:

    Host Identity Hash  The cryptographic hash used
-  in creating the Host Identity Tag from the Host Identity.
+  in creating the Host Identity Tag from the Host Identifier.
  (I will move the definition of Host Identifier earlier so that the 
terms appear in chronological order)

>  In section 4.1 second paragraph, it seems odd to refer to the
>  public-private key pair as the structure of the abstract Host Identity.
>  Given that the earlier text refers to the Public key as the Host
>  Identifier, I am not sure how you want to refer to the public/private key
>  pair.  But I do not think it "is" the structure of the Host Identity.

Agree. Suggested rephrasing:

-    The only completely defined structure of the Host Identity
-    is that of a public/private key pair.  In this case, the Host
-    Identity is referred to by its public component, the public
+    An identity is based on public-private key cryptography in HIP.
+    The Host Identity is referred to by its public component, the 
public
  key.

>  In the section 4.4 discussion of locally scoped identifier (LSI), it
>  appears that applications need to be modified to use this.  Reading 
>between
>  the lines of the stack architecture, the actual advantage of using HIP 
>with
>  LSIs is that the application changes can be restricted to whatever
>  indication is to be used that the stack is to use HIP, rather than 
>changing
>  the places that use sockaddrs, etc.  But this is not clearly stated here.

yes, you are correct. I would suggest the following changes to make this 
more clear:

  A Host Identity Tag is a 128-bit representation for a Host
-    Identity.  It is created from an HIH,
-    an IPv6 prefix [RFC7343] and a hash identifier.
+    Identity. Due to its size, it is suitable to be used in the 
existing sockets API in
+    the place of IPv6 addresses (e.g. in sockaddr_in6 structure, 
sin6_addr member) without modifying applications.
+    It is created from an HIH, an IPv6 prefix [RFC7343]
+    and a hash identifier.

...and the following:

  An LSI is a 32-bit localized representation for a Host
-    Identity. The purpose of an LSI is to facilitate using Host
+    Identity. Due to its size, it is suitable to be used in the 
existing sockets API in
+    the place of IPv4 addresses (e.g. in sockaddr_in structure, 
sin_addr member) without modifying applications.
+    The purpose of an LSI is to facilitate using Host
  Identities in existing APIs for IPv4-based
-    applications. Besides facilitating HIP-based connectivity for
+    applications.
+    LSIs are never transmitted on the wire; when an application
+    sends data using a pair of LSIs, the HIP layer (or sockets
+    handler) translates the LSIs to the corresponding HITs, and
+    vice versa for receiving of data.
+    Besides facilitating HIP-based connectivity for
  legacy IPv4 applications, the LSIs are beneficial in two other
  scenarios [RFC6538].

@@ -712,6 +721,14 @@
  to facilitate backward compatibility with existing networking
  APIs and stacks.

>  In s

[Gen-art] Genart last call review of draft-ietf-lisp-signal-free-multicast-07

[Roni Even]

Reviewer: Roni Even
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 treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-lisp-signal-free-multicast-??
Reviewer: Roni Even
Review Date: 2018-02-26
IETF LC End Date: 2018-02-27
IESG Telechat date: 2018-03-08

Summary:
The document is ready for publication as experimental RFC

Major issues:

Minor issues:

Nits/editorial comments:

1. in section 1 "The signal-free mechanism here proposed " should be "The
signal-free mechanism proposed here " 2.  in section 2 SSM is Source Specific
Multicast not single source 3. in section 7 bullet 5 "When the the ITR..."


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

[Gen-art] Genart last call review of draft-ietf-hip-native-nat-traversal-27

[Roni Even]

Reviewer: Roni Even
Review result: Almost 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-hip-native-nat-traversal-??
Reviewer: Roni Even
Review Date: 2018-02-26
IETF LC End Date: 2018-02-26
IESG Telechat date: Not scheduled for a telechat

Summary:
The document is almost ready for publication as a standard track RFC

Major issues:

Minor issues:

1. in section 4.2 "Gathering of candidates MAY also be performed by other means
than described in this section.  For example, the candidates could be
   gathered as specified in Section 4.2 of [RFC5770] if STUN servers are
   available, or if the host has just a single interface and no STUN orData
   Relay Server are available." I did not see this a different ways since
   section 3 says "The hosts use either Control Relay Servers or Data Relay
   Servers (or other infrastructure including STUN or TURN servers) for
   gathering the candidates." so STUN is mentioned also here.

2. In section 4.6.2 "The connectivity check messages MUST be paced by the Ta
value negotiated during the base exchange as described in Section 4.4.  If
neither one of the hosts announced a minimum pacing value, a value of  20 ms
SHOULD be used." in section 4.4 the default value is 50 ms?

3. in section 5.4 what about "ICE-STUN-UDP 2" ;  I assume it is not
relevant but this is also the IANA registeration

4. In section 5.5 "The TRANSACTION_PACING is a new parameter" it is not new it
is in RFC5770

5. In section 5.10 "SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED  63" is the
only new one. this also relates to section 7 that says that all error values in
section 5.10 are new while the rest are in RFC5770. Also there is no mention in
section 7 of which registry is used for the error values.

Nits/editorial comments:
1. Expand SPI and LSI when first appear in the document

2. in section 2 "the base of an candidate" should be "a candidate"

3. In section 3 "so it is the Initiator may also have registered to a Control
and/or Data Relay Server" maybe "so  the Initiator may also need to register to
a Control and/or Data Relay Server"

4. In section 4.2 "However, it is RECOMMENDED that a Data Relay Client
registers a new server reflexive candidate for each its peer for the reasons
described" maybe "for each of its..."

5. In section 4.2 I could not parse the sentence "where Ta is the value used
for Ta is the value used for the"

6. in section 4.6 "as defined in section in 6.7 in [RFC7401]:"  change to "as
defined in section 6.7 in [RFC7401]:"


___
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-hip-rfc4423-bis-18

[Miika Komu]

Hi Joel,

thanks for the nice review! My suggested changes for HIP architecture 
document are below (in "diff" format).


On 02/18/2018 07:33 AM, Joel Halpern wrote:

Reviewer: Joel Halpern
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 treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-hip-rfc4423-bis-18
Reviewer: Joel Halpern
Review Date: 2018-02-17
IETF LC End Date: 2018-02-26
IESG Telechat date: Not scheduled for a telechat

Summary: This document is ready for publication as an Informational RFCs.
  The following comments may be useful for the authors to consider.

Major issues: N/A

Minor issues:
 In the table in section 2.2 (Terms specific to this and other HIP
 documents) the Host Identity Hash is defined as "The cryptographic hash
 used in creating the Host Identity Tag from the Host Identity."  I am
 pretty sure the last word should be Identifier, not Identity,, which
 matches the meanings and the usage in the following term.


agreed. Suggested change:

   Host Identity Hash  The cryptographic hash used
-  in creating the Host Identity Tag from the Host Identity.
+  in creating the Host Identity Tag from the Host Identifier.
 (I will move the definition of Host Identifier earlier so that the 
terms appear in chronological order)



 In section 4.1 second paragraph, it seems odd to refer to the
 public-private key pair as the structure of the abstract Host Identity.
 Given that the earlier text refers to the Public key as the Host
 Identifier, I am not sure how you want to refer to the public/private key
 pair.  But I do not think it "is" the structure of the Host Identity.


Agree. Suggested rephrasing:

-The only completely defined structure of the Host Identity
-is that of a public/private key pair.  In this case, the Host
-Identity is referred to by its public component, the public
+An identity is based on public-private key cryptography in HIP.
+The Host Identity is referred to by its public component, the 
public

 key.


 In the section 4.4 discussion of locally scoped identifier (LSI), it
 appears that applications need to be modified to use this.  Reading between
 the lines of the stack architecture, the actual advantage of using HIP with
 LSIs is that the application changes can be restricted to whatever
 indication is to be used that the stack is to use HIP, rather than changing
 the places that use sockaddrs, etc.  But this is not clearly stated here.


yes, you are correct. I would suggest the following changes to make this 
more clear:


 A Host Identity Tag is a 128-bit representation for a Host
-Identity.  It is created from an HIH,
-an IPv6 prefix [RFC7343] and a hash identifier.
+Identity. Due to its size, it is suitable to be used in the 
existing sockets API in
+the place of IPv6 addresses (e.g. in sockaddr_in6 structure, 
sin6_addr member) without modifying applications.

+It is created from an HIH, an IPv6 prefix [RFC7343]
+and a hash identifier.

...and the following:

 An LSI is a 32-bit localized representation for a Host
-Identity. The purpose of an LSI is to facilitate using Host
+Identity. Due to its size, it is suitable to be used in the 
existing sockets API in
+the place of IPv4 addresses (e.g. in sockaddr_in structure, 
sin_addr member) without modifying applications.

+The purpose of an LSI is to facilitate using Host
 Identities in existing APIs for IPv4-based
-applications. Besides facilitating HIP-based connectivity for
+applications.
+LSIs are never transmitted on the wire; when an application
+sends data using a pair of LSIs, the HIP layer (or sockets
+handler) translates the LSIs to the corresponding HITs, and
+vice versa for receiving of data.
+Besides facilitating HIP-based connectivity for
 legacy IPv4 applications, the LSIs are beneficial in two other
 scenarios [RFC6538].

@@ -712,6 +721,14 @@
 to facilitate backward compatibility with existing networking
 APIs and stacks.


 In section 5.1 paragraph 3, the text talks about a connecting client not
 specifying a responder identifier (HIP Opportunistic mode) in order to
 enable load balancing.  I think the text would be helped by an example of
 how an initiator might know to do this, rather than just not using HIP.
 Also, it would be good if the text was explicit as to whether or not there
 was a way to support load balancing / multi servers without either using a
 shared identity or sacrificing security by using Opportunistic HIP.


agreed, the descr