Re: [Gen-art] [Drip] Genart last call review of draft-ietf-drip-rid-24

2022-05-16 Thread Elwyn Davies 

Hi, Bob.

Sorry for the tardy reply.  Thanks for the responses, and, yes, I think 
the changes clear up the nits I identified.  Now good to go.


Cheers,
Elwyn

On 16/05/2022 13:32, Robert Moskowitz wrote:

Elwyn,

I believe your comments are the only opens left.  Does this response 
and the current drip-rid-26 address your points?


Note that the question sec 8.1 was addressed by IANA and is reflected 
in -26.


Thank you.

Bob

On 5/10/22 21:13, Robert Moskowitz wrote:



On 5/10/22 12:25, Elwyn Davies via Datatracker wrote:

Reviewer: Elwyn Davies
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-drip-rid-24
Reviewer: Elwyn Davies
Review Date: 2022-05-10
IETF LC End Date: 2022-05-11
IESG Telechat date: Not scheduled for a telechat

Summary:
Ready with nits.  I can't speak for the robustness of the security 
choices but
the document is well written apart from a couple of pieces of deep 
jargon that

may need explanation for more naive readers (notably multilateration -
definitely a new one on me!)


Multilateration occurs once in the draft, sec 9.1.  It is a main part 
of draft-moskowitz-crowd-sourced-rid where I have the definition:


   Multilateration:  Multilateration (more completely, pseudo range
  multilateration) is a navigation and surveillance technique based
  on measurement of the times of arrival (TOAs) of energy waves
  (radio, acoustic, seismic, etc.) having a known propagation speed.


Do you think it should be added here in the definitions section? I 
really don't want to pull it from 9.1, and I don't see adding this 
whole definition into 9.1.


Multilateration is an important tool in aviation traffic management.  
Oh and this is fundamental to GPS.


I do expect, at some point soon, that crowd-sourced-rid will become a 
wg draft...





Major issues:
None

Minor issues:
None

Nits/editorial comments:
Abstract/s1:  The term 'self-asserting IPv6 address'  is defined in 
Section 3
of the DRIP architecture.  AFAICS 'self-asserting' is novel 
terminology, at

least in this context, and I think  it would be good to point to the
architecture in the Abstract  and to make it a little clearer that 
the term
self-asserting (IPv6 address) is defined in the architecture - I 
missed that on

first reading - as well as the idea of HHITs.


para 2 of the Intro references Architecture, but what do you think of:

   This document describes the use of Hierarchical Host Identity Tags
   (HHITs) as self-asserting IPv6 addresses, as described in the DRIP
   Architecture, and thereby a trustable identifier for use as the
   Unmanned Aircraft System Remote Identification and tracking (UAS 
RID).







s1, para 3: s/are updated, these/are updated, but these/


Fixed for -25



s3.2: Query:  Is there are good reason for leaving the HIT/HHIT 
Suite ID value

4 unused?


Because draft-moskowitz-hip-new-crypto has it as '5', and that draft 
(which will be needed for secure-nrid-c2) proposed 5 (and 6) because 
a dead draft used 4...


I will see if I can move them all up.  I do have to check with 
implementors to see if there are any issues that I am forgetting.




s3.2, s3.4.2, s8.2 and s8.4:  After the definition of the 
EdDSA/cSHAKE128 value
  '(RECOMMENDED)' is appended.  What or who is this recommendation 
aimed at?
The users of the specification or IANA in relation to TBD3? The 
registry
doesn't seem to have scope for recording this recommendation. If it 
is aimed
at users, I think there should be words to this effect in s3.2 and 
it is

probably not relevant in s3.4.2.


To implementors.  This is a copy from 7401, and maybe it is no longer 
the style?


From 7401:

    HIT Suite   Four-bit ID    Eight-bit encoding

    RESERVED    0 0x00
    RSA,DSA/SHA-256 1 0x10 (REQUIRED)
    ECDSA/SHA-384   2 0x20 (RECOMMENDED)
    ECDSA_LOW/SHA-1 3 0x30 (RECOMMENDED)


Can someone provide guidance on current style for me?



s3.4.1.1 and s8.4:  Similar question regarding '(RECOMMENDED)'.

s3.4, para 2: s/As such the following updates HIP parameters./The 
subsections

of this section document the required updates of HIP parameters./


Fixed.  Thanks, I like this improved wording.



s3.5.2.1, s3.5.3 and s3.5.4:  I suggest adding a reference to the 
HITv2 archive

where the prefix 2001:20::'28 is allocated (3 places).


is it enough to put in 3.5.2.1 a reference to sec 6, RFC7343?

   For HIPv2, the Prefix is 2001:20::/28 (Section 6 of [RFC7343]).
   'Info' is zero-length (i.e., not included), and OGA ID is 4-bit.




s4, para 2: 'The 2022 forthcoming ...' is not future proof. Suggest

Re: [Gen-art] [Drip] Genart last call review of draft-ietf-drip-rid-24

2022-05-16 Thread Robert Moskowitz 

Elwyn,

I believe your comments are the only opens left.  Does this response and 
the current drip-rid-26 address your points?


Note that the question sec 8.1 was addressed by IANA and is reflected in 
-26.


Thank you.

Bob

On 5/10/22 21:13, Robert Moskowitz wrote:



On 5/10/22 12:25, Elwyn Davies via Datatracker wrote:

Reviewer: Elwyn Davies
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-drip-rid-24
Reviewer: Elwyn Davies
Review Date: 2022-05-10
IETF LC End Date: 2022-05-11
IESG Telechat date: Not scheduled for a telechat

Summary:
Ready with nits.  I can't speak for the robustness of the security 
choices but
the document is well written apart from a couple of pieces of deep 
jargon that

may need explanation for more naive readers (notably multilateration -
definitely a new one on me!)


Multilateration occurs once in the draft, sec 9.1.  It is a main part 
of draft-moskowitz-crowd-sourced-rid where I have the definition:


   Multilateration:  Multilateration (more completely, pseudo range
  multilateration) is a navigation and surveillance technique based
  on measurement of the times of arrival (TOAs) of energy waves
  (radio, acoustic, seismic, etc.) having a known propagation speed.


Do you think it should be added here in the definitions section? I 
really don't want to pull it from 9.1, and I don't see adding this 
whole definition into 9.1.


Multilateration is an important tool in aviation traffic management.  
Oh and this is fundamental to GPS.


I do expect, at some point soon, that crowd-sourced-rid will become a 
wg draft...





Major issues:
None

Minor issues:
None

Nits/editorial comments:
Abstract/s1:  The term 'self-asserting IPv6 address'  is defined in 
Section 3
of the DRIP architecture.  AFAICS 'self-asserting' is novel 
terminology, at

least in this context, and I think  it would be good to point to the
architecture in the Abstract  and to make it a little clearer that 
the term
self-asserting (IPv6 address) is defined in the architecture - I 
missed that on

first reading - as well as the idea of HHITs.


para 2 of the Intro references Architecture, but what do you think of:

   This document describes the use of Hierarchical Host Identity Tags
   (HHITs) as self-asserting IPv6 addresses, as described in the DRIP
   Architecture, and thereby a trustable identifier for use as the
   Unmanned Aircraft System Remote Identification and tracking (UAS RID).






s1, para 3: s/are updated, these/are updated, but these/


Fixed for -25



s3.2: Query:  Is there are good reason for leaving the HIT/HHIT Suite 
ID value

4 unused?


Because draft-moskowitz-hip-new-crypto has it as '5', and that draft 
(which will be needed for secure-nrid-c2) proposed 5 (and 6) because a 
dead draft used 4...


I will see if I can move them all up.  I do have to check with 
implementors to see if there are any issues that I am forgetting.




s3.2, s3.4.2, s8.2 and s8.4:  After the definition of the 
EdDSA/cSHAKE128 value
  '(RECOMMENDED)' is appended.  What or who is this recommendation 
aimed at?
The users of the specification or IANA in relation to TBD3?  The 
registry
doesn't seem to have scope for recording this recommendation. If it 
is aimed

at users, I think there should be words to this effect in s3.2 and it is
probably not relevant in s3.4.2.


To implementors.  This is a copy from 7401, and maybe it is no longer 
the style?


From 7401:

    HIT Suite   Four-bit ID    Eight-bit encoding

    RESERVED    0 0x00
    RSA,DSA/SHA-256 1 0x10 (REQUIRED)
    ECDSA/SHA-384   2 0x20 (RECOMMENDED)
    ECDSA_LOW/SHA-1 3 0x30 (RECOMMENDED)


Can someone provide guidance on current style for me?



s3.4.1.1 and s8.4:  Similar question regarding '(RECOMMENDED)'.

s3.4, para 2: s/As such the following updates HIP parameters./The 
subsections

of this section document the required updates of HIP parameters./


Fixed.  Thanks, I like this improved wording.



s3.5.2.1, s3.5.3 and s3.5.4:  I suggest adding a reference to the 
HITv2 archive

where the prefix 2001:20::'28 is allocated (3 places).


is it enough to put in 3.5.2.1 a reference to sec 6, RFC7343?

   For HIPv2, the Prefix is 2001:20::/28 (Section 6 of [RFC7343]).
   'Info' is zero-length (i.e., not included), and OGA ID is 4-bit.




s4, para 2: 'The 2022 forthcoming ...' is not future proof. Suggest 
adding an

RFC editor note to remove '2022 forthcoming' during editing.


the doc is in ASTM editor's hands now.  But we all know about final 
editing processes!


Does this resolve your concern:

   Note to RFC

Re: [Gen-art] [Drip] Genart last call review of draft-ietf-drip-rid-24

2022-05-10 Thread Robert Moskowitz 



On 5/10/22 12:25, Elwyn Davies via Datatracker wrote:

Reviewer: Elwyn Davies
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-drip-rid-24
Reviewer: Elwyn Davies
Review Date: 2022-05-10
IETF LC End Date: 2022-05-11
IESG Telechat date: Not scheduled for a telechat

Summary:
Ready with nits.  I can't speak for the robustness of the security choices but
the document is well written apart from a couple of pieces of deep jargon that
may need explanation for more naive readers (notably multilateration -
definitely a new one on me!)


Multilateration occurs once in the draft, sec 9.1.  It is a main part of 
draft-moskowitz-crowd-sourced-rid where I have the definition:


   Multilateration:  Multilateration (more completely, pseudo range
  multilateration) is a navigation and surveillance technique based
  on measurement of the times of arrival (TOAs) of energy waves
  (radio, acoustic, seismic, etc.) having a known propagation speed.


Do you think it should be added here in the definitions section?  I 
really don't want to pull it from 9.1, and I don't see adding this whole 
definition into 9.1.


Multilateration is an important tool in aviation traffic management.  Oh 
and this is fundamental to GPS.


I do expect, at some point soon, that crowd-sourced-rid will become a wg 
draft...





Major issues:
None

Minor issues:
None

Nits/editorial comments:
Abstract/s1:  The term 'self-asserting IPv6 address'  is defined in Section 3
of the DRIP architecture.  AFAICS 'self-asserting' is novel terminology, at
least in this context, and I think  it would be good to point to the
architecture in the Abstract  and to make it a little clearer that the term
self-asserting (IPv6 address) is defined in the architecture - I missed that on
first reading - as well as the idea of HHITs.


para 2 of the Intro references Architecture, but what do you think of:

   This document describes the use of Hierarchical Host Identity Tags
   (HHITs) as self-asserting IPv6 addresses, as described in the DRIP
   Architecture, and thereby a trustable identifier for use as the
   Unmanned Aircraft System Remote Identification and tracking (UAS RID).






s1, para 3: s/are updated, these/are updated, but these/


Fixed for -25



s3.2: Query:  Is there are good reason for leaving the HIT/HHIT Suite ID value
4 unused?


Because draft-moskowitz-hip-new-crypto has it as '5', and that draft 
(which will be needed for secure-nrid-c2) proposed 5 (and 6) because a 
dead draft used 4...


I will see if I can move them all up.  I do have to check with 
implementors to see if there are any issues that I am forgetting.




s3.2, s3.4.2, s8.2 and s8.4:  After the definition of the EdDSA/cSHAKE128 value
  '(RECOMMENDED)' is appended.  What or who is this recommendation aimed at?
The users of the specification or IANA in relation to TBD3?  The registry
doesn't seem to have scope for recording this recommendation.  If it is aimed
at users, I think there should be words to this effect in s3.2 and it is
probably not relevant in s3.4.2.


To implementors.  This is a copy from 7401, and maybe it is no longer 
the style?


From 7401:

    HIT Suite   Four-bit ID    Eight-bit encoding

    RESERVED    0 0x00
    RSA,DSA/SHA-256 1 0x10   (REQUIRED)
    ECDSA/SHA-384   2 0x20 (RECOMMENDED)
    ECDSA_LOW/SHA-1 3 0x30 (RECOMMENDED)


Can someone provide guidance on current style for me?



s3.4.1.1 and s8.4:  Similar question regarding '(RECOMMENDED)'.

s3.4, para 2: s/As such the following updates HIP parameters./The subsections
of this section document the required updates of HIP parameters./


Fixed.  Thanks, I like this improved wording.



s3.5.2.1, s3.5.3 and s3.5.4:  I suggest adding a reference to the HITv2 archive
where the prefix 2001:20::'28 is allocated (3 places).


is it enough to put in 3.5.2.1 a reference to sec 6, RFC7343?

   For HIPv2, the Prefix is 2001:20::/28 (Section 6 of [RFC7343]).
   'Info' is zero-length (i.e., not included), and OGA ID is 4-bit.




s4, para 2: 'The 2022 forthcoming ...' is not future proof. Suggest adding an
RFC editor note to remove '2022 forthcoming' during editing.


the doc is in ASTM editor's hands now.  But we all know about final 
editing processes!


Does this resolve your concern:

   Note to RFC Editor: This, and all references to F3411 need to be
   updated to this new version which is in final ASTM editing.  A new
   link and replacement text will be provided when it is published.





s5, para 1: s/does not intent/does not intend/


fixed


s5:  The examples should be

Re: [Gen-art] [Drip] Genart last call review of draft-ietf-drip-rid-24

2022-05-10 Thread Robert Moskowitz 

Per Wikipedia:

"Multilateration is a technique for determining a stationary or moving 
"vehicle's" position based on measurement of the times of arrival (TOAs) 
of virtually any type (physical phenomenon) of energy wave having a 
known waveform and propagation speed when traveling either from 
(navigation) or to (surveillance) multiple system stations."


1st modern use was WW1 audio multilateration of artillery.  Anyway that 
is what I was once told...


I guess with this audience, that should be defined...

I will go over your comments and get back to you.

Bob

On 5/10/22 12:25, Elwyn Davies via Datatracker wrote:

Reviewer: Elwyn Davies
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-drip-rid-24
Reviewer: Elwyn Davies
Review Date: 2022-05-10
IETF LC End Date: 2022-05-11
IESG Telechat date: Not scheduled for a telechat

Summary:
Ready with nits.  I can't speak for the robustness of the security choices but
the document is well written apart from a couple of pieces of deep jargon that
may need explanation for more naive readers (notably multilateration -
definitely a new one on me!)

Major issues:
None

Minor issues:
None

Nits/editorial comments:
Abstract/s1:  The term 'self-asserting IPv6 address'  is defined in Section 3
of the DRIP architecture.  AFAICS 'self-asserting' is novel terminology, at
least in this context, and I think  it would be good to point to the
architecture in the Abstract  and to make it a little clearer that the term
self-asserting (IPv6 address) is defined in the architecture - I missed that on
first reading - as well as the idea of HHITs.

s1, para 3: s/are updated, these/are updated, but these/

s3.2: Query:  Is there are good reason for leaving the HIT/HHIT Suite ID value
4 unused?

s3.2, s3.4.2, s8.2 and s8.4:  After the definition of the EdDSA/cSHAKE128 value
  '(RECOMMENDED)' is appended.  What or who is this recommendation aimed at?
The users of the specification or IANA in relation to TBD3?  The registry
doesn't seem to have scope for recording this recommendation.  If it is aimed
at users, I think there should be words to this effect in s3.2 and it is
probably not relevant in s3.4.2.

s3.4.1.1 and s8.4:  Similar question regarding '(RECOMMENDED)'.

s3.4, para 2: s/As such the following updates HIP parameters./The subsections
of this section document the required updates of HIP parameters./

s3.5.2.1, s3.5.3 and s3.5.4:  I suggest adding a reference to the HITv2 archive
where the prefix 2001:20::'28 is allocated (3 places).

s4, para 2: 'The 2022 forthcoming ...' is not future proof. Suggest adding an
RFC editor note to remove '2022 forthcoming' during editing.

s5, para 1: s/does not intent/does not intend/

s5:  The examples should be using the 'example' top level domain.

s5, para 7:  The phrase 'If we assume a prefix of 2001:30::/28,' is confusing.
This prefix is the one the document is asking IANA to allocate for the HHITs so
I suggest 'Using the allocated prefix for HHITs TBD6 [suggested value
2001:30::/28] (See Section 3.1)'.

s8.1,  last item:  'False?': A decision needs to be taken on what value should
be here.

s9.1, para 4:  Is 'multilateration' sufficiently well understood to be used
without explanation?

App A, para 1: s/EU/The EU/ (2 places).





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