Re: correct Error code

Hi Tolga,

It's a subtle point about the definitions.  My personal views are
unchanged, but I think this argument is being addressed in the other
branch of this thread.

My intended contribution just that the RFC appears to have some text
missing in one of the critical passages, that could perhaps be addressed
if there is ever another rev of M3UA.

Andrew

Tolga Asveren wrote:
> If RC is configured statically per ASP on SGP, I wouldn't think it is wrong
> to say that it is invalid for that particular ASP. The peers are ASPs and
> SGPs in that relationship.
>
>    Thanks,
>    Tolga
>
>   
>> -----Original Message-----
>> From: Andrew Booth [mailto:[email protected]]
>> Sent: Thursday, March 29, 2007 8:55 AM
>> To: Aditya; [email protected]
>> Subject: Re: [Sigtran] correct Error code
>>
>>
>> Hi,
>>
>> I agree with Brian.  The RC is not invalid, the SGP is just refusing the
>> ASP ACTIVE.  Hence "Refused Management Blocking" is appropriate.
>>
>> As an aside, I think the text of the pertinent paragraph is missing
>> something.  The meaning is fairly clear, but it should probably read:
>>
>> If for any local reason the SGP will not act on the ASP ACTIVE request
>> (e.g., management lockout) the SGP responds to an ASP Active message
>> with an Error message with reason "Refused Management Blocking".
>>
>> Andrew
>>
>> Brian F. G. Bidulock wrote:
>>     
>>> Aditya,
>>>
>>> The RC is not invalid: the ASP is merely not permitted to
>>>       
>> activate for it.
>>     
>>> In this case it is management blocked.  The peer should be welcome to
>>> retry, because at some point in the future it might be
>>>       
>> permitted to activate
>>     
>>> for the AS (e.g. the permission might have only been revoked
>>>       
>> temporarily).
>>     
>>> Sending "Invalid Routing Context" would make the peer believe that the
>>> corresponding RK is not provisioned (which it is) and might result in a
>>> dynamic registration attempt (which is inappropriate).
>>>
>>> Besides, if "Invalid Routing Context" is returned, it violates
>>>       
>> the MUST in
>>     
>>> this passage:
>>>
>>>
>>>       
>>>>      - If the RC parameter is included in the ASP Active
>>>>         
>> message and the
>>     
>>>>      corresponding RK has been previously defined (by either static
>>>>      configuration or dynamic registration), the peer node MUST respond
>>>>      with an ASP Active Ack message. If for any local reason (e.g.,
>>>>      management lockout) the SGP responds to an ASP Active message with
>>>>      an Error message with reason "Refused Management Blocking".
>>>>
>>>>         
>>> --brian
>>>
>>> Aditya wrote:                                     (Thu, 29 Mar
>>>       
>> 2007 05:53:59)
>>     
>>>>    Brian,
>>>>    RFC  4666  mentions Invalid Routing Context to be sent if a
>>>>         
>> message is
>>     
>>>>    received  from  a  peer  with an invalid(unconfigured)
>>>>         
>> Routing Context
>>     
>>>>    value. Your analysis makes me think that only unconfigured
>>>>         
>> RC is to be
>>     
>>>>    treated  as  Invalid.  Isnt  the  RC  invalid in the
>>>>         
>> example mentioned
>>     
>>>>    below.
>>>>    I  may be wrong but sending ERR management Locked message
>>>>         
>> somehow does
>>     
>>>>    not  inform  the  peer that there is something wrong at its
>>>>         
>> end. IMHO,
>>     
>>>>    "Invalid Routing Context" seems like an appropriate
>>>>         
>> message, since the
>>     
>>>>    RC is INVALID in this case. The RC being configured does
>>>>         
>> not take away
>>     
>>>>    from the fact that it is invalid.
>>>>    Does  RFC  4666  state  anywhere that only unconfigured
>>>>         
>> RC's are to be
>>     
>>>>    treated as Invalid? I mean, does it define Invalid RC in any sense.
>>>>    Aditya
>>>>
>>>>         
>>>
>>>       
>> _______________________________________________
>> Sigtran mailing list
>> [email protected]
>> https://www1.ietf.org/mailman/listinfo/sigtran
>>     
>
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>