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

[Albert Cabellos <[e-mail]>]

Hi

I agree with Dino, regarding my affilitiation please use this:

Universitat Politecnica de Catalunya
c/ Jordi Girona s/n
08034 Barcelona
Spain

Thanks

Albert

> On 21 Sept 2022, at 13:54, Luigi Iannone <[e-mail]> wrote:
> 
> 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
>> 
>> 
>