Re: [auth48] [C381] AUTH48 cluster questions: AUTH48: RFCs-to-be 9299 - 9306

[Luigi Iannone <[e-mail]>]

Hi,

I do agree with Dino’s suggestions.

Ciao

L.


> On 21 Sep 2022, at 03:31, Dino Farinacci <[e-mail]> wrote:
> 
>> Greetings all,
>> 
>> While reviewing this cluster of documents*, please reply regarding the 
>> questions below regarding consistency across the cluster.  These questions 
>> are in addition to the document-specific questions that have been sent.  
>> Your reply will likely impact two or more of the documents in the cluster, 
>> so please discuss as necessary, and let us know the group decision.  (You 
>> have the option of updating the edited XML files accordingly, if you are so 
>> inclined.)  We will wait to hear from you before continuing with the 
>> publication process.
> 
> I believe any reference to a data structure, packet type, or fields in a packet should be capitalized to distinguish it. My comments so far have been consistent with that convention. So I will comment the same way below.
> 
>> 1) The following terms were used inconsistently in this cluster.
>> We updated to use the latter forms.  Please let us know any
>> objections.
>> 
>> map-cache / Map-Cache
> 
> Map-Cache
> 
>> RLOC-probe / RLOC/Probe (noun)
>> (per much more common usage in this cluster) *
>> 
>> * Please note, however, that RFC 6830 uses "RLOC-probe".
>> 
>> RLOC probing / RLOC-probing / RLOC-Probing
> 
> An RLOC-Probe is a noun, RLOC-probing is a verb by "sending an RLOC-Probe". I think we should keep everything the way it is and just spell out as "RLOC-Probe" and "RLOC-Probing".
> 
>> 2) Throughout the text, the following terminology appears to be used 
>> inconsistently.  Please review these occurrences and let us know
>> how/if they may be made consistent.  
>> 
>> the Authentication Data vs. the authentication data (used generally
>>  in running text)
> 
> Authentication Data
> 
>> echo-nonce vs. Echo-nonce vs. Echo-Nonce vs. echo nonce (in running text)
> 
> Echo-Nonce
> 
>> encapsulated Map-Request (draft-ietf-lisp-sec) vs.
>>  Encapsulated Map-Request (draft-ietf-lisp-rfc6833bis,
>>  draft-ietf-lisp-sec (1 instance in Section 6.7))
> 
> Encapsulated Map-Request
> 
>> EID-prefix vs. EID-Prefix vs. EID prefix
> 
> EID-Prefix
> 
>> EID record vs. EID-record (in text)
> 
> EID-Record
> 
>> RLOC record vs. RLOC-record (in text)
> 
> RLOC-Recort
> 
>> EID-to-RLOC cache (draft-ietf-lisp-sec) vs.
>>  EID-to-RLOC Cache (draft-ietf-lisp-rfc6830bis)
> 
> All occurences should say just "Map-Cache" or "EID-to-RLOC Map-Cache".
> 
>> locator(s) vs. Locator(s) (used more generally)
> 
> Locator(s)
> 
>> locator address vs. Locator address
>>  (i.e., "each Locator address" in draft-ietf-lisp-rfc6830bis but
>>   "locator address" used generally in draft-ietf-lisp-rfc6833bis)
> 
> Locator Address
> 
>>  Do these instances all mean "Routing Locator address"?
> 
> Yes, they do. And you can change all occurences of "locator address" to "Routing Locator Address".
> 
>> longest-match (draft-ietf-lisp-rfc6830bis) vs.
>>  longest match (draft-ietf-lisp-sec)
> 
> longest-match
> 
>> mapping system vs. Mapping System
> 
> Mapping System
> 
>> RLOC-set (draft-ietf-lisp-rfc6833bis) vs.
>>  RLOC set (draft-ietf-lisp-rfc6830bis, draft-ietf-lisp-6834bis)
> 
> RLOC-Set
> 
>> Email for Vince Fuller:
>> =======================
>> [e-mail]
>> [e-mail]
> 
> Vince's information and affliation is in RFC 9300. He provided it during IESG review.
> 
> Dino
> 
>