Re: [Drip] WGLC of draft-ietf-drip-rid-13 (Ends 29/11/2021) ( was IETF 112 drip-rid presentation comment)

[[e-mail]]

Hi Bob, all, 

I'm afraid that we don't have strong justification to ask for a shorter prefix vs the length that is used for ORCHID. No?

BTW, Bob can you please update the draft to follow this template for the prefix request from 2001::/23?  

=====
   o  Address Block - A block of IPv6 addresses that has been
      registered for a special purpose.

   o  Name - A descriptive name for the special-purpose address block.

   o  RFC - The RFC through which the special-purpose address block was
      requested.

   o  Allocation Date - The date upon which the special-purpose address
      block was allocated.

   o  Termination Date - The date upon which the allocation is to be
      terminated.  This field is applicable for limited-use allocations
      only.

   o  Source - A boolean value indicating whether an address from the
      allocated special-purpose address block is valid when used as the
      source address of an IP datagram that transits two devices.

   o  Destination - A boolean value indicating whether an address from
      the allocated special-purpose address block is valid when used as
      the destination address of an IP datagram that transits two
      devices.

   o  Forwardable - A boolean value indicating whether a router may
      forward an IP datagram whose destination address is drawn from the
      allocated special-purpose address block between external
      interfaces.

   o  Global - A boolean value indicating whether an IP datagram whose
      destination address is drawn from the allocated special-purpose
      address block is forwardable beyond a specified administrative
      domain.

   o  Reserved-by-Protocol - A boolean value indicating whether the
      special-purpose address block is reserved by IP, itself.  This
      value is "TRUE" if the RFC that created the special-purpose
      address block requires all compliant IP implementations to behave
      in a special way when processing packets either to or from
      addresses contained by the address block.
======

Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : Robert Moskowitz <[e-mail]>
> Envoyé : mercredi 1 décembre 2021 18:20
> À : Stuart W. Card <[e-mail]>; BOUCADAIR Mohamed
> INNOV/NET <[e-mail]>
> Cc : [e-mail]; Jeff Ahrenholz <[e-mail]>
> Objet : Re: [Drip] WGLC of draft-ietf-drip-rid-13 (Ends 29/11/2021) ( was
> IETF 112 drip-rid presentation comment)
> 
> We MUST NOT in the broader use have a hash less than 64 bits. Enough
> issues with this.  So either go with my 'closed enclave' 60 bits for the
> 8 bit Suite ID, or take 4 bits out of the stuff to the left.  Smaller HID
> space or smaller prefix.
> 
> I can't budge on a 64 bit hash as the MINIMUM.  I really don't like the
> 60 bit closed enclave hack.
> 
> Bob
> 
> On 11/29/21 12:59, Stuart W. Card wrote:
> > Reminder: I raised another issue in the email to which Med was
> > responding, not just a CIDR structure for prefix/RAA/HDA...
> >
> > The horrible HIT Suite ID hack of 20 years ago!
> >
> > That _may_ have been appropriate for an _experimental_ protocol.
> >
> > It _may_ have been appropriate for HITs rather than HHITs.
> >

_________________________________________________________________________________________________________________________

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.