Re: [Last-Call] Opsdir last call review of draft-ietf-drip-reqs-12

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

 



Hi Nagendra, 

Thank you for the comments.

For your comment about the AAA entry:

   AAA
      Attestation, Authentication, Authorization, Access Control,
      Accounting, Attribution, Audit, or any subset thereof (uses differ
                                      ^^^^^^^^^^^^^^^^^^^^^^    
      by application, author, and context).  (DRIP)
                                              ^^^^
I confirm that the WG had that discussion. The outcome of that discussion is to tag this entry as DRIP specific + indicate that the term is also used to refer to a subset of these functions. 

It wasn't clear at that time the need to use a different term such as the one you suggested (DRIP-AAA) as this will overload the other drip documents that will refer anyway to the terms defined in this I-D.

I trust the authors will fix the other points.

Cheers,
Med

> -----Message d'origine-----
> De : Nagendra Nainar via Datatracker [mailto:noreply@xxxxxxxx]
> Envoyé : lundi 7 juin 2021 23:55
> À : ops-dir@xxxxxxxx
> Cc : draft-ietf-drip-reqs.all@xxxxxxxx; last-call@xxxxxxxx; tm-
> rid@xxxxxxxx
> Objet : Opsdir last call review of draft-ietf-drip-reqs-12
> 
> Reviewer: Nagendra Nainar
> Review result: Has Nits
> 
> Hi,
> 
> I have reviewed this document as part of the Operational
> directorate's ongoing effort to review all IETF documents being
> processed by the IESG.  These comments were written with the intent
> of improving the operational aspects of the IETF drafts per
> guidelines in RFC5706.
> 
> Comments that are not addressed in last call may be included in AD
> reviews during the IESG review.  Document editors and WG chairs
> should treat these comments just like any other last call comments.
> 
> Version: draft-ietf-drip-reqs-12
> 
> Overall Summary:
> 
> This draft is an informational track defining the terminologies and
> listing the requirements for DRIP.
> 
> Overall this is a well-written document explaining the requirements
> and the rationale behind the same. This document does not propose
> any new standards or extensions to the existing standards and so
> does not introduce any operational challenges or gaps as such. I am
> choosing "Has Nits" only to check if the authors can address any of
> the below observations. Otherwise, it is ready.
> 
> Few observations below:
> 
> ==> Is there any reference that you can add to the below-mentioned
> community documents?.
> 
> "On this and other terminological issues, to encourage comprehension
>    necessary for adoption of DRIP by the intended user community,
> that
>    community's norms are respected herein, and definitions are
> quoted in
>    cases where they have been found in that community's documents."
> 
> ==> Based on the below DRI suffice, I assume that the below one is
> defined by this document.
> 
> "AAA
>       Attestation, Authentication, Authorization, Access Control,
>       Accounting, Attribution, Audit, or any subset thereof (uses
> differ
>       by application, author, and context).  (DRIP)"
> 
> AAA is common terminology used for "Authentication, Authorization,
> and Accounting". While they both seem to be similar, is there any
> need to use a different term to differentiate DRIP-AAA from the
> traditional AAA?.
> 
> ==> The text below Figure 3 appears to mention UA-GCS, UA-Internet,
> and GCS-Internet, but this is not clear in the figure.
> 
> "Figure 3 illustrates Network RID information flows.  Only two of
> the
>    three typically wireless links shown involving the UAS (UA-GCS,
> UA-
>    Internet, and GCS-Internet) need exist"
> 
> Thanks,
> Nagendra
> 


_________________________________________________________________________________________________________________________

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