[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cifs-protocol
Subject:    Re: [cifs-protocol] [REG:115071012931908] MS-ADTS 6.2.2.3.4.3 KCC ColorVertices
From:       Douglas Bagnall <douglas.bagnall () catalyst ! net ! nz>
Date:       2015-07-11 11:07:08
Message-ID: 55A0F8DC.2020705 () catalyst ! net ! nz
[Download RAW message or body]

hi Edgar,

Sorry for the excessive musing -- I just want to be sure that the
section highlighted section really intends to be using localSiteVertex
and not v.

thanks,
Douglas

On 11/07/15 08:00, Edgar Olougouna wrote:
> Douglas,
> I will assist you on this inquiry. Can you clarify whether you'd like me to review \
> your comments on the algorithm? Sorry I am trying scope this to a precise question.
> 
> Thanks,
> Edgar
> 
> -----Original Message-----
> From: Tarun Chopra 
> Sent: Friday, July 10, 2015 11:13 AM
> To: Douglas Bagnall
> Cc: cifs-protocol@lists.samba.org; MSSolve Case Email; Edgar Olougouna
> Subject: [REG:115071012931908] MS-ADTS 6.2.2.3.4.3 KCC ColorVertices
> 
> Hello Douglas
> 
> We have created a case; 115071012931908, to track your inquiry and Edgar (lopped in \
> Cc) will be assisting you further. 
> Best Regards,
> Tarun Chopra | Sr. Escalation Engineer
> Open Specifications Support Team
> Work +1-425-705-5042
> Email  tarun.chopra@microsoft.com
> Monday-Friday 9:00a-6:00p Pacific Timezone
> 
> 
> -----Original Message-----
> From: Douglas Bagnall [mailto:douglas.bagnall@catalyst.net.nz] 
> Sent: Thursday, July 9, 2015 6:28 PM
> To: Interoperability Documentation Help
> Cc: cifs-protocol@lists.samba.org
> Subject: MS-ADTS 6.2.2.3.4.3 KCC ColorVertices
> 
> hi Dochelp,
> 
> In the ColorVertices function:
> 
> LET localSiteVertex be the vertex in graph.Vertices such that
> localSiteVertex.ID = objectGUID of the local DC's site object
> FOR each v in g.Vertices
> FOR each interSiteTransport object t that is a child of the
> CN=Inter-Site Transports child of the CN=Sites child of the
> config NC
> IF localSiteVertex.Color = COLOR.RED and t!name ≠ "IP"
> and FLAG_CR_NTDS_DOMAIN bit is set in cr!systemFlags
> Skip t
> ENDIF
> IF no edge e exists in g.Edges such that e.VertexIDs
> contains v.ID
> Skip t
> ENDIF
> LET partialReplicaOkay be TRUE if and only if
> localSiteVertex.Color = COLOR.BLACK
> 
> LET bh be the result of GetBridgeheadDC(
> localSiteVertex.ID, cr, t, partialReplicaOkay,
> detectFailedDCs)
> IF bh = null
> /* No bridgehead DC is currently available. */
> SET foundFailedDCs to TRUE
> Skip t
> ENDIF
> APPEND t!objectGUID to v.AcceptRedRed
> APPEND t!objectGUID to v.AcceptBlack
> ENDFOR
> ENDFOR
> 
> ... GetBridgeheadDC() is being called for the localSiteVertex in a loop over all \
> the graph vertices. That's this bit in the middle: 
> LET partialReplicaOkay be TRUE if and only if
> localSiteVertex.Color = COLOR.BLACK
> 
> LET bh be the result of GetBridgeheadDC(
> localSiteVertex.ID, cr, t, partialReplicaOkay,
> detectFailedDCs)
> 
> which seems invariant with regard to the outer loop -- it will produce the same \
> answers for each vertex -- and somewhat irrelevant for the Accept* lists on the \
> remote vertex. It looks to me like it would make sense to use the vertex v in place \
> of localSiteVertex in this part. However, the spec is very determined to generate \
> the localSiteVertex variable for something, so this doesn't look like a simple \
> typo. In effect this looks like a roundabout way of saying nothing gets added to \
> anyone's Accept* lists when there is no local bridgehead. 
> regards,
> Douglas
> 


_______________________________________________
cifs-protocol mailing list
cifs-protocol@lists.samba.org
https://lists.samba.org/mailman/listinfo/cifs-protocol


[prev in list] [next in list] [prev in thread] [next in thread]