Re: [Last-Call] Fwd: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-04.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Bob,

 

Please see inline.

 

Cheers,

Med

 

De : Robert Moskowitz <rgm@xxxxxxxxxxxxxxxxxxxx>
Envoyé : lundi 21 novembre 2022 14:25
À : last-call@xxxxxxxx; draft-moskowitz-ipsecme-ipseckey-eddsa.all@xxxxxxxx; BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@xxxxxxxxxx>
Objet : RE: [Last-Call] Fwd: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-04.txt

 

 

In response to a reminder of an earlier comment:

-------- Forwarded Message --------

Subject:

Re: [Drip] Fwd: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-03.txt

Date:

Tue, 8 Nov 2022 08:08:38 +0000

From:

mohamed.boucadair@xxxxxxxxxx

To:

Robert Moskowitz <rgm@xxxxxxxxxxxxxxxxxxxx>, saag@xxxxxxxx <saag@xxxxxxxx>, tm-rid@xxxxxxxx <tm-rid@xxxxxxxx>, Roman D. Danyliw <rdd@xxxxxxxx>


>

>
> Hi Rob,
>
>  
>
> I have two comments about the IANA section:
>
>  
>
> (1) As you are changing the format of the ipseckey-rr-parameters table (by adding a new “Format description” column), please update the text with an explicit action for IANA. This change does not impact RFC4025, IMO.
>

I believe that the text in -04 covers this:

   This document requests IANA to update the "Description" field in
   existing entries of the "Algorithm Type Field" subregistry of the
   "IPSECKEY Resource Record Parameters" [IANA-IPSECKEY] to explicitly
   state that is for "Public" keys:

"requests IANA to update" sounds like explicit action for IANA.

[Med] That request is about the information in the “Description”. I was looking for something close to the following:

 

OLD:

   This document requests IANA to update the "Description" field in

   existing entries of the "Algorithm Type Field" subregistry of the

   "IPSECKEY Resource Record Parameters" [IANA-IPSECKEY] to explicitly

   state that is for "Public" keys:

 

NEW:

    This document requests IANA to add a new field “Format Specification”

   to the "Algorithm Type Field" subregistry of the "IPSECKEY Resource

   Record Parameters" [IANA-IPSECKEY]. Also, this document requests IANA

  to update the "Description" field in existing entries of that

   registry to explicitly state that is for "Public" keys:

 

         …

 

   IANA is requested to update the reference of that registry by adding the

   the RFC number to be assigned to this document.

 

>  
>
> (2) I would delete this text as it is redundant with the text right before + the entry right after:
>
>  
>
>    IPSECKEY:
>
>       This document defines the new IPSECKEY value TBD1 (suggested: 4)
>
>       (Section 2) in the "Algorithm Type Field" subregistry of the
>
>       "IPSECKEY Resource Record Parameters" registry.
>

I disagree, as the first section is asking IANA to change the formating (and add some text) to the current entries in the subregistry.

 

[Med] By the “text right before”, I meant:

 

   Further, this document requests IANA to make the following addition

   to the "IPSECKEY Resource Record Parameters" [IANA-IPSECKEY]

   registry:

 

vs.

 

   IPSECKEY:

      This document defines the new IPSECKEY value TBD1 (suggested: 4)

      (Section 2) in the "Algorithm Type Field" subregistry of the

      "IPSECKEY Resource Record Parameters" registry.

 

vs.

 

   Value  Description                Format description    Reference
 
   TBD1   An EdDSA Public Key        [RFC8080], Sec. 3     [ThisRFC]

 

 

Whereas this 2nd section is instructing IANA to ADD an additional entry to the subregistry.

[Med] Yes, I know. This was very minor. My point is that you can save some lines by avoiding redundant information.


Two different requests, worded differently.


Bob


>  
>
> Thanks.  
>
>  
>
> Cheers,
>
> Med
>


_________________________________________________________________________________________________________________________

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.
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux