Hi Mirja, Thank you for your quick feedback. Please see inline …
On 8/17/17, 6:12 AM, "Mirja Kuehlewind (IETF)" <[email protected]> wrote: <snip> .. keeping only the open issues. > >> >> >> >>> >>> 3) This document does not really normative specify the use of the newly >>> defined >>> options. It only gives an examples but it does not specify normatively >>>any >>> actions that need to performed on receipt of these options. How does >>>the >>> MAG >>> know if the LMA does not support Multipath binding? An LMA that does >>>not >>> implement this spec will not send back an error message. Why are there >>>two >>> different options? What happens if one of the options is present in the >>> Proxy >>> Binding Update but not the other? >>> >> >> >> This is a good point. There is an implicit assumption that the LMA >> behavior is consistent with the behavior when dealing with any unknown >> options. >> We can put a note that the PBU will rejected with error code 128. > >That's good. Are you supposed to resend without the new options if you >received 128? And again what happens if only one option is present? I will take care of this. Will add considerations on both LMA/MAG behavior when there is version incompatibility. Will post a new rev with these considerations. But, thank you; we definitely overlooked this part. > >> >> >> >> >> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> Please also clarify the definitions of Interface Label and Binding >>> Identifier >>> as requested by the gen-art review (Thanks Robert!) >>> >> >> Interface label is a static field, Ex: “LTE-Interface”, “my blue >> interface”. Traffic policy is tied to this static label, >> >> HTTP Flow: Use LTE-Interface, if not available, use “WiFI-Interface”. >> Label is tied to a policy; which the MAG and LMA will translate it bind >> the flow to a dynamically created tunnel using the CoA from that >>interface. >> >> Binding identifier is what is dynamically generated and using to >>identify >> a specific binding on the LMA. > >I think this comment was on the way it is described in the draft. Maybe >the wording can be further clarified there. Here is the original text >from the genart review of Robert Sparks: I have looked at both the definitions and I agree it needs to some clarification. I will fix this. > >"* I still find the definitions of Interface Label and Binding Identifier >confusing. > I suspect they _both_ need to be carefully rewritten to make sure they >are > definitions of the terms, and not descriptions of the interactions of >the two > fields. Why is the Interface Label definition talking so much about >binding? > As currently written, that last sentence of the Binding Identifier > definition says the document says the mobile access gateway assigns > a single unique binding identifier for each of its interfaces. „ > > >Thanks! >Mirja > > > >> >> >> >> >>> >> > _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
