Hi Tom, The changes to take into account the outcome of this thread can be seen at https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-telemetry-20 I highly appreciate your effort to review as much documents in the IETF LC. Big thanks for that. Your review is ACKed in the document. Cheers, Med > -----Message d'origine----- > De : tom petch <daedulus@xxxxxxxxxxxxx> > Envoyé : vendredi 21 janvier 2022 12:32 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@xxxxxxxxxx>; last- > call@xxxxxxxx > Cc : dots-chairs@xxxxxxxx; valery@xxxxxxxxxxx; dots@xxxxxxxx; draft- > ietf-dots-telemetry@xxxxxxxx > Objet : Re: Last Call: <draft-ietf-dots-telemetry-19.txt> (Distributed > Denial-of-Service Open Threat Signaling (DOTS) Telemetry) to Proposed > Standard > > On 19/01/2022 12:56, mohamed.boucadair@xxxxxxxxxx wrote: > > Hi Tom, > > > > Thank you for checking the changes and sharing your feedback. > > > > Please see inline. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : tom petch <daedulus@xxxxxxxxxxxxx> Envoyé : mercredi 19 janvier > >> 2022 13:35 > >> > > ... > >>> ... > >>>> > >>>>>> The user has to understand that [Enterprise-Numbers] is the same > >>>>>> as Private Enterprise Numbers", which may not be apparent; > >>>>>> consistent terminology is good. > >>>>> > >>>>> [Med] Not sure a (which) change is needed. The current text says: > >>>> > >>>> In most walks of life, if you have a registry and a private > >>>> registry, then users will assume that the registry is public and > >>>> the private registry is private and that there are two separate > >>>> registries. Here there is just the one and the correct name is > >>>> 'Private Enterprise Number' sometimes abbreviated to PEN. Experts > >>>> will know that there is no Public Enterprise Number, others will > >>>> not so I think we should use Private Enterprise Number in all cases > >>>> and not just Enterprise > >> Number. > >>>> > >>> > >>> [Med] Went with the following change: > >>> > >>> OLD: > >>> > >>>>> vendor-id: Vendor ID is a security vendor's Enterprise > >>>>> Number > >> as > >>>>> registered with IANA [Enterprise-Numbers]. > >>>>> > >>> > >>> NEW: > >>> vendor-id: Vendor ID is a security vendor's enterprise number > as > >>> registered in the IANA's "Private Enterprise Numbers" > registry > >>> [Enterprise-Numbers]. > >> > >> > >> You have still got half a dozen or so uses of 'Enterprise Number' in > >> the I-D and my preference would be to change them all to 'Private > >> Enterprise Number'! > > > > [Med] No change is made for the other occurrences on purpose. For > > example, > > > > The examples use the Enterprise Number 32473 defined for > > documentation use [RFC5612]. > > > > no change is made to that text because we want to be consistent with > existing RFC5612 which says the following: > > > > IANA has updated the registration for Enterprise Number 32473 to > > point to this RFC. > > > > As I said before, an expert knows that there is no Public > >> Enterprise Number, others do not. > >> > > > > [Med] Added this new entry to the terminology section: > > > > NEW: > > The document uses IANA-assigned Enterprise Numbers. These numbers > > are also known as "Private Enterprise Numbers" and "SMI (Structure > of > > Management Information) Network Management Private Enterprise > Codes" > > [Enterprise-Numbers]. > > > > Better? > > > I cannot see us agreeing on this. The fact that the terminology of > RFC5612 is not what it might be does not, for me, sanction other such > glitches. > > Tom Petch _________________________________________________________________________________________________________________________ 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
