Re: [mpls] Notes on draft-jags-mpls-mna-hdr-04

[Tony Li <[e-mail]>]

Hi Greg,


>>>> How about we add this:
>>>> 
>>>> 	A node that removes the last NAS that references post-stack
>>>> 	data MUST also remove the post-stack data.
>>> GIM>> It is clearer. Do you think that a small tweak will help a bit more:
>>> Tony's text:
>>> 	A node that removes the last NAS that references post-stack
>>> 	data MUST also remove the post-stack data.
>>> Greg's text:
>>> 	A node that removes the last NAS that references post-stack
>>> 	data MUST also remove that post-stack data.
>> 
>> 
>> That begs the question, if it’s not removing all of the PSD, which parts does it remove?
> GIM2>> Great question, thank you. I imagine that if a NAS that references a PSD is removed, then only the PSD that is referenced may be removed. Would an additional word-tweaking help:
> NEW TEXT:
> A node that removes a NAS that references PSD MUST
> remove the PSD if no other NAS references it.


After consulting with others, I would like to propose something similar:

	A node that removes the only NAS that has the P bit set MUST remove all PSD.

>>>>> s/OAM logging/OAM action/?
>>>> 
>>>> I think you’re referring to the text in the introduction. The intent here was to refer to the actual result of the OAM action, not the action itself.
>>> GIM>> Although sometimes an OAM action triggers logging a message, that is not always the case. Was it in reference to a specific OAM action?
>> 
>> 
>> No.  This was just an example.  We’re talking about sentence 2 in the introduction:
>> 
>> 	Forthcoming applications require MPLS packets to perform special network actions 
>> 	and carry optional Ancillary Data (AD) that can affect the packet 
>> 	forwarding decision or trigger OAM logging.
>> 
>> I would be happy to change ‘can’ to ‘could’, or add the words ‘, for example’ at the end, if that would help.
> GIM2>> Personally, I prefer the latter but either works. 


Agreed. Done.


>>>>> User-defined actions are mentioned twice in the document. Considering the extent of the document, a new document documenting user-defined actions, their scope, etc., would be a reasonable format. What do you think?
>>>> 
>>>> I don’t understand the concern. This document reserves code points for user-defined actions.  Beyond that, it’s completely up to the users to document such actions. It’s a completely blank slate and I’m not sure what more can be said. The whole point it to leave it as open as possible.
>>> GIM>> As Loa suggested, having a new document is reasonable. I'd be happy to note that the user-defined actions are outside the scope of this document and are for further study. 
>> 
>> 
>> User defined actions need to be documented here at least a little bit.  At the very least, we need to mention them and then we need the allocation for some code points in the IANA considerations section (where they’re labelled ‘private use’ to match IANA conventions), so I don’t think we can wholesale remove them.
>> 
>> I still don’t understand what more needs to be said.
> GIM2>> I'll leave that to the group discussion. I have some uneasy feelings toward user-defined MNAs, but yet nothing that I can put my finger at.


I concur with the uneasy feelings. :-)


Regards,
Tony