Re: [Gen-art] Genart last call review of draft-ietf-core-oscore-edhoc-09

[jmh.direct]

Thank you Marco.  Those changes address my comments and I think make the 
document clearer.Yours,JoelSent via the Samsung Galaxy S20 FE 5G, an AT 5G 
smartphone
 Original message From: Marco Tiloca  Date: 
11/23/23  10:25 AM  (GMT-05:00) To: Joel Halpern , 
gen-art@ietf.org Cc: c...@ietf.org, draft-ietf-core-oscore-edhoc@ietf.org, 
last-c...@ietf.org Subject: Re: Genart last call review of 
draft-ietf-core-oscore-edhoc-09 
Hello Joel,
  
  Thanks a lot for your review! Please find in line below our
  detailed replies to your comments.
  
  A Github PR where we have addressed your comments is available at
  [GENART-PR].
  
  Unless any concern is raised, we plan to soon merge this PR (and
  the other ones related to other received reviews), and to submit
  the result as version -10 of the document.
  
  Thanks,
  /Marco
  
  [GENART-PR] https://github.com/core-wg/oscore-edhoc/pull/15
  

On 2023-11-12 17:19, Joel Halpern via
  Datatracker wrote:


  Reviewer: Joel Halpern
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-core-oscore-edhoc-09
Reviewer: Joel Halpern
Review Date: 2023-11-12
IETF LC End Date: 2023-11-13
IESG Telechat date: Not scheduled for a telechat

Summary: This document is ready for publication as a proposed standard
reviewer note: I did not attempt to verify that the description here of the
underlying security protocols is correct.  I leave that to the WG and the
security reviewers.

Major issues: N/A

Minor issues:
   In reading the first part of section 3, I found myself confused in two
   regards.  First, the diagram shows the third message as containing EDHOC
   message_3 + OSCORE-protected data. But the text refers to it as also
   containing C_R which is not apparently part of EDHOC message 3.  I think
   this is explained in step 4 of section 3.2, but it is at best jarring at
   this stage. (Maybe just call it OSCORE option C_R? Or note at this point,as
   you do later, in the text that the EDHOC C_R and the OSCORE C_R are
   identical?)


==>MT

The *CoAP request* contains C_R, while EDHOC message_3 does not. In
fact, that is the case in both the original workflow and the
optimized workflow.

That is, in both workflows, C_R is not part of EDHOC message_3, and
it has to be somehow specified in the CoAP request that conveys
EDHOC message_3.

As to the original workflow, this is already defined in
draft-ietf-lake-edhoc, and reminded in Section 2 of the present
document. That is, C_R is specified in the payload of the CoAP
request, as prepended to EDHOC message_3, i.e.:

> The request payload consists of the EDHOC connection identifier
C_R encoded as per Section 3.3 of [I-D.ietf-lake-edhoc],
concatenated with EDHOC message_3.

As to the optimized workflow in Section 3, the diagram in Figure 2
is correct about what it shows. As it happens, C_R is already
specified as the value of the 'kid' field in the CoAP OSCORE Option
included in the CoAP request. Hence, we take advantage of that and
we do not prepend C_R to EDHOC message_3 in the request payload.

Note that there is no concept of "OSCORE C_R" or "OSCORE option
C_R", and the CoAP OSCORE Option does not include a C_R field. There
is only EDHOC C_R, as the EDHOC Connection Identifier of the
Responder.

To make these points clearer, in Section 3.0 we have revised the
bullet list introduced by "That is, the EDHOC + OSCORE request ..."
to become as follows.

> That is, the EDHOC + OSCORE request is composed of the
following two parts combined together in a single CoAP message:
> 
> * The OSCORE Request from Figure 1, which is also in this case
sent to a protected resource, with the correct CoAP method and
options intended for accessing that resource.
>
> * EDHOC data consisting of the pair (C_R, EDHOC message_3)
required for completing the EDHOC session, transported as follows:
>    * C_R is the OSCORE Sender ID of the client and hence
transported in the 'kid' field of the OSCORE Option (see Section 6.1
of RFC 8613). Unlike in the sequential workflow shown in 

Re: [Gen-art] Genart last call review of draft-ietf-netmod-schema-mount-10

[jmh.direct]

Thank you.  Those changes will do the trick.  I realize they are small.  They 
fix a lot of confusion.
Yours,Joel
PS:  While I think the absence of information on how the server knows / decides 
what to mount where is unfortunate, I understand that to be the WG agreement 
and therefore am not objecting to progressing the document.


Sent via the Samsung Galaxy S® 6, an AT 4G LTE smartphone
 Original message From: Martin Bjorklund  
Date: 6/29/18  05:53  (GMT-05:00) To: j...@joelhalpern.com Cc: 
gen-art@ietf.org, net...@ietf.org, i...@ietf.org, 
draft-ietf-netmod-schema-mount@ietf.org Subject: Re: Genart last call 
review of draft-ietf-netmod-schema-mount-10 
Hi,

Thank you for your review!  Comments inline.


Joel Halpern  wrote:
> Reviewer: Joel Halpern
> 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-netmod-schema-mount-10
> Reviewer: Joel Halpern
> Review Date: 2018-06-28
> IETF LC End Date: 2018-06-29
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: This document is almost ready for publication as a Proposed 
> Standards.
> I believe that the working group has gotten too close to the work, and
> failed to notice that important explanations that they understand do not
> actually appear in the document.
> 
> Major issues:
>  There is no explanation in the document as to who controls mounting and
>  how it is specified.  From this, I infer that the intention is that the
>  server knows what is to be mounted at specific mount points, and does 
>so. 
>   The Client does not tell the server to mount specific schemas in 
>specific
>  places.  Ok.  Say so.  And explain that the server knows this by means
>  external to the YANG modules.  The text explicitly states that the case
>  where the mount point definition selects the data model to be mounted is
>  NOT supported by this document.

The document has the following text, which was supposed to cover this
case:

   Schema mount applies to the data model, and specifically does not
   assume anything about the source of instance data for the mounted
   schemas.  It may be implemented using the same instrumentation as the
   rest of the system, or it may be implemented by querying some other
   system.  Future specifications may define mechanisms to control or
   monitor the implementation of specific mount points.

But howabout we add a new paragraph after this:

   How and when specific mount points are instantiated by the server
   is out of scope for this document.  Such mechanisms may be defined
   in future specifications.

> There is some ambiguity, quite possibly only in this reader, as to what a
> client finds when it does a NETCONF Get at or below the mount point.  I 
>had
> assumed originally that it would find structure defined by the schema that
> is mounted there, as defined by the schema-mount container.

This is correct.

> However, the
> Schema-mount definition itself states that what is found at the mount 
>point
> is an instance of YANG library.

Hmm, do you mean the text in the YANG module:

   "This node indicates that the server has mounted
    'ietf-yang-library' at the mount point, and its
    instantiation provides the information about the mounted
    schema.

If so, maybe we can clarify by saying

   "This node indicates that the server has mounted
    at least the module 'ietf-yang-library' at the mount
    point, and its
    instantiation provides the information about the mounted
    schema.


> Given that this lefft me completely
> confused, please add some explanatory text?
> 
> Minor issues:
> N/A
> 
> Nits/editorial comments:
> The introduction, in its third paragraph refers to the "source or target
> YANG module" seeming to use both the term source and the term target to
> refer to the module with the uses or augments statement.  Even if other
> YANG documents use both terms, this is a confusing construction.

How about:

OLD:

   With both mechanisms, the source or target YANG module explicitly
   defines the exact location in the schema tree where the new nodes are
   placed.

NEW:

   With both mechanisms, the YANG module with the "uses" or "augemnt"
   statement explicitly defines the exact location in the schema tree
   where the new nodes are placed.


/martin
___
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 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 

Re: [Gen-art] Review of draft-mohali-dispatch-cause-for-service-number-12

[jmh.direct]

Thank you.That seems a reasonable compromise among the constraints. 
Ypyrs,Joel


Sent via the Samsung Galaxy S® 6, an AT 4G LTE smartphone
 Original message From: Ben Campbell  Date: 
1/27/17  14:17  (GMT-06:00) To: marianne.moh...@orange.com Cc: Joel Halpern 
, gen-art@ietf.org, i...@ietf.org, 
draft-mohali-dispatch-cause-for-service-number@ietf.org, dispa...@ietf.org 
Subject: Re: Review of draft-mohali-dispatch-cause-for-service-number-12 
On 27 Jan 2017, at 11:15, marianne.moh...@orange.com wrote:

> Hi Joel,
>
> I have submitted a new version (v-13) of the draft.
> I have addressed your comment for IPv6 addresses format in the 
> example.
> Concerning your major comment, the discussion is leaded by Ben.

To that point: Please note that version 13 adds a comment to the end of 
the introduction to make it clear that this draft documents something 
that another group (3GPP) does. It is not an IETF standard.

Thanks!

Ben.

>
> I hope I have correctly address your comment.
> https://datatracker.ietf.org/doc/draft-mohali-dispatch-cause-for-service-number/
>
> Best regards,
> Marianne
>
>> -Message d'origine-
>> De : Joel Halpern [mailto:j...@joelhalpern.com]
>> Envoyé : vendredi 16 décembre 2016 04:57
>> À : gen-art@ietf.org
>> Cc : i...@ietf.org; draft-mohali-dispatch-cause-for-service-
>> number@ietf.org; dispa...@ietf.org
>> Objet : Review of draft-mohali-dispatch-cause-for-service-number-12
>>
>> Reviewer: Joel Halpern
>> Review result: Ready with Issues
>>
>> Major:
>> This document defines a new code for use in SIP, and specifies 
>> new behavior
>> both for the code itself and for its use in history-info.  I am thus 
>> confused as to
>> how this can be an informational RFC.  It looks like it either 
>> Proposed Standard
>> or experimental.  Yes, I see that RFC 4458, which this updates is 
>> Informational.
>> But just because we did it wrong before does not make that behavior 
>> correct
>> now.  In addition to my understanding of the roles of different RFCs, 
>> I note that
>> RFC 3969 and the IANA registry both state that this assignment must 
>> be made
>> by a standards track RFC.
>>
>> Minor:
>>    Given our emphasis on IPv6 over IPv4, would it not make sense for 
>> the
>> examples to use IPv6 addresses?  (Inspired by the Id-Nits alert.)
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les 
> messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, 
> deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and 
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have 
> been modified, changed or falsified.
> Thank you.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art